[SPARK-19066][SPARKR][Backport-2.1]:LDA doesn't set optimizer correctly

What changes were proposed in this pull request?
Back port the fix to SPARK-19066 to 2.1 branch.
How was this patch tested?
Unit tests

Could you change the PR title to
[SPARK-19066][SPARKR][Backport-2.1]LDA doesn't set optimizer correctly

Test build #71527 has started for PR 16623 at commit bdc7e4a.

Changed. Thanks!

@yanboliang  ported it to 2.1. Thanks!

Test build #71527 has finished for PR 16623 at commit bdc7e4a.

This patch fails SparkR unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71527/
Test FAILed.

Test build #71542 has started for PR 16623 at commit 3b17c3d.

Test build #71542 has finished for PR 16623 at commit 3b17c3d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71542/
Test PASSed.

Merged build finished. Test PASSed.

LGTM

merged to 2.1. thanks!

@wangmiao1981 could you close this PR - backport doesn't get closed automatically.

Close this PR as it has been merged to 2.1. Thanks!

@felixcheung  Just saw this was backported to 2.1.1.  Since this is a fairly significant behavioral change, I recommend we revert this backport.  I could imagine workloads working with EM but failing with online LDA, and we should be careful about having such failures in patch versions (2.1.0->2.1.1).  Let's wait until the next major release (2.2.0) instead.
I've also seen other PRs adding public APIs to SparkR for 2.1.1.  I understand that SparkR is still fairly experimental, but I recommend we start treating it like other parts of Spark in terms of API stability.  We can talk about exceptions when they are really necessary.
Can you please revert this patch?  Thanks!

Surely. This is a small enough change (one line) that we could revert easily.
But just so I understand, this isn't just a behavior change per se - this is the API not doing that is documented. Isn't this something we should fix in a patch release?

Hm, true, this is a weird case, where it is somewhere between a behavior change and a bug fix.  You're right---let's not revert this patch.
I do worry about other patches in SparkR; I'll try be more vigilant about API stability for SparkR for future patches.
Thanks!

Sure - I understand you perspective on the API state, and we share the same view. To be clear we should avoid breaking API changes and new API should be in minor release and not patch release.
But there needs to be exception to the rule - SparkR is no where ready or stable and there are many gaps we need to fill as soon as possible. Or we might as well abandon it.

Thanks for cc'ing me on this - I think @jkbradley has a good point that we should be a bit more explicit in discussing when / why we backport changes in SparkR. While we have not declared it a stable interface, I think the number of users who are using it is large enough now that there is some expectation of stability.
I think we can easily separate out the fixes we backport into a couple of buckets -- changes like https://github.com/apache/spark/commit/7763b0b8bd33b0baa99434136528efb5de261919 which are internal changes and don't affect the API / are bug fixes fixing the behavior of an existing API. My reading of our versioning policy is that these are expected in a feature release.
The second group are changes that either add or modify an API (we should never backport something that removes an API). For the modifications, lets explicitly discuss in the JIRA / Github PR as to why this is necessary / a good idea and also if its source compatible (e.g.,  https://github.com/apache/spark/commit/06e77e0097c6fa0accc5d9d6ce08a65a3828b878 is source compatible)
The other thing we could do is add JIRA labels like regression / bug-fix / api-modify to each JIRA that gets backported. Does that sound like something that would be useful @jkbradley @felixcheung  ?

Thanks for the comments.  I definitely agree with many of your combined statements:

R has not been declared stable.  (Though where in the docs is this even stated?  I was unable to find anything saying it is an alpha component.)
Some changes are necessary and OK, such as APIs which simply do not work.
We could still be stricter about some API changes.

If I'm a user of SparkR, I agree I'd expect it to be less stable than the rest of Spark.  But apparent instability from changing APIs can also scare away users from putting SparkR into actual use.  It's a balance, but I'd prefer to err on the side of stability.
I do like the idea of tagging backports, but it's Ok with me not to as long as there is proper explanation of the reason within the JIRA.


converting to lowercase locale undependend in es backend indexer

1. Why is this change necessary?
Because the locale settings of the Shop Administrator is unknown, strings should be converted independently of the locale. I received a lot of errors while importing products with a lot of german strings into elasticsearch.
2. What does this change do, exactly?
It converts strings to lowercase not by locale settings, but by the Unicode character properties.
3. Describe each step to reproduce the issue or behaviour.
echo strtolower('Trikothose Kids weiß Saison 16/17');
#can produce in some case of locale settings, something like this: 'trikothose kids wei? saison 16/17'

echo mb_strtolower('Trikothose Kids weiß Saison 16/17')
#expected is: 'trikothose kids weiß saison 16/17'

4. Please link to the relevant issues (if any).
5. Which documentation changes (if any) need to be made because of this PR?
6. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-23912
Please use this issue to track the state of your pull request.

Hi @wrongspot, thank you very much for your contribution! 💙


Warnings in strict mode

EDIT: For the developers that feel adventurous, they can try:
import {
- createMuiTheme,
+ unstable_createMuiStrictModeTheme as createMuiTheme,
  darken,
} from '@material-ui/core/styles';

It's available since #20523, v4.9.11, our intended version for v5. You can find the documentation at https://material-ui.com/customization/theming/#unstable-createmuistrictmodetheme-options-args-theme.

I am playing with Suspense on my project topheman/react-fiber-experiments. I have the following warnings in development:
Warning: Legacy context API has been detected within a strict-mode tree:

Please update the following components: MuiThemeProvider, WithStyles(AppBar), WithStyles(ButtonBase), WithStyles(Card), WithStyles(CardContent), WithStyles(CssBaseline), WithStyles(Drawer), WithStyles(Footer), WithStyles(Header), WithStyles(HomeContainer), WithStyles(IconButton), WithStyles(MainDrawer), WithStyles(MainLayout), WithStyles(Modal), WithStyles(Paper), WithStyles(SvgIcon), WithStyles(Toolbar), WithStyles(Typography)

Learn more about this warning here:
https://fb.me/react-strict-mode-warnings

Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of ButtonBase which is inside StrictMode. Instead, add a ref directly to the element you want to reference.

    in button (created by ButtonBase)
    in ButtonBase (created by WithStyles(ButtonBase))
    in WithStyles(ButtonBase) (created by IconButton)
    in IconButton (created by WithStyles(IconButton))
    in WithStyles(IconButton) (at Header.js:76)
    in div (created by Toolbar)
    in Toolbar (created by WithStyles(Toolbar))
    in WithStyles(Toolbar) (at Header.js:75)
    in header (created by Paper)
    in Paper (created by WithStyles(Paper))
    in WithStyles(Paper) (created by AppBar)
    in AppBar (created by WithStyles(AppBar))
    in WithStyles(AppBar) (at Header.js:74)

Learn more about using refs safely here:
https://fb.me/react-strict-mode-find-node

The Suspense part (asynchronous fetching, placeholders ...) works ok out of strict mode - check the demo.
Though, the async render part (time slicing) may need strict mode (check the link bellow). This is something to dig into now, people will soon be trying alphas of Suspense and a new major version of react will come in a few months.
Resource to read
Related: Migrate from findDOMNode to refs
Your Environment

Tech
Version

Material-UI
v3.1.2

React
v16.6.0 - custom build from this commit

Browser
Chrome

More infos:

https://react-fiber-experiments.surge.sh/about
https://github.com/topheman/react-fiber-experiments

We can't get rid of findDOMNode in many cases as I pointed out previously: https://github.com/mui-org/material-ui/issues/13221#issuecomment-429451615
Is there currently a way to check from a component if it is in StrictMode? That way we could avoid findDOMNode and somehow communicate to users that their components should properly forward their refs.
The context API rewrite should hopefully not cause any breakage but I'm not very familiar with our theming approach.

Is there currently a way to check from a component if it is in StrictMode? That way we could avoid findDOMNode and somehow communicate to users that their components should properly forward their refs.

It seems that you need to have access to the current fiber in process : https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberBeginWork.js#L946-L948 though, this will be a common need for library authors.

I think that line is about context.
So I looked at the code of findDOMNode and did some testing and it turns out that React does not warn if you pass a dom element which is perfect for us. We can still use findDOMNode but test our tree in strict mode to be ready for Supsense.
Example: https://codesandbox.io/s/qko6n6vzjj

Just to be clear, it currently works with Suspense (this is the Async rendering part which might pose problem - like Time Slicing).
Your example is perfect 👍- at least we know that there is an escape hatch anyway.
However, this means, that each time the user passes a component prop, he/she will have to create a new one with React.forwardRef before using it.
Example:
<Toolbar>
  <Button
    component={Link}
    to="/"
    title="Home"
  />
  <IconButton
    component={Link}
    to="/foo"
    title="Foo"
  />
  <Typography
    component={Link}
    to="/"
    title="Bar"
  >
    Bar
  </Typography>
</Toolbar>

@topheman Might be a good idea to add a note to the documentation where people can pass their own component and we use findDOMNode on their refs and require that those components forward their refs properly in the next major or so.
We could also issue deprecation warnings if findDOMNode(ref) !== ref but this won't provide useful error stacks unless we actually throw. I wish the warning package would include the component stack.
Also the react docs recommend using forwardRef with a new major because it could be considered breaking behavior (with which I agree) but we have to be careful not to introduce to many breaking changes in our next major because people might not be able to upgrade.

React does not warn if you pass a dom element which is perfect for us.

If you pass a DOM element, why do you need findDOMNode at all? It will just give you that element back.

React does not warn if you pass a dom element which is perfect for us.

If you pass a DOM element, why do you need findDOMNode at all? It will just give you that element back.

@gaearon
We don't pass the DOM elements but the user. We interface the as prop in Button so that it accepts anything that can hold refs.
interface Props {
  as: React.ComponentClass | React.ForwardRefExoticComponent | string;
}
function Button({ as: Component }: Props) {
  // users in strict mode would be required to forward refs to the DOM node
  // while users in "loose" mode can simply pass in anything that can hold refs
  return <Component ref={ref => findDOMNode(ref)!.focus()} />
}

// valid
<Button as="div" />
<Button as={SomeClassComponent} />
<Button as={SomeComponentThatForwardsRefs} />
<Button as={ReactRouterLink} />
// invalid but was valid via findDOMNode(this) in the Button implemented as a class component
<Button as={() => <ReactRouterLink to="/somewhere" />} />

Is this merge supposed to solve the issues with React.StrictMode? Has this been pushed to a beta that we could test?
I've updated material-ui to version 3.6.2 and I'm still getting this error:
Warning: Legacy context API has been detected within a strict-mode tree:
    in StrictMode
    in Router (created by BrowserRouter)
    in BrowserRouter
    in Provider

Please update the following components: MuiThemeProviderOld

If I remove Router from my app, this is the error I get
react-dom.development.js:506 Warning: Legacy context API has been detected within a strict-mode tree:
    in StrictMode
    in Provider

Please update the following components: MuiThemeProviderOld

However, if I remove MuiThemeProvider, the error goes away.

@alveshelio This issue is concerned about findDOMNode warnings. You need to use @material-ui/styles@alpha and follow https://material-ui.com/css-in-js/basics/ to get rid of strict mode warnings concerning legacy context.

Hi @eps1lon, Thank you for the follow up. I'll give it a try.

Tracking progress here.
Test plan:

[ ] run unit test in React.StrictMode: https://github.com/eps1lon/material-ui/tree/test/strict-mode
[ ] enable StrictMode in docs (/pages/_app.js)

"@material-ui/lab/SpeedDial" demo issues warning when used with StrictMode see https://codesandbox.io/s/speed-dial-with-strictmode-oicqp. Should I create a separate bug?

@sarod

The component can cause issues in StrictMode.

-- https://material-ui.com/api/speed-dial/#notes

I'm seeing issues with StrictMode using the Tooltip and Popper components. A simple use case of the Tooltip can be seen here: https://codesandbox.io/s/material-ui-strictmode-tooltip-issue-dypgp
You have to hover the component for it to throw the error.

@JCQuintas The IconButton causes this. That component doesnt support strict mode yet.

@eps1lon what about the one with just a div inside the tooltip? It throws an error also.

Same: https://material-ui.com/api/tooltip/#notes

No github I said another change

would close #13394

I'm using the Drawer component and passing state to it from a custom Layout component in order to open and close it with animation with Slide. This is the warning that appears with that usecase:
Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference.

    in div (created by Transition)
    in Transition (created by ForwardRef(Fade))
    in ForwardRef(Fade) (created by ForwardRef(Backdrop))
    in ForwardRef(Backdrop) (created by WithStyles(ForwardRef(Backdrop)))
    in WithStyles(ForwardRef(Backdrop)) (created by ForwardRef(Modal))
    in div (created by ForwardRef(Modal))
    in ForwardRef(Portal) (created by ForwardRef(Modal))
    in ForwardRef(Modal) (created by ForwardRef(Drawer))
    in ForwardRef(Drawer) (created by WithStyles(ForwardRef(Drawer)))
    in WithStyles(ForwardRef(Drawer)) (at SideMenu.js:76)
    in SideMenu (at Layout.js:41)
    in Layout (at HomeLayout.js:5)
    in HomeLayout (at pages/index.js:9)
    in Home (at _app.js:43)
    in GraphQLProvider (at _app.js:42)
    in StylesProvider (at _app.js:40)
    in ThemeProvider (at _app.js:39)
    in Container (at _app.js:38)
    in StrictMode (at _app.js:37)
    in WagglioMainApp (created by WithGraphQL(WagglioMainApp))
    in WithGraphQL(WagglioMainApp)
    in Suspense (created by AppContainer)
    in Container (created by AppContainer)
    in AppContainer

Learn more about using refs safely here:
https://fb.me/react-strict-mode-find-node

Not sure if there's a simple way for me to avoid the warning, but just wanted to comment here about it for anyone Googling

@fillipvt

The component can cause issues in StrictMode.

-- https://material-ui.com/api/drawer/#notes

@fillipvt As you can see in the component stack trace, we are dependent on https://github.com/reactjs/react-transition-group/issues/429.

since with version mui has solved most strict issues?

@sibelius v4.5.1 is a safe bet 😁.

An update on our current progress.
We have solved all the issue in Material-UI. We dependent on reactjs/react-transition-group#429 to be 100% compliant.

Maybe we should consider move on our own way without slow developing dependencies? 😁

We were pleased to see Shopify uses our patched version for their design system this morning: https://github.com/Shopify/polaris-react/blob/master/package.json#L182 ✌ @AndrewMusgrave

@oliviertassinari wow :) so if you already done this I should not have issues with this but unfortunately I have one.

index.js:1437 Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here: https://fb.me/react-strict-mode-find-node
in div (at Login.js:179)

<Slide direction="right" in={props.show} appear={false}>

        <TextField ... />

    </Slide>

@chibis0v ⚠ we don't use @material-ui/react-transition-group.

@oliviertassinari I'm a little bit confused 😁 why do we have working solution but using buggy one?

@oliviertassinari I'm a little bit confused 😁 why do we have working solution but using buggy one?

The actual react-transition-group is not "buggy". It only issues warnings in StrictMode.
We can't use @material-ui/react-transition-group because some of our components that require a ref to their child also allow plain function components. For those we do need findDOMNode.
It was an oversight on my part when working on this for v4. You should be able to alias react-transition-group to @material-ui/react-transition-group in order to remove findDOMNode warnings. However, this library is still not concurrent nor StrictMode compatible with this alias due to our styling solution. I'm not sure if styled-components is StrictMode compatible

can we have a checklist of items that still need to be fixed?

can we have a checklist of items that still need to be fixed?

Grep the codebase for StrictModeViolation. Should be only related to react-transition-group or enzyme tests or makeStyles usage.

I'm confused about what to fix
@eps1lon

Hello guys, I face the same problem with opening a Menu or opening the Drawer.
What do you think guys, can we expect solution soon, or we should just ignore the warning for now?
Thanks

This will be solved in v5. We can't fix it without a breaking change. I'll put together a gist how to fix this  in your app by using the theme.

Hey @eps1lon, when you have the link for the gist you mentioned above, please let us know. :)

Hey @eps1lon, when you have the link for the gist you mentioned above, please let us know. :)

Thanks for the reminder. I have this working partially on some side-projects but I need to be careful with communicating it since it relies on more internals than I'd like. Considering this got quite a bit of upvotes I'll look into this more considering Easter won't be as busy as usual.

Hey again, @eps1lon and thanks for your prompt feedback... :)
The link below is an example from https://material-ui.com/components/drawers/ - Persistent drawer.
https://codesandbox.io/s/drawer-x283v
Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here: https://fb.me/react-strict-mode-find-node
    in div (created by ForwardRef(Paper))
    in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
    in WithStyles(ForwardRef(Paper)) (created by Transition)
    in Transition (created by ForwardRef(Slide))
    in ForwardRef(Slide) (created by ForwardRef(Drawer))
    in div (created by ForwardRef(Drawer))
    in ForwardRef(Drawer) (created by WithStyles(ForwardRef(Drawer)))
    in WithStyles(ForwardRef(Drawer)) (at drawer.js:117)
    in div (at drawer.js:94)
    in PersistentDrawerLeft (at App.js:8)
    in div (at App.js:7)
    in App (at src/index.js:9)
    in StrictMode (at src/index.js:8)

I'm sorry if this is a basic question, but where exactly is the issue here that we would need to add a ref? Is it with the Transition? And if I understand it correctly, there is no easy fix for this until v5?
Thanks a lot and be safe!

`import React from 'react';
import ReactDOM from 'react-dom';
import './index.scss';
import App from './App';
import * as serviceWorker from './serviceWorker';
import { turnOnTheServer } from './helpers/helpers';
// Environment variable config
turnOnTheServer()
ReactDOM.render(
<React.StrictMode>

</React.StrictMode>,
document.getElementById('root')
);
`
||
v
`import React from 'react';
import ReactDOM from 'react-dom';
import './index.scss';
import App from './App';
import * as serviceWorker from './serviceWorker';
import { turnOnTheServer } from './helpers/helpers';
// Environment variable config
turnOnTheServer()
ReactDOM.render(
,
document.getElementById('root')
);
`

when u guys will solve this?

Snackbar is producing the same error.

I'm getting this error when using Grow transition
Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here: https://fb.me/react-strict-mode-find-node
I'm using
    "@material-ui/core": "^4.9.11",
    "@material-ui/icons": "^4.9.1",
    "react": "^16.13.1",

For the developers that feel adventurous, they can try:
import {
- createMuiTheme,
+ unstable_createMuiStrictModeTheme as createMuiTheme,
  darken,
} from '@material-ui/core/styles';

(available since #20523, v4.9.11)

makeStyles usage.

Do we know what it's going to take to make makeStyles StrictMode compatible? Is it the use of useSynchronousEffect? I'm aware of the plan to move to Styled Components, but I'm curious how/if they solved this problem.

There are multiple issues that make makeStyles not concurrent safe. Being able to use a library that is dedicated to this problem space should free up some resources.

There are multiple issues that make makeStyles not concurrent safe.

If it's not too much trouble, would you be able to spell them out? For the benefit of those who may want to contribute a solution, or even to understand the problem space better. But I agree with the core team wanting to spend resources on using an alternative library instead.

https://github.com/cssinjs/jss/issues/1338
https://github.com/cssinjs/jss/issues/1332

We are not using createUseStyles but a custom implementation that is very similar. Since the issues are the same I suspect fixes in one could be ported to another.
If you want to deep-dive you should apply
-    mount = createMount({ strict: undefined });
+    mount = createMount({ strict: true });

to https://github.com/mui-org/material-ui/blob/27471b4564eb40ff769352d73a29938d25804e45/packages/material-ui-styles/src/makeStyles/makeStyles.test.js#L42
and make them pass.
Though you might want to flip to false first and make those pass. An explicit false just adds wrapper component so that you're forced to write tests that assert the same component structure as with StrictMode.

although I have put the drawer inside the forwardRef, I still have the issue.
And the weird part is that when adding this forwardRef, the transition disapeared.
const FwdDrawer = React.forwardRef<
		RefObject<HTMLSpanElement>,
		IDrawerInnerType
	>((props, ref) => <SwipeableDrawer ref={ref} {...props} />);

	return (
		<FwdDrawer
			open={props.open}
			onOpen={() => setOpenedDrawer(true)}
			onClose={() => setOpenedDrawer(false)}
			ModalProps={{
				keepMounted: true,
			}}
			anchor="left"
		>

				<IconButton
					onClick={() => setOpenedDrawer(false)}
					style={{ color: colorsPalette.white }}
				>
					{theme.direction === "ltr" ? (
						<ChevronLeftIcon />
					) : (
						<ChevronRightIcon />
					)}
				</IconButton>

			<Divider />
			{menuList}
		</FwdDrawer>
	);

@oliviertassinari unstable_createMuiStrictModeTheme is so cool! Those warnings were driving me nuts. May I update the theming docs?. A quick paragraph mentioning strict mode theming is available but unstable.

May be disable StrictMode
replace
ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

to
ReactDOM.render(
  <React.Fragment>
    <App />
  </React.Fragment>,
  document.getElementById('root')
);

https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

For the developers that feel adventurous, they can try:
import {
- createMuiTheme,
+ unstable_createMuiStrictModeTheme as createMuiTheme,
  darken,
} from '@material-ui/core/styles';

(available since #20523, v4.9.11, our intended version for v5)

Sorry for the probably silly question, but is there an example of such implementation ?
Thanks

@RealSlimMahdi there are no examples for using the unstable_createMuiStrictModeTheme specifically in the docs, but you can follow the docs' theming examples (https://material-ui.com/customization/theming/#createmuitheme-options-args-theme, or https://material-ui.com/styles/api/#themeprovider), and replace the createMuiTheme imports with unstable_createMuiStrictModeTheme as createMuiTheme. They should work in strict mode with no issues as far as you are using React/React-DOM >16.3. Here is a full example:
import React from 'react';
import {
// createMuiTheme, // this line was replaced
unstable_createMuiStrictModeTheme as createMuiTheme, // for this one
ThemeProvider
} from '@material-ui/core/styles';
import purple from '@material-ui/core/colors/purple';
import green from '@material-ui/core/colors/green';

const theme = createMuiTheme({ //and used here
  palette: {
    primary: purple,
    secondary: green,
  },
  status: {
    danger: 'orange',
  },
});
 // so you can get rid of the "findDOMNode is deprecated in Strict mode" warnings
ReactDOM.render(
  <React.StrictMode>
      <ThemeProvider theme={theme}>

 Hi

      </ThemeProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

@RealSlimMahdi there are no examples for using the unstable_createMuiStrictModeTheme specifically in the docs, but you can follow the docs' theming examples (https://material-ui.com/customization/theming/#createmuitheme-options-args-theme, or https://material-ui.com/styles/api/#themeprovider), and replace the createMuiTheme imports with unstable_createMuiStrictModeTheme as createMuiTheme. They should work in strict mode with no issues as far as you are using React/React-DOM >16.3. Here is a full example:
import React from 'react';
import {
// createMuiTheme, // this line was replaced
unstable_createMuiStrictModeTheme as createMuiTheme, // for this one
ThemeProvider
} from '@material-ui/core/styles';
import purple from '@material-ui/core/colors/purple';
import green from '@material-ui/core/colors/green';

const theme = createMuiTheme({ //and used here
  palette: {
    primary: purple,
    secondary: green,
  },
  status: {
    danger: 'orange',
  },
});
 // so you can get rid of the "findDOMNode is deprecated in Strict mode" warnings
ReactDOM.render(
  <React.StrictMode>
      <ThemeProvider theme={theme}>

 Hi

      </ThemeProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

@luminaxster it fixes the issue thanks, but there is no such package called unstable_createMuiStrictModeTheme in @material-ui/core/styles, so how come it still works. could you tell how it fixes the issue.

@26rahulsingh Not sure what you mean, the export for this function is right here: https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/styles/index.js
I think you might be interpreting your linter warning wrong: There are no type definitions, yet. So in a Typescript project, the linter will show an error that the import can't be found.

I get this warning with the simple Dialog example
Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of
Transition which is inside StrictMode. Instead, add a ref directly to the element you want to
reference. Learn more about using refs safely here: https://fb.me/react-strict-mode-find-node
    in div (created by Transition)
    in Transition (created by ForwardRef(Fade))
    in ForwardRef(Fade) (created by ForwardRef(Backdrop))
    in ForwardRef(Backdrop) (created by WithStyles(ForwardRef(Backdrop)))
    in WithStyles(ForwardRef(Backdrop)) (created by ForwardRef(Modal))
    in div (created by ForwardRef(Modal))
    in ForwardRef(Portal) (created by ForwardRef(Modal))
    in ForwardRef(Modal) (created by ForwardRef(Dialog))
    in ForwardRef(Dialog) (created by WithStyles(ForwardRef(Dialog)))
    in WithStyles(ForwardRef(Dialog)) (at demo.tsx:26)
    in div (at demo.tsx:22)
    in FormDialog (at index.tsx:7)
    in StrictMode (at index.tsx:6)

Codesandbox : https://codesandbox.io/s/material-demo-h7hu6

@oliviertassinari react-transition-group released v4.4.0 and they fixed StrictMode issue. Could we update components?

Could we update components?

I'm trying to get this to work but no guarantees. It's somewhat difficult since we forgot to put an important restriction on Snackbar during the v4 development.

@eps1lon Just as a mention, this also happens with <TextField select {...rest} >; I think because the options are displayed in a MuiMenu.

This happens with <Fade > as well

Same with <Slide>

<Collapse> as well

@26rahulsingh Not sure what you mean, the export for this function is right here: https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/styles/index.js
I think you might be interpreting your linter warning wrong: There are no type definitions, yet. So in a Typescript project, the linter will show an error that the import can't be found.

@26rahulsingh Not sure what you mean, the export for this function is right here: https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/styles/index.js
I think you might be interpreting your linter warning wrong: There are no type definitions, yet. So in a Typescript project, the linter will show an error that the import can't be found.

@pReya my bad, I did not notice that :)

Also happens with Dialog. Do you have a solution?

Also happens with Grow Transition component, drawer and tooltip. Any solution in the near future?

Starting with<EMAIL_ADDRESS>you can use unstable_createMuiStrictModeTheme which should fix all the findDOMNode related warnings. Please read the restrictions carefully.

Starting with<EMAIL_ADDRESS>you can use unstable_createMuiStrictModeTheme which should fix all the findDOMNode related warnings. Please read the restrictions carefully.

It says that we should not use this in production ... :(

It says that we should not use this in production ... :(

It's a precaution since we can't be sure whether this works for your app or not. Since it only fixes dev-only warnings you shouldn't take the risk.

Please, i need absolutely the solution

Seeing this inside Trigger, coming from the Tooltip component
Please update the following components: Trigger

Learn more about this warning here: https://fb.me/react-legacy-context
    in Trigger (created by Tooltip)
    in Tooltip (created by ComponentEnhancer(Range))

I have the problem as described above, what to do?

Could i get clarification? There is nothing much we can do apart to remove StrictMode in React project, we just have to wait until Material UI updates it's library?

unstable_createMuiStrictModeTheme impacts the Menu and many other components.

Hi @oliviertassinari / @eps1lon - has this issue been fixed?? I'm still getting a findDOMNode warning when opening Snackbar from button click in strict mode. I'm using following React and material ui versions:

React - ^16.13.1
React DOM - ^16.13.1
Material ui - ^4.10.1

And here's a sample code of what I did so far.
I tried to follow as an example (mentioned by @eps1lon) from here but still getting that Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode.
Do you guys have an idea of getting around of this warning in strict mode except disabling the strict mode itself? Thanks in advance.

Thanks @jsonnikson - using unstable_createMuiStrictModeTheme wipes the findDOMNode warning out for now. Hopefully, v5 gets released soon and has a stable solution for this warning.

react-transition-group fixed this issue in version 4.4.0. Will this version be included in version 4 of Material UI or it will be in version 5?

Also confirming that #13394 is fixable just by upgrading. Thanks guys for the effort. 👍

Also confirming that #13394 is fixable just by upgrading to v5. Thanks guys for the effort. 👍

Is V5 out?

Also confirming that #13394 is fixable just by upgrading to v5. Thanks guys for the effort. 👍

Is V5 out?

I checked my commits and found out that I updated react-tooltip from 4.2.7 to 4.2.8. I don't why I wrote v5, sorry about that. Needless to say, my issue was fixable purely by updating my dependencies by running:
npx npm-upgrade
npm i

@afroguy16 V5 is still in alpha but if you install @material-ui/core@next the warning goes away.

@afroguy16 V5 is still in alpha but if you install @material-ui/core@next the warning goes away.

Is there any repercussions from doing so?
Is the alpha safe enough to use?
I know each team has their own definition of what's alpha worthy.

@ZachMurray alpha as breaking changes potentially every week.

@eps1lon From what I understand, we can close this issue now (v5.0.0-alpha.7) and only keep #18018 open. Do you confirm?

This is an umbrella issue for all issues related to StrictMode. It shouldn't be closed if the underlying issues remain.

Still having this issue

using v15, no more this issue
Le lun. 2 nov. 2020 à 16:20, Rondip<EMAIL_ADDRESS>a écrit :

Still having this issue
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mui-org/material-ui/issues/13394#issuecomment-720536722,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMFJIE6FGDDJLHFMRXEKW7TSN3E4ZANCNFSM4F7PN7PA
.

Anyway to solve it without using v5?

@jnrbo Yes, https://github.com/mui-org/material-ui/issues/13394#issuecomment-619266831, or remove the strict mode wrapper.

In theory, #24405 solves #20708, the last standing issue with have with StrictMode.

In theory, #24405 solves #20708, the last standing issue with have with StrictMode.

In theory, #24405 solves #20708, the last standing issue with have with StrictMode.

That's unclear at this moment. We still have plenty of components not tested in StrictMode.

In theory, #24405 solves #20708, the last standing issue with have with StrictMode.

That's unclear at this moment. We still have plenty of components not tested in StrictMode.

Anyway to solve it without using v5?

@jnrbo Yes, #13394 (comment), or remove the strict mode wrapper.

So it seems the options are:

Upgrade to the version 5 alpha (which involves addressing breaking changes and removes IE 11 support)
Use an unstable_ alternative to  createMuiTheme (despite being told not to use it in production)
Turn off StrictMode.
Do nothing (and continue getting warnings)

All four options appear to have some level of risk, but, personally, I don't understand the implications of any of them. I know that you guys only have so many resources to address things like this and that you don't work for us. However, people like me are in the very uncomfortable position of having to choose between 4 mysterious and possibly dangerous paths.
Can anyone advise to the dangers of each option? Are the warnings indicative of a genuine risk of broken behavior? Does disabling StrictMode also disable helpful safeguards? Just how "unstable" is unstable_createMuiStrictModeTheme?

@BrandonWilliamsCS It's not that important, you give one option a try and see how it goes. Not that v5 has almost the same level of IE 11 support than v4.
Personally, I would do:

For new projects
If Material-UI is the only offender
If I have a legacy project or a large one.
Never

Anyway to solve it without using v5?

You can create your own transition components (Collapse, Fade, Grow, Slide, Zoom) based off Material UI that passes nodeRef transition prop to react-transition-group.
Here is a custom Collapse component based off Material UI's Collapse:
import React, { forwardRef, useEffect, useRef } from 'react'
import clsx from 'clsx'
import { Transition } from 'react-transition-group'
import { withStyles } from '@material-ui/core/styles'
import transitions from '@material-ui/core/styles/transitions'
import { getTransitionProps } from '@material-ui/core/transitions/utils'

export const styles = (theme) => ({
  /* Styles applied to the container element. */
  container: {
    height: 0,
    overflow: 'hidden',
    transition: theme.transitions.create('height'),
  },
  /* Styles applied to the container element when the transition has entered. */
  entered: {
    height: 'auto',
    overflow: 'visible',
  },
  /* Styles applied to the container element when the transition has exited and `collapsedHeight` != 0px. */
  hidden: {
    visibility: 'hidden',
  },
  /* Styles applied to the outer wrapper element. */
  wrapper: {
    // Hack to get children with a negative margin to not falsify the height computation.
    display: 'flex',
  },
  /* Styles applied to the inner wrapper element. */
  wrapperInner: {
    width: '100%',
  },
})

const Collapse = forwardRef((props, ref) => {
  const {
    children,
    classes,
    className,
    collapsedHeight: collapsedHeightProp = '0px',
    component: Component = 'div',
    in: inProp,
    onEnter,
    onEntered,
    onEntering,
    onExit,
    onExited,
    onExiting,
    style,
    timeout = transitions.duration.standard,
    TransitionComponent = Transition,
    ...other
  } = props
  const timer = useRef()
  const wrapperRef = useRef(null)
  const autoTransitionDuration = useRef()
  const collapsedHeight =
    typeof collapsedHeightProp === 'number'
      ? `${collapsedHeightProp}px`
      : collapsedHeightProp

  useEffect(() => {
    return () => {
      clearTimeout(timer.current)
    }
  }, [])

  const nodeRef = useRef(null)

  const handleEnter = (isAppearing) => {
    nodeRef.current.style.height = collapsedHeight

    if (onEnter) {
      onEnter(isAppearing)
    }
  }

  const handleEntering = (isAppearing) => {
    const wrapperHeight = wrapperRef.current
      ? wrapperRef.current.clientHeight
      : 0

    const { duration: transitionDuration } = getTransitionProps(
      { style, timeout },
      {
        mode: 'enter',
      }
    )

    if (timeout === 'auto') {
      const duration2 = transitions.getAutoHeightDuration(wrapperHeight)
      nodeRef.current.style.transitionDuration = `${duration2}ms`
      autoTransitionDuration.current = duration2
    } else {
      nodeRef.current.style.transitionDuration =
        typeof transitionDuration === 'string'
          ? transitionDuration
          : `${transitionDuration}ms`
    }

    nodeRef.current.style.height = `${wrapperHeight}px`

    if (onEntering) {
      onEntering(isAppearing)
    }
  }

  const handleEntered = (isAppearing) => {
    nodeRef.current.style.height = 'auto'

    if (onEntered) {
      onEntered(isAppearing)
    }
  }

  const handleExit = () => {
    const wrapperHeight = wrapperRef.current
      ? wrapperRef.current.clientHeight
      : 0
    nodeRef.current.style.height = `${wrapperHeight}px`

    if (onExit) {
      onExit()
    }
  }

  const handleExited = onExited

  const handleExiting = () => {
    const wrapperHeight = wrapperRef.current
      ? wrapperRef.current.clientHeight
      : 0

    const { duration: transitionDuration } = getTransitionProps(
      { style, timeout },
      {
        mode: 'exit',
      }
    )

    if (timeout === 'auto') {
      const duration2 = transitions.getAutoHeightDuration(wrapperHeight)
      nodeRef.current.style.transitionDuration = `${duration2}ms`
      autoTransitionDuration.current = duration2
    } else {
      nodeRef.current.style.transitionDuration =
        typeof transitionDuration === 'string'
          ? transitionDuration
          : `${transitionDuration}ms`
    }

    nodeRef.current.style.height = collapsedHeight

    if (onExiting) {
      onExiting()
    }
  }

  const addEndListener = (done) => {
    if (timeout === 'auto') {
      timer.current = setTimeout(done, autoTransitionDuration.current || 0)
    }
  }

  return (
    <TransitionComponent
      in={inProp}
      onEnter={handleEnter}
      onEntered={handleEntered}
      onEntering={handleEntering}
      onExit={handleExit}
      onExited={handleExited}
      onExiting={handleExiting}
      addEndListener={addEndListener}
      nodeRef={nodeRef}
      ref={ref}
      timeout={timeout === 'auto' ? null : timeout}
      {...other}
    >
      {(state, childProps) => (
        <Component
          className={clsx(
            classes.container,
            {
              [classes.entered]: state === 'entered',
              [classes.hidden]:
                state === 'exited' && !inProp && collapsedHeight === '0px',
            },
            className
          )}
          style={{
            minHeight: collapsedHeight,
            ...style,
          }}
          ref={nodeRef}
          {...childProps}
        >

{children}

        </Component>
      )}
    </TransitionComponent>
  )
})

export default withStyles(styles)(Collapse)

And here is how you use it:
import React, { useState } from 'react'
import Collapse from 'components/Collapse'

export default function App() {
  const [inProp, setInProp] = useState(false)

  return (

      <button onClick={() => setInProp((prev) => !prev)}>
        Click to Toggle
      </button>
      <Collapse in={inProp} timeout="auto">

hello 1

hello 2

hello 3

hello 4

hello 5

      </Collapse>

  )
}

You have to do this for each transition component you want to use. But at least you don't have to disable React.StrictMode or use the unstable_ alternative to createMuiTheme.

@kimbaudi That is exactly what unstable_createMuiTheme originally did. But it should not be required anymore since our transition components should be StrictMode compatible in v4 (if using unstable_createMuiTheme) and v5.

@eps1lon I'm currently using v4 and I don't want to use unstable_createMuiTheme in production. I also don't want to use v5 until it is officially released (currently v5 pre-release). My solution might still be useful for those that are in similar situation.

Perhaps renaming unstable_createMuiTheme to createMuiThemeStrict would make people feel better about using it in production?

@caseyjhol I still wouldn't feel comfortable using it in production even if it was renamed to createMuiThemeStrict because the current documentation for unstable_createMuiStrictModeTheme(options, ...args) => theme says:

WARNING: Do not use this method in production.

The irony is that StrictMode does nothing in production 😆

The irony is that StrictMode does nothing in production 😆 , you could very well branch between the two createTheme helpers.

Since the findDOMNode warning only occurs during development, another way to handle the warning is to change createMuiTheme to unstable_createMuiStrictModeTheme during development and change it back to createMuiTheme in production 😄.

FWIW, I'm trying to get a Dialog component working. I'm starting with the example at https://codesandbox.io/s/4xlrs. I get the findDOMNode warning each time I attempt to apply the paper setting for scroll. That setting is why I'm using the component in the first place. I don't see how to apply the unstable_createMuiTheme work-around because the demo code doesn't appear to use a theme anywhere visible outside the Dialog components.
Is there some resource that can help me find my way through all this without distracting the rest of you? You are all well beyond my expertise with any of this. I'm just looking for a way to get this to work without spending days at each step of a journey with miles to go.
Has anybody updated the Dialog example, even if it isn't published yet? I'm sure there's some straightforward solution -- I just don't know where to look.

FWIW, I'm trying to get a Dialog component working. I'm starting with the example at https://codesandbox.io/s/4xlrs. I get the findDOMNode warning each time I attempt to apply the paper setting for scroll. That setting is why I'm using the component in the first place. I don't see how to apply the unstable_createMuiTheme work-around because the demo code doesn't appear to use a theme anywhere visible outside the Dialog components.
Is there some resource that can help me find my way through all this without distracting the rest of you? You are all well beyond my expertise with any of this. I'm just looking for a way to get this to work without spending days at each step of a journey with miles to go.
Has anybody updated the Dialog example, even if it isn't published yet? I'm sure there's some straightforward solution -- I just don't know where to look.
For example, I don't need a "transition" at all. I can tolerate the Backdrop while the Dialog is open, but I don't need it. Since this complaint seems to be a result of the transition (from the stacktrace) and since it only happens on the paper scroll type, then if there is an easy way to say "no transition" or perhaps pass in a ref (perhaps the findDOMNode isn't needed if there's a ref?) then that would be fine.
For any who have read this far, I appreciate your attention.

This may help
// index.js
// ...
import {createMuiTheme} from "@material-ui/core";
import {unstable_createMuiStrictModeTheme} from "@material-ui/core";
// ...
const createTheme = process.env.NODE_ENV === 'production' ? createMuiTheme : unstable_createMuiStrictModeTheme;
const theme = createTheme({
  // ...
});
// ...
ReactDOM.render(
  <React.StrictMode>
    <CssBaseline/>
    <ThemeProvider theme={theme}>
      <App/>
    </ThemeProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

My understanding is the sole purpose of using StrictMode is to highlight/warn potential issues. If you're doing something to ignore those issues then what's the point of having StrictMode enabled? Developers should not be hiding warnings for the sake of clearing their console but rather using that information to be made aware of potential issues.
I appreciate the MUI team feedback here, and for the other devs wondering how to get around this it seems like update to v5 or just be made aware of the warning. If you don't care about the warning then why are you using StrictMode?

My understanding is the sole purpose of using StrictMode is to highlight/warn potential issues. If you're doing something to ignore those issues then what's the point of having StrictMode enabled? Developers should not be hiding warnings for the sake of clearing their console but rather using that information to be made aware of potential issues.
I appreciate the MUI team feedback here, and for the other devs wondering how to get around this it seems like update to v5 or just be made aware of the warning. If you don't care about the warning then why are you using StrictMode?

I'm relatively new to this entire technology stack. I therefore don't trust my own ability to differentiate between nits that I can ignore and serious issues that I should address. I also don't have time to wrap all this in unit tests. That means that I'm exquisitely sensitive to the strength or weakness of linters like this.
So -- I have StrictMode enabled in general in order to make maximal use of whatever linters already exist.
In a perfect world, this work-around will silence this warning for just this issue. I don't know if that's the case or not.
I'm reluctant to update to v5 because this project is hard enough for me already -- I REALLY don't want to be distracted by bugs in my framework, especially when I have very limited ability to even identify them as such.
The reason that I want to silence this particular warning, at least for awhile, is that it is verbose and happens all the time. The result is that my console is filled with noise (because every complaint about this after the first one is just noise) and that noise obscures far more important console complaints arising from issues with my own code.
Since I find it nearly impossible to put unit tests around all this (I'm normally test-driven and I think I'm pretty good at it. Unit testing in the declarative environment of functional React and ES6 is VERY different from xUnit development in Python, Perl, Ruby, Java, PHP, etc). That means that I'm back at relying on console complaints to alert me to issues.

Developers should not be hiding warnings for the sake of clearing their console but rather using that information to be made aware of potential issues.

Developers should also be respectful of other developers and perhaps a bit slower to assume incompetence or stupidity.
I am not using this technology stack and framework because I like it. I use React and NodeJS because it sucks less than all the alternatives I'm aware of (and I think I'm reasonably well-informed of what's available). I'm pulled a long way out of the envelope  of my ordinary coding (I've been doing all this since 1982), and I don't have head space or time to spend more months drilling down into the bowels of all this to resolve an issue like this -- the very fact that the MUI team has not yet released v5 tells me that it's a mistake to assume that all this is trivial.
It is unfortunate that the toolset for all this is so far behind what has been standard practice for decades. I haven't had to rely on logging to console I coded device drivers in C in 1983. Still, it is what it is. That's not a problem have time to solve right now.
This is all a long-winded way of saying why I REALLY appreciate the workaround from @partoneplay.
I do care about the warning, just not enough to let it block me.

Developers should also be respectful of other developers and perhaps a bit slower to assume incompetence or stupidity.

 I was saying that these warnings are only shown in development mode, once you are in production the warnings won't be shown.
If you're only worried about your console while developing then the fix makes perfect sense, but you're also losing the other warnings. You could also add a filter to your console to ignore particular warnings that you don't care about.

@CWSites: Understood, and that's a good point about the filter. Once I get all this working, I'll turn StrictMode back on and be sure that's my only complaint.

@topheman Do you know if this is still an issue in v5 beta?

Looking at the results of https://github.com/mui-org/material-ui/search?q=StrictModeViolation.

It seems that we are done. The instances where it fails are related to the soon-to-be deprecated @material-ui/styles package. @eps1lon Is it accurate? Is there anything left before we can close?

Public documentation that these methods are neither StrictMode nor React 18 compatible is missing. Then we can close. For StrictMode issues in React 18 I would start a new issue.

@eps1lon  @oliviertassinari
This is still an issue with accordions which I'm seeing in one of my projects.
here's a code sandbox reproduction https://codesandbox.io/s/laughing-wildflower-3fntc

@eps1lon
hm, not sure why my previous comment was hidden, if you like I can delete it but following the comments above it seemed that this issue was resolved and I happened to see it occur so thought I should let you as library authors know.
Thanks

@SangeetAgarwal You are using v4, the latest version is v5.0.0-beta.2, the issue if fixed on this version. I have marked the comment as "outdated".

With the release of v5 (release candidate next week) all StrictMode related issues for React 17 (and current 18) will be fixed. For new StrictMode issues in React 18 we'll want to open a new issue (if they come up).
Happy to close this issue before its 3 year anniversary and thank you for your patience.

version 5.0.1. am I missing something?
index.js:1 Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here: https://reactjs.org/link/strict-mode-find-node
    at div
    at Transition (http://localhost:3000/static/js/vendors~main.chunk.js:142549:30)
    at Grow (http://localhost:3000/static/js/vendors~main.chunk.js:7012:24)
    at div
    at Portal (http://localhost:3000/static/js/vendors~main.chunk.js:13216:24)
    at Popper (http://localhost:3000/static/js/vendors~main.chunk.js:12893:24)
    at Tooltip (http://localhost:3000/static/js/vendors~main.chunk.js:16665:28)
    at WithStyles (http://localhost:3000/static/js/vendors~main.chunk.js:24423:31)
    at Pl (http://localhost:3000/static/js/vendors~main.chunk.js:45129:12)
    at div
    at div
    at div
    at _l (http://localhost:3000/static/js/vendors~main.chunk.js:45333:13)
    at Nl (http://localhost:3000/static/js/vendors~main.chunk.js:45467:14)
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:45515:13
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:45553:16
    at div
    at ql (http://localhost:3000/static/js/vendors~main.chunk.js:45574:8)
    at ya (http://localhost:3000/static/js/vendors~main.chunk.js:46074:15)
    at Ea (http://localhost:3000/static/js/vendors~main.chunk.js:46100:1)
    at Sa (http://localhost:3000/static/js/vendors~main.chunk.js:46128:15)
    at div
    at NoSsr (http://localhost:3000/static/js/vendors~main.chunk.js:11456:24)
    at http://localhost:3000/static/js/vendors~main.chunk.js:46527:13
    at Ms (http://localhost:3000/static/js/vendors~main.chunk.js:50767:11)
    at http://localhost:3000/static/js/vendors~main.chunk.js:51116:13
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:1486:73
    at CardContent (http://localhost:3000/static/js/vendors~main.chunk.js:33905:86)
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:1486:73
    at Paper (http://localhost:3000/static/js/vendors~main.chunk.js:35737:86)
    at http://localhost:3000/static/js/vendors~main.chunk.js:1486:73
    at Card (http://localhost:3000/static/js/vendors~main.chunk.js:33738:86)
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:1486:73
    at Grid (http://localhost:3000/static/js/vendors~main.chunk.js:34917:91)
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:1486:73
    at Grid (http://localhost:3000/static/js/vendors~main.chunk.js:34917:91)
    at Dashboard (http://localhost:3000/static/js/main.chunk.js:1184:75)
    at Route (http://localhost:3000/static/js/vendors~main.chunk.js:137144:29)
    at GuardedRoute (http://localhost:3000/static/js/main.chunk.js:312:3)
    at Switch (http://localhost:3000/static/js/vendors~main.chunk.js:137346:29)
    at div
    at http://localhost:3000/static/js/vendors~main.chunk.js:1486:73
    at Paper (http://localhost:3000/static/js/vendors~main.chunk.js:35737:86)
    at div
    at InnerThemeProvider (http://localhost:3000/static/js/vendors~main.chunk.js:38557:74)
    at ThemeProvider (http://localhost:3000/static/js/vendors~main.chunk.js:38139:5)
    at ThemeProvider (http://localhost:3000/static/js/vendors~main.chunk.js:38577:5)
    at App (http://localhost:3000/static/js/main.chunk.js:85:86)
    at Router (http://localhost:3000/static/js/vendors~main.chunk.js:136775:30)
    at BrowserRouter (http://localhost:3000/static/js/vendors~main.chunk.js:136396:35)
    at Provider (http://localhost:3000/static/js/vendors~main.chunk.js:133160:20)
console.<computed> @ index.js:1
printWarning @ react-dom.development.js:67
error @ react-dom.development.js:43
findHostInstanceWithWarning @ react-dom.development.js:25406
findDOMNode @ react-dom.development.js:26067
performEnter @ Transition.js:245
updateStatus @ Transition.js:228
componentDidMount @ Transition.js:172
commitLifeCycles @ react-dom.development.js:20663
commitLayoutEffects @ react-dom.development.js:23426
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
commitRootImpl @ react-dom.development.js:23151
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
commitRoot @ react-dom.development.js:22990
performSyncWorkOnRoot @ react-dom.development.js:22329
(anonymous) @ react-dom.development.js:11327
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushSyncCallbackQueueImpl @ react-dom.development.js:11322
flushSyncCallbackQueue @ react-dom.development.js:11309
scheduleUpdateOnFiber @ react-dom.development.js:21893
dispatchAction @ react-dom.development.js:16139
(anonymous) @ useControlled.js:38
handleOpen @ Tooltip.js:273
(anonymous) @ Tooltip.js:306


How does this integrate with the Source control and build process

We can have X++ code checked in to DevOps and picked up by a build VM.
Will it work for C# code? If not, please describe the process.

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

ID: 292aba1a-611d-3c57-b6b3-4ad4c1f609c6
Version Independent ID: a85180de-f264-3a6a-cd6c-51bb019cecac
Content: Write business logic by using C# and X++ source code - Finance & Operations | Dynamics 365 | #MSDyn365FO
Content Source: articles/dev-itpro/dev-tools/write-business-logic.md
Service: dynamics-ax-platform
GitHub Login: @pvillads
Microsoft Alias: pvillads

@turbozapekanka, Thanks for posting this! In the meantime, to get product help you can contact Support using one of the options described here: Support contact options. In particular, you might want to go to the Dynamics 365 for Finance and Operations community page to get help with your questions from the Dynamics community.
@pvillads, please review and update the content as needed.

Bug 336503 has been logged to track this issue.

This is currently not integrated into the standard build pipeline. You would have to manually edit the pipeline to compile and copy the output. We have blogged about one somewhat standard option to accomplish this using dependency XML file: https://community.dynamics.com/365/financeandoperations/b/newdynamicsax/posts/selecting-what-models-are-part-of-the-build-automation-process
However, this is not a great experience and most people familiar with C# and builds can typically edit the build definition to their liking in a simpler way. Additionally, we are working on a newer build pipeline, without VM, which is more standard and will support this correctly out of the box.
As such, we are not planning to update the documentation as the new build is currently in private preview already and should go to a public preview soon.


use https url for submodule

I suggest to replace the submodule url with an https url (instead of ssh), which is easier for users that don't have an ssh key set up with github. We use this repo as a submodule in one of our repos and it looks like some user ran into this issue (link).

Makes sense, thanks for the PR


Make days in time entry list collapsible

Depends on #1746.

Implementation started on win-split-cells-by-day. Days collapse, still to be fixed are keyboard highlight, end edit popup behaviours and a few small details.

Completed on same branch.


Denoise kernel size

I'm finding for some older phase1/phase2 fieldmaps that it's necessary to set the kernel size to 5 for this node: https://github.com/poldracklab/sdcflows/blob/0.0.2/sdcflows/workflows/phdiff.py#L98
Is there a downside to setting the default to 5? Or  should we make this a parameter?

Does it make sense to set a target smoothness instead of a straight kernel smoothing, as with 3dBlurToFWHM? Then we're less dependent on the quality of the input data.

Hopefully, this will not be necessary after #14, but it doesn't hurt to first get this done.

For now I have the kernel size only go up to 5 if there are two phase maps (#30) and the size stays 3 for phasediff images. #30 also re-organizes the workflows so that #14 can be used on these fieldmaps

I've set 5 as the default for now, and I'm pretty happy with the results.
I'm also with @effigies that 3dBlurToFWHM is a very cheap but effective solution to the problem.
Finally, we need to investigate the resampling when moving the fieldmap to the target EPI dataset because I'm under the impression that it is introducing some little spikes in it.

Isn't 3dBlurToFWHM doing Gaussian smoothing instead of a median filter? I thought the main purpose was to remove spikes, which would end up getting spread out spatially if you just smooth with a Gaussian kernel.

Isolated spikes would be removed with a Gaussian filter easily - median filters are better for salt&pepper kind of noise. It doesn't hurt to try.
But yes, you are right - the median filter is just to remove spikes

Superseded by #119.


Handle Nullable types

See #16

Also, we should probably be handling Nullable differently to other generics...
Json Schema allows for { "type": "null" }, see: https://json-schema.org/understanding-json-schema/reference/null.html
Which means we could detect System.Nullable and set the property as { "type": [ "T", "null" ] }

Thinking of looking into this for Hacktoberfest. Any pointers?

We generate a Document which contains Messages, each message has a Payload.
https://github.com/tehmantra/saunter/blob/279f51fce99847009b43badb522428638e3b6688/src/Saunter/Generation/DocumentGenerator.cs#L253
This ISchema is in JSON-Schema format.
When we set the Schema.Type property (which is currently a string) by reflecting types in the SchemaGenerator.
https://github.com/tehmantra/saunter/blob/279f51fce99847009b43badb522428638e3b6688/src/Saunter/Generation/SchemaGeneration/SchemaGenerator.cs#L31:L49
An example of a simple schema representing a non-nullable int:
{
    "type": "integer"
}

An example representing a nullable int:
{
    "type": ["integer", "null"]
}

We need to make Schema.Type render as either a string "T", or if the type is nullable, an array containing [ "T", "null" ].
We can optionally/additionally support the OpenAPI spec which defines an additional property nullable: bool
Example of nullable int in OpenAPI:
{
    "type": "integer",
    "nullable": true
}

This is implemented using a [Flags] enum in Newtonsoft.Json.Schema
https://github.com/JamesNK/Newtonsoft.Json.Schema/blob/master/Src/Newtonsoft.Json.Schema/JSchemaType.cs
Same as NJsonSchema
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema/JsonObjectType.cs
I suppose this is the easiest way to be able to set this as one or more value.
// for non-nullable primitives
Type = JsonSchemaType.Integer;

// for nullable-primitives
Type = JsonSchemaType.Integer | JsonSchemaType.Null;

This also allows for setting the nullable type separate from the underlying type;
var type = JsonObjectType.Integer;

//... elsewhere
if (nullable) {
    type = type | JsonObjectType.Null;
}

Closing in favor of #60


Picker UI is not consistent at safari - reported by @Puneet-here

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to settings > preferences

Expected Result:
The picker is not consistent and looks broken
Actual Result:
Describe what actually happened
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web

Version Number: 1.1.99-0
Reproducible in staging?:  Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
Issue reported by: @Puneet-here
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1661765012423859
View all open jobs on GitHub

Unable to repro on v1.2.2-0, @mvtglobally are you still able to repro this?


Use "Un-tag" and "Unmark" menu options for tagged NPCs and marked objects/tiles

Closes runelite/runelite#1177

Can this be also extended for object markers etc?

Added a commit to make a similar change in the object markers plugin.

Added another commit for ground markers while I was at it.

Needs rebase


Cannot draw any content initially on macOS 10.14 (until window is moved or resized)

These codes are most from glfw guide "Getting started". It works fine in macOS 10.13, but it draw nothing from beginning on macOS 10.14. If you move / resize the window manually, your content will write to screen finally.
main.txt

Confirmed.
The same problem for me.

Same problem here. I tried to work around the problem by doing a resize in my application to see if that would trigger the drawing, but it seems that only a manual resize of move of the window will trigger the drawing.

Same here.

glfw just needs to call update() on the NSGLContext a couple of times before swapping the buffers. https://github.com/kovidgoyal/kitty/commit/b82e74f99ae30599cd88ef6a1216625b57a0414a

I confirm.
I work around with glfwSetWindowsSize (with different initial size), (ONLY!) after first glfwSwapBuffer: before does not work.

Yes, I confirm.
My work around (for now) is to call glfwSetWindowsSize (with different initial size), once, in main loop, ONLY(!) after the first glfwSwapBuffers: resize before does not work.
Like this:
            glfwSwapBuffers(getGLFWWnd());

#ifdef __APPLE__
            static bool macResized = false;

            if(!macResized) {
                glfwSetWindowSize(getGLFWWnd(),differentWidth, differentHeight);
                macResize = true;
            }
#endif

you dont need to do that, just call the update method on the nsglcontext object, as I demonstrated in the commit I linked to earlier.

I noticed that the Gears example works fine, and stops working when removing glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE); from it. So I guess that making transparent buffers could also be a work-around.

Here's a workaround that worked for me:
Use glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE); before creating the window.
If the application results with transparency in the frame buffer and background is showing through the window, clear your frame buffer's alpha (using glColorMask, glClearColor, and glClear) before swapping buffers.

Quoting @BrutPitt

My work around (for now) is to call glfwSetWindowsPos (with different initial position), once, in main loop, ONLY(!) after the first glfwSwapBuffers: move before does not work.

I like this workaround, as it works for early versions of GLFW (GLFW_TRANSPARENT_FRAMEBUFFER
is only available on newer versions) and is at the public API level.

I spend some time debugging how NSOpenGLView works and why it has no problems with rendering immediately. I disassembled the NSOpenGLView and found out that it is creating a custom layer (class: _NSOpenGLViewBackingLayer). I tried to create the same layer and it worked. I start to investigate the code of the _NSOpenGLViewBackingLayer and found out that it does some stuff in the display method and it is a subclass of CALayer. I tried to copy the functionality of the _NSOpenGLViewBackingLayer, but with no success. Then I tried to simply create an instance of CALayer and it worked!
PS. One call to [NSOpenGLContext update] must be made (it is done in [NSOpenGLView openGLContext] method.
Here is the fix (for my engine), it should be easy to integrate the same code in GLFW:
https://github.com/elnormous/ouzel/commit/eaa566abbee8a2c6e2e07bf4ecfb51960ba5debb
PS. My workaround is more elegant than updating the NSOpenGLContext two times because mine starts rendering immediately (from the first frame) instead of two frames later. This is useful in case you want to render something only once, save the result, and quit.

Ok, my fix broke compatibility with older macOS which does not use layers for rendering. Did some more disassembling and came to a fix, that works both on Mojave and older versions on macOS: https://github.com/elnormous/ouzel/commit/7e708636189d970bad6b013ecd5375cfe693f3f3
Basically calling [NSOpenGLContext update] without a layer attached to the view does nothing and usually, it is not attached to the view on the first frame (that is why you have to do it on the second one). But this risky, because the layer can be attached to the view sometime later. My fix updates the NSOpenGLContext as soon as the layer is being set.

Please see if the mojave-fixes branch resolves this for you.

@elmindreda, looks good.

@BrutPitt I already downloaded the last version of source code (commit 8055dad7), rebuilt and reinstalled it. But I still have this problem.
Do you have any clues of what's happening?
I don't know if this is important, but I have XCode v9.4.1

Hi @jfbueno
After reading your post I ri-tested my project on MAC OS X 10.14.1, and also on 10.14.3 (after update) and for me all works fine.
Currently I have in my project an olden GLFW version (November) that work well, but I tested (just now) also the last commit 8055dad without problem.
I'm not a GLFW developer, but only a developer that use GLFW ;-)
I use GLFW with OpenGL 4.1 (on MAC), and CLang (XCode 10.1 with command line extension) version: Apple LLVM 10.0.0 clang-1<IP_ADDRESS>.
And (if it can help) this is my GLFW initialization from my glApp.cpp
        glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
        glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);
        glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
        glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
        glfwWindowHint(GLFW_DOUBLEBUFFER, GL_TRUE);

Unfortunately now I have no way to test it with a older version of XCode or OS X
But it makes me think... are you sure that you link the correct version of GLFW, and not maybe an old version that is yet in the LIB path?
(this happened to me)

I didn't notice, sorry. Thanks for your help, anyway.
Don’t mention it, I'm glad to help (if I can), but mostly glad you solved.


Do not depend on Rails

Rails comes with Actioncable and all sorts of other stuff which not everyone might want to have installed. It's better to depend on the parts of Rails that are actually required by Clearance. Otherwise everyone is forced to install all parts of Rails instead of just the parts that are necessary.

FYI this other PR seems to target the same goal: #776

Thanks for this idea! Resolved by https://github.com/thoughtbot/clearance/pull/800


SystemChrome.setApplicationSwitcherDescription makes the app NAME disappear in the application switcher

Steps to Reproduce
Our app is a mix of Flutter and native development, flutter is only used for part of the functional UI。
When the flutter engine is first initialized，SystemChrome.setApplicationSwitcherDescription makes the app NAME disappear in the application switcher！！！

MaterialApp-->WidgetsApp-->Title-->SystemChrome.setApplicationSwitcherDescription

It is hoped that this feature can be turned on or off by variable switch,
for example SystemChrome.setSystemUIOverlayStyle

➜  ~ flutter doctor -v
[✓] Flutter (Channel stable, 2.5.3, on macOS 11.6 20G165 darwin-x64, locale
    zh-Hans-CN)
    • Flutter version 2.5.3 at /Library/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (9 months ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/junhualin/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✗] Xcode - develop for iOS and macOS
    ✗ Xcode installation is incomplete; a full installation is necessary for iOS
      development.
      Download at: https://developer.apple.com/xcode/download/
      Or install Xcode via the App Store.
      Once installed, run:
        sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
        sudo xcodebuild -runFirstLaunch
    ✗ CocoaPods not installed.
        CocoaPods is used to retrieve the iOS and macOS platform side's plugin
        code that responds to your plugin usage on the Dart side.
        Without CocoaPods, plugins will not work on iOS or macOS.
        For more info, see https://flutter.dev/platform-plugins
      To install see
      https://guides.cocoapods.org/using/getting-started.html#installation for
      instructions.

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

[✓] Android Studio (version 2021.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      11.0.12+0-b1504.28-7817840)

[✓] Connected device (1 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 103.0.5060.114

! Doctor found issues in 1 category.

Hi @JunhuaLin, you appear to be on an older version of flutter.
Can you upgrade to the latest version of flutter to see if you still experience the issue?
If you do, please provide a complete minimal reproducible code sample as well as the output of flutter doctor -v.
Thank you

Hi @JunhuaLin, you appear to be on an older version of flutter.
Can you upgrade to the latest version of flutter to see if you still experience the issue?
If you do, please provide a complete minimal reproducible code sample as well as the output of flutter doctor -v.
Thank you

The master branch code for the current Flutter repository is unchanged. The question remains

Hi @JunhuaLin, there's a chance that something could have changed on the engine side that fixed the issue.
The SystemChrome.setApplicationSwitcherDescription should not make the application name disappear so that is a bug that needs to be fixed if it exists on the latest versions of flutter.
Kindly confirm if you still experience this issue on the latest version of flutter.
If you do, please provide a complete minimal reproducible code sample as well as the output of flutter doctor -v.
Thank you

Hi @JunhuaLin, there's a chance that something could have changed on the engine side that fixed the issue.
The SystemChrome.setApplicationSwitcherDescription should not make the application name disappear so that is a bug that needs to be fixed if it exists on the latest versions of flutter.
Kindly confirm if you still experience this issue on the latest version of flutter.
If you do, please provide a complete minimal reproducible code sample as well as the output of flutter doctor -v.
Thank you

We developed Flutter with a native project. The MaterialApp#title field has not been set。
What SystemChrome#setApplicationSwitcherDescription USES the empty string makes the app NAME disappear in the application switcher！
So It is hoped that the SystemChrome#setApplicationSwitcherDescription feature can be turned on or off by variable switch

Labeling for further input from the team


Feature request: Add URI service to download the ontology

Provide a URL, e.g.,
http://endopint-url/onto

for giving external applications the possibility of downloading the ontology.

Implemented in
feature/ontologyFetcher

To be merged.

Implemented, tested, and merged in branch version4.


False positive for Rails/ActionControllerFlashBeforeRender when redirecting in ensure

When using an ensure block to redirect (see below controller code), this cop raises an error.
I think it's different, but could be related to: https://github.com/rubocop/rubocop-rails/issues/909
  def destroy
    if label_icon.destroy
      flash[:success] = "Label Icon deleted: #{label_icon.name}."
    end
  rescue ActiveRecord::InvalidForeignKey => e
    flash[:error] = "Cannot delete #{label_icon.name}, remove from all packing categories first."
  ensure
    redirect_to admin_label_icons_path # <- This action never renders, because of this redirect
  end

Expected behavior
Rubocop pass
Actual behavior
C: [Correctable] Rails/ActionControllerFlashBeforeRender: Use flash.now before render.
    flash[:error] = "Cannot delete #{label_icon.name}, remove from all packing categories first."
    ^^^^^

Steps to reproduce the problem
Run rubocop on the above code.
RuboCop version
bundle exec rubocop -V
1.39.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.23.0, running on ruby 3.1.2) [x86_64-darwin19]
  - rubocop-rails 2.17.3

There is a similar false positive when using a conditional followed by rescue:
  context 'when using `flash` before a `redirect_to` in a conditional branch followed by render & rescue' do
    it 'does not register an offense' do
      expect_no_offenses(<<~RUBY)
        class HomeController < ApplicationController
          def create
            if condition?
              flash[:notice] = "success"
              redirect_to login_path
            else
              flash.now[:error] = "conditional error"
              render :new
            end
          rescue ActionController::ParameterMissing
            flash.now[:form_errors] = "param error"
            render :new
          end
        end
      RUBY
    end
  end

This issue has been resolved by latest RuboCop Rails. Please upgrade to the latest version of RuboCop Rails. Thank you.


How to create a slideshow with navigation????

I want to create a full screen image slider that has a navigation, which allows you to choose which image you want to skip to and shows which image your currently on like in this example:
http://demo.dev7studios.com/nivo-slider/
(the above link is not a FULL SCREEN image slider, but it shows what i mean).
How would I do this? I think i know how to create a nav so that it skips to certain images, but how do you show which image your currently on?
Please Help!!!!

Hi Christopher, can you provide the HTML of the given code please? I've tried links and their containers with these classes, but can't seem to get it to work.
I'm working with the Drupal module btw.


Extension to load static files - Error on install via bower

When I try to install  angular-translate-loader-static-files extension via bower, is thrown the following error:
bower angular-translate-loader-static-files#*       not-cached git://github.com/PascalPrecht/bower-angular-translate-loader-static-files.git#*
bower angular-translate-loader-static-files#*          resolve git://github.com/PascalPrecht/bower-angular-translate-loader-static-files.git#*
bower angular-translate-loader-static-files#*          ECMDERR Failed to execute "git ls-remote --tags --heads git://github.com/PascalPrecht/bower-angular-translate-loader-static-files.git", exit code of #128 fatal: read error: Connection reset by peer

Additional error details:
fatal: read error: Connection reset by peer

Any suggestion?
Thanks!

Yes, the failure is caused by the underlaying connection -- your online connection. "read:error: Connection reset by peer" is a low level message.
Either you have local issues, or github.com has/had issues in the moment (dealing your request). In both way we can recommend only: try again.


Feature Request: Make a Jupyter Notebook cell into view of an existing Python file

I'll start with saying this isn't a trivial ask, but I think would be worth the effort. I'd love to have the ability to make a cell in a Jupyter notebook a "live" view of a python file, so that when I edit code for, say, a class I'm workshopping, I don't have to keep copying and pasting changes into that .py to reflect the changes I've made in the notebook. This could work vice versa where you can ask to update the content of the cell with the .py if you come back to that notebook later.
I'm not sure how many people have this workflow of workshopping classes that naturally exist in a .py somewhere, but are iterated on in jupyter notebook, but I know it would be a huge deal for me.
I mentioned it wouldn't be trivial. I don't know too much about jupyter and its .json reading, but maybe you can just add some meta information about the cell in the .json that has a link to the original file. This can allow the extension to start a dialog with it. I don't know, just spit-balling ideas.

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


⚠ Bofrost.de has degraded performance

In 255e15f, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1977 ms

Resolved: Bofrost.de performance has improved in 8fe0739.


dndfonts.sty: Fix compilation with xelatex and lualatex

dndfonts.sty includes kpfonts, which is compatible with pdflatex, but not with xelatex and lualatex. While the kpfonts package defaults to including kpfonts-otf when it detects xelatex or lualatex, it doesn't pass options to kpfonts-otf, which makes lualatex and xelatex complain about unrecognised options used in dndfonts.sty (i.e., notext, nomath, nott), and change almost all fonts in the style.
This fix tests for pdflatex in lib/dndfonts.sty, and else loads kpfonts-otf directly, correctly passing the necessary options.

... in the meantime, I've contacted Herbert Voss, who made the latest changes to kpfonts. He sent me a patched kpfonts.sty that does parse and pass options to kpfonts-otf, so I hope soon the workaround that I shared in this PR actually isn't necessary.

kpfonts has been fixed, this PR is no longer necessary!


wrangler route list knows nothing about --env

🐛 Bug Report
Looks like the route command is unable to load config according to a specified environement:
$ wrangler route list --env production
Error: You must specify a zone_id in `wrangler.toml` to use `wrangler route` commands.

Environment

operating system: linux/ubuntu
output of rustc -V: N/A
output of node -v: v12.16.1
output of wrangler -V: wrangler 1.8.2

Steps to reproduce
Put configuration of zones/accounts/routes in an env section and try to list the routes.
What did you expect to see?
Routes associated to an env.
What did you see instead?
missing configuration message or default config routes instead of the env's ones.

The error message here indicates that you need to set a zone_id in the [env.production] section of your wrangler.toml in order for that command to work.

Of course the zone_id and account_id have been filled for these envs because I can publish the worker.
here is a sample to reproduce it:
cd /tmp
wrangler generate -t webpack test-route
cd test-route

wrangler.toml
name = "test-route"
type = "javascript"
account_id = ""
workers_dev = true
route = ""
zone_id = ""

[env.production]
account_id = "1516XXXX"
zone_id = "9c08XXXXX"

I can also confirm that this is an issue.
If I create an environment, then I can no longer use
wrangler route list

I'm still unable to reproduce this error - @ashleymichal maybe you can try?

@EverlastingBugstopper In the example I gave I voluntarily let empty the account and zone id to demonstrate it doesn't take into consideration the values in the prod env.
If you have an account and zone id in the default section, then if you try to switch to another zone in the prod env you'll see you'll query the default zone, not the prod one.
Hopping it will help to reproduce...

we've repro'd this and  i've started on a solution.  should be able to work on it more later this week.

Same Problem here, is there a fix?

I'll take a look at this issue


User Story: Add product to cart

The website should allow the user to add available products to the cart of any quantity, and to remove those products from the cart as well.

Already uploaded the add products page


Floating point issues

What is wrong.
In order to be compliant with the spec, we need code that does the following.

let A be the unsigned 64 bit integer:<PHONE_NUMBER>9102705664
let B be the 64 bit floating point representation of A
let C be the 64 bit integer representation of B
assert A == C

Where is this requirement described in the spec? I think I could tackle this.

Not specifically, it's derived from a failing test.  Specifically the one in float_exprs.wast.json, command line 515

More on that failing test:
runner.py                  433 DEBUG    running command: line=515  type=<class 'wasm.tools.fixtures.datatypes.AssertReturnCommand'>
runner.py                  148 DEBUG    function_address: 71
control.py                  51 DEBUG    block()
variable.py                 31 DEBUG    get_local()
numeric.py                1159 DEBUG    f64.convert_s/i64(17293822569102705664)
numeric.py                1091 DEBUG    i64.trunc_s/f64(-1.152921504606847e+18)
control.py                 120 DEBUG    end()
control.py                 120 DEBUG    end()
runner.py                  204 DEBUG    expected:<PHONE_NUMBER>9102705664 | actual:<PHONE_NUMBER>9102704640

You can see it passes through two opcodes, f64.convert_s/i64 > i64.trunc_s/f64 and the result should be the same as the input.

Assuming https://babbage.cs.qc.cuny.edu/IEEE-754.old/64bit.html is correct it suggests pythons float representation is truncating (which isn't surprising).  The binary representation is:
0100001111101110000000000000000000000000000000000000010000000000

But if you convert struct.pack('>d', float(17293822569102705664)) to binary it is;
0100001111101110000000000000000000000000000000000000000000000000

Which you can see there's a bit different between the two.

Yeah that extra bit seems to make the difference. It's in the 11th place and that means it represents 2 ** 10 = 1024 which appears to be the difference between the actual and expected values.

Murrr, this was really just an incorrectly implemented set of opcodes and then me mis-understanding what was supposed to be happening under the hood.  The correct set of operations which work natively with python constructs is starting_int -> starting_int_as_signed -> starting_int_as_float -> math.trunc(starting_int_as_float) -> result which correctly evaluates, ie. starting_int == s64_to_u64(math.trunc(u64_to_s64(starting_int))) works correctly.


[pulsar-proxy]Adjust the location of logger.debug

(If this PR fixes a github issue, please add Fixes #<xyz>.)
Fixes #
(or if this PR is one task of a github issue, please add Master Issue: #<xyz> to link to the master issue.)
Master Issue: #
Motivation
Explain here the context, and why you're making that change. What is the problem you're trying to solve.
if (log.isDebugEnabled()) {
                        log.debug("[{}] [{}] Removing decoder from pipeline", inboundChannel, outboundChannel);
                    }

The above log should be output when the decoder is actually removed.
Modifications
Describe the modifications you've done.
Adjust the location of the log.
Verifying this change

[x] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no) no
The public API: (yes / no) no
The schema: (yes / no / don't know) no
The default values of configurations: (yes / no) no
The wire protocol: (yes / no) no
The rest endpoints: (yes / no) no
The admin cli options: (yes / no) no
Anything that affects deployment: (yes / no / don't know) no

Documentation

Does this pull request introduce a new feature? (yes / no) no
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

thank you very much @mantuliu
committer to master branch, it will be available on 2.8.0


IVs of 0 are read as 31 by correctHiddenPower

This line doesn't differentiate between IV values of 0 and undefined
https://github.com/smogon/damage-calc/blob/81f2e785da80b10d190c55cf6b3f94bcd0a4855e/src/js/shared_controls.js#L963
This is an issue for any pre gen 7 set with hidden power in its moveset & 1 or more IVs of 0. The gen 5 Bronzong (OU Tank) set should have a speed IV of 0, but gets assigned 31 instead (which has a big effect on its gyro ball damage).
Can be fixed by changing the line's || to ??.

also, nbd but I think the for loop's condition should be < rather than <=
https://github.com/smogon/damage-calc/blob/81f2e785da80b10d190c55cf6b3f94bcd0a4855e/src/js/shared_controls.js#L961


test

Codecov Report

Merging #13 (56130c4) into main (8c4520a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #13   +/-   ##
=======================================
  Coverage   11.05%   11.05%
=======================================
  Files           4        4
  Lines        1095     1095
=======================================
  Hits          121      121
  Misses        974      974

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 97a5327...56130c4. Read the comment docs.


Trailing Slash in url Replacment

Is there a way to use another field for the image replacement? In my version of Powerpoint 16.38 (osx) when I put in a url replacement variable $/image1/ it get replaced to $/image1 and therefore never gets swapped out from the template.

Seems like if I put a \ at the end it works.

Hi @daltonch,
Thank you for your interest in this library!
You are right, configure this might be a good addition.
To be sure, can you confirm this behavior:
try(FileOutputStream out = new FileOutputStream("generated.pptx")) {
  new PptMapper()
    .variableCharDelimiter("|")
    .text("title", "Hello")
    .text("subtitle", "World!")
    .processTemplate(PptTemplateDemo.class.getResourceAsStream("/title.pptx"))
    .write(out);
}

So you would be able to use $|title| in your presentation, and it would correctly be replaced by Hello.


Upgrade io.projectreactor:reactor-bom 2022.0.6 -> 2022.0.7

This PR contains the following updates:

Package
Type
Update
Change

io.projectreactor:reactor-bom (source)
import
patch
2022.0.6 -> 2022.0.7

Release Notes

reactor/reactor
v2022.0.7
Compare Source
2022.0.7 release train is made of:

reactor-core 3.5.6
reactor-netty 1.1.7
reactor-kafka 1.3.18

These artifacts didn't have any changes

reactor-pool 1.0.0
reactor-addons 3.5.1
reactor-kotlin-extensions 1.2.2

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade Project Reactor 2022.0.6 -> 2022.0.7

See:
- https://github.com/reactor/reactor/releases/tag/2022.0.7
- https://github.com/reactor/reactor/compare/2022.0.6...2022.0.7


NewRelicAgent 7.5.2 fails downloading

The latest NewRelicAgent version - 7.5.2 - cannot be installed by CocoaPods. The server where the xcframework is hosted responds with Error 503 Response object too large.
Description
As stated above, NewRelicAgent 7.5.2 cannot be used in an iOS project that uses Cocoapods due to the XCFrameworks file download failing.
Steps to Reproduce

Start a new project and configure it with Cocoapods, or use an existing one
Add the pod 'NewRelicAgent', '7.5.2' to a target
Run pod install

Expected Behavior
The pods successfully install.
Relevant Logs / Console output
$ pod install
Analyzing dependencies
Downloading dependencies
Installing NewRelicAgent (7.5.2)

[!] Error installing NewRelicAgent
[!] /usr/bin/curl -f -L -o /var/folders/cg/ld1r2k3d4kj97tsz6_1hbc5w0000gn/T/d20241109-41722-1x2fvlo/file.zip https://download.newrelic.com/ios_agent/NewRelic_XCFramework_Agent_7.5.2.zip --create-dirs --netrc-optional --retry 2 -A 'CocoaPods/1.16.2 cocoapods-downloader/2.1'

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   472    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (56) The requested URL returned error: 503

curl -v https://download.newrelic.com/ios_agent/NewRelic_XCFramework_Agent_7.5.2.zip gives a similar response, though with more details.
Opening the URL in a web browser results in the same error:

Your Environment
MacOS Sequoia 15.0.1 (24A348)
Xcode 16.1 (16B40)
Cocoapods 1.16.2
Additional context
None

This was related to an outage in New Relic's download site at https://download.newrelic.com/ over the weekend.
I have verified that asset is now available again.


//undo doesnt work (FAWE)

Server OS: Mohist
1.12.2 Forge
Last Version of REID
0 mod installed

step to reproduce:
start a server with REID and FAWE (fastAsyncWorldEdit)
do a command to edit the world, then execute //undo

No error on the console
No error on client
The undo command just replace all block in area to air without
this happen:

https://media.discordapp.net/attachments/1224013658707722330/1242785054053367849/image.png?ex=664f1946&is=664dc7c6&hm=4ed0d10443096b2856f9a48065143428300313c4a74f3cf8ee3b4a8042cecda6&=&format=webp&quality=lossless&width=720&height=289

I don't plan on supporting FAWE, as it looks like there is no easy way to get the source in a dev environment. Please use regular WorldEdit (the mod version is the only tested one), as that is supported by REID. In general, non-Forge servers aren't really supported either.