After update to 4.0 lint errors are blocking the rendering

Describe the bug
With CRA 3.x lint errors where reported as warning in the console. Now it is blocking the rendering :

Expected behaviour
I would like to have by default the old behaviour (warning in console), or at least a way to switch back to this old behaviour

Edit:
@unframework give bellow a nice analysis about this issue:  https://github.com/facebook/create-react-app/issues/9887#issuecomment-720902192_
Solutions & workarounds

Implement a way to disable eslint in CRA builds/dev (env variables ...)
Use two eslint config files. One for text editor, and one for React.
Clean your code or change severity of eslint rules in your eslintrc file. (change them to warning for instance)

I always get these compile fails on eslint errors also in CRA 3.x (which is fine).

It depends. For example a simple console.log now also prevents compiling. This was not the case with 3.4.x. There is always the flag TSC_COMPILE_ON_ERROR=true you can set in your .env to compile anyways.

This also breaks on prop warnings, which is very intrusive during development. It would be nice if this could be fixed...

"We've upgraded to ESLint 7 and added many new rules...
https://github.com/facebook/create-react-app/blob/master/CHANGELOG.md#eslint

Maybe that is the reason for the new eslint errors.
To fix e.g. the parameter props assignment error, in package.json I put:
"eslintConfig": {
   "rules": {
     "no-param-reassign": [
       "error",
       {
         "props": false
       }
     ],
   }
}

"We've upgraded to ESLint 7 and added many new rules...
https://github.com/facebook/create-react-app/blob/master/CHANGELOG.md#eslint

Maybe that is the reason for the new eslint errors.
To fix e.g. the parameter props assignment error, in package.json I put:
"eslintConfig": {
   "rules": {
     "no-param-reassign": [
       "error",
       {
         "props": false
       }
     ],
   }
}

Add
emitWarning: true,
failOnError: false,
failOnWarning: false,

In config/webpack.config.js ->  ESLintPlugin
      new ESLintPlugin({
        // Plugin options
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        emitWarning: true, // new
        failOnError: false, // new
        failOnWarning: false, // new
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

failOnError: false, Don't do that... Skip warnings only

Even more, the compilation time became much longer because it now extends the ESlint config and runs lint on every change, which eliminates the speed of fast refresh. I used ESlint only as a part of lint-staged before and want to continue to use it as an optional thing that won't slow down compilation time.

Try with caching, again add
cache: true,
in ESLintPlugin options.

Fixed in this PR: https://github.com/facebook/create-react-app/pull/9911

There is a temporary workaround, but it works for me for now. I renamed .eslintrc to something else which is not findable by cra, like config.eslint.js. Then I changed all eslint scripts in package.json to eslint -c config.eslint.js ...rest of params. The only problem I have now is that my configuration is not working in my editor too, I mean fix eslint errors on save is not working and I should change the configuration file for my editor too. It may not worth it to change all of these also.

It feels like webpack.config.js should honour the SKIP_PREFLIGHT_CHECK environment variable something like this https://github.com/abraidwood/create-react-app/commit/bd71a1ffb6a8f46abaf08e71ebb33d196294cd78

In my case, the errors I got after upgrading were in files that are not included in the build - and thus weren't linted in v3.4.0 but somehow are in v4.0.0. Maybe this is what you're seeing too?

I encountered this issue yesterday 😕 Spend hours trying to understand what was going on. I had to downgrade to v3.4.4, now it's working fine ✨ I wish this issue can be fixed soon

Just want to post some extra context for anyone reading:
Originally CRA used its own config for linting files during build and did not consult main project eslintrc file at all. This was useful because a lot of the rules were not a style issue but actual runtime bugs (e.g. rules-of-hooks). Also, one could still tell CRA to use project's main lint config via the EXTEND_ESLINT option.
Then in CRA v4.0 that was consolidated (see https://github.com/facebook/create-react-app/pull/9587) - now EXTEND_ESLINT is the default. That removed a lot of ambiguity but now stylistic rule errors block dev build, which is what this thread is all about.
This is actually not such a big issue for initial CRA lint setup (since most rules in eslint-config-react-app are set to "warn") but for those of us using config presets like eslint-config-airbnb, etc, most of the rules are set to "error", and this starts to interrupt workflow. So, when people started upgrading to CRA v4.0, this behaviour began to be very noticeable.
Hopefully the above provides some background information for why this came up at this point in time.

I'd like to be able to disable CRA running of eslint completely.  I already have a git precommit hook that runs run eslint & prettier fixing for code layout then will block commit if further rules are failing.  I also have linting running on CI as a merge-blocking step (in case anyone disables the precommit hook).
I feel like CRA is dictating and restricting workflow with this change & that is unhelpful and beyond its scope.
I also don't see why it is enabled when SKIP_PREFLIGHT_CHECK is true. I'm also confused about that flag's purpose as in the code it looks like it disables another, separate path to eslint & I don't understand why there are two.

Do we have a confirmation that this only happens for people with custom configs?

Do we have a confirmation that this only happens for people with custom configs?

If I get rid of .eslintrc.js, I see the "old" behavior of compiling with warnings.  If I keep .eslintrc.js, any rules not set to "warn" in that file will result in "Failed to compile" with a listing of broken rules (the two rules I tested were no-unused-vars and no-debugger).

Do we have a confirmation that this only happens for people with custom configs?

I confirm for me too. In my case it come from my air-bnb extended eslint

+1 here on confirming the relationship to existing rules.
I have always had 'airbnb' in my extends list. It has been there for years on dozens of projects with CRA 3.
With CRA 4, it causes dev build to fail on unused variables. Removing airbnb fixes it.

I also get then no-console complier error, I fixed it by remove the old eslintrc.js and overrides rules in package.json:
  "eslintConfig": {
    "extends": [],
    "overrides": [
      {
        "files": [
          "**/*.ts?(x)"
        ],
        "rules": {
          "no-console": "off"
        }
      }
    ]
  },

@LuoTuxiu that worked for me too! Thanks for the suggestion 👌

I'm also seeing this issue - unfortunately none of the suggested solutions work. I had briefly thought that @LuoTuxiu's suggestion worked, but that's because I forgot to include the offending file 🤦♂

Updated to CRA v4 and started running into this as well. We have a more restrictive .eslintrc that was used to keep things like unintentional debugger and log statements out of production builds. But now those are throwing compile errors during the normal development process, which is rather cumbersome and slows things down.
We're going with a modified version of @jrr 's conditional config fix for now to allow us to use the more restrictive config only in our CI builds (https://github.com/facebook/create-react-app/issues/9929#issuecomment-719160209).

Just to leave my personal experience with my project and  this issue here.
I fixed this issue on my project by:

Cleaning my code: Fixing real eslint issues where it was needed
Setting rules severity to the appropriate level (warn for instance)

I wonder if this issue should just not be fixed ? I mean, an eslint "Error" should be treated as an error. So if in our project we consider a broken rule should not break the build or rendering .... Then it should probably be a "Warning" rule and not an
What do you think about it ?

@Poyoman39 I don't think thats a sensible approach.
There should be a difference between running the dev server and creating a production build. Having any lint errors break the build in dev server is a problem for a lot of people, because the development "flow" is grinding to a halt. But the production build should fail with linting errors.
Example: We really don't want any unused variables in our code base. But I think it should be ok while developing because there are many situations where you just comment something out and thus have an unused variable somewhere. A warning would be more than enough in this case.
Also, your linked "solution" is not feasible either, because it would mean that we would have to reconfigure all rules from the base ruleset for which we want to change the error level. Because a lot of rules have additional settings that need to be set in addition to the error level this would be close to completely redefining the config – extending a base config would be close to useless in that scenario. And, like I explained above, this would also change the configuration for the prod build or any other explicit linting check.
Imho the best idea is the second approach in your link – but that's something that would have to be change in create-react-app. Hence this issue.

For me and my team, this is a real issue. For exemple, we want to prevent commiting console.log, so we used to set it as an eslint error.
For now, our bypass is to manage 2 eslint config (thanks to lint-stage and husky) :

one for development, only with warning
one for commit, with error

That's not really ideal, but it allow us to develop peacefully and prevent from commiting mistake.

Any update about this issue when it will be fixed in CRA?

Workaround is to use craco.
craco.config.js
module.exports = function ({env, paths}) {
      configure: (webpackConfig, {env, paths}) => {
        const EXCLUDED_PLUGINS = ['ESLintWebpackPlugin']
        webpackConfig.plugins = webpackConfig.plugins.filter(
          plugin => !EXCLUDED_PLUGINS.includes(plugin.constructor.name),
        )
      }
}

I managed to disable eslint completely by changing the extensions line to extensions: []. Very happy.

Finally bootstrapping a new project with v4 and this caught me by surprise.
It completely breaks using Prettier with ESLint.

Completely broke my builds, had to manually override every rules to warning as I don't think using singlequote nor omitting a prop-type or two is build breaking

This is extremely annoying behaviour, and frankly, something as intrusive as this should be a choice left to the developer using the framework, NOT the maker of the framework.
Please give us the option to atleast configure this from within CRA without the need for ejecting out of CRA.

This is extremely annoying behaviour, and frankly, something as intrusive as this should be a choice left to the developer using the framework, NOT the maker of the framework.
Please give us the option to atleast configure this from within CRA without the need for ejecting out of CRA.

Yep, a configurable option would be nice. It's simply because of this annoying behavior that I have held out on upgrading to V4

This is extremely annoying behaviour, and frankly, something as intrusive as this should be a choice left to the developer using the framework, NOT the maker of the framework.
Please give us the option to atleast configure this from within CRA without the need for ejecting out of CRA.

Yep, a configurable option would be nice. It's simply because of this annoying behavior that I have held out on upgrading to V4

Yeah, me too. Only because of this issue, I didn't yet upgrade to v4 version

This issue fix is scheduled for 4.0.2. https://github.com/facebook/create-react-app/milestone/79

Either the releases page didn't mention this as a breaking change or I completely missed it before updating but this has been a huge waste of time for me, since it completely halted all work while I tried to fix my dev environment.
Reverting react scripts to 3.4.3 seems to be the ticket for now - since this issue will be fixed relatively soon.

Since the issue fix is scheduled for 4.0.2 I used patch-package to create a temporary workaround.

Follow the steps at patch-package set-up section

In node_modules\react-scripts\config\webpack.config.js you can change the ESLintPlugin config to allow compiling when has eslint erros adding failOnError as false (I also added emitWarning as true to see errors in console):

     new ESLintPlugin({
        // Plugin options
        failOnError: false, // add this line
        emitWarning: true,  // add this line
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        cache: true,
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

Then run npx patch-package react-scripts. This will create a patch to your project that whenever someone installs dependencies, it will change de webpack.config.js file at react-scripts folder.

Since the issue fix is scheduled for 4.0.2 I used patch-package to create a temporary workaround.

Follow the steps at patch-package set-up section

In node_modules\react-scripts\config\webpack.config.js you can change the ESLintPlugin config to allow compiling when has eslint erros adding failOnError as false (I also added emitWarning as true to see errors in console):

     new ESLintPlugin({
        // Plugin options
        failOnError: false, // add this line
        emitWarning: true,  // add this line
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        cache: true,
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

Then run npx patch-package react-scripts. This will create a patch to your project that whenever someone installs dependencies, it will change de webpack.config.js file at react-scripts folder.

Since the issue fix is scheduled for 4.0.2 I used patch-package to create a temporary workaround. You can do the following to fix the issue:

Follow the steps at patch-package set-up section
In node_modules\react-scripts\config\webpack.config.js you can change the ESLintPlugin config to allow compiling when has eslint erros adding failOnError as false (I also added emitWarning as true to see errors in console):

     new ESLintPlugin({
        // Plugin options
        failOnError: false, // add this line
        emitWarning: true,  // add this line
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        cache: true,
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

Then run npx patch-package react-scripts. This will create a patch to your project that whenever someone installs dependencies, it will change the webpack.config.js file at react-scripts folder.

Thank you very much @fernandaad, this helped a lot!

Since the issue fix is scheduled for 4.0.2 I used patch-package to create a temporary workaround. You can do the following to fix the issue:

Follow the steps at patch-package set-up section
In node_modules\react-scripts\config\webpack.config.js you can change the ESLintPlugin config to allow compiling when has eslint erros adding failOnError as false (I also added emitWarning as true to see errors in console):

     new ESLintPlugin({
        // Plugin options
        failOnError: false, // add this line
        emitWarning: true,  // add this line
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        cache: true,
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

Then run npx patch-package react-scripts. This will create a patch to your project that whenever someone installs dependencies, it will change the webpack.config.js file at react-scripts folder.

Thank you very much @fernandaad, this helped a lot!

Hi all, we've created a discussion around this - as we do plan to make changes soon. Please let us know what you'd like to prioritise, or if we've missed something.
https://github.com/facebook/create-react-app/discussions/10344

Hi all, we've created a discussion around this - as we do plan to make changes soon. Please let us know what you'd like to prioritise, or if we've missed something.
https://github.com/facebook/create-react-app/discussions/10344

In our setup it looks like our .eslintrc.json is ignored by the build. Yet, it is properly applied in VSCode.

In our setup it looks like our .eslintrc.json is ignored by the build. Yet, it is properly applied in VSCode.

I also get no-console complier error, I fixed it by remove the old eslintrc.js and overrides rules in package.json:
  "eslintConfig": {
    "extends": [],
    "overrides": [
      {
        "files": [
          "**/*.ts?(x)"
        ],
        "rules": {
          "no-console": "off"
        }
      }
    ]
  },

Thanks, but I fixed it after adding something to the extends field based on your solution.
"extends": [
	"react-app",
	"react-app/jest"
],

Hi everyone, you can now change this behaviour as of the latest react-scripts release, 4.0.2. There are two new flags, ESLINT_NO_DEV_ERRORS and DISABLE_ESLINT_PLUGIN.
Please see the PR #10170 or docs for more info!
https://create-react-app.dev/docs/advanced-configuration/

Forgive me if this sounds naiive, I'm a little new to create-react-app, but does the configuration text mentioned in the CRA ESLint documentation go in .eslintrc.<whatever> or somewhere else?

Forgive me if this sounds naiive, I'm a little new to create-react-app, but does the configuration text mentioned in the CRA ESLint documentation go in .eslintrc.<whatever> or somewhere else? I'm a little confused because it doesn't quite look like that's an eslint config file of its own, with the "eslintConfig" key being at the root.

Nevermind, I figured out it goes in package.json, I guess that makes sense.

@KyleRAnderson it can go in the root too if you prefer, as a valid ESLint config file.
Just keep in mind that the behaviour as of v4.0 is that your ESLint config is used within the Webpack ESLint Plugin, which means that errors will show in the error overlay (which is what this issue, and solution are about).

Awesome Work

Hi everyone, you can now change this behaviour as of the latest react-scripts release, 4.0.2. There are two new flags, ESLINT_NO_DEV_ERRORS and DISABLE_ESLINT_PLUGIN.
Please see the PR #10170 or docs for more info!
https://create-react-app.dev/docs/advanced-configuration/

Truly Awesome Work 👏🔥🔥

@KyleRAnderson it can go in the root too if you prefer, as a valid ESLint config file.
Just keep in mind that the behaviour as of v4.0 is that your ESLint config is used within the Webpack ESLint Plugin, which means that errors will show in the error overlay (which is what this issue, and solution are about).

Thank-you for clarifying, that makes a lot of sense, and thank-you for resolving this issue. It was something I was facing as well 😃

@mrmckeb possible related issue #10509

I'm also a bit new to CRA so I'm having troubles with this, I'm adding the new rule to my .env as says on the docs but when I try to run the dev server I keep geetting the errors that prevent the build. This is only happening with ESLINT_NO_DEV_ERRORS using DISABLE_ESLINT_PLUGIN does work. Thanks for the help

@CarlosHdez  -- I'm seeing the exact same behavior.
I have two files, .env and .env.production which look like the following:
.env
SKIP_PREFLIGHT_CHECK=true
ESLINT_NO_DEV_ERRORS=true

.env.production
SKIP_PREFLIGHT_CHECK=true
ESLINT_NO_DEV_ERRORS=true
PUBLIC_URL=/my-app

Unfortunately the ESLINT_NO_DEV_ERRORS does not work, while DISABLE_ESLINT_PLUGIN does.

Thanks for reporting this @cjones26 and @CarlosHdez. Are either of you able to provide a reproduction of this?
Using<EMAIL_ADDRESS>I'm able to confirm that this works with a few errors/warnings, but it could be to do with the number of errors... Or something else might be at play.
In this example, I have one error, one warning. With this flag, both are now warnings

@mrmckeb for some reason, I can see that all errors became warnings with the new flag in the terminal, but it still throws the error on the app error overlay. That's the point of this issue.

@rus-yurchenko, this was supposed to fix that, I'm sorry if you aren't seeing it fixed.
Can you please share a screenshot, or some more details? A reproduction would be ideal :)

@mrmckeb I left a comment with a Codesandbox Container example where the problem metioned by @rus-yurchenko can be reproduced. You can see it here

Thanks @miguelCT. Interestingly I can reproduce with only some errors, not all (maybe only TypeScript-related errors).
I'll keep investigating. I see they also made changes to the way this works in the plugin itself, which I also need to dig into:
https://github.com/webpack-contrib/eslint-webpack-plugin/blob/master/CHANGELOG.md#250-2021-02-04

Thanks @miguelCT. Interestingly I can reproduce with only some errors, not all (maybe only TypeScript-related errors).
I'll keep investigating. I see they also made changes to the way this works in the plugin itself, which I also need to dig into:
https://github.com/webpack-contrib/eslint-webpack-plugin/blob/master/CHANGELOG.md#250-2021-02-04

Would it still be helpful if we provided an example, or is the example provided by @miguelCT sufficient?

I still have the problem with eslint error cause dev server break:
node : 14.15.5
react scripts:  4.0.2
.env
ESLINT_NO_DEV_ERRORS=true
the error :
src\router\index.jsx
Line 13:1:  Unexpected console statement  no-console

Same here:
Failed to compile

src/lib/charger/Connection.ts
  Line 109:21:  Unexpected empty method 'setupMessaging'  @typescript-eslint/no-empty-function

Having .env:
ESLINT_NO_DEV_ERRORS=true

I saw this only set emitWarning to true on the plugin config.
There was a 2.5.0 release of the plugin that seems to have changed expectations:
https://github.com/webpack-contrib/eslint-webpack-plugin/commit/d38165bef1e2d73a9d53f42d80b926c9eab12707
Here are the options details: https://github.com/webpack-contrib/eslint-webpack-plugin#errors-and-warning
It seems we want failOnError to be false when ESLINT_NO_DEV_ERRORS is set.

I've confirmed this was caused by the release of<EMAIL_ADDRESS>(https://github.com/webpack-contrib/eslint-webpack-plugin/pull/72), as @maximeg said, and it seems it was intentional but they are looking at changing it.
To fix this, we need to two things:

We need to replace emitWarning with emitError and invert the flag.
We need to wait for this issue to be patched. There is an open issue (https://github.com/webpack-contrib/eslint-webpack-plugin/issues/84).

I'll take a look at the plugin and see if I can raise a fix for them today/tomorrow.

In the meantime...
If you're using Yarn, you can use resolutions to force this back to the previous version.
  "resolutions": {
    "eslint-webpack-plugin": "2.4.3"
  },

If using NPM, you could use npm-force-resolutions - although I believe this doesn't work with npm@7.
And there's also the option to disable the plugin completely until we resolve this, using DISABLE_ESLINT_PLUGIN=true.

There is another way to fix it temporarily with npm: I added "eslint-webpack-plugin": "2.4.3", to my package.json to force the version.

Thanks @targos, the reason I didn't suggest that is that it's not reliable - but you're right, it will work in some cases!
In other cases, users will still face this issue, as their dependency tree might look like this:
# Before
yarn list --pattern eslint-webpack-plugin                                                                                master
yarn list v1.22.5
└─<EMAIL_ADDRESS>✨  Done in 0.60s.

# After
yarn list --pattern eslint-webpack-plugin                                                                                master
yarn list v1.22.5
├─<EMAIL_ADDRESS>└─<EMAIL_ADDRESS>   └─<EMAIL_ADDRESS>✨  Done in 0.60s.

Just wanted to add that if using the DISABLE_ESLINT_PLUGIN=true option, rather than .env, you probably want it in your .env.development (and possibly .env.test). You likely DO want these errors failing react-scripts build for production builds.

I have same problem
I change React-Scripts version from 4.0.2 to 3.4.4, and add this SKIP_PREFLIGHT_CHECK=true into my .env file

Thanks @ehaynes99, this is definitely a viable workflow if you don't have CI checks in place. On my projects we would normally block merging to main if lint fails, so in a case like that you could always disable the plugin.
@davoodhobabi you shouldn't need to do that. But if you don't need anything from the 4.x branch, then that's a fine option too.

Updated:
Add
emitWarning: true,
failOnWarning: false,

In config/webpack.config.js -> ESLintPlugin
      new ESLintPlugin({
        // Plugin options
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        emitWarning: true, // new
        failOnWarning: false, // new
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

Question: for some reason, I don't have config/webpack.config.js inside my folders, and everything works fine. Except that I'm having the same problem as the people on this Issue, am I missing something?

OK, it looks like a fix is out and we're going to try to get that into CRA shortly.
https://github.com/facebook/create-react-app/pull/10590

Hi all, @iansu published 4.0.3 yesterday and this should resolve the issue for you. Please let us know if it doesn't!

Hi all, @iansu published 4.0.3 yesterday and this should resolve the issue for you. Please let us know if it doesn't!

It still exists.
I used create-react-app to create the project. Nothing in it. I just changed App.js to class component and set a state variable. On running npm start, it said state is not defined. I deleted the project and try this process from beginning again. However, it still exists. This error can be removed when I disable the eslint. But this is not solution. Please fix that. The react-script version is 4.0.3.

Thanks, it works perfect for me.
@channyeintun Did you add the env variable  ESLINT_NO_DEV_ERRORS=true

I set SKIP_PREFLIGHT_CHECK=true and
ESLINT_NO_DEV_ERRORS=true in .env file.

@channyeintun can you provide a reproduction of the issue ?

no-undef is a syntax error, not a linting error, so webpack fails to compile the module at all. This wouldn't have rendered under<EMAIL_ADDRESS>either.
If you fix your no-undef problems, but leave the no-unused-vars problem, it would fail under 4.0.2 but render with 4.0.3

Unsubscribe
在 2021-02-24 04:02:16，"Ashfaq Nisar"<EMAIL_ADDRESS>写道：
@channyeintun can you provide a reproduction of the issue ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@channyeintun It looks like you're only seeing the output in the console, so you're not seeing dev errors. Is it showing the overlay?

@mrmckeb
Thanks, yesterday, the problem exists. When I try today the create-react-app, there is no more errors and warnings. I think you guys solved it already.
@ehaynes99
There was no syntax errors.
For example, the state is actually ok. Just linting had some problems. It is now ok. Thanks

eject + emitError=false
works for me

eject + emitError=false
works for me

Now no error exists. It's fixed. No need to configure anything. Just execute create-react-app project-name.

@maksim-chekrishov We don't recommend ejecting, as you'll no longer receive updates from us - including security updates.
Try to eject only if you really need to modify the scripts/configs yourself and want to manage the configs/upgrades for yourself.

Hi @mrmckeb,
I'm not sure if the problem is related but upgrading to React 4.0.3 from 3.x gave us new errors blocking the build, same as the author of this thread.
While I'm not against blocking the build I don't understand why I cannot modify those errors in our eslintrc.json file.
It looks like upgrading to 4.X now ignore our local configuration. For exemple, adding "@typescript-eslint/ban-ts-ignore": "off", successfully removes the error from VScode but the build is still failing the same way.

Hi @vincentdesmares, that sounds like a setup issue - as it definitely shouldn't behave that way - but it may be a bug of course! Can you share a reproduction? I can investigate further :)

I will try to reproduce the issue in a standalone repository.
I'm very tempted to just trash my previous config and start clean but right now if I want to configure my app, the only reference that I found is https://create-react-app.dev/docs/setting-up-your-editor and the emplacement of the configuration is not explicitly specified.
What's the available configurations?

It should be anything that ESLint supports: https://eslint.org/docs/2.0.0/user-guide/configuring#configuration-file-formats
Just make sure it's not defined in your package.json too - as that's where we place it by default.

I'm still getting this issue in 4.0.3 -
Failed to compile.

src/scripts/components/App.tsx
  Line 7:8:     'Loading' is defined but never used                            @typescript-eslint/no-unused-vars

@stclairdaniel add ESLINT_NO_DEV_ERRORS=true in your .env, it will skip these errors in development

SOLUTION

remove <React.StrictMode> from index.tsx.
in tsconfig.json add compilerOptions: { strict: false }

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

That’s the expected behavior.  It’s the DEV in NO_DEV_ERRORS.  If you don’t want a particular error to break your build, you can turn off the specific linting rule in your eslint config.

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

That’s the expected behavior. It’s the DEV in NO_DEV_ERRORS. If you don’t want a particular error to break your build, you can turn off the specific linting rule in your eslint config.

Is there no build equivalent of ESLINT_NO_DEV_ERRORS? I don't want ANY lint errors to break my build, it's a style check, bad style should not be a reason for my deployment to suddenly be not building.  I shouldn't have to go through and change all my lint rules to warning instead of errors, especially because then our CI workflow won't notify us of the lint "failure"

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

That’s the expected behavior. It’s the DEV in NO_DEV_ERRORS. If you don’t want a particular error to break your build, you can turn off the specific linting rule in your eslint config.

Is there no build equivalent of ESLINT_NO_DEV_ERRORS? I don't want ANY lint errors to break my build, it's a style check, bad style should not be a reason for my deployment to suddenly be not building. I shouldn't have to go through and change all my lint rules to warning instead of errors, especially because then our CI workflow won't notify us of the lint "failure"

@Nerdsie There is.  Check out this PR.  The environment variable DISABLE_ESLINT_PLUGIN set to true will do what you want.

emitWarning: true,
failOnWarning: false,

This worked for me. See reference

Confirming @rswerve solution, here is my build npm script:
"build": "npx tsc --noEmit && DISABLE_ESLINT_PLUGIN=true CI=false react-scripts build",


chore(deps)!: upgrade to typescript-eslint v4

I followed the steps inside the changelog of typescript-eslint. Additionally, I've re-enabled a rule which used to report false positives, but should be fixed by now (see here).

Nice one @kripod - thank you!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cannot install on 4.2.6

Hello,
Composer throws an error when trying to install package for Laravel 4.2.6 - do you have another branch for 4.2 or?
Problem 1
    - Installation request for barryvdh/laravel-ide-helper 2.0 -> satisfiable by barryvdh/laravel-ide-helper[v2.0.0].
    - Conclusion: remove laravel/framework v4.2.6
    - barryvdh/laravel-ide-helper v2.0.0 requires illuminate/filesystem 5.0.x -> satisfiable by illuminate/filesystem[v5.0.0, v5.0.4].
    - don't install illuminate/filesystem v5.0.0|don't install laravel/framework v4.2.6
    - don't install illuminate/filesystem v5.0.4|don't install laravel/framework v4.2.6
    - Installation request for laravel/framework 4.2.6 -> satisfiable by laravel/framework[v4.2.6].

Yes


Can not generate SAS token using AZ CLI

I can not generate sas token because in the az iot hub --help, there is no generate sas token commands. Can anyone help me?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.


Enable more error prone checkes

BadInstanceof, CompareToZero, InconsistentHashCode, ObjectToString
#4188

Thanks!

@chhsiao90 thank you!
could you please update the https://github.com/prestosql/presto/issues/4188 to indicate which are done?

No problem :)


Design

Create a design for how the posts and the comments will look like
options to add, remove, upvote etc.

Already created


Use embeds for media queries and the like

This feature raises some flags w.r.t. the logic for finding embeddings. In particular, it does not currently handle nested embeddings (because it wasn't necessary so far). Why is that necessary for the feature being added here? Consider the following snippet:
<style>
@media screen {
  .foobar {
    color: green;
  }
}
</style>

Using the default CssLanguagePlugin and HtmlLanguagePlugin, this would first extract the embedded CSS:
<style>
wm-embed@abcd-8
</style>

@media screen {
  .foobar {
    color: green;
  }
}

but won't try to discover potential embeddings in the discovered embeddings.
For this reason, this Pull Request is blocked for now.


Switch to randomString form auto increment

future proof
non disclosure
unique across tables

Will use 8 (a balance between guarantee and share-length i.e. Twitter). 62**8, which is aboot 210 Trillion

[ ] prop validation


Exposed jitter_image in Python and added an example

Exposed jitter_image function in Python API along with an example.
This is useful while building datasets using the Python API.

Thanks for the PR.  I don't see anything wrong with the code but I do have a question.  What are you doing with the jittered images?  The DNN training API isn't exposed through python.  Are you planning on exposing part of that as well?

My thought was that jittering could be useful while building a dataset:

Get images for class
Align
Cluster
Jitter
Store

Another use, while training a classifier:
Let training data consist of m images with labels

For (image, label) in raw image training data
Jitter image n times
Get n representations from model (for the n jittered images)
Add to training data (descriptor_1, label), (descriptor_2, label), ...., (descriptor_n, label)
Repeat until all m images are done
Now training data has n x m (descriptor, label) entries
Train a classifier on the n x m dataset

I could consider porting the training part as well though the current C++ example serves me well.

You definitely don't want to store jittered images to disk.  Jittering is
much more efficiently done one the fly.
It makes sense for training models though.  My only reservation is that
this python interface to jittering is going to be really slow because of
all the list building.  So I would never use it myself and I'm generally
hesitant to put things in dlib that I wouldn't be willing to use.  Isn't
there a way to make returning an image to python more efficient?

I guess we could pass matrix<rgb_pixel> to Python. But at the end of the day, would still need to convert from that data structure to numpy array for OpenCV stuff.
I did think about the list construction, but at the end of the day, since rgb_pixel is a class, I am not sure we can do some kind of memory map.
It seems to me once would need to iterate through the pixels either in C++ like it is now or in Python to get to a Numpy image structure.
Do you have any better ideas? I could look into improving it.

Python list construction is much slower than looping over pixels in C++
since the python list involves a lot f pointer indirection, memory
allocations (this means mutex locks and system calls in most cases), page
faults, and so on.
I would either avoid using opencv entirely, thus allowing you to use a
matrix<rgb_pixel> directly, or figure out how to construct numpy objects
from C++ so you can copy the image into one of them in C++ code, which will
be thousands of times faster than doing all that list stuff.

I am able to return numpy arrays with the following code snippet:
#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
#include <numpy/ndarrayobject.h>

// ... previous code

boost::python::list get_jitter_images(object img, size_t num_jitters = 1, bool disturb_colors = false)
{
    if (!is_rgb_python_image(img))
        throw dlib::error("Unsupported image type, must be RGB image.");

    // Convert the image to matrix<rgb_pixel> for processing
    matrix<rgb_pixel> img_mat;
    assign_image(img_mat, numpy_rgb_image(img));

    // The top level list (containing 1 or more images) to return to python
    boost::python::list jitter_list;

    // Size of the numpy array
    npy_intp dims[3] = { num_rows(img_mat), num_columns(img_mat), 3};

    for (int i = 0; i < num_jitters; ++i) {
        // Get a jittered crop
        matrix<rgb_pixel> crop = dlib::jitter_image(img_mat, rnd_jitter);
        // If required disturb colors of the image
        if(disturb_colors)
            dlib::disturb_colors(crop, rnd_jitter);

        PyObject *pyObj = PyArray_SimpleNewFromData(3, dims, NPY_UINT8, image_data(crop));
        boost::python::handle<> handle(pyObj);
        // Append image to jittered image list
        jitter_list.append(object(handle));
    }

    return jitter_list;
}

BOOST_PYTHON_FUNCTION_OVERLOADS(get_jitter_images_with_defaults, get_jitter_images, 1, 3)

// ----------------------------------------------------------------------------------------
void bind_image_classes()
{
    using boost::python::arg;
    import_array();

    {
    class_<rgb_pixel>("rgb_pixel")
        .def(init<unsigned char,unsigned char,unsigned char>( (arg("red"),arg("green"),arg("blue")) ))
        .def("__str__", &print_rgb_pixel_str)
        .def("__repr__", &print_rgb_pixel_repr)
        .add_property("red", &rgb_pixel::red)
        .add_property("green", &rgb_pixel::green)
        .add_property("blue", &rgb_pixel::blue);
    }

    def("jitter_image", &get_jitter_images, get_jitter_images_with_defaults(
    "Takes an image and returns a list of jittered images."
    "The returned list contains num_jitters images (default is 1)."
    "If disturb_colors is set to True, the colors of the image are disturbed (default is False)",
    (arg("img"), arg("num_jitters"), arg("disturb_colors"))
    ));
}

I also changed the cmake file (tools/python/CMakeLists.txt) to check for presence of numpy:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12)

set(USE_SSE4_INSTRUCTIONS ON CACHE BOOL "Use SSE4 instructions")
# Make DLIB_ASSERT statements not abort the python interpreter, but just return an error.
add_definitions(-DDLIB_NO_ABORT_ON_2ND_FATAL_ERROR)

include(../../dlib/cmake_utils/add_python_module)

# Test for numpy
FIND_PACKAGE(PythonInterp)
IF(PYTHONINTERP_FOUND)
    EXECUTE_PROCESS( COMMAND ${PYTHON_EXECUTABLE} -c "import numpy" OUTPUT_QUIET ERROR_QUIET RESULT_VARIABLE NUMPYRC)
    IF(NUMPYRC EQUAL 1)
        MESSAGE(FATAL_ERROR "Python interpreter found but 'numpy' package not available")
    ELSE(NUMPYRC EQUAL 1)
        MESSAGE(STATUS "Found Python with installed numpy package")
        EXECUTE_PROCESS( COMMAND ${PYTHON_EXECUTABLE} -c "import sys; from numpy import get_include; sys.stdout.write(get_include())" OUTPUT_VARIABLE NUMPY_INCLUDE_PATH)
        MESSAGE(STATUS "Numpy include path '${NUMPY_INCLUDE_PATH}'")
        include_directories(${NUMPY_INCLUDE_PATH})
    ENDIF(NUMPYRC EQUAL 1)
ELSE(PYTHONINTERP_FOUND)
    MESSAGE(FATAL_ERROR "Could not find Python interpreter")
ENDIF(PYTHONINTERP_FOUND)

#include_directories($(python -c "from numpy import get_include; print(get_include())"))

add_definitions(-DDLIB_VERSION=${DLIB_VERSION})

# Tell cmake to compile all these cpp files into a dlib python module.
set(python_srcs
   src/dlib.cpp
   src/matrix.cpp
   src/vector.cpp
   src/svm_c_trainer.cpp
   src/svm_rank_trainer.cpp
   src/decision_functions.cpp
   src/other.cpp
   src/basic.cpp
   src/cca.cpp
   src/sequence_segmenter.cpp
   src/svm_struct.cpp
   src/image.cpp
   src/rectangles.cpp
   src/object_detection.cpp
   src/shape_predictor.cpp
   src/correlation_tracker.cpp
   src/face_recognition.cpp
   src/cnn_face_detector.cpp
)

# Only add the GUI module if requested
if(NOT ${DLIB_NO_GUI_SUPPORT})
   list(APPEND python_srcs src/gui.cpp)
endif(NOT ${DLIB_NO_GUI_SUPPORT})

add_python_module(dlib ${python_srcs})

# When you run "make install" we will copy the compiled dlib.so (or dlib.pyd)
# library file to the python_examples folder.
install_dlib_to(../../python_examples)

As long as the numpy module is installed via pip, `tools/python' can be built.
But I am facing a problem of the images not being correctly returned to Python. The returned object is an ndarray with the right dimensions but in certain instances only the blue channel is present and all other channel values are 0, resulting in a blue image.
Could you help spot the issue?

You aren't using PyArray_SimpleNewFromData right.  I googled that function and the manual tells you what's wrong with what you did.  I'm also not super excited about adding a numpy dependency.  Isn't it possible to return an appropriate buffer to python without making the dlib compile dependent on numpy headers?

@davisking thanks for pointing that out. Here is my modified function:
boost::python::list get_jitter_images(object img, size_t num_jitters = 1, bool disturb_colors = false)
{
    if (!is_rgb_python_image(img))
        throw dlib::error("Unsupported image type, must be RGB image.");

    // Convert the image to matrix<rgb_pixel> for processing
    matrix<rgb_pixel> img_mat;
    assign_image(img_mat, numpy_rgb_image(img));

    // The top level list (containing 1 or more images) to return to python
    boost::python::list jitter_list;

    // Size of the numpy array
    npy_intp dims[3] = { num_rows(img_mat), num_columns(img_mat), 3};

    for (int i = 0; i < num_jitters; ++i) {
        // Get a jittered crop
        matrix<rgb_pixel> crop = dlib::jitter_image(img_mat, rnd_jitter);
        // If required disturb colors of the image
        if(disturb_colors)
            dlib::disturb_colors(crop, rnd_jitter);

        void* img_data_copy = malloc(img_mat.nr() * width_step(crop));
        memcpy(img_data_copy, image_data(crop), img_mat.nr() * width_step(crop));
        PyObject *pyObj = PyArray_SimpleNewFromData(3, dims, NPY_UINT8, img_data_copy);
        PyArray_ENABLEFLAGS((PyArrayObject*)pyObj, NPY_ARRAY_OWNDATA);
        boost::python::handle<> handle(pyObj);
        // Append image to jittered image list
        jitter_list.append(object(handle));
    }

    return jitter_list;
}

There are many questions regarding returning a Numpy array from dlib including this old question:
https://sourceforge.net/p/dclib/discussion/442518/thread/533998a7/
I myself was hoping to return a Numpy array straightaway from the c++ code.
However, if you think adding Numpy dependency is undesirable, you can simply close this pull request.

Maybe adding a numpy dependency is fine.  It's not like you get very far in any reasonable python use without numpy anyway.  I have to think about it.

You can still use memcpy here, which yes, is probably faster.

@davisking I earlier tried a for loop (which worked), but since we get a pointer to the buffer, I changed to memcpy instead. So now we get a list of numpy arrays directly returned by this function.
The only concern I can think of is if someone is using a really old (incompatible) version of Numpy and they want to upgrade dlib.

@davisking I've made presence of Numpy during compilation optional. Also made sure that if Numpy is present, it can be v1.5.1 or later (which was released on Nov 18, 2010 - before the first release of dlib on Github)

@davisking what are your thoughts here concerning inclusion of Numpy? I can accordingly change the PR.

Sorry, been busy the last few days.
I think the PR is good.  Making it disable and continue to build successfully if numpy's headers aren't available is a good way to do it.  I'll look it over more carefully and merge it soon.

Thanks, look good :)


Only update non-terminal tasks on node removal.

- What I did
When a node is removed, its tasks are set in state ORPHANED. This does not need to be done for tasks that are already in a terminal state, and if all tasks in all states are updated, the size of the transaction may grow too large to process, and node removal becomes impossible.
This changes to only set non-terminal tasks to state ORPHANED, and terminal tasks are left alone.
- How I did it
Altered the orphanNodeTasks function in manager/controlapi/node.go to check if a task is in a terminal state before updating it.
- How to test it
Updated the unit test for that function to check correctness of the new behavior.
- Description for the changelog

Fixed an issue where nodes with lots of tasks could not be removed.

LGTM 👍


Add MaxLogsPerSpan option

Basictracer now supports a MaxLogPerSpan options; plumbing this option in
Lightstep as well.
Fixes #46.

It looks like the CI build is using an old basictracer-go (which doesn't build with the latest opentracing-go).

Yes, that happened with the previous build as well. I'll take a look.
On Fri, Sep 30, 2016 at 8:38 AM RaduBerinde<EMAIL_ADDRESS>wrote:

It looks like the CI build is using an old basictracer-go (which doesn't
build with the latest opentracing-go).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lightstep/lightstep-tracer-go/pull/47#issuecomment-250777160,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKeRmktMOTD1qWnXldNLwRh8dvmzEeMgks5qvSycgaJpZM4KJ5nj
.

The CircleCI cache needed to be flushed. Fixed!
On Fri, Sep 30, 2016 at 8:40 AM spoons<EMAIL_ADDRESS>wrote:

Yes, that happened with the previous build as well. I'll take a look.
On Fri, Sep 30, 2016 at 8:38 AM RaduBerinde<EMAIL_ADDRESS>wrote:

It looks like the CI build is using an old basictracer-go (which doesn't
build with the latest opentracing-go).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lightstep/lightstep-tracer-go/pull/47#issuecomment-250777160,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKeRmktMOTD1qWnXldNLwRh8dvmzEeMgks5qvSycgaJpZM4KJ5nj
.

Sorry I forgot about this...
On one hand, I'm not crazy about the way the second set of defaults is expressed here. On the other hand, I don't want to make you change that since it would affect BasicTracer as well. So we can merge this and potentially clean up the options stuff separately.

Thanks @bensigelman
I can do some cleanup, what do you have in mind? Exporting the default value from basictracer as a constant that we use here as well?

@RaduBerinde there's a lightstep-internal effort to canonicalize the semantics of tracer tuning options across platforms... until that's settled down, it's probably not worth the churn. (Aside from anything else, I'd rather do a "functional options" idiom for the initialization)


Only link library specific files

This is not compatible with CMake 3.10 (due to the use of generator expressions in install(CODE), requiring the setting of CMP0087). Can anyone think of a better method to do the same thing?

If using the temporary script works, I have no real objections to that approach.

Why are we running macOS tests?  @pfultz2 @saadrahim  should they block Liam

I updated the noted line, however CMake seems to be unable to locate cl on the new version.

CMake 3.10 is not aware of and does not support Visual Studio 2019. The earliest version which does is CMake 3.14. @pfultz2 preferred resolution?

We should then skip 3.10 on windows. There is a way to exclude combinations described here:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-excluding-configurations-from-a-matrix
There is also an if that can be added to skip steps:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsif

Let me adjust the required statuses so this can be merged.

Any idea why the macos tests aren't running?

Any idea why the macos tests aren't running?

No clue on the test queue, but I would at least vote to make the macos tests not required, are you ready to merge otherwise?    I don't even support running them until we actually have use cases on macos.    This fix is blocking downstream builds so hope it can get in today if you are happy with it so we can iterate if it causes some new issues.  @DanyiLin has a windows build pipeline consuming rocm-cmake so will be interesting to see if this will trigger it.

Perhaps try bumping it to macOS-10.15? I'm not certain where to find the supported platforms list for GitHub Actions, but macOS 10.14 isn't in Azure's list of Microsoft-hosted agents.


Reintroduce Docsy as a submodule

This PR reintroduces Docsy as a submodule so that it will be easier to manage upgrades.
Details: this PR ...

Contributes to #123
Eliminates the "hardcoded" files under website/themes/docsy, unlinked (via a git submodule or otherwise) to any Docsy repo
Eliminates the Bootstrap and FontAwesome (FA) submodules
Adds https://github.com/google/docsy/commit/e67775a312f1f3ad32137423fe2b311a397f5293 as a submodule, which itself has Bootstrap and FA as submodules. For the rationale, see below.
Updates NPM scripts to support building the website under this new setup
There is no effective change to the rendered site. For details, read below.

Preview: https://deploy-preview-160--tag-env-sustainability.netlify.app/

Context
The files under website/themes/docsy were a copy of https://github.com/google/docsy/commit/f69a99d7e38a541b74ade9850a813aee26964ba8. But that commit is a fork commit based on https://github.com/google/docsy/commit/e67775a312f1f3ad32137423fe2b311a397f5293 from the official Docsy repo, with the following overrides:
Only in tmp/docsy: .git
Only in tmp/docsy: .gitmodules
Only in themes/docsy: .hugo_build.lock
diff --exclude=userguide --exclude=vendor -r themes/docsy/assets/scss/main.scss tmp/docsy/assets/scss/main.scss
36,37c36
<     overflow: auto;
<
---
>
diff --exclude=userguide --exclude=vendor -r themes/docsy/layouts/partials/footer.html tmp/docsy/layouts/partials/footer.html
5c5
<

---
>

12c12
<

---
>

19c19
<

---
>

23,25c23,24
<     {{ with .Site.GetPage "about" }}
{{ .Title }}
{{ end }}
<   {{ end }}
<         {{ partial "hooks/footer-end.html" . }}
---
> 		{{ with .Site.GetPage "about" }}
{{ .Title }}
{{ end }}
> 	{{ end }}
Only in themes/docsy/layouts/partials/hooks: footer-end.html

Regarding the diffs shown above:

themes/docsy/layouts/partials/footer.html it is completely overridden by website/layouts/partials/footer.html and so the diff shown above is irrelevant, as is the deletion of footer-end.html -- which isn't used by website/layouts/partials/footer.html

overflow: auto in the footer gets set in website/themes/docsy/assets/scss/main.scss (see site-diff below), gets overridden by https://github.com/cncf/tag-env-sustainability/blob/38cb8316e393d7f1ce3eb53d86e0bb642992a3f5/website/assets/scss/_footer.scss#L2-L4
The website/assets/scss/_footer.scss file gets included via https://github.com/cncf/tag-env-sustainability/blob/38cb8316e393d7f1ce3eb53d86e0bb642992a3f5/website/assets/scss/_styles_project.scss#L14
So the SCSS diff has no visible effect.

Consequently I'm going to use the official Docsy commit  https://github.com/google/docsy/commit/e67775a312f1f3ad32137423fe2b311a397f5293 as a basis for this repo's Docsy submodule.
No change to the rendered tag-env-sustainability site
If you build the site from this PR using the following command npm run serve:dev (which serves to disk), you'll see only one minor diff:
$ npm run serve:dev
... # Terminate serve command once site has been generated to disk ^C
$ (cd public && git diff -- . ':(exclude)*.map')
... # Output shown below
$

Here's the diff output:
diff --git a/scss/main.css b/scss/main.css
index 2b42976..c0ea53c 100644
--- a/scss/main.css
+++ b/scss/main.css
@@ -14008,8 +14008,7 @@ div.toc-header {
     border-color: #403F4C; }

 footer {
-  min-height: 150px;
-  overflow: auto; }
+  min-height: 150px; }
   @media (max-width: 991.98px) {
     footer {
       min-height: 200px; } }

The override of footer's overflow is confirmed by examining CSS in dev tools when we examine the website prior to the changes in this PR:

Related
@aliok did a great job analyzing the situation for tag-contributor-strategy, though the situation was slightly different. For details, see https://github.com/cncf/tag-contributor-strategy/pull/399.
/cc @nate-double-u @caniszczyk @cjyabraham

(I'll fix the DCO soon.)

Thanks for the review Chris. I'm unsure that the informal review policy is here, but with one approval I'm going merge and continue working on the Docsy upgrade. Comments are still welcome.

For the record, both the original build of this PR and the build of the main branch (post merge) required that the cache be cleared (due to git submodule changes). I've done that in both cases, and the main build is green again:


Result type unknown in SQL query using IIF

Describe the bug
Based on the value of some column A, I want to return either the value or null for column B.
I tried to be more compact by using SQLite's IIF, but when building Drift informs me that:
line 206, column 9: Expression has an unknown type, the generated code can be inaccurate.

I was already thinking about using a completely different method, but then I tried it using a CASE statement, and the build runner now ran successfully, and correctly inferred that the datatype of my resulting row should be int?.
(the original column B is already a nullable int, if that matters)
SELECT
  CASE
    WHEN a = 'foo' THEN b
    ELSE NULL
  END b_value -- The build runner realises b_value is of type 'int?'
FROM table;

SELECT
  IIF(a = 'foo', b, NULL) b_value -- The build runner doesn't know b_value's type
FROM table

It's no big deal for me right now, but I thought to report it anyways: I guess the evaluation of these statements may differ quite a bit under the hood, though I use them interchangably in my example.
And a final remark: Initially, I tried to help the build_runner by telling it that the resulting type should be an int?, but I couldn't get it to work or find any documentation on it. If it is in fact possible, it'd be nice to have some documentation on this. If not, then it's fine as it is I guess :)

You're right, type analysis support for IIF was missing. I've fixed it in this repository, but those changes haven't been released yet.
As a workaround in the meantime, you could add an explicit CAST around the IIF or use a CASE WHEN expression.
Closing this as a duplicate of https://github.com/simolus3/drift/issues/2392.


Docker encoding issue file read

The following code will result in an ascii encoding error when trying to execute in container:
https://github.com/ml-research/rational_activations/blob/8efb850a49f5feaea669794aa9ef977fed8b7df5/setup.py#L115-L119

Suggestion:
adding the following file opening code for a file should fix the issue when in a container:
with open(FILENAME, "rb") as fh:

One could also just assign empty string to the variables:
long_description = ""
and
requirements = fh.readlines()
and then pip3 install -r requirements.txt
Thanks for the feedback, I am closing

One could also just assign empty string to the variables:
long_description = ""
and
requirements = fh.readlines()
and then pip3 install -r requirements.txt
Thanks for the feedback, I am closing


adding support on Jacoco report

Jacoco is quite popular for java code coverage. Hope this tool could add support for Jacoco

Because of the lacking mercurial support I created an alternative tool, using Node.js, diff-test-coverage.
Supported coverage report formats:

lcov
cobertura
clover
jacoco
golang-cover

Supported source control systems:

Git
Mercurial
Anything else that produces unified diffs.

@peterg79 added jacoco support! https://pypi.org/project/diff_cover/1.0.5/


fix: removes exportAs key

Pull Request Template
📲 What
Removes exportAs as it's not being used we think, and it's no longer in taskctl.
🤔 Why
To fix the local builds
🛠 How
👀 Evidence
🕵 How to test
Notes for QA

/azp run


Object Sphere Center

Hello
How the center of the object sphere is determined?

Please refer to the paper illustration and the function.
For convenience, we directly provide the solutions to the geometry equations.
The depth estimation is bounded by the prior human-object relative depth relations labeled by humans (min-z, max-z), e.g., for hold-cup, the cup would not be too far from the human.

I meant the center of the sphere, not its depth and radius

How to get the optical center C?

I meant the center of the sphere, not its depth and radius
--I meant x_o, y_o, z_o too.
z_o is decided by the depth. The sphere is tangent to the two planes P1 and P2, then the sphere center will fall on the P_ABC including x_o and y_o. x_o and y_o are easy to locate because we can find the clues from the 2d boxes and C locations. But depth is hard, so we also define a boundary for it from human priors.
Camera parameters come from the SMPLify-x, like focal length, C.


Wrap io errs for kodata layer

Fixes https://github.com/google/ko/issues/319
This is untested. The new io/fs stuff might make this easier, but I'm too lazy to try it out.
@benmoss would this have helped?

Codecov Report

Merging #320 (c639cb7) into main (a6442e6) will decrease coverage by 0.09%.
The diff coverage is 12.50%.

@@            Coverage Diff             @@
##             main     #320      +/-   ##
==========================================
- Coverage   38.07%   37.97%   -0.10%
==========================================
  Files          33       33
  Lines        1513     1514       +1
==========================================
- Hits          576      575       -1
- Misses        844      845       +1
- Partials       93       94       +1

Impacted Files
Coverage Δ

pkg/build/gobuild.go
59.24% <12.50%> (-0.47%)
:arrow_down:

Continue to review full report at Codecov.

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

Not much because of the re-assignment of hostPath on the line immediately preceding where you print it :)
2021/02/25 11:41:43 error processing import paths in "config/core/999-cache.yaml": error resolving image references: filepath.EvalSymlinks(""): not a directory

Not much because of the re-assignment of hostPath on the line immediately preceding where you print it :)

🤦
One more try? 😄

yay
2021/02/25 12:07:26 error processing import paths in "config/core/999-cache.yaml": error resolving image references: filepath.EvalSymlinks("/home/cesium/workspace/serving/cmd/queue/kodata/HEAD"): not a directory


When will limitations be fixed?

It's been over a year since last release. When will the limitations be fixed. In particular not being able to use 'group by' greatly hampers queries.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a6289377-8b4b-733b-8b32-78bdb289e3bb
Version Independent ID: fb3d012e-c4cd-06c8-673c-c3d51c879c76
Content: Azure Cosmos DB SQL API client library for Python
Content Source: docs-ref-services/latest/cosmos-readme.md
Service: cosmos
Product: azure
Technology: azure
GitHub Login: @maggiepint
Microsoft Alias: magpint

Thanks for the feedback, we’ll investigate asap.

Hello @docgregt
Currently we do not have a date for any new feature, which means that the limitations will continue for longer. We would like to provide dates for each limitation but it's not possible now. Can you ping me again by the end of the year? Tks

Ok.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Rodrigo Souza @.>
Sent: Tuesday, September 7, 2021 3:17:38 PM
To: Azure/azure-sdk-for-python @.>
Cc: Greg Turner @.>; Mention @.>
Subject: Re: [Azure/azure-sdk-for-python] When will limitations be fixed? (#20497)
Hello @docgregthttps://github.com/docgregt
Currently we do not have a date for any new feature, which means that the limitations will continue for longer. We would like to provide dates for each limitation but it's not possible now. Can you ping me again by the end of the year? Tks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-sdk-for-python/issues/20497#issuecomment-914595638, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKKWSHYFD2WWLLPJ5HD2FATUAZXOFANCNFSM5DFT3LVA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Hello @docgregt
Currently we do not have a date for any new feature, which means that the limitations will continue for longer. We would like to provide dates for each limitation but it's not possible now. Can you ping me again by the end of the year? Tks

It's well over a year and a half since the last update of this message. I'm wondering if there's been any progress on a date for GROUP BY?

Agreed - Not having the ability to use GROUP BY and aggregations in python SDK queries is a huge limitation. Is there any update on when this will be available?

@simorenoh can add details...

@James-Beckwith @metamoof @docgregt
Thank you all for showing interest in this feature, a lot had been going on this last year with the team. While we can't provide an estimate for a date yet, we have been knocking out several other limitations, bugs, and improvements - and I assure you this item is in the backlog.
If I get any concrete updates, I'll be sure to keep updating this thread. Thank you all for your patience!
@JericHunter @gahl-levy

"we have been knocking out several other limitations, bugs, and improvements"...please provide link to all of these and please not the blog posts as those dont cover much.

@docgregt Sure, I'll attach some of them here. Our Changelog file should also outline all the things we've been up to - anything after release 4.3.0b1 is new changes: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/cosmos/azure-cosmos/CHANGELOG.md
General Limitations
New Cosmos Asynchronous client: https://github.com/Azure/azure-sdk-for-python/pull/21404
Split-proof sync client: https://github.com/Azure/azure-sdk-for-python/pull/22237
Split-proof async client: https://github.com/Azure/azure-sdk-for-python/pull/22261
Control Plane Limitations
Add ability to use cosmos integrated cache: https://github.com/Azure/azure-sdk-for-python/pull/22946
Security Improvements/ Limitations
AAD Authentication for the sync client: https://github.com/Azure/azure-sdk-for-python/pull/23604
AAD Authentication for the async client: https://github.com/Azure/azure-sdk-for-python/pull/23717
Bug-fixes
Use account's default consistency as opposed to Session for default: https://github.com/Azure/azure-sdk-for-python/pull/22792
There's a bunch of other PRs and work that has been done, so if the CHANGELOG feels like not enough I encourage you to filter by closed pr's with the tag cosmos, and you should be able to see what we've been up to.


Concurrency issues investigation

Problem statement
The performance team has found that the influxdb3 process does not handle concurrency well. In https://github.com/influxdata/influxdb/pull/25604 we made a change very similar to what was done in IOx to move the query planning off of the main IO thread pool, but this did not improve things and instead seems to have lead to a regression (see https://github.com/influxdata/influxdb/issues/25562#issuecomment-2516135217).
This issue is for investigating why the system is breaking down under concurrent loads.
Ideas
Not configuring the main tokio runtime
Here we initialize the tokio runtime using the defaults: https://github.com/influxdata/influxdb/blob/0daa3f2f1d780aa846fbe39ee4f402e16bbeac5a/influxdb3/src/main.rs#L116
This means that the tokio runtime is initializing with as many threads as there are CPU cores, so it could be competing with  the DataFusion runtime as a result.
Hard-coding the query concurrency semaphore to 10
Here we hard-code the query concurrency semaphore for the: https://github.com/influxdata/influxdb/blob/0daa3f2f1d780aa846fbe39ee4f402e16bbeac5a/influxdb3/src/commands/serve.rs#L518
This sets the semaphore limit here: https://github.com/influxdata/influxdb/blob/0daa3f2f1d780aa846fbe39ee4f402e16bbeac5a/influxdb3_server/src/query_executor.rs#L95-L96
Which is supposedly used by the flight service here: https://github.com/influxdata/influxdb/blob/0daa3f2f1d780aa846fbe39ee4f402e16bbeac5a/influxdb3_server/src/query_executor.rs#L353-L358

Should we do away with the query concurrency semaphore? I worry about if it unnecessarily slows things down if a query is waiting on IO (i.e. another query could be executing, but won't because of the semaphore).
There's definitely a point where we'll want to park incoming requests because of maxed out resource utilization, I just doubt that a semaphore is the best primitive for this. I'd rather just remove it for now and address query throttling later.

Might be relevant as I think we synced this change over from Pro, but we did enable IO on the dedicated executor because without it we had crashes and the default to not have it enabled is from IOx. This was part of their split of having separate executors. I wonder if it makes sense to have just one executor to avoid contention in Monolith at least.
https://github.com/influxdata/influxdb_pro/pull/174

Let's remove the semaphore completely. One less thing to confound the investigation.

Let's remove the semaphore completely. One less thing to confound the investigation.

Can try to remove completely but I'm not sure it can be because it is relied on by core traits used in the Flight service. But I think setting it to u16::MAX should have the desired effect.

Can we run it through a profiler to see where it's spending the time (maybe on the box that perf team are using)?

It looks like IOx does this in the querier by setting the limit to u16::MAX

That was incorrect, IOx doesn't set u16::MAX as the limit, that is just the limit that they impose. IOx uses the default as 10, however, their scenario is different given that that default is set on a per-querier basis, so for us, it may make sense to remove the limit by default, but still allow it to be configurable. I will open an issue to deal with that specifically.

I opened https://github.com/influxdata/influxdb/issues/25627

@hiltontj fyi only - the concurrency issue is global across the product and just for Last value cache. The details I have observed is,

Even with concurrent query load of 2, the CPU cores are utilized to 95-99% on a large machine (2 cores and 8 GiB RAM)and increase in the latency is observed
To ensure this is not a limitation by the machine used, tried the same experiment on 2XLarge machine (8 cores and 32 GiB RAM) and still observed the CPU usage of 95-99% with increase in the latency

As the next step,
Taking the latest build of PRO, and retrying the concurrency problems with Large, 2XL, 8XL machine configurations

Something that I noticed was that the TokioDatafusionConfig that we utilize from influxdb3_core has IO disabled (see here).
This likely does not bode well for us. In IOx, it seems that all IO that could happen from within a query context is spawned onto the main IO runtime using this function.
Initially, in https://github.com/influxdata/influxdb/pull/25604, I thought the only IO in IOx was for communication with the catalog, which we don't need IO for in monolith since the catalog is in memory. However, I missed that IOx also spawns requests to the object store on the IO runtime (see here) when fetching parquet files. That makes sense, as that would be an important IO operation within the context of a query.
Therefore, the changes in https://github.com/influxdata/influxdb/pull/25604 are incomplete. We need to decide if we are going to stick to separate runtimes for IO/DataFusion, or switch to a single runtime. That will inform how to sort this out.


if n_samples is large , certain outlier model error rate 200% higher

Hi, YZhao;
I was writing to one possible isuue: in example notebooks compare all models, if the n_samples change to a big number, for example : 10*5 or larger. certain model OD result is totally wrong.
Note: I noticed there is a similar issue. Problem in CBLOF when the number of clusters is big and the train set has too many repeated value #53. But my found should be differnet, so post is as well.
Here is isssue:

the default n_sample  =200, outlier_fraction = 0.25. That means od ground trun point is 50.  After change the n_sample to 10**5, the ground true outlier point should be 25000.
However, following models error higher that the groud true OD points. they were:
Feature Bagging:  35259
Local Outlier Factor (LOF) 36144
Locally Selective Combination (LSCP) 37276
below is the screen capture.

I guess it might related to the dataset type. Doest it mean the simulation data similar to the
"glass", "optdigits" sample date? why the other estimator did not show such higher error rate?
Looking forward your kindly response！
Last but not least, I was know PYOD existed from zhihu. It is a excellent tools, especialy, I have access to more OD resources link for your github. Your work is awesome!
Recently, i has begun to try use some model it in one of my general OD automation tools.(which use docker, and airflow for platform).  dataset type, and dataset qty are two of point need considered.
WangYong
<EMAIL_ADDRESS>

Hi Wang,
Interesting. LSCP example uses LOF as the base detectors so the result is not surprising if LOF fails to work.
My guess is the parameter choice. LOF depends on n_neighbors to define the local region. By the synthetic data we are using, 25,000 points are condensed and the locality assumption may be violated. What about using a larger n_neighbors in LOF.
Would you able to share the actual code so I could take a look?
Thanks,
Yue

I just use the defauly notebook. Only change the n_samples number from 200 to 10**5.
This morning, I tried change the n_neighbour to sqrt of n_samples, but not feedback, not appropriate parameter for fitting. So, only change it to 100. Looks not significant improvoment yet.
Here is tow notebooks for your reference.
notebooks.zip

Thanks for the info. Will do some investigation :) Stay tuned.

Hi there,
I just checked the file and realized the example is just for demo purpose. The reason why certain models do not work is data dependent and impacted by the model parameter.
when setting n==10^5, there are too many outliers (too condensed) as the generation algorithm is fixed the range in 0.3 * normal distribution. The local algorithms like LOF won't work well. Featurebagging and LSCP both use LOF as base detector so they fail to work as well.
However, if you let outliers to spread sparsely by setting outliers_fraction to a small number like below, they will work perfectly.
# Define the number of inliers and outliers
n_samples = 5000
outliers_fraction = 0.01

The ultimate cause is due to LOF's reachability definition, and you are welcome to take the original paper for more info:  http://www.dbs.ifi.lmu.de/Publikationen/Papers/LOF.pdf

Hi,
Thanks for you rapid answer. It do help me. Thank you.
I will spend time to study the paper later.

Perfect. Feel free to drop any question.


Question on Tutorial 3 (rnn output explanation)

Hi,
the tutorial gives the following interpretation/explanation for the output of rnn :
You can think of the third axis as being the forward and backward hidden states stacked on top of each other
But here I would like to ask for some help. I would understand this as a concatenation rather than as stacking. Do we say the same think with other words?
To me stacking would be a kind of nesting for example if we had [src sent len, batch size, hid dim , num directions] instead of [src sent len, batch size, hid dim * num directions] .  Could you elaborate?
Thanks!

Yeah, concatenation would be a better term - not sure why I originally said "stacking". Must be the way I picture it. I'll look into changing it.

In flair (nlp library) they use the same term. For example they use the term StackedEmbeddings, where it means concatenate the embeddings, as I discovered. So it may makes sense. (But I found it a bit confusing). Thanks for the answer!

Yeah, I think because the order they are concatenated is always forward:backward I have this image in my head of the forward hidden states being "under" the backward hidden states. Concatenation is a much better term, I think calling it stacking just confuses things with multi-layer RNNs when those are actually stacked on top of each other (as they process data up the stack from the first layer to the last).
I'll change it tonight.


Holiday Rescheduling (FINERACT-1313)

Description

See details of the issue resolved on the following Apache Fineract JIRA ticket.
An article has been written on this.
Corresponding UI change is here.

Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[ ] Write the commit message as per https://github.com/apache/fineract/#pull-requests

[ ] Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

[ ] Create/update unit or integration tests for verifying the changes made.

[ ] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.

[ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/api-docs/apiLive.htm with details of any API changes

[ ] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

@francisguchie  and @bharathc27  Please can you find time to test this one functionally? Looks interesting.

Is there a UI component to this?
@ptuomola  Do you have an opinion?

Is there a UI component to this? @Cadreia  @xurror ??

Is there a UI component to this? @Cadreia  @xurror ??

For this feature, there is no actual need for a UI change as it just an improvement on the loan rescheduling algorithm and nothing around the API.
The improvement is more at the level of improving the holiday rescheduling algorithm to work better with long holidays as in the past, the feature would accumulate unpaid loans during holiday periods to a single on the next working day.
With this update, the loans schedule instead get extended.

For this feature, there is no actual need for a UI change as it just an improvement on the loan rescheduling algorithm and nothing around the API.
The improvement is more at the level of improving the holiday rescheduling algorithm to work better with long holidays as in the past, the feature would accumulate unpaid loans during holiday periods to a single on the next working day.
With this update, the loans schedule instead get extended.
So same UI from before works for this.

I have not used the reschedule before but if this is what is being updated, its a +1 from me - This is really a good improvement

This feature is part of a strategy of keeping Fineract vaccinated against pandemic. Read more here.. https://research.muellners.org/holiday-rescheduling/


No enterprise_extensions.setup_sampler in model_utils

I get an error when running the last part of gwa_tutorial.ipynb "Now, the easy way to do all of this" during the sampler_setup step that model_utils doesn't have setup_sampler.
# Setup a sampler instance.
# This will add some fanicer stuff than before, like prior draws,
# and custom sample groupings.
sampler = model_utils.setup_sampler(pta, outdir=outdir, resume=False)

If I replace model_utils with sampler and import sampler from enterprise_extensions earlier, then it works. I found this by grepping in enterprise_exentions, so I don't know if this is the Right Thing To Do. There is also a sampler_setup in hypermodel.

I made a pull request for my fix: #3

Thanks @kayhangultekin. There were some API changes to enterprise_extensions which are probably being reflected here.

Your fix looks good for this notebook, @kayhangultekin . The hypermodel sampler_setupis more relevant to model selection analyses in the second notebook.


Improve code style

helper functions for send error and success
alias for env data
add .env.example file
seperate dev and prod environment
using alias for http codes

I think there is no need to require status codes utility/helpers.js
It is required because sendError will receive a param, status which will be BAD_REQUEST, etc. and in res.status(status), status will be derived from the alias to get the corresponding code!!

I think there is no need to require status codes utility/helpers.js

It is required because sendError will receive a param, status which will be BAD_REQUEST, etc. and in res.status(status), status will be derived from the alias to get the corresponding code!!

I think there is no need to require status codes utility/helpers.js

It is required because sendError will receive a param, status which will be BAD_REQUEST, etc. and in res.status(status), status will be derived from the alias to get the corresponding code!!

Value of BAD_REQUEST will be passed on with the function that will stick to status variable.

I think there is no need to require status codes utility/helpers.js

It is required because sendError will receive a param, status which will be BAD_REQUEST, etc. and in res.status(status), status will be derived from the alias to get the corresponding code!!

Value of BAD_REQUEST will be passed on with the function that will stick to status variable.

okay, got it!


Add rust.cargoEnv configuration key

rust.cargoEnv can be used to set custom environment variables when running
cargo. This is useful for compiling some crates like openssl-sys.
For example to compile openssl-sys on osx with openssl from homebrew, the
following can be set in settings.json:
"rust.cargoEnv": {
    "OPENSSL_INCLUDE_DIR": "/usr/local/opt/openssl/include",
    "OPENSSL_LIB_DIR": "/usr/local/opt/openssl/lib"
}

👍


I successfully integrated summer note to this app but not able to fetch data

I added summernote to my application for blog but i am getting HTML tags to the front end. I applied styles and fonts to text in the editor. I successfully saved it in data base but not able render fonts and text in front end. Instead i am getting text with bunch of html code.

hackathon-stater is using pug for the frontend rendering.  I would suggest searching in pug documentation or issues for how to do what you are trying to achieve.


covid19cellatlas - SARSCoV2ResponseDynamics

Project short name:
SARSCoV2ResponseDynamics
Primary Wrangler:
Ida
Secondary Wrangler:

Associated files

Google Drive: folder

Published study links

Paper: Human SARS-CoV-2 challenge resolves local and systemic response dynamics

Accessioned data:

PBMC
Nasal

Ingest
Key Events

[ ] Convert published metadata to HCA spreadsheet
[ ] Manually curate dataset to meet HCA metadata standard
[ ] Collect any matrix and cell-type annotation files
[ ] Are the analysis files suitable for CellxGene? If something is missing get in touch with the authors to request it
[ ] Upload sheet to validate metadata
[ ] Transfer raw files to ingest to validate data files
[ ] Check linking using ingest graph validator
[ ] Ask the Secondary Wrangler for an end-to-end review of the project. Ask the Expertise Wrangler to review specific tabs if needed
[ ] Submit dataset to Production
[ ] Complete the Export SOP
[ ] Convert project data to SCEA format following the SCEA conversion SOP if appropriate

ideally we should request a term for nasal swab but for now I'm using nasal brush which is quite close in practice

graph valid and ready for secondary review

Hi Ida,
Great job with the dataset! Minor comments

Project
we don't have the EGA ID yet? or DUOS-Id?
Project-HCA bionetworks is empty- is that what you intended?
Project-Funders
You could include the EUH2020 Marie-Curie grant, AMR, MRC etc
Donor organism
Typos in column B- 'partecipant'
I cannot see where the ETHNICITY is mentioned to be European for white individuals
Dissociation
this looks tricky. To me it seems a mix of mechanical and enzymatic like enzymatic dissociation but mechanically. Can the steps until the Accutase treatment be considered mechanical?
Enrichment
Cell B8 is empty
in 'cell_size_selection' would be it any better to have '40' in the MINIMUM SIZE SELECTED and '70' in the 'MAXIMUM SIZE SELECTED'
**Computational method'
Can COMPUTATIONAL METHOD be added for the 'processed_matrix_generation'


Rename or close repo

SOOOOO many time my coworkers and I have confused this repo for the real one. GO AWAY 👎  I just spent a half hour reading the wrong docs. You owe me money 💰

With all the respect, this was the original repo and it was the first one. The repo you are referring to it was a clone of this one and it is using a similar name

All right, all right. I apologize tiberian. Cheers.

it is ok, no problem, it is also my fault, I should write I don’t update this repo and people should also look on the other one which is more updated. I promise I will do that

🍝


Multiple Pattern Fix + jMutRepair improvement

fixed #94 and #85 wrt jMutRepair

Hi @martinezmatias ,
I have a doubt about designing test cases. I think I've two options right now:

Use @BeforeAll to process all the input files at once. After that, we just need to analyze the results in each of the test cases. Hence, the heavy processing is done only once.
The other is the usual choice of dividing files into different sets of test cases. This may result in a repetition of the same file as well as the processing of the same file more than once.

WDYT?

I think this should complete Nopol and jMutRepair modules


CodeGen doesn't support common types in v4 & v5

For the new common types v4 and v5, some properties were specified the format, which caused the CodeGen can't indicate these types as common types.

Here is a sample https://github.com/Azure/azure-sdk-for-net/pull/37213 which have to use directive to mitigate

Done


FIX-216: Allow passing optional _id while uploading to gridfs files

For: 216 - In GridFs, allow assigning a custom _id to documents in files collection
Allowing custom ids means the _id could be a binary, which Mongo supports.

Thank you!


Added dependencies to setup

Added the dependencies for the install_requires portion of setup.py

I'll chime in: I would avoid using install_requires for things like numpy and matplotlib. Installing matplotlib via pip is never the right thing to do. Before install, you need to do some system-dependent changes to the setup file to specify e.g. graphics backends. Pip doesn't know how to do this, so the installation will pretty much always fail.
On top of that, when working in virtual environments, pip in Python 2.x may not recognize your numpy install, and in trying to rectify that will destroy your Python stack. I've had it happen, and it's not pretty.
For those reasons, I avoid install_requires in all my packages, and I'd encourage everyone else to do so as well – especially if the requirements include matplotlib or numpy.

Do you think we should list any deps here?
Sent from my iPhone

On Sep 22, 2015, at 8:34 PM, Jake Vanderplas<EMAIL_ADDRESS>wrote:
I'll chime in: I would avoid using install_requires for things like numpy and matplotlib. Installing matplotlib via pip is never the right thing to do. Before install, you need to do some system-dependent changes to the setup file to specify e.g. graphics backends. Pip doesn't know how to do this, so the installation will pretty much always fail.
On top of that, when working in virtual environments, pip in Python 2.x may not recognize your numpy install, and in trying to rectify that will destroy your Python stack. I've had it happen, and it's not pretty.
For those reasons, I avoid install_requires in all my packages, and I'd encourage everyone else to do so as well – especially if the requirements include matplotlib or numpy.
—
Reply to this email directly or view it on GitHub.

Do you think we should list any deps here?

That's tough – I think it's confusing if we list some deps but not all. I tend to just avoid it altogether in favor of a detailed installation section in the README. I know lots of others disagree with me, though.

Would it be reasonable to check in setup whether the dependencies are installed and display a warning for those that are not? The warning could direct users to the installation instructions in the README.

I am also wondering if we can isolate the dependencies in the code so that
the main API will run with only traitlets (and not pandas or mpl).
Then just requiring traitlets would be a good options (it is pure python
and trivial to install).
On Wed, Sep 23, 2015 at 12:24 PM, alope107<EMAIL_ADDRESS>wrote:

Would it be reasonable to check in setup whether the dependencies are
installed and display a warning for those that are not? The warning could
direct users to the installation instructions in the README.
—
Reply to this email directly or view it on GitHub
https://github.com/ellisonbg/altair/pull/59#issuecomment-142703463.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

One difficulty of that is that the type inference depends on Pandas, and it would be difficult to make it work apart from that.

Hmm, yeah that is right in the middle of it all. So maybe let's leave it empty for now. Also, most people who will use this will already have all that installed - and we can add an Installation section to the README. @alope107 can you do that instead of this one?

We could also provide a conda recipe / binaries (might be another good place to use conda-forge).

+1 on that - Thomas if you have done that before, do you want to have a go
at that?
On Thu, Sep 24, 2015 at 10:01 AM, Thomas A Caswell<EMAIL_ADDRESS>
wrote:

We could also provide a conda recipe / binaries (might be another good
place to use conda-forge).
—
Reply to this email directly or view it on GitHub
https://github.com/ellisonbg/altair/pull/59#issuecomment-142989193.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

Added installation instructions.  Do we need to specify which version of each dependency to use, and if so, what are they?

mpl needs to be 1.5.0rc1 or better.

Sorry for the slow response. I've added the suggested changes.


Link to a good key={index} danger explanation

I liked this article: https://medium.com/@robinpokorny/index-as-a-key-is-an-anti-pattern-e0349aece318
I think we should link to it from Lists and Keys page for people who want to know why indexes as keys are not safe in some cases, since we often get asked that but it's not essential or easy to explain enough to include in the doc itself.

I can do a quick revision to the Lists and Keys page and find an appropriate place to insert the link if you would like help.

👍 sounds great

Ok, added the link where I thought it may best fit in PR #340 😄


Conflict in temporary files in multi-user system

I'm using mlxu (0.1.10) and noticed that it creates temporary files under /tmp/mlxu. The problem with the current framework is that, if multiple people are using the system and running experiments using mlxu, the mlxu folder in temp in /tmp/ is created with write permissions only for whoever first created the folder. Is there a way to get around this? Perhaps by setting an environment variable that puts those folders elsewhere?
I would suggest in the future making the temp folder /tmp/mlxu_<uid>/ for example to avoid this problem.

The /tmp/mlxu is created by the logger. In order to change it, you can use command line flags to specify the logging directory:
python experiment.py --logger.output_dir=/path/to/logger/output

That is good know. Thank you.
I still think that it would be good to set the default directory to something a bit more general and robust (#3). Also, it shouldn't break any properly written code because one would either be relying on whatever the default directory is or setting it explicitly. Can you think of a reason not to implement that change?

This issue has been open for a while. If you disagree or don't want to apply this change for whatever reason, I understand. Even in that case, please close this issue and the associated PR to mark it one way or the other.


ImportError: cannot import name 'TensorOpParams' from 'cumm.gemm.algospec.core'

Hi, I built cumm from source on Nvidia Jetson nano board, when I import cumm inside python, no errors appear.
But when import TensorOpParams as following: from cumm.gemm.algospec.core import TensorOpParams I got the following error:

Traceback (most recent call last):
File "", line 1, in
File "/home/jetson/build_spconv/spconv3/spconv/spconv/init.py", line 15, in
from . import build as _build
File "/home/jetson/build_spconv/spconv3/spconv/spconv/build.py", line 24, in
from spconv.core import SHUFFLE_SIMT_PARAMS, SHUFFLE_VOLTA_PARAMS, SHUFFLE_TURING_PARAMS
File "/home/jetson/build_spconv/spconv3/spconv/spconv/core.py", line 18, in
from cumm.gemm.algospec.core import TensorOpParams
ImportError: cannot import name 'TensorOpParams' from 'cumm.gemm.algospec.core' (/home/jetson/build_spconv/spconv3/cumm/cumm/gemm/algospec/core.py)

Environment：
NVIDIA Jetson Nano Developer Kit  (aarch64)
Python: 3.7.5
cumm: 0.3.0
cuda: 10.2
Please help me!!! Thank you!

I got the same errors. Any solutions will be appreciated!

you can checkout to tags v0.2.8


ES: implement get_metric and has_metric

Coverage decreased (-0.1%) to 79.235% when pulling 59e6766d5b51ae778e92c6ca41cdb941a2b153bc on adericbourg:get_metric into cd3f29f5c6466398500c7891eb18e0a0d36f3fa5 on criteo:master.


Add a .gitignore

Is the .sass-cache required?

Not required. Just updated with gitignore file. Starting cloning again or pull master. Thanks!


fix run.sh script in wenetspeech KWS

Resolve the issue of finetune. py script parameter passing failure due to insufficient addition of \ in wenetspeech KWS run.sh

Thank you for your first-time contribution!


ActionSet handling perf tweaks

Change Overview
The proposed set of changes improves perf of Add ActionSet workflow handling in Kanister controller by fixing the following issues:

Currently controller's onAdd event handler starts an ActionSet execution goroutines after prevalidation stage, which contains several API calls to K8S apiserver. These calls take several seconds before spawning a goroutine, and considering the fact that go-client cache calls onAdd sequentially this adds significant time delay before starting ActionSets if multiple ones are submitted simultaneously.
If multiple ActionSets are handled in parallel, this makes a load on k8s api servers and makes it less responsive. It was measured that for 10 simultaneous ActionSet executions each k8s API call may take up to 1 sec during execution. To reduce server load it was decided to reduce number of k8s API calls where it's possible. For example, all calls to get ActionSet blueprint were replaced with a single call to Blueprint's List method with further lookup through received Blueprints.

As a proof of perf improvement I measured execution time of several ActionSets submitted simultaneously depending on their count and phase count in a corresponding blueprint. A test ActionSet just performed single KubeExec call to minimize phase execution impact.
Results:

Phases per Blueprint
Parallel ActionSets
Old execution time
New execution time

1
10
35 sec
24 sec

1
20
1 min 12 sec
1 min 1 sec

1
30
1 min 50 sec
1 min 16 sec

3
10
56 sec
42 sec

3
20
1 min 53 sec
1 min 22 sec

3
30
2 min 51 sec
2 min 4 sec

5
10
1 min 12 sec
1 min 2 sec

5
20
2 min 26 sec
2 min 4 sec

5
30
3 min 26 sec
3 min 0 sec

Pull request type
Please check the type of change your PR introduces:

[ ] :construction: Work in Progress
[x] :rainbow: Refactoring (no functional changes, no api changes)
[ ] :hamster: Trivial/Minor
[x] :bug: Bugfix
[ ] :sunflower: Feature
[ ] :world_map: Documentation
[ ] :robot: Test

Issues

fixes #1646

Test Plan

[x] :muscle: Manual
[x] :zap: Unit test
[ ] :green_heart: E2E

@ihcsim Could you please take a look at these changes too?

@ihcsim @viveksinghggits @pavannd1 I've opened the follow-up PR, which addresses the rest of comments left after merge. I decided to return back direct retrievals of blueprints from the API server, as it seems that using caches brings much more problems in comparison with its contribution to overall workflow runtime.


Translation not shown properly

Affected Symphony version(s) : 2.7.10
PHP version(s) : 7.2
OS(es) : Ubuntu (Chrome, Firefox)
I have a Symphony translation:
'This request exceeds the maximum allowed request size of %s specified by your host.' =>
'Táto požiadavka prekročila povolenú veľkosť %s stanovenú serverom.',

But in the UI it is shown the following way (see at the beginning):

It looks like it is somehow changed by the backend javascript, 'cause in the html source the translation is present as translated, but changed in browser's debugger:

No errors in JS.

Ok I have reproduced this.
The problem is because of this line:
https://github.com/symphonycms/symphonycms/blob/master/symphony/assets/js/src/symphony.notify.js#L56
{
Ignore?: "Ignorovať?",
next: "ďalšie",
at: "o",
status: 200
}

Táto požiadavka  get Tátpožiadavka

@wdebusschere any ideas on how to fix it ?

only replace if there is a %s (date?) after.. (maybe check if after the space there is a number)
'Author created at %s.' =>'Autor um %s erstellt.',

It's a minor issue, but i guess it can happen often.. example german: at = um, i guess the message could have some words ending in um with a space after and then the next word..


ci(fix): create operatorhub.io pr only on latest release

Since adding an old version into the stable-v1 channel is not possible, and we keep only one channel and always with the latest version, we should create the PR to the OperatorHub.io only on the latest release branch.
Closes #4843

/ok-to-merge