Fixes Issue 9677: Docker client errors out, when daemon flags are passed to docker subcommands

Fixes #9677

@duglin right now docker flag parsing relies on one hashmap to classify whether the incoming argument is a flag or not. That map includes both daemon and global flags. Unless we use two maps to store daemon and global args separately, I don't see a way to avoid this extra map.
N Separating IMHO would not be easy, it has dependencies everywhere.
For this error, we need some kind of data structure to look-up if the incoming argument is a daemon flag or not.
I will  reorder the entries according to the help menu. And also add the deprecated flags which I have not added.
Shishir

@shishir-a412ed sorry if I wasn't clear.  I wasn't talking about a map during parsing, I was talking about a map/struct during flag setup time.  For example, if you look at the InstallFlags() func, that is what will register all of our daemon-side flags.  And it does it via a list of flag.XXX calls. A hard coded list of calls.  So knowing when a new one (like perhaps "-log-driver" at the end) is added is hard to detect when you also want to have your new code work.   So, I was wondering if we could take all of the flag definitions from InstallFlags() and put them into a struct.  InstallFlags() would then look over that struct to make all of the appropriate flag.XXX calls.
But, and this is the point, your new code can then use that same struct to perform the checks you need to know if any of them were specified w/o the -d flag.  Then as new flags are added you won't need to update your code.  Does this make any sense?

@duglin
I think I get the central idea of what you are trying to achieve.
You are trying to have a common struct/map that can be used to set the flags in daemon/config.go InstallFlags() method. By iterating over that data structure and populating the flags rather than hard coding it.
N use the same struct/map to do the look-up for my use-case to identify if it's a daemon flag or not.
So that updates are made at one central location rather than at two different places.
Few open questions:

" So, I was wondering if we could take all of the flag definitions from InstallFlags() and put them into a struct. InstallFlags() would then look over that struct to make all of the appropriate flag.XXX calls."
Isn't that what we are doing right now ? flag.XXX call is using the daemon config struct to populate the flags. InstallFlags is a method typed to daemon config struct i.e. struct.InstallFlags()
Not sure how you would iterate over a struct and avoid the hard coding ?

Populating a flag needs a struct. I am not sure how a map would work here, as iterating over a map won't tell me which field I am getting back. Checking daemon flags would needs a map to do the lookup {struct won't work here}. I feel these are two different use cases requiring two different data structures.

Nways let other maintainers jump in, and see what they feel.
I ll be happy to change the code, if there is a mutual consensus on a solution.
Till that time, I ll clean up the code.
Shishir

@duglin I have reordered the flags according to the help menu.
And added support for deprecated flags.
ping @tiborvass
Shishir

@shishir-a412ed  to your questions:

no its not. Each call to flag.XXX is hand coded, not reading from a structure/array. This means that each time a new daemon flag is created people will need to not only add a new call to flag.XXX but also remember to update your Init() func - which I'm sure they'll forget. By having a single spot that is used to define the daemon flags (via a flag.XXX call) and setup your mapDaemonFlags structure, we avoid one being updated w/o the other.
wouldn't all daemon flags, except -d, be added to your mapDaemonFlags structure? If so, then we just need one if-statement to avoid adding it to your mapDaemonFlags.
But perhaps I'm missing something, or defining such a structure/array is more complicated than I'm thinking.

@duglin I have re-factored the code. Does this solve your concern ?

@icecrime Thanks, I have made the changes. Please check now.

@shishir-a412ed I'm afraid this also needs to be rebased. The code looks good to me except for a minor comment.

@calavera thanks ... I have rebased the PR and made changes for the comment.

cool, thanks!
:space_invader: LGTM :space_invader:

LGTM

@duglin @icecrime @tiborvass I ll go ahead and be ambitious here ! lol
But can we get this merged in docker 1.6.0 ?

LOL good one :-)

I think we can wait for 1.7

@shishir-a412ed this doesn't really solve any regression in the current RCs for 1.6.0. I'm afraid it'll probably have to wait until 1.7. But good try :grin:

@calavera @duglin @icecrime @tiborvass 1.7.0 it is :)
Let me add some testing code to the PR by then.

sorry needs rebase

@jfrazelle I have rebased the PR.

@calavera I have changed this HasDaemonFlag = MapDaemonFlags[name] back to my original code.
This has a small bug. If a daemon flag is followed by a global flag. At the end of the flag parsing flag.Parse()
HasDaemonFlag would be set to false eventhough it should have been true.

@shishir-a412ed it makes sense, thanks for fixing it. I think it would make sense to add a few tests to validate this behavior.
I was also wondering if it would make sense to have two completely different FlagSet lists, one for the daemon flags and another for the rest. That way we wouldn't need to modify the flag package. I don't know if that would work as expected though.

We are planning on a more extensive patch to break these flags apart.  But we need to do a lot of hacking for backwards compatibility.  Sadly if we could go back to original docker and just have
docker daemon ...
All of this would be unnecessary...

@calavera I ll add the test cases in 1-2 days. Thanks.

@calavera I have added the test cases.
ping @tiborvass

@shishir-a412ed Thanks for your work Shishir, I'll carry this PR and #10535 to get it in asap.

Where is this going to be carried?

Carried in #13771


Add a page with the usage of the add API

@Fati-Mon mentioned that from the documentation it is not clear how to set up a model in Ribasim python for new users. We have the examples, but that is already quite a deep dive without detailed explanation of the add API.
So I propose adding a new page with how to set up a model, with detailed explanations of every step from initializing the model to writing it to disk. Maybe also add some information about how the input data will end up in the tables.

This is what I had in mind for #1158 as well.


[KOGITO-7288] [KSW-Guides] Event correlation with workflows

JIRA: https://issues.redhat.com/browse/KOGITO-7288

Description:

Please make sure that your PR meets the following requirements:

[ ] You have read the contributions doc
[ ] Pull Request title is properly formatted: KOGITO-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting main: [0.9.x] KOGITO-XYZ Subject
[ ] The nav.adoc file has a link to this guide in the proper category
[ ] The index.adoc file has a card to this guide in the proper category, with a meaningful description

@tiagodolphine can you please rebase and consider @MarianMacik's suggestions, please?

Merging this PR for DP1


Allow multiple dhcp6c debugging levels.

dhcp6c has two levels of debugging or NO debugging,. Specifying -d or -D gives you the two levels. Omitting it completely gives no debug logging, meaning it's quiet.
Due to the escaping of the existing commands in interfaces inc I have had to add a check to see if both debugging and no-release are empty, thus the two exec_safe options.
This replaces the commit I had to close.
#3934 PR replaces this PR and adds multiple dhcp6c WAN. Use of both PRs will require cherry picking.

Is this still active?

It's built into other updates... IIRC!


Add a new selection method for unit_test:

^we are aligned that the option to "add a new selection method for unit_test:" is the preferred solution!

Originally posted by @graciegoheen in https://github.com/dbt-labs/dbt-core/issues/9895#issuecomment-2077293380
Housekeeping

[X] I am a maintainer of dbt-core

Short description
There should be a selection method for unit tests (unit_test:), and the output of dbt ls should be usable with dbt test --select {unit test selection method}.
Acceptance criteria

Output of dbt list still includes:unit_test:my_project.my_unit_test

Output of dbt ls --select unit_test:my_project.my_unit_test includes:unit_test:my_project.my_unit_test

dbt run --select unit_test:my_project.my_unit_test does nothing
dbt test --select unit_test:my_project.my_unit_test executes a single node -- the unit test
dbt build --select unit_test:my_project.my_unit_test executes a single node -- the unit test
PR resolves and closes both #9895 and #10053

e.g., if the PR description includes resolves #9895 resolves #10053, it will accomplish that goal.

Confirm that the user docs label opens an issue in the docs.getdbt.com repo

Update the docs issue with enough information for this feature to be documented (syntax example(s) and link to the docs page to be updated).

Suggested Tests
Although the following two proposed tests cover independent expected behaviors, they can be combined into a single test if desired.
Test 1

dbt list --select {mode_name} --output json --quiet
Parse the output as JSON-L
Confirm there is just a single item and it has the expected unique_id value

Test 2
Do the following steps:

dbt list --select {mode_name} --output json --quiet
Parse the output as JSON-L
For each item in the result, confirm the following has the expected result:

dbt test --select {unique_id}

Impact to Other Teams
Unknown.
Will backports be required?
No.
Context
https://github.com/dbt-labs/dbt-core/issues/9895

Opened a new issue in dbt-labs/docs.getdbt.com: https://github.com/dbt-labs/docs.getdbt.com/issues/5468


localization.csv already exists

Every time I run php artisan larex:import crowdin I get the message The 'resources/lang/localization.csv' already exists.. It works when I delete the file first. But is this the way it should work? It would be easier if the import function just overwrites the existing csv file.

Append --force parameter


The character move when must hit section

What is your question?
The character move when the camera follow the character in must hit section, how to fix?

Probably an issue with your .XML

I am having the same issue. The XML is directly from adobe, so that cannot be the case.

The character move when the camera follow the character in must hit section, how to fix?

Rephase that, i dont get it

The character move when the camera follow the character in must hit section, how to fix?

Rephase that, i dont get it

basically, when a must hit section changes, a character moves with the screen. like an object set to the hud or other.

The problem is in your XML file.


[Feature] Publish alloy on crates.io

Component
rpc
Describe the feature you would like
Could a recent version of alloy be published on crates.io?
Additional context
The version available on crates.io give the impression that alloy is a project that is just starting and not usable. This is the wrong impression as I could use it for my needs.
An additional problem is that crates.io is a closed system. You cannot publish a crate if it depends on a crate which is not on crates.io. So the lack of publishing has functional consequences.
The problems that I see are the following:

The alloy (see https://crates.io/crates/alloy) has a fixed version 0.1.0 and there is no pointing GitHub repository.
The alloy-provider (see https://crates.io/crates/alloy-provider) is marked as 0.1.0 and updated 5 days ago, yet only one version is indicated and there is again no pointing GitHub repository.
The alloy-rpc-types (see https://crates.io/crates/alloy-rpc-types) is marked as v0.0.0-reserved. Which is a little bit unfortunate because there is a rpc-types-eth in alloy.

Our company have ended up starting a big project using ethers because a combination of factors made it appear that alloy is A LOT less mature than it actually is.
To ones listed above I would add:

alloy marked as "Soon" in top-level project readme
no link to examples repo in the meta-crate readme
major projects like foundry still using ethers alongside alloy (that was more of a case a few months ago, now looks like only abigen dep still left)

It's only after a lot of digging and discovering examples we realized the true state of the crate and have since been actively migrating to alloy.
Alloy releases not present in crates.io is now a big obstacle that prevents us from uploading our own libraries built on top of it.

This has been done :)
https://crates.io/crates/alloy


how to access a rawBody in an endpoint

Discussed in https://github.com/sveltejs/kit/discussions/10832

Originally posted by jesuscovam October  5, 2023
Describe the bug
To validate a request from stripe, I have to provide them the rawBody of the request, but every try throws an error.

I have tried other solutions that I read in other issues that worked for some users but I couldn't make it work
Solution with text: https://github.com/sveltejs/kit/pull/3384#issuecomment-1087795404
Solution with buffer: https://github.com/sveltejs/kit/pull/3384#issuecomment-1087011013
I think we have the same error https://github.com/sveltejs/kit/issues/10339
Reproduction
pnpm dev this sveltekit app repo
have installed the stripe-cli and have an user to test it download stripe cli
do the login for the stripe with stripe login
connect the cli with the server stripe listen --forward-to http://localhost:5173/api/with-buffer
in a another terminal run a stripe event, the one I use is payment.intent stripe trigger payment_intent.succeeded
you can also test the other method with stripe listen --forward-to http://localhost:5173/api/with-text
Logs
StripeSignatureVerificationError: No signatures found matching the expected signature for payload. Are you passing the raw request body you received from Stripe?

System Info
System:
    OS: macOS 14.0
    CPU: (8) arm64 Apple M1
    Memory: 45.23 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.17.1 - ~/.nvm/versions/node/v18.17.1/bin/node
    Yarn: 1.22.10 - /opt/homebrew/bin/yarn
    npm: 9.6.7 - ~/.nvm/versions/node/v18.17.1/bin/npm
    pnpm: 8.8.0 - ~/Library/pnpm/pnpm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 117.0.5938.149
    Safari: 17.0
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.1.0
    @sveltejs/adapter-vercel: ^3.0.3 => 3.0.3
    @sveltejs/kit: ^1.20.4 => 1.25.1
    svelte: ^4.0.5 => 4.2.1
    vite: ^4.4.2 => 4.4.10

Severity
blocking an upgrade
Additional Information
No response

@jesuscovam apologies for prematurely transferring the original issue to a discussion. After a bit more digging around, I found out SvelteKit is creating a new ReadableStream of the original request body. https://github.com/sveltejs/kit/blob/master/packages/kit/src/exports/node/index.js#L47-L93
I currently lack the knowledge to know if this is the cause of the issue. If it is, I wonder if using a Passthrough (next.js approach) could help with this? https://github.com/vercel/next.js/blob/canary/packages/next/src/server/body-streams.ts#L76-L89

I finally got down to signing up to Stripe and trying to reproduce the issue with the Stripe CLI. It works perfectly with either await request.text() and Buffer.from(await request.arrayBuffer()). It does not seem to be an issue with SvelteKit modifying the request body.
import { json, text } from "@sveltejs/kit";
import { env } from "$env/dynamic/private";
import Stripe from "stripe";

const stripe = new Stripe(env.STRIPE_SECRET_KEY, {
  apiVersion: "2023-08-16",
});

export const POST = async ({ request }) => {
  const sig = request.headers.get("stripe-signature");
  const webhookSecret = env.STRIPE_WEBHOOK_SECRET;

  let event: Stripe.Event;

  try {
    if (!request.body || !sig || !webhookSecret) {
      return text("Client Error", { status: 400 });
    }
    // this works too!
    // const payload = await request.text();
    const payload = Buffer.from(await request.arrayBuffer());
    event = await stripe.webhooks.constructEventAsync(payload, sig, webhookSecret);
  } catch (err: any) {
    console.error(`❌ Error message: ${err.message}`);
    return text(`Webhook Error: ${err.message}`, { status: 400 });
  }

  return json({ event });
};

@eltigerchino did you test this locally with strip cli or in a deployed webhook?

For anyone else coming here looking for answers: If you input the wrong webhook signing secret, the error you get is about the request body.
Really confusing 🫤 make sure you use the local signing secret (printed in the terminal) if you're forwarding webhook events to your local app.


fix: fixes google sheets datasource global search error

When navigating to a google sheets datasource using the global search bar, the app crashes, this was caused due to an improperly placed return code written in the render method of the DatasourceEditorRouter.
Fixes #15012
Fixes #15089

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

How Has This Been Tested?
Manual, Cypress
Checklist:

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

/ok-to-test sha=d17da78

/ok-to-test sha=c39c2d6

/ok-to-test sha=7491c0a

@vivekverma2312 - Can you please verify bug #15012 in this PR's dp & add the Test Plan Approved if it looks Ok? Cypress test is added fine for the scenario.

@ade : Identified an Issue :

Navigating to Gsheet Queries from global search leads user to empty page

This can be treated as a separate issue. @prapullac

/ok-to-test sha=2bbbc5a

/ok-to-test sha=2bbbc5a


Default architecture settings

I am a bit confused by the default architecture selected by OpenBLAS. I built a static version of the library with MinGW and one with Visual Studio. The one built with MinGW crashed (illegal instruction) on an old notebook while the other one works. Is there a difference in the default architecture settings when using GCC vs. MSVC?

MSVC does not support the style of assembly (inline assembly statements, AT&T syntax) used in many of the optimized BLAS kernels, so a MSVC build defaults to TARGET=GENERIC with plain C sources (which has the side effect to make it portable, but also much less performant).
If you want your MinGW build to be portable, compile with DYNAMIC_ARCH=1 (and DYNAMIC_OLDER=1 if you plan to support really old pc hardware) which will include optimized code for several targets with automatic selection at runtime.

Thanks! is this fact documented somewhere?

The README.md describes the DYNAMIC_ARCH option and links to the wiki for building with MSVC and its limitations.
Note that you will want to combine DYNAMIC_ARCH=1 with a TARGET (for all the common code) set to the oldest cpu you expect to encounter, e.g. DYNAMIC_ARCH=1 TARGET=NEHALEM or DYNAMIC_ARCH=1 TARGET=GENERIC, else the common code may again contain instructions that are only supported on the build host cpu.

Thank you for the information.


Filter problems

Closes #183

This is WIP, but at least it's reproducible now.

As can be seen in the filter pipeline test, it's not just blosc/lzf filters, looks like something gets corrupted with the filter pipeline when applying it to the dataset.

@mulimoen Any thoughts where the corruption might happen? Hm..

I am not very familiar with the filter code, but I've had a look at the lzf filter. In here the filter is modified in set_local_lzf which increases the number of elements to three which clashes with the check in parse_lzf which checks
ensure!(cdata.is_empty(), "expected length 0 cdata for lzf filter");

This check should probably be removed or check if 0 or 3?

And I do wonder if nbit filter must also have a larger cdata to store offset and precision

And I do wonder if nbit filter must also have a larger cdata to store offset and precision. The shuffle filter must store the number of bytes for shuffling.

Yep, agreed, and that logic is pretty complicated per-filter (i.e. cdata size may depend on the data itself), and in some cases there's up to around 20 values being stored. I've relaxed the checks so that only the minimum length is verified in the cases where we need to pull the parameters.
Now the failure you see in the filters test is the one where blosc filter parameters are zeroed out.

That is, before we apply the filter to the dataset:
// before applying to dataset (just storing in DCPL)
cdata = [
    0, 0, 0, 0, 9, 1, 5,
]
// after applying to dataset and then extracting it back
cdata = [
    2, 2, 4, 800000, 0, 0, 0,
]

Note that all internal parameters have been filled out now (first 4 values), but the user parameters (last 3) got erased somehow...

Was an actual bug - a single character mistake which essentially disabled all blosc filters 🤣 (hopefully fixed now in baf4ddb - and we'll have to release a version asap so that it actually works)

Interesting, now there's obscure conda-related failures.

Looks like the failures are related to HDF5_PLUGIN_PATH somehow

Any thoughts on how to reproduce/fix this? Hm...

Another thought that I had - don't hide Blosc, BloscShuffle structs etc under #[feature = "blosc"] so that you could read filter pipeline and see it properly (and not as Filter::User).
However, then we need to manually check that filters are available (both cfg!(feature = "blosc") and blosc_available()) when applying the filters to DCPL. Maybe it makes sense to do it regardless.

I tried reproducing in python here: https://github.com/mulimoen/hdf5_py_test/actions/runs/1473774852 but could not get the error to trigger. Maybe h5py has a workaround?

Another thought that I had - don't hide Blosc, BloscShuffle structs etc under #[feature = "blosc"] so that you could read filter pipeline and see it properly (and not as Filter::User).

Would this not depend on BLOSC_FILTER_ID being exactly 32001? This might be a problem for all files created by other libraries. (This is also a breaking change)

Another thought that I had - don't hide Blosc, BloscShuffle structs etc under #[feature = "blosc"] so that you could read filter pipeline and see it properly (and not as Filter::User).

Would this not depend on BLOSC_FILTER_ID being exactly 32001? This might be a problem for all files created by other libraries. (This is also a breaking change)

Blosc filter ID being 32001 is a sort of immutable invariant that we have to accept, I guess... More details here: https://support.hdfgroup.org/pubs/rfcs/RFC_Filters-registration-policy-final.pdf

Ok, I was able to reproduce it, same as one of the failures in CI: macOS, using 1.8.18 from anaconda main channel.
Error: H5Pset_filter(): failed to call private function: can't open directory: .../envs/hdf5-1.8.18/lib/hdf5/plugin

Apparently, there's H5PL* API for managing plugin paths etc, but it's only available on 1.10.1 and later. Before that it just looks at env vars which may be cached or not... I'll give it a try tomorrow to see if anything can be hacked around.

Hm, if setting HDF5_PLUGIN_PATH manually to some obscure folder, it now yields
Error: H5Pset_filter(): failed to call private function: failed to load dynamically loaded plugin

So just setting the env var wouldn't solve it, need to dig deeper.

Ok, interesting - it's adding that weird non-existent user filter that fails sometimes in some conditions
If I remove a line with Filter::user(...), it seems to pass. Wonder then, why doesn't it fail everywhere, hm.

Ok, fixed yet another typo/bug in a573e72 (🤦, having proper tests is a good thing, we need more of them to cover all the new dataset/DCPL stuff...), let's see how this works out now.

Ok, this should be good to go, I think. Hopefully fixes most filter problems.


eduAlgo logo not displaying in About Us section

Logo not displaying in about us section.

Assign me this issue and I'll fix it.

@QAZIMAAZARSHAD this is not the project where the website code is present.


Add indicator what's included in "run all" to list commands

Simple * at the end of the command means what's included in run --all when running runme list or runme beta list.

Review, please, @pastuxso.


Update checkout quantity when checkout lines are deleted

Checkout quantity wasn't updated when the checkout line was deleted with the use of CheckoutLineDelete mutation

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-2507 CheckoutLineDelete doesn't update Checkout.quantity


BE-SPRING-BOOT - move jar copy from jenkinsfile into gradle build

today jenkinsfile:
sh "cp build/libs/${context.componentId}-*.jar docker/app.jar"
gradle:
jar {
archiveName     "....."
}
we should move the cp logic directly into jar of gradle - e.g.
jar {
archiveName     "app.jar"
destinationDir  file("$buildDir/../docker")
}
that way people can run
gradle build
docker build
and then just run it locally :)

@michaelsauter  @ManuelFeller @stitakis  - thoughts? ... we could do this for all quickstarters .. that way people can run the stuff directly on docker .. w/o any changes ... :)


feat(vm-series): add new example with user data bootstrap method

Description
Example for vmseries with bootstrapping with user_data #111
Motivation and Context
Add another example of the VM-Series module usage - this time using the User Data bootstrap method.
How Has This Been Tested?
By running terraform apply -var-file=example.tfvars, like described in the "Usage" section of the README file.
Screenshots (if appropriate)
Terraform deployment:

SSH into the instance, check bootstrap status:

GUI access - disabled user/pass login:

Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes if appropriate.
[ ] All new and existing tests passed.

@migara @michalbil - I've updated the module variables and README.md, and added the pre-commit webhook to the example README. Once Michal merges the outputs change into the VM-Series module, I'll update the one in the example accordingly. Michal - please do not run the pre-commit webhook for your change - I'll do that for both of us. Thanks!

@migara @michalbil - I've merged Michal's changes into develop and adjusted this branch accordingly - please review - and let's merge if thats fine with you.

@migara can we merge this PR now?


In App messages doesn't unfocus input

Hi,
When in app message is sent, library don't remove the keyboard, because of that it looks terrible.
This needs to be fixed from the library level.

yes. because you can't overlay on the keyboard and when it is a modal like in app message it looks ugly.
it was seen on ios i haven't test on android but if there is no logic it will be same.
I can't find it now, but the situation was like this: I'm showing the input with a keyboard and at that time we are triggering in app is visible on top of the viewable area but the keyboard isn't visible still. so it doesn't make sense to have the keyboard opened

any update?

Hi @beqramo, thanks for your patience here and for the reminder. The issue that @mrehan27 created on your behalf has been scoped and we're optimistic about an approach to fix the issue, but have so far prioritized in-app and SDK improvements that have pushed the changes needed here further out.
If our priorities seem wrong or we're missing additional context, would you be open to a quick call to better understand your use case and how your app and flows are impacted?

Hi @beqramo
Good news! The fix for this issue is now available in version 4.0.2. This version of customerio-reactnative also includes support for CDP (Customer.io Data Pipelines). If you haven’t upgraded to version 4.x yet, please refer to our migration guide and quick start guide for assistance.
With the release of this fix, we’re closing this issue. However, feel free to open a new issue if you have any questions!


add knowledge center mysql generated column article

merged in https://github.com/ariga/atlas/commit/c3c9972ec818f50277d6908eeaf455f5be41ac36 (https://github.com/ariga/atlas/pull/955)


Infoj: Group expanding on load

Pull Request Template
Description
Allows `groupClassList: "expanded"' to be added to any member of the group and have the group expanded on load.
GitHub Issue
This PR addresses #1327
Type of Change

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

How have you tested this?
Test in bugs_testing/infoj_order/workspace.json Added groupClassList: "expanded" to the second member of a group and saw that the group was expanded as it should be.
Testing Checklist

✅ Existing Tests still pass
✅ Ran locally on my machine

Code Quality Checklist

✅ My code follows the guidelines of XYZ
✅ My code has been commented
✅ Documentation has been updated
✅ New and existing unit tests pass locally with my changes
✅ Main has been merged into this PR

@AlexanderGeere is this condition required?
&& !Array.from(groups[entry.group].classList).includes('expanded')


Windows DLL ole32.dll not found on Mono

When I try to run the LfMerge skeleton as it currently stands (as of commit 17269b8), I get an exception in FwAccess.cs when it tries to call FdoCache.CreateCacheFromExistingData. Apparently one of the methods deep inside FDO still has a dependency on something COM-related, because SIL.FieldWorks.FDO.IOC.FdoServiceLocatorFactory.CreateServiceLocator () is trying to construct a  SIL.FieldWorks.FDO.IOC.StructureMapServiceLocatorobject, which in turn is calling SIL.FieldWorks.Common.COMInterfaces.LgIcuCharPropEngineClass.Create (), which in turn is calling System.Runtime.Remoting.Activation.ActivationServices.CreateProxyForType (type={SIL.FieldWorks.Common.COMInterfaces._LgIcuCharPropEngineClass}). And that, after a few more calls, fails because Mono can't find the Windows DLL ole32.dll.
Stack trace follows:
System.DllNotFoundException: ole32.dll
  at at (wrapper managed-to-native) System.__ComObject:CoCreateInstance (System.Guid,intptr,uint,System.Guid,intptr&)
  at System.__ComObject.Initialize (System.Type t) [0x00082] in <filename unknown>:0
  at at (wrapper remoting-invoke-with-check) System.__ComObject:Initialize (System.Type)
  at Mono.Interop.ComInteropProxy.CreateProxy (System.Type t) [0x00007] in <filename unknown>:0
  at System.Runtime.Remoting.RemotingServices.CreateClientProxyForComInterop (System.Type type) [0x00000] in <filename unknown>:0
  at System.Runtime.Remoting.Activation.ActivationServices.CreateProxyForType (System.Type type) [0x00047] in <filename unknown>:0
  at at (wrapper managed-to-native) object:__icall_wrapper_mono_object_new_specific (intptr)
  at SIL.FieldWorks.Common.COMInterfaces.LgIcuCharPropEngineClass.Create () [0x00001] in <filename unknown>:0
  at SIL.FieldWorks.FDO.IOC.StructureMapServiceLocator..ctor (StructureMap.Container container) [0x00000] in <filename unknown>:0
  at SIL.FieldWorks.FDO.IOC.FdoServiceLocatorFactory.CreateServiceLocator () [0x00448] in <filename unknown>:0
  at SIL.FieldWorks.FDO.FdoCache.CreateCacheInternal (IProjectIdentifier projectId, IFdoUI ui, IFdoDirectories dirs, SIL.FieldWorks.FDO.FdoSettings settings) [0x0002b] in <filename unknown>:0
  at SIL.FieldWorks.FDO.FdoCache.CreateCacheInternal (IProjectIdentifier projectId, System.String userWsIcuLocale, IFdoUI ui, IFdoDirectories dirs, SIL.FieldWorks.FDO.FdoSettings settings, System.Action`1 doThe, System.Action`1 initialize) [0x0001e] in <filename unknown>:0
  at SIL.FieldWorks.FDO.FdoCache.CreateCacheFromExistingData (IProjectIdentifier projectId, System.String userWsIcuLocale, IFdoUI ui, IFdoDirectories dirs, SIL.FieldWorks.FDO.FdoSettings settings, IThreadedProgress progressDlg) [0x00015] in <filename unknown>:0
  at LfMerge.FwAccess.TryGetFdoCache () [0x00062] in /home/rmunn/code/LfMerge/src/LfMerge/FwAccess.cs:77
  at LfMerge.FwAccess..ctor (LfMerge.ProjectIdentifier proj) [0x0003b] in /home/rmunn/code/LfMerge/src/LfMerge/FwAccess.cs:23
  at LfMerge.MainClass.Main (System.String[] args) [0x00065] in /home/rmunn/code/LfMerge/src/LfMerge/Program.cs:31

@ermshiperete - I assume you've been able to deal with this error; how did you deal with FDO trying to access COM interfaces? Or maybe you didn't encounter this exception at all, and you can run FdoCache.CreateCacheFromExistingData without any problems?

@rmunn You need to source environ from the FW directory before running LfMerge:
cd ~/fwrepo/fw
. environ

@rmunn I suggest that this conversation would be better had on Flowdock prior to posting a bug against LFMerge.  Thanks.


Fix missing zero for version metadata

Follow up of #6293.
Since float lacks 0, This PR replaced it with string.
% ruby -e 'p 0.50'
0.5

The following is an updated manual example.
@@ -918,7 +918,7 @@ EnforcedStyle | `runtime_error` | `runtime_error`,
`standard_error`

 Enabled by default | Safe | Supports autocorrection | VersionAdded |
 VersionChanged
  --- | --- | --- | --- | ---
  -Enabled | Yes | No | 0.5 |
  +Enabled | Yes | No | 0.50 |

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run rake default. It executes all tests and RuboCop for itself, and generates the documentation.

Great catch! I also think we should display - when there's no version data, as I see right now we display nothing, which is a bit confusing.

Sure! I updated it.

Thanks!

Thanks too!


Controller is constructed before route middleware are executed

Version: Laravel 9
PHP: 8.1
The problem that I'm having is that Laravel constructs the controller object and it's entire dependency injected set of parameters and the entire tree of other dependencies too. Before the middleware are run through and that means that middleware can't affect those dependencies by adjusting the request or setting other parameters that would affect how the AppServiceProvider can create the dependencies.
Is there a reason why the Controller is constructed before the route middleware are triggered and passed through? It seems like this is backwards, since the route middleware are supposed to do things based on the route and typically middleware affect how the system will run, THEN the controller executes and does the work.
But if the controller is created first, then all it's tree of dependencies are created too, direct parameters result in objects created, but those objects also have constructors, resulting in more objects being created, etc, etc. This entire tree of objects is created before the middleware has a chance to even do it's job.
This results in my rest api as a system which throws exceptions because one of the dependencies deep in the tree tries to do something that it's not allowed. Something the middleware would prevent by adjusting the request based on circumstances such as permissions or auth capabilities.
So whats the solution to this? I see this issue was talked about since 2016, but I can't think that I'm the only person who thought of this problem.

So what's the solution to this? I see this issue was talked about since 2016, but I can't think that I'm the only person who thought of this problem.

Because the framework allows to prepare the response a Controller construction level. That's why you can add middleware programmatically inside the __construct.
To me, this seems more like a dependency problem rather than Laravel's problem. Detach the logic from the controller middleware and add it after the controller receives the data. No need to do everything at the middleware level.

The middleware problem I'm having has nothing to do with the controller in question though, it's a system level need to adjust the request constructed in order that the dependencies to the controller are constructed in the correct way.
I can't add the middleware into the controller, since the middleware does not care about the controller, it adjusts the objects that are created by the app service provider. There are a couple of controllers that also use the same dependencies.
The issue that I have, is that route middlewares, don't actually seem to exist. You can define middlewares on routes, but those middlewares are run AFTER the controller construction, hence, ALL route middlewares are in fact, controller middlewares.
I want a middleware, which is connected to the route requested, to execute and do it's job, before the controller is run, before any of the dependencies are created.
I understood from the docs that there are three sets of middleware

global middleware
route middleware
controller middleware

but seems that all route middleware are executed after the construction of the controller, then they are not route middleware, because they are not in the middle of anything. They are always executed AFTER the controller. That isn't the purpose of a middleware

This pseduo-code is an illustration of the problem
class EnableServiceHeaderMiddleware {
    public function handle(Request $request, Closure $next) {
        config()->set('is_public', true);
        return $next($request);
    }

// service_headers is mapped to the EnableServiceHeaderMiddleware class
$router->group(['middleware' => ['service_headers', namespace...etc, etc], function(Router $router) {
    $router->get('/public', 'PublicController@getData');
});

class PublicController extends Controller {
    public function __construct(DepA, BrokenDepB, DepC) { ... }
}

class AppServiceProvider {
    public function register() {
        $this->app->bind(BrokenDepB::class, function() {
           $c = config('is_public') == true ? config('public_a') : config('private_b');
           return new BrokenDepB($c);
        });
    }
}

So I guess the heart of the problem, is how can I create a fully dependency injected controller, that depending on the route that controller is executed on, will construct the BrokenDepB object, with the correct configuration needed for that route, based on it's requirements.
I can't adjust BrokenDepB because it's used in public AND private scenarios. It needs to allow for both. I can't also create two subclasses for PublicBrokenDepB and PrivateBrokenDepB either, because I've noticed in the class heirarchy of some dependencies, the controller is not the one creating the dependency, but a dependency down in the tree of other objects created by another controller. So the problem is I have no direct connection with all the instantiations of that object.
So I need to be flexible, to use a configuration value to adjust how that class will be created, no matter where in the heirarchy tree it will be.
This problem would be solved, if route middlewares triggered SEPARATELY from controller middlewares, like this
Global middleware -> router -> Route middleware -> Controller Construction -> Controller Middleware.
It seems that Route middleware and Controller middleware are being lumped into one group, executed AFTER the controller is constructed. I think that's a mistake. That's what I'm trying to discuss here.

I'm just gonna leave https://github.com/laravel/framework/pull/40165#issuecomment-1001806578 and https://github.com/laravel/framework/pull/40306 and https://github.com/laravel/framework/pull/40675 here.
I've tried fixing this issue as it had bitten me multiple times in the past and unfortunately every attempt got rejected/reverted in the end, mostly due to concerns regarding backwards compatibility.
IMO there's no way around this, at some point in the future the feature of being able to add middleware via the controller constructor needs to go away as that feature is the reason why all these bugs are happening. And that's exactly one of the reasons we have a major version concept in SemVer, so IMO the sooner this happens the better.
At the time when those PRs were a thing I don't believe the maintainers understood just how broken this behavior is and how big the impact is across the community (as it was just me and a few other people that were pushing for this to be fixed) so the decision was that the BC cost outweighed the benefits. Hopefully with more and more issues popping around regarding this problem that decision is gonna be reevaluated especially as using dependency injection gets more popular within the Laravel community.

@christhomas you can inject dependencies on controller methods, they will be run after any declared middleware:
single action controller
class PublicController extends Controller {
    public function __construct() {
        // middleware declaration, authorization, etc...
    }

    public function __invoke(DepA $depA, DepB $depB, DepC $depC) {
        // ...
    }
}

multi-action controller:
class PublicController extends Controller {
    public function __construct() {
        // middleware declaration, authorization, etc...
    }

    public function index(DepA $depA) {
        // ...
    }

    public function create(DepB $depB) {
        // ...
    }

    public function store(Request $request, DepC $depC) {
        // ...
    }
}

@X-Coder264

in the future the feature of being able to add middleware via the controller constructor needs to go away

I hope not.
Might be personal preference, but in projects with gazillion routes spread over many route files, I prefer to declare middleware in the constructor, so they are close to where it affects code. I also prefer to keep my route files as clean as they get.
To me it is much easier, and makes more sense, to look at a controller constructor and see all needed middleware close to the method I am working with, to skim a very long route definition file. It also helps in code review, it is one less place to look when refactoring, and it is much easier to spot which parameter a middleware that accepts parameters is using when they are close to the route. Not just easier to spot, but easier to reason and understand why that parameter might be different to that particular route.
I always advocate for declaring middleware on a controller's constructor when showing people Laravel.
Also, resolving dependencies on the controller method seems, to me, to be a  better solution:

On single action controllers (ones using __invoke) it actually doesn't matter, and there is no reason to add state to the class object just to hold the dependencies for a single method that can require its own dependencies.
On multi-action controllers, injecting dependencies by methods helps avoiding instantiating unnecessary dependencies that can be costly to instantiate when calling a method that won't need them.

One last thing, before the AuthorizesRequests, that streamlines adding the can middleware, was only available as a trait. Now I believe one can define them on the route definition (I am not sure), but in a lot of projects this helped pushing middleware definition to the controller's constructor.
I understand some people says "dependency injection should be done in the constructor...". Well, I believe there is nothing wrong in providing dependencies to a method if only that method will use it, and also - in my opinion - Controllers classes are not a typical class on a OOP sense. They are short lived, there is no sense on them to hold state, and their purpose is to connect the pieces needed to resolve a response from a request. I usually think of them more like lambdas, or plain functions.
And lastly when we declare closure routes, the dependencies are passed to the anonymous function parameter list. Having dependencies passed to a controller method instead to a constructor looks more consistent with this behavior.

being able to add middleware via the controller constructor needs to go away as that feature is the reason why all these bugs are happening

Which bugs? It is how the framework request workflow works. Just because something does not work as you expect that does not mean it is a bug.
I understand one might want something to work differently. I actually have things I preferred to be different in behavior in other parts of the framework. But I can live with those for the benefits Laravel brings to the table.
In my opinion, the trade-off of using a framework is exchanging the time to solve trivial day-today tasks with adapting to some conventions, and - sometimes - to workflows we really wished would be different.
And let's agree on something, Laravel helps to solve way more than the trivial things a web-app needs.
But that is definitely no a bug per se. Sorry for the long post, no hard feelings =)

@X-Coder264

in the future the feature of being able to add middleware via the controller constructor needs to go away

I hope not.
Might be personal preference, but in projects with gazillion routes spread over many route files, I prefer to declare middleware in the constructor, so they are close to where it affects code. I also prefer to keep my route files as clean as they get.

Nobody said that those declarations need to be removed from the controller. I said those declarations need to be moved away from the controller constructor - constructor being the key word here as it means that the controller must always get instantiated in the "gathering of middleware for the route" step of the request lifecycle. If you take a look at the PRs that I've linked you can see that my proposal was to move those calls from the constructor to a static method (within the same class). During the discussions attributes/annotations were suggested for this too, especially since we now have native support for them in PHP. Either way, every approach that would properly fix this issue would be a breaking change.

Also, resolving dependencies on the controller method seems, to me, to be a better solution:

It doesn't even matter whether you think method injection is better than constructor injection. Without even looking at all the other issues that currently affect the constructor injection approach in controllers (which were described in the linked PRs) the fact that the behavior between these two injection approaches is different/inconsistent is an issue in and of itself.

being able to add middleware via the controller constructor needs to go away as that feature is the reason why all these bugs are happening

Which bugs? It is how the framework request workflow works. Just because something does not work as you expect that does not mean it is a bug.

These bugs: https://github.com/laravel/framework/pull/40306#issuecomment-1008126705 and https://github.com/auth0/auth0-PHP/issues/543
And these are just the examples I could think of the top of my head that I've personally run into multiple times.
Every bug in the framework that was ever fixed was how the "framework worked" up until the point at which the bug/behavior was fixed so that statement makes no sense IMO.
To be fair, as far as this goes, nobody can convince me that this is not a problem. As an example, getting a completely different guard depending on whether you've used constructor vs method injection cannot be described as anything other than a bug (especially since you can't even catch that problem by writing tests) so at worst the code reaches production and it doesn't work because the guard keeps returning null instead of the logged in user. Method injection is just a workaround, the issue/bug with constructor injection is still there.
So if you are "lucky" your application immediately blows up due to an exception (like the author of this issue mentioned) during development, if you are not lucky and you get an issue like the guard one which does not throw an exception and you have broken behavior in your app that you are most likely completely unaware of until your QA department (or potentially even worse - end users on production) report the problem to you. And then, especially if you are not an experienced developer and/or not familiar with the internals of the Laravel middleware gathering logic you are scratching your head because you can't figure out why the guard that is supposed to return a logged in user is all of a sudden constantly returning nulls.

If you take a look at the PRs that I've linked you can see that my proposal was to move those calls from the constructor to a static method (within the same class)

I did. Very carefully. Now and then. And the comments made myself even surer of my intance on this.
It is very odd you assume I didn't. Maybe you assume I just had to read the comments you made or the ones supporting your personal preference.
As you assumed something out of the blue about me, I think it is safe to assume you don´t quite remember the discussion had strong arguments with a different and more compelling argument. It is natural to have selective memory and tend to remember only the reality we wish it happened, but unfortunately not always the reality is the same as we wished.
See this comment (linked below), which you seem to have missed or forgotten, which even has a diagram to help to illustrate for those who can´t follow only with words. Some excerpts from that comment, (which I, and as you can see others too, strongly agree):

[...] biggest issue with PR https://github.com/laravel/framework/pull/40397 is that it tries to couple middleware with controller instantiation.
However, that coupling is problematic because:

middleware are, by definition, strongly coupled to the current request.
controller instantiation is (and should be) strongly decoupled from the current request as it happens only once for applications that are kept alive (Octane, tests, etc.).

...
You just need to add your dependency injections to the controller's __invoke method instead of its __construct method. And that's not even a workaround, that does make sense because:

Dependency injections from the __construct method will be cached throughout all requests received regardless of the middleware it registers.
Dependency injections from the __invoke method will depend on the current request and will be affected by the middleware it went through.

So we have two distinct ways of registering dependencies based on the application's lifecycle which is perfect.

https://github.com/laravel/framework/pull/40675#issuecomment-1023415277

It doesn't even matter whether you think method injection is better than constructor injection. Without even looking at all the other issues that currently affect the constructor injection approach in controllers (which were described in the linked PRs) the fact that the behavior between these two injection approaches is different/inconsistent is an issue in and of itself.

It also doesn't even matter whether you think constructor injection is better than method injection.
This is a (my) personal opinion:
There is no sense on adding a constructor dependency to a object state just be used by a single method when the object is short-lived and meant only to act as a short-lambda connecting two dots into the request cycle
This is also a (your) personal opinion:

Method injection is just a workaround, the issue/bug with constructor injection is still there.

All the "issues" you mentioned can be solved with a note in the docs.
Unlike civil engineering, and other engineering, that many times, due to regulation requirements, have to follow strict standards, software engineering does not have an agreed set of standards on how things should be done.
Most best practices are just "personal opinions". And arguing Laravel should follow the behavior because "other frameworks do like this" (see your past comment linked below), is not actually a compelling argument to change how things have worked across the years just to satisfy a edge case that can be solved with a note, or to satisfy your personal preference or "opinion".
Also using the argument That's what users expect because that's how it also works in other frameworks, to back up your own preference, when this works the way it works on Laravel for many, and many years, is also not a compelling argument (also in the same comment linked below).
https://github.com/laravel/framework/pull/40397#issuecomment-1022057837

Even Taylor acknowledged that this is a bug, which is why he merged a fix for it (which was later reverted like I've already mentioned due to BC reasons).

Well, so many things here:

Even Taylor acknowledged that this is a bug

I would appreciate if you can link where he says it is a "bug", or that this behavior needs to be fixed (which could imply it is a bug).
On every discussion I can find, he at most says he is open to alternatives. He propose using an event as a better alternative, and even expresses, more than once, the risks of breaking changes for "put the breaking change on people because for 99% of Laravel devs it's most definitely not worth it IMO" (link below)
https://github.com/laravel/framework/pull/40306#issuecomment-1008101721

which is why he merged a fix for it

Being the first affirmation false, you can't assume it was a justification for he merging anything. On my understanding he changed on good faith the BC would minimal, after much insistence, even after trying to persuade that using events would be a better solution.
https://github.com/laravel/framework/pull/40165#issuecomment-1004269218

which was later reverted like I've already mentioned due to BC reasons

Well, one might interpret the justification on the reverting PR differently, for instance:

This PR reverts https://github.com/laravel/framework/pull/40397. We've rethought the changes made in that PR and, at the moment, are not comfortable making these changes without knowing all implications. These changes can potentially have large implications on users, apps and packages.

I concede that "Large implications" could be related to BC.
But one might agree that the value proposed by the changes were not sufficient to justify changing a well-defined behavior most developers are comfortable with. Which is slightly different than a BC done on the will of improvements. And how would a revert before a release have caused any BC?
Actually the only real comment regarding the justification tried to appeal for those changes is when Dries states the arguments are overwhelming and asks for a minimal description on a next attempt:
https://github.com/laravel/framework/pull/40675#issuecomment-1113422171
Prior art
One last thing. As you assumed I didn't read any of the discussions you linked, I guess you won't bother if I assume you are, in good faith, not aware of past discussions regarding of injecting dependencies into the constructor.
Prior to Laravel 5.3.4, there as a common pattern of expecting the session and request to be available at a controller's constructor, just like you are pushing now.
Since Laravel 5.3.4 this behavior was changed, and the Controller@middleware method was added as a workaround for those who wanted a way to still access application state inside a controller's constructor. You can see the upgrade path here:
https://laravel.com/docs/5.3/upgrade#5.3-session-in-constructors
And this interesting excerpt from the official docs linked above:

In previous versions of Laravel, you could access session variables or the authenticated user in your controller's constructor. This was never intended to be an explicit feature of the framework.

There were discussions about either a controller constructor should have access to application state or not, and at the end the decision was to introduce the breaking change linked above, while providing a workaround (closure-based middleware defined in a controller's constructor), as accessing application state in a controller's constructor ".. was never intended to be an explicit feature of the framework".
These are some PR discussions regarding this matter:

https://github.com/laravel/framework/pull/15080
https://github.com/laravel/framework/issues/15072

And a complementary blog post:
https://josephsilber.com/posts/2017/01/23/getting-current-user-in-laravel-controller-constructor
Also, as you attributed an opinion to Taylor without providing any link to it, in PR #15072 his opinion seems very clear:

...  from a design perspective it's very bad to use session or auth in your constructor and here is why: no request has happened yet and session and auth are INHERENTLY tied to an HTTP request. You should receive this request in an actual controller method which you can call multiple times with multiple different requests. By forcing your controller to resolve session or auth information in the constructor you are now forcing your entire controller to ignore the actual incoming request which can cause significant problems when testing, etc.
Most of the confusion on this issue stems from a failure to realize that sessions and auth are specifically tied to http requests and cookies and it's impossible to access those things until a request has actually entered your application. The very fact that you can not go into the command line and instantiate your controller via the "tinker" command should be a huge red flag that the controller is not constructed properly.

https://github.com/laravel/framework/issues/15072#issuecomment-242769373
Of course I will understand if his opinion changed since 2016. But this is an actual opinion he shared related to the matter, not a personal interpretation based on my personal wishes or preferences.
Also I am not saying you are lying, as you are a long time contributor you might have had a personal talk with him. I am just saying I could not find any comment that back up this opinion you attributed to him.
Epilogue
I agree maybe we need to document better that application state is not available in a controller's constructor. And that this is intended behavior, and how the framework works.
Having this documented would solve the "issues" you linked that third-parties might have when integrating with Laravel.
A mechanical can expect that an engine works the same as they are used to work with other engines. But if there is a manual stating the differences, they won't fight against it due to personal preferences.
This is absolutely not a bug, and using method injection is absolutely not a "workaround".
Even Symfony, that you mentioned to back your personal opinion, allows method injection along with property injection these days.
So following your idea of "we should do what others are doing", maybe we could propose adding property injection, which "in my opinion" does not bring enough value compared to the hassle implementing and maintaining it.
But as I stressed, that is my opinion. If, and when, added to the framework I could try to present my arguments, but as long it is accepted, I will also accept it and deal with it, regardless of my personal instance.
Appealing to labeling "method injection a workaround", implying with a constructed narrative that constructor injection is better in any form, is the kind of purism that reminds me of the discussion around if Façades are true Façades in regards to design patterns, or if they should be named proxies instead.
As I said, there is no agreed standards on software engineering on how to best built things. And personally I think this is better than forcing a single way of thinking that foster innovations.
Not agreeing with a particular behavior is fine. Proposing changing a behavior you don't agree with is fine.
Labeling behavior you don't agree with as bugs is not fine.
Trying to argue with fallacies (I noticed appeal to authority,  ad hominen, bandwagon, and casual fallacies) without presenting compelling benefits on why such a structural change should be accepted is not fine.

It's not "very odd" that I assumed that you haven't read that as you were asking "which bugs" in the previous comment which is the reason why I've linked you the post which explains them. Unfortunately I don't remember every Github username that was part of every Github discussion that I was ever part of.
I didn't say that Taylor said it was a bug. I said he acknowledged that it was a bug and he did so by merging a fix for it. You can't fix something that is not broken, right? :) If that wasn't a bug/issue the PR wouldn't have been merged, it would've been closed instead. "We do recognise that this needs a better approach. We'd like to take our time to investigate and work on a solution ourselves" (https://github.com/laravel/framework/pull/40675#issue-1116283290) - also a quote from the maintainers -> if there is no issue/bug why would they talk about working on a "solution"? In order for there to be a solution there needs to be a problem/bug/issue first.
"a well-defined behavior most developers are comfortable with" -> this behavior is the exact opposite of "well defined" as it is not "defined" at all anywhere in the documentation nor would any person that is new to Laravel expect this behavior. People usually get to know this behavior when they run into a bug which they have to debug because of this. If this behavior was so well-defined this Github issue would have probably never existed. The only people that are actually familiar with this behavior (excluding those who run into issues and have to debug and find out about this issue that way) are the maintainers themselves, other people who just love to deep dive into the framework internals for fun and people who are constantly reading all Laravel Github issues and PRs. That excludes basically most of the framework users so most developers are not comfortable with this behavior as your average Laravel developer does not even know about this behavior (the average Laravel developer does not even use any kind of dependency injection, they use facades or global helpers instead because that's what is used in 99% of the Laravel documentation). Also it is my opinion that "fixing" this by adding a warning to the documentation is not adequate.
I don't see how Taylor's comment from 2016 and the "you could access session variables or the authenticated user in your controller's constructor, this was never intended to be an explicit feature of the framework" sentence applies here. I don't want to access session nor get the authenticated user in my controller's constructor, I actually believe that to be an anti-pattern so I'm glad that the Laravel explicitly said that that was not an intended feature. What I want is to be able to reliably get the authenticated user in a controller action method while still being able to use constructor dependency injection.
You can use constructor dependency injection in all classes including controllers. It doesn't make sense to all of a sudden say "you can use constructor dependency injection in controllers, but you can't use it for X, Y and Z scenarios". A feature either works or it doesn't so IMO you should either be able to always use it in a controller constructor or not.
I brought up Symfony back then because I thought that was a thing that they are doing better than Laravel currently does (the controller is a service that is resolved out of the container like any other without any catches and "edge cases" like the ones we are discussing here). Guess what, I think that property injection is an anti-pattern that Symfony shouldn't have merged as a feature and should never be used as there's already constructor and method injection available so that debunks your "we should do what others are doing" statement about me. I've used various frameworks over the years (both publicly available ones as well as in-house built ones) so I don't bring up other frameworks because I think Laravel should blindly follow anyone, I only bring up very specific things when I believe that those things are better solved elsewhere.
Most of your comment is focused on trying to convince me that this is expected behavior instead of discussing the substance of the problem which you basically label as non-existent even though it is obvious (as evidenced by the existence of this Github issue and all of the previously linked PRs) that a problem exists. Even on both a purely technical and logical level it doesn't make sense to instantiate the controller before we know that the controller logic will even have to be executed (e.g. if the middleware already returned a response or if the middleware throws an exception like for example the authentication and authorization middleware do when the user is not logged in or when they don't have permission to access the resource). So it's no wonder why the author of this Github issue is asking why is this behaving in this way.
 I don't use them in my projects nor does naming affect functionality. And that was/is the advertised beauty of Laravel - it doesn't force you to use facades nor global helpers nor dependency injection. But all of a sudden you are telling me that I should use method injection in controllers instead of constructor injection and that's why I consider that a "workaround" and why I consider this to be a bug/issue, as this actually affects me and a lot of other developers.
One other advertised beauty of Laravel is DX. Having such an inconsistent constructor dependency injection behavior which is not well known at all definitively negatively impacts DX.
This is probably gonna be my last reply on this topic as I've already spent too much time and energy on this topic, trying to make the framework a better tool for every user and trying to find a solution which would be a compromise so that the root issue gets fixed while keeping both sides happy.

You can't fix something that is not broken, right? :)

Laravel is always open to merge different ways to complete a task. From the discussion on the merged PR it is clear it was merged on good-will to address the request, but all the times the concern on adding a edgy-case that could led to many apps bring broken was expressed.

If that wasn't a bug/issue the PR wouldn't have been merged, it would've been closed instead.

A lot of PR are merged to add new features, to add new ways on doing something, to improve DX, to remove deprecated code.
Laravel has a good-will tendency to embrace lots of opinions. And when something goes wrong it gets reverted. This also happens commonly.
I could rephrase your argument as : "If it was a true fix it would not have been reverted, right?"
There are many features, such nested filed validations, that took many minor versions to get it right. And although reverting was considered, there was energy and effort on trying to solve the issue and make an improvement.
On my understanding is that they are open for improvements. But if it was an issue I am sure it would have been resolved by now.

I didn't say that Taylor said it was a bug. I said he acknowledged that it was a bug and he did so by merging a fix for it.

You're right. For me as a foreigner both statements seems similar to me. But I see the difference and I apologize for stating this.
My intention was argue on the later. But late justification is not a good argument either. And I don't like when people states someone said something they didn't.
I am sorry for not reviewing carefully this part of my reply. And I hope you can apologize me for this part.

You can use constructor dependency injection in all classes including controllers.

That is not actually true. Well the container is capable of trying to create a not bound object , this is correct.
But in Laravel, jobs have their dependencies inject on its handle/__invoke method, while the constructor is reserved for passing state variables to be used on the job execution.
The same is true for mailables, notifications, and other components.
One could argue it is more idiomatic in Laravel to have a execution dependency injected on a method and not on a constructor.

don't understand why third party libraries are brought up when this issue is being discussed

I brought it up because that was actually the single real issue with any impact you linked before. All the other links were PR trying to change the behavior.

But all of a sudden you are telling me that I should use method injection in controllers instead of constructor injection and that's why I consider that a "workaround" and why I consider this to be a bug/issue, as this actually affects me and a lot of other developers.

Well, nowhere in the documentation says you can't use dependency injection on jobs classes. But if one tries, and the class is complex enough, it will error on serialization.
What I said, or at least what I want to argue, is that my understanding is that controllers are to be seen as state-less lambdas that connects the dots on a request/response cycle. In that sense it is more logical to inject its dependencies on execution than on instantiation.
If for example, the business logic on the example presented in this issue was extracted to a job/action, and this job or action (I am calling action a synchronous job), gets dispatched from the controller, the dependency injection of this job would happen after the request arrived the controller and all the middleware had already run, there would be no such issue.
I am not suggesting or imposing a way to how one should structure their code. As I said software engineering does not have agreed, or at least regulated, standards to follow.
But in the same sense you stating that some way of doing things needs to go away (see citation below), or that implying things should be done in a way and if done in another it is surely a workaround, is not a reasonable thing, and is "all of a sudden you are telling me that I should" do things the way you prefer, and calling other perfect reasonable ways - even explained with diagrams - as workarounds.
It seems, in my sole opinion, you are forcing your way into others and is not open to alternatives. And I am sorry, but this is something I would not like to see in Laravel, or a thing I think will improve any DX on the framework.
Again, a note in the docs that dependency injection should be done in the methods, such as it is currently done in:

jobs
mailables
notifications
Commands (can be done on the constructor too, but it is common to see examples of this done in the handle method)
View class based components
and other components

My argument on "a well-defined behavior most developers are comfortable with", is based on framework consistency across components, and not on personal preference.

This is probably gonna be my last reply on this topic as I've already spent too much time and energy on this topic

Me too. I hope you don't think this is personal, it is not.
To me controller classes are to be considered like a "super" closure, a way to decouple writing all your app on the route file. In that sense I don't see a reason why it should hold any state.
And to me, and I think to many others, constructor injection is primarily to set an instance state.
But I think it is better we agree on disagree. My contend was with statements like:

in the future the feature of being able to add middleware via the controller constructor needs to go away

As you said Laravel is known for its DX.
And keeping the ability to define middleware the way they currently are, and seeing method injection as a logical thing to do, and not "a  workaround", is an opinion I, at least one more developer (the one I linked their comments), and I believe many others, are comfortable with and would not want it to go away due a purist discussion on how things are better done or should be done.
My suggestion is still adding a note on the docs, and call it a day.
But if you can find a full backwards way to keep things the way they current are, which again is not a bug, while avoiding this behavior you don't like, or at least don't seem to find correct, I will totally support it.

@X-Coder264 I sent PR #44192 as a proof of good-will to propose a middle-ground solution that I think will solve the issue you described while keeping changes a minimal.
If you can review it, I would really appreciate.
Thanks for all the insights, and I hope any contends are kept in the realm of the ideas an not personal.

Hi everyone. I'm very sorry but this issue is just too much for me to take on and read through. Afaik as I can tell from glancing through it I can only say that this is the current expected behavior. I see @rodrigopedra has sent in a PR to change this behavior in Laravel v10. Let's see what Taylor says there.

Hey guys, thanks for the replies. Sorry I'm late back to this cause I've been busy at the weekend.
I've read the first couple of lines of #40165 and this problem of being able to adjust the application state based on tenancy is the exact same problem that I've got. I need to adjust the app state based on the route, but the controller gets dependencies whilst when constructed, take the wrong state because the middleware runs AFTER the controller gets constructed. That actually is the shortest explanation of my problem I've been able to make so far.

From what I can see, #44192 is exactly what I was looking for, what do you think @X-Coder264 ?

He replied in that thread. That PR does look good. I haven't been able to review it in depth but it seems to nicely solve the problem that all our PRs have tried to solve in the past.

Hey guys, I've been carefully reading the thread and the PR, yet I struggle to make it out of my issue. So, I created a middleware to limit the data a connected user has access to by adding global scopes depending on some informations:
public function handle(Request $request, Closure $next)
    {
          if (auth()->user()?->organization_id) {
              User::addGlobalScope(new OrganizationScope(auth()->user()->organization));
          }

        return $next($request);
    }

The middleware is added to the 'auth.group' middleware group in Kernel.php which is used in web.php:
Route::middleware(['auth.group'])->group(function () {
  Route::resource('users', UserController::class);
});

Then in the controller, I would expect a user to get a 404 when trying to see a page of a user he has no rights to. But the $user is retrieved before the middleware applies the global scope.
public function show(User $user, Request $request) {
  // dd($user); // <= This actually contains the User model! It shouldn't, of course.
  // dd(User::find($user->id)); // <= null, as it should!
}

So, the dependency is apparently calculated before the middleware is applied. That's how I got to this thread. And I can't make sense out of it about how I could have that middleware run when I want it.
Before that I was applying the global scopes at the Model level, in the booted function (as shown in the docs). But I had lots of issues with that - namely, accessing a relationship from there to check what is allowed or not is problematic, as the relationship call will look for something in the Model itself, and said model is not ready since it's booting. For example, checking a relationship of the connected user on the User model has to be done with a direct query to the db, that will be ran every time the model is called... Not good.
Anyway, I like the middleware approach as it is a clean way to deal with rights as well, I think. Any recommandation?


[SUGGESTION]

Can you make it so you can add decorations to the particles it makes so you don't have to do that your self

Good feature request, thank you. Will not be added in v1.0 because of feature freeze but manipulation of particle properties is planned for future versions.
Added 'future' label

Wait... this actually is gonna get in? (Plus i don't remember posting this at first (I was about to post this again))


Verify JWT signature

Feature
Why is this feature being added?

Since we're looking at the JWT for some features on the site we can add a bit of security by verifying the signature of the JWT and removing the cookie if it's not valid. I think we should be able to do this with RSA. This will require a change on the backend.
What should your feature do?
In src/shared/utils/cookieHelper.js validToken() add some code that verifies the signature of the JWT. We'll also have to keep the public cert in sync.

This could get handled in #329  - did you want to assign yourself to this @sethbergman ?

Will implement auth via jwt in new repo


[WIP] CLI refactoring

[x] Relative imports
[x] Better naming for functions
[x] Move usage of pretty_print_stats to the loop with event handling, cleanup main
[x] Add docstrings
[ ] Add more tests to cover cases found by mutmut
[x] Fix & update tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@c28cb9b). Click here to learn what that means.
The diff coverage is 100%.

@@           Coverage Diff           @@
##             master   #180   +/-   ##
=======================================
  Coverage          ?   100%
=======================================
  Files             ?     18
  Lines             ?    838
  Branches          ?    116
=======================================
  Hits              ?    838
  Misses            ?      0
  Partials          ?      0

Flag
Coverage Δ

#unittests
100% <100%> (?)

Impacted Files
Coverage Δ

src/schemathesis/models.py
100% <100%> (ø)

src/schemathesis/cli/__init__.py
100% <100%> (ø)

src/schemathesis/runner/__init__.py
100% <100%> (ø)

src/schemathesis/cli/output.py
100% <100%> (ø)

src/schemathesis/runner/events.py
100% <100%> (ø)

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 c28cb9b...f7b308f. Read the comment docs.


Add support for relative refs in spec

Fixes #254
Fixes #967
This PR fixes the very long-standing issue of being able to handle relative references, which allows users to split their specification into multiple files.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

16 of 16 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 92.325%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
3260

Relevant Lines:
3531

💛  - Coveralls

Cool, does Connexion include an example showing how to split a JSON or YAML spec into multiple files?

We don't have an explicit example or documentation on this, since it works with the default way to spit yamls (I just tested and can confirm it works as intended).


Error while converting op of type: Conv. Error message: provided number axes -1 not supported

🐞Describe the bug
In converting the PyTorch pretrained Progressive GAN model to CoreML (https://pytorch.org/hub/facebookresearch_pytorch-gan-zoo_pgan/), I am encountering a fatal error in the onnx to coreml conversion step. See below for the trace and a simple end-to-end script that goes from PyTorch to CoreML that reproduces the issue both locally and in a Google Colab notebook environment.
Trace
This is the output from my conversion script, with the final part being the CoreML crash.
WARNING:root:TensorFlow version 1.15.0 detected. Last version known to be fully compatible is 1.14.0 .
Using cache found in /Users/davidkosslyn/.cache/torch/hub/facebookresearch_pytorch_GAN_zoo_hub
Loading default model : celebaHQ-256
Average network found !
input shape: torch.Size([1, 512])
GNet(
  (scaleLayers): ModuleList(
    (0): ModuleList(
      (0): EqualizedConv2d(
        (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
      (1): EqualizedConv2d(
        (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
    )
    (1): ModuleList(
      (0): EqualizedConv2d(
        (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
      (1): EqualizedConv2d(
        (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
    )
    (2): ModuleList(
      (0): EqualizedConv2d(
        (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
      (1): EqualizedConv2d(
        (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
    )
    (3): ModuleList(
      (0): EqualizedConv2d(
        (module): Conv2d(512, 256, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
      (1): EqualizedConv2d(
        (module): Conv2d(256, 256, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
    )
    (4): ModuleList(
      (0): EqualizedConv2d(
        (module): Conv2d(256, 128, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
      (1): EqualizedConv2d(
        (module): Conv2d(128, 128, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
    )
    (5): ModuleList(
      (0): EqualizedConv2d(
        (module): Conv2d(128, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
      (1): EqualizedConv2d(
        (module): Conv2d(64, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
      )
    )
  )
  (toRGBLayers): ModuleList(
    (0): EqualizedConv2d(
      (module): Conv2d(512, 3, kernel_size=(1, 1), stride=(1, 1))
    )
    (1): EqualizedConv2d(
      (module): Conv2d(512, 3, kernel_size=(1, 1), stride=(1, 1))
    )
    (2): EqualizedConv2d(
      (module): Conv2d(512, 3, kernel_size=(1, 1), stride=(1, 1))
    )
    (3): EqualizedConv2d(
      (module): Conv2d(512, 3, kernel_size=(1, 1), stride=(1, 1))
    )
    (4): EqualizedConv2d(
      (module): Conv2d(256, 3, kernel_size=(1, 1), stride=(1, 1))
    )
    (5): EqualizedConv2d(
      (module): Conv2d(128, 3, kernel_size=(1, 1), stride=(1, 1))
    )
    (6): EqualizedConv2d(
      (module): Conv2d(64, 3, kernel_size=(1, 1), stride=(1, 1))
    )
  )
  (formatLayer): EqualizedLinear(
    (module): Linear(in_features=512, out_features=8192, bias=True)
  )
  (groupScale0): ModuleList(
    (0): EqualizedConv2d(
      (module): Conv2d(512, 512, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
    )
  )
  (leakyRelu): LeakyReLU(negative_slope=0.2)
  (normalizationLayer): NormalizationLayer()
)
Converting model to ONNX...
Exported model progan.onnx has been tested with ONNXRuntime, and the result looks good!
Converting to CoreML...
1/278: Converting Node Type Pow
2/278: Converting Node Type ReduceMean
3/278: Converting Node Type Add
4/278: Converting Node Type Sqrt
5/278: Converting Node Type Div
6/278: Converting Node Type Mul
7/278: Converting Node Type Reshape
8/278: Converting Node Type Gemm
9/278: Converting Node Type Mul
10/278: Converting Node Type LeakyRelu
11/278: Converting Node Type Shape
12/278: Converting Node Type Gather
13/278: Converting Node Type Unsqueeze
14/278: Converting Node Type Concat
15/278: Converting Node Type Reshape
16/278: Converting Node Type Pow
17/278: Converting Node Type ReduceMean
18/278: Converting Node Type Add
19/278: Converting Node Type Sqrt
20/278: Converting Node Type Div
21/278: Converting Node Type Mul
22/278: Converting Node Type Conv
Traceback (most recent call last):
  File "repro.py", line 43, in <module>
    image_output_names=['output'])
  File "/Users/davidkosslyn/anaconda3/lib/python3.7/site-packages/onnx_coreml/converter.py", line 625, in convert
    _convert_node_nd(builder, node, graph, err)
  File "/Users/davidkosslyn/anaconda3/lib/python3.7/site-packages/onnx_coreml/_operators_nd.py", line 2370, in _convert_node_nd
    return converter_fn(builder, node, graph, err)
  File "/Users/davidkosslyn/anaconda3/lib/python3.7/site-packages/onnx_coreml/_operators_nd.py", line 524, in _convert_conv
    builder, node, graph, err)
  File "/Users/davidkosslyn/anaconda3/lib/python3.7/site-packages/onnx_coreml/_operators_nd.py", line 70, in _add_conv_like_op
    return err.unsupported_op_configuration(builder, node, graph, "provided number axes {} not supported".format(rank))
  File "/Users/davidkosslyn/anaconda3/lib/python3.7/site-packages/onnx_coreml/_error_utils.py", line 60, in unsupported_op_configuration
    self.rerun_suggestion)
TypeError: Error while converting op of type: Conv. Error message: provided number axes 1 not supported
 Please try converting with higher target_ios.
You can also provide custom function/layer to convert the model.

To Reproduce
This below script will pull the pretrained model, convert to onnx and from onnx convert to coreml. You can also use this directly on a colab notebook that also reproduces the issue: https://colab.research.google.com/drive/126k3OL3378IiNPO8NmFHuPq2BhwKb404#scrollTo=kE8VYX3n4-14.
import onnx
import onnxruntime
import torch.onnx
import numpy as np
from onnx_coreml import convert
import sys

print(f"Torch version: {torch.__version__}")
print(f"Onnx version: {onnx.__version__}")
print(f"onnxruntime version: {onnxruntime.__version__}")
print(f"Python version: {sys.version}")

NAME = "progan"
full_network = torch.hub.load('facebookresearch/pytorch_GAN_zoo:hub', 'PGAN', pretrained=True, useGPU=False)
input, _ = full_network.buildNoiseData(1)
print(f"input shape: {input.shape}")
model = full_network.netG
print(model)
model.eval()
output = model(input)

print("Converting model to ONNX...")
onnx_name = f"{NAME}.onnx"
torch.onnx.export(model,               # model being run
                  input,                         # model input (or a tuple for multiple inputs)
                  onnx_name,   # where to save the model (can be a file or file-like object)
                  export_params=True,        # store the trained parameter weights inside the model file
                  opset_version=11,          # the ONNX version to export the model to
                  do_constant_folding=True,  # whether to execute constant folding for optimization
                  input_names = ["input"],   # the model's input names
                  output_names = ["output"], # the model's output names
                  )
onnx_model = onnx.load(onnx_name)
onnx.checker.check_model(onnx_model)
ort_session = onnxruntime.InferenceSession(onnx_name)
def to_numpy(tensor):
    return tensor.detach().cpu().numpy() if tensor.requires_grad else tensor.cpu().numpy()
# compute ONNX Runtime output prediction
ort_inputs = {ort_session.get_inputs()[0].name: to_numpy(input)}
ort_outs = ort_session.run(None, ort_inputs)
# compare ONNX Runtime and PyTorch results
np.testing.assert_allclose(to_numpy(output), ort_outs[0], rtol=1e-03, atol=1e-04)
print(f"Exported model {onnx_name} has been tested with ONNXRuntime, and the result looks good!")

print("Converting to CoreML...")
mlmodel = convert(onnx_model,
                minimum_ios_deployment_target='13',
                image_output_names=['output'])
coreml_name = f"{NAME}.mlmodel"
mlmodel.save(coreml_name)
print(f"coreml model saved at {coreml_name}")

The onnx model correctly output from the above script is available to download here, if that helps in reproducing: https://drive.google.com/file/d/1ILLDBo2xXdsgaaf-Q_jilKFgTehNOVst/view?usp=sharing.
Here is also attached an exported environment.yml file for my conda environment which locally also has the same issue.
Diagram (too big a network to view in one frame):

System environment:

coremltools version: 3.0
onnx-coreml version: 1.0
OS: MacOS
macOS version: 10.15.1
How you install python: anaconda3
python version: 3.7.3

Just updated the colab notebook to onnx opset 11, and
Torch version: 1.3.1
Onnx version: 1.6.0
onnxruntime version: 1.1.0
Was hoping this would help. Did change the error from axes 1 to -1, but it's still there.

Can reproduce

@kossnick Can you please try converting the model using this change?
https://github.com/onnx/onnx-coreml/pull/524

The conv op in my own model is indeed converting correctly, thank you! :raised_hands: :heart:
I have gotten other similar axes=-1 issues elsewhere in our models (InstanceNorm2d in some scenarios and Slice in some scenarios). I've yet to find/make a simpler standalone repro for the other axis=-1 issues. Any advice on how to tackle those, or things to dig into for them?

@kossnick Can you please try converting the model using the change in PR
#524 ?

I Had exactly this problem with my "home made" model. Forcing the rank to be evaluated to 3 (if rank == -1: rank = 3) solved the issue to me. (I have two Conv1D with tensor shape of rank 3) I also tested your code and the export work perfectly.

I used the change in PR #524 , now I got a new Error while converting op of type: BatchNormalization. Error message: provided number axes -1 not supported error, guess it can be fixed by the same way?

Yes, for Conv2D, BN and GlobalPooling, it will all get rank=-1 error. Need to modify all these 3 source code.

related with https://github.com/onnx/onnx-coreml/commit/c36bfefbf84ce280195e9589e44aac3ee688b11d ?

May be the source of the problem. But I don't know if the previous implementation (rank = len(graph.shape_dict[node.inputs[0]])) would work with the current code base. Unfortunately I don't have the time to run this type of tests this week :/

Also saw this issue for Conv ConvTranspose' and 'MaxPool'. Worked around it by forcing the rank to the value I knew was expected in my "home made" model, in the _add_conv_like_op function.


Possibility to have pivccu-modules-dkms on fedora

First of all, thank you for all the work Alex !
I'm trying to setup an efficient as possible base system for docker purposes and would like to use Fedora Core OS as main system and docker host.
As I understood, the current kernel modules are only available for Debian related distributions but expect in generic to work on other linux environments.
Unfortunalty fedora does not use the Debian apt repository's but requires an .rpm package as installation source.
I tried to compile the core modules into a deb package (which worked fine) and rebuild the .deb to an .rpm source (which looked ok) but installation fails based on dependency's
I am wondnering if it would be possible to provide your kernel modules also as an .rpm source allowing us to use non-detain like distro's
Thank you and. have a nice day !
~Dutch
outcome of my test with own compiled package :
sudo dnf install ./pivccu-modules-dkms-1.0.71-2.noarch.rpm
Last metadata expiration check: 3:55:16 ago on Fri Feb  4 08:48:05 2022.
Dependencies resolved.
==================================================================================================================================
 Package                               Architecture             Version                      Repository                      Size
==================================================================================================================================
Installing:
 pivccu-modules-dkms                   noarch                   1.0.71-2                     @commandline                    57 k

Transaction Summary
==================================================================================================================================
Install  1 Package

Total size: 57 k
Installed size: 246 k
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction test error:
  file /lib from install of pivccu-modules-dkms-1.0.71-2.noarch conflicts with file from package filesystem-3.14-7.fc35.x86_64

I'm pretty sure, that the kernel modules will work on other distributions, too. But as I have no experience in building rpm packages, I cannot provide them.


Abitily to Unmatch?

 As I poke around trying to find if any of the apps I have installed are hpm providers, I find none. However, I'd still like to take advantage of hpm! If I create a repository, and a manifest file for each of my apps, hpm will (hopefully) happily assume control and all I have to do is tick the version when one of the apps updates.
However......what needs to happen if the author then starts providing an hpm manifest and repository?

Good point. Right now you'd have to uninstall and reinstall. However, do you really think hpm provides much value if you have to maintain the manifests yourself?

Well. It wouldn't be hard to make a small web service which creates and updates the manifest files by scanning the static files on github for updates... and I might just (have done that...)!

For my case, I think the easy solution will be to completely nuke packagemanager if the situation ever comes up. It's not a perfect solution, but it'll accomplish the goal without adding complexity to hpm.