Updated to work with Expressive dev-feature/stratigility-2.0

Updates to allow working with Stratigility 2.0 via the Expressive feature/stratigility-2.0 feature branch. This means that middleware should be http-interop/http-middleware types as much as possible, and also means that default invocation is via process().
This is a work in progress until that feature branch is merged to Expressive's develop branch and/or tagged as version 2.0.

Just tried it, in PHP 7.1 and got the following error:
Fatal error: Uncaught Error: Call to a member function process() on string
in /vendor/zendframework/zend-expressive/src/Middleware/DispatchMiddleware.php on line 43

@samsonasik Can you do the following for me, please?

How are you piping and/or routing middleware? Can you provide examples?
Related, can you provide the dependency (container) configuration for the piped and routed middleware?
What is the output of composer show?

@weierophinney here is what I tried:

I use default skeleton (zf-servicemanager, zend-router, zend-view), the HomeAction same as https://github.com/weierophinney/zend-expressive-skeleton/blob/067f39f785579a5ff39fdf0deed63f20174a7ef6/src/App/src/Action/HomePageAction.php
I used default skeleton for dependency container config (nothing changed)
Here is my composer.json config:

    "require": {
        "php": "^5.6 || ^7.0",
        "roave/security-advisories": "dev-master",
        "zendframework/zend-expressive": "dev-feature/stratigility-2.0 as 1.1.0",
        "zendframework/zend-expressive-helpers": "^3.0",
        "zendframework/zend-stdlib": "^2.7 || ^3.0",
        "zendframework/zend-expressive-zendrouter": "^2.0",
        "zendframework/zend-servicemanager": "^2.7.3 || ^3.0",
        "zendframework/zend-expressive-zendviewrenderer": "^1.0"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/weierophinney/zend-expressive.git"
        }
    ],

Here is composer show output:

$ composer show
container-interop/container-interop            1.1.0                                Promoting the interoperability of container objects (DIC, SL, etc.)
doctrine/instantiator                          1.0.5                                A small, lightweight utility to instantiate objects in PHP without invoking their constructors
fig/http-message-util                          1.1.0                                Utility classes and constants for use with PSR-7 (psr/http-message)
filp/whoops                                    2.1.5                                php error handling for cool kids
http-interop/http-middleware                   0.4.1                                Common interface for HTTP server-side middleware
phpdocumentor/reflection-common                1.0                                  Common reflection classes used by phpdocumentor to reflect the code structure
phpdocumentor/reflection-docblock              3.1.1                                With this component, a library can provide support for annotations via DocBlocks or otherwise retrieve information that is...
phpdocumentor/type-resolver                    0.2.1
phpspec/prophecy                               v1.6.2                               Highly opinionated mocking framework for PHP 5.3+
phpunit/php-code-coverage                      2.2.4                                Library that provides collection, processing, and rendering functionality for PHP code coverage information.
phpunit/php-file-iterator                      1.4.2                                FilterIterator implementation that filters files based on a list of suffixes.
phpunit/php-text-template                      1.2.1                                Simple template engine.
phpunit/php-timer                              1.0.8                                Utility class for timing
phpunit/php-token-stream                       1.4.9                                Wrapper around PHP's tokenizer extension.
phpunit/phpunit                                4.8.34                               The PHP Unit Testing framework.
phpunit/phpunit-mock-objects                   2.3.8                                Mock Object library for PHPUnit
psr/http-message                               1.0.1                                Common interface for HTTP messages
roave/security-advisories                      dev-master 3db4b0d                   Prevents installation of composer packages with known security vulnerabilities: no API, simply require it
sebastian/comparator                           1.2.4                                Provides the functionality to compare PHP values for equality
sebastian/diff                                 1.4.1                                Diff implementation
sebastian/environment                          1.3.8                                Provides functionality to handle HHVM/PHP environments
sebastian/exporter                             1.2.2                                Provides the functionality to export PHP variables for visualization
sebastian/global-state                         1.1.1                                Snapshotting of global state
sebastian/recursion-context                    1.0.2                                Provides functionality to recursively process PHP variables
sebastian/version                              1.0.6                                Library that helps with managing the version number of Git-hosted PHP projects
squizlabs/php_codesniffer                      2.7.1                                PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and detects violations of a defined set of coding standards.
symfony/yaml                                   v3.2.2                               Symfony Yaml Component
webmozart/assert                               1.2.0                                Assertions to validate method input/output with nice error messages.
zendframework/zend-diactoros                   1.3.10                               PSR HTTP Message implementations
zendframework/zend-escaper                     2.5.2
zendframework/zend-eventmanager                3.1.0                                Trigger and listen to events within a PHP application
zendframework/zend-expressive                  dev-feature/stratigility-2.0 580351c PSR-7 Middleware Microframework based on Stratigility
zendframework/zend-expressive-helpers          3.0.1                                Helper/Utility classes for Expressive
zendframework/zend-expressive-router           2.1.0                                Router subcomponent for Expressive
zendframework/zend-expressive-template         1.0.4                                Template subcomponent for Expressive
zendframework/zend-expressive-zendrouter       2.0.0                                zend-mvc router support for Expressive
zendframework/zend-expressive-zendviewrenderer 1.2.1                                zend-view PhpRenderer integration for Expressive
zendframework/zend-http                        2.6.0                                provides an easy interface for performing Hyper-Text Transfer Protocol (HTTP) requests
zendframework/zend-loader                      2.5.1
zendframework/zend-psr7bridge                  0.2.2                                PSR-7 <-> Zend\Http bridge
zendframework/zend-router                      3.0.2
zendframework/zend-servicemanager              3.2.0
zendframework/zend-stdlib                      3.1.0
zendframework/zend-stratigility                2.0.1                                Middleware for PHP
zendframework/zend-uri                         2.5.2                                a component that aids in manipulating and validating » Uniform Resource Identifiers (URIs)
zendframework/zend-validator                   2.8.2                                provides a set of commonly needed validators
zendframework/zend-view                        2.8.1                                provides a system of helpers, output filters, and variable escaping

@samsonasik I've just done the following:

First, I created a packages.json with the following contents:
{
    "packages": {
        "zendframework/zend-expressive-skeleton": {
            "1.1.0": {
                "name": "zendframework/zend-expressive-skeleton",
                "version": "1.1.0",
                "source": {
                    "type": "git",
                    "url": "https://github.com/weierophinney/zend-expressive-skeleton.git",
                    "reference": "feature/stratigility-2.0"
                }
            }
        }
    }
}

Next, I invoked the following:
$ composer create-project --repository packages.json zendframework/zend-expressive-skeleton zend-expressive-skeleton-129 1.1.0

During installation, I told it to:

Use the "Flat" installation (default)
Use zend-servicemanager (default)
Use zend-router (non-default, but what you appear to have selected)
Use zend-view (non-default; again, your selection)
Use whoops (you did not indicate your preference for errors)
Install zend-validator to config/config.php, as well as any other packages of that type

Ran composer serve from the newly created directory.

I did all of these commands using PHP 7.1.0.
I then visited http://localhost:8080, and the home page came up fine, as did /api/ping.
I noticed a few differences between my installation and yours, but only around PHPUnit and its dependencies; all others were the same.
As such, I cannot reproduce at this time.

@samsonasik I have trying to reproduce it but it's working over here. Are you sure you created a propject from the installer located at: https://github.com/weierophinney/zend-expressive-skeleton/tree/feature/stratigility-2.0?
To test it I locally checkout that branch from weierophinney/zend-expressive-skeleton and after that I use this: https://gist.github.com/xtreamwayz/7590e55f95e98daf8d930b64cd8e4b69

@xtreamwayz Thanks for the review; incorporated all feedback at this time.

@weierophinney thank you. I confirm that it works. It seems I was using default composer create-project which read form dev-master.

Just thinking out loud:
Can we change in test/ExpressiveInstallerTest/ProjectSandboxTrait.php
        // Import programmatic/declarative middleware pipeline and routing configuration statements
        $app->pipe(ErrorHandler::class);
        $app->pipe(ServerUrlMiddleware::class);
        $app->pipeRoutingMiddleware();
        $app->pipe(ImplicitHeadMiddleware::class);
        $app->pipe(ImplicitOptionsMiddleware::class);
        $app->pipe(UrlHelperMiddleware::class);
        $app->pipeDispatchMiddleware();
        $app->pipe(NotFoundHandler::class);

        if ($setupRoutes === true && $container->has(HomePageAction::class)) {
            $app->get('/', HomePageAction::class, 'home');
        }

        if ($setupRoutes === true && $container->has(PingAction::class)) {
            $app->get('/api/ping', PingAction::class, 'api.ping');
        }

with
        // Import programmatic/declarative middleware pipeline and routing configuration statements
        require 'config/pipeline.php';
        if (file_exists('config/routes.php')) {
            require 'config/routes.php';
        }

Also the signature can be changed from getAppResponse($path = '/', $setupRoutes = true) to getAppResponse($path = '/'). It will setup routes if the file exists and if it actually contains any routes.
It seems to work in a local project and it makes sure all the latest changes to piped middleware and routes config files are tested.

@weierophinney
I used your steps to install the new skeleton from this comment:
https://github.com/zendframework/zend-expressive-skeleton/pull/129#issuecomment-276458486
I discussed the new structure of the skeleton with some guys who want to start with Zend\Expressive and are waiting for the new modular structure. The flat structure is no option for them. Here are some ideas for improvement from yesterdays discussion:

Why is the /src/ directory called src at all? It contains classes and templates and the configuration for this module. We expected a /module/ or /modules/ directory instead.

Why is some of the configuration for the App module still placed in /config/autoload/? For example, the dependencies configuration for the two action middleware PingAction and HomePageAction is still placed in /config/autoload/routes.global.php and should be deleted since it is already defined in the App/ConfigProvider. It is also confusing that some of the layout config is in the /config/autoload/templates.global.php while the rest is in the App/ConfigProvider class. Please put it in one place only.

If the dependencies configuration for the two action middleware PingAction and HomePageAction  is removed from the /config/autoload/routes.global.php file then the RouterInterface::class configuration could be moved to the /config/autoload/dependencies.global.php file and the /config/autoload/routes.global.php file could be deleted altogether, couldn't it? Same for the /config/autoload/templates.global.php when the templates config is moved to the App\ConfigProvider class. Less config file makes it easier for beginners to adopt Zend\Expressive.

I find it really confusing that the /config/development.config.php file is overwriting stuff from the /config/autoload/zend-expressive.global.php file. I understand that you need it to make the development mode stuff working. But it is still very confusing that I need to switch between the directory structure to understand the current setting for the caching for example. These settings should either been placed in the /config/ path or in the /config/autoload/ path but not in two different paths.

Currently the routes definitions are placed in the /config/routes.php file. The structure contains only the App module yet, but think about adding more modules. Users will feel to be forced by the structure to add their routes the /config/routes.php file. This is destroying the idea of a modular structure. If I have a User module I would expect the routing configuration somewhere in the /module/User/ path. I know that it is quite hard to build a sensible structure if you want to add the routes programmatically. I love the programmatic addition of the routes but currently this structure needs a little bit of improvement. What about a new method to the App/ConfigProvider class which takes the Zend\Expressive\Application instance as an parameter? Or what about a App/RoutesProvider class?  The /config/routes.php should be refactored then to add all these RoutesProvider classes or ConfigProvider::addRoutes() methods.

I think the programmatic middleware pipeline is a great step to reduce the complexity of multi-level config files. But I don't like the approach in the /public/index.php file to first grab the Zend\Expressive\Application instance from the DI container and then requiring the config/pipeline.php and config/routes.php files which amend the application instance inline. It really looks weird and confusing in the /public/index.php file. Why not doing some stuff like $app = require 'config/application.php'; similar to the configuration of the DI container? We still have the problem how to add the middleware pipeline and the routes programmatically but now it is hidden from such a high level. Inline requiring to add stuff to an existing object feels a bit messy. Another Idea: couldn't we use some custom delegator factories to add stuff like middleware pipeline and routes to the Zend\Expressive\Application instance? Then the /public/index.php could look like this again:

/** @var \Interop\Container\ContainerInterface $container */
$container = require 'config/container.php';

/** @var \Zend\Expressive\Application $app */
$app = $container->get(\Zend\Expressive\Application::class);
$app->run();

Regarding the composer.json file. Why not changing the requirements for Zend\ServiceManager and Zend\Stdlib to its 3.x versions? Is there a sceanario where the 2.x versions are needed? If we force the Zend\ServiceManager 3.x versions the configuration can be simplified by removing the invokables to teach beginners the new way of  Zend\ServiceManager 3.x version.

Ok, this was a longer comment that I thought. Please don't get me wrong. Maybe I am totally on the wrong track. But I think you are doing a great job with Zend\Expressive 2.x. Though I think to support the adoption rate for beginners we really need to improve the modular structure of the skeleton. This will lead beginners in the right direction. With the current state most modular Zend\Expressive applications will become a mess in a short time. If the skeleton of the new Zend\Expressive 2.x will be creating the current state of the application structure this will be the base for a lot of applications. People need some guidance when it comes to structure.
Feedback and comments are really appreciated.

@xtreamwayz —

Can we change in test/ExpressiveInstallerTest/ProjectSandboxTrait.php

I just tried this, modifying the code to use the configured $projectRoot when including the files, and got a ton of test failures and errors. As such, I don't think it's quite safe.
If you can figure out a way to make it work, feel free to send a PR against my branch.

I've updated the code to use the develop branch of Expressive at this time, and removed the repositories setting that was pointing to my own development branch.
I had to make the following changes:

Configure the DefaultDelegate and NotFoundDelegate in the dependencies.
Add support for aliases to the Pimple and Aura configuration.
Decided to add delegator factory support for Aura as well, which requires the installer to copy over a couple additional classes to the config/ tree.
Update tests that execute the application to pass the default delegate when invoking the application.

Errors are currently being reported for the ContainerTest when used with Aura.Di under PHP 5.6 and when using the lowest dependencies; I'll investigate that in the coming days.
@RalfEggert Thank you for the detailed feedback! I'll start addressing it early next week.

@RalfEggert:

Why is the /src/ directory called src at all? It contains classes and templates and the configuration for this module. We expected a /module/ or /modules/ directory instead.

Because it contains your source code. That allows it to be purposed in such as way as to contain both modules and library code, without requiring those be in separate trees of the project.
Since a module in Expressive is simply a tree that is under a common namespace that contains a ConfigProvider class, there's nothing else special about it at all. It's just source code for your application.

Why is some of the configuration for the App module still placed in /config/autoload/? For example, the dependencies configuration for the two action middleware PingAction and HomePageAction is still placed in /config/autoload/routes.global.php and should be deleted since it is already defined in the App/ConfigProvider.

Good catch! I'll fix that!

It is also confusing that some of the layout config is in the /config/autoload/templates.global.php while the rest is in the App/ConfigProvider class. Please put it in one place only.

I've just reviewed, and I'm not sure I agree with your assessment.
The ConfigProvider for the App module only defines template paths for templates it provides. The config/autoload/templates.global.php file, on the other hand, provides configuration for the chosen template renderer, and application-level configuration — which can include things like a choice of layout (this is only true currently of zend-view; the other template renderers choose the layout within the templates). As such, I think everything is currently in the correct location.

If the dependencies configuration for the two action middleware PingAction and HomePageAction is removed from the /config/autoload/routes.global.php file then the RouterInterface::class configuration could be moved to the /config/autoload/dependencies.global.php file and the /config/autoload/routes.global.php file could be deleted altogether, couldn't it? Same for the /config/autoload/templates.global.php when the templates config is moved to the App\ConfigProvider class. Less config file makes it easier for beginners to adopt Zend\Expressive.

I agree with moving the router configuration to the dependencies.global.php file. However, as noted above, the templates.global.php file contains application-level configuration, which should not be in a module, and I plan to retain it.

I find it really confusing that the /config/development.config.php file is overwriting stuff from the /config/autoload/zend-expressive.global.php file. I understand that you need it to make the development mode stuff working. But it is still very confusing that I need to switch between the directory structure to understand the current setting for the caching for example. These settings should either been placed in the /config/ path or in the /config/autoload/ path but not in two different paths.

We have a bit of a chicken-and-egg problem here.
zf-development-mode will do the following when enabling:

copy config/development.config.php.dist to config/development.config.php.
copy config/autoload/development.local.php.dist to config/autoload/development.local.php if it exists.

The problem is that the first file is required; if it does not exist, zf-development-mode will not do anything. So we cannot just remove it.
This is due to its original purpose: enabling development mode in zend-mvc applications, where the development config may also enable additional modules, which need to be enabled first, as configuration is a two-step process (aggregate all module configuration, then aggregate autoloadable, application-level configuration).
With Expressive, configuration is flat. This means that the two files are roughly equivalent, with one caveat; the configuration from config/development.config.php will have precedence over all other settings, as it is merged last; this helps ensure that things like config caching (not general application caching!) and debug mode are enabled.
As such, my thought is this:

We recommend using config/autoload/development.local.php.dist for the majority of development mode settings, which might include things like overrides for caching, logging, databases, etc.
We ship config/development.config.php.dist with only settings for enabling debug mode and disabling config caching, and recommend making no further changes to that file, and note that it exists to allow enabling development mode.

From what I can tell, that would likely address your primary concerns; thoughts?

Currently the routes definitions are placed in the /config/routes.php file. The structure contains only the App module yet, but think about adding more modules. Users will feel to be forced by the structure to add their routes the /config/routes.php file. This is destroying the idea of a modular structure. If I have a User module I would expect the routing configuration somewhere in the /module/User/ path. I know that it is quite hard to build a sensible structure if you want to add the routes programmatically. I love the programmatic addition of the routes but currently this structure needs a little bit of improvement. What about a new method to the App/ConfigProvider class which takes the Zend\Expressive\Application instance as an parameter? Or what about a App/RoutesProvider class? The /config/routes.php should be refactored then to add all these RoutesProvider classes or ConfigProvider::addRoutes() methods.

This was something we debated quite a bit before implementing the current solution. Our primary issues with having modules supply routing information come down to usage with third-party modules:

route strings and options are specific to routing implementations, which makes compatibility a problem.
there is a potential for routing conflicts.
the routes from a third-party module may not reflect what you actually want to use in your own application.

As such, we felt that not having the ability to configure routes was actually a benefit to programmatic applications, as it solves these problems.
The issue, of course, is that you end up with a potential for a lot of copy-and-paste, which can lead to issues when upgrading a module.
Our recommendation thus became: use delegator factories on the Application instance.
Part of this pull request is ensuring that delegator factories are supported across each of the supported container implementations. We'd previously supported them on zend-servicemanager (obviously!), as well as Pimple; we now can support them for Aura.Di as well, making this a viable recommendation.
That said, there's a caveat: while internal modules can register them by default, third-party, distributed modules should not, for the reasons stated above: conflicts, compatibility, and application specificity. If the routes suggested satisfy your criteria, you could then register the delegator factory without issue; if they do not, you can manage the routes manually within your application.
So, as an example: I could create a distributable module named phly/social-auth that has some default routing. I'd create a delegator factory for Zend\Expressive\Application that would register them:
namespace Mwop\SocialAuth;

use Interop\Container\ContainerInterface;
use Zend\Expressive\Application;
use Zend\Expressive\Router\AuraRouter;
use Zend\Expressive\Router\FastRouteRouter;
use Zend\Expressive\Router\ZendRouter;
use Zend\Expressive\Router\RouterInterface;

class SocialAuthApplicationDelegatorFactory
{
    public function __invoke(ContainerInterface $container, $serviceName, callable $callback)
    {
        /** @var Application */
        $application = $callback();

        // Add routes.
        $router = $container->get(RouterInterface::class);

        switch (true) {
            case ($router instanceof AuraRouter):
                $this->injectAuraRoutes($application);
                break;
            case ($router instanceof FastRouteRouter):
                $this->injectFastRouteRoutes($application);
                break;
            case ($router instanceof ZendRouter):
                $this->injectZendRouterRoutes($application);
                break;
            default:
                // Unknown router type; do nothing
                return $application;
        }

        // Return the configured application:
        return $application;
    }
}

I would then inform users that they need to enable this delegator factory within their application, but would not do so by default.
However, if this were a module developed directly in my application, I'd likely:

skip the bits where I check the router type, and just register routes directly, using the routing syntax for the router I've chosen for my application.
register the delegator factory within my module's ConfigProvider.

Which solves the issues you present: you can keep the routes close to your modules, and have them auto-registered without needing to update the config/routes.php file at all.
Make sense?

I think the programmatic middleware pipeline is a great step to reduce the complexity of multi-level config files. But I don't like the approach in the /public/index.php file to first grab the Zend\Expressive\Application instance from the DI container and then requiring the config/pipeline.php and config/routes.php files which amend the application instance inline. It really looks weird and confusing in the /public/index.php file. Why not doing some stuff like $app = require 'config/application.php'; similar to the configuration of the DI container? We still have the problem how to add the middleware pipeline and the routes programmatically but now it is hidden from such a high level. Inline requiring to add stuff to an existing object feels a bit messy. Another Idea: couldn't we use some custom delegator factories to add stuff like middleware pipeline and routes to the Zend\Expressive\Application instance? Then the /public/index.php could look like this again:
/** @var \Interop\Container\ContainerInterface $container */
$container = require 'config/container.php';

/** @var \Zend\Expressive\Application $app */
$app = $container->get(\Zend\Expressive\Application::class);
$app->run();

As noted above, you can also use delegator factories with the approach we've provided; as such, if you want, you could remove those require statements from your public/index.php file entirely.
The reason we're using the current approach is because it's far easier to get started by saying "Open the file config/routes.php and add [. . .]" than it is to say "Create a file src/Foo/src/Factory/Routes.php and create the class Foo\Factory\Routes with the following contents [. . .]; now update the file config/autoload/dependencies.global.php and add the following [. . .]". On top of being more work, it also requires explaining additional concepts such as delegator factories, modules, etc.
In regards to using something like require 'config/application.php';, you end up with the same problem: how is the pipeline created, and how are routes registered? And you either end up with required files, such as we're currently doing, or more advanced concepts such as delegator factories.
One goal for Expressive is to have not only an enterprise-level middleware microframework, but something approachable. As such, we feel the require approach fulfils the latter goal better.

Regarding the composer.json file. Why not changing the requirements for Zend\ServiceManager and Zend\Stdlib to its 3.x versions? Is there a sceanario where the 2.x versions are needed? If we force the Zend\ServiceManager 3.x versions the configuration can be simplified by removing the invokables to teach beginners the new way of Zend\ServiceManager 3.x version.

Good point about updating those dependencies; I'll do so shortly!
That said, we'll still support invokables configuration, for one reason: cross-container compability. While zend-servicemanager offers the InvokableFactory, which largely removes the need for invokables, we do not want to make zend-servicemanager a dependency when other container types are used! (Interestingly, zend-servicemanager, when provided with invokables configuration, simply sets up a factory mapping pointing to an InvokableFactory instance; if the service name and class name do not match, it also creates an alias.)
Thanks for the great feedback!

I agree with moving the router configuration to the dependencies.global.php file.

Actually, this is not as easy as it looks.
Currently, the config/autoload/dependencies.global.php file is static; the information it contains will work for any of the various container, router, or template renderer options. The installer does not touch this file; all it does is move additional files into that tree, based on the capabilities selected.
As updating a file in situ is more problematic both in terms of accomplishing as well as testing, I'll leave the file in place, minus the middleware dependency registration.

@weierophinney
Thanks for your reply. I will pick up some of the points if I have something to add.

Because it contains your source code. That allows it to be purposed in such as way as to contain both modules and library code, without requiring those be in separate trees of the project.

Ok, that sounds reasonable. However having a path /src/App/src/Action/ still looks a little unusal. If it only contains source code why do we need to have another /src subfolder then? I guess it is needed since we have source code and templates within it. Beginners will definitely trip over this and wonder why it is done like this. So I still would prefer /module/ or something similar.

this is only true currently of zend-view; the other template renderers choose the layout within the templates

I think this is the problem with some of the other issues I mentioned. The files in the skeleton are the result of the open concept to support different renderers, routers and DI containers. The file setup makes sense from the point of view of the installer. But people who want to start their project after the installation are really confused about the config data in different places. After we setup the Expressive app last week the first thing we did was tidy up the configuration. From the development point of view it doesn't make sense to have some template configuration in the /config/autoload/ folder and some in the App\ConfigProvider class.
The same applies to the router config you mentioned in the follow up comment.

We have a bit of a chicken-and-egg problem here.

Ok, I understand the problem but maybe we can have a solution that is less confusing. Could the /config/development.config.php be made static and just add another Zend\ConfigAggregator\PhpFileProvider instance to add the config/autoload/{{,*.}development}.php config files? Then all development config stuff can be placed in the /config/autoload/ folder?
Anyway we still have another problem, I guess. If we leave it like it is or use this approach, the development configuration will overwrite the local configuration, won't it? In my MVC projects I always used the levels global -> development -> local, so local can overwrite development configuration.

Our recommendation thus became: use delegator factories on the Application instance.

Yeah, this sounds great. And since I saw that you have already written some docs about it I guess this is a proper solution. Maybe in the files created by the installer itself we could add a link to the docs?
The same applies for the middleware pipeline.
Thanks again for you thoughts and your reply. I really think we should make it easier for beginners to understand the Zend\Expressive way of building applications and make them comfortable from them start. In general, every config file that we don't need is a good config file. If this makes the installer more complicated I really think it is worth it.

Ok, that sounds reasonable. However having a path /src/App/src/Action/ still looks a little unusal.

I don't like it either, but it's copied from zend-mvc. I would prefer something like src\MyModule\Action and place all resources like the templates in src\MyModule\Resources\views and src\MyModule\Resources\public.
 You don't need to use the default structure. I don't think there can be a 100% satisfying solution for everyone.

I think this is the problem with some of the other issues I mentioned. The files in the skeleton are the result of the open concept to support different renderers, routers and DI containers. The file setup makes sense from the point of view of the installer. But people who want to start their project after the installation are really confused about the config data in different places. After we setup the Expressive app last week the first thing we did was tidy up the configuration. From the development point of view it doesn't make sense to have some template configuration in the /config/autoload/ folder and some in the App\ConfigProvider class.
The same applies to the router config you mentioned in the follow up comment.

Those files are the left overs from moving the config to the ConfigProvider class. Those left over dependencies are there for a reason: Simplicity.
There are 3 ways to make the installer work:

Collect the entire configuration and dynamically generate all the php files and classes. This would be the nicest solution, however it require to include something like zend-code. Since the installer is executed before anything else and before composer installs any dependencies, zend-code or anything like it can't be used and thus all relevant functionality needs to be copied to the installer and maintained there as well. Unless someone knows an easy to maintain lightweight class to generate PHP code... It would make the installer easier to extend and configure.

Make different versions of config\autoload\dependencies.global.php. This might be an option as well but it means you need to make a different file for all possible combinations. That's too hard to maintain and it gets even worse if other packages are added in the future.

Leave it as it is and keep it simple. For those that don't like it, they can merge the config files and move files around. The installer would still be helpful since it really gets you started within a minute and does all the wiring for you.

Arguably you don't really need the ConfigProvider class if you use the flat structure.

Maybe in the files created by the installer itself we could add a link to the docs?

Good idea.

@RalfEggert —

Beginners will definitely trip over this and wonder why it is done like this. So I still would prefer /module/ or something similar.

When I look at other frameworks, this is what I see:

Laravel has two concepts: the application source code, which goes under app/; and packages, which are similar to ZF modules, and go under a packages/ directory.
Symfony has bundles; these go under the src/ tree, just like any other source code.
Slim puts everything under src/ including non-OOP code, but does not have a concept of modules or packages.
ZF has a module/ directory, because all source code goes in modules.

I'd argue that if a src/ tree that combines bundles and regular source code is okay for Symfony, we can do the same here. If end-users want to structure differently, of course they can; we do not dictate where code goes, we simply provide a default location so you have something to work with immediately.

But people who want to start their project after the installation are really confused about the config data in different places. After we setup the Expressive app last week the first thing we did was tidy up the configuration.

Who is "really confused"? I'm not seeing a lot of chatter on the issue tracker about confusion, to be honest, so if you are seeing this, I'd love to see some links so I can investigate further.
I think the different files made more sense when we were doing more in them. The middleware-pipeline.global.php had both dependencies for the various middleware in the pipeline, as well as configuration for it; the routes.global.php file had dependency configuration for routed middleware, as well as configuration for the routes itself.
I feel templates.global.php still works in this regard; it has dependency configuration for the renderer being used, as well as configuration specific to that template renderer. (More on this below.)
But I think having multiple files fills another niche: it helps demonstrate that you don't have to put all configuration in a single file, but can separate it by semantic needs. This is great for maintainability and understanding how various pieces interact — and with configuration caching enabled by default in production, there's no expensive overhead.

From the development point of view it doesn't make sense to have some template configuration in the /config/autoload/ folder and some in the App\ConfigProvider class.

Again, there is no template configuration in the config/autoload/templates.global.php file. It contains only dependency configuration, and configuration options for the specified template renderer: what extension to look for, information on caching, assets, extensions, and, yes, in the case of zend-view, the default layout to use (as it's the only renderer that doesn't specify the layout directly in the template).

(something about autoloading development files using the aggregator)

You can, of course, do that in your own project. However, the idea around zf-development-mode is to allow you to quickly and easily switch in and out of a set of specific development configurations, specified in two specific files. If you have a PhpFileProvider aggregating anything with a .development.php extension always, you then have to manually manage those files (i.e., copying them from .dist files to non-.dist files, etc.). It's out-of-scope.

the development configuration will overwrite the local configuration, won't it?

Depends!
If you do not alter config/development.config.php.dist, then that only overrides the configuration caching and debug settings. Any other overrides will be in config/autoload/development.config.php.dist — and you can have another .local.php file override those settings by having it named such that it will glob later. As an example, zzz.local.php will autoload later.

Maybe in the files created by the installer itself we could add a link to the docs?

Sure!

@xtreamwayz —

I would prefer something like src\MyModule\Action and place all resources like the templates in src\MyModule\Resources\views and src\MyModule\Resources\public.

I've never been a fan of mixing non-PHP code in the same tree as the PHP code itself, which is why ZF modules have a src/ directory, and then peer directories for configuration, views, etc.
That said, I see that Symfony bundles do exactly this, so I have no argument there. Would you care to send a PR against my branch to enable this?

@xtreamwayz

I don't like it either, but it's copied from zend-mvc.

Well, I think it is not. Zend\Mvc uses a /module/Application/ path with src/, view/ and config/ in it. It doesn't use /src/Application/.
https://github.com/zendframework/ZendSkeletonApplication/tree/master/module/Application

Leave it as it is and keep it simple. For those that don't like it, they can merge the config files and move files around. The installer would still be helpful since it really gets you started within a minute and does all the wiring for you.

I understand your points. Ok, then we definitely need a recipe what users can do to simplify the config files after installation. I am willing to write this recipe when everything is settled and I find the time.

@weierophinney

When I look at other frameworks, this is what I see

The reason why I like the Zend Framework (1 to 3) since the beginning is its clear structure. With all the other frameworks you mentioned I always had some problems to find my way around. Maybe I am getting old and becoming a creature of habits. I never understood the separation of app and src in Symfony both having source code and templates in it. And maybe I am just used to the Zend\Mvc way of structuring its models with Zend\ModuleManager. If a /src folder with both source code, config and templates is the way to go, I will start to live with it. At least I know how to change the structure. ;-)

Who is "really confused"? I'm not seeing a lot of chatter on the issue tracker about confusion, to be honest, so if you are seeing this, I'd love to see some links so I can investigate further.

Well, I moderated two ZF3 and Zend\Expressive workshops in the last weeks. In both of these workshops it took me a long time to explain the structure of the config files as it is. In both of these workshops the first things we did was some reorganizing. So there will be no links I can present. It is just some feedback from experience I personally made.
And don't get me wrong. I am not against multiple files for different aspects of configurations.

@weierophinney

That said, I see that Symfony bundles do exactly this, so I have no argument there. Would you care to send a PR against my branch to enable this?

It doesn't make sense to do that. If you change the module structure /src/App/src/Action to /src/App/Action, you would have the flat structure.
That's why I proposed somewhere to use /src/Action as the flat structure.
@RalfEggert

I understand your points. Ok, then we definitely need a recipe what users can do to simplify the config files after installation. I am willing to write this recipe when everything is settled and I find the time.

I don't think you need to write a recipe for this. It's more a personal taste on how to fine tune your application. I've seen several structures already and one has all local and global files grouped in different directories. You could even argue to split the dependencies.global.php file in smaller files to group dependencies. It might be easier in larger applications.

Well, I think it is not. Zend\Mvc uses a /module/Application/ path with src/, view/ and config/ in it. It doesn't use /src/Application/.

Actually, I thought you tripped over the two times src in the module structure. That's why I came up with a Symfony like approach to get rid of the second one. I still think that source code belongs in /src rather than in /module. But again, this my personal preference and this skeleton can't please everyone.

@xtreamwayz

But again, this my personal preference and this skeleton can't please everyone.

Yep, I think that is a good final summary. I will try to start to refrain from pushing my personal preferences from the skeleton.
 I hope I bought in some points to think about in this discussion though.

I think whole structure should be the same as in ZF3. Beginners have an opinion and simply adapts to the proposed structure. For more advanced programmers it just simplifies using modules between these 2 frameworks. I have just finished quick project on Expressive and it was very convenient to copy finished modules from ZF3 with some quick adaptation. My structure is:
/module/namespace/config[/module.config.php|someotherconfig.php]
|-.../src[/Action|Entity|Form|Hydrator|...]
|-.../view

Template path inside module config is set to ./view within namespace.
More confusing, after reading 1.1 changelog, was - why do I have to use programatic pipeline when everything was set in config files earlier.

@xorock —

More confusing, after reading 1.1 changelog, was - why do I have to use programatic pipeline when everything was set in config files earlier.

Because we have found through teaching and support that the developers find the programmatic pipeline and routing to be easier to understand and easier to create than the configuration files. We originally used configuration because of our background with zend-mvc, but there was a disconnect when applying it to middleware applications.

Docs for Expressive are the weakest point, and valuable insights are mostly here on github. If You do not track issues then docs are not a good place to start.

If you feel the documentation should be improved, please submit issues or pull requests against the zend-expressive repository with your suggestions.

I hope I bought in some points to think about in this discussion though.

You absolutely did! Thanks for collaborating!


Only build master branch.

This change is

Previously, richard1122 (richard) wrote…
> #### Only build master branch\.

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Implement the /policies and /policy_groups API routes

There's some refactoring that's possible, but this is ready for review.
(Fails with FILE_STORE=true.)

Ah, yes, this fails with FILE_STORE=true still.

:+1:

LGTM, just remember to address # XXX remove :data_store_exceptions before final merge.


Show ESLint errors

This is a workaround because webpack-command's formatter doesn't format ESLint & Stylelint well. Similar to https://github.com/webpack-contrib/webpack-stylish/issues/22

Love it!


Local server not receiving any request on identity handler or execute handler

I have setup everything right according to the readme. And initially i got one or 2 requests in the identifyhandler in which i threw error. But now no matter what i do, i am not seeing any request coming to the local server. Even though google home is loading the local server web page.
Should i do something else ? or this is a bug with google home itself ?
Also this is my response in the sync request -
{
    "requestId": "12942802761996814011",
    "payload": {
        "agentUserId": "1234",
        "devices": [
            {
                "id": "1xj9",
                "type": "action.devices.types.SWITCH",
                "traits": [
                    "action.devices.traits.OnOff"
                ],
                "name": {
                    "defaultNames": [
                        "Smart Switch"
                    ],
                    "name": "Smart Switch",
                    "nicknames": [
                        "smart switch"
                    ]
                },
                "deviceInfo": {
                    "manufacturer": "L",
                    "model": "L",
                    "hwVersion": "1.0.0",
                    "swVersion": "2.0.0"
                },
                "willReportState": true,
                "otherDeviceIds": [
                    {
                        "deviceId": "5678"
                    }
                ]
            },
            {
                "id": "22bn",
                "type": "action.devices.types.OUTLET",
                "traits": [
                    "action.devices.traits.OnOff"
                ],
                "name": {
                    "defaultNames": [
                        "Smart Outlet"
                    ],
                    "name": "Smart Outlet",
                    "nicknames": [
                        "smart plug"
                    ]
                },
                "deviceInfo": {
                    "manufacturer": "L",
                    "model": "L",
                    "hwVersion": "1.0.0",
                    "swVersion": "2.0.0"
                },
                "willReportState": true,
                "otherDeviceIds": [
                    {
                        "deviceId": "1234"
                    }
                ]
            }
        ]
    }
}

What discovery method do you use in your scan configuration? If you are using UDP discovery, do your local devices see the periodic UDP broadcast from the Home device?

I wanted to make an example using mdns discovery and contribute.
I setup mdns discovery in actions console.

And i started advertising on mdns also using an esp8266.
I noticed now, that identify request is not triggered unless i change the wifi network name itself.
When i changed the wifi name, it again triggered once. After that its NOT calling it again whenever i ask for sync my devices or unlink/link my account or if i restart the google home.

I got it, i re read the documentation, it says The IDENTIFY handler will be triggered when the Google Home or Google Nest device reboots and sees unverified devices.
I have one more doubt regarding mdns.
I tried using mdns in app.ts for fetching info from local devices, but it fails to compile when i am using mdns or mdns-js. (I guess, maybe they are not meant to run on browser ? and only in NodeJs ?)
Will it be right approach for supporting devices based on mdns ? or i am headed in wrong direction. @devunwired  Will be glad if you know something and you can point me in right direction.

Correct, the IDENTIFY handler is only called until you have successfully identified the device that was discovered on the local network.

I tried using mdns in app.ts for fetching info from local devices, but it fails to compile when i am using mdns or mdns-js.

Depending on what you are trying to accomplish, this probably isn't the right approach. The compilation issue is probably because you need to use a tool like Webpack to compile using a library built for Node.js so it can run within the Chrome environment.
However, since the discovery process handles all the mDNS discovery (and provides you the results in the mdnsScanData), you shouldn't need to use an mDNS library directly to get any of the data broadcast by the device. The TXT record data will all be present in the additionals property of the scan data provided to your IDENTIFY handler.
Once the device has been discovered and identified, use the DataFlow component of the SDK to communicate with it using TCP/UDP/HTTP.
Side Note: I would recommend asking these more general development questions on StackOverflow using the google-smart-home tag so they get more visibility.


when will the 2.1.3 of windows version be released, the current version is 2.1.1, only the linux and mac has the 2.1.3 version for this moment?

when will the 2.1.3 of windows version be released, the current version is 2.1.1, only the linux and mac has the 2.1.3 version for this moment?

Any plan beyond 2.1.1 is currently abandoned, see #15344 for more details.


Seeing if I can run e2e

A test - please ignore.

/azp run ci, e2e

I am hitting the same issue as others where I can't access secrets needed by the pipeline because my PR was opened from a fork. Closing this PR now.


Dose this repo support tracking in video?

@bhack , @KainingYing
Which tracking algorithm do you want?  Have you looked at the Torchyolo library? I added the tracker library for Yolo models.
https://github.com/kadirnar/torchyolo
My Tracker Repos:
https://github.com/kadirnar/Norfair-Track
https://github.com/kadirnar/ocsort-pip
https://github.com/kadirnar/bytetrack-pip
https://github.com/kadirnar/strongsort-pip
https://github.com/kadirnar/sort-pip

I added the SAHI algorithm for small object detection.
https://github.com/kadirnar/segment-anything-video#sahi--segment-anything

These tracking algorithm are good but I don't think that these are mask tracking.
See the the upstream ticket datasets related leaderboards.

thanks

@kadirnar With you algos you can reproduce something like: https://github.com/yahooo-mds/OSTrack_SAM
But it will not have the quality and temporal consistency as using the embedding with VOS specific networks like the ones performing in the mentioned datasets.

https://github.com/kadirnar/segment-anything-video/issues/6#issuecomment-1505328823

https://github.com/gaomingqi/Track-Anything

Dear @kadirnar, you've linked the Track Anything repository in your comment above, which interestingly has the exact metaseg demo in their repo (demo.py). To clarify: (1) Does metaseg support tracking of segmentation masks through videos? (2) Is there a link between metaseg and Track Anything?

The Metaseg library does not have a tracker feature. You can view the feature list here:
https://github.com/kadirnar/segment-anything-video#extra-features
The Track-Anything repo used to use the metaseg library but no longer does.


how to merge trace file collected from different socs

Stated in title, trace file is collected from different socs, how to merge them together into same timeline?

There is no supported way of merging two traces.
On Thu, Sep 21, 2023 at 10:33 AM hanbu111 @.***> wrote:

Stated in title, trace file is collected from different socs, how to merge
them together into same timeline?
—
Reply to this email directly, view it on GitHub
https://github.com/google/perfetto/issues/594, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZ3CHTUQHAGT4PQYDM56PNTX3QCWDANCNFSM6AAAAAA5BHOB6Y
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

You might also want to consider the third-party tool vperfetto (https://github.com/741g/vperfetto) which can be used to merge traces but it is not supported by the Perfetto team. We do not have any tools on our side to do trace merging as Anna said.


Resource storage URL auto-mapping

If you request a resource to the server's URL it should match automatically to the stored file, where ever it may be.
clarification needed

@sadok-f I'm not very clear in how this should work. Could you write a quick speck here?


Issue-animate location of percent text on update

Automated Review Comments
Issues in src/components/Bar.js:

(8, 'Hardcoded string found')
(9, 'Hardcoded string found')
(10, 'Hardcoded string found')
(13, 'Line exceeds 80 characters')
(19, 'Line exceeds 80 characters')
(20, 'Line exceeds 80 characters')
(24, 'Hardcoded string found')
(25, 'Line exceeds 80 characters')
(30, 'Hardcoded string found')
(33, 'Hardcoded string found')
(34, 'Hardcoded string found')
(35, 'Hardcoded string found')
(36, 'Hardcoded string found')
(41, 'Hardcoded string found')
(42, 'Hardcoded string found')
(43, 'Hardcoded string found')
(44, 'Hardcoded string found')
(46, 'Line exceeds 80 characters')
(50, 'Hardcoded string found')
(52, 'Hardcoded string found')
(53, 'Hardcoded string found')
(54, 'Hardcoded string found')
(62, 'Hardcoded string found')
(64, 'Hardcoded string found')
(65, 'Hardcoded string found')

I got it.


Use POCL-CUDA instead of POCL

Fixes https://github.com/illinois-ceesd/mirgecom/issues/50

Ready for review.


Unable to download the Playlist.

youtube-dl https://www.youtube.com/playlist?list=PLjP-FzwmAXChcbQ1t0weZpcNcdoXaxfZD
[youtube:playlist] PLjP-FzwmAXChcbQ1t0weZpcNcdoXaxfZD: Downloading webpage
ERROR: Unable to extract title; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

You are using an outdated version of youtube-dl. Read our FAQ if you have troubles updating.

Thank you. I am using Ubuntu 15.10 and below code worked well for me.
sudo pip install -U youtube-dl
Thank you for your help.


Any date for the v2.70.0 port ?

I like to skip the 2.70 - the next version will be the 3.0.0.
The new version will be in sync with HtmlUnit 3.0.0 - see https://www.htmlunit.org/migration.html
It will be great if you can test the lastest snapshot - you need this
<dependency>
    <groupId>org.htmlunit</groupId>
    <artifactId>htmlunit-android</artifactId>
    <version>3.0.0-SNAPSHOT</version>
</dependency>

and this new snapshot repo
<repository>
  <id>OSS Sonatype snapshots</id>
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
  <snapshots>
    <enabled>true</enabled>
    <updatePolicy>always</updatePolicy>
  </snapshots>
  <releases>
    <enabled>false</enabled>
  </releases>
</repository>

Sorry for the long wait - but there was a lot of things to do to make this finally happen.
3.1.0 is out! Enjoy and report your findings.


Pull requests in Issues section

I noticed in the DEV.to repo that pull requests are also being shown in the issues section: https://github.com/thepracticaldev/dev.to/issues/1816
While looking at the Github API docs I noticed that it mentions that pull requests are also being returned in the issues endpoint: https://developer.github.com/v3/issues/

Note: GitHub's REST API v3 considers every pull request an issue, but not every issue is a pull request. For this reason, "Issues" endpoints may return both issues and pull requests in the response. You can identify pull requests by the pull_request key.
Be aware that the id of a pull request returned from "Issues" endpoints will be an issue id. To find out the pull request id, use the "List pull requests" endpoint.

I wasn't sure if this was a bug or maybe for some reason intended behaviour. Anyways if it is a bug this can easily be fixed by adjusting the filter in markdownIssues.js.
I can make a PR with the fix once this gets approved as a bug.

Is this intended behaviour or indeed a bug? I can make a PR for it but would like to know if this is an approved bug.

Well, initially, it was an intended behavior or I can say I was forced to do it because I could not find a way at that time to make a difference.
I will check this PR out and will review it soon.


Item spec rework [WIP]

Related Issue(s): #681
Proposed Changes:

Move the two best practices in item spec to the 'best practices' document
Add rel 'alternate' with type html recommendation to communicate that there is an html version. (can make an issue of this to discuss)

PR Checklist:

[ ] This PR has no breaking changes.
[ ] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
[ ] API only: I have run npm run generate-all to update the generated OpenAPI files.

May want to also add in a bit more of a mention in the item spec that fields should be added for 'search'. We do mention the reason for the item spec is search at the top, but a bit more might be good.

There are also changes in the PR coming from #763 though...

Ah shoot, I'll redo it. My git skills are still not great.
On Mon, Apr 13, 2020, 5:10 AM Matthias Mohr<EMAIL_ADDRESS>wrote:

There are also changes in the PR coming from #763
https://github.com/radiantearth/stac-spec/pull/763 though...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/radiantearth/stac-spec/pull/764#issuecomment-612873058,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADDL2POVDKRRPWW5ZN4A2TRML6KJANCNFSM4MGSNNWA
.


Convert lpc-doc plaintext docs

These have been converted quickly and roughly to a combination of markdown and simple HTML. But this means we're not losing any useful documentation relative to Dworkin's lpc-doc repository. Everything should be viewable via GitHub Pages.
This PR is relative to the branch from another PR, the one that adds the architecture/layers docs. So all the commits except the last one are from that branch.

All unmerged PRs need README conflcts resolved.

Other PRs conflicts resovled, this now has 3 files conflicting.

Yeah. This is the hard part of multiple PRs. I can base each one on the previous one (which sucks to read), or I can base them (as much as possible) all on the current head... Which means a lot of merge conflicts after one gets merged.

Thank you.


add pool totalSupply to add and remove liquidity logs

Add to remove and add liquidity logs the balancer pools total supply. The call is pool.totalSupply()

Is this still needed?

@robert-e-davidson3 I believe this is done


ios: update unary/streaming & add test

Per the discussion here, updating the unary and streaming interfaces.

Moved the non-streaming convenience function into an extension on the protocol type so that it's available to all consumers
Added a test to validate the default behavior of this extension function
Added a CancelableStream protocol which includes a subset of functionality from the StreamEmitter, allowing consumers of the unary function to cancel requests without having the ability to send additional data into the stream

Signed-off-by: Michael Rebello<EMAIL_ADDRESS>

@buildbreaker thanks for the callout - we can do something like CancelEmitter in the future if that makes sense 🤷♂


Deactivate button and routing

Did the deactivation of button and routing, Email not sending. #8

db.session.delete(user) does not seem to work?
user returns the get user id, basically calls the function verify_reset_token


Cyllene Testnet Tracking Issue

This is a tracking issue for the release of the next Penumbra testnet, Cyllene.
Final pre-flight testing: Monday, April 25 in the AM Eastern time
Release and deployment: Monday, April 25 in the PM Eastern time
Please file bugs if you find them and associate them with the Cyllene testnet milestone.
High-level plan:

[x] Pre-release testing throughout this week (week of Apr 18-Apr 22, 2022)
[x] Generate pre-flight test plan (here: https://github.com/penumbra-zone/penumbra/wiki/Testnet-Acceptance-Tests)
[ ] Prepare announcement / high-level description of changes
[ ] Final pre-flight testing on Monday, fixing any bugs found
[ ] Deployment on Monday using the existing droplet

I previously created this PR to include additional allocations for Galileo at genesis: https://github.com/penumbra-zone/penumbra/pull/654

Includes:
https://github.com/penumbra-zone/penumbra/pull/672
https://github.com/penumbra-zone/penumbra/pull/655
https://github.com/penumbra-zone/penumbra/pull/649
https://github.com/penumbra-zone/penumbra/pull/578


Can "Blazor (ASP.NET Core hosted) template" use windows authentication?

Description
I know Blazor client-side can NOT use windows authentication but Blazor side-side can. I wonder could "Blazor (ASP.NET Core hosted) use windows authentication? Even though it's Blazor client-side project, but it still runs on dotnet core back-end.

Thanks for contacting us, @howardgod.
Blazor client-side currently has no support for authentication. We'll look into covering that gap post 3.0 release, as part of #12476

Good day! I decided to try creating a Blazor WebAssembly App project template. Everything was done as it is written here - https://docs.microsoft.com/en-us/aspnet/core/blazor/get-started?view=aspnetcore-3.0&tabs=visual-studio. At Press F5 to run the app a blank page opens with an inscription in the upper left corner Loading.
SDK - 3.0.100 - preview8-013656
Visual Studio Community 2019 Preview 16.3.0 Preview 2.0
In Output VS i see -
Failed to load resource: the server responded with a status of 404 (Not Found) [http://localhost:49566/_framework/blazor.boot.json]
SyntaxError: Unexpected end of JSON input
at Object. (http://localhost:49566/_framework/blazor.webassembly.js:1:30734)
at http://localhost:49566/_framework/blazor.webassembly.js:1:30237
at Object.next (http://localhost:49566/_framework/blazor.webassembly.js:1:30342)
at i (http://localhost:49566/_framework/blazor.webassembly.js:1:29088)
The program '' has exited with code -1 (0xffffffff).
The program '[3548] dotnet.exe' has exited with code -1 (0xffffffff).
I tried to run like this - For a Blazor client-side experience, execute the following commands in a command shell:
dotnet new blazorwasm -o WebApplication1
cd WebApplication1
dotnet run
The result is the same. Help, please! I can’t do anything, because I stopped at the very beginning.

Hi.
It looks like you are posting on a closed issue!
We're very likely to lose track of your bug/feedback/question unless you:

Open a new issue
Explain very clearly what you need help with
If you think you have found a bug, include detailed repro steps so that we can investigate the problem


TypeScript errors with Preact components

[x] I have read the troubleshooting section before opening an issue.
[x] I have tried upgrading iles and vite.

Description 📖
In a new îles app with Preact, I tried creating a component with TypeScript, and got a TypeScript error:

Type 'Element' is not assignable to type 'VNode'.

(See full output below.)
Reproduction 🐞
eostrom/iles-preact-typescript-repro

Dependencies Info
❯ npx iles info
iles v0.6.4 vite v2.6.14

❯ npm list
<EMAIL_ADDRESS>/Users/eostrom/workspace/swagleft/iles-preact-typescript-repro
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>

Logs 📜

Output
npm run dev and build work, but my IDE shows the errors produced by yarn tsc --noEmit:
src/components/FrameworkLink.tsx:4:3 - error TS2322: Type 'Element' is not assignable to type 'VNode<any>'.
  Types of property 'type' are incompatible.
    Type 'VNodeTypes' is not assignable to type 'string | ComponentType<any>'.
      Type 'VNode<RendererNode, RendererElement, { [key: string]: any; }>' is not assignable to type 'string | ComponentType<any>'.
        Type 'VNode<RendererNode, RendererElement, { [key: string]: any; }>' is not assignable to type 'string'.

4   <a target="_blank" href="https://preactjs.com">
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5     Preact
  ~~~~~~~~~~
6     { props.children }
  ~~~~~~~~~~~~~~~~~~~~~~
7   </a>
  ~~~~~~

  node_modules/preact/src/index.d.ts:85:18
    85 export interface FunctionComponent<P = {}> {
                        ~~~~~~~~~~~~~~~~~
    The expected type comes from the return type of this signature.

Found 1 error.

The solution for me was to change the jsx property in tsconfig.json and add jsxImportSource:
    "jsx": "react-jsx",
    "jsxImportSource": "preact",

solution from Preact docs
PR in my repo

I'm not sure where the initial tsconfig.json file came from or how to make this change for Preact projects only, but if you point me in the right direction I'd be happy to try to provide a PR.

Hi Erik!
Thanks for sharing! I'll add the proper tsconfig.json to the preact template in Iles-create.
I'll keep this issue open as a reminder in the meantime.

Fixed in<EMAIL_ADDRESS>Thanks @eostrom!


fix:修复选择更多模版按钮文字在小尺寸屏幕下换行

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation update
[ ] Performance improvement
[ ] Test related changes
[ ] Security fix
[ ] Dependency update
[ ] Revert changes
[ ] Other... Please describe:

What is the current behavior?
选择更多模版按钮的文字会在小尺寸屏幕下换行
What is the new behavior?
加宽不换行
Does this PR introduce a breaking change?

[ ] Yes
[x] No

UI Changes

Other information

感谢你的pr，如果想参与后续的，可以添加我主页上的微信我邀请你进群


retry find statefulset when destroyMaster

Ⅰ. Describe what this PR does
when delete JindoRuntime, if master statefulset deleted early, the delete process will trap in a loop so that the deletion process cannot proceed normally
2021-05-12T15:33:49.437+0800	INFO	jindoctl.JindoRuntime	jindo/cache.go:65	Failed to get master	{"jindoruntime": "default/hadoop", "err": "StatefulSet.apps "hadoop-jindofs-master" not found"}
2021-05-12T15:33:49.437+0800	ERROR	jindoctl.JindoRuntime.reconcileRuntimeDeletion	controllers/runtime_controller.go:158	Failed to shutdown the engine	{"jindoruntime": "default/hadoop", "Runtime": {"namespace": "default", "name": "hadoop"}, "error": "StatefulSet.apps "hadoop-jindofs-master" not found"}
Ⅱ. Does this pull request fix one issue?

Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #774 (59a3cb3) into master (edf7060) will increase coverage by 0.33%.
The diff coverage is 28.31%.

:exclamation: Current head 59a3cb3 differs from pull request most recent head 4f027f3. Consider uploading reports for the commit 4f027f3 to get more accurate results

@@            Coverage Diff             @@
##           master     #774      +/-   ##
==========================================
+ Coverage   12.63%   12.97%   +0.33%
==========================================
  Files          93       96       +3
  Lines        4241     4316      +75
==========================================
+ Hits          536      560      +24
- Misses       3645     3696      +51
  Partials       60       60

Impacted Files
Coverage Δ

pkg/common/constants.go
0.00% <ø> (ø)

pkg/ddc/alluxio/metadata.go
0.00% <0.00%> (ø)

pkg/ddc/alluxio/transform.go
0.00% <0.00%> (ø)

pkg/ddc/alluxio/transform_optimization.go
78.46% <0.00%> (ø)

pkg/ddc/alluxio/ufs_internal.go
0.00% <0.00%> (ø)

pkg/ddc/alluxio/utils.go
36.17% <ø> (-1.33%)
:arrow_down:

pkg/ddc/jindo/cache.go
0.00% <0.00%> (ø)

pkg/ddc/jindo/master_internal.go
0.00% <0.00%> (ø)

pkg/ddc/jindo/runtime_info.go
0.00% <ø> (ø)

pkg/ddc/jindo/shutdown.go
0.00% <0.00%> (ø)

... and 12 more

Continue to review full report at Codecov.

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


Open new tab when logged in

Currently when a person is logged in, and they click 'Pledge to Donate' it does not take them to a new tab like it does when you are not logged in.
The stakeholder would like the 'Pledge to Donate' button to open in a new tab regardless if the user is logged in or not.

Hi @seanmarcia I would love to tackle this and a few other beginner friendly issues on this project - let me know if someone else is working on this, otherwise, look out for a PR in the next few days!

Hey @memcmahon the issue(s) are yours! I sent you an invite to collab so you can send PR's directly and not have to fork :)

Awesome, thanks @seanmarcia!

Hey @seanmarcia - I just submitted a PR(#200) that I believe resolves this issue.  After digging in to it, I think the main issue was slightly different than originally outlined.  I have summarized my findings below and on the PR.  Also, I noticed that the Travis CI build is failing on my push, but passing on the PR.  I don't think I made any changes that would have caused a major failure, but any insight that you have on this would be appreciated!
Updated Description of Issue
####Expected Behavior:
As a user (logged in or not)
When I visit the root page
And click on 'Pledge To Donate'
A new tab is opened with the item's amazon url
And the current page is redirected to the pledges page
Then when I click on 'home'
And click on 'Pledge to Donate'
A new tab is opened with the item's amazon url
And the current page is redirected to the pledges page
####Actual Behavior:
As a user (logged in or not)
When I visit the root page
And click on 'Pledge To Donate'
A new tab is opened with the item's amazon url
And the current page is redirected to the pledges page
Then when I click on 'home'
And click on 'Pledge to Donate'
Then the current page is redirected to the pledges page
-- OR --
As a user (logged in or not)
When I visit the root page
And click on 'Pledge To Donate'
A new tab is opened with the item's amazon url
And the current page is redirected to the pledges page
Then when I click on my browser's back button
A new tab is opened with the item's amazon url
And the current page is redirected to the pledges page
As outlined above, the issue is that the expected behavior (a new tab being opened) is only happening the first time the home page is loaded and subsequently, only if the browser's back button is used. The fix should allow for the expected behavior regardless of the user's method of returning to the home page.


AttributeError: 'RVC' object has no attribute 'tgt_sr'

Traceback (most recent call last):
File "D:\BaiduNetdiskDownload\RVC-beta0717\RVC-beta0717\gui_v1.py", line 502, in
gui = GUI()
File "D:\BaiduNetdiskDownload\RVC-beta0717\RVC-beta0717\gui_v1.py", line 74, in init
self.launcher()
File "D:\BaiduNetdiskDownload\RVC-beta0717\RVC-beta0717\gui_v1.py", line 260, in launcher
self.event_handler()
File "D:\BaiduNetdiskDownload\RVC-beta0717\RVC-beta0717\gui_v1.py", line 271, in event_handler
self.start_vc()
File "D:\BaiduNetdiskDownload\RVC-beta0717\RVC-beta0717\gui_v1.py", line 330, in start_vc
self.config.samplerate=self.rvc.tgt_sr
AttributeError: 'RVC' object has no attribute 'tgt_sr'

please don't use beta release, there are new one here :
For Nvidia GPU users:
https://huggingface.co/lj1995/VoiceConversionWebUI/resolve/main/RVC1006Nvidia.7z
For AMD/Intel GPU users:
https://huggingface.co/lj1995/VoiceConversionWebUI/resolve/main/RVC1006AMD_Intel.7z
for start UI : go-web.bat


Prepare 6.11.0 release

🎈 Release
Preparation for 6.11.0 release
Comparison to 6.10.0: https://github.com/gazebosim/gz-math/compare/ignition-math6_6.10.0...ign-math6
Checklist

[x] Asked team if this is a good time for a release
[ ] There are no changes to be ported from the previous major version
[ ] No PRs targeted at this major version are close to getting in
[x] Bumped minor for new features, patch for bug fixes
[x] Updated changelog
[ ] Updated migration guide (as needed)
[ ] Link to PR updating dependency versions in appropriate repository in ignition-release (as needed):

#424 has been merged

#424 has been merged

5c6761d


Page of  materials created by NFDI4BioImage members

If we had a list of NFDI$BioImage  members, we could build a [sub]page that lists all materials NFDI4BioImage created.

I've now introduced a tag for this:
  tags:
  - NFDI4BioImage


chore: upgraded psr/log dependency version (added compatibility to ^v1|^v2|^v3)

Hey, thank you for your work, I just discovered this package.
I first used it with the cachetool.phar and saw that it can be added as a project dependency.
In a fresh SF6 app with symfony/cache, it was not possible to run composer require gordalina/cachetool as psr/log was in version 3.0 (see the above log).
I could have run composer require gordalina/cachetoo -W to downgrade psr/log but maybe this PR is usefull for you anyway.
Please feel free to give me your feedback if it was a good idea or not.
Logs:
Problem 1
- Root composer.json requires gordalina/cachetool ^8.1 -> satisfiable by gordalina/cachetool[8.1.0].
- gordalina/cachetool 8.1.0 requires psr/log ^1.0 -> found psr/log[1.0.0, ..., 1.1.4] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

This is great, thank you for contributing!

Thank you for your feedback !


OS wait support

Coroutinify wait() and waitpid() syscalls

Errors on windows-latest are not related.


help_docs: Update link in restrict-private-messages.

Updates a link to point to the correct help center documentation page, and makes some small style adjustments to the page in general.
Screenshot of updated help center documentation:

Looks good other than the comments above -- thanks for the fixes!

Hmm, let's make it: "In Zulip, users can exchange private messages with other users, bots and themselves."; the word "themself" looks a bit funny to me here.
Otherwise, looks good to me!

@timabbott ready for you.

Merged, thanks @laurynmm and @alya!  I do note, unrelatedly, that we still mention a "beta period" in this article -- we might want to remove that classification (possibly after testing and then opening some issues for any remaining tweaks we want to make).

Tweaks I see:

#13656, which I added to the list of https://github.com/zulip/zulip/issues/19525 follow-ups
Filed #21888
Filed #21889
Added a note to #3409

I think only #21889 should be a blocker for removing the "beta" flag from the help center doc and the settings UI.


Multiple Commands

When creating my own custom power using execute command, does it allow the use of multiple commands?

You can use an origin:and action and then have multiple execute_command actions, or you can use a function. Also, this is not the place for asking data pack questions, please use the Origins Discord for that.


False positives for German date strings

I am using the phone number matcher (default to DE) to sift through a large body of German text for finding phone numbers - it works pretty good, thank you!
Unfortunately, I am getting a lot of false positives for German point-separated dates and date ranges, e.g.:
05.10.1986
03.05.1987
03.06.15
02.03.1992
05.06.2011
03.05.1984
04.07.1988
03.01.1990
03.07.90
04.06.1988
04.06.-07.06
03.07 - 17.07.15
03.06-07.06.2015
03.07 - 10.07
16.8.-1.9
04.06-07.06
08.06  - 22.06
07.08. - 25.08
05.10-09.10.2015
03.08.15-04.08.15
Not sure about validity of these numbers, but I suppose many people would classify them not as phone numbers (see http://en.wikipedia.org/wiki/Date_format_by_country)
There is already an exception for SLASH_SEPARATED_DATES in PhoneNumberMatcher.java, I think it would be a good idea to extend that at least to POINT_SEPARATED_DATES. That doesn't cover of course the date ranges.

Yes, that's a known issue, especially with German numbers which have a huge range of possibly valid numbers in terms of the length. Similar issues are known e.g. with Italian numbers too.
A reasonable phone number annotator in free text should check for high confidence date patterns first. Once you've ruled out that it's a not a date (e.g. applying ICU as a high precision low recall date parser), you can apply the phone number library.

Hmm, why shouldn't that be part of PhoneNumberMatcher.java which as far as I can tell is designed to be exactly such an annotator? As noted there is already an exception for slash dates:
private static final Pattern SLASH_SEPARATED_DATES =
      Pattern.compile("(?:(?:[0-3]?\\d/[01]?\\d)|(?:[01]?\\d/[0-3]?\\d))/(?:[12]\\d)?\\d{2}");

As you can see from my Wikipedia link there are dozens of countries that use a point convention for dates. Or is 05.10.1986 a more valid phone number than 05/10/1986?

Indeed is 05.10.1986 a more valid phone number than 05/10/1986. We have often seen dot as a valid separator (in addition to space, dash) for phone number formatting. However, slash as a separator never gets used beyond separating area code and subscriber number, which means there should be no more than 1 slash in a phone number.

Also, note there are multiple leniency levels implemented for the phone number matcher, which you can use to cut down false positives.


parsing error

i keep getting a parsing error, it downloads but it doesnt load

Which maps cause this error?


chore: configure renovate

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feature: Explicit CUDA, OpenCL support in Clangd extra

Did you check the docs?

[X] I have read all the LazyVim docs

Is your feature request related to a problem? Please describe.
Currently, LazyVim with Clangd extra does not know about the existence of CUDA and OpenCl files at all, despite the fact that much of the tool used in the extra (like the Clangd language server) already supports them natively. Neovim assigns lisp filetype for OpenCl files.
At the moment, I circumvented the issue with an autocommand that sets the filetype to c, when I open an OpenCL file. This way I can access much of the features. Though it is a little bit buggy solution (for example there is no syntax highlight for telescope preview).
Describe the solution you'd like
Explicit support for CUDA, OpenCl, akin to what already is for C / C++.
Describe alternatives you've considered
LazyVim with the Clang extra, should detect CUDA and OpenC files, and have all the features that it have for C / C++.
Additional context
Since CUDA and OpenCL are simple extensions of the basic C, many of the Clangd extra tools support them natively. It should not be much difficulty to add them, because only some filetype definition and assignment is needed.

The languages Extras come from user contributions mostly who dabble in the specific domain. Feel free to submit a PR.


Installing ArangoDb silently, with all the settings by default. How?

For Ubuntu 21.x, or Debian 9. And MacOS as well.
I want to install ArangoDb silently, via a bash script, so that a user won't have to specify password, nor select any other settings at all. With all the default settings.
How to do that?
When I download and run a *.deb file, or when I try to install it via "apt install ...", installation process doesn't go silenty as it'lll ask 4 questions: create a new passowrd, whether or not make backups, which engine....

have a look at the old docker scripts, they used to do exactly that: https://github.com/arangodb/arangodb-docker/blob/official/Dockerfile33.local

Is there a standard, easier way? For instance, on Arch Linux in Aur, it's installed, from a deb package, without these commands:
echo arangodb3 arangodb3/password password test | debconf-set-selections) && \
    (echo arangodb3 arangodb3/password_again password test | debconf-set-selections) && \
    DEBIAN_FRONTEND="noninteractive"

somehow.

else use the tarball?


Request inclusion of man pages from Debian

In the Fedora package review, it has been suggested that it might be a good idea for the man pages provided from Debian be added to the official yosys repository and releases.  As of this writing, they can be found in a tarball at:
http://dist1.800hosting.com/debian/pool/main/y/yosys/yosys_0.7-2.debian.tar.xz
However, the URL changes every time the Debian package is revised.
If you'd like me to to add them and submit a pull request, let me know.

I'll accept a pull request that adds the man page. Please coordinate with the debian package maintainer @rubund to guarantee a smooth transition regarding the primary location of the man page.


fix: Changed error message to be thrown on failed parsing of executeActionDTO

Description

A malformed body (multipart form) for the /execute endpoint leads to an error on UI showing: "invalid parameter: executeActionDTO".
This has now been changed in this pr to show error as: "The request could not be understood by the server due to malformed syntax."

PR fixes following issue(s)
Fixes #23250 (partly)
Type of change

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

Testing

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[ ] Manual
[ ] Jest
[ ] Cypress

Test Plan

This can be tested by calling /execute endpoint with malformed form data since replicating this issue using UI is unreliable. The UI in general doesn't produce a malformed request body.

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/build-deploy-preview

/ok-to-test

/ok-to-test


Umlauts with \u \U for ü Ü ...

Description
Latex has this nice syntax where it renders all "us as üs.
As of now, typst does to my knowledge not include any way to write umlauts without having them on the keyboard.
A possible syntax to enable that could be \u for ü, \s for ß and so on.
Use Case
This way, Users who don't have umlauts on their keyboard can still write German stuff fast and without too much distractions -- just like with LaTex.

Duplicate https://github.com/typst/typst/issues/833


Add migration according to Node change

This issue is to support Node 설정 상세 규격 project, in https://www.notion.so/cluml/Node-d1a58fd7fbb8488db1b33157eae8ad77?pvs=4

Resolved by ee18807ccb32053a8d300cb12bd2747ff708afa5

@sehkone I do not have rights to close this issue, please close.

Closed by #161


Dialog, Alert and Confirm

Add a new Dialog Cube, serving as a Base for new Alert and Confirm Cubes.

Rename Confirm and Alert to ConfirmDialog and AlertDialog


Pixel perfect Navbar filters

I'll give more details with comments on the code 👌

Woohoo! OMG this is so much better, thanks @promatik ! Can confirm it's all looking and working nicely:
https://github.com/Laravel-Backpack/CRUD/assets/1032474/ce021e82-0b58-4b7f-96b6-2814130530d9


Upgrade to lodash 4.17.11

There are known vulnerabilities in versions of Lodash lower than 4.17.11
https://nvd.nist.gov/vuln/detail/CVE-2018-16487
https://nvd.nist.gov/vuln/detail/CVE-2018-3721
Upgrading to 4.17.11 resolves these vulnerabilities

You broke the build, please take a look at resolving.
It's also not your place to release a new version, please remove that
commit.
On Fri, Mar 1, 2019, 8:28 AM Doug Keller<EMAIL_ADDRESS>wrote:

There are known vulnerabilities in versions of Lodash lower than 4.17.11
https://nvd.nist.gov/vuln/detail/CVE-2018-16487
https://nvd.nist.gov/vuln/detail/CVE-2018-3721
Upgrading to 4.17.11 resolves these vulnerabilities
You can view, comment on, or merge this pull request online at:
https://github.com/terinjokes/gulp-uglify/pull/351
Commit Summary

Upgrade to lodash 4.17.11 to avoid security vulnerabilities
3.0.2

File Changes

M package.json
https://github.com/terinjokes/gulp-uglify/pull/351/files#diff-0 (4)

Patch Links:

https://github.com/terinjokes/gulp-uglify/pull/351.patch
https://github.com/terinjokes/gulp-uglify/pull/351.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/terinjokes/gulp-uglify/pull/351, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQsZWIBCFGHgDQ-QuxGPGzHjuekBPiHks5vSVU4gaJpZM4bZXiU
.


Equinox causes assertion failures if operating on PyTrees containing custom PyTree nodes defined using jax-dataclasses

Equinox causes assertion failures if operating on PyTrees containing custom PyTree nodes defined using jax-dataclasses. In particular, equinox calls .unflatten with a treedef that terminates at the custom PyTree node, but supplies a scalar Boolean value for the leaf (so shape annotations are violated).
Equinox works fine with simple custom PyTree nodes:
import jax
import jax.numpy as jnp
import equinox as eqx

class FooBasic:
    def __init__(self,array):
        self.array=(array,)

def unflatten(aux_data,flat_contents):
    return FooBasic(*flat_contents)
def flatten(item):
    return item.array,None

jax.tree_util.register_pytree_node(FooBasic,flatten,unflatten)
jax.tree_util.tree_leaves([FooBasic(jnp.ones(3)),FooBasic(jnp.zeros(3))])

yields:
[Array([1., 1., 1.], dtype=float32), Array([0., 0., 0.], dtype=float32)]

as expected, and:
eqx.filter_closure_convert(do_nothing, FooBasic(jnp.array([1,2,3])))

yields:
_TrivialClosureConvert(
  fn=<function do_nothing>,
  in_dynamic_struct=(
    [ShapeDtypeStruct(shape=(3,), dtype=int32)],
    PyTreeDef(((CustomNode(FooBasic[None], [*]),), {}))
  ),
  in_static=([], PyTreeDef(((CustomNode(FooBasic[None], [None]),), {})))
)

However, if we instead use jax-dataclasses to make the custom PyTree node:
import jax_dataclasses as jdc
import jax.numpy as jnp
from typing import Annotated
import equinox as eqx

@jdc.pytree_dataclass
class Foo(jdc.EnforcedAnnotationsMixin):
    bar:Annotated[jnp.ndarray,(...,3),]
def do_nothing(X):
    return X

eqx.filter_closure_convert(do_nothing, Foo(jnp.array([1,2,3])))

then we get an exception:
AssertionError                            Traceback (most recent call last)
Cell In[1], line 12
      9 def do_nothing(X):
     10     return X
---> 12 eqx.filter_closure_convert(do_nothing, Foo(jnp.array([1,2,3])))

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/equinox/_ad.py:547, in filter_closure_convert(fn, *args, **kwargs)
    511 def filter_closure_convert(fn: Callable[_P, _T], *args, **kwargs) -> Callable[_P, _T]:
    512     """As `jax.closure_convert`, but works on functions accepting and returning
    513     arbitrary PyTree objects. In addition, all JAX arrays are hoisted into constants
    514     (not just floating point arrays).
   (...)
    545         ```
    546     """
--> 547     in_dynamic, in_static = partition((args, kwargs), _is_struct)
    548     in_dynamic_struct = jax.eval_shape(lambda: in_dynamic)
    549     in_dynamic_struct = jtu.tree_flatten(in_dynamic_struct)

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/equinox/_filters.py:149, in partition(pytree, filter_spec, replace, is_leaf)
    135 def partition(
    136     pytree: PyTree,
    137     filter_spec: PyTree[AxisSpec],
    138     replace: Any = None,
    139     is_leaf: Optional[Callable[[Any], bool]] = None,
    140 ) -> tuple[PyTree, PyTree]:
    141     """Splits a PyTree into two pieces. Equivalent to
    142     `filter(...), filter(..., inverse=True)`, but slightly more efficient.
    143
   (...)
    146         See also [`equinox.combine`][] to reconstitute the PyTree again.
    147     """
--> 149     filter_tree = jtu.tree_map(_make_filter_tree(is_leaf), filter_spec, pytree)
    150     left = jtu.tree_map(lambda mask, x: x if mask else replace, filter_tree, pytree)
    151     right = jtu.tree_map(lambda mask, x: replace if mask else x, filter_tree, pytree)

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/jax/_src/tree_util.py:244, in tree_map(f, tree, is_leaf, *rest)
    242 leaves, treedef = tree_flatten(tree, is_leaf)
    243 all_leaves = [leaves] + [treedef.flatten_up_to(r) for r in rest]
--> 244 return treedef.unflatten(f(*xs) for xs in zip(*all_leaves))

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/jax/_src/tree_util.py:244, in <genexpr>(.0)
    242 leaves, treedef = tree_flatten(tree, is_leaf)
    243 all_leaves = [leaves] + [treedef.flatten_up_to(r) for r in rest]
--> 244 return treedef.unflatten(f(*xs) for xs in zip(*all_leaves))

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/equinox/_filters.py:71, in _make_filter_tree.<locals>._filter_tree(mask, arg)
     69     return jtu.tree_map(lambda _: mask, arg, is_leaf=is_leaf)
     70 elif callable(mask):
---> 71     return jtu.tree_map(mask, arg, is_leaf=is_leaf)
     72 else:
     73     raise ValueError(
     74         "`filter_spec` must consist of booleans and callables only."
     75     )

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/jax/_src/tree_util.py:244, in tree_map(f, tree, is_leaf, *rest)
    242 leaves, treedef = tree_flatten(tree, is_leaf)
    243 all_leaves = [leaves] + [treedef.flatten_up_to(r) for r in rest]
--> 244 return treedef.unflatten(f(*xs) for xs in zip(*all_leaves))

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/jax_dataclasses/_dataclasses.py:106, in _register_pytree_dataclass.<locals>._unflatten(treedef, children)
    105 def _unflatten(treedef, children):
--> 106     return cls(
    107         **dict(zip(child_node_field_names, children)),
    108         **{key: tdef for key, tdef in zip(static_field_names, treedef)},
    109     )

File <string>:4, in __init__(self, bar)

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/jax_dataclasses/_enforced_annotations.py:121, in EnforcedAnnotationsMixin.__post_init__(self)
    118 if len(metadata_shape) > 0 and shape is not None:
    119     # Get expected shape, sans batch axes.
    120     (expected_shape,) = metadata_shape
--> 121     field_batch_axes = _check_batch_axes(shape, expected_shape)
    122     if batch_axes is None:
    123         batch_axes = field_batch_axes

File ~/miniconda3/envs/gobnilp/lib/python3.9/site-packages/jax_dataclasses/_enforced_annotations.py:176, in _check_batch_axes(shape, expected_shape)
    169 suffix = shape[-len(expected_suffix) :]
    171 shape_error = (
    172     "Shape did not match annotation: expected"
    173     f" ({','.join(map(str,expected_prefix + ('*',) + expected_suffix))}) but"
    174     f" got {shape}."
    175 )
--> 176 assert suffix == expected_suffix, shape_error
    177 assert prefix == expected_prefix, shape_error
    178 batch_axes = shape[len(expected_prefix) : -len(expected_suffix)]

AssertionError: Shape did not match annotation: expected (*,3) but got ().

This looks like a bug in jax-dataclasses. In JAX, unflatten rules must work using any leaf types. Typically this means that an unflatten rule should not call __init__, and it certainly shouldn't perform typechecks. See also the guidance in the JAX docs.
I'd recommend using equinox.Module instead, which behaves correctly here.

jax-dataclasses is unfortunately a dependency of a dependency for me so swapping will be painful. Thanks for clarifying! Will see about filing an issue against jax-dataclasses.


Make branches more easily identifyable

via reddit
/u/VerticalEvent has a point, if you have multiple devs using the same branch this could get hell of confusing after.

Merged #4, which fixes this. :+1: