ref-forwarding API

View formatted RFC
Implementation at facebook/react/pull/12346

I really like this approach. Makes a lot of sense for existing applications and should be something fairly simple to build into the compiler to handle too.

Maybe this is out of scope, but could be worth mentioning that this same strategy can be used for all HOCs. For example:
function ThemedButton(props, theme) {
  return <button className={'theme-' + theme} {...props} />
}

export default withTheme(Movie);

where withTheme internally uses a context consumer.

@streamich This is an HOC, except it only works for functional components. The difference is that instead of injecting additional props, it passes additional arguments.
The larger idea behind this proposal is that we could use the same pattern for other APIs, too. Like, say, context:
const ThemeContext = React.createContext('light');

function ThemedButton(props, theme) {
  return <button className={'theme-' + theme} {...props} />;
}

export default ThemeContext.withContext(ThemedButton);

@sebmarkbage suggested we use the use prefix instead of with since some HOCs may add more than one argument:
function Counter(props, count, updateCount) {
  return (
    <>
      Count: {count}
      <button onClick={() => updateCount(c => c + 1)}>+</button>
    </>
  );
}

export default useState(Counter, 0);

Or no arguments at all:
function ComputationallyExpensiveComponent(props) {
  const thing = somethingThatTakesALongTime(props);
  return <Whatever thing={thing} />;
}

const MemoizedComponent = usePure(ComputationallyExpensiveComponent);

Thanks @trueadm!

Maybe this is out of scope, but could be worth mentioning that this same strategy can be used for all HOCs.

Yeah, this was what I was thinking, but maybe didn't make it clear enough. I'll try to make it clearer in the code example.
Sorry, I misread this message initially. I still agree with the sentiment of your comment, but I think mentioning it might be a bit out of scope for this RFC. 😄

@sebmarkbage suggested we use the use prefix instead of with since some HOCs may add more than one argument

@sebmarkbage always has good ideas. 😄I'll update!

How does this handle static class properties?  It would seem to swallow them, if you did something like:
class DataContainer extends Component {
  static fragments = {widget: gql`...`}
}

export default React.useRef((props, ref) => (
  <DataContainer {...props} forwardedRef={ref} />
));

Perhaps the solution / challenge is the same as other higher-order components, in that it would either require buy-in on the original component itself so that it attached static properties to the wrapper or would require a workaround like hoist-non-react-statics.
That said, it would be nice if however this worked did not require knowledge of static properties, especially in the case where you want to wrap a third-party component with useRef without needing to know the full implementation details of the wrapped component.
This very well may be a non-issue.

This would work 100% for styled-components.

That's great to hear, Max!

How does this handle static class properties?

Perhaps the solution / challenge is the same as other higher-order components, in that it would either require buy-in on the original component itself so that it attached static properties to the wrapper

I don't think static properties are a problem here (but please correct me if I'm overlooking something). I think your observation about attaching/forwarding them to the exported ref-type is a reasonable solution.
The key part is that you would be able to do this in a way that's transparent to users of the thing you'r wrapping. (That isn't currently possible, due to refs.)

Perhaps the solution / challenge is the same as other higher-order components, in that it would either require buy-in on the original component itself so that it attached static properties to the wrapper or would require a workaround like hoist-non-react-statics.

I'd be wary of this at the library level. When I write a HOC I actually don't use hoist-non-react-statics, I use hoist-non-react-methods because often when wrapping a component in a HOC not only do statics get shadowed but also instance methods like focus/show/hide and React Native's measure.
So if we create something at the library level that shadows static properties and the library has to workaround it, I'm worried that if no-one remembers to take them into account we'll end up with something baked into the library (where we can't just switch to a different implementation) that handles statics but forgets about instance methods on the prototype.

Thanks for writing this!
I'm having a similar issue where I have some HOCs over an  and need to expose it's focus() method. it's only possible with some custom innerRef prop and a recursive getInnerMostRef helper. But this will work only if my HOCs are in my control and know how to keep track of inner refs.
Not really related, but if there's any API change suggested, could React specific props be more distinct?
e.g.
<Comp $ref={...} $key={...} />
<Comp react-ref={...} react-key={...} />
<Comp react.ref={...} react.key={...} />

this will allow more explicit way to define react props and prevent breaking changes when new react-specific props are added. Also will allow proper spread of objects that may contain ref or key attributes.

@elado XHTML does have a concept of namespaces, could do something like react:key, etc.

Namespaces in JSX have been discussed before: https://github.com/facebook/jsx/issues/81 We would love to have them for styled-components but it doesn't seem like that's happening.

I'd be wary of this at the library level. When I write a HOC I actually don't use hoist-non-react-statics, I use hoist-non-react-methods because often when wrapping a component in a HOC not only do statics get shadowed but also instance methods like focus/show/hide and React Native's measure.

I might be misunderstanding your concern, but this ref-forwarding proposal is specifically intended to help with the shadowing of instance methods like focus/show/hide. If you decorate/wrap a component with those methods, so long as you forward the ref to it, then the owner of the ref can use those methods (e.g. ref.value.focus()).

So if we create something at the library level that shadows static properties and the library has to workaround it

I don't think static properties is a common concern. Maybe I'm wrong. But if this is a case for a given component, there is a workaround (discussed above).
WRT namespaced attributes, that's outside of the scope of this RFC. :smile:

I might be misunderstanding your concern, but this ref-forwarding proposal is specifically intended to help with the shadowing of instance methods like focus/show/hide. If you decorate/wrap a component with those methods, so long as you forward the ref to it, then the owner of the ref can use those methods (e.g. ref.value.focus()).

True, I could just forward the ref to the top-level component. But I am worried that: A) sometimes I want to forward refs for something deep but I still want to offer direct methods on my component for the top level component (Say a <PromptDialog> that forwards a ref to the text input for inputRef.focus() but directly exposes it's own show/hide instead of forwarding a dialogRef to the <Dialog> it happens to use internally). B) Sometimes I may have a good reason to expose an instance method as part of my Component's API, after all here and there even React Native has reasons to do so. And I don't believe forwarding refs help that, but it sounded like they interfere with hoisting if it turns out I need to forward refs for one of my component's children.

sometimes I want to forward refs for something deep but I still want to offer direct methods on my component for the top level component

This comment doesn't make sense to me.
I think the ref should always point to the conceptual "top-level component". So in the case of a Button component that's wrapped by a withTheme HOC, the ref attribute would point to the Button component.
In the case you describe, the top-level component sounds like it would be the PromptDialog, which may look something like this:
class PromptDialog extends React.Component {
  inputRef = React.createRef();

  show() {
    // Show...
  }

  hide() {
    // Hide...
  }

  focus() {
    if (this.inputRef.value != null) {
      this.inputRef.value.focus();
    }
  }

  render() {
    return isShown ? <input ref={this.inputRef} /> : null;
  }
}

External users of your dialog would use it like so:
class Example extends React.Component {
  dialogRef = React.createRef();

  componentDidMount() {
    this.dialogRef.value.show();
    this.dialogRef.value.focus();
  }

  render() {
    return <PromptDialog ref={dialogRef} />;
  }
}

It doesn't make sense for a single ref to point to multiple things. If you want to be able to have multiple refs, you still could:
class PromptDialog extends React.Component {
  show() {
    // Show...
  }

  hide() {
    // Hide...
  }

  render() {
    // Forward props.inputRef so it points to the inner <input>
    return isShown ? <input ref={this.props.inputRef} /> : null;
  }
}

function wrapForSomeReason(Component) {
  function WrapperComponent(props) {
    // (This wrapper intentionally left blank to simplify the example.)
    return <Component {...props} ref={props.forwardedRef} />;
  }

  // Forward top-level `ref` so it points to Component
  return React.useRef((props, ref) => (
    <WrapperComponent {...props} forwardedRef={ref} />
  ));
}

// Top-level `ref` will point to PromptDialog
const WrappedDialog = wrapForSomeReason(PromptDialog);

Sometimes I may have a good reason to expose an instance method as part of my Component's API, after all here and there even React Native has reasons to do so. And I don't believe forwarding refs help that, but it sounded like they interfere with hoisting if it turns out I need to forward refs for one of my component's children.

I don't really understand this comment, which makes me wonder if you're thinking of this proposal as something fundamentally different than I am. (Or maybe I'm just...misunderstanding your comment.) 😄
Do my above examples clarify any? If not, could you write a small example component that illustrates your point? I don't see how this proposal complicates or prevents you from doing what you're describing.

@bvaughn Sorry, I read the RFC but I'll admit I found it hard to understand. Your last example makes sense and fits. I was just going off another comment talking about the interactions with hoisting and I worried because HOC usage is fairly common for me. For wrapForSomeReason I often have a bunch of reason to use some HOC, a theme context providing HOC, an API providing HOC, etc. And some of them are used on something like the PromptDialog that may be a component provided for other components to use and have a reason to have instance methods.

No problem. If you have suggestions for ways I can clarify the RFC wording, let me know.
This RFC is intended to help with the specific case you're describing - so that you can wrap your PromptDialog with as many HOCs as you need to, without users of PromptDialog needing to know or care (because ref would just get passed through to your PromptDialog).

I don't think static properties are a problem here (but please correct me if I'm overlooking something).

This is the case I'm thinking of:
import SomeComponent from 'third-party-library';

// SomeComponent has static properties, but I don't necessarily know
// this because it's a third-party NPM module that's not in my control.

const RefWrappedSomeComponent = React.useRef((props, ref) => (
  <SomeComponent {...props} forwardedRef={ref} />
));

export default RefWrappedSomeComponent;

In that case, I would need to know about the implementation of SomeComponent in order to know whether or not static properties would need to be hoisted, but it would be nice if there was a way to wrap the ref on a component without necessitating static hoisting.
But like I said before, there may not be, given that this is a common concern with HOCs.
The "fix" using this API would be something like this:
import hoistNonReactStatics from 'hoist-non-react-statics';
import SomeComponent from 'third-party-library';

const RefWrappedSomeComponent = React.useRef((props, ref) => (
  <SomeComponent {...props} forwardedRef={ref} />
));

hoistNonReactStatics(RefWrappedSomeComponent, SomeComponent);

export default RefWrappedSomeComponent;

In that case, I would need to know about the implementation of SomeComponent in order to know whether or not static properties would need to be hoisted, but it would be nice if there was a way to wrap the ref on a component without necessitating static hoisting.

That's fair. My thinking about this is that most times, if you're wrapping a component in this way, you fall into one of two categories:

You're working in a library that defines the component (e.g. react-select does this) in which case you know if the component has static methods, or...
You're working in an application that uses the component, in which case you can search to see if you're using any static methods within your codebase.

I don't imagine many ambiguous cases where you import a third party component, wrap it, and re-export it for external use. Although I haven't personally used hoist-non-react-statics before, it seems like it could be a reasonable workaround for that case though.
I don't have any data to back this up, but my anecdotal experience is that instance methods on components far outweigh static methods.

Renamed React.useRef to React.forwardRef

This RFC is now in the final comment period. A version of this will likely be released in an upcoming 16.3 alpha as well.

Hey @bvaughn how could I use this with a Stateful Component?
render() {
  return React.forwardRef((...?) => (
    null
  ))
}

class Button extends React.Component {
  render() {
    // Use this.props.myRef (or whatever you called it)
  }
}

// Export this instead
export default React.forwardRef((props, ref) => (
  <Button {...props} myRef={ref} />
));

I'm not sure I understand that example, @btnwtn.
It doesn't really make sense to create a ref-forwarding component wrapper if you have access to the thing inside of it (which you would have to if you were rendering it).
It's meant to be used when you want to export one type of component for rendering, but let refs pass through to another type- inside of what's rendered.
const ThemeContext = React.createContext("light");

function withTheme(ThemedComponent) {
  function ThemeContextInjector(props) {
    return (
      <ThemeContext.Consumer>
        {value => (
          <ThemedComponent {...props} ref={props.forwardedRef} theme={value} />
        )}
      </ThemeContext.Consumer>
    );
  }

  // Forward refs through to the inner, "themed" component:
  return React.forwardRef((props, ref) => (
    <ThemeContextInjector {...props} forwardedRef={ref} />
  ));
}

// We have a handle on ButtonComponent here,
// We want to export a themed wrapper (so the button is auto-themed).
// But we want users to be able to get a ref to button.
export const ThemedButtonComponent = withTheme(ButtonComponent);

// This ref will point to the inner ButtonComponent,
// Even though we are rendering the "themed" wrapper.
<ThemedButtonComponent ref={buttonRef} />

Or to borrow Dan's example from Twitter:
// Tell React I want to be able to put a ref on LikeButton.
const LikeButton = React.forwardRef((props, ref) => (

    {/* Forward LikeButton's ref to the button inside. */}
    <button ref={ref} onClick={props.onClick}>
      Like
    </button>

));

// I can put a ref on it as if it was a DOM node or a class!
// (In this example, the ref points directly to the DOM node.)
<LikeButton ref={myRef} />;

@bvaughn Minor feedback on the presentation of these examples—I think it requires some additional mental effort to understand how this plays together with context. While this is useful as one practical case we should mention, it's probably easier to explain this feature alone.

I wonder why not do something like the following and support both class and function components:
const Header = props => React.forwardRef(ref => (

{props.message}

));

class Header extends React.Component {
  render() {
    return React.forwardRef(ref => (

{this.props.message}

    ));
  }
}

I'm not clear on the implementation, so I might be mis-interpreting how this works.

This does support both class and functional components 😄
// Functional example...
const Header = ({ children, forwardedRef }) => (
  {children}
);

// Class example...
class Header extends React.Component {
  render() {
    const { children, forwardedRef } = this.props;
    return {children};
  }
}

// You would use either the same way...
const ForwardingHeader = React.forwardRef((props, ref) => (

));

This does support both class and functional components

Yeah, I saw that. Was wondering an alternative approach so you can do this in render directly rather than one extra wrapping.

support both class and function components

The RFC as it is already supports both functional and class components. The thing you pass to forwardRef is not exactly a component. It's more like a render prop. Inside that render prop, you can render either a function or a class component (or any kind of tree really).
The API you propose seems aesthetically nicer to me but I don’t think it works conceptually. By the time you’re in the render method it’s already “too late”. For example consider what happens if you make the return value of render conditional, with one branch returning a plain div. It would be surprising if the component’s ref pointer “jumped” from a forwarded ref to a class instance (when we don’t render a forwardRef return value) depending on that branch at runtime. Especially considering this could happen deep in the tree.

It would be surprising if the component’s ref pointer “jumped” from a forwarded ref to a class instance

I wouldn't really be surprised if it jumps to the class instance when don't return the stuff wrapped in React.forwardRef, assuming you're talking about this:
class Header extends React.Component {
  render() {
    if (this.props.isLoading) {
      return
Loading
;
    }

    return React.forwardRef(ref => (

{props.message}

    ));
  }
}

This seems like the intended behaviour, since for the element I returned, I didn't signal it to forward the ref by wrapping in React.forwardRef.
However, in the following case, I'd expect the ref to become null:
class Header extends React.Component {
  render() {
    return React.forwardRef(ref => {
      if (this.props.isLoading) {
        return
Loading
;
      }

      return
{props.message}
;
    });
  }
}

Same in this case:
const Header = React.forwardRef(props, ref => {
  if (props.isLoading) {
    return
Loading
;
  }

  return
{props.message}
;
});

I wouldn't really be surprised if it jumps to the class instance when don't return the stuff wrapped in React.forwardRef, assuming you're talking about this

It looks nice and tidy if it’s top level return value. What if it’s nested? Maybe even in a chain of helper methods called from render. Then it influencing “own” ref of the component seems quite confusing to me. You also can’t safely “extract” a component that contains this. It would change the meaning. So this violates existing expectations.
If something is only allowed at top level then we should enforce it. That’s what the API does.

In general our constraint (which is partly responsible for React’s success) is that changing what a component returns from render doesn’t change its own API. That’s what allows easy refactorings. There are a few APIs that violate this but they have other issues on their own (findDOMNode). I think we shouldn’t add more APIs that pierce through component abstraction.

super excited about this. I'm going to give it a whirl in some of the react-bootstrap v4 upgrades and see how it feels.

Aren't we widening the gap between functional and class components?
In functional components we can just use ref in our render method, but in class components we don't have this.ref (or this.props.ref).

In functional components we can just use ref in our render method, but in class components we don't have this.ref (or this.props.ref).

You don't have ref in your render method for a functional component either. (Refs can't be attached to functional components.)

Hey everyone, this is really awesome, thank you!
As this features very strongly in focus control to achieve accessibility, I'd like to update the a11y doc to reflect this at the right moment.
Is it prudent to already open a separate PR for that at this stage?

Hi @AlmeroSteyn. Are you talking about this section of the React docs? If so, feel free to submit a PR at any point if you have ideas to improve the docs. 😄

@bvaughn
So this is not a functional component:

    {/* Forward LikeButton's ref to the button inside. */}
    <button ref={ref} onClick={props.onClick}>
      Like
    </button>

));```

But what's a proper name?

Ah. I see.
The like button example isn't a functional component, although it looks similar to one.
forwardRef accepts a render function that returns a react node. It's invoked directly, rather than being wrapped up in a React element. This is why its second parameter is ref (instead of the legacy context).

@rickbeerendonk Perhaps the example in https://github.com/reactjs/rfcs/pull/30#issuecomment-373170677 will mark more sense to you? It shows it works the same way for functional components and classes.

@gaearon I'd read that comment before reacting. A first reaction might be "why do we need this if we can just add a forwardRef prop to our component?". So this feature cannot be explained all by itself, but needs context and requires knowledge of other features.

So this feature cannot be explained all by itself, but needs context and requires knowledge of other features.

Hopefully the "Motivation" section of the RFC provides sufficient context for at least one use case 😄 the comments here are partial examples, assuming shared context of the RFC content.

@bvaughn Not really. If react-relay has a problem, why should React "solve" this?

...requires users of the ThemedComponent to be aware of the fact that it's wrapped by a higher-order component. This detail should not be important.

But in https://github.com/reactjs/rfcs/pull/30#issuecomment-373170677 we end up with 2 "components" Header and ForwardHeader and a different meaning of ref. Maybe it improves backwards compatibility, but future users are required to know the difference between the two.

If react-relay has a problem, why should React "solve" this?

It's not isolated to React Relay, the exact same problem will affect any other library that will want to use the context API and has some imperative hooks. The only reason we mentioned React Relay is we're the ones migrating it so we're first to experience this problem.
This is also not strictly limited to the context API (although that's what tipped the scales). The problem has existed for years for any HOCs and, in general, React DOM component libraries. You can see it solves longstanding pain points for React Bootstrap and Styled Components maintainers. This problem is familiar to other HOC authors (e.g. React Redux) too how currently have to tell users to chain getWrappedInstance() calls any time a component needs to be connected but is already used as a ref.

But in #30 (comment) we end up with 2 "components" Header and ForwardHeader and a different meaning of ref. Maybe it improves backwards compatibility, but future users are required to know the difference between the two.

You’d export just one of them. Just like when you use HOCs, you don’t export all intermediate versions of the component. This is about better encapsulation and exposing less internals (HOCs can be more “transparent”), not exposing more internals.

Okay, the longer I think about this, the more it becomes clear that this should not be taught in a React class. It is clearly a corner case feature, best kept hidden from beginners.

This is a power user feature for library authors. We didn’t say it’s appropriate for beginners. Even the article on refs themselves is outside the “beginner-friendly” Quick Start section in the React docs.

@gaearon
Thank you for the extensive answer.
Did you consider making ref-prop available inside components instead?
Two things to close (no answer needed):

I do teach ref in a beginner course, since students are used to DOM manipulation and I don't want to make them feel like React is just one huge abstraction far away from what they know.
HOC in the React world are hard to avoid. Beginners will be confronted by HOC in the projects they join. In my course I don't do a deep dive into HOC to explain them though.

Did you consider making ref-prop available inside components instead? -- I see now appearing your RFC that you did.

Yeah, that doesn’t really work because it’s an all-or-nothing approach. This RFC doesn’t have that problem.

I do teach ref in a beginner course, since students are used to DOM manipulation and I don't want to make them feel like React is just one huge abstraction far away from what they know.

That sounds good. I still think ref forwarding is an even more advanced topic and primarily is useful to library developers.

HOC in the React world are hard to avoid. Beginners will be confronted by HOC in the projects they join. In my course I don't do a deep dive into HOC to explain them though.

Right, but they’re unlikely to write them before they know React well. Ref forwarding is primarily useful to people writing HOCs. By the point they need to write one, you have to explain the problem with refs anyway, but at least now we’re offering a solution to that problem.

Did you consider making ref-prop available inside components instead?

Assuming you mean props.ref- we did briefly talk about this. The main motivation against it is that it would not work with the very common case of spreading props. (It would be too easy for the same ref to end up being passed to multiple components, unintentionally. That would be a very backwards-breaking change.)

@bvaughn @gaearon
I can see the issues with this.ref.
Component could also overwrite what ref is being returned by introducing a lifecycle method:
function logProps(WrappedComponent) {
  return class extends React.Component {

    // New Lifecycle Method:
    // Allows user to overwrite the ref that is being returned from this component.
    componentReturnsRef(topRef) {
      // Defaulf would be: return topRef
      return this.wrappedRef;
    }

    componentWillReceiveProps(nextProps) {
      console.log('Current props: ', this.props);
      console.log('Next props: ', nextProps);
    }
    render() {
      return <WrappedComponent {...this.props} ref={ref => this.wrappedRef = ref} />;
    }
  }
}

I'm not sure I understand what's being proposed/suggested above, but the proposal in this RFC also works for functional components (which don't have lifecycles- at least not at the moment). 😄

@bvaughn
I was responding to @gaearon's

wrapping a component in a HOC always breaks refs

Seems like it is a problem that ref is not being exposed inside components (or the meganism not being open enough). I was just wondering (playing around to see) if you could expose ref just enough to fix the problem, instead of introducing external constructs to "fix" the limited visibility.

I was just wondering (playing around to see) if you could expose ref just enough to fix the problem, instead of introducing external constructs to "fix" the limited visibility.

The approach you’re suggesting doesn’t work with functional components because they have no lifecycle methods. This limitation is unfortunate because we are considering moving away from class-based APIs in the future. So any APIs we’re adding today shouldn’t ideally be bound to classes unless they only extend class-only features (e.g. this is not a concern for getDerivedStateFromProps because it only makes sense for components with state anyway). Forwarding refs isn’t necessarily tied to classes.
Another problem with adding a lifecycle method is that we have to check each class component for it. We already do quite a bit of checks for lifecycle methods, and they chip away at performance for large updates. We’d like to avoid adding more such checks. For comparison, with the API in this RFC you only “pay” for this feature only when you actually use it.
Finally, I’m not sure I see how the API you proposed would work in practice (it’s a bit hard to think about). How would React know when to call componentReturnsRef and “propagate” the update upwards? You could pass a ref several layers deep and then give it to a leaf that mounts and unmounts independently of its parent (e.g. in response to a deep state change). In your example code, this.wrappedRef = ref assignment wouldn’t be sufficient for React to guess that the outer’s class own ref has changed, and now needs to also be updated. With the API in this RFC, this is not a problem because we are literally injecting the ref “from above” right into the component. So the ref given to the nested child is the same ref provided to the parent, not a wrapper.

Forgive me if this has already been covered — did a quick read-through, and didn't see anything.
I just want to confirm that the ref supplied as the callback argument within React.forwardRef is of the RefObject<T> type returned by React.createRef().
For reference, RefObject<T> has the following signature:
type RefObject<T> = {
  value: T | null
};

In some cases, its necessary for a wrapped component to both forward a ref and access it itself. I'm looking for assurance that the following code would work:
class FancyTextbox extends Component {
  state = {
    value: '',
  };

  // In this contrived method, I'd like to be able to access
  // the same <input> ref that I'm forwarding.
  reset() {
    this.setState({ value: '' }, () => {
      if (this.props.forwardedRef.value) {
        this.props.forwardedRef.value.focus();
      }
    });
  }

  render() {
    return (

        <input
          type="text"
          ref={this.props.forwardedRef}
          value={this.state.value}
          onChange={(value) => this.setState({ value })}
        />

    );
  }
}

export default React.useRef((props, ref) => (
  <FancyTextbox {...props} forwardedRef={ref} />
));

The above example is exceedingly contrived, but the actual usage I have in mind concerns binding native Animated events in React Native, which uses an imperative API that needs to be invoked every time the ref changes. (Such code is best tucked away in a HOC, hence the need for both ref forwarding and internal access.)

I just want to confirm that the ref supplied as the callback argument within React.forwardRef is of the RefObject<T> type returned by React.createRef().

No. The ref argument could also be a callback ref.

Why is setting .current legal? That's not part of the createRef() spec, right?
How resistant would you be to normalizing the type of ref to either a callback ref or RefObject<T>? If this API is borne of a wish to simplify and normalize nested ref handling, it'd be a shame if it ended up trading old boilerplate for new (i.e., trading manual, proprietary ref unwrapping with the code above, which will need to be aware of all possibly-legal ref values, and is thus not future proof).
I feel like this RFC + the createRef() RFC gets us so close to avoiding all this unnecessary ref munging.

Forcing refs to be a RefObject<T> would mean complex use cases that we tell people to use callback refs for would not work with this RFC.
Rather than forcing a single type of ref, if it's important for user code be able to essentially set a ref, we should expose a helper for that instead of restricting to a single type.
i.e. A React.???(ref:RefObject<T>|CallbackRef<T>, T) that would either set the ref object's value or call the callback ref.

I'm perfectly fine with @dantman's approach, too.
I missed the boat on the createRef() RFC, but I think it was an oversight for the RefObject<T> to not contain a setValue method.
Regarding the use cases served by a callback ref, they can still be accomplished via a RefObject<T> (albeit in a convoluted manner) if you work off the assumption that componentDidUpdate will always be invoked after a change in ref.
class Wrapper extends Component {

  lastRef = this.props.wrappedRef.value;

  componentDidUpdate() {
    const { lastRef } = this;
    const { value: nextRef } = this.props.wrappedRef.value;

    if (lastRef !== nextRef) {
      // Do whatever you would've done in your callback ref.
      this.lastRef = nextRef;
    }
  }

  // ...
}

// ref is of type RefObject<T>
export default React.useRef((props, ref) => (
  <Wrapper {...props} forwardedRef={ref} />
));

Why is setting .current legal? That's not part of the createRef() spec, right?

createRef has been updated (in alpha 2) to use .current instead of .value because the team had concerns that cases like inputRef.value.value would be confusing.
The updated example by @jamesreggio does not handle the callback ref case, so it would not work. Setting that aside, using the property initializer case for extracting a createRef ref wouldn't work either, as the ref wouldn't be available until after the component mounted.

I agree it would be nice to have a built-in bulletproof to compose refs (the result would always have to be a functional ref). I don’t feel like it has to be a part of this proposal though. It is also not a fundamentally new capability so perhaps it could live outside of React (I know at least one library that does this although it’ll need to be updated for object refs.) Maybe a separate RFC?

The updated example by @jamesreggio does not handle the callback ref case, so it would not work.

The point of this example was to show how to attain the flexibility of a callback ref if React.forwardRef only  provided instances of RefObject<T>. It hinges upon that assumption.

createRef has been updated (in alpha 2) to use .current instead of .value because the team had concerns that cases like inputRef.value.value would be confusing.

Name change aside, it sounds like you're saying that it's safe and supported to write to the RefObject<T>.current property. 👍

I'm fine punting the normalization concerns to user-space or a separate RFC, but in order to do so, I want to explicitly confirm what has been implicit to this conversation. Specifically:
The ref value supplied by React.forwardRef to the callback is the exact value of ref passed into the outer component returned by React.forwardRef.
This guarantee means that we can assume that the value of ref is one of the known, valid ref formats, and we can behave accordingly (e.g., by invoking callback refs or by updating .current on boxed refs).
(I feel like there may be certain internal implementation conveniences or optimizations that could be leveraged if the ref provided by the forwardRef function were opaque, but those would have to be deferred to a future major release.)

it sounds like you're saying that it's safe and supported to write to the RefObject.current property

Yes. (When you want to manage it manually, such as the case when composing refs.)

The ref value supplied by React.forwardRef to the callback is the exact value of ref passed into the outer component returned by React.forwardRef.

Yes. (Intentionally because always “normalizing” it to some form might be an unnecessary cost in most cases.)

As I think about the use-case you raise, @jamesreggio, I find myself warming up to the idea of a new package that would help compose both ref-types. I'll add it to my list of things to write an RFC for (unless you beat me to it).

Hi @AlmeroSteyn. Are you talking about this section of the React docs? If so, feel free to submit a PR at any point if you have ideas to improve the docs. 😄

@bvaughn Yes that is it exactly! I will definitely allign that doc in the near future.

I don't know if there are plans on making ref forwarding a part of React, but I just wrote a quick library that allows hoisting instance methods from inner refs. It uses context (old API), and some JS magic.
First draft here:
https://github.com/elado/react-ref-method-forwarder

I don't know if there are plans on making ref forwarding a part of React

That's what this RFC was for 😄and the feature is part of the upcoming 16.3 (currently available as an alpha on NPM).

I think the final comment period is done for this PR.

@bvaughn @gaearon there's one use case I'm still not sure how React.forwardRef solves:
class Field extends Component {
  focusInput() {
    this.input.focus()
  }

  render() {
    return (

        <input ref={i => (this.input = i)} />

    )
  }
}

class App extends Component {
  render() {
    return (

        <Field ref={i => (this.field = i)} />
        <button onClick={() => this.field.focusInput()}>Focus</button>

    )
  }
}

when Field is wrapped with some HOC from a different library:
class Field extends Component {
  focusInput() {
    this.input.focus()
  }

  render() {
    return (

        {this.props.label}
        <input ref={i => (this.input = i)} />

    )
  }
}

// one or more HOCs from my code/other libraries
const WrappedField = someHOC(Field)

class App extends Component {
  render() {
    return (

        <WrappedField ref={i => (this.field = i)} />
        {/* this will fail */}
        <button onClick={() => this.field.focusInput()}>Focus</button>

    )
  }
}

In App I want this.field to point to the Field instance, not the someHOC instance. I can't change someHOC to forward refs.
Or even with Redux connect - I want to "skip" HOCs and access methods on my wrapped component. Specifically focus, scrollTo and methods that change UI state that is not controlled by React (e.g. setting isFocused on an element is not the solution because this UI state is ephemeral and user may blur it).

In App I want this.field to point to the Field instance, not the someHOC instance. I can't change someHOC to forward refs.

This is meant for library developers writing the HOC, not for consumers.
But you could write your own HOC which renames forwards the ref as some prop (say forwardedRef, and then in your component, use that when assigning the ref for input.

@satya164 is right. forwardRef is meant more for use by the developer writing the HOC than one using it. Ideally, someHOC would use forwardRef to do this for you automatically.
Worst case, assuming someHOC  passes through props to your inner component, you can just intercept the ref and convert it to a prop, and maybe pass it through using something like this?
// Extracts a forwared ref-prop and applies as a ref
function applyForwardedRefTo(Component) {
  return function ApplyForwardedRef({ forwardedRef, ...props }) {
    return <Component {...props} ref={forwardedRef} />;
  };
}

// Intercepts an incoming ref and forwards it as a prop
function forwardRefTo(Component) {
  function ForwardRefTo(props, ref) {
    return <Component {...props} forwardedRef={ref} />;
  }
  return React.forwardRef(ForwardRefTo);
}

const WrappedField = forwardRefTo(someHOC(applyForwardedRefTo(Field)));

Here's a CodeSandbox example: https://codesandbox.io/s/p7xnpvvpoj

@satya164

This is meant for library developers writing the HOC, not for consumers

This means that current non-maintained libraries will probably never get this feature
Instead of waiting for updates/submitting PRs, I think there should be a global, bulletproof solution.
That's why I came up with https://github.com/elado/react-ref-method-forwarder in the first place.
React.forwardRef actually helps here, and still needs 2 HOCs (like react-ref-method-forwarder):
import React, { Component } from 'react'
// just a 3rd party library that exports a HOC
import dimensions from 'react-dimensions'

class Field extends Component {
  focusInput() {
    this.input.focus()
  }

  render() {
    return (

        <input ref={i => (this.input = i)} />

    )
  }
}

const forwardRefOuter = Wrapped => {
  return React.forwardRef((props, ref) => <Wrapped {...props} innerRef={ref} />)
}

// this *WORKS*, but throws a warning:
// Warning: Stateless function components cannot be given refs. Attempts to access this ref will fail.
// const forwardRefInner = Wrapped => props => <Wrapped {...props} ref={props.innerRef} />

const forwardRefInner = Wrapped => {
  return class extends Component {
    render() {
      return <Wrapped {...this.props} ref={this.props.innerRef} />
    }
  }
}

export default forwardRefOuter(dimensions()(forwardRefInner(Field)))

/* or
@forwardRefOuter
@dimensions()
@forwardRefInner
class Field...
*/

This means that current non-maintained libraries will probably never get this feature

This goes for any RFC. We’ve always been improving the way React apps and libraries are written in the future rather than adding retroactive hacks that get around an abstraction. If something is unmaintained it will likely bump into breaking changes between majors in any case. I understand it’s not always convenient, but it’s a larger discussion and unrelated to this particular API.


"Root/Desktop" session is automatically deleted after a while without taking into account newCommandTimeout

Hello,
In our automated tests of an UWP app we need at given times to create a root/desktop session so we can perform certain actions outside of the UWP app (such as accepting the camera permissions prompt, or checking that a given web page was opened in Edge).
Initially we were creating a new root / desktop session for each interaction of this kind, but because it takes quite a while (sometimes 30 seconds+) for the session to be created we decided to create only one session before any of our tests, reuse that session across all tests and then kill it at the end of out tests.

Thank you,
Cosmin

Do you know if the issue persists if you use WinAppDriver directly (and the latest version of that)?

No, and unfortunately it would be quite complicated to tests.
As a workaround we've tagged our tests that required a desktop session, and create one and tear it down for each test, rather than creating a single on for all tests (which would time out) or creating the session at the point of use (which would cause some other UWP specific issues - see https://social.msdn.microsoft.com/Forums/ie/en-US/8f0746ae-2790-4366-9f51-8d3cc9baa501/uwpcamera-crash-when-accepting-permisssion-prompt?forum=wpdevelop)


feat: Added Double Factorial Iterative Implementation

This pull request aims to add the iterative implementation of double factorial in TypeScript
Here's the entry I aim to add an implementation to: https://the-algorithms.com/algorithm/double-factorial-iterative

Code-wise fine, but unfortunately not really algorithmically interesting...

Yeah, that is indeed true. This code does not really have anything particularly interesting going for it. The sole reason I added this is so that the TypeScript implementations are available for more algorithms and it was the first one which I saw which didn't have an implementation.
However, I don't mind if you reject this PR since the code is pretty trivial and boring, and isn't that much of a valuable addition to the repository

Could you please atleast leave a reply @appgurueu ...?

Umm, a response or a reply would be highly appreciated

Sorry for the late reply. Well, nothing has changed; I still think this is relatively straightforward, about as interesting as the factorial implementation - it may be warranted on these grounds, also considering that it has some applications in combinatorics. I'm fairly neutral on this; I'm not opposed to merging this. @raklaptudirm thoughts?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 97.00%.  Consider uploading reports for the commit 4c87609 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #187      +/-   ##
==========================================
+ Coverage   96.98%   97.00%   +0.01%
==========================================
  Files          97       98       +1
  Lines        1793     1800       +7
  Branches      345      346       +1
==========================================
+ Hits         1739     1746       +7
  Misses         54       54

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Implement API key

Enable key= query parameter to identify source of request for statistical, not authentication purposes.
This will, more than anything, allow statistics on request coming from GEOLocate.

Authentication might need to happen (and probably through a more robust method that an API key) if feedback is going to be accepted. For example: authenticated clients could have the capability to request blocking a "bad" georeference in the gazetteer.


Proposal: Allow convenience inits to assign self

Closing this until someone has time to finish up the implementation.


added method to expose gravity control.

Hey @DanielMartinus
added method to expose vertical/bottom gravity control. I think this would be helpful in controlling the momentum of the confettis with higher speeds, so that they don't just jump out of screen, when burst in upward direction. Kept the defaults same.
I'm also thinking to work on gravity control on x-axis, to allow change in gravity direction as well. let me know what you think.

@akashraghav thank you for your contribution. Could you run ./gradlew spotlessApply to make sure the CI succeeds?

@akashraghav thank you for your contribution. Could you run ./gradlew spotlessApply to make sure the CI succeeds?

@akashraghav thank you for your contribution. Could you run ./gradlew spotlessApply to make sure the CI succeeds?

I did this earlier and pushed the change reported in log, you can view diff konfetti/src/main/java/nl/dionsegijn/konfetti/Confetti.kt but the CI check is still reporting same issue. While, I'm getting build success locally on both ./gradlew spotlessCheck and ./gradlew spotlessApply calls. Is there a way to trigger check again?
./gradlew spotlessCheck

> Configure project :demo-google-play
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

BUILD SUCCESSFUL in 4s
5 actionable tasks: 5 executed

./gradlew spotlessApply

> Configure project :demo-google-play
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

BUILD SUCCESSFUL in 926ms
5 actionable tasks: 1 executed, 4 up-to-date

@akashraghav thank you for your contribution. Could you run ./gradlew spotlessApply to make sure the CI succeeds?

I did this earlier and pushed the change reported in log, you can view diff konfetti/src/main/java/nl/dionsegijn/konfetti/Confetti.kt but the CI check is still reporting same issue. While, I'm getting build success locally on both ./gradlew spotlessCheck and ./gradlew spotlessApply calls. Is there a way to trigger check again?
./gradlew spotlessCheck

> Configure project :demo-google-play
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

BUILD SUCCESSFUL in 4s
5 actionable tasks: 5 executed

./gradlew spotlessApply

> Configure project :demo-google-play
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

BUILD SUCCESSFUL in 926ms
5 actionable tasks: 1 executed, 4 up-to-date

You're right, something is wrong with Spotless. I got it fixed locally but the CI keeps throwing the same error even though the formatting is correct. I'll let you know once its fixed

You're right, something is wrong with Spotless. I got it fixed locally but the CI keeps throwing the same error even though the formatting is correct. I'll let you know once its fixed

Figured it out. The CI is running the workflow in pull_request_target mode. I had to configure the workflow like that so it would also run for forked pull request like this. However, unfortunately it will take the base branch (master) and run spotless on that branch. I'll have to find a fix for that but for now it's fixed if you merge master into your PR.

Figured it out. The CI is running the workflow in pull_request_target mode. I had to configure the workflow like that so it would also run for forked pull request like this. However, unfortunately it will take the base branch (master) and run spotless on that branch. I'll have to find a fix for that but for now it's fixed if you merge master into your PR.

Seems, I did something wrong, I'll close this and create a new PR.

Seems, I did something wrong, I'll close this and create a new PR.

@akashraghav I fixed it for you

@akashraghav I fixed it for you

Thanks for your contribution @akashraghav

Thanks for your contribution @akashraghav


What to use for FEEDBACK_SKIP_AUTH

What var should I set for FEEDBACK_SKIP_AUTH to skip auth?

Hey Simon.  It can be any value.  It just have to set to something.  For example, SetEnv FEEDBACK_SKIP_AUTH Y would work.


hcxdumptool missing options

I had cloned the latest version of the respiratory yet i still can't use options like --enable_status or --filterlist_ap,
it says that the options weren't found, how can i fix this?

Please close this issue because you are using an old version of hcxdumptool, not the latest.
Starting with the release v6.3.0 (05.05.2023), hcxdumptool uses different options.
In other words, the syntax has changed.
https://github.com/ZerBea/hcxdumptool/discussions/423
By the way, if you are asking for help, please provide more details.
Which Linux distro you are using, which exactly version of hcxdumptool, etc.
To get the latest version please read here
https://github.com/ZerBea/hcxdumptool/blob/master/README.md

Additional to the FAQ (discussion section), more information can be found in changelog.
https://github.com/ZerBea/hcxdumptool/blob/3693e7721ac61b893d948add620de76d90749ed6/changelog#L177
And hcxdumptool's help menu:
$ hcxdumptool -h
Closed this report, because this is an issue tracker. If you have further going questions please use the discussion section.


Pixel math

capitalized species name
fixed bug where animation was not returning to the original value
fixed bug where population > resolution
updated pixelation with different implementation that uses ease functions and percentages
started adding code to address rectangular images

Closes #31, #33

Forgot that scientific names always have the first word capitalized but the second one not capitalized, so I took that out.


PUSH_RECEIVER:::Error while starting the service TypeError: Object has been destroyed

Here is my setup.
"dependencies": {
"@capacitor/electron": "2.2.1",
"electron-push-receiver": "^2.1.3",
"electron-updater": "^4.3.1",
},
"devDependencies": {
"electron": "9.1.0",
"electron-builder": "22.7.0"
},
in the renderer process:
import {
    START_NOTIFICATION_SERVICE,
    NOTIFICATION_SERVICE_STARTED,
    NOTIFICATION_SERVICE_ERROR,
    NOTIFICATION_RECEIVED as ON_NOTIFICATION_RECEIVED,
    TOKEN_UPDATED,
} from 'electron-push-receiver/src/constants';

// Listen for service successfully started
ipcRenderer.on(NOTIFICATION_SERVICE_STARTED, (_, token) => // do something);
// Handle notification errors
ipcRenderer.on(NOTIFICATION_SERVICE_ERROR, (_, error) => // do something);
// Send FCM token to backend
ipcRenderer.on(TOKEN_UPDATED, (_, token) => // Send token);
// Display notification
ipcRenderer.on(ON_NOTIFICATION_RECEIVED, (_, notification) => // display notification);
// Start service
ipcRenderer.send(START_NOTIFICATION_SERVICE, senderId);

in the main process:
setupPushReceiver(mainWindow.webContents);

I received the following error when running the electron app, when it is setting up the push receiver :
PUSH_RECEIVER:::Error while starting the service TypeError: Object has been destroyed
at WebContents..send (electron/js2c/browser_init.js:173:2098)
at IpcMainImpl. (/Users/pianokai/Sites/restvo/front/electron/node_modules/electron-push-receiver/src/index.js:55:19)
(node:81584) UnhandledPromiseRejectionWarning: TypeError: Object has been destroyed
at WebContents..send (electron/js2c/browser_init.js:173:2098)
at IpcMainImpl. (/Users/pianokai/Sites/restvo/front/electron/node_modules/electron-push-receiver/src/index.js:59:19)
upon further investigation, it seems like it crashed in src/index.js line 52 - 55
      // Listen for GCM/FCM notifications
      await listen(Object.assign({}, credentials, { persistentIds }), onNotification(webContents));
      // Notify the renderer process that we are listening for notifications
      webContents.send(NOTIFICATION_SERVICE_STARTED, credentials.fcm.token);

#11


BBCode shortcode parameter value chokes on the tag closing character

Using CommonSyntax, the following text won't be picked up by the regular parser:
[url=http://example.com]link[/url]
The parser correctly recognize the opening shortcode, continue to getting the parameter value, then finds a /which is a marker token, then look for a closing token, doesn't find it and return false.
Using parameter delimiter like this [url="http://example.com"]link[/url] yields the expected result.

@MrPetovan Your reasoning here and in #38 is correct, the RegularParser::value() method matches only "strings", ie. "not tokens" as parameter values. Mentioned URL contains shortcode token "closing mark", ie. forward slash /. Parameter value delimiters " will indeed solve the issue, but I think the generic whitespace delimited value should be possible. I'm working on the solution.

For backward compatibility in my project, I need to be able to parse such shortcode.
I see two ways of solving it:

Check that there’s a close token just after the marker token, or else keep on parsing the parameter value.
Check that there’s a marker token just before a close token to decide it’s a self-closing tag.

Just throwing ideas around.

@MrPetovan please look at #66. Please install the dev- composer version from the PR branch and verify that it works for your test cases. I added a quite thorough test for it, but I suspect there may be some uncovered edge cases. Let me know if all my answers so far and this PR solves all your issues. I'm always happy to answer more questions.
Flyers won their match, I had fun writing code, and it's nearly dawn at my place, so I'm going to a well-deserved sleep. :)

I use a little workaround for wordpress parser:
    public function getBbCode($sc)
    {
        $code = null;

        if ($this->getParser() === 'wordpress') {
            $params = $sc->getParameters();
            if (is_array($params)) {
                $keys = array_keys($params);
                $code = trim(array_shift($keys), '=');
            }
        } else {
            $code = $sc->getBbCode();
        }
        return $code;
    }


Replace webcomponents import

@jkandasa in reference to this thread: https://forum.mycontroller.org/topic/376/custom-widget-send-command-to-node/8
this PR resolves multiple problems which became obvious in the above mentioned thread:

webcomponents import is not widely supported, was recently deprecated and will be removed in near future by chrome. (see: https://www.chromestatus.com/feature/5144752345317376)
the polyfill does a good job of loading additional files but will be problematic if additional angular modules are included that way (modules will be loaded after angulars bootstrap, which causes the frontend to crash if additional modules are defined in app.js)
there is no way to specify loading of additional modules through mycontrollers frontend

to combat a race condition between angulars bootstrap process, slower internet connections and the process of loading additional JS from local or remote servers, i opted to:

defer angulars bootstrapping process. (see: https://docs.angularjs.org/guide/bootstrap)
load additional JS resources via $.getScript (see: https://api.jquery.com/jquery.getscript/)
use promises to handle the asynchronous process
test if the specified additional angularJS modules can be loaded (angular crashes if modules can not be loaded)
finally resume angulars bootstrap and pass additional modules to load

this has been tested so far on windows 10 x64 1806 with firefox 63.0.3 64-bit and is working fine for me.
i've been able to plug your custom slider widget example right into the frontend without modifying app.js. as far as i can tell, the websites is working flawless, on first an subsequent visits, with or without additional modules specified.

@elgarfo Thank you for the awesome work!
I will review this PR soon and merge it if everything goes well.

@elgarfo All works great! Thank you so much for your contributions!
There are minor update needs,

We should not touch locale files (ie: mc_locale_gui-de_de.json), We should update only mc_locale_gui_source_en.json, other files should be updated from https://transifex.com/mycontrollerorg/ I can push the source and make available your change in https://transifex.com/mycontrollerorg/ once I merge this PR.
Can you add mcv=${mc.gui.version} for newly created files?

<script src="angular_defer_bootstrap.js?mcv=${mc.gui.version}"></script>
<script src="/_configurations/additional.js?mcv=${mc.gui.version}"></script>
 <link rel="stylesheet" type="text/css" href="/_configurations/additional.css?mcv=${mc.gui.version}">

Update mc.gui.version to 28

@elgarfo I have updated the changes. Thanks!

@elgarfo I tested only on Chrome and I do not face any issue. It was a simple change I made.
Thank you for your great PR.

I checked this widget in Chrome, it works great.
In Firefox, all menus look like this ({{variable}}.

@wanvo which version of firefox and what OS did u use? can you try with a new firefox profile?

@elgarfo I am using Windows7 x64, the latest version of Firefox x64. I created a new firefox profile and I tried the widget in it.The menus look the same {{variable}}.


alerting rules: replace severity with action

The upstream Prometheus team has been discussing severity labeling and the result is that info/warning/critical is too vague for users to know what that means, which is why it was decided that the best practice will be to use the action that a particular alert is supposed to trigger.
What that means for these rules is

critical --> page
warning --> ticket

@xiang90 @heyitsanthony
/cc @fabxc @mxinden @Gouthamve

This sparked another discussion about this and it seems there is no consensus yet, so closing this until there is actually a change to the existing practice. No changes needed for now.


dynamic requirements: what's wrong with what I am doing?

here's a dead-simple self-contained example of what i'm trying to do in a much more complex workflow
if you run the following code, you'll see that it never terminates.
i think there's something i'm doing wrong with the luigi API but i'm not sure what's the issue
import luigi.local_target

import luigi

class DatumTask(luigi.Task):
    split = luigi.Parameter(significant=False)

    def output(self):
        return luigi.local_target.LocalTarget(f"/tmp/{self.split}.bin")

    def run(self):
        with self.output().open("w"):
            pass

class DatasetTask(luigi.Task):
    def output(self):
        return luigi.local_target.LocalTarget("/tmp/_SUCCESS")

    def run(self):
        for split in ["train", "test", "valid"]:
            yield DatumTask(split=split)
        with self.output().open("w"):
            pass

task = DatasetTask()
luigi.build([task], local_scheduler=True)

my observation is that if i execute the script once, it creates train.bin and test.bin successfully, and then it keeps running forever, never terminating
if i interrupt the run, and then run it again, it creates valid.bin, validates DatasetTask as complete, and correctly terminates
my issue is that in my real-world pipeline i have many more tasks, and i don't want to restart the script several times for the workflow to terminate.
how can i fix this?

I tried using DynamicRequirements but it's not solving my issue
tagging @riga because he might know what the issue is

Hi @tgy ,
your split parameter is not significant, resulting in the luigi scheduler not triggering all three tasks but just a subset of tasks (in your case one or two of them; I think this should be only one though). As a result your second task declares dynamic dependencies that are never run and thus it never makes it to the point where its own run method finishes.
The DynamicDependencies container is just a way of saving resources during repeated completness checks, e.g. in cases with large numbers of dynamic deps with remote targets.
So, in short, setting significant back to True should do the trick.
Hope that helps!

thanks @riga, that was exactly it. i figured it out by myself before your message but did not really understand why making the parameter significant solved it. now i got it :) thanks a lot!


Mocking approach for testing

Many thanks for submiting your Pull Request :heart:!
As discussed in last meeting, I am sharing mocking approach with testity framework.
We are already using testify framework in our project to write assert in unit test cases. I had implement mocking services of testify framework to write test cases with mocking of another service.
With this approach we can cover every scenerio in our project.
Please make sure that your PR meets the following requirements:

[ ] You have read the contributors guide
[ ] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[ ] You've tested the new feature/bug fix in an actual OpenShift cluster

I can see a meaning for mocking in case we want to simulate some specific conditions/issues like failure in Kubernetes API call, something what is hard to simulate with current functionality. Not much for "common" usage.
Mocking would allow us to run unit tests for "high level" structures, by isolating it from lower levels. But do we want it?
IMHO such approach would bind the tests with the implementation, in case of refactoring we would have to basically rewrite the tests.
We would still have to keep some functional tests to make sure that application layers can work together, making sure that upper layer is able to process response from lower layer.
Unit tests have sense in case of simple functions without much dependencies and integrations. But for complex functionality it is from my point of view important to make sure it follows contract and correctly integrates with all components.

Agree with @sutaakar, IMO I don't see why mocking these internals on command side. The main problem that we'd like to test is actually to see if the flags are been converted into the correct CR structure. Mocking this behavior would not test what we really need.

@vaibhavjainwiz can we close this one?

@vaibhavjainwiz can we close this one?

Please close it


Managed Istio: Manager exited non-zero

Hi team! We have the managed istio on multiple IKS clusters.
We are using the latest 1.7.2 version and sporadically on some clusters we can see logs as the following:
2020-09-24T13:23:12.697712Z	error	error retrieving resource lock ibm-operators/istio-operator-lock: Get "https://<IP_ADDRESS>:443/api/v1/namespaces/ibm-operators/configmaps/istio-operator-lock": context deadline exceeded
2020-09-24T13:23:12.697802Z	info	failed to renew lease ibm-operators/istio-operator-lock: timed out waiting for the condition
2020-09-24T13:23:12.697865Z	fatal	Manager exited non-zero: leader election lost

and as:
    Sep 24 15:23:13kube-brq9cjpd05d8tb2l7bfg-ghostfordoc-default-00000115syslogE0924 13:23:13.260809    6966 pod_workers.go:191] Error syncing pod bd4d62ea-e38d-4e67-98c0-48b339f06337 ("managed-istio-operator-88cc547b4-8p9x4_ibm-operators(bd4d62ea-e38d-4e67-98c0-48b339f06337)"), skipping: failed to "StartContainer" for "istio-operator" with CrashLoopBackOff: "back-off 10s restarting failed container=istio-operator pod=managed-istio-operator-88cc547b4-8p9x4_ibm-operators(bd4d62ea-e38d-4e67-98c0-48b339f06337)"

    Sep 24 15:23:13kube-brq9cjpd05d8tb2l7bfg-ghostfordoc-default-00000115kubelet.logE0924 13:23:13.260809    6966 pod_workers.go:191] Error syncing pod bd4d62ea-e38d-4e67-98c0-48b339f06337 ("managed-istio-operator-88cc547b4-8p9x4_ibm-operators(bd4d62ea-e38d-4e67-98c0-48b339f06337)"), skipping: failed to "StartContainer" for "istio-operator" with CrashLoopBackOff: "back-off 10s restarting failed container=istio-operator pod=managed-istio-operator-88cc547b4-8p9x4_ibm-operators(bd4d62ea-e38d-4e67-98c0-48b339f06337)"

This seems to appear only some days and everything seems to be fine (the system works as usually).
The istioctl analyze -n namespace doesn't show any problem.
The istioctl version shows that every proxy is updated to latest 1.7.2 version.
Any ideas? Are there action that we can take to avoid those crash?
If required, I can attach some extra logs.

@ostromart this looks like a crash failure. Can you take a look?

@luiof just a brief look. It appears as if leader election, which is used to ensure only one operator is running at a time within a namespace (aka fencing), is lost because of a timeout reading from the K8s API server. Looking at the K8s client code, the default is 10 seconds for RenewDeadline and the operator does not override this configuration.
10 seconds may be insufficient on a heavily loaded K8s API server.
@ostromart how do you think we should proceed? Increase the timeout to something more reasonable like 30 seconds?
@morvencao if you're bored :)
Cheers,
-steve

can add a new env to the template to customize renewDeadline and pass in the manager config

Any update or eta about the new customization to mitigate the timeout?
Our managed-istio-operator restarts multiple times in four days:
$ kubectl get pods -n ibm-operators
NAME                                     READY   STATUS    RESTARTS   AGE
managed-istio-operator-56759bf69-xjdxc   1/1     Running   10         4d

@richardwxn I made this a P0 for 1.8 as this seems to be an important bug fix. Looks like you have an idea about how to fix it so temporarily assign to you. Please downgrade if you think this is not a P0 or reassign if necessary. thanks!

This let us set the RENEW_DEADLINE but the leaseDuration limits the renewDeadline.
We set the RENEW_DEADLINE to 30s and get this error when the operator pod tries to start.
2021-04-09T18:45:44.565506Z	info	installer	Controller added
2021-04-09T18:45:44.565541Z	info	Starting the Cmd.
2021-04-09T18:45:44.565767Z	fatal	Manager exited non-zero: leaseDuration must be greater than renewDeadline

It seems like the leaseDuration defaults to 15s
cc @richardwxn


Added a few new methods. Removed some deprecated ones. Fixed tests.

I noticed that some tests were failing. Turns out that Sauce changed some of the endpoints. I fixed the Information methods and associated tests. All tests now succeed.

Removed information.get_browsers()
Removed information.get_count()
Added information.get_platforms()
Added information.get_appium_eol_dates()

Also, the json_load method is now being called from client.request() so it is no longer needed in each of the other methods (and has been removed).
There are a few other methods that sound eventually be added to the client. I started doing that, but then felt like some parts are due for a rewrite. Maybe someday. :)
BTW, the tests should probably eventually be mocked so they don't actually hit Sauce (and then we can get TravisCI wired up).

👍  looks great!  thanks for the contribution.


Extension host process runs at version N+1

We have observed, sometimes, updates are applied to disk while VS Code is running. It is therefore possible to end up in a situation where VS Code is launched at version N, with a renderer at version N and an extension host at version N, and then the extension host crashes or needs to be restarted and then an extension host at version N+1 is launched since the update was applied on disk.
Since it is very difficult to prevent the updater from touching the disk while VS Code is running, we should implement an extra protection mechanism into the extension host protocol. (fyi @Tyriar @joaomoreno)

Related: https://github.com/Microsoft/vscode/issues/5908

Yes, that's why I created a new issue... because the old bugs keep getting closed ... 😄.


Move sveltekit to svelte

Folder was incorrectly named sveltekit. We need to migrate all files and documentation over to the svelte folder.

Will do @cobycloud  🚀


OpenQASM 3 integer literals should use integer division

Describe the bug
After some discussion here: https://github.com/Qiskit/qiskit/issues/12167, it seems that the stdgates.inc definition gate sx a { pow(1/2) @ x a; } should have the 1/2 resolve to 0 thanks to integer division (i.e. stdgates.inc has an incorrect definition of sx gate). As it stands, it seems that when interpreting openQASM 3, the Braket sim treats these values as floats (which makes that sx gate definition behave correctly).  Apparently the relevant part of the specification is here: https://openqasm.com/language/classical.html#integers.
Being as 'fixing' this would break stdgates.inc as of right now, I don't think it should be 'fixed' yet. I'm not even sure how closely Braket promises to follow the openQASM specification, so perhaps it's a non-issue.
To reproduce
from braket.circuits import Circuit
from braket.devices import LocalSimulator

device = LocalSimulator()
quantum_circuit = Circuit.from_ir('''
OPENQASM 3.0;
include "stdgates.inc";
qubit[1] q;
ry(1/2) q;
''')
quantum_circuit.probability()
res = device.run(quantum_circuit, 0)
print(res.result().values)

Expected behavior
The ry(1/2) should resolve to ry(0) here resulting in a 1.0 probability of q being 0. To use floating point division it would need to be 1.0 / 2, 1 / 2.0 or 1.0 / 2.0.
Screenshots or logs
Actual output: [array([0.93879128, 0.06120872])]
System information
A description of your system. Please provide:

Amazon Braket Python SDK version: v1.74.0
Amazon Braket Python Schemas version:
Amazon Braket Python Default Simulator version:
Python version: Python 3.10.12

Additional context
N/A

Hi @DanBlackwell - thank you for raising this issue! We will look into this.

stdgates.inc will be fixed in https://github.com/openqasm/openqasm/pull/529, so #247 will work fine with it


Sidecar: add accept-all-ssl-certificates property in order to be able to use https health checks with self-signed certificates

Hello guys!
Adding a new property I think can be interesting :)
Actually I had to do a workaround (https://github.com/spring-cloud/spring-cloud-netflix/issues/3175#issuecomment-420276337 thanks @spencergibb ) in a project I'm working on, but I think that changing the way RestTemplate is created, we can make Sidecar work with https healthchecks, with self-signed certificates.
Don't know if it's useful for you. What do you think?
Stuff I'd like to improve in the case the feature is OK

Default value for accept-all-certificates. How can I set it to false?
Add Unit test to LocalApplicationHealthIndicator

PS: PR https://github.com/spring-cloud/spring-cloud-netflix/pull/3213 closed because of a problem while rebasing :/

Sounds good, also need to add documentation

Codecov Report

Merging #3224 into 2.0.x will decrease coverage by 6.21%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##              2.0.x    #3224      +/-   ##
============================================
- Coverage     66.06%   59.84%   -6.22%
+ Complexity     1465      871     -594
============================================
  Files           182      129      -53
  Lines          6845     4585    -2260
  Branches        836      469     -367
============================================
- Hits           4522     2744    -1778
+ Misses         2011     1664     -347
+ Partials        312      177     -135

Impacted Files
Coverage Δ
Complexity Δ

...etflix/turbine/stream/HystrixStreamAggregator.java
73.68% <0%> (-5.27%)
8% <0%> (-1%)

...ud/netflix/zuul/ZuulServerMarkerConfiguration.java

...ud/netflix/zuul/filters/CompositeRouteLocator.java

...ul/filters/discovery/SimpleServiceRouteMapper.java

...filters/discovery/DiscoveryClientRouteLocator.java

...lters/route/okhttp/OkHttpRibbonCommandFactory.java

...l/filters/discovery/PatternServiceRouteMapper.java

.../netflix/zuul/filters/route/SendForwardFilter.java

...ework/cloud/netflix/sidecar/SidecarController.java

...oud/netflix/zuul/filters/post/SendErrorFilter.java

... and 42 more

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 8bfc0d5...ad24dc8. Read the comment docs.

@ryanjbaxter thanks! Done!


New graph layout algorithm + ELK layout engine

This PR adds a new layout method for graphs which uses the open source ELK/elkjs graph layout library.
I've attached slides from a presentation I gave to the F' team describing the rationale for this effort: FPrimeVisualELKPresentation.pdf.
In short, this enables intelligent graph layout and edge routing, so that graphs may be rendered with fewer confusing visual artifacts, such as connection lines overlapping each other or drawn on top of boxes. Example old layout:

New layout:

Notes

The new layout/rendering code is mainly in src/fprime_visual/flask/static/js/renderers/render-elk.js
Since elkjs is really the only dependency, I decided to just include a bundled version of it in our repo (in src/fprime_visual/flask/static/js/lib/elkjs) rather than introduce npm dependency management.
Similarly I didn't want to complicate things by adding a build process or anything - however I did restructure things to use native JS modules with import statements for more predictable scoping etc.
Since the original layout sometimes produces good results, I've preserved its code (restructured slightly) and made it available with the "Layout" dropdown option. Each layout provides a module with a render function, so we can add additional future layouts with this pattern if we want.

Future work
Things I didn't get to...

Shared ELK renderer - Currently the rendering code is fairly closely tied to the layout code. In future it would be good to have a single shared ELK renderer (the part which draws things on the canvas) which is capable of rendering multiple ELK-generated layouts (the part that decides where things go), if we want to provide access to additional ELK algorithms/features.
Settings panel - It would be nice to let the user modify some of the ELK settings to get the best results. This could be done with an expandable side panel containing options which modify the config option passed to the renderer. The user should also be able to select between the different available color themes, which already exist.
Visual updates - Themes could be changed a bit to improve readability and contrast. I started work on a light color theme with better contrast but it needs more work. We'd also like to visually group ports that are in the same port group.

Please let me know if you have any questions, happy to discuss it further. Thanks!

Closing and reopening to re-trigger CI.

Ah - just took a peek at the failing tests from the CI build - I didn't realize they were there & my changes likely broke them because I changed which <script>s are included in the HTML template (some are loaded via import now). I can push a fix tomorrow or feel free to do it without me.

@LeStarch yes that's correct, all of the files in lib/elkjs are copied from elkjs without any modifications - thanks for checking.
Looking at it again, we may not to include the elk-api.js and elk-worker.js files since I think they are both included in the elk.bundled.js file. All of the .d.ts files are still useful to include, though, since they give you type hints in the IDE.

Works nicely!


Improvement: Visit 'admin' privileges

Context:

https://streamalert.readthedocs.io/account.html#administrator
https://streamalert.slack.com/archives/general/p1486614692000033

[ ] Update the docs with whitelisted AWS permissions
[ ] Create a role which all SA CLI users can inherit from which gives them only the access they need as well as the ability to read Terraform statefiles

https://www.streamalert.io/account.html


Build failure: ripgrep-all

Steps To Reproduce
Steps to reproduce the behavior:

build ripgrep-all

Build log
https://gist.github.com/Samasaur1/3a9b67fdcca24e4ccede859cdd480153
Additional context
Add any other context about the problem here.
Notify maintainers
@zaninime @Ma27
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix run nixpkgs#nix-info -- -m
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.6.0, macOS 14.6.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.18.8`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/store/60sn02zhawl3kwn0r515zff3h6hg6ydz-source`

Add a :+1: reaction to issues you find important.

Looks like this is a Darwin exclusive issue - ripgrep-all builds fine on x86_64 and aarch64 Linux.

Same issue here, also on macOS.

Does anybody have an idea how the rga-fzf-open.dSYM ends up in there? And is this even needed or just an artifact that ends up there for no real reason?
If the latter is actually the case, we could also just rm it before creating the wrappers.


Add new problem kind features

@arbimo in this PR we added two new features: STATIC_FLUENTS_IN_OBJECT_ASSIGNMENTS and FLUENTS_IN_OBJECT_ASSIGNMENTS. I think they are probably supported by aries.

Codecov Report
Patch coverage: 87.87% and project coverage change: +0.01 :tada:

Comparison is base (d354253) 85.01% compared to head (0d67aa7) 85.03%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #437      +/-   ##
==========================================
+ Coverage   85.01%   85.03%   +0.01%
==========================================
  Files         198      198
  Lines       25523    25552      +29
==========================================
+ Hits        21699    21727      +28
- Misses       3824     3825       +1

Impacted Files
Coverage Δ

unified_planning/model/problem_kind.py
96.99% <ø> (ø)

...ed_planning/grpc/generated/unified_planning_pb2.py
6.99% <25.00%> (ø)

unified_planning/model/problem.py
89.47% <80.00%> (-0.09%)
:arrow_down:

...lanning/engines/compilers/bounded_types_remover.py
96.61% <100.00%> (+0.05%)
:arrow_up:

...g/engines/compilers/conditional_effects_remover.py
95.32% <100.00%> (+0.05%)
:arrow_up:

...ngines/compilers/disjunctive_conditions_remover.py
87.71% <100.00%> (+0.10%)
:arrow_up:

unified_planning/engines/compilers/grounder.py
98.15% <100.00%> (+0.02%)
:arrow_up:

...g/engines/compilers/negative_conditions_remover.py
95.75% <100.00%> (+0.04%)
:arrow_up:

..._planning/engines/compilers/quantifiers_remover.py
92.56% <100.00%> (+0.10%)
:arrow_up:

...ning/engines/compilers/state_invariants_remover.py
88.65% <100.00%> (+0.23%)
:arrow_up:

... and 5 more

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


ESA-1867 Created new eForm Submitter field on Case, added layout and …

…Permission Set changes.

If you didn't get requirements or if you're not sure with the other page layouts and report types, remove them from your PR. Otherwise keep them.


PLNSRVCE-1310: bump exporter mem from 256 to 512 Mib

Have pattern where the exporter in production hovers around 256 MiB for several hours, and when we bump up too much against it, the kubelet restarts us.  No error message in prev log.  So consistent with mem limit rebump.
Going to 512 to start.
As point of ref, tekton pipeline controller in production is hovering around 1GiB (and it has no mem limit).
We watch less that ^^ so let's see the 512 run first.

Forcing merge as it won't impact the CI.


No module named "cde.utils"?

After installing the package I ran into an Error after trying out the demo, can you help me on this please?

ModuleNotFoundError                       Traceback (most recent call last)
 in
----> 1 from cde.density_simulation import SkewNormal
2 from cde.density_estimator import KernelMixtureNetwork
3 import numpy as np
4
5 """ simulate some data """
~/opt/anaconda3/lib/python3.7/site-packages/cde/init.py in
----> 1 from .BaseConditionalDensity import ConditionalDensity
~/opt/anaconda3/lib/python3.7/site-packages/cde/BaseConditionalDensity.py in
7 import matplotlib.pyplot as plt
8 import scipy
----> 9 from cde.utils.optimizers import find_root_newton_method, find_root_by_bounding
10
11
ModuleNotFoundError: No module named 'cde.utils'

I encountered the same error, is there any update on this at the moment?

any update on this?

I ran into this issue. Had to create a new environment and downgrade to Python 3.6.

Hey install the package by cloning the repo and then using setup.py?
happened to me but now encountering TensorFlow version errors


Provide Export with a bundled webserver option?

This has cropped up a few times on the forum recently - might be worth exploring whether it's worth it for deployment to CD/USB etc...

Implemented this differently, by encapsulating the dynamix content in javascript files, that get all loaded once.


Defining rules via data

Hi
I'm really impressed with this project.  I was wondering if there's a way to define rules in a way that could be stored in a database to allow for rules to be configured at runtime?
If this was possible then this library could become very powerful in applications such as product configuration.

Hi Lee, Thank you. There is definitely more than one way of going about this. Depending on what makes more sense to you. One approach I would take, let the data drive the rules defined at runtime.
In the example below, I've defined a rule to log my model. However the rule would only execute if the rule constraint evaluates to true. And the data injected via the dependency injection at runtime which drives the behavior of the rule.
Would that solve the problem for you?
Example:
class LoggingRule : Rule<Model>
{
    ILogger _logger;
    ILogConfiguration _logConfiguration;

    public LoggingRule(ILogger logger, ILogConfiguration logConfiguration)
    {
        _logger = logger;
	_logConfiguration = logConfiguration;
    }

    public override Task Initialize()
    {
        Configuration.Constraint = model => _logConfiguration.EnableLogging;
        return null;
    }

    public override IRuleResult Invoke()
    {
        _logger.log(...);
	return null;
    }
}


when a client disconnects and reconnects even their own messages will be sent to them

I assume you are mentioned this behavior:

The bottom terminal is 'Noveee' and as you can see they receive every message even if it's them sending it.
This behavior IS NOT unique to this use case where there user disconnects/reconnects. Here is an example showing that it happens:

Based on the way you broadcast message this is the expected behavior for all use cases
# Broadcasting messages to all connected clients
def broadcast(message):
    for client in clients:
        client.send(message)

As you can see the broadcast() function does not have any logic to handle the sending of a message to specific clients. Therefore, every message is sent to everyone. To fix this, we can add extra logic into the broadcast() function to make it 'filter out' any client we want:
Possible implementation No. 1
Add an argument that specifies which clients are to be included in the broadcast.
The argument can be either one socket.socket or many sockets (list[socket.socket])
# Broadcasting messages to all connected clients
def broadcast(message: str, listeners: socket.socket | list[socket.socket]) -> None:
    for client in listeners:
        client.send(message)

Example Use Case:
message = 'Hello World!'
listeners = [client1, client2, client3]
broadcast(message, listeners)

Possible implementation No. 2
Add an argument that specifies which clients are to be excluded in the broadcast
The argument can be either one socket.socket or many sockets (list[socket.socket])
def broadcast(message: str, exclude: socket.socket | list[socket.socket]) -> None:
    listeners = list(set(clients) - set(exclude))
    for client in listeners:
        client.send(message)

Example Use Case:
message = 'Hello World!'
broadcast(message, exclude=[client1, client69])


Cloud controller logs have too much low-information entries

The logs for parse_params, cc.read, and cc.enumerate.related should be downgraded to DEBUG2.  They fill up the logs and rotate more useful messages to secondary files, and quickly to oblivion.

Hi @ericpromislow, thanks for submitting this issue!
We appreciate your input when describing this issue, however we find the information in these log messages useful when debugging. As such we will not be changing log levels at this time.
Best,
@zaksoup + @wendorf, CF Runtime Team

We just reopened discussion on this issue, and fail to see how any of the affected messages are useful. Place log.debug messages in two broad categories: 1: log potentially anomalous, and infrequent, conditions in the field that could be useful to support teams, and (2): emit messages that help the developers better understand their code. I would say we have no business pushing type-2 log.debug messages into production, especially when they cause logs to turn over in less than a minute on busy clusters.  @zaksoup and @wendorf, could you explain some specific benefits of retaining these statements?


Revert Empty Query Param Value Change in UrlBuilder

Description
Reverts an internal change to how UrlBuilder handles query parameters with null or empty values.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.

/azp run java - core


WIP: Produce with schema

TODO :

[x] add unit test
[x] refactoring : should we create a dedicated Record object for the production? or merge with the actual Record?

Good stuff here :)
Thanks :+1:
Just the combo box with available schema will be very nice.
Also don't understand the  dedicated Record object for the production, can you tell me more ?

Also don't understand the  dedicated Record object for the production, can you tell me more ?

At first, I wanted to re-use the Record entity, and fill all the attributes to finally call a "serialize" method on it, but the use case is different of the actual Record which is more or less a wrapped ConsumerRecord. So I wondered if I should have created some kind of ProducerRecord wrapper.
As a first step I only created a dedicated serialization class (maybe its sufficient)

ok better understanding now :)
dedicated serialization class don't shock me, you can keep it as I think !
the modules directory is little messy but one day, i will cleanup it and separate some of them to a services directory, but it's fine for now :)

Seems to be better now !
Thanks
Last things I see is ACLS, if the user has no right on the schema registry and there is no configured schema registry, you should not displayed this feature.
I think for now, no SR mean a null pointer exception

You're right, I will check this next week when coming back from hollidays :D

thanks :)
but for ACLS, I mostly think about this conditions :
https://github.com/tchiotludo/kafkahq/blob/2e2cde3b85114529484b4af92ccade7a93d39dfa/src/main/resources/views/includes/template.ftl#L90
That is available globally for all templates from :
https://github.com/tchiotludo/kafkahq/blob/2e2cde3b85114529484b4af92ccade7a93d39dfa/src/main/java/org/kafkahq/controllers/AbstractController.java#L74
It will check if registry acls and configuration are present ;)

Sorry I missed this point -_-'
I'will have a check on this :)

All good work :)
It's merged and I just add a little commit on layout.
Thanks a lot :)


Carthage Support

I made the framework-target shared to support Carthage

@ChrisSchneider Thanks ! And I'm sorry to late.


OpenCvSharp4.Windows Unable to load DLL 'OpenCvSharpExtern'

Summary of your issue
Getting OpenCvSharp4.Windows from nuget, try demo code of lenna, got this error
System.TypeInitializationException
  HResult=0x80131534
  Message=The type initializer for 'OpenCvSharp.NativeMethods' threw an exception.
  Source=OpenCvSharp
  StackTrace:
   at OpenCvSharp.NativeMethods.imgcodecs_imread(String filename, Int32 flags)
   at OpenCvSharp.Mat..ctor(String fileName, ImreadModes flags)
   at OpenCvSharpYolo3.Program.Main(String[] args) in D:\Users\Died.Liu\source\repos\OpenCvSharpYolo3\OpenCvSharpYolo3\Program.cs:line 14

Inner Exception 1:
DllNotFoundException: Unable to load DLL 'OpenCvSharpExtern': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Environment
package id="OpenCvSharp4.Windows" version="<IP_ADDRESS>81225" targetFramework="net46"
win 10 v1809 , vs2017 v18.8.9
What did you do when you faced the problem?
the demo code work on OpenCvSharp v3, it should be work at v4
Example code:
demo code
Quick fix
stupid way copy dll folder from previous project that using OpenCvSharp3.

put into your \bin\debug then it work, but I think it's for v3 not v4.
Guess
Maybe it's typo or something, @shimat can you check it ?
I noticed on frontpage ubuntu build Instructions have Build native wrapper OpenCvSharpExtern, so I think it maybe miss on OpenCvSharp4.Windows nuget package, it didn't include OpenCvSharpExtern.dll,

This is still a problem with the latest version (4.2....).
Do you have a plan to fix this?

I have the same problem with the VideoCaptureForm and SamplesVB projects

I have the some project with versión 4.2.20200421

I have the some project with versión4.22.20200208

I have the same problem version <IP_ADDRESS>00524

v<IP_ADDRESS>10210 still the same.
I just download sample project directly from github, set the VideoCaptureForm as startup proj and run, the error showed up. Did I miss any step?

Same runtime exception with installed version : <IP_ADDRESS>10817

Hello guys.
You need to install both of these NuGet packages not only the first one (in my case, it fixed the problem):

OpencvSharp4
OpencvSharp4.runtime.win
hope it helps.

Hello guys.
You need to install both of these NuGet packages, not only the first one (in my case, it fixed the problem):

OpencvSharp4
OpencvSharp4.runtime.win

I hope it helps.


nix-shell fails in newly initialized obelisk project

I'm trying to set up a new obelisk project, and after running nix shell in the project root I get the following error message:
error: Package ‘fix-darwin-dylib-names-hook’ in /nix/store/ahg8gp1z3qrw1ds5vx2324j72i7y9vjg-source/pkgs/build-support/trivial-builders.nix:74 is not supported on ‘x86_64-linux’, refusing to evaluate.

       a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

        Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
        (Flake) command, `--impure` must be passed in order to read this
        environment variable.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.
(use '--show-trace' to show detailed location information)

Running the command with NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 returned
error: iOS builds are not supported on this platform.

I'm super new to nix, and am not even sure that using nix-shell is how I'm supposed to start things; ob run seems to work on its own already, but I had added a local package, and putting it in the cabal file didn't seem to be enough for ob run to find it, so thought maybe I was supposed to add it to default.nix and enter a nix-shell before using the ob commands, but truthfully I'm not sure if that's right.
I'm running in NixOS, and don't need iOS support for anything. I'm not even sure how much this is an obelisk issue; I had a similar issue trying to modify the default.nix shown at https://github.com/reflex-frp/reflex-platform/blob/develop/docs/project-development.rst to work for a minimal project to after deciding obelisk might be too much complexity too soon.
I'm mainly posting here since all of the code in my obelisk project was exactly as created by ob init, so if nix-shell is supposed to work, I feel like it should work there.

ob has its own shell command: ob shell. This might get you the shell you want.

Ah, I didn't know about that one, thanks. After doing some more digging on the local packages problems I was having it seemed to be a permissions problem; fixing that got ob run working the way I had expected it to work.


Add Nova by Ahrix

Song Name
Nova
Artist Name
Ahrix
Source
Youtube
Youtube Link
X5mcY8ecs8I
Direct File Link
No response
Song ID
592052
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 4981164

Accept

Thanks for contributing! Someone will soon review your request.
Here is the JSON result for the reviewer:
{
  "name": "Nova",
  "artist": "Ahrix",
  "source": "youtube",
  "startOffset": 0,
  "yt-id": "X5mcY8ecs8I",
  "songs": [
    592052
  ]
}

To accept the request, a reviewer needs to write "accept".

this is current request

auto

accept

Thanks for contributing! Someone will soon review your request.
Here is the JSON result for the reviewer:
{
  "name": "Nova",
  "artist": "Ahrix",
  "source": "youtube",
  "startOffset": 0,
  "yt-id": "X5mcY8ecs8I",
  "songs": [
    592052
  ]
}

To accept the request, a reviewer needs to write "accept".

accept

accept


TypeError: argument of type 'NoneType' is not iterable

I am running 1.8.0, and I get the following error:

[2021-04-26 09:50:04,686] [util.py:313]               [DEBUG]    | Traceback (most recent call last):                                                                 |
                                                                 |   File "plex_meta_manager.py", line 110, in start
                                                                 |     config = Config(default_dir, config_path, libraries_to_run)
                                                                 |   File "/home9/calboi/Plex-Meta-Manager/modules/config.py", line 391, in __init__
                                                                 |     if self.general["radarr"]["url"] or "radarr" in lib:
                                                                 | TypeError: argument of type 'NoneType' is not iterable
                                                                 |
[2021-04-26 09:50:04,687] [plex_meta_manager.py:114]  [CRITICAL] | argument of type 'NoneType' is not iterable

I do not have radarr configured in my config.yml file.

I think this is already fixed in develop


Add loginUser to centos7 entity

This is short term amendment until JCLOUDS-1165 is addressed. Currently unless loginUser: centos is specified in the location of a CentOS image, Jclouds fails to provision the machine.

This is unfortunately not going to work because the RightScale image which Brooklyn provisions by default when launching with CentOS selected has the default use of root.


AuthenticationToken not returned in FB Limited Login

Description: In the SocialLoginPlugin.swift file, the authenticationToken is not returned when performing a Facebook Limited Login. Although the token is successfully retrieved in the FacebookLoginResponse, only the accessToken and profile fields are included in the response, which prevents the front-end from accessing the authenticationToken required for further authentication steps.
This issue specifically affects scenarios where Facebook Limited Login is used.
Steps to reproduce:
Initiate a Facebook Limited Login using the SocialLoginPlugin with the limited login option set in the payload.
Observe the response object returned to the front-end.
Notice that authenticationToken is missing, while accessToken and profile are present.
Expected Behavior: The response object should include the authenticationToken field, along with the accessToken and profile, especially when using Facebook Limited Login.
Current Behavior: The authenticationToken is not returned in the login result for Facebook when using Limited Login. The relevant code section omits this field.
Affected Code: In the file SocialLoginPlugin.swift, the method handleLoginResult currently returns the following for Facebook:
else if let facebookResponse = response as? FacebookLoginResponse {
    call.resolve([
        "provider": "facebook",
        "result": [
            "accessToken": facebookResponse.accessToken,
            "profile": facebookResponse.profile
        ]
    ])
}

Proposed Fix: Modify the handleLoginResult method to include the authenticationToken in the response for Facebook Limited Login:
else if let facebookResponse = response as? FacebookLoginResponse {
    call.resolve([
        "provider": "facebook",
        "result": [
            "accessToken": facebookResponse.accessToken,
            "profile": facebookResponse.profile,
            "authenticationToken": facebookResponse.authenticationToken ?? ""
        ]
    ])
}

The authenticationToken is a critical part of Facebook Limited Login and is required for verifying the login state. Please ensure the authenticationToken is properly returned to the front-end, allowing full access to the necessary authentication details when using Facebook Limited Login.

Thanks for the report, it should be good now !