i have suggest to update useRef.current when there is a new value not in useEffect, as it may be deffered
here : https://github.com/facebook/react/issues/14927#issuecomment-474787269
Hope, @gaearon will explain his point of view.

I'm not 100% on this, but I think that a side effect, like mutating a ref on render, will cause issues with concurrent React. When done inside useEffect tree consistency is guaranteed. Not so much when done in the render method's body. Or at least that's my understanding.

I'm not 100% on this, but I think that a side effect, like mutating a ref on render, will cause issues with concurrent React. When done inside useEffect tree consistency is guaranteed. Not so much when done in the render method's body. Or at least that's my understanding.

Sorry but i do not agree at all. this sound like all is dangerous, just to scared people.
it is totally safe and there is no side effect, if you know what you are mutating and when you need it updated or not.
Snd this is the case, we need to save a ref to the last props rendered.
There is too much hype on side effect, and so people forgot what is a pointer!!!.

@salvoravida,

We do the assignment inside an effect so that the ref value only changes after the DOM has been updated. This ensures our mutation doesn’t break features like Time Slicing and Suspense which rely on interruptible rendering.

- Dan on How Are Function Components Different from Classes?

@salvoravida,

We do the assignment inside an effect so that the ref value only changes after the DOM has been updated. This ensures our mutation doesn’t break features like Time Slicing and Suspense which rely on interruptible rendering.

Dan on How Are Function Components Different from Classes?

@migueloller
The problem is just this: people do not understand what is a pointer and what is thier use case.
The general warning of Dan mutation doesn’t break features like Time Slicing and Suspense
has the side effect of scared peopole, like you, without understanding what they are doing.

in the demo of Dan (setTimemout - show message), even if React Suspend the render and do not commit to dom, the "new message" is already fired by the user, so IT IS CORRECT to save the last message that the user fire on render phase also.

in our case react-redux, even if React Suspence or ConcurrentMode interrupt render, we need always the last props in our current ref, so it is TOTALLY safe to update them in render phase, even if it is INTERRUPtED, becouse
a) if it will be re-redered with same last props, it's fine we already have them,
b) if it will be re-renderd with some-prevs props, react-redux selector will be recalculated.

So as you can see, Dan mutation message, is for 99% of use case, not 100%.

@deini
it would be nice to see your point, with code/demo that support your KO.

@salvoravida I'm just downvoting because of the offensive language, as usual.

@salvoravida I'm just downvoting because of the offensive language, as usual. (Won't reply again, to keep the thread focused)

Coding is not a religion. You should reply to something with code/example support of your idea, as i do.
Otherwise is just doing what "others" say, without understanding WHY.

Awright, cool it down, folks, or I'm going to have to lock this thread so that I'm the only one giving updates.

Specifically addressing the issue at hand:
The ideal solution here is to update the ref in useLayoutEffect().  That runs its callback synchronously in the commit phase, after the render has been completed, which is the same phase where cDM/cDU run.  This also matches the behavior of how v5's class-based implementation worked, where the nested subs are notified in cDU (which winds up cascading the store updates synchronously).
However, the React team has chosen to log console warnings any time useLayoutEffect() is called in SSR, because they're apparently worried folks will call it to do some kind of critical behavior without realizing it won't actually execute in an SSR environment.  That's unfortunate, given that useLayoutEffect() is a perfectly valid public API.
@salvoravida 's suggestion of writing to the ref directly in the render logic has both pros and cons:

👍 Pros:

It does seem like it would solve the timing issue overall
Yes, it's just a pointer assignment
No console warnings in SSR

👎 Cons:

Technically a side effect in render
Could potentially wind up with an incorrect props reference in Concurrent Mode if the component rendered, but the render was thrown away before it's committed (so it's not "totally safe" to assign this)

That said, we're already doing at least one "bad" thing in the render logic right now (directly reading the store state if the render was not caused by a store update), so it's likely v7 really isn't Concurrent Mode-compatible anyway.
It's also worth noting this is an incredibly obscure edge case.  It's possible there's a simpler repro, but I'd be willing to bet 99.9999% of React-Redux users wouldn't be in a situation where this would come up.
Summing up: I'll try to poke around at this further and see if I can come up with any other possible options.  If not, I'm willing to consider the "assign ref in render" approach for now to get v7 out the door.  It's also worth continuing to push the React team to remove that console warning for useLayoutEffect() in SSR.

@markerikson, I think the pros outweigh the cons given that v7 is already reading from the mutable store reference in render. In a future version any issues with concurrent mode could be fixed. Given that, I think mutating the ref in render would be fine for now.

I do have several other things I need to get done over the next couple days.  What would really help me at this point is if someone can turn @alexreardon 's sandbox into a unit test in connect.spec.js that fails on the current v7-beta branch, and ideally would actually pass if that little ref tweak is made or useLayoutEffect() is used to save the wrapper props.
I think the code from the sandbox can be simplified in several ways:

Drop all the styling
Can create the store normally, and have the middleware listen for some kind of a "SET_COMPONENT_CALLBACK" action that grabs the component method out of the action and saves it in the middleware closure (vaguely similar to the sample Redux timer middleware I once wrote), rather than trying to create the store inside a parent component
I don't think the list part is needed - just have one child component that receives a prop from the parent's state, and have the component method setState({field : someOtherValue}) to cause the wrapper props to change
Don't even need payloads in the actions or an object in the state (just a counter value)

Basically, see just how minimal we can make the repro code, and turn it into a test.

@markerikson Can't promise anything but will try to give it a shot tomorrow.

@markerikson
there is no side effect, because even if the current render is discarded by CM, the "next" effective useEffect where lastWrapperProps.current is used will always be executed after the LAST effective COMMITTED render, where we have RE-UPDATED lastWrapperProps.current.
The Problem : I need the latest possible own props:
The Solution: the latest COMMITTED own props are the one of last render, so it is safe to "save ref" on render

@salvoravida : that's the point.  A render isn't "committed" until the commit phase logic like useLayoutEffect executes.   In Concurrent Mode, they won't, and the render results can be thrown away.  If a Redux action is dispatched in that gap between when the first render is executed and the render pass is finalized, the subscription callback would potentially be reading from the wrong wrapper props value.

@markerikson yes, you are right, but in that case (action dispatched in the middle) the final render, will override and correct the old ownprops, because
 const actualChildProps = usePureOnlyMemo(
        () => {
          if (
            childPropsFromStoreUpdate.current &&
            wrapperProps === lastWrapperProps.current
          ) {
            return childPropsFromStoreUpdate.current
          }

          // TODO We're reading the store directly in render() here. Bad idea?
          return childPropsSelector(store.getState(), wrapperProps)
        },
        [store, previousStateUpdateResult, wrapperProps]
      )

wrapperProps === lastWrapperProps.current  fails and
childPropsSelector(store.getState(), wrapperProps)
is updated correctly.

I've been following this issue (and anything react-redux/hooks related) for a couple of days and it's been a fascinating discussion. I'd like to throw in my two cents as well.
@markerikson To make the code compatible with concurrent mode we should only access the store state in the update callback and then use the state captured there when the component is re-rendered. I see you are already capturing the new store state in previousStateUpdateResult.latestStoreState. Why not make use of this captured state in the computation for actualChildProps? Basically, if the render was triggered by a change to wrapper props we want the component to render based on the latest state that was available when the render started. By taking the state from previousStateUpdateResult instead of always accessing the latest store value concurrent mode should take care of ensuring the component sees a consistent result.
The required code change would just be this:
return childPropsSelector(
  (previousStateUpdateResult &&
    previousStateUpdateResult.latestStoreState) ||
    store.getState(),
  wrapperProps
)

This change passes all existing tests. This code can of course be made a bit simpler by capturing the store.getState() in the initStateUpdates of useReducer.
I will try to work on some tests as well that show these concurrency issues and that will hopefully also show my suggested change solves those issues.

Oh, and to solve the timing issue with lastWrapperProps I don't see why you couldn't just also capture the lastWrapperProps.current used inside checkForUpdates in the reducer and compare that inside the actualChildProps computation? That ensures the childPropsFromStoreUpdate have been computed with the same lastWrapperProps. So these code changes should fix it:
// inside actualChildProps computation
if (
  childPropsFromStoreUpdate.current &&
  wrapperProps === lastWrapperProps.current &&
  (!previousStateUpdateResult ||
    wrapperProps === previousStateUpdateResult.lastWrapperProps)
) {
  return childPropsFromStoreUpdate.current
}

// inside checkForUpdates
forceComponentUpdateDispatch({
  type: 'STORE_UPDATED',
  payload: {
    latestStoreState,
    lastWrapperProps: lastWrapperProps.current,
    error
  }
})

Again, these code changes pass all existing tests. Now I will start working on new tests to show those issues.

Sorry for the spam, but I feel creating separate posts is better than editing existing ones.
@markerikson There is a very simple test that showcases the issue @lecstor mentioned. The test doesn't need middlewares etc. at all. The following test fails currently but is fixed by using either useLayoutEffect or my suggested change with putting the lastWrapperProps onto the previousStateUpdateResult. The test is written so that we expect three renders of the InnerComponent with props being { count: 0, reduxCount: 1 } => { count: 1, reduxCount: 1 } => { count: 1, reduxCount: 2 }, but currently the last render get { count: 0, reduxCount: 2 }.
it('should invoke mapState always with latest props', () => {
  const store = createStore((state = 0) => state + 1)

  let propsPassedIn

  @connect((reduxCount, props) => {
    props
    return { reduxCount }
  })
  class InnerComponent extends Component {
    render() {
      propsPassedIn = this.props
      return <Passthrough {...this.props} />
    }
  }

  class OuterComponent extends Component {
    constructor() {
      super()
      this.state = { count: 0 }
    }

    render() {
      return <InnerComponent {...this.state} />
    }
  }

  let outerComponent
  rtl.render(
    <ProviderMock store={store}>
      <OuterComponent ref={c => (outerComponent = c)} />
    </ProviderMock>
  )

  outerComponent.setState(({ count }) => ({ count: count + 1 }))
  store.dispatch({ type: '' })

  expect(propsPassedIn.count).toEqual(1)
  expect(propsPassedIn.reduxCount).toEqual(2)
})

@MrWolfZ : hmm.  I pasted that test into connect.spec.js, but I'm only seeing two renders atm: [ { count: 0, reduxCount: 1 }, { count: 1, reduxCount: 2 } ].  So, it's actually passing for me right now, without having made any code changes to fix this issue.

I had the same experience with that test and with my attempt at the middleware test.
it('should use the latest props when updated between actions', () => {
  const store = applyMiddleware(store => {
    let callback
    return next => action => {
      if (action.type === 'SET_COMPONENT_CALLBACK') {
        callback = action.payload
      }
      if (callback && action.type === 'INC1') {
        next(action)
        callback()
        store.dispatch({ type: 'INC2' })
        return
      }
      next(action)
    }
  })(createStore)((state = 0, action) => {
    if (action.type === 'INC1') {
      return state + 1
    } else if (action.type === 'INC2') {
      return state + 2
    }
    return state
  })
  const Child = connect(count => ({ count }))(function(props) {
    return (
      <div
        data-testid="child"
        data-prop={props.prop}
        data-count={props.count}
      />
    )
  })
  class Parent extends Component {
    constructor() {
      super()
      this.state = {
        prop: 'a'
      }
      this.inc1 = () => store.dispatch({ type: 'INC1' })
      store.dispatch({
        type: 'SET_COMPONENT_CALLBACK',
        payload: () => this.setState({ prop: 'b' })
      })
    }

    render() {
      return (
        <React.Fragment>
          <div data-testid="click" onClick={this.inc1} />
          <ProviderMock store={store}>
            <Child prop={this.state.prop} />
          </ProviderMock>
        </React.Fragment>
      )
    }
  }
  const rendered = rtl.render(<Parent />)
  expect(rendered.getByTestId('child').dataset.count).toEqual('0')
  expect(rendered.getByTestId('child').dataset.prop).toEqual('a')
  rtl.fireEvent.click(rendered.getByTestId('click'))
  expect(rendered.getByTestId('child').dataset.count).toEqual('3')
  expect(rendered.getByTestId('child').dataset.prop).toEqual('b')
})

If you see anything I didn't catch from the codesandbox, please repurpose.

@MrWolfZ , @maxkostow :
Huh.  So, I thought about this a bit, and I think the issue may actually be with the use of React's new act() test API (via rtl.act()).
act() is implemented as:
  act(callback: () => void) {
    ReactDOM.unstable_batchedUpdates(callback);
    ReactDOM.render(actElement, actContainerElement);
  },

Note that it actually tries to batch updates itself.
If I comment out the rtl.act() portion of @MrWolfZ 's test, and just run the setState + dispatch back to back, I actually see the results we were hoping to see in terms of renders, and the test fails:
    [ { count: 0, reduxCount: 1 },
      { count: 1, reduxCount: 1 },
      { count: 0, reduxCount: 2 } ]

If I then change connect to call useLayoutEffect(), the test actually passes, with these renders:
    [ { count: 0, reduxCount: 1 },
      { count: 1, reduxCount: 1 },
      { count: 1, reduxCount: 2 } ]

So, that test may actually be useful - we just have to not allow React to completely batch things here somehow.
In fact, when I run the test without act() around that setState() call, I then see React flushing the pending useEffect() when the subsequent dispatch queues a state update, in the same way that the original sandbox from @alexreardon did.  So, I think the test now serves its intended purpose.

@markerikson yes, you are absolutely right, I apologize. I actually added that rtl.act directly with an edit here in my post (because I thought that's always the correct way of doing state updates in tests), but I didn't check the effect that change had on the code.
Talking about batched updates, I'd like to make a somewhat controversial suggestions (one that didn't let me sleep properly last night since I couldn't get the idea out of my head :) ). I believe the tiered subscriptions should not be required to deal with the zombie child problems as long as store subscription callbacks are called inside unstable_batchedUpdates. However, this belief is based on my very limited understanding of how react works. I have only really been looking into react for about a week, so generally it's safe to assume I have no idea what I am talking about, but maybe my guesses turn out to be right. Also, this is going to be rather long, so please bear with me.
So, why do I believe tiered subscriptions are not required? Let's take this scenario of a connected outer component rendering a connected inner component while passing props that depend on the state (in connect.js). In this example the desired render order (see the console log output with connected prefix for the actual render order) would be

outer render
inner render
outer render
inner render

With v4.4.10 (the last version to exhibit the zombie child problem; switch the imports at the top of connect.js to see this in the sandbox) the render order is this

outer render
inner render
inner render <--- this is the zombie child case where the inner component is rendered with the new store state but old props
outer render
inner render

With v5+ the correct render order is always observed.
In the sandbox, there is a second example called manual-sub.js. This example uses a very naive and dirty way to directly subscribe to the store with useEffect instead of using connect. If we only do this, then we get indeed the zombie child problem, since even with useEffect the inner component's effects are triggered first and therefore it's subscription callback is invoked first which in turn causes an immediate re-render of the child due to the call to setLatestState (again, you can see this in the console log output with the manual sub prefix). However, if we wrap the store in a proxy that invokes store subscription callbacks inside unstable_batchedUpdates then we get the desired render order (change useProxy to true inside ManualSubApp.render to see this in action).
As I mentioned this example is absolutely basic and I am sure it is missing lots of edge cases. However, as you can see we can get the correct render order without tiered subscriptions. The huge advantage of this is when it comes to hooks. The use of tiered subscriptions currently forces connectAdvanced to be a HOC since you need to wrap the rendered child in a new provider to propagate the tiered subscription. If we get rid of that there is no reason why the logic inside connectAdvanced (minus all the wrapperProps stuff etc) couldn't also be used in a useRedux hook.
There is one last thing to mention: even with the batched updates, the subscription callbacks are still called in the order 1. inner, 2. outer. This has some implications, since currently connectAdvanced is applying the mapStateToProps inside of checkForUpdates and then tries to re-use that result during render. That checkForUpdates call is using the stale props. However, due to the staleness check inside the actualChildProps computation, when the component gets rendered, it will invoke mapStateToProps again. I propose to change this behaviour to only use the result of mapStateToProps inside checkForUpdates as a heuristic to determine whether the component needs to be re-rendered and then always compute mapStateToProps during the render (using the state that was captured during checkForUpdates, i.e. previousStateUpdateResult.latestStoreState). The only downside of this is the performance hit of calling mapStateToProps always twice for each component on a (relevant) store update. The upsides are that a) this should make us compatible with concurrent mode, and b) this will allow for a hooks implementation that doesn't need to know about the props of the component using the hook without suffering from a stale hooks problem (which for example react-redux-hooks currently does suffer from). Basically, I think with this approach we are mixing the approach of v6 (propagating a store update always top-down through renders) with the performance of efficiently updating only relevant components without needing to visit the whole component tree on each store update.
So, to wrap up, I have no idea whether all of my thoughts are even remotely correct, or whether I am just missing something, but this seems like a reasonable approach to me. Of course this would require massive changes (and will break lots of tests that check for mapStateToProps call counts and I'm sure also other tests I can't even think of right now). Still, I think I will try implementing this on the weekend anyways. Please let me know your thoughts about all of this.

@mrwolfz: yikes, Wall O' Text. (that's my job :))
Brief answer now off the top of my head, and I'll reread later and respond in more depth if needed :
The tiered updates are about ensuring subscription callbacks run with the right updated props from a parent, rather than just "render" order.

@markerikson yes, I am aware. See the second to last paragraph of my post of why I think it still works. Although reading through that now, I think I may have to write another post with more details on why I think my suggestion works.

I think we should focus on coming up with crazy edge-case tests to put the suggestions up to the task. That's the only way to know for sure.

@MrWolfZ , @saboya : so the original genesis of the "stale props in the subscription callback" thing was issues like #86 , #99, #292 , etc.  Specifically, we were seeing cases where:

Connected children subscribe before their parents because of cDM firing bottom-to-top
A child mapState function specifically tries to look up an item from the store by ID or similar, and then read values from the item to return as props
An action is dispatched that results in that item being removed
The child mapState runs first and tries to read the now non-existent value from the store, thus throwing an error.  The parent would have re-rendered without that child had it gone first, and thus the child's mapState would never have executed.

I was trying to throw together a codesandbox using RRv4 that would demonstrate that crash error, but it's actually working "correctly" without an error, which is surprising.
Some of our existing tests were probably added in response to issues like this, but I'm not sure which ones off the top of my head.

@markerikson while working on some example code to back my case for using batched updates, I just noticed that using previousStateUpdateResult.latestStoreState as I suggested does not work. The reason is that latestStoreState is only ever updated when the result of mapStateToProps changes in the store subscription. That means if a state update occurs which doesn't change the result of the mapStateToProps call and then a props change happens, a stale latestStoreState would be used. However, since that change passes all existing tests, that indicates a missing test. I'll put writing that test on my TODO list.
Another thing I noticed while working on the example is that we may have another timing issue. Using useEffect for subscribing to the store could lead to missed updates when a store update occurs between the initial render of the component and the execution of the effect. Using useLayoutEffect would fix this, with all the downsides that causes during SSR.

@MrWolfZ : the "dispatch between mount and subscription" part should be handled already:
        // Pull data from the store after first render in case the store has
        // changed since we began.

        subscription.onStateChange = checkForUpdates
        subscription.trySubscribe()

        checkForUpdates()

:fire::fire::fire:React-Redux v7 beta is out! :fire::fire::fire: We've just published our first beta of React-Redux version 7, and it should be the fastest version of React-Redux yet! Please try it out in your production apps, and let us know how well it works for you!
https://github.com/reduxjs/react-redux/releases/tag/v7.0.0-beta.0
We've rewritten connect to use hooks internally, switched back to using direct store subscriptions in components, and we're now using React's "batched updates" API to reduce re-renders. v7 is API-compatible with v6 - the major bump is primarily because we require React 16.8.
We've also added a new batch() API you can import and call in your own code to minimize re-renders with multiple dispatches. connect and batch should work correctly in ReactDOM and React Native, and there's a new alternate entry point to use with alternate React renderers.
We've tested and benchmarked, and are confident this beta is ready for you to try out in your own apps. We've got a lot of users who do things we don't know about, so if you do find an issue, please let us know here:
https://github.com/reduxjs/react-redux/pull/1209

I have tested it with react-beautiful-dnd@hooks and I can confirm that the timing issue is gone. And the performance is lit.
👏

So with that blurbage out of the way, lemme document what all I did this evening.
Timing Issue Fix
I wound up resolving the update timing issue we've been talking about by borrowing a trick I saw linked from the "useLayoutEffect causes warnings in SSR" issues.  We do a quick check to see if we're running in a browser or not, and if not, fall back to useEffect instead.  Neither runs under SSR, but useEffect doesn't print warnings:
const useIsomorphicLayoutEffect =
  typeof window !== 'undefined' ? useLayoutEffect : useEffect

useIsomorphicLayoutEffect(() => {
	lastWrapperProps.current = wrapperProps
}

@maxkostow filed a PR with the timing tests from the last few comments.  I merged that PR and cleaned those tests up a bit.
Test File Cleanup
Having done that, I finally got fed up with the connect.spec.js file.  We've had a bunch of tests added over time, but many of them were added in random ordering.  I reorganized the entire file using some nested describe()s, like:
describe("Core subscription and prop passing behavior", () => {})

describe("Performance optimizations and bailouts", () => {})

describe("Store subscriptions and nesting", () => {})

describe("Refs", () => {})

describe("Subscription and update timing correctness", () => {})

That at least makes the file easier to navigate overall.
Tests for Edge Cases
I added a couple of tests to verify behavior when errors are thrown in mapState.  A while back, we had reports in #802 that connect would sometimes swallow errors thrown in mapState functions, without rethrowing them.  We never did get a good repro for that.
I noticed I was seeing the same behavior in v7-beta in a particular case.  I took the "child throws an error in mapState when its data was deleted and we aren't doing top-down updates" scenario, turned it into a test, and saw that we never got the error thrown.  In v7's case, at least, that was because we were telling the component to re-render so it could throw the error, but the batched updates caused the parent to re-render the child out of existence before the error was thrown in the child.
Our top-down updates should actually ensure this doesn't happen.  But, just in case, I added a check in the effect's unsubscribe handler to re-throw an error if we wind up unmounting without the error being thrown from render.
I also added a test to verify that we do indeed re-throw errors when they occur in mapState when the component isn't being unmounted.
Finally, I added a test to verify that we do not cause warnings to be logged in SSR environments.  (Thanks to @ephem for adding those SSR tests in the first place!)
Publishing
Aaaand finally, I went ahead and published<EMAIL_ADDRESS> Note that there's no @acemarke/ scoped prefix this time - this is the real deal!

We've also added a new batch() API you can import and call in your own code to minimize re-renders with multiple dispatches.
just have to say, this is really cool.
From the example I saw previously I'm assuming that the individual actions will be dispatched and show in devtools as individual actions, but the update will only occur once? This should be flagged as a major feature as it's a better solution than any other batched actions solutions for reducing renders afaik.

@lecstor : that's the idea, yeah.
Y'know, that's a good point.  I'll be honest... I added the export... and I haven't even tested that it works!  :)
Welp, it's a beta. Plenty of time to add more tests.

I just posted a sample benchmarks run and explanation of the results over in the PR, if anyone's interested.

Awesome work, and your timing couldn't be better! Now, the one thing I lost track of a bit in earlier discussions and experiments in other issues: does this v7 beta include any public hooks?

@kbrandwijk : no.  v7 is built using hooks internally, but no public hooks API yet.  Given that shipping a final version of 7.0 is a prerequisite for that, we haven't even begun to seriously think through that question ourselves.
The current public discussion on this topic is in #1179 .

@markerikson this issue made it sound like you were dropping Context API completely in favor of direct subscriptions, but the source code in v7 beta still uses Context API. Can you reword the v7 beta README to be more clear about the actual implementation differences between v6 and v7?

@jeremygottfried : the difference is that we no longer use the context API to propagate state updates.  React-Redux has always used context to make the store instance itself available to nested connected components, regardless of whether it's the legacy context API or the new context API.

v5: legacy context, direct subscriptions for updates
v6: new context, store state updates via context instead of subscriptions
v7: new context, back to direct subscriptions

If you want the nitty-gritty details on how and why things changed, I'd suggest reading this thread top-to-bottom.
I'll also eventually update my post The History and Implementation of React-Redux, which currently covers up through v6-beta, to cover the v7 implementation once v7 goes final

This is looking really good. I didn't have time to dig into it, but I'm pretty sure I was also hit by the bug that @alexreardon reported. Not anymore it seems.
We have a fairly large app written entirely with React and Redux (ported gradually from Backbone), with about 180 connected components. In addition we have redux-thunk, redux-saga, and reselect (in addition to a lot of other deps of course...). Fairly typical React and Redux setup probably. A lot of complex flows that are a lot easier to maintain with React and Redux compared to the old Backbone app.
We have about 500 Nightwatch.js tests to test all the functionality of the app, in addition to about 2800 Jasmine tests.
With previous alphas I was seeing some failures, with v7 beta all is green.
And the performance looks great too :)
Great stuff!
Thanks

@einarq : hah, I totally understand that kind of an app setup :)  We've got one that's still about 70% Backbone and 30% React+Redux.  Hoping to finally get to rewrite the rest of that one in the not-too-distant future.

Hang in there, you’ll get there in the end :)

@markerikson I have created a PR that adds a test for the issue with my suggested change I mentioned above.
Also, regarding the use of batching to replace the tiered subscriptions, I have to point out one thing. My whole suggestion depends on the assumption that mapStateToProps should be a pure/side-effect free function. However, I have looked at the official documentation and nowhere does it state that mapStateToProps must be pure. So, if this is not the case, then my argumentation is moot.
If mapStateToProps is indeed required to be pure, then I believe what you are trying to achieve (and what your tests check for) - namely that mapStateToProps is never called with an inconsistent combination of ownProps and store state - is not what needs to be ensured. Instead, the correct invariant to keep should be that a render is never executed with the result of a mapStateToProps call with an inconsistent combination of ownProps and store state.
So my question is this: is mapStateToProps intended to be a pure function?

@MrWolfZ : yes, mapState should always be pure, the same way reducers and other selectors should be pure.  We can't catch and enforce that they're pure, but they should be.  (If we don't explicitly say that in the docs, we ought to.)
The early issues that I linked around stale props included cases where mapState functions were trying to read values from the store that no longer existed, because the data had been removed.  Based on that store state, the component should have been un-rendered already, but the bottom-up firing of subscriptions was breaking that assumption.
I suppose you can argue that users should write more defensive mapState functions to avoid throwing errors, but our goal has always been that mapState would be called with consistent props and store state.

@markerikson In that case I think my suggestion with batched updates would still work, but would require some changes to the current error handling and the way mapState is called. As you mentioned in this comment, using batched updates does not prevent stale props from being passed to mapState. I argue that this does not matter if we change the error handling as follows.
Currently, errors thrown during the execution of mapState in the subscription callback get caught and re-thrown during render. However, this re-throwing should not be required, since during render mapState will be executed again, and due to it being a pure function, if it is called with the same parameters that caused the error, it will throw again, just as if we had thrown the error ourselves. If the parameters changed however (e.g. because props have been updated to be consistent with the state) then it won't throw. Also, in case the component got unmounted, the render won't be called at all, so no issue there. So in your scenario it would work like this:

a store update occurs that removes the last list item
the subscription callback for the last list item will be executed and the call to mapState will fail, due to the inconsistent state and props, but since the error is caught nothing happens
the subscription callback of the parent is executed
all render changes are applied together due to batching and the child never gets rendered due to the parent rendering first and the list item being removed

It would also work for cases where the element is still in the component tree. However, this change would require to always call mapState during render, since the result from the subscription callback might have been created with inconsistent props and state.
In summary, this way we may be able to make use of batched updates, but even if it works (and I am sure I have missed and edge case or two) it would come at the cost of performance due to having to call mapState always during render (although you are already memoizing it, so it shouldn't be that bad). Still, I think the current implementation works just fine, so no reason to change it. However, when it comes to hooks it may be worthwhile to revisit this idea, since it obviates the need for a HOC.
PS: While evaluating this idea, I found an issue with the way mapState calls are memoized. I created a separate issue for this.

@MrWolfZ : I do appreciate you spending a bunch of time digging into this and discussing ideas.  However, at this point, I'm not seeing a pressing need to go making drastic changes to what appears to be a working v7 beta implementation.
If you feel that a different approach would work better, I'd encourage you to take the time to implement it and file a PR for discussion.  The key criteria are:

Must either pass all existing tests either as-is, or have specific justification for why a test was changed based on the implementation differences before and after (ie, number of mapState calls used as an expectation)
Must be at least as fast as v5 in our benchmarks suite

The release of v7.0 isn't a once-and-done thing for the development of that line.  Obviously we hope to release a 7.x later with a hooks API.  If there's alterations to the implementation that improve things, we can certainly incorporate those and release a minor version.
Also, batched updates definitely exist in RN's renderer - we're importing that method when built in an RN environment.
So, not trying to cut off this discussion completely, but at this point my view is that v7 is basically code-complete except for whatever bugfixes come up.  If you or anyone else can show that there's distinct improvements we can make before release, I'm entirely open to evaluating those, but I don't want to burn time on hypotheticals right now.  Show me code :)

@markerikson Yeah, as I wrote in my post, I don't think anything should be changed for v7.0 since it works just fine. I was thinking more about the future, especially when it comes to hooks. It seems you want to keep this issue about v7.0, so I guess I'll better take my thoughts (and soon hopefully some code) to the appropriate issue then.

@markerikson thank you for the previous response, as that cleared up a lot for me! Looking at the new batch update API, I am curious why you expose that directly? It seems like update notifications are batched by default in the provider, so what are some possible use cases for using the unstable_batchedUpdates directly when I dispatch actions?
Your readme shows this as an example:   ```
batch(() => {
dispatch(increment());
dispatch(increment());
})

But it seems like that example is already being handled when the Provider calls its `notifySubscribers` method. Am I wrong about that?

What I understand is that when you wrap two dispatches with a batch, it will only update the state once, as far as subscribers go.

@saboya I think I understand now. If you have multiple promises resolving close to each other, you can use batch so that duplicate dispatches only result in a single render. This is different use case from  connect and provider, where batch is preventing unnecessary renders within nested subscriptions.

React's unstable_batchedUpdate() API allows any React updates in an event loop tick to be batched together into a single render pass.

Is there anything left outstanding for v7? I have been using the beta in react-beautiful-dnd for a few days and I have not found any issues

In v6, every Redux state update immediately causes a setState() in  at the root of the tree, and React always has to walk through the component tree to find any connected components that may be interested in the new state. This means that v6 ultimately results in more work being done for each Redux store update. For usage scenarios with frequent Redux store updates, this could result in potential slowdowns.

@markerikson Have you thought about do something which is similar to the ConnectComponent? This can aviod going each connected component.
import React, {
  memo,
  useCallback,
  useContext,
  useEffect,
  useRef,
  useState
} from "react";

const StoreContext = React.createContext({}, () => 0), // avoid going thought each connected components and let subscribe to handle when to re-render
  ConnectComponent = memo(props => {
    const [state, setState] = useState(null),
      { subscribe, unsubscribe } = useContext(StoreContext);

    useEffect(
      () => {
        subscribe(props, setState); // this passes the setState to subscribe to deteremine when to re-render
        return () => {
          unsubscribe(props, setState);
        };
      },
      [props]
    );

    return React.Children.map(props.children, child =>
      React.cloneElement(child, { ...props, ...state })
    );
  }),
  useStore = (initialState = {}, keyFunc, actionFunc) => { // Assume this is a key value pair store
    const store = useRef(new Map(Object.entries(initialState))),
      listenersRef = useRef(new Map()),
      subscribe = useCallback((props, setState) => {
        const key = keyFunc(props);

        if (store.current.has(key)) {
          setState(store.current.get(key));
          return;
        }

        const isResolving = !listenersRef.current.has(key);

        listenersRef.current = new Map(listenersRef.current);
        const listeners = new Set(listenersRef.current.get(key));
        listeners.add(setState);
        listenersRef.current.set(key, listeners);

        if (!isResolving) {
          let promise = actionFunc(props);

          if (!(promise instanceof Promise)) {
            promise = Promise.resolve(promise);
          }

          promise.then(state => {
            store.current = new Map(store.current);
            store.current.set(key, state);
            listenersRef.current.get(key).forEach(setState => setState(state));
            listenersRef.current = new Map(listenersRef.current);
            listenersRef.current.delete(key);
          });
        }
      }, []),
      unsubscribe = useCallback((props, setState) => {
        const key = keyFunc(props);
        let listeners = listenersRef.current.get(key);
        if (listeners) {
          listenersRef.current = new Map(listenersRef.current);
          listeners = new Set(listenersRef.current.get(key));
          listeners.delete(setState);
          if (listeners.size === 0) {
            listenersRef.current.delete(key);
          } else {
            listenersRef.current.set(key, listeners);
          }
        }
      }, []);

    return [subscribe, unsubscribe];
  },
  StoreContextProvider = props => {
    const [subscribe, unsubscribe] = useStore(
      props.configs,
      (props) => props.id,
      (props) => fetch(props.url).then((res) => res.json())
    ); // eslint-disable-line react/prop-types

    return (
      <StoreContext.Provider value={{ subscribe, unsubscribe }}>
        {props.children}
      </StoreContext.Provider>
    );
  };

@wood1986 Can you explain this line:
const StoreContext = React.createContext({}, () => 0);

I can't seem to find any mention of the the createContext method taking a second parameter in React's docs.

It's intentionally undocumented / unstable, but implementation-wise, always returning 0 there means that no context updates ever directly propagate to any consumer.

@IsenrichO : yeah, it's undocumented.  See my writeup here:
#1018: Investigate use of context + observedBits for performance

Noted. Thank you all for the info!

but you can't specify observedBits on useContext for example.

@Jessidhia Do you mean you can't specify observedBits in the second argument of useContext? I specify it.
https://github.com/dai-shi/react-hooks-global-state/blob/1edf110120b7c3019db51989bf72ef3891f9d23d/src/index.js#L77
(this one does a tricky thing to hide warning, though. It was originally like this.)

@Jessidhia @dai-shi I tested observedBits did work in Hooks. Otherwise, I won't suggest this.

I see that it's now forwarded to readContext; it was broken at some point (with a warning, even) during the 16.8 cycle, likely pre-release.

@markerikson I tested the latest beta in react-boilerplate and several work projects. No issues to report!

Folks, it's time to finally bring this issue to a close.
Because I've just published React-Redux v7 final!!!!!
Go install it :)
Nice to know that this is done and there's no other long, contentious, complex API design threads to figure out after this.
oh waitaminute


Move social media from gist to README

work in progress

After the commit Moving Contribution guidelines and Contributors list to README.md I guess we have the position to add the gist into readme; but it should have a non-technical counterpart too, this one has some technical aspects, not much tho; so much confusion..

Yeah, create a PR for the contrib. The gist can be done in another branch.

Yeah, create a PR for the contrib. The gist can be done in another branch.

Ig everything looks fine now and is in track.

@proffapt please checkout branch feature-social-media for a starting point

@proffapt please checkout branch feature-social-media for a starting point

that's exactly what I was doing right now

Cool


CHDO	Change Document Object

Now looking into it. Another ancient object not supported over SE80 / Workbench tools.

Have completed CHDO and will prepare a PR within the week.
When deserializing the CHDO object, includes and function group are generated if not existing in target system - as per transport behaviour.
When deserializing the CHDO object when includes and function group already exist in target system then no regeneration occurs - as per transport behaviour.

Just an update - should be ready for a PR in the next week.

done in https://github.com/abapGit/abapGit/pull/3207 closing


Compile data report from second field test

@JSegrave-IBM, we need to compile a report from the first and second field test for the firefighters. Can you please help create pdfs like you did with the data from last year?
I assume that we first use the batch job first to upload data to the database?
FYI @krook @mrodrise : pls add details.

[ ] Need to upload field test data from all devices used
[ ] Need to combine that with database data
[ ] Need to back it all up!
[ ] Need to generate reports on this data, similar to what John did last year with last Feb's data
[ ] Need to see how we can make this data accessible in the dashboard for this and other events
[ ] Need to confirm it's consistent with what's shown in the dashboard


[SPARK-21040][CORE][FOLLOW-UP] Only calculate executorKillTime when speculation is enabled

What changes were proposed in this pull request?

Only calculate executorKillTime in TaskSetManager.executorDecommission() when speculation is enabled.
Why are the changes needed?

Avoid unnecessary operations to save time/memory.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Pass existed tests.

Merged build finished. Test PASSed.

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

@prakharjain09 @cloud-fan Please take a look, thanks!

Test build #127563 has started for PR 29464 at commit 45d0dea.

looks reasonable.

@Ngone51 Looks good.

github action passed, merging to master!

thanks all!!

Test build #127563 has finished for PR 29464 at commit 45d0dea.

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

Merged build finished. Test PASSed.

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


release-1.0 new way to track dxvk source releases?

I see that the master branch is no longer tracking dxvk releases.
Is the release-1.0 branch the accepted way to track newer releases?
I am asking with reference to the winetricks dxvk verb.
This currently uses the RELEASE file, to obtain the current release.
Thanks

Hm, yeah, I can see why this is an issue. release-1.0 has diverged from master and only receives cherry-picked bug fixes. master will at some point (soon-ish) turn into 1.1.
Would it be useful if I maintained a latest-release branch that always points to the latest tagged release, and thus always contains an up-to-date RELEASE file? I'd just force-push to it whenever tagging a new one.

KISS! So yeah, a latest-release branch would be cool.
Thanks! :-)

A latest-release branch would work, but I'm not clear on why that couldn't be done in master instead?
I have two concerns with that approach.

you might forget to update the service branch
if there's 1.0, 1.0.1 and 1.1, then you tag 1.0.2, what's the latest? IMO it's 1.1, but it's unclear from your comment which it would be.

Anyway, as long at there's a file we can query in plain text, we can make it work 😀

Release can be done by tagging point release. Then with git it is simple.

@austin987 because having a commit "Release 1.0.2" in the master branch which has nothing to do with Release 1.0.2 is a bit weird, to say the least.
@phush0 What do you mean? Releases are already tagged.

@bobwya Branch is up: https://github.com/doitsujin/dxvk/tree/latest-release

Never mind, my misunderstanding of the problem.

Thanks, that's great!

@doitsujin, I agree. Do you plan to tag 1.0.2 in latest-release, after 1.1.0? That's what I'm trying to understand/avoid.

Saw edit, that works, thanks!

Before anyone complains: I'm not going to update that branch to 1.1, that release turned out to be a failure pretty much immediately.

You can just use the github api to get the latest release:
https://api.github.com/repos/doitsujin/dxvk/releases/latest
It's what I'm doing for the galliumnine verb already. For exactly that reason, there's no need to rely on any commited file, branch or whatever.


Disable docs builds for dependabot

Description
This change disables docs builds for changes related to dependabot (dependency updates).
Closes #101
What kind of change(s) are included?

[x] Documentation (changes docs or other related content)
[x] Bug fix (fixes an issue).
[ ] Enhancement (adds functionality).
[ ] Breaking change (these changes would cause existing functionality to not work as expected).

Checklist
Please ensure that all boxes are checked before indicating that this pull request is ready for review.

[x] I have read and followed the CONTRIBUTING.md guidelines.
[x] I have searched for existing content to ensure this is not a duplicate.
[x] I have performed a self-review of these additions (including spelling, grammar, and related).
[x] These changes pass all pre-commit checks.
[x] I have added comments to my code to help provide understanding
[ ] I have added a test which covers the code changes found within this PR
[x] I have deleted all non-relevant text in this pull request template.

Thanks @jenna-tomkinson, merging this in!


FlutterBeepPlugin.java uses or overrides a deprecated API

I'm excited for this package, but I receive these warnings when using the package for Android.  Is this something we can fix easily?
Note: C:\Users\Joe.DESKTOP-4BRHLNO\AppData\Roaming\Pub\Cache\hosted\pub.dartlang.org\flutter_beep-0.2.0\android\src\main\java\com\gonoter\flutter_beep\FlutterBeepPlugin.java uses or overrides a deprecated API.

I have the same warning...


can't copy/paste within tmux using mouse

Environment
Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.19042.0 Microsoft Windows NT 10.0.19042.0
Windows Terminal Version: 1.3.2651.0
WSL2: Ubuntu 18.04.2 LTS
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
Remote Server Version: Ubuntu 18.04.3 LTS
tmux 2.6

Steps to reproduce
1 - Open Windows Terminal
2 - Open Ubuntu 18.04 WSL terminal
3 - SSH to the remote server
4 - Start or open a tmux session
tmux new -s test
5 - Copy paste using mouse
** Using the Shift key`**

Select some text in the terminal using Shift + mouse left
Paste it using shift + right

** Without shift key **

Select some text in the terminal using mouse left
Paste it using right

Expected behavior
I want to switch the Windows terminal from Cygwin based mintty terminal.
In Cygwin terminal, shift + mouse left click selects and copies text from a tmux session. shift + mouse right pastes. The copied text is in the clipboard, and I can even paste it into any text editor in Windows.
However, I couldn't accomplish to copy/paste behavior on the Windows terminal using shift or without shift.

Actual behavior

shift + mouse left selects texts, but it doesn't seem copy. shift + mouse right can't paste.
mouse left doesn't select and copy text. mouse right doesn't do anything,

I guess there was a configuration issue. I completely removed and installed again. The version was newer but the config was older, and there were some parsing errors due to breaking changes.


Rename azure.worker to azure.functions.worker

For publishing to PyPI.

We cannot move the worker under azure.functions as we are separating the packages, and azure.functions is not a pure namespace.  I suggest renaming the worker to azure._functions.worker instead.


[naver] Add support for multi track videos

C:\rtmp>youtube-dl --verbose http://tvcast.naver.com/v/201958
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', 'http://tvcast.naver.com/v/201958']
[debug] Encodings: locale cp949, fs mbcs, out cp949, pref cp949
[debug] youtube-dl version 2014.09.06
[debug] Python version 2.7.8 - Windows-7-6.1.7601-SP1
[debug] Proxy map: {}
[Naver] 201958: Downloading webpage
ERROR: couldn't extract vid and key; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Traceback (most recent call last):
  File "youtube_dl\YoutubeDL.pyo", line 523, in extract_info
  File "youtube_dl\extractor\common.pyo", line 178, in extract
  File "youtube_dl\extractor\naver.pyo", line 34, in _real_extract
ExtractorError: couldn't extract vid and key; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.

@ubless607 Works fine here:
$ youtube-dl --verbose http://tvcast.naver.com/v/201958
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', 'http://tvcast.naver.com/v/201958']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2018.03.14
[debug] Python version 3.6.5 (CPython) - Linux-4.15.0-32-generic-x86_64-with-Ubuntu-18.04-bionic
[debug] exe versions: ffmpeg 3.4.2-2, ffprobe 3.4.2-2, phantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
[Naver] 201958: Downloading webpage
[Naver] 201958: Downloading JSON metadata
[debug] Default format spec: bestvideo+bestaudio/best
[debug] Invoking downloader on 'http://g-vod-naver.pstatic.net/navertv/global/read/TVCAST_2014_09_04_2/03100423811353EE7DC38918730A17A3B45_muploader_n_720P_1280_2048_192_B.mp4?__gda__=1534742689_3ac4f9068cfdfd66d5f75a2ac41d3d9d'
[download] Destination: [멀티트랙] '믹스앤매치' 티저 영상, 그들만의 시사회-201958.mp4
[download] 100% of 37.15MiB in 00:05

Can you please confirm?


chore: Update to snapbox 0.6

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

3 of 3 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.785%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3563

Relevant Lines:
5335

💛  - Coveralls


Bulk processes for invokeBinding

How to perform bulk operations with invokeBinding?
I have an output binding defined for PostGRES and can invoke an 'exec' to insert a record to the database, but this would be incredibly inefficient for 1000s records per second, presuming a commit is done after each call to invokeBinding. Is there a 'standard' way of passing a batch of data or controlling the commit?
I can do this using the spring-boot postgres library and connection.getCopyAPI().copyIn(sql), but this kind of negates the need for Dapr as I have to manage the database connection, batching data etc.
Is it possible to extend the PostGRES binding to implement this functionality?

@mike-reynolds-savient This would be work to be implemented in components-contrib.
Moving to contrib repo.


Fix the non modular error within Xcode7.1

I don't know why Travis doesn't find the file, maybe because it's not linked with JSQSystemSound, but it works

hey @baoluo - sounds like you have something wrong with your xcode project setup. this change shouldn't make a difference.

Hello @jessesquires,
Thank you for your response, it does't change anything for you, but for those who use Xcode7.1 and Swift it will.
I made this project https://github.com/processone/xmpp-messenger-ios, and some user reported the issue when they upgraded to Xcode 7.1

I am using Xcode 7.1 with Swift and we into heavy internal testing but no one has yet reported any issue on these lines... (yet)

I can assure you that there is people out there including me who have this problem.
As I said, it doesn't change anything for the rest of you, it just solve the issue for us.

I'm using Xcode 7.1. Built and ran the demo project without any issues.

This is the opened issue, it will only show the error from the xmppFramework, but when I fixed these errors, one in JSQMessageViewController popped up. https://github.com/processone/xmpp-messenger-ios/issues/15

@jessesquires, @svtechnology  Many other projects have the same issue, just for an example, please check these issues in Mantle and ParsePlatform projects:
https://github.com/Mantle/Mantle/issues/626
https://github.com/ParsePlatform/ParseFacebookUtils-iOS/issues/2
Non-modular import statements in Objective-C pods in some cases can cause problems for dependent Swift pods.

@abbasmousavi - interesting. I'll look into this more.

i had to do this as well to get my app to build

This PR doesn't compile since you need also add use_frameworks! into Podfile and run pod install using cocoapods 0.39.0. I've created a similar pull request https://github.com/jessesquires/JSQMessagesViewController/pull/1325
See also issue: https://github.com/jessesquires/JSQMessagesViewController/issues/1322

@marco1981 Of course you have to put the use_frameworks! into the Podfile, it's mandatory if you use Pod with Swift files.

More info:
https://github.com/CocoaPods/CocoaPods/issues/4420
https://github.com/CocoaPods/CocoaPods/issues/4056#issuecomment-143187681

• If you get an error stating "Include of non-modular header inside framework module" for a
framework that previously compiled, make sure the "Always Search User Paths"
build setting is set to "No". The default is "Yes" only for legacy reasons. (22784786)

This will have to wait until after the 7.2.1 release.
I've marked it for the 8.0.0 milestone, which is when iOS 7 will be dropped.
iOS 7 does not support frameworks, which is why we can't make this change right now.

fixed by #1649


REST service to get information about Estimated Subsistence Minimum

AS A Product Owner
I WANT TO have information about Estimated Subsistence Minimum
SO THAT I can get information about Estimated Subsistence Minimum
Acceptance Criteria

[ ] When asked Bürokratt will give End User information about Estimated Subsistence Minimum

Previous task: https://github.com/buerokratt/Common-Services/issues/3


update dependencies of packages

If you import arco-lib into a new project, it will fail to run, because 'framer-motion' and 'mobx' are missing. arco-lib depends on these packages indirectly, so users need to add them in project manually. I update packages' dependecies to solve this problem.
#455

still has some issues


BinaryTypeInfo Error

FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. binaryTypeInfo
I receive the following error while running the code:
CREATE TABLE mtkellr2.counties (Area string, Perimeter string, State string, County string, Name string, BoundaryShape binary)
ROW FORMAT SERDE 'com.esri.hadoop.hive.serde.JsonSerde'
STORED AS INPUTFORMAT 'com.esri.json.hadoop.EnclosedJsonInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat';
I am using Hive 0.8.1

The issue here is that your version of Hive has a bug related to binary fields.  The GIS tools only support Hive 0.9 and up.


[management] Add basic json-rpc client

To better support the ecosystem, it makes sense to consolidate
management related components into management. This means we'll need the
ability to at least submit and craft transactions. This right now is
intended to be used for emergency situations, where the admin will craft
the transaction on the fly and then submit it. In the future, this
framework will enable generating and submitting any transaction relevant
to the entities the system supports.
Why not re-use the existing cli / client? For this tool, we really don't
need something so heavy. This is intended to be used in a trusted
environment and quick to use. The other tool has a lot of different
features and would require substantial effort to integrate into this
framework. That would also require two tools for handling this work.
Perhaps one day we can explore a unification, but not now, not now.

@bors-libra r=joshlind

:pushpin: Commit 0566801 has been approved by joshlind

:hourglass: Testing commit 05668012ee99a7cc636ef0bbcd3d8a470754fedf with merge<PHONE_NUMBER>b9b68b6722fc1b3bacd2f4f68b1060...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=joshlind

:pushpin: Commit b1ea219 has been approved by joshlind

:hourglass: Testing commit b1ea219f2a7b9d5be75f65d09c9a213d93bb960c with merge ac010aa00b33f7fe3b478b7b5b75aee3284afcfd...

:hourglass: Testing commit b1ea219f2a7b9d5be75f65d09c9a213d93bb960c with merge f58b2e84a3233eaa0f8843d4992c88e032e98dd1...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: joshlind
Pushing f58b2e84a3233eaa0f8843d4992c88e032e98dd1 to master...

:boom: Test timed out


Fix text selection for correct indices in textTrans

The way that text elements are currently selected leads to the index passed to textTrans always being 0.
This is fixed by changing the selection so that text is [t1, t2, ..], rather than [[t1],[t2],...].

Will take a look at this today or tomorrow, thanks!


Let PMD Maven Plugin output to console

Makes it easier to see what and where the errors are:
https://maven.apache.org/plugins/maven-pmd-plugin/check-mojo.html
Possibly, aggregate results.

It makes sense, I just submitted a PR.


OpenShift deploy fails during "Rebooting cluster to complete installation"

I'm working on building a POC of OpenShift (OCP) on Azure for one of our customer. I ran into multiple issues (#48, 51 & 53) and i bypassed them by following the workarounds suggested and with the help of @dwaiba. Now i run into below issue:
New-AzureRmResourceGroupDeployment : 5:30:59 PM - Resource Microsoft.Resources/deployments 'OpenShiftDeployment' failed with message '{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "DeploymentFailed",
"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.",
"details": [
{
"code": "Conflict",
"message": "{\r\n "status": "Failed",\r\n "error": {\r\n "code": "ResourceDeploymentFailure",\r\n "message": "The resource operation completed with terminal provisioning state 'Failed'.",\r\n "details": [\r\n {\r\n
"code": "VMExtensionProvisioningError",\r\n "message": "VM has reported a failure when processing extension 'deployOpenShift'. Error message: "Enable failed: failed to execute command: command terminated with exit
status=1\n[stdout]\nonf']})\nchanged: [ocpcluster-master-2] => (item={u'key': u'kubeletArguments.cloud-provider', u'value': [u'azure']})\n\nRUNNING HANDLER [restart atomic-openshift-node] ********************************\nchanged: [ocpcluster-master-2]\n\nPLAY
RECAP *********************************************************************\nocpcluster-master-0 : ok=4 changed=2 unreachable=0 failed=0 \nocpcluster-master-1 : ok=4 changed=2 unreachable=0 failed=0 \nocpcluster-master-2 :
ok=4 changed=2 unreachable=0 failed=0 \n\nThu Mar 22 00:27:10 UTC 2018 - Cloud Provider setup of node config on Master Nodes completed successfully\nThu Mar 22 00:27:10 UTC 2018 - Sleep for 60\n\nPLAY [nodes:!masters]
**********************************************************\n\nTASK [make sure /etc/azure exists] *********************************************\nchanged: [ocpcluster-infra-0]\n\nTASK [populate /etc/azure/azure.conf]
******************************************\nchanged: [ocpcluster-infra-0]\n\nTASK [insert the azure disk config into the node] ******************************\nchanged: [ocpcluster-infra-0] => (item={u'key': u'kubeletArguments.cloud-config', u'value':
[u'/etc/azure/azure.conf']})\nchanged: [ocpcluster-infra-0] => (item={u'key': u'kubeletArguments.cloud-provider', u'value': [u'azure']})\n\nRUNNING HANDLER [restart atomic-openshift-node] ********************************\nchanged: [ocpcluster-infra-0]\n\nPLAY
[nodes:!masters] **********************************************************\n\nTASK [make sure /etc/azure exists] *********************************************\nchanged: [ocpcluster-infra-1]\n\nTASK [populate /etc/azure/azure.conf]
******************************************\nchanged: [ocpcluster-infra-1]\n\nTASK [insert the azure disk config into the node] ******************************\nchanged: [ocpcluster-infra-1] => (item={u'key': u'kubeletArguments.cloud-config', u'value':
[u'/etc/azure/azure.conf']})\nchanged: [ocpcluster-infra-1] => (item={u'key': u'kubeletArguments.cloud-provider', u'value': [u'azure']})\n\nRUNNING HANDLER [restart atomic-openshift-node] ********************************\nchanged: [ocpcluster-infra-1]\n\nPLAY
[nodes:!masters] **********************************************************\n\nTASK [make sure /etc/azure exists] *********************************************\nchanged: [ocpcluster-node-0]\n\nTASK [populate /etc/azure/azure.conf]
******************************************\nchanged: [ocpcluster-node-0]\n\nTASK [insert the azure disk config into the node] ******************************\nchanged: [ocpcluster-node-0] => (item={u'key': u'kubeletArguments.cloud-config', u'value':
[u'/etc/azure/azure.conf']})\nchanged: [ocpcluster-node-0] => (item={u'key': u'kubeletArguments.cloud-provider', u'value': [u'azure']})\n\nRUNNING HANDLER [restart atomic-openshift-node] ********************************\nchanged: [ocpcluster-node-0]\n\nPLAY RECAP
*********************************************************************\nocpcluster-infra-0 : ok=4 changed=4 unreachable=0 failed=0 \nocpcluster-infra-1 : ok=4 changed=4 unreachable=0 failed=0 \nocpcluster-node-0 : ok=4
changed=4 unreachable=0 failed=0 \n\nThu Mar 22 00:28:23 UTC 2018 - Cloud Provider setup of node config on App Nodes completed successfully\nThu Mar 22 00:28:23 UTC 2018 - Sleep for 120\n\nPLAY [masters]
*****************************************************************\n\nTASK [set masters as unschedulable] ********************************************\nchanged: [ocpcluster-master-0]\nchanged: [ocpcluster-master-2]\nchanged: [ocpcluster-master-1]\n\nPLAY RECAP
*********************************************************************\nocpcluster-master-0 : ok=1 changed=1 unreachable=0 failed=0 \nocpcluster-master-1 : ok=1 changed=1 unreachable=0 failed=0 \nocpcluster-master-2 : ok=1
changed=1 unreachable=0 failed=0 \n\nThu Mar 22 00:30:25 UTC 2018 - Cloud Provider setup of OpenShift Cluster completed successfully\nThu Mar 22 00:30:25 UTC 2018 - Rebooting cluster to complete installation\n\n[stderr]\n % Total % Received % Xferd
Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n\r 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\r100 6 100 6 0 0 590 0 --:--:--
--:--:-- --:--:-- 666\n[DEPRECATION WARNING]: 'include' for playbook includes. You should use \n'import_playbook' instead. This feature will be removed in version 2.8. \nDeprecation warnings can be disabled by setting deprecation_warnings=False in
\nansible.cfg.\n[DEPRECATION WARNING]: 'include' for playbook includes. You should use \n'import_playbook' instead. This feature will be removed in version 2.8. \nDeprecation warnings can be disabled by setting deprecation_warnings=False in
\nansible.cfg.\n[DEPRECATION WARNING]: The use of 'static' for 'include_role' has been \ndeprecated. Use 'import_role' for static inclusion, or 'include_role' for \ndynamic inclusion. This feature will be removed in a future release. \nDeprecation warnings can be
disabled by setting deprecation_warnings=False in \nansible.cfg.\n[DEPRECATION WARNING]: The use of 'include' for tasks has been deprecated. Use \n'import_tasks' for static inclusions or 'include_tasks' for dynamic inclusions.\n This feature will be removed in a
future release. Deprecation warnings can be \ndisabled by setting deprecation_warnings=False in ansible.cfg.\n[DEPRECATION WARNING]: include is kept for backwards compatibility but usage is\n discouraged. The module documentation details page may explain more about
this\n rationale.. This feature will be removed in a future release. Deprecation \nwarnings can be disabled by setting deprecation_warnings=False in ansible.cfg.\n[DEPRECATION WARNING]: The use of 'static' has been deprecated. Use \n'import_tasks' for static
inclusion, or 'include_tasks' for dynamic inclusion. \nThis feature will be removed in a future release. Deprecation warnings can be \ndisabled by setting deprecation_warnings=False in ansible.cfg.\n [WARNING]: Could not match supplied host pattern, ignoring:
oo_all_hosts\n [WARNING]: Could not match supplied host pattern, ignoring: oo_lb_to_config\n [WARNING]: Could not match supplied host pattern, ignoring: oo_nfs_to_config\n [WARNING]: Consider using yum, dnf or zypper module rather than running rpm\n [WARNING]:
Consider using unarchive module rather than running tar\n [WARNING]: Consider using get_url or uri module rather than running curl\n [WARNING]: Could not match supplied host pattern, ignoring:\noo_containerized_master_nodes\n [WARNING]: Could not match supplied
host pattern, ignoring:\noo_nodes_use_flannel\n [WARNING]: Could not match supplied host pattern, ignoring:\noo_nodes_use_calico\n [WARNING]: Could not match supplied host pattern, ignoring:\noo_nodes_use_contiv\n [WARNING]: Could not match supplied host pattern,
ignoring: oo_nodes_use_kuryr\n [WARNING]: Could not match supplied host pattern, ignoring: oo_nodes_use_nuage\n [WARNING]: Could not match supplied host pattern, ignoring: glusterfs\n [WARNING]: Could not match supplied host pattern, ignoring: glusterfs_registry\n
[WARNING]: Module did not set no_log for stats_password\n [WARNING]: Module did not set no_log for external_host_password\nWarning: Permanently added 'ocpcluster-master-0,<IP_ADDRESS>' (ECDSA) to the list of known hosts.\r\nerror: 'openshift-infra' already has a value
(apiserver), and --overwrite is false\n"."\r\n }\r\n ]\r\n }\r\n}"
}
]
}
]
}
}'
At line:1 char:1
New-AzureRmResourceGroupDeployment -Name OCPDeploy -ResourceGroupName ...

CategoryInfo          : NotSpecified: (:) [New-AzureRmResourceGroupDeployment], Exception
FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.NewAzureResourceGroupDeploymentCmdlet

New-AzureRmResourceGroupDeployment : 5:30:59 PM - At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.
At line:1 char:1
New-AzureRmResourceGroupDeployment -Name OCPDeploy -ResourceGroupName ...

CategoryInfo          : NotSpecified: (:) [New-AzureRmResourceGroupDeployment], Exception
FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.NewAzureResourceGroupDeploymentCmdlet

New-AzureRmResourceGroupDeployment : 5:30:59 PM - Template output evaluation skipped: at least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.
At line:1 char:1
New-AzureRmResourceGroupDeployment -Name OCPDeploy -ResourceGroupName ...

CategoryInfo          : NotSpecified: (:) [New-AzureRmResourceGroupDeployment], Exception
FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.NewAzureResourceGroupDeploymentCmdlet

New-AzureRmResourceGroupDeployment : 5:30:59 PM - Template output evaluation skipped: at least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.
At line:1 char:1
New-AzureRmResourceGroupDeployment -Name OCPDeploy -ResourceGroupName ...

CategoryInfo          : NotSpecified: (:) [New-AzureRmResourceGroupDeployment], Exception
FullyQualifiedErrorId : Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.NewAzureResourceGroupDeploymentCmdlet

Details:
Deployment mode: Powershell
Command: PS C:\WINDOWS\system32> New-AzureRmResourceGroupDeployment -Name OCPDeploy -ResourceGroupName OCPRG -TemplateFile C:\Users\mandava\openshift-container-platform-master\azuredeploy.json -TemplateParameterFile C:\Users\mandava\openshift-container-platform-master\azuredeploy
.parameters.json
Docker version: 1.12.6
OpenShift version: 3.7
Instructions followed from: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/openshift-prerequisites
I did looked into logs in folders "0" and "1" on bastion node and i did not find any more details other than what's in the failure. I did not find anything wrong in deployOpenShift.sh script and i do not see a parameter "--overwrite" to change the value to "true".
Attaching logs from "0" & "1" folders for reference along with the scripts i'm using. Please suggest a solution for this failure. Thank you!

@miosman Can you please help me with this issue?

What I can see from the logs is that the error is in:
error: 'openshift-infra' already has a value (apiserver), and --overwrite is false
which corresponds to the command
runuser -l $SUDOUSER -c  "oc label nodes $MASTER-0 openshift-infra=apiserver"  in deployOpenshift.sh
It seems you are were retrying the deployment after the deployment failed at a later step and that's why the label is already applied. Try removing all the resources are recreating the environment with the fixes applied.

@miosman Ok. Every attempt i make is from scratch. After every failure i delete the RG and start all over again.
However, i have made several changes to my scripts (change docker version from 1.12.6 to 1.13.1, grant permission to SP at subscription level and changing the defaultValue URL path) and the deployment is successful now. So, i think we can close this issue.


Flex Modifiers don't seem to be working

How do I use .row-wrap, .col-bottom, etc? I have tried numerous ways  and they do not seem to work. Also, I don't see the breakpoints working either. I apologize if this is my ignorance, but I was unable to see these things identified in the docs. I hope this helps...
Version info

Milligram:
https://cdnjs.cloudflare.com/ajax/libs/milligram/1.1.0/milligram.css
Other (e.g. normalize.css, node.js, npm, bower, browser, operating system) (if applicable):
NA
Test case

http://codepen.io/jkinley/pen/PGYXvJ
Steps to reproduce

I have tried numerous ways to get  modifiers like .row-wrap .col-top, etc to work and I am lost. I have looked at the Scss and tried several classes and they do not seem to work.
I have reviewed the docs and there are no examples of how to use these advanced modifiers.
Expected behavior

.row-wrap should invoke flexbox to wrap.
.col-bottom should make flex items align to the bottom.
Actual behavior

the classes don't have an effect.

Hi @jkinley-sds
Sorry if this has caused any problems, then less will be available the next version of Milligram with this issue fixed. #88


Add scanning for a single row

Hi, thanks for creating this library, it's very useful!
However, I think it'd be great to add a function (or change behaviour of ScanOne) so we can pass the row type. Right now, when implementing scany, all code that uses QueryRow has to switch to using Query because none of the functions support scanning sql's row, only rows.

Hi. Thanks for opening this issue. Could you please provide an example of what are you trying to achieve?

Sure. Basically, I had this code:
err = n.DB.QueryRow(context.Background(), sql, args...).Scan(
    &news.ID,
    &news.Title,
    &news.Subtitle,
    &news.Content,
    &news.Category,
    &news.Slug,
    &news.PublishedAt,
    &news.CreatedAt,
    &news.UpdatedAt,
)

And I'd like to be able to implement scany for it to look like this:
row := n.DB.QueryRow(context.Background(), sql, args...)
var news entity.News
err = pgxscan.ScanOneRow(&news, row)

But, since all scany's methods require rows, and don't support row, I had to implement it like this:
rows, err := n.DB.Query(context.Background(), sql, args...)
if err != nil {
    return nil, err
}
var news entity.News
err = pgxscan.ScanOne(&news, rows)

Which requires more code and isn't as clear (because we query for multiple rows, but only use one).

You can do it even simpler, using the pgxscan.Get() function:
var news entity.News
err := pgxscan.Get(context.Background(), n.DB, &news, sql, args...)
...

For more detail see docs for the .Get() function.
Scany doesn't work with Row type intentionally, because it doesn't expose enough information to do the mapping.
And generally, there should be no need to pass a Row type to scany, since it provides all helper functions that you would need.
I hope it helps!

I won't be able to use pgxscan.Get() in every situation, but fair enough! Thanks!


fix(Typography): Remove italic from helper-text-01

Closes https://github.com/carbon-design-system/carbon-website/issues/314
Remove "italics" from $helper-text-01 description & example
Changelog
Changed
Typography page, $helper-text-01 description.
Change helper text example to be not italic.

Looks like I was unable to remove the italic in the example. Welp!

Let's wait for the rest of the color PRs to line up and merge together.

I removed the "italic" mention in the spec, but looks like I was unable to remove the italic in the example. Welp!

This is pulling styles directly from the type package. Has it been updated there?

Ah that explains it! Thank you @alisonjoseph . I will make an issue to update the type package.

fix was merged in and will be avail in next Carbon minor release https://github.com/carbon-design-system/carbon/pull/4004

This issue fixes the text description on the website, not the actual token value. Waiting for release date to merge because we don't wanna update the website without releasing the token in prod.