Proposal: Move testing args a launch config and add separate configs per run/discovery/debug

The following outlines a proposal for how to handle testing args.
Submitted issues related to this problem:

https://github.com/microsoft/vscode-python/issues/21255
https://github.com/microsoft/vscode-python/issues/11736
https://github.com/microsoft/vscode-python/issues/21176
https://github.com/microsoft/vscode-python/issues/15148
https://github.com/microsoft/vscode-python/issues/18778
https://github.com/microsoft/vscode-python/issues/17171
design of UI as someone selects args: https://github.com/microsoft/vscode-python/issues/17094
https://github.com/microsoft/vscode-python/issues/12997
https://github.com/microsoft/vscode-python/issues/11932
As part of this overhaul we will stop parsing args:

https://github.com/microsoft/vscode-python/issues/20425
https://github.com/microsoft/vscode-python/issues/21798

Current design:
Currently, to pass any command line args for test run/discovery via the extension there is a single setting per test type (one for unittest, one for pytest). The two settings are python.testing.pytestArgs: [] and python.testing.unittestArgs: [] which take a string array of command line args. The args are then processed by the extension to remove some not applicable to the current action (removing run args during discovery and discovery args during run) but this is buggy and hard to maintain. Additionally to debug a debug config can be created in the launch.json.
Issues with current design:

With only a single place to put args for each test type, a user cannot distinguish between which command line args they want to include during test run, discovery, coverage, or debug.
Since pytest does not allow some args to be included during with the arg --collect-only (used to distinguish run from discovery by the extension) these args are parsed out by the extension before sending the request. This means custom args are removed from test args and generally it creates a buggy experience that is hard to maintain with the breadth of args users would like to pass into their tests.
There is no straightforward solution to providing environment variables while running and discovering tests.

Proposed new design:
Create new custom launch configs that can be setup for test run and discovery. Also, increase compatibility with debug launch configs to make sure these work in tandem. The launch config would be set up something like this:
    {
      "name": "Python: pytest run",
      "type": "python-pytest",
      "request": "launch",
      "args": ["", ""],
      "env": {
        "PYTHONPATH": "${workspaceFolder}"
      }
    },
    {
      "name": "Python: pytest discover",
      "type": "python-pytest",
      "request": "launch",
      "args": ["", ""],
      "env": {
        "VAR": "true"
      }
    }

The two particular fields "args" and "env" would provide functionality useful to users. The rest would be default values.
The new launch config types that would be added would be:

Python: pytest run
Python: pytest discover
Python: unittest run
Python: unittest discover
The names of each one are up for discussion, please provide feedback below!

Next a way to set up these launch configs would be introduced to the extension. The initial steps would be:

add configuration -> python -> python config menu
Two possible options for how to display the testing config options would be:
A:  to have another submenu called something like "testing" which, when opened, lists the 4 config options above
B: have the 4 config options sit in the current python submenu.
(I think option A is better for clarification even though it requires one more menu clickthrough).
additionally the button "configure tests" found on the test explorer would be changed so it routed the user to a menu of the launch config options for testing (similar to option A).

Concerns with proposed design:

The use of launch configs may be harder for new / beginner users.
The discoverability of launch configs is harder.
The transition from a setting to using a config could be complicated/confusing for current users.

Possible ways to address above concerns

help beginner users
a. Increase documentation and provide specific examples of launch configs.
b. provide default values for all fields in the launch config (this is already planned so the launch config should be runnable upon creation without edits meaning no args or env vars need to be provided)
discoverability
a. There is already a larger discussion happening on how we can improve this, switching to configs for testing provides even more reason to tackle this problem
b. switching the button "configure tests" to the new config flow is very discoverable since that is already the workflow
transition
a. We can have a deprecation notification regarding the setting and show it to all those still using the setting for test args
b. It should be simple to take someone's test args in their settings and turn that into a launch config so we could offer a button that handles this for the user to switch them over (drawback is we would be setting discovery and run to the same args but the user could see this then go change it)

Notes on Debugging:
Less investigation has been done into test debugging as we already offer a similar launch config. Further analysis should be done to see what is missing in this flow and how to improve it to align with test configs once a design is decided on.
Action Items:
We are looking for feedback on this proposal so please comment below any thoughts. Thanks!

The "name" of a launch config is for the name that the user picks, it shouldn't be used to change the behavior of the launch config. Also what does "discovery" involve? We shouldn't use launch configs for anything that isn't basically running/debugging a program.

Another suggestion, I don't know how much complexity is behind the "python-pytest" debug adapter, but if the point is just to invoke the python DA with some args, another option would be to add a config snippet to help users figure out how to write their pytest launch configs. An example of this is the snippets that we have for js-debug to help users write launch configs that start an npm script.

Yes, I forgot to update the "name" of the launch config to represent that as a user input and instead focus on using "type" to change the behavior.
discovery involves running pytest discovery. It is equivalent to running "python -m pytest --collect-only" from the command line. So it is running python code if that is the concern.
I will look into the js-debug snippet! Thanks

adding https://github.com/microsoft/vscode-python/issues/18778 to the related issues as this discusses limitations with current setup.

discovery involves running pytest discovery

Yes- and what is pytest discover? 😄

and instead focus on using "type" to change the behavior.

I would say this also isn't what I expect- "type" should indicate which debug adapter is being used, and this should just be "pytest" or even "python" or something like that, and then there should be some other argument that changes the behavior.

In that issue, it sounds like it's discussing limitations with launch configs, not settings? I don't understand what Karthik means when he says

We currently only read this from the launch.json. We could expand the scope of where we read it from, but that has some things that we have not decided yet.

in https://github.com/microsoft/vscode-python/issues/18778? I tagged it since resolving this args issue would then remove the setting entirely so it would simplify this process since the launch config would be the only place to reference. I mis-attributed it to "limitations" it is more like this issue would provide clarity to the issue brought up in #18778.

Yes- and what is pytest discovery? 😄
During discovery pytest goes through and discovers all files that fit the file format for test files and finds tests within those files (both test classes and just functions). It also should read markers to determine which tests to return. So it isn't executing any of the users test code.

I would say this also isn't what I expect- "type" should indicate which debug adapter is being used, and this should just be "pytest" or even "python" or something like that, and then there should be some other argument that changes the behavior.

gotcha yeah that makes sense

During discovery pytest goes through and discovers all files that fit the file format for test files and finds tests within those files (both test classes and just functions)

This doesn't sound like a good match for a debug config then, if I'm not going to be setting breakpoints and debugging my code. It sounds more like a task perhaps? Or just something that the extension does, configured by some settings.

@brettcannon, @karthiknadig, @luabud : thoughts on @roblourens comment?

The thing is that to configure the debugger to debug pytest tests, one needs to create a launch.json file. Given that, I think it makes sense to migrate how users can configure how to run pytest tests in launch.json too.
But the whole issue is that users would like to pass different configurations for pytest discovery, which needs to be done prior run/debug. If the config for running and debugging pytest tests are in launch.json, isn't it a bit weird to have the configuration for discovery elsewhere?

The other thing to call out is .env files -- using launch.json allow users to have different pytest configs with different environment variables per run, which is harder to do with settings

I guess my question is is launch.json is just for debugging why isn't it named debug.json? 😉 I personally view launch.json as the place to configuring launching your code which is traditionally for the debugger. As well, I views tasks.json as a way to run something in the terminal that we don't have extension support for and to parse the output (which this isn't doing; it's directly tying into things).
The other thing is that while you might not use the debugger every time, you may want to use the debugger when running the tests, and so it isn't a disconnect, I think, to use launch.json this way. And since discovery and running are tied together, I think putting one somewhere else just because you typically don't debug with it seems like we're putting purity over practicality. I.e., what Luciana said. 😁
Do we know how other testing extensions handle configuration for debugging compared to running? And we can bring this up in the Pacific stand-up if necessary.

I still don't really understand what discovery is or what the user flow is for this scenario. I haven't used a testing framework that has discovery as a separate step. What is the output of discovery?
So if I want to debug my tests, I'm going to run a "discovery" launch config, wait for that to finish, then run the "run tests" launch config?

different configurations for pytest discovery, which needs to be done prior run/debug

Sounds like a prelaunch task?

How does js-debug know what tests to list in the test explorer?

There's no connection between js-debug and the test explorer. Our self-host test provider that we use for the vscode repo https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-selfhost-test-provider creates a filewatcher for our test files, and parses them when they are added or changed. It's automatic there, I don't know about other test provider extensions. I wouldn't expect to run a launch config to populate the test explorer, that feels backwards.
I didn't realize that this is about the test explorer. So is the expected user flow like this?

Run the "discovery" launch config
Tests show up in the test explorer
Debug a test

And does 3 happen via the Test Explorer UI or the proposed Python: pytest run launch config?

parses them when they are added or changed.

pytest and unittest handle the test discovery, so we need to have those tools tell us what they find.

Run the "discovery" launch config

We run the discovery launch config; there's no manual step here beyond any custom configuration from the user.
This issue is just about configuration; the user doesn't perform any extra action for testing because of this and this is only for special cases where users need to specify extra details.

We run the discovery launch config

Launch configs are usually for users, they don't get run automatically in the background by an extension. When you do that, the debug toolbar will show up and the statusbar will turn orange and that will be spooky if it happens by itself.

another idea @luabud suggested would be something like this:
    "inputs": [
        {
            "id": "fileArguments",
            "description": "The arguments to send to the debugger",
            "type": "promptString",
            "default": "",
        }
    ],

    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "console": "integratedTerminal",
            "request": "launch",
            "program": "${file}",
            "args": "${input:fileArguments}",
            "justMyCode": true
        }
    ]

Had to type this out twice after it got lost in the github.com ether yesterday, here goes. Still thinking this through but here's some thoughts-
I hadn't realized that you can already define some config in launch.json for debugging tests in the test explorer. I see that in https://code.visualstudio.com/docs/python/testing#_debug-tests you can tag a launch config with "purpose": ["debug-test"] and it gets used for debugging from the test explorer. But it gets to me a bit that the docs suggest adding a config that isn't a "real" debug config since it can't be run by the debug UI on its own, and isn't hidden from the UI. Do you pull all the properties from the launch config in this case? I get why it would be annoying to duplicate all of that if this was going to be configured somewhere else. But isn't it also true that half of those properties are not going to do anything in the test explorer? name, request, program, and console seem like basically boilerplate that you need just to fit the pattern of a launch config, and I would also find that confusing as a user. This and having to hide the launch config from the UI shows that you are using a launch config for something other than its intended purpose. It's also confusing that you can have multiple launch configs tagged with purpose but there's no way to know which one is being used, which makes launch.json seem like it's the wrong shape for this config anyway.
You are also reading and writing the launch.json file on disk directly, right? I think extensions shouldn't be doing this with launch.json, or settings.json, or other files that are managed by vscode. I think that was a disconnect in our conversation, regarding what types of configuration extensions should store in launch.json- they shouldn't store anything in launch.json. You should interact with the features via extension API. Working with the files directly could lead to complications like not handling launch configs in workspace files or launch configs from settings properly (you can actually define launch configs in settings.json via the launch setting key) and vscode could change how it stores launch configs.
Using the purpose flag for test configuration would be a nice power-user feature if I could have one config that could run as a normal launch config, but also contribute debug config to the test explorer, but this seems impossible. If I add "module": "pytest" and run it in the test explorer I get errors about it being invalid, is that right?
Overall I really think that settings.json is the right place for extension configuration. I think it's confusing to have extensions storing things in launch.json that are not actually launch configs. Eleanor found an example of how the Java test extension stores test configs in settings, and that looks like a good pattern to follow, to me. I'm fine keeping what you already have with the purpose flag, since it already exists, but I think it would work better for the primary configuration source to be in settings.

Before reading Rob's comment and the docs, I actually arrived on something similar to the existing "purpose" -- and I'm curious why that isn't sufficient for this use case.
I think such a launch config could be a "real" config that runs/debugs all tests, and not hidden from users. You could short circuit the direct usage of that configuration in your DebugConfigurationProvider to start a test run so that test results are reported to the UI in the standard way. Perhaps you would only want a subset of options to be supported in that config, or use a different debug type with different options. Ideally configuration provided in that type would be enough for discovery and execution of tests, rather than having two different launch configs.
Also, you could support multiple test-purposed launch configs by adding them as different TestRunProfiles.

If you expect this launch config to also configure test running/debugging when you do it via the test explorer UI, then the extension is still reading configuration from launch.json, and I don't really like that.

Ideally configuration provided in that type would be enough for discovery and execution of tests, rather than having two different launch configs.

I don't know whether having discovery args in that launch config makes sense, because discovery happens before running tests, and you can only have one active discovery config.

will envFile still be an option in these launch configs so that we dont need to hardcode env vars?

Very likely. I would assume we will effectively duplicate most of what's available in launch.json (hence why we are thinking of putting things there to begin with).

not sure if this belongs in this issue or a separate issue

Don't worry about it; it's fine sitting here while we discuss where to place the settings.

how would this support having overrides to envFiles?

There isn't a proposal for that right now as that hasn't been an explicit ask before (to my knowledge).

I appreciate all of y'all looking into how we can make this more configurable.
I wouldn't find it odd to have testing configs inside the settings.json.
If I had to choose between simplicity and less configuration vs some complexity and more control, I would be in favor of the more complex and flexible configuration.
Specifically I think the best exposing multiple test configurations would be a huge lift for developers where the workspace is either a mono-repo, or simply a repo that includes multiple different python components that have their own standalone libraries (ie project that has a folder for their cron jobs, and a different folder for steaming)
Currently, because their is only one configuration object available anytime I want to run tests I have to do two things for the existing configs available:

Change the value for the outsets arguments to a different "path" which is one of the top level folder names
in the bottom right choose a different python interpreter

It would be nice for theses options to be nested in a list, allowing me to have multiple options
And for part of the configuration to give the python interpreter.
Given that the interpreter selection is actually determines more than testing(such as linking and auto completion, etc) the testing configuration might not be the appropriate place to define the interpreter, and maybe that's a different setting entirely.
Right now selection of the python interpreter isn't something that's saved into settings.json, in fact I don't even know where that value gets saved and persisted and have no idea how to set the path other than via the bottom bar or the select python interpreter command.
Multiple python interpreters for different parts of the same project may have its own headache I imagine and maybe just isn't feasible, but I did want to call out how currently the selected python interpreter does interact with the test run/discovery despite not having anywhere where you can actually type the path for the executable.

trying to write down a clear list of requirements for this new design and what we want its capabilities to be. I think if we can get to a final list of what we want the user to be able to do, it then might be easier to define how the user does so and how it looks.
Requirements for MVP (minimal viable product) of new test arg config:
Requirements for the Capabilities of the JSON testing config:

users must be able to define args, envFile and env for their test configuration

envFile not required for mvp

users must be able to define if this config is test type pytest or unittest
users must be able to define if this configuration is of type run or discovery
users must be able to uniquely name their configuration which can be used to reference it in other places
users must be able to define multiple run configurations

Requirements for Debugging

users should be able to use the run and debug tab to run their tests
users should be able to reference their tests configs from their debug configs defined in launch.json
users should not have to repeat their args or environment configs in multiple places in VS Code to achieve discovery, run, and debug
users should be able to debug multiple run configurations

Other Requirements:

users should be able to select which run config they want to use for a given run

this process should be easily accessible, but this is not a requirement for the MVP

users should be able to define a default run config

Python folks, what am I missing here or want is not a requirement in your option (both for MVP or for final design in general).

Now in terms of UX and functionality, here is a potential design option. It is full of a lot of questions / different ideas on configurations. Precidence should be used to determine the best design but in grey areas I was not so sure how to use our current design (like python debug config) to fit a new need.
settings.json design
{
      "name": "run config: unique name", // user defined name, must be unique
      "args": ["-v"],
      "env": {
				"PYTHONPATH": "${workspaceFolder}",
        "DJANGO_TESTING": "true",
				"DJANGO_SETUP_SCRIPT_PATH": "/path/to/file",
      },
			"envFile": "path/to/file",

      // idea 1.1: use type & purpose
			"type": ["python-unittest", "python-pytest"],
			"purpose": ["discovery", "run"],

			// idea 1.2: use type & testKind
			"type": ["discovery", "run"],
			"testKind": ["unittest", "pytest"],

			"request": "launch", // is this needed for test configs?
},

"python.testing.pytestEnabled": false,
"python.testing.unittestEnabled": false,
// Question 1.3
// should there be one value for default config?
"python.testing.defaultConfig": ["run config: unique name"],

// or should there be one per test library
"python.testing.pytestDefaultConfig": ["run config: unique name"],
"python.testing.unittestdefaultConfig": ["run config: unique name"],

// or one setting & multiple values there and we select
// the one with the correct purpose/test kind in config
"python.testing.defaultConfig": ["run config: pytest", "run config: unittest"],

// or should default config be defined in the config like so
{
      "name": "user config option 2",
      "args": ["-v"],
			"defaultConfig": true,
      .....
},

launch.json design
{
  "name": "Python: Debug Tests",
  "type": "python",
  "request": "launch",
  "program": "${file}",
  "console": "integratedTerminal",
  "justMyCode": false

	// Question 2.1: where to select which kind of run (options debug or run)?
	// Question 2:2: should the user be able to set just a run config from here so it shows up in the menu
	// Question 2.3: where to set which config to run?
	"purpose": ["debug-test"],
	"purpose": ["run config: unique name"], // see name is from above

	// Question 2.4: Should the user be able to define variables they can also define in
	// the settings.json? Can we restrict this option?
	"env": "",
	"args": "",
	"envFile": "",
}
{
  "name": "Python: Run Pytest Tests",
  "type": "python",
  "request": "launch",
  "program": "${file}",
  "console": "integratedTerminal",
  "justMyCode": false

	// idea 2.5: use purpose & type values
	// question 2.6: should there be a purpose to just run test?
	// question 2.7: should purpose `debug-in-terminal` still exist?
	"purpose": ["debug-test"],
	"type": ["run config: unique name"]
}

Possible UI design:
( this would not be required for the MVP but could be the goal of what we want the final experience to be like)
run and debug panel allows for the same behavior with defined run & debug configurations shown in the dropdown

This is just an idea, but I think it would be a great addition if Test Explorer had a dropdown that allows the user to select which config they want to use. (this is just a quick mockup, I think the look is a bit smushed so we would have to give it more thought if we went for something like this).

Some feedback reading through:

If your configs map to TestRunProfiles, you don't need to have settings for the default configs, as these are handled/persisted by the editor. That also solves some things like "where to set which config to run?"
Can pytestEnabled/unittestEnabled be covered by the presence of the associated run config? / are there cases where I could have one but not the other?
I would try to minimize how much the user needs to cross-reference between settings.json/launch.json, especially since I don't think you can do much with intellisense as an extension there
Is it the most common case that a user will use the same configuration to both run and debug? If so, are there design decisions that can be made to simplify that path?
"Test Explorer had a dropdown that allows the user to select which config they want to use" -- we don't have a <select> menu like debug uses, but using TestRunProfiles will let the user pick their config

"python.testing.pytestEnabled": false,

Are these settings an alternative to labelling the configs as pytest/unittest or are they doing something else? I would assume you mark a config as being for pytest, then use that config, and don't need another setting like that.
Are there workspaces that use both pytest and unittest?

2.1: If it's in a launch.json, it should be debugging by default
2.2: I don't understand what you mean
2.3/2.4: I know you said

users should not have to repeat their args or environment configs in multiple places in VS Code

but I agree with Connor and if I was doing this I would probably leave out this part of referencing settings.json configs for simplicity. I wonder how complex the configurations typically are? But if this is really important, I think the pattern is fine.  "purpose" doesn't quite mean the right thing to me. I would suggest "extends", implying that it will use that settings.json config as a base, but you can override properties from the settings.json config by setting them in the launch config as well.
2.6: There is a builtin command "Run without debugging", it starts your launch config with the "noDebug" property added dynamically, I would suggest building on that.

Are these settings an alternative to labelling the configs as pytest/unittest or are they doing something else?

Something else; they already exist as settings for the extension to control which testing framework you are using and thus which one you want us to integrate with.

Some feedback reading through:

If your configs map to TestRunProfiles, you don't need to have settings for the default configs, as these are handled/persisted by the editor. That also solves some things like "where to set which config to run?"

Yes this looks perfect!

Can pytestEnabled/unittestEnabled be covered by the presence of the associated run config? / are there cases where I could have one but not the other?

I think this is possible that the configs could have an associated pytest/unittest with each and it runs the given one. So if you select "run profile A", somewhere in the config for "run profile A" you defined it runs with "pytest" so then anytime you attempt "run profile A" it selects "pytest". @brettcannon or @luabud is this too hard for users to do or to discover? I am unsure of how often people want to switch between "unittest" and "pytest" and therefore how important this consideration is.

I would try to minimize how much the user needs to cross-reference between settings.json/launch.json, especially since I don't think you can do much with intellisense as an extension there

Yeah I think this is a very good point. If a user presses the "debug" button on the test explorer with a given set of args / env vars what is the difference then them create a config in their launch.json with the same args/env vars and running it there? Wondering if we just allow the option to use launch.json to continue as it is and we focus on just expanding the test explorer.

Is it the most common case that a user will use the same configuration to both run and debug? If so, are there design decisions that can be made to simplify that path?

Yes I think so. I think it would be good since you could set a different default per run / debug if we maybe just offer every run config as an option on the debug config list. Like if the person creates a config "profile 1" they will see that in both the "run" and "debug" dropdowns? Or do we think people will find this cluttered / not enough control? I guess we could also always add an arg that is like "show for: debug, run" and the default is both but could be changed.

"Test Explorer had a dropdown that allows the user to select which config they want to use" -- we don't have a  menu like debug uses, but using TestRunProfiles will let the user pick their config

The dropdown looks great! Sorry I missed this earlier!!!
For others here is how it could look with the dropdown:

The dropdown looks great! Sorry I missed this earlier!!! (also idk why it isn't letting me "reply" like above to your comment, the formatting was getting messed up)
For others here is how it could look with the dropdown:

replies to @roblourens comments:

2.1: If it's in a launch.json, it should be debugging by default 2.2: I don't understand what you mean 2.3/2.4: I know you said

Debug by default makes sense, that solves 2.3 as well. 2.4 was just about duplicating settings so I just more wanted to repeat that question there

but I agree with Connor and if I was doing this I would probably leave out this part of referencing settings.json configs for simplicity. I wonder how complex the configurations typically are? But if this is really important, I think the pattern is fine.

I think its common to have a few environment variables and args but maybe @luabud can speak more to this question.

"purpose" doesn't quite mean the right thing to me. I would suggest "extends", implying that it will use that settings.json config as a base, but you can override properties from the settings.json config by setting them in the launch config as well.

yes this sounds fine to use "extends" if we do want them to build off each other.

2.6: There is a builtin command "Run without debugging", it starts your launch config with the "noDebug" property added dynamically, I would suggest building on that.

this is great ya, no need then for 2.6

I think this is possible that the configs could have an associated pytest/unittest with each and it runs the given one. So if you select "run profile A", somewhere in the config for "run profile A" you defined it runs with "pytest" so then anytime you attempt "run profile A" it selects "pytest". @brettcannon or @luabud is this too hard for users to do or to discover?

I would expect users to never swap between them once they have chosen their test runner.
For Rob and Connor's edification: pytest can run pytest and unittest testing code (i.e., be a test runner for anyone), but unittest can only run unittest testing code, hence why users even have to specify anything (and this sparks an idea I'm going to go talk to Eleanor about 😁).

Following this round of comments, here is my new proposal on the design.
settings.json design
{
      "name": "run config: unique name", // user defined name
      "args": ["-v"],
      "env": {
	"PYTHONPATH": "${workspaceFolder}",
        "DJANGO_TESTING": "true",
	"DJANGO_SETUP_SCRIPT_PATH": "/path/to/file",
      },
       "envFile": "path/to/file",
       "testRunProfileKind": ["discovery", "run", "debug"] // all run kind will also display under debug, but not vice versa
},
"python.testing.framework": ["unittest","pytest"] // this is NOT required, the default will be used if not included

therefore the simplest config if you do all the most basic setup steps with pytest for example would be:
{
      "name": "pytest discovery config",
      "args": [], // this might even be optional too- open to suggestions on if this is a required part of the json.
       "testRunProfileKind": ["discovery"]
},

default values

default value for testing library (unittest or pytest) will be pytest if it is installed in the environment and unittest if not with this value being configurable via a single setting "python.testing.framework".
the default config will now be defined by the dropdown menu on the Test Explorer tab for run and debug like so:

launch.json design
Launch.json configuration for debugging testing will stay exactly as it is now with the current functionality and design. Users will NOT be able to reference their settings.json test configurations from their config.json file. They will need to duplicate / rewrite any configurations they want to use as a debug config there. This will cause duplication of work but I believe will be the simplest for the MVP and I predict users will tend to stick to a single way of use that will make sense to them. @brettcannon, @luabud, @karthiknadig let me know your thoughts on this as I most unsure about this decision and not sure it impact down the road.
Possible UI design:
Will use TestRunProfiles and their related UX. I will update this issue shortly with the flow of how users will set up testing once we switch. Additionally @connor4312 would it be possible to get a dropdown the same as on the "run" and "debug" icons on the reload icon to allow us to configure different profiles of kind "discovery" that could appear here? With the same option to set a default?

If we can't unify in a single file then I am afraid duplication is just unavoidable. We can operate under the assumption that if you're debugging a test it's a single test and thus going to be a bit specific rather than generic to your whole test suite.
One question about "python.testing.framework" is whether that should be global or should we make a per-config setting (thinking of the monorepo case)?

hi @eleanorjboyd! I love this proposal, it would fix an issue my org has with our test suite (we use pytest-xdist to parallelize test runs, but this breaks when we try debugging tests in VS Code). Is there a timeline for when this will be supported?

Is there a timeline for when this will be supported?

Eleanor is busy w/ non-test stuff this month, but the plan is to pick it back up in April.

+1 for this. The collection thing has been really frustrating. Not just that it doesn't work with some args, but also that if you have coverage enabled like so, it overwrites the coverage report. Not critical but it is annoying if you have it setup to discover on save.
The debugging portion of this is a deal breaker. It's working again now, but my issue #22820 is an example of how the current solution is brittle.
"python.testing.pytestArgs": [
        "--cov",
        "--cov-report=html",
        "-vvv",


pull request for e2e test at 02/04/2017 10:15:06

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Refactor Activity Share with Selector

While refactoring the activity share to use a selector, I found there were some missing icons around downloading and file sharing as well.
This should fix both. Commits should be proper.

Deploy preview for hopeful-hamilton-4090b9 ready!
Built with commit 7e449606271bff513cae695b8d954614c1156991
https://deploy-preview-770--hopeful-hamilton-4090b9.netlify.com


No such module "Alamofire" issue with xcode 7.3

i just updated to xcode 7.3 and from that moment i am getting this error :- No such module Alamofire. I have updated the Alamofire pod to 3.2.1 , then also the issue remains.Please guide

Alamofire 3.2.1 is not Xcode 7.3 compatible. For now, you'll need to use the swift_2.2 branch. We're aiming to have out a release today that resolves this issue.

i have updated the alamofire to 3.3.0, converted code to latest syntax, running xcode 7.3 and still facing the issue on my another project. I always face this issue once a while ,can u resolve this . Thanks

Quit Xcode, clear derived data, wipe your Xcode cache, then relaunch. That should fix everything up. Sometimes you also need to reboot your machine as well.


feat: start building pages

On small screens, the pages get compressed - we need to make sure that every page works on different screen sizes

Ex: on my screen size, this background wraps around again

Some comments here:
1. Can we limit the horizontal size of the wallet connect button by wrapping it with another container or flex
2. We don't need to allow people to select quantity, no one should ever have more than 1 membership pass
3. We don't need to show the number minted at the bottom (everyone should just have minted either 0 or 1, if they've minted they're part of the community)

Another example of mobile view - I would suggest going over and looking through all the mobile views/trying to make them responsive (it will just be a matter of having everything in Flex/Stack layouts, should make it much easier)

This membership button at the top doesn't actually link anything for me

The membership and events tabs shouldn't show up when a user hasn't claimed yet

Airtable environment variables should be on the `.env.example`

We probably want the events page to be able to wrap any number of events

Even with env vars, the /profile page or whichever page "Update Profile" button for me redirects to base URL (I can never actually access the page)

/profile should redirect to /register

Repalce Address on form with Wallet Address

Should hardcode to whatever color mode you're using

Members area text shouldn't link to home page

Add navigation to register page


More of a question than an issue.

This is really cool stuff. I have one question that comes to mind, and I might not be getting what's going on.
For this code, posted to your recent essay
loop :: Val -> X86()
loop (A dst) = do
  emit [0xE2]
  src <- gets _memoff
  ptr <- gets _memptr
  emit [fromIntegral $ dst - src]

Since emit takes a [Word8], isn't this liable to generate incorrect code if dest - src is outside of range (a longer jump than 127/128 bytes)? In fact, since Word8 is unsigned, I believe that overflow is technically already happening (-4 to 252) in the example given; it's harmless in this case, because the bit pattern 0xfc is preserved either way.

I should probably clarify in the article, the loop instruction makes for a nice short factorial function because it works for short jumps. Its operand code is rel8 so one signed byte at the machine level. Because relative offset is signed 0x00 to 0x7F is for forward jumps, and from 0x80 to 0xFF for backwards jumps.
So yes, it's possible that this will overflow if you give it a destination that's too far. So what I'll write about next is how we guarantee this invariant when we choose the right jmp or loop instruction from the higher level AST.


ci: setup Codeql workflow

Hi !
This is a setup for Codeql for kuma-gui as it is packaged in kuma.
I originally created an issue in kuma
And a pull request.
The use of Codeql in this repository would help complete the coverage of the vulnerabilities detection :)
Signed-off-by: Matthieu MOREL<EMAIL_ADDRESS>

Suggestion: Please merge the latest changes from the master branch into your PR’s branch. I’ve made changes to the mocks.ts file that should avoid the reported CodeQL warnings.

Hi @kleinfreund,
I rebased my branch, to integrate your latest modifications

Thanks for your contribution 🎉


QF-2161-R14Banner

Closing this without merging as we have by-passed pre-release as we do not know why there are un-merged commit from a year ago still on the pre-release branch


PlatformIO as Continuous Integration tool for embedded projects

Aims
PlatformIO is #1 tool for "Cloud Compiling" now. The one missing feature is to allow each developer/script to use PlatformIO in "Continuous Integration" manner. PlatformIO can build embedded projects for the different development platforms (Atmel AVR, Atmel SAM, TI MSP430, TI TIVA, Teensy, (soon Freescale FRDM, NXP LPC, Nordic RF51) and etc).
Requirements
The main aim is to promote PlatformIO as tool which is the best for "Continuous Integration". It should allow to specify src files, lib directories and boards which PlatformIO should use for running.
Implementation
It should be implemented via the new command platformio ci with the next options:

-s, --src the list with source files/dirs.They should be copied to src directory in new PlatformIO based project.
-l, --lib the list with source code of libraries which should be copied to lib directory of PlatformIO project.
-b, --board the list with boards. All tests should be passed over them.

NOTE
--src, --lib and board can be MULTIPLE. GLOB syntax should by allowed.
Using
For example, let's use this project https://github.com/felis/USB_Host_Shield_2.0. We want to test PS3SPP.ino example with the different boards/platforms:
# clone repo and change directory to it
platformio ci --src="examples/Bluetooth/PS3SPP/PS3SPP.ino" --lib="." --board=uno --board=teensy31 --board=due

Travis CI
Yep :) PlatformIO could be the best friend of @travis-ci. Example of .travis.yml:
language: python
python:
    - "2.7"

install:
    - python -c "$(curl -fsSL https://raw.githubusercontent.com/ivankravets/platformio/master/scripts/get-platformio.py)"

script:
    - platformio ci --src="examples/Bluetooth/PS3SPP/PS3SPP.ino" --lib="." --board=uno --board=teensy31 --board=due
    - platformio ci --src="examples/pl2303/pl2303_gps/pl2303_gps.ino" --lib="." --board=megaatmega2560
# ... and etc

We have already implemented a lot of these things... See how does testing work with PlatformIO Examples via Travis CI:
https://travis-ci.org/ivankravets/platformio/jobs/52805475

Friends @valeros, @aphelps, @robertinant, @PaulStoffregen, @aethaniel, @xxxajk, @Lauszus, @pelikhan, @ncolomer, @bettabacon, @eiginn, @Informatic, @mac7, @manashmndl, @MrCustomizer, @franciscoruiz, @elyulka
What do you think about it?

What about those prompts? They are complete show stopper right now.
Travis support sounds great however it should limited to it. There are many other build systems.
Travis supports a feature to cache certain folders, like npm-modules. You should update your example: installing a complete platformio drop on every build might quickly turn out costly for you.

Sent from Outlookhttp://taps.io/outlookmobile
On Tue, Mar 3, 2015 at 2:51 PM -0800, "Ivan Kravets" <notifications<EMAIL_ADDRESS>wrote:
Aims
PlatformIO is #1https://github.com/ivankravets/platformio/issues/1 tool for "Cloud Compiling" now. The one missing feature is to allow each developer/script to use PlatformIO in "Continuous Integration" manner. PlatformIO can build embedded projects for the different development platforms (Atmel AVR, Atmel SAM, TI MSP430, TI TIVA, Teensy, (soon Freescale FRDM, NXP LPC, Nordic RF51) and etc).
Requirements
The main aim is to promote PlatformIO as tool which is the best for "Continuous Integration". It should allow to specify src files, lib directories and boards which PlatformIO should use for running.
Implementation
It should be implemented via the new command platformio ci with the next options:

-s, --src the list with source files/dirs.They should be copied to src directory in new PlatformIO based project.
-l, --lib the list with source code of libraries which should be copied to lib directory of PlatformIO project.
-b, --board the list with boards. All tests should be passed over them.

NOTE
--src and --lib can be MULTIPLE. GLOBhttp://en.wikipedia.org/wiki/Glob_(programming) syntax should by allowed.
Using
For example, let's use this project https://github.com/felis/USB_Host_Shield_2.0. We want to test a few examples with the different boards/platforms:
clone repo and change directory to it
platformio ci --src="examples/Bluetooth/PS3SPP/PS3SPP.ino" --lib="." --board=uno --board=teensy31 --board=due
Travis CI
Yep :) PlatformIO could be the best friend of @travis-cihttps://github.com/travis-ci. Example of .travis.yml:
language: python
python:
- "2.7"
install:
- python -c "$(curl -fsSL https://raw.githubusercontent.com/ivankravets/platformio/master/scripts/get-platformio.py)"
script:
- platformio ci --src="examples/Bluetooth/PS3SPP/PS3SPP.ino" --lib="." --board=uno --board=teensy31 --board=due
- platformio ci --src="examples/pl2303/pl2303_gps/pl2303_gps.ino" --lib="." --board=megaatmega2560
... and etc

We have already implemented a lot of these things... See how does testing work with PlatformIO Exampleshttps://github.com/ivankravets/platformio/tree/develop/examples via Travis CI:
https://travis-ci.org/ivankravets/platformio/jobs/52805475

Friends @valeroshttps://github.com/valeros, @aphelpshttps://github.com/aphelps, @robertinanthttps://github.com/robertinant, @PaulStoffregenhttps://github.com/PaulStoffregen, @aethanielhttps://github.com/aethaniel, @xxxajkhttps://github.com/xxxajk, @Lauszushttps://github.com/Lauszus, @pelikhanhttps://github.com/pelikhan, @ncolomerhttps://github.com/ncolomer, @bettabaconhttps://github.com/bettabacon, @eiginnhttps://github.com/eiginn, @Informatichttps://github.com/Informatic, @mac7https://github.com/mac7, @manashmndl<https://gi
%20thub.com/manashmndl>, @MrCustomizerhttps://github.com/MrCustomizer, @franciscoruizhttps://github.com/franciscoruiz, @elyulkahttps://github.com/elyulka
What do you think about it?

Reply to this email directly or view it on GitHubhttps://github.com/ivankravets/platformio/issues/108.

What's the advantage of this new command to just using 'platformio run' with appropriate options?

Dear @pelikhan ,

What about those prompts? They are complete show stopper right now.

There are a few options to disable prompts:

using environment variable PLATFORMIO_SETTING_ENABLE_PROMPTS=No
disable global setting enable_prompts via platformio settings command
masking under Continuous Integration system via environment variable CI=true.

Travis support sounds great however it should limited to it. There are many other build systems.

Which others systems you could propose?

Travis supports a feature to cache certain folders, like npm-modules. You should update your example: installing a complete platformio drop on every build might quickly turn out costly for you.

@travis-ci doesn't allow to cache "something" for free account. This feature is available only for the premium accounts.

Dear @aphelps,

What's the advantage of this new command to just using 'platformio run' with appropriate options?

platformio ci command will consist from init + source/libs GLOB finder + run commands. This command is useful for the projects which want to be tested under different embedded platforms, but don't want to keep project structure in PlatformIO style. The simple example is Arduino library. The most libs like to keep in root of repository "library source code" and test code in "examples" folder.
Therefore, developers of libraries can add the only single .travis.yml or circle.yml file to repo and PlatformIO will test all examples. Another way is to dynamically perform "bash" commands with platformio init + cp files + platformio run.
If you like to keep your project in PlatformIO compatible structure, the you can use "platformio run" command for Continuous Integration systems.

Jenkins is another one.
Sent from Outlookhttp://taps.io/outlookmobile
On Thu, Mar 5, 2015 at 1:32 PM -0800, "Ivan Kravets" <notifications<EMAIL_ADDRESS>wrote:
Dear @pelikhanhttps://github.com/pelikhan ,
What about those prompts? They are complete show stopper right now.
There are a few options to disable prompts:

using environment variable PLATFORMIO_SETTING_ENABLE_PROMPTS=Nohttp://docs.platformio.org/en/latest/envvars.html#envvar-platformio-setting-enable-prompts
disable global setting enable_prompts via platformio settings commandhttp://docs.platformio.org/en/latest/userguide/cmd_settings.html#cmd-settings
masking under Continuous Integration system via environment variable CI=truehttp://docs.platformio.org/en/latest/envvars.html#envvar-ci.

Travis support sounds great however it should limited to it. There are many other build systems.
Which others systems you could propose?
Travis supports a feature to cache certain folders, like npm-modules. You should update your example: installing a complete platformio drop on every build might quickly turn out costly for you.
@travis-cihttps://github.com/travis-ci doesn't allow to cache "something" for free account. This feature is available only for the premium accounts.

Reply to this email directly or view it on GitHubhttps://github.com/ivankravets/platformio/issues/108#issuecomment-77456433.

Yeah, Jenkins is what I typically use for more serious projects.
Also, thanks for the clarification on what all 'platformio ci' will be doing, that makes sense.


Make general improvements

https://github.com/denoland/manual/issues/426

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


fix: handle python_date_format in ExploreMixin

SUMMARY

The ExploreMixin class is missing the logic to handle python_date_format, adding it.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

🏷 preset:2023.19


Dynamic Form won't update Single-TaxonomyFieldValue on a ListItem

Category
[ ] Enhancement
[ x ] Bug
[ ] Question
Version
Please specify what version of the library you are using: v3.13.0
Expected / Desired Behavior / Question
When saving the dynamic form when changing a Single Taxonomy Field Value, it should save the value to the list item.
Observed Behavior
The Single Taxonomy Field Value is not saved at all, and no error is observed. Reproducing this over the SharePoint REST API it seems that there is a problem when updating a list item with a Single Taxonomy Field Value with the standard Update method for the list item.
I tested this out with the UpdateValidateListItem method, and it works fine, so I will try to change the onSubmitClick method in the DynamicForm.tsx to not use listitem.update but to use updateValidateListItem instead! So a Pull Request will come in soon to fix this!
Steps to Reproduce
Create a list with a single taxonomy field (AllowMultipleSelection=false), and try to change a list item with the Dynamic Form. It will not change the value of the Single Taxonomy Field.
Thanks!

Could this be related to this issue? If it is changing the update to a validateUpdateListItem, could fix it.

Hi @SmarterJB,
I've tested on my side with a single taxonomy field value and it's updated without any issue:
{"__metadata":{"type":"SP.Data.EmployeeOnboardingListItem"},"Description":"ezaeazezaeazezaezaezae","Taxo":{"__metadata":{"type":"SP.Taxonomy.TaxonomyFieldValue"},"Label":"Rights","TermGuid":"042cad7f-276a-44a1-932a-9974a95fd338","WssId":"-1"}}

And under the hood, it's still the "update" method from PnPjs which is called (POST request on the /_api/web/lists/items endpoint.
Can you give us more info about the context? Are you trying to interact with a doc item like suggested by @HohoMike?


Securing crate admin interface with userid and password

Is it possible to secure create admin interface with login credentials?

How about Shield support with ES 1.4.2? Granted, this only helps those willing to pay for it. Just wondering if this will be supported naturally when Crate reaches that version.

I created some security stuff for elasticsearch, maybe i can help:
https://github.com/salyh/elasticsearch-security-plugin
https://github.com/salyh/elastic-defender

@dobe maybe you can try it during Snowsprint Hackathon? Regards to the other Snowsprinters ...


refactor(cleanup): remove test experiment

This PR resolves []
Description
Cleanup test experiment with unleash.

QA Test Case(s)

Test Case
Feature
Environment
Acceptance Criteria
Setup Instructions/Link

PR Checklist

[ ] I tested my changes on iOS / Android.
[ ] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.
[ ] I added an app state migration.
[ ] I hid my changes behind a feature flag.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

removed unleash example experiment - gkartalis

Need help with something? Have a look at our docs, or get in touch with us.

@pvinis do we also need to remove this? I guess not since it is a good example on where we can place the fallbacks 🤔

hm ok so we actually don't have any unleash flags? maybe we should keep the smudge code then 🤔 until we do

i feel scared enabling anyone to do anything in unleash, because we don't have the readyForRelease. Its something that we really want to have there before we start adding more serious flags.
I have been slow to make a ticket about this. How about this: I will make a ticket for this on the moplat jira, and tomorrow on mobile practice we could add this quickly, (i don't think it needs a lot of time to add), and then we can merge that too and start telling people to use unleash as the go-to?

closing this as it is stale, will revisit when we have time 😁


Thanks for this plugin !

Just a comment to say "Thank you!" for these excellent modules. You're right, they bring back the fun factor like when I first started using Rack. And yes, I tend to use a well-defined workflow, so every now & then it's a good idea to get out of that flow. Your modules make it easy to do that, I find them very provocative for the creative mind.
Best regards,
Dave Phillips

I'm really glad you like it! Thanks for the kind words!


Swift Vapor

Progress

[x] 🏁 Fork the starter repo & post the link in this issue
[x] 🎨 Create logo for repo & update issue status (@EricSimons)
[ ] 🔨 Implement all of Conduit's functionality per the spec & API
[ ] 👀 Move repo to main org & Peer review final codebase by admins/community (RFC)
[ ] 🎉 Tag v1 release and officially list it on the README!

Current Status
Codebase (in progress):
https://github.com/amadeu01/swift-vapor-conduit-example-app

@Cameron-C-Chapman Actually, it is not a mobile. It is a server-side (backend) application. Vapor is like Django (Python), Rails (Ruby), Express (Node)... Just a webframework

Hi @Cameron-C-Chapman
Actually, Vapor is a web framework just like Django, Rails, Express. That is not a mobile project.

Hi @EricSimons
Sorry for bothering you, but do you have some time to make the logo for the repository?

There you go. I'd also like to help with coding as I'm experimenting with Vapor.

@sherlockmac I had stopped, but I'll add the logo and make it again hehe. 🎉
thanks!

Let's keep the ball rolling ... let's get Swifty

@sherlockmac sorry my delay! We got the first PR. I'm gonna give more time to this project !

@amadeu01 It's fine.
Let me know if I could help :)

awesome!

@sherlockmac sorry! I changed from one company to another and things got a little overwhelming. But, I'll keep it rolling now.

Hello @amadeu01
I also intend to implement RealWorld backend with Vapor on Swift.
Please tell me the state if you like 🙏
Thanks

@iq3addLi sorry my delay. You can open any PR to the project. I'm really slow on this, but I'm going to work on that this weekend 😄

@amadeu01
Thank you for reply!
I understand that you will continue the project.
I looked at your project and it seems that the architecture is different from me.
So I'm considering starting a project with a different name, are you in favor?

@amadeu01
Thank you! Let's advance toward completion each other. 😊

Hello we are currently moving all work in progress to Github Discussions.
I'll close this issue by now, you can find instruction to open a discussion there : https://github.com/gothinkster/realworld/discussions/633
Thanks for your contribution !


error handling:

-now the errors raise a pending intent and the app doesn't crash
-refactored a bit
resolved #42

fixed with SHA: 7c98fed8ff2dd63bf176836e6ef415bf12e1f1ca


Re-authenticating each time I perform a helm3 command

Output of helm version: version.BuildInfo{Version:"v3.0.0-rc.3", GitCommit:"2ed206799b451830c68bff30af2a52879b8b937a", GitTreeState:"clean", GoVersion:"go1.13.4"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"windows/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.): AKS
Steps to reproduce:

Run the following to generate a kube config file
helm3 list -n adrian
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code [REDACTED] to authenticate.
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

Run again and it's ok
helm3 list -n adrian
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

Run kubectl command ok
kubectl get pods -n adrian
NAME      READY     STATUS         RESTARTS   AGE
nginx     0/1       Running	   0          3h58m

Run helm command again and asked to re authenticate
helm3 list -n adrian
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code [REDACTED] to authenticate.

Run kubectl command ok
kubectl get pods -n adrian
NAME      READY     STATUS         RESTARTS   AGE
nginx     0/1       Running	   0          3h58m

Is it possible for helm3 to load the kubeconfig in first before talking to the api server? This ordering is giving me some problems in AKS. As you can see below kubectl seems to load in the config before talking to the api server whereas helm3 is going directly.
kubectl get pods -n adrian -v 9
I1107 12:11:10.544621    2452 loader.go:359] Config loaded from file .kube/config
I1107 12:11:10.548623    2452 loader.go:359] Config loaded from file .kube/config
I1107 12:11:10.551625    2452 loader.go:359] Config loaded from file .kube/config
I1107 12:11:10.556620    2452 round_trippers.go:386] curl -k -v -XGET  -H "User-Agent: kubectl/v1.11.0 (windows/amd64) kubernetes/91e7b4f" -H "Accept: application/json, /" 'https://[REDACTED].hcp.eastus2.azmk8s.io:443/apis/metrics.k8s.io/v1beta1?timeout=32s'
helm3 list -n adrian -v 9
I1107 11:38:27.698145   11052 round_trippers.go:423] curl -k -v -XGET  -H "Accept: application/json, /" -H "User-Agent: helm3/v0.0.0 (windows/amd64) kubernetes/$Format" 'https://[REDACTED].hcp.eastus2.azmk8s.io:443/version?timeout=32s'
I1107 11:38:27.701150   11052 loader.go:375] Config loaded from file:  c:\Users\Adrian.kube\config

interesting find. If you can identify where in the code base that call is being made, a patch would be appreciated. The kube config file should certainly be loaded before making a call out to Kubernetes.

I think I found the culprit. Somewhere in the CLI, we might be calling IsReachable prior to loading the kube config file. I'll see if I can find the problem area.
https://github.com/helm/helm/blob/43acbfe86d2228134a5f3478e97cae433ca33fb2/pkg/kube/client.go#L75-L83

I had a look through the code base. Everything seems fine from a deep dive; the kubeconfig file is loaded first before fetching server information.
According to client-go, it should be logged if the verbosity level is 6 or higher: https://github.com/kubernetes/client-go/blob/e55a71a3e03e5656a816878524151bd42ad3a25e/tools/clientcmd/loader.go#L375
testing with:
><> kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
><> helm version
version.BuildInfo{Version:"v3.0.0-rc.3", GitCommit:"2ed206799b451830c68bff30af2a52879b8b937a", GitTreeState:"clean", GoVersion:"go1.13.4"}

><> helm list -v 6
I1107 12:31:08.984612    1032 round_trippers.go:443] GET https://<IP_ADDRESS>:8443/version?timeout=32s 200 OK in 5 milliseconds
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
wp      default         1               2019-11-07 12:17:55.64773868 -0800 PST  deployed        wordpress-7.6.0 5.2.4

Same goes for master:
><> ./bin/helm version
version.BuildInfo{Version:"v3.0+unreleased", GitCommit:"43acbfe86d2228134a5f3478e97cae433ca33fb2", GitTreeState:"clean", GoVersion:"go1.13.3"}
><> ./bin/helm list -v 6
I1107 12:32:16.799707    1167 round_trippers.go:443] GET https://<IP_ADDRESS>:8443/version?timeout=32s 200 OK in 5 milliseconds
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
wp      default         1               2019-11-07 12:17:55.64773868 -0800 PST  deployed        wordpress-7.6.0 5.2.4

I could not see the same log messages you reported here with either version. Can you please verify that you're using the same helm version in your demonstrations?
What seems most interesting to me is how kubectl loads the kubeconfig three times in quick succession as shown in your output of kubectl get pods -v 9. If you can share details on how you provisioned your cluster, perhaps that could identify the issue.

Thanks for the quick turnaround @bacongobbler, I've tried to recreate on a clean linux machine and I cannot.  I'm happy to close, sorry for the trouble.

Not reproducible.

it could be bash environment problem.
I encounter the same problem, when using mobaxterm as bash on my windows, and helm3 is a soft link to windows exe.
then i cannot reproduce the problem when i shifted to wsl(ubuntu) and used linux format helm3 binary.
Can anybody expain why?


Alternative to „Vector Representation Pre-training“ possible?

In the paper Driving with LLMs a „Vector Representation Pre-training“ is used to interact with llama-7b as follows: „In our framework, we aim to convert vector representations into language using a structured language generator to facilitate the grounding the vector representation into LLMs. Since our object-level vectors contain semantically significant attributes, such as the number of cars and pedestrians, their respective locations, orientations, speeds, bounding boxes and other attributes, we employ a structured language generator (lanGen) function to craft pseudo-language labels derived from the vector space…“
Question: can we apply / modify minbpe to achieve the same? Or is this a silly question…

Sounds interesting. I should read the paper first, but just going of the text you provided I am unsure how you are relating it  to bpe. They are going from vector representations to pseudo-language. Bpe allows tekst to be encoded as a sequence of integers where the integers then are used to lookup the vector representation. So the other way around basically. But maybe you are thinking about reversing the principle?
It is something I have been thinking about and I tried to get some discussion started in another post. Not much response as of yet unfortunately.
I was thinking a scheme where the tokeniser doesn't just give a sequence of tokens but also a set of modifiers to the tokens. The integer we would use as normal to lookup the token embedding, but the modifiers we map onto synthetic (non-trained) dimensions of the token embedding.
The tokeniser would have to be very different from just doing bpe. Instead we would make an attempt of building a tokeniser using a-priori knowledge of different languages. Just as an example:
" bus", "Bus", "busses" for instance would all map to the same integer and the synthetic dimensions would provide the information of the specific variation. Maybe language could be a modifier too. So that the same word in different languages also have the same integer.


blog.mlc.ai is down

❓ General Questions
Hey folks, the blog.mlc.ai is reporting 404 error now. Waiting to check out the scalability experiments on different # of GPUs. Let me know if it's back up. Thank you so much for the great work!

thanks for reporting, this is now back


Add DLI PowerSwitch Component

Description:
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

Successor of #4563.

This PR seems to have gone stale. Closing it. You can reopen it when you're ready to finish it.


ERR: drop function code macro generation

While working on #13390, I figured that we could as well complete the work by dropping the generation of _F_ macros.  The new ones that were generated in master have been questioned more than once, since they aren't useful anywhere.
This PR includes the commits from #13390, and is pending that one being merged.

Rebased for GH action fixups

Rebased on fresher master

I figured that we could as well complete the work by dropping the generation of F macros.

Does that have downstream "just recompile" issues?  Yes, obviously, but are they ones you care about?

Hmmmm, that's a good question.  Let me have another look

@richsalz, the thing you're missing is that I've moved all the _F_ macros that we have in 1.1.1 to include/openssl/cryptoerr_legacy.h and include/openssl/sslerr_legacy.h.  This allows us to clean the other err headers.
So no, downstream recompilation should not be a problem.

@richsalz, the thing you're missing is that I've moved all the _F_ macros that we have in 1.1.1 to include/openssl/cryptoerr_legacy.h and include/openssl/sslerr_legacy.h. This allows us to clean the other err headers.

Got it, makes sense, thanks.
And I guess you originally forgot that, too since you had to look :)

And I guess you originally forgot that, too since you had to look :)

Yup.  I did this work quite a while ago, and my personal memory banks have their limits :wink:

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged
b14c8465c0899c3c2b2acc3d01472941de4c318e ERR: clean away everything related to F macros from util/mkerr.pl
e337b82410a031f0ff60ebf6744b97da2a276e51 ERR: Rebuild all generated error headers and source files


How to refer to each element of the list?

For example, when I click on an item, I make a visible picture, and thus it is necessary that in all other elements this picture becomes invisible. How can this be realized?

you can do it like this in yourAdapter at this method convert find your view  View yourView = help.getView(R.id.your_view_id);   if(item.getIsHidden()){yourView.setVisibility(View.VISIBLE or View.GONE)}

if I do so, then every 13 list items will become visible. 0, 13, 26 etc

You can add a field marker view to show and hide the data layer


Site not work

Site doesnt work. Can you check this out?

I'm migrating datmusic to the new server. It will be up soon.


Include hint to enable Bluedroid in Readme

Hopefully makes it clear that the Bluetooth and Bluedroid component have to be enabled

Thanks!


[WIP] correct template location for neutron lbaas on newton

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

LGTM. Remove WIP when u would like it to get merged.

ok to test

@nirajdp76,  thanks for your review.


Just to tell you that i've used your script in my App

You can find it there -> https://github.com/prisonier/armourer
Good job man thanks !

No problems, I'm glad you found it useful.


Document precedence of :

https://doc.rust-lang.org/nightly/reference/expressions.html#expression-precedence is missing the colon operator :.  In previous versions it was the same precedence as as.

Type ascription is not currently stable.

KK.  Thanks


Decimate incorrect for nondivisible factors

Problems occurring for values of factors for which the sampling frequency is not divisible by the factor. Array length is less by 1.
OUTPUT:
array lengths differed, expected.length=32 actual.length=31; arrays first differed at element [31];
Expected :-0.494
Actual   :end of array
at com.onyx.jdsp.TestDecimate.DecimateWithZeroPhaseTest(TestDecimate.java:102)
Caused by: java.lang.AssertionError: expected:<-0.494> but was:
at org.junit.Assert.failNotEquals(Assert.java:835)

Resolved by changing the length of the output array in Decimate class.


Webflux plugin optimization

Please answer these questions before submitting pull request

Why submit this pull request?

[ ] Bug fix

[ ] New feature provided

[x] Improve performance

Related issues
https://github.com/apache/skywalking/issues/3242

New feature or improvement
Support for more versions
Support for @controller and Functional endpoints
More complete collection of links in high concurrent scenarios

This PR is ready.
I did not find the problem in the case of 20 concurrent threads, so I did not use the AsyncSpan API.

/run e2e

the webflux agent will throw ClassCastException, and can not collect span info when defining:
@Component
public class MyFilter implements WebFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
        return chain.filter(new MyServerWebExchangeDecorator(exchange));
    }

    public static class MyServerWebExchangeDecorator extends ServerWebExchangeDecorator {
        public MyServerWebExchangeDecorator(ServerWebExchange delegate) {
            super(delegate);
        }
    }

}

and can fixing it by:
public class DefaultServerWebExchangeInstrumentation extends ClassInstanceMethodsEnhancePluginDefine {
    @Override
    protected ClassMatch enhanceClass() {
        return byHierarchyMatch(new String[] {"org.springframework.web.server.ServerWebExchange"});
    }
    ......
}

org.springframework.web.server.ServerWebExchange

Can you move this and create an ISSUE for describe how to reproduce and fix this problem?

the webflux agent will throw ClassCastException, and can not collect span info when defining:
@Component
public class MyFilter implements WebFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
        return chain.filter(new MyServerWebExchangeDecorator(exchange));
    }

    public static class MyServerWebExchangeDecorator extends ServerWebExchangeDecorator {
        public MyServerWebExchangeDecorator(ServerWebExchange delegate) {
            super(delegate);
        }
    }

}

and can fixing it by:
public class DefaultServerWebExchangeInstrumentation extends ClassInstanceMethodsEnhancePluginDefine {
    @Override
    protected ClassMatch enhanceClass() {
        return byHierarchyMatch(new String[] {"org.springframework.web.server.ServerWebExchange"});
    }
    ......
}

Can you move this and create an ISSUE for describe how to reproduce and fix this problem?

ok, I will create a new issue.

new issue: https://github.com/apache/skywalking/issues/3392


Inconsistent markdown (beta editor)

Issue Summary
When writing in markdown, the change appears in the editor, but when you publish it or look at the preview that change might not be what you expect, but it shows the markdown text.
https://github.com/TryGhost/Ghost/assets/5787110/f5bad6e9-3777-481a-9f16-1d1ba2725d4c
In this video, you can see I've bolded some content inside the markdown and it shows bold in the editor, but it is not getting applied on the preview.
Steps to Reproduce

Create some text
make it bold by adding ** in front and back of a word
editor shows text bolded correctly but the website shows it as not bold

Ghost Version
5.55.0
Node.js Version
18.12.1
How did you install Ghost?
Ubuntu
Database type
MySQL 5.7
Browser & OS version
No response
Relevant log / error output
No response
Code of Conduct

[X] I agree to be friendly and polite to people in this repository

For anyone picking up this issue, the issue is with how the data is stored rather than how it's rendered.
https://github.com/TryGhost/Ghost/assets/34619861/a16ce192-1ea9-47b1-a1ba-6006dbead0e1
If the user saves the post without pressing enter or clicking elsewhere the lexical editor keeps the whole node as one but when moved to a new line there are 2 nodes, one with the format as 1 (bold) and the other 0.

Can I contribute to this issue? if still active.


Automated PyPI distribution

Add deployment instructions to .travis.yml so that new releases are automatically deployed to PyPI.
References:

https://github.com/eflglobal/filters/blob/master/.travis.yml#L8-L15
https://docs.travis-ci.com/user/deployment/pypi/

Bonus Points
Create binaries for major OS distros as part of the deployment process, so that end users don't have to compile anything.

Implemented in https://travis-ci.org/todofixthis/pyota-ccurl/builds/225465539

Credentials are incorrect:
Uploading distributions to https://pypi.python.org/pypi

Uploading PyOTA-CCurl-1.0.1.tar.gz

[================================] 9115/9115 - 00:00:00

HTTPError: 401 Client Error: You must be identified to edit package information for url: https://pypi.python.org/pypi

Verified in https://travis-ci.org/todofixthis/pyota-ccurl/jobs/225470821


VkParserAv1PictureData: increase array size to 256

Set to the maximum number of tiles specified
by any defined level.
See VulkanVideoParser.cpp+169
TODO: Use a dynamic allocation of this structure

^ @lolzballs


Fix BDC tree getting stuck loading

The view would get "stuck" showing the Loading controllers... message if there were no registered BDC clusters. This isn't a complete blocker since users could still run the commands to register a new BDC cluster just fine and then things would work as expected, it was only this initial load that things could get stuck.
This is because we were firing the _onDidChangeTreeData event while getting the children, which would cause it to cancel the original children query and end up returning undefined instead.
getChildren is already a promise so instead of doing this roundabout way of loading where we kick off the load async'ly and then refresh the tree once it's done we just always wait to load the nodes when getting the children to start with. (the original method was likely due to the welcome view stuff not existing back when this was made, so we'd often make a "dummy" message node with the message while it was loading. But that isn't necessary anymore with the welcome views)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 42.24%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
28178

Relevant Lines:
62341

💛  - Coveralls


fix: Fix transformation for plus/minus one reactions

The current transformation happens at the wrong nesting level so it doesn't happen. Fixing to obtain +1 and -1 reactions.

@sicarul can you merge main into your branch?
Thanks!


automatically generate desired controller-gen binary

Issue #, if available:
#633
Description of changes:

Desired version of controller-gen binary will be automatically generated with 'make build-controller SERVICE=$SERVICE' command
Removed kubernetes-sigs/controller-tools from prerequisites as users might try to install controller-gen manually and run into errors mentioned in #633 . The Makefile change will anyways install the correct version automatically or indicate the user to install the correct one in case of mismatch as below -

$make build-controller SERVICE=$SERVICE
building ack-generate ... ok.
FATAL: Existing version of controller-gen Version: v0.4.1, required version is v0.4.0.
FATAL: Please uninstall controller-gen and install the required version with scripts/install-controller-gen.sh.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

kind & jq have pretty neat installation instructions so we should be good there.


echo solution for CMake error , for no meta example

#3535

Nice, exactly this. Just a minor change and we are good (please suqash commits, or use git commit --amend on your branch)

As I said above, please squash commits


Fix timestamp value in query params

Coverage remained the same at 56.432% when pulling 7e60dedbb8356fed5635ae5b83a4fa26842a2a8d on wknet123:master-log-query-params into 6cee61cb232154c33bc7922b1460fb6a43d033cd on vmware:master.

Coverage remained the same at 56.116% when pulling 93a821910866b7bc5ed4abaecde1aad702cffca2 on wknet123:master-log-query-params into ba785357da25f9417b4e7e4fb08c27b08d948eee on vmware:master.


[QUESTION] Downsampling big clouds to find correspondences?

Have you read the documentation?

[x] Yes
[ ] No - then this issue will be closed.

Is there a way to down-sample a point cloud with teaser++ in C++? I was calculating the correspondences between clouds and it takes a lot of time (3 h)!
[INFO] Reading Point Clouds ..
 Read 436186 total vertices
 Read 409625 total vertices
 Read 418356 total vertices
 Read 423251 total vertices
 Finding correlations between : 0 , and 1
Calculating fpfh
Calculating correspondences <- Stuck here

@b15h0y The FPFH correspondence computation module included in the TEASER++ repo is very rudimentary, and it does not have downsampling functions. For downsampling, I recommend either use PCL in C++, or Open3D in python.

It would be really helpful to extend the Utils function in TEASER++ with methods to do conversions of point clouds to other libraries classes like pcl::PointCloud<TYPE>::Ptr or even an Eigen matrix to handle transformations better. So in a scenario like the one I am facing or in real application where the point cloud is huge some one can do something like this :
pcl::PCLPointCloud2::Ptr cloud = teaser::utils::toPCLPointCloud(cloud_read_with_teaserpp); <- Here
pcl::PCLPointCloud2::Ptr cloud_filtered (new pcl::PCLPointCloud2 ());
pcl::VoxelGrid<pcl::PCLPointCloud2> sor;
sor.setInputCloud (cloud);
sor.setLeafSize (0.01f, 0.01f, 0.01f);
sor.filter (*cloud_filtered);
teaser::PointCloud cloud_downsamples = teaser::utils::toTeaserppPointCloud(cloud_filtered); <- Back Here
...

I agree. I think this should be easy to do. If you submit a PR, I am more than happy to merge it.


Update mcgd.py, 'Series' object has no attribute 'append'    #739

Originally posted by @Se6T in https://github.com/twopirllc/pandas-ta/issues/739#issuecomment-2019752885

Hello @hardywu,
Please checkout the development branch, make adjustments, check your tests, and resubmit.
Kind Regards,
KJ

@hardywu
By no response I assume the development branch solves this issue. If that is unture, feel free to open a new PR using the development branch version.
Kind Regards,
KJ


Setup Popup Window for Work Section

In this PR, I fulfilled the following tasks:

[x] Create a Popup window for mobile and desktop versions.
[x] Add a JavaScript array to store all the information for the projects.
[x] Update the main page so that the projects section is created dynamically from a JS script
[ x] Update the README file with the new feature

Observation 1: Kindly fix the width of the modal as per the given Figma template.

Observation 2: Please fix the height of the modal on the mobile version. It uses almost half of the page as seen below.

Observation 3: Please fix the icon like on the Figma template. The icons is not under the link, it is just located on the next to it.

Observation 4: Please make sure the Lorem Ipsum text is not overflowing from the modal and there is padding on the bottom of the text.


Update scripts to OpenType 1.8.3

... there seem to be problems with Travis; AFAICS, the failures are not related to this pull request.

Will, are you going to add this pull request to fontspec?

Very sorry for the slow reply, Werner. Much appreciated.


[web] My complex widget list is not working on real devices

I hava one problem of web develop
I made web resource from command build web
And I published on my webserver
It's well working for Andorid, but IOS is stuck
Here is my pseudo code
List items;
MainScreen extend StatelessWidget
build(){
return Column(
   children :[
      Container,
      Wrap(
      list.generate(
      children : items.length,
      (index)=>MyWidget(item[i])
    )
   )
  ]
)
}

MyWidget extend StatelessWidget
build(){
return Column(
   children : [Container, MySubWidget]
)
}

MySubWidget extend StatelessWidget
List options
build(){
return Wrap(
  children :  list.generate(
   children : options.length,
   (index)=>MyWidget(options[i])
   )
)
}

and then my flutter doctor -v
[✓] Flutter (Channel beta, 1.23.0-18.1.pre, on Mac OS X 10.15.7 19H2 x86_64, locale en-KR)
    • Flutter version 1.23.0-18.1.pre at /Users/taz/Documents/flutter_channels/flutter_beta
    • Framework revision 198df796aa (4 weeks ago), 2020-10-15 12:04:33 -0700
    • Engine revision 1d12d82d9c
    • Dart version 2.11.0 (build 2.11.0-213.1.beta)

How can I see 'IOS logs' when site stuck?

When I remove Wrap at MainScreen, It's well working on both of them

Hello @taz1208 , could you please mention the browser you are using to test this. You can use flutter Run and view the logs.
Could you please provide the output of flutter doctor -v
Thanks

@taz1208
Are you trying to run on Android and iOS mobile browsers ? When you say not working on iOS, what do you mean exactly ? Does it show any error ?
Also, please provide a complete reproducible code sample.

@sidrao2006
It just happen on real device(My step is flutter build web, and publish on my test webserver, then test android, IOS mobile browsers)
Android test on 'Chrome' and 'Samsung Internet Browser',
IOS test on 'Safari', 'Naver app', 'Chrome'
Here is my flutter doctor -v
[✓] Flutter (Channel beta, 1.23.0-18.1.pre, on Mac OS X 10.15.7 19H2 x86_64, locale en-KR)
    • Flutter version 1.23.0-18.1.pre at /Users/taz/Documents/flutter_channels/flutter_beta
    • Framework revision 198df796aa (4 weeks ago), 2020-10-15 12:04:33 -0700
    • Engine revision 1d12d82d9c
    • Dart version 2.11.0 (build 2.11.0-213.1.beta)

@darshankawar
Yes, I tried on Android and iOS mobile browsers, but I don't know how to see log on real device :(
I just publish on  my test webserver,
It's not problem on Android but stuck on IOS
And I can't provide my code, It's so complex and use network Image, Data

@taz1208 If your issue is just about how to debug on iOS mobile browser, I think you may ask the same in support channels. Please see https://flutter.dev/community for resources.
You can chat and ask web-related questions on the #help channel on Discord.

@taz1208 ,
To test your app on Chrome (iOS and Android) , you have to run the app locally on a desktop/laptop and then connect your device with a usb cable and setup port forwarding.
Check out this guide to enable chrome remote debugging.
Then run flutter run -d chrome --web-port 8080 and setup port forwarding for 8080. That way, you will be able to run it on a mobile and view the logs in your console

I got found reason form reomte safari debug

hmmmm...
My complex widget use like this
Column[
	Slider(like PageView),
	Container,
	Wrap[
		MyWidget,
		MyWidget,
		MyWidget,
		... about 10 less

	],
	Container,
	Row(),
	...etc
]

MyWidget[
	Column[
		Container,
		Wrap[
			Text,
			Text,
			Text,
			Text,
			... about 5 less
		]
	]

]

I should be change code more simple?

It's beta
so, should I endure?
Is it my personal problem?
Android is fine, but IOS is not fine.
What can I do?

Hi @taz1208
To better address the issue,  Can you please provide your flutter doctor -v your flutter run --verbose and a complete reproducible minimal code sample instead of a widget tree.
Thank you

Sorry I can't provide my code
but I found similar case #54584

Hi @taz1208
It doesn't need to your own code, you can replace whatever content you have dummy text and placeholder images  and provide code reproducible ode sample
For example, you can replace text lorem ipsum and images with flutter logo images from Google images
Thank you

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: ListView(children: [
        Wrap(
          children: <Widget>[
            for (var i = 0; i < 15; i++) FractionallySizedBox(widthFactor: 0.2, child: ProductPreview()), //need case1
            for (var i = 0; i < 15; i++) ProductPreview(), //need case2
          ],
        ),
      ]),
    );
  }
}

class ProductPreview extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      behavior: HitTestBehavior.translucent,
      onTap: () => print('tap'),
      child: Column(
        mainAxisSize: MainAxisSize.min,
        // crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          Container(
            margin: EdgeInsets.all(23),
            padding: EdgeInsets.all(18),
            decoration: BoxDecoration(
              color: Color(0xfff9f9f9),
              shape: BoxShape.circle,
            ),
            child: Image.network(
              'https://cdn.pixabay.com/photo/2014/03/24/17/06/hummingbird-295026_1280.png',
              width: 100,
              height: 100,
            ),
          ),
          Text(
            'title',
          ),
          SizedBox(
            height: 14,
          ),
          Wrap(
            alignment: WrapAlignment.center,
            children: [
              ProductOption(
                optionText: 'option1',
              ),
              ProductOption(
                optionText: 'option2',
              ),
              ProductOption(
                optionText: 'option3',
              ),
              ProductOption(
                optionText: 'option4',
              ),
              ProductOption(
                optionText: 'option5',
              ),
            ],
          ),
        ],
      ),
    );
  }
}

class ProductOption extends StatelessWidget {
  final optionText;
  const ProductOption({
    Key key,
    @required this.optionText,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Container(
      constraints: BoxConstraints(minWidth: 56),
      margin: const EdgeInsets.all(2),
      padding: EdgeInsets.symmetric(horizontal: 11, vertical: 5),
      decoration: BoxDecoration(
        border: Border.all(
          width: 1,
          color: Color(0xffebebeb),
        ),
        borderRadius: BorderRadius.all(Radius.circular(15)),
      ),
      child: Text(
        optionText,
        maxLines: 1,
        // style: Theme.of(context).textTheme.bodyText2,
        textAlign: TextAlign.center,
        overflow: TextOverflow.ellipsis,
      ),
    );
  }
}

It make simple batter than my code
and my flutter doctor -v is here
[✓] Flutter (Channel beta, 1.23.0-18.1.pre, on Mac OS X 10.15.7 19H2 x86_64, locale en-KR)
    • Flutter version 1.23.0-18.1.pre at /Users/jhon/Documents/flutter_channels/flutter_beta
    • Framework revision 198df796aa (5 weeks ago), 2020-10-15 12:04:33 -0700
    • Engine revision 1d12d82d9c
    • Dart version 2.11.0 (build 2.11.0-213.1.beta)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/jhon/Library/Android/sdk
    • Platform android-30, build-tools 29.0.2
    • ANDROID_HOME = /Users/jhon/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.2, Build version 12B45b
    • CocoaPods version 1.9.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 50.0.1
    • Dart plugin version 193.7547
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.51.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (2 available)
    • Web Server (web) • web-server • web-javascript • Flutter Tools
    • Chrome (web)     • chrome     • web-javascript • Google Chrome 86.0.4240.198

I think that main point is wrap in wrap..

Hi @taz1208
Thanks for the reproducible code sample, I can reproduce the issue, and Removing Wrap from the main screen does solve the issue
However, the issue only reproduces on beta and dev for me, master doesn't have the issue
Issue reproducible

flutter doctor -v
[✓] Flutter (Channel beta, 1.23.0-18.1.pre, on macOS 11.0.1 20B29 x86_64, locale
    en-GB)
    • Flutter version 1.23.0-18.1.pre at /Users/tahatesser/Code/flutter_beta
    • Framework revision 198df796aa (5 weeks ago), 2020-10-15 12:04:33 -0700
    • Engine revision 1d12d82d9c
    • Dart version 2.11.0 (build 2.11.0-213.1.beta)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/tahatesser/Code/sdk
    • Platform android-30, build-tools 30.0.2
    • ANDROID_HOME = /Users/tahatesser/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.2)
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.2, Build version 12B45b
    • CocoaPods version 1.10.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.51.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (3 available)
    • Taha’s iPhone (mobile) • 00008020-001059882212002E • ios            • iOS
      14.2
    • Web Server (web)       • web-server                • web-javascript •
      Flutter Tools
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 86.0.4240.198

• No issues found!

[✓] Flutter (Channel dev, 1.24.0-10.2.pre, on macOS 11.0.1 20B29 darwin-x64,
    locale en-GB)
    • Flutter version 1.24.0-10.2.pre at /Users/tahatesser/Code/flutter_dev
    • Framework revision 022b333a08 (19 hours ago), 2020-11-18 11:35:09 -0800
    • Engine revision 07c1eed46b
    • Dart version 2.12.0 (build 2.12.0-29.10.beta)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/tahatesser/Code/sdk
    • Platform android-30, build-tools 30.0.2
    • ANDROID_HOME = /Users/tahatesser/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.2)
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.2, Build version 12B45b
    • CocoaPods version 1.10.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.51.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (4 available)
    • Taha’s iPhone (mobile) • 00008020-001059882212002E • ios            • iOS
      14.2
    • macOS (desktop)        • macos                     • darwin-x64     •
      macOS 11.0.1 20B29 darwin-x64
    • Web Server (web)       • web-server                • web-javascript •
      Flutter Tools
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 86.0.4240.198

• No issues found!

No issue

flutter doctor -v

[✓] Flutter (Channel master, 1.24.0-8.0.pre.304, on macOS 11.0.1 20B29
    darwin-x64, locale en-GB)
    • Flutter version 1.24.0-8.0.pre.304 at
      /Users/tahatesser/Code/flutter_master
    • Framework revision c6290500f8 (13 hours ago), 2020-11-18 17:29:28 -0800
    • Engine revision 35a0b9fe68
    • Dart version 2.12.0 (build 2.12.0-50.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/tahatesser/Code/sdk
    • Platform android-30, build-tools 30.0.2
    • ANDROID_HOME = /Users/tahatesser/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.2)
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.2, Build version 12B45b
    • CocoaPods version 1.10.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.51.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (4 available)
    • Taha’s iPhone (mobile) • 00008020-001059882212002E • ios            • iOS
      14.2
    • macOS (desktop)        • macos                     • darwin-x64     •
      macOS 11.0.1 20B29 darwin-x64
    • Web Server (web)       • web-server                • web-javascript •
      Flutter Tools
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 86.0.4240.198

• No issues found!```

Can you please upgrade to the latest  master and try again
flutter channel master
flutter upgrade --force
flutter doctor -v
Thank you

Thanks @TahaTesser
It working fine mostly device on master channel but some device still stuck somtime..
Low performance devices in beta has improved in master, but stuck devices in beta still sometimes stuck(better than beta)
It happens more often on the iPhone than on Android
I think that seems to be related to memory, right?

Hi @taz1208
Thanks for confirming

@taz1208 thanks for repro, we are looking at issue now.

Update: @taz1208 verified that the large canvas allocation causing out of memory on iOS is fixed. However profiling your sample with master we found an opportunity to it up speed since it is generating large number of svgs.