[Core] remove style-propable mixin from components

style-propable is a mixin that I really don't see why it should exist. This mixin does not affect component's life cycle and the only thing it does is inject helper functions.
This mixin appears in most of the components and is the only mixin in most cases. Removing this not only improves the performance and clarity, more importantly, many components will be changed to pure and written in es6 style.
List of components:

[x] material-ui\src\app-bar.jsx (#3183)
[x] material-ui\src\app-canvas.jsx (#3184)
[x] material-ui\src\auto-complete.jsx (#3350)
[x] material-ui\src\avatar.jsx (#3235)
[x] material-ui\src\badge.jsx (#3185)
[x] material-ui\src\before-after-wrapper.jsx (#3228)
[x] material-ui\src\buttons\flat-button-label.jsx (#3197)
[x] material-ui\src\card\card-actions.jsx (#3198)
[x] material-ui\src\card\card-expandable.jsx (#3198)
[x] material-ui\src\card\card-header.jsx (#3198)
[x] material-ui\src\card\card-media.jsx (#3198)
[x] material-ui\src\card\card-text.jsx (#3198)
[x] material-ui\src\card\card-title.jsx (#3198)
[x] material-ui\src\card\card.jsx (#3198)
[x] material-ui\src\checkbox.jsx (#3234)
[x] material-ui\src\circular-progress.jsx (#3233)
[x] material-ui\src\date-picker\calendar-year.jsx (#3291)
[x] material-ui\src\date-picker\calendar.jsx (#3291)
[x] material-ui\src\date-picker\date-display.jsx (#3291)
[x] material-ui\src\date-picker\date-picker-dialog.jsx (#3291)
[x] material-ui\src\date-picker\date-picker.jsx (#3291)
[x] material-ui\src\date-picker\day-button.jsx (#3291)
[x] material-ui\src\date-picker\year-button.jsx (#3291)
[x] material-ui\src\dialog.jsx (#3218)
[x] material-ui\src\drop-down-icon.jsx (removed in #3108)
[x] material-ui\src\enhanced-button.jsx (#3254)
[x] material-ui\src\enhanced-switch.jsx (#3255)
[x] material-ui\src\enhanced-textarea.jsx (#3252)
[x] material-ui\src\floating-action-button.jsx (#3251)
[x] material-ui\src\font-icon.jsx (#3230)
[x] material-ui\src\grid-list\grid-list.jsx (#3202)
[x] material-ui\src\grid-list\grid-tile.jsx (#3202)
[x] material-ui\src\hoc\selectable-enhance.js (#3261)
[x] material-ui\src\icon-button.jsx (#3232)
[x] material-ui\src\ink-bar.jsx (#3256)
[x] material-ui\src\left-nav.jsx (#3229)
[x] material-ui\src\linear-progress.jsx (#3233)
[x] material-ui\src\lists\list-item.jsx (#3259)
[x] material-ui\src\lists\list.jsx (#3259)
[x]  material-ui\src\menu\link-menu-item.jsx (removed in #3108)
[x]  material-ui\src\menu\menu-item.jsx (removed in #3108)
[x]  material-ui\src\menu\menu.jsx (removed in #3108)
[x]  material-ui\src\menu\subheader-menu-item.jsx (removed in #3108)
[x] material-ui\src\menus\icon-menu.jsx (#3219)
[x] material-ui\src\menus\menu-item.jsx (#3219)
[x] material-ui\src\menus\menu.jsx (#3219)
[x] material-ui\src\overlay.jsx (#3220)
[x] material-ui\src\paper.jsx (#3221)
[x] material-ui\src\popover\popover-animation-from-top.jsx (#3201)
[x] material-ui\src\popover\popover-default-animation.jsx (#3201)
[x] material-ui\src\popover\popover.jsx (#3201)
[x] material-ui\src\radio-button-group.jsx (#3224)
[x] material-ui\src\radio-button.jsx (#3224)
[x] material-ui\src\raised-button.jsx (#3263)
[x] material-ui\src\refresh-indicator.jsx (#3233)
[x] material-ui\src\ripples\circle-ripple.jsx (#3199)
[x] material-ui\src\ripples\focus-ripple.jsx (#3199)
[x] material-ui\src\ripples\touch-ripple.jsx (#3199)
[x] material-ui\src\SelectField\SelectField.jsx (#3260)
[x] material-ui\src\slider.jsx
[x] material-ui\src\snackbar.jsx (#3257)
[x] material-ui\src\svg-icon.jsx (#3222)
[x] material-ui\src\table\table-body.jsx (#3227)
[x] material-ui\src\table\table-footer.jsx (#3227)
[x] material-ui\src\table\table-header-column.jsx (#3227)
[x] material-ui\src\table\table-header.jsx (#3227)
[x] material-ui\src\table\table-row-column.jsx (#3227)
[x] material-ui\src\table\table-row.jsx (#3227)
[x] material-ui\src\table\table.jsx (#3227)
[x] material-ui\src\tabs\tab.jsx (#3236)
[x] material-ui\src\tabs\tabs.jsx (#3236)
[x] material-ui\src\TextField\TextField.jsx (#3349)
[x] material-ui\src\time-picker\clock-hours.jsx (#3188)
[x] material-ui\src\time-picker\clock-minutes.jsx (#3188)
[x] material-ui\src\time-picker\clock-number.jsx (#3188)
[x] material-ui\src\time-picker\clock-pointer.jsx (#3188)
[x] material-ui\src\time-picker\clock.jsx (#3188)
[x] material-ui\src\time-picker\time-display.jsx (#3188)
[x] material-ui\src\time-picker\time-picker-dialog.jsx (#3188)
[x] material-ui\src\time-picker\time-picker.jsx (#3188)
[x] material-ui\src\toggle.jsx (#3189)
[x] material-ui\src\toolbar\toolbar-group.jsx (#3180)
[x] material-ui\src\toolbar\toolbar-separator.jsx (#3180)
[x] material-ui\src\toolbar\toolbar-title.jsx (#3180)
[x] material-ui\src\toolbar\toolbar.jsx (#3180)
[x] material-ui\src\tooltip.jsx (#3203)
[x] material-ui\src\transition-groups\scale-in-child.jsx (#2909)
[x] material-ui\src\transition-groups\scale-in.jsx (#2909)
[x] material-ui\src\transition-groups\slide-in-child.jsx (#2909)
[x] material-ui\src\transition-groups\slide-in.jsx (#2909)

@yongxu The long term plan is to remove all the mixins, and work on removing style-propable has already started for some of the components. For example, style-propable has been replaced with style utils in DropdownMenu, Divider, and internal stateless TextField components. That being said, this could be an issue to track components that are left. Do you want to compile a list of component that still use the style-propable mixin so we can track it?

@newoga A simple search for style-propable would reveal all the components using it. :grin:
@yongxu Thanks for raising this. We'll keep track of it so we don't forget :+1: :+1:

@alitaheri I know :smile: Just figured it'd be nice to track in this Github issue as well, as since @yongxu opened this, might be nice to see at the top of the issue.

Ohhh you mean a checklist we can track the progress of. I like that idea, yeah that sounds very good :+1: :+1: :+1:

yeah sure thing @newoga
here are the components that currently using style-propable
material-ui\src\app-bar.jsx:

material-ui\src\app-canvas.jsx:

material-ui\src\auto-complete.jsx:

material-ui\src\avatar.jsx:

material-ui\src\badge.jsx:

material-ui\src\before-after-wrapper.jsx:

material-ui\src\buttons\flat-button-label.jsx:

material-ui\src\card\card-actions.jsx:

material-ui\src\card\card-expandable.jsx:

material-ui\src\card\card-header.jsx:

material-ui\src\card\card-media.jsx:

material-ui\src\card\card-text.jsx:

material-ui\src\card\card-title.jsx:

material-ui\src\card\card.jsx:

material-ui\src\checkbox.jsx:

material-ui\src\circular-progress.jsx:

material-ui\src\date-picker\calendar-year.jsx:

material-ui\src\date-picker\calendar.jsx:

material-ui\src\date-picker\date-display.jsx:

material-ui\src\date-picker\date-picker-dialog.jsx:

material-ui\src\date-picker\date-picker.jsx:

material-ui\src\date-picker\day-button.jsx:

material-ui\src\date-picker\year-button.jsx:

material-ui\src\dialog.jsx:

material-ui\src\drop-down-icon.jsx:

material-ui\src\enhanced-button.jsx:

material-ui\src\enhanced-switch.jsx:

material-ui\src\enhanced-textarea.jsx:

material-ui\src\floating-action-button.jsx:

material-ui\src\font-icon.jsx:

material-ui\src\grid-list\grid-list.jsx:

material-ui\src\grid-list\grid-tile.jsx:

material-ui\src\hoc\selectable-enhance.js:

material-ui\src\icon-button.jsx:

material-ui\src\ink-bar.jsx:

material-ui\src\left-nav.jsx:

material-ui\src\linear-progress.jsx:

material-ui\src\lists\list-item.jsx:

material-ui\src\lists\list.jsx:

material-ui\src\menu\link-menu-item.jsx:

material-ui\src\menu\menu-item.jsx:

material-ui\src\menu\menu.jsx:

material-ui\src\menu\subheader-menu-item.jsx:

material-ui\src\menus\icon-menu.jsx:

material-ui\src\menus\menu-item.jsx:

material-ui\src\menus\menu.jsx:

material-ui\src\overlay.jsx:

material-ui\src\paper.jsx:

material-ui\src\popover\popover-animation-from-top.jsx:

material-ui\src\popover\popover-default-animation.jsx:

material-ui\src\popover\popover.jsx:

material-ui\src\radio-button-group.jsx:

material-ui\src\radio-button.jsx:

material-ui\src\raised-button.jsx:

material-ui\src\refresh-indicator.jsx:

material-ui\src\ripples\circle-ripple.jsx:

material-ui\src\ripples\focus-ripple.jsx:

material-ui\src\ripples\touch-ripple.jsx:

material-ui\src\SelectField\SelectField.jsx:

material-ui\src\slider.jsx:

material-ui\src\snackbar.jsx:

material-ui\src\svg-icon.jsx:

material-ui\src\table\table-body.jsx:

material-ui\src\table\table-footer.jsx:

material-ui\src\table\table-header-column.jsx:

material-ui\src\table\table-header.jsx:

material-ui\src\table\table-row-column.jsx:

material-ui\src\table\table-row.jsx:

material-ui\src\table\table.jsx:

material-ui\src\tabs\tab.jsx:

material-ui\src\tabs\tabs.jsx:

material-ui\src\TextField\TextField.jsx:

material-ui\src\time-picker\clock-hours.jsx:

material-ui\src\time-picker\clock-minutes.jsx:

material-ui\src\time-picker\clock-number.jsx:

material-ui\src\time-picker\clock-pointer.jsx:

material-ui\src\time-picker\clock.jsx:

material-ui\src\time-picker\time-display.jsx:

material-ui\src\time-picker\time-picker-dialog.jsx:

material-ui\src\time-picker\time-picker.jsx:

material-ui\src\toggle.jsx:

material-ui\src\toolbar\toolbar-group.jsx:

material-ui\src\toolbar\toolbar-separator.jsx:

material-ui\src\toolbar\toolbar-title.jsx:

material-ui\src\toolbar\toolbar.jsx:

material-ui\src\tooltip.jsx:

material-ui\src\transition-groups\scale-in-child.jsx:

material-ui\src\transition-groups\scale-in.jsx:

material-ui\src\transition-groups\slide-in-child.jsx:

material-ui\src\transition-groups\slide-in.jsx:

material-ui\src\buttons\flat-button-label.jsx

material-ui\src\card\card-actions.jsx

material-ui\src\card\card-expandable.jsx

material-ui\src\card\card-header.jsx

material-ui\src\card\card-media.jsx

material-ui\src\card\card-text.jsx

material-ui\src\card\card-title.jsx

material-ui\src\card\card.jsx

material-ui\src\date-picker\calendar-year.jsx

material-ui\src\date-picker\calendar.jsx

material-ui\src\date-picker\date-display.jsx

material-ui\src\date-picker\date-picker-dialog.jsx

material-ui\src\date-picker\date-picker.jsx

material-ui\src\date-picker\day-button.jsx

material-ui\src\date-picker\year-button.jsx

material-ui\src\grid-list\grid-list.jsx

material-ui\src\grid-list\grid-tile.jsx

material-ui\src\hoc\selectable-enhance.js

material-ui\src\lists\list-item.jsx

material-ui\src\lists\list.jsx

material-ui\src\menu\link-menu-item.jsx

material-ui\src\menu\menu-item.jsx

material-ui\src\menu\menu.jsx

material-ui\src\menu\subheader-menu-item.jsx

material-ui\src\menus\icon-menu.jsx

material-ui\src\menus\menu-item.jsx

material-ui\src\menus\menu.jsx

material-ui\src\popover\popover-animation-from-top.jsx

material-ui\src\popover\popover-default-animation.jsx

material-ui\src\popover\popover.jsx

material-ui\src\ripples\circle-ripple.jsx

material-ui\src\ripples\focus-ripple.jsx

material-ui\src\ripples\touch-ripple.jsx

material-ui\src\SelectField\SelectField.jsx

material-ui\src\table\table-body.jsx

material-ui\src\table\table-footer.jsx

material-ui\src\table\table-header-column.jsx

material-ui\src\table\table-header.jsx

material-ui\src\table\table-row-column.jsx

material-ui\src\table\table-row.jsx

material-ui\src\table\table.jsx

material-ui\src\tabs\tab.jsx

material-ui\src\tabs\tabs.jsx

material-ui\src\TextField\TextField.jsx

material-ui\src\time-picker\clock-hours.jsx

material-ui\src\time-picker\clock-minutes.jsx

material-ui\src\time-picker\clock-number.jsx

material-ui\src\time-picker\clock-pointer.jsx

material-ui\src\time-picker\clock.jsx

material-ui\src\time-picker\time-display.jsx

material-ui\src\time-picker\time-picker-dialog.jsx

material-ui\src\time-picker\time-picker.jsx

material-ui\src\toolbar\toolbar-group.jsx

material-ui\src\toolbar\toolbar-separator.jsx

material-ui\src\toolbar\toolbar-title.jsx

material-ui\src\toolbar\toolbar.jsx

material-ui\src\transition-groups\scale-in-child.jsx

material-ui\src\transition-groups\scale-in.jsx

material-ui\src\transition-groups\slide-in-child.jsx

material-ui\src\transition-groups\slide-in.jsx

there are so many of them, but it is actually very easy to track, just search ./mixins/style-propable you will be able to find all of them

Thanks for the change @alitaheri ! Really like the check list :)

Thank you. Now we can track the progress :grin: :grin:

@yongxu @alitaheri Perfect, thanks much! (Those are a lot :fearful:). I'll make sure to mark my progress here as I remove uses of the mixin. Based on my memory, this mixin was going to be one of the easier ones to remove.

Today I was thinking about the best ways to replace style-propable,  It looks like that styles.js and immutability-helper.js are the main cause that significantly slow down the performance. I am wondering if it is better to remove them completely.
Plus, AutoPrefix is very costly. IMO, We should manually adding default style prefix and leave the user to decide if they'd like to use AutoPrefixer themselves.
Currently, in style-propable,
mergeStyles() {
    return ImmutabilityHelper.merge.apply(this, arguments);
 }

that in immutability-helper,
import update from 'react-addons-update';
function mergeSingle(objA, objB) {
  if (!objA) return objB;
  if (!objB) return objA;
  return update(objA, {$merge: objB});
}

//here is the merge called
  merge() {
    const args = Array.prototype.slice.call(arguments, 0);
    let base = args[0];

    for (let i = 1; i < args.length; i++) {
      if (args[i]) {
        base = mergeSingle(base, args[i]);
      }
    }
    return base;
  },

In most cases, this is totally waste of time.
The following code

  mixins: [
    StylePropable,
  ],

//and somewhere in code, probably many times:
this.merge(defaultStyle, styleFromProps);

is simply equivalent to
{...defaultStyle, ...styleFromProps}

The two other functions mergeAndPrefix() and prepareStyles(muiTheme, ...styles) in style-propable has even worse performance.
mergeAndPrefix() ==> cost of merge() + AutoPrefix.all(mergedStyles)

prepareStyles(muiTheme, ...styles) ==> O(merge + ensureDirection + AutoPrefix.all)

Those two functions are highly used in React render function. I think this might slow down the response time x10~ times. No testing, just my estimate.
There is a quite shocking result I found:
when searching ensureDirection(muiTheme, style), 175 matches across 79 Components for "prepareStyles". Many appears in render function, including most used component such as TextField, Button, Card, Textarea, List... Pretty much all the components. ensureDirection(muiTheme, style) a very costly function, which only used to ensures that style supports both ltr and rtl directions by checking every style element that might be executed hundreds of time every time some part of your page rerender.
In practice, it is not complicated to manage AutoPrefix or left-to-right direction.  We should remove these from the library.

@yongxu I agree that ideally these should be removed entirely. Right now there are discussions about using another library/tool/approach for styling and I think any significant work in this area will probably have to wait until we make that decision. I'm haven't fully considered the short term implications of not using those methods in existing components, but I can't imagine it not being a breaking change. I think we should carefully consider all alternatives before making this switch and try to get it right the first time.

In practice, it is not complicated to manage AutoPrefix or left-to-right direction. We should remove these from the library.

I would like to give users more flexibility in this process, but do you have an ideas how this could work?

@yongxu I couldn't agree more even if I wanted to!  We have a plan for these. first and most importantly we should remove a huge number of lines of code in 0.15.0 so we can move more freely, right now too many things are deprecated. and having them around really ties our hands behind our backs. With those codes removed we can do a whole lot of things. one of them would be memoization of calculated styles, optimization of these functions, using better libraries like Radium and Recompose and a whole lof of things. but with all these old rusty codes around it's really hard.

@newoga IMO, manually adding prefix is more efficient. The idea is actually very simple:
transition: ...

can be rewritten as:
transition: ...
WebkitTransition: ...
msTransition: ...

So we can simply write
this.prepareStyles(styles1, styles2);
/*and*/
this.mergeAndPrefix(styles1, styles2);

as
{...styles1, ...styles2}

@alitaheri Yeah I totally agree with you. IMO, If we are going to remove style-propable, the mixin that deals with style merge, we should write the whole mechanism to make it as efficient as possible. If we simply replace them with the current helper function there won't be much performance improvement and we probably have to rewrite this part again in the future.  It is probably the best time to redesign the style merge and resolve this issue once for all.
Radium is a good library, but also slow. For many basic components such as buttons or text fields, manually adding prefix is the most performance efficient. It is worth to put a little extra time since one site may contain hundreds of these elementary blocks.

Radium is a good library, but also slow. For many basic components such as buttons or text fields, manually adding prefix is the most performance efficient. It is worth to put a little extra time since one site may contain hundreds of these elementary blocks.

I think the slowness is negligible if it happens only once. I mean with memoization we shouldn't worry so much about prefixing. But with manual prefixing there will be many things to worry about, things like maintenance, more things to teach contributes, much harder code review, etc, etc... . I'm always against doing things that external libraries can do better much better myself. @oliviertassinari @newoga Thoughts?

@alitaheri Manual prefixing everything is indeed quite a lot work and much harder code review. I totally agree with you on this. However, memoization may cause internal state. I think the 20-80 rule is probably a good choice here, focus on prefixing the low level components such as Paper, and keeping code clarity for some not so frequently used components like DatePicker.
Paper is probably the most used component, but if you take a look at its render function, there is definitely quite a bit problem here:
  render() {
    const {
      children,
      circle,
      rounded,
      style,
      transitionEnabled,
      zDepth,
      ...other,
    } = this.props;

    const styles = {
      backgroundColor: this.state.muiTheme.paper.backgroundColor,
      transition: transitionEnabled && Transitions.easeOut(),
      boxSizing: 'border-box',
      fontFamily: this.state.muiTheme.rawTheme.fontFamily,
      WebkitTapHighlightColor: 'rgba(0,0,0,0)',
      boxShadow: this._getZDepthShadows(zDepth),
      borderRadius: circle ? '50%' : rounded ? '2px' : '0px',
    };

    return (
      <div {...other} style={this.prepareStyles(styles, style)}>
        {children}
      </div>
    );
  },

Transitions.easeOut() is quite bad, it is simply generating '450ms all 0ms linear' over and over again.
this.prepareStyles(styles, style) is terrible, iterating all the styles, slow merging and check if everything supports both ltr and rtl and then prefixing every element... umm this is definitely a problem.

Manual prefixing everything is indeed quite a lot work and much harder code review

There is also server-side-rendering. without user-agent aware prefixing we'll end up with tons of useless prefixed going down the wire. surely a very new browser will never need any prefix. we'll have to add a huge number of bytes only to supper a very few number of target browsers. Such things can be very easily handled by libraries. Surely they are slow, but we don't need that much performance if we handle the flow right. (with memoization)

memoization may cause internal state.

Why do you say that? I can't imagine how memoization can do this if we handle things right. And handling memoization right is A LOT easier than handling prefixing right. I for one know exactly how to memoize with ease and determinism. But I truly suck at prefixing :cry: :cry:

this.merge(defaultStyle, styleFromProps);
is simply equivalent to
```js
{...defaultStyle, ...styleFromProps}

What's the point?

The two other functions mergeAndPrefix() and prepareStyles(muiTheme, ...styles) in style-propable has even worse performance.

mergeAndPrefix() is deprecated, we are supposed to only use prepareStyles() in the entire code base.

`prepareStyles(muiTheme, ...styles) ==> O(merge + ensureDirection + AutoPrefix.all)``

The ensureDirection work is by passed unless you enable the RTL mode.

ensureDirection(muiTheme, style) a very costly function

I'm not sure about it, but we could use a hash map instead of a switch to improve performances for people how use the RTL option.

Those two functions are highly used in React render function. I think this might slow down the response time x10~ times. No testing, just my estimate.

Yes prepareStyles is highly used in our component. Let's take a look at the DatePicker component that is probably the one how use it the more (each date displayed in the calender is a react component: DayButton).
Here is the result, that seems preaty cheap:

That's also related to https://github.com/callemall/material-ui/issues/2437.

@yongxu @alitaheri @oliviertassinari I have a suggestion that basically sums what was presented in this issue and proposes a next step forward. :smile:
1. Replace style-propable mixin with utility functions
I think we would all agree that these functions do not need to be in a mixin. We have an exported utility library at /utils/style.js that uses pretty much uses the same implementation as the mixin. Removing the use of the mixin will be a step towards transitioning the codebase towards functional components and class based components (and cleaning up the code in general).
The style-propable isn't the only mixin we have to remove, but it probably is the most straight forward to remove. I think this issue would be a great umbrella issue to track the progress of that initiative.
2. Finalize how we should change and use /utils/styles.js moving forward
The /utils/styles.js module currently exports 4 functions:, merge, mergeAndPrefix, ensureDirection, and prepareStyles.
We're not using mergeAndPrefix since its deprecated, so I say remove all uses of it (if any) and simply remove this function from the /utils/styles.js module.
The prepareStyles function can't be removed for backwards compatibility reasons.
I'm not sure if there is any reason why ensureDirection needs to be exported if it's only for prepareStyles, so maybe we can leave this function, but not export it.
That really only only leaves merge. @alitaheri @oliviertassinari, do you think we should continue using this function or should we switch all uses of this to the destructuring syntax?
merge()
3. Move discussions of how to change styling to a different issue
@yongxu I think everyone agrees that the current approach to styling is going to have to change. The problem is that there is still a ton of work to be done in a number of areas before we can tackle it.
Would it be alright if we continued or postponed this discussion of manual AutoPrefixing and direction into a separate issue?

Great sum up @newoga :+1: :+1: I agree on all fronts :grin: Thank you

@alitaheri

memoization may cause internal state.
Yeah you are right, memoization does not necessarily introducing internal state, depends on how the code is handled. Depends on the situation, you either need extra initialization or using react life cycle method. IMO, it is probably not the ideal choice for UI or stateless components.

I'd love to see more ideas and different opinions. No worries your point is not offencive at all. I'd like to see all different opinions even if they are offencive, as long as they are valid. :+1:
@oliviertassinari this.merge(defaultStyle, styleFromProps); is not very costly, but it does run quite a bit unnecessary code. {...defaultStyle, ...styleFromProps} is much more straightforward and clear.

The ensureDirection work is by passed unless you enable the RTL mode.
Your are right on this, sorry I did not see this line if (!muiTheme.isRtl) return style;. However I still think we should remove this extra logic, let user to deal with it.

I also tried to run few components using chrome timeline. The cost were probably not as high as I expected initially, they are still quite costly and should be optimized. Not very familiar with chrome timeline, but I think the point is still valid.

Babel transpile {...defaultStyle, ...styleFromProps} using this utility method:
var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };

It would be intereseting to see how is the performant difference between _extends  and merge.

let user to deal with it

The issue is that I can't see how user can deal with it.

@oliviertassinari merge uses react-addons-update, performance wise it is surely slower and makes code more complicated. There is no reason to import an addon if it is not necessary.
RTL can be dealt by rewriting style, maybe we can put this part of code into theme manager. Checking each style element in every rendering is just too much overhead and not very reasonable.

I'm coming in a bit late on this issue, but have been looking at #2859, and the styling is causing most of the performance issues.  The issue is that this.mergeStyles() returns a different object reference regardless of a change style, which then trigger a re-render on every sub component.  E.g. a SelectField with 2000 items has 6000ms wasted render cycles.
Dropping in the following lists the changing properties.
// remove PureRenderMixin from mixins: []
shouldComponentUpdate(nextProps, nextState, nextContext) {
    const shouldUpdate = PureRenderMixin.shouldComponentUpdate(nextProps, nextState, nextContext);
    /* eslint-disable */
    if (shouldUpdate === true) {
      for (var key in nextProps) {
        if (nextProps[key] !== this.props[key])
          console.log(key, nextProps[key], this.props[key]);
      }
    }
    /* eslint-enable */
    return shouldUpdate;
  },

When I did this on list-item I got (2000 times),
onTouchTap onTouchTap(e) {
        _this._handleMenuItemTouchTap(e, child);
        if (child.props.onTouchTap) child.props.onTouchTap(e);
      } onTouchTap(e) {
        _this._handleMenuItemTouchTap(e, child);
        if (child.props.onTouchTap) child.props.onTouchTap(e);
      }
innerDivStyle Object {paddingLeft: 24, paddingRight: 24, paddingBottom: 0, paddingTop: 0} Object {paddingLeft: 24, paddingRight: 24, paddingBottom: 0, paddingTop: 0}
style Object {color: "rgba(0, 0, 0, 0.87)", lineHeight: "32px", fontSize: 15, whiteSpace: "nowrap"} Object {color: "rgba(0, 0, 0, 0.87)", lineHeight: "32px", fontSize: 15, whiteSpace: "nowrap"}
children [undefined, undefined, undefined] [undefined, undefined, undefined]

For onTouchTap I suspect we'll need some form of memoization, for style and innerDivStyle we're going to need an immutable mergeStyles solution.  For children, I think we're going to need to try and be cleverer, and pass undefined instead of [undefined...].
Also, on the prefixing discussion, I came across this babel module... https://github.com/UXtemple/babel-plugin-react-autoprefix which looks like it could do the work at compile time, rather than build time.  I know this will increase the payload slightly, but as vendor prefixes are very similar, i imagine they'll gzip up quite nicely.

Hey @chrismcv! A lot has been refactored since we left off with this discussion. :)
this.mergeStyles() (and the style-propable mixin) is going away very soon. We're replacing all merging with Object.assign (and will use it in an immutable fashion.. Object.assign({}, ...). The auto-prefixer is configurable (and can even be disabled) and based on profiling I've seen is never the true bottleneck.

The issue is that this.mergeStyles() returns a different object reference regardless of a change style, which then trigger a re-render on every sub component.
Mutating style props in React was deprecated so there's no way around this I thought?

I think you were alluding to this but a lot of performance issues I see are fixed (or dramatically improved) by properly implementing shouldComponentUpdate(). I've experimented and measured it as well. It's on the ROADMAP, but we haven't gotten around to it because we've been focusing on code cleanup and refactoring, deprecating old APIs etc.

Yes - I've noticed much of the progress.  That being said I still think it leaves us with a significant perf issue, we're going to need to make some strides with.

Mutating style props in React was deprecated so there's no way around this I thought?

I meant that the style doesn't mutate, but because we're calling mergeStyles we end up with a different reference - so in my example above, neither style changes, but pure-render-mixin (shallowEquals) decides that they have because its a different reference.  I think we need to come up with a way of this only returning a different object when their is an actual difference, so that a fast pure-render implementation can be used. (This could factor in auto-prefixing as well, if it isn't indeed a bottleneck.)

I think you were alluding to this but a lot of performance issues I see are fixed (or dramatically improved) by properly implementing shouldComponentUpdate(). I've experimented and measured it as well. It's on the ROADMAP, but we haven't gotten around to it because we've been focusing on code cleanup and refactoring, deprecating old APIs etc

In my example, list-item is using PureRenderMixin, which I think is a "proper" implementation, but because of the mutating style objects, it is ineffective.  Perhaps we can come up with a better implementation, but shallowEquals seems like the best target to me, and we should try to design our style generation around this.  I'm still pondering how...

That being said I still think it leaves us with a significant perf issue, we're going to need to make some strides with.

Yup, I agree, most of the refactoring thus far weren't primarily for performance but for code cleanup (however it is likely faster, just not in areas that contribute to the majority of the time).

I meant that the style doesn't mutate, but because we're calling mergeStyles we end up with a different reference - so in my example above, neither style changes, but pure-render-mixin (shallowEquals) decides that they have because its a different reference.

Okay I understand what you're saying now and I agree!
Based on my understanding, using something like Immutable.js, the reference wouldn't change if the computed style is the same. Though I think we were trying to avoid adding that as a dependency to this project.
I'm still pondering too and open to any ideas!

That's pretty awesome :rocket:. @newoga Good job!

Sorry to comment on a closed ticket, but it seems previous devs on our app used the internal material-ui versions of style-propable mixin  in our own code, and now that material-ui has removed it, our code now breaks and I need to figure out how to remove the coupling in our code. Any suggestions?

@bytor99999 I'm sorry to hear that. There are a handful approaches to tackling a migration like this and it probably all depends on how large your codebase is, how coupled you are to the mixin (including which methods you are using), and how much manual effort you are willing to invest.
The old mixin implementation is here: https://github.com/callemall/material-ui/blob/v0.14.4/src/mixins/style-propable.js
You could probably reimplement the mixin in your local project and change all the import paths from material-ui to your new local module. That would probably be the least impact on your current code, however that being said, your larger goal should probably be to move away from mixins entirely as the React community is moving away from it.
To see how this project moved away from the mixin, you can look at any of our closed PRs that show how we did it for each component: https://github.com/callemall/material-ui/pulls?q=is%3Apr+style-propable+is%3Aclosed. Rather than blindly following the same approach we took, you may want to consider changing your code to not use material-ui at all for style-propable related functionality. If my memory is correct, the mixin before was pretty much for auto-prefixing and merging objects, all which can be done by importing other packages yourself.
If you have a really large codebase, my feedback would be to:

Slowly migrate your code away from the mixins before you update to a version of material-ui that didn't include it.
Optionally consider scripting parts of the migration using a tool like https://github.com/facebook/jscodeshift

Good luck!


Go uprobes attachment fails for go 1.20.4 and later

@vihangm tried to upgrade our go version to 1.20.4 (from 1.20.2) in #1266. After investigating this more, I determined that our go version detection fails for these newer binaries and prevents stirling from attaching uprobes to the application. Detecting an application's go version is necessary because applications built with go 1.18 and later must be handled different with our uprobes (source).
In addition to the go 1.20.4 issues, we recently discovered the same go version detection logic also doesn't handle 32 bit binaries properly (#1300). The go cli provides a mechanism for reading the go version of an application and its implementation is very different from what we currently do. We are proceeding with a go 1.20.4 specific fix to unblock #1266, but we need to rehaul our version detection to be more similar to Go's implementation so we can fix #1300 and issues with newer binaries.

This was fixed in #1605.


Invalid --pull-secret

$ az aro create   --resource-group $RESOURCEGROUP   --name $CLUSTER   --vnet aro-vnet   --master-subnet master-subnet   --worker-subnet worker-subnet --worker-count 3 --pull-secret @pullsecret.txt
Invalid --pull-secret.
always return "Invalid --pull-secret."

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

ID: 93aa980e-1970-235c-228a-7b19880171b8
Version Independent ID: 6f7937a4-12e0-d61c-3bd8-c6347ec48385
Content: Tutorial - Create an Azure Red Hat OpenShift 4 cluster
Content Source: articles/openshift/tutorial-create-cluster.md
Service: azure-redhat-openshift
GitHub Login: @sakthi-vetrivel
Microsoft Alias: suvetriv

@fionaaws2018 Thanks for the feedback. We are investigating the issue and will update you shortly.

Hi @fionaaws2018, thanks for reaching out. Usually the secret is stored under pull-secret.txt under the openshift-config namespace. Are you sure it will be pullsecret.txt and not pull-secret.txt with a '-' in between?

Hi @fionaaws2018 , thanks for the update. Glad it got resolved.


A couple of  links for you

https://bitbucket.org/frank_niemeyer/nativeinterop
https://github.com/alexandrnikitin/MPMCQueue.NET

@jcoder58 thank you for your contribution! I just added the links to the main page.


Add Iter::sum() and Iter::product()

Replaces #36
Depends on:

[ ] #325

we are in favor of simple code e.g,  x.to_iter().fold(init=0, fn {x,y=> x+y}), thanks for your contributions


cancel auto-renew loans

Hi, great bot!
If it possible to cancel auto loans using your bot, if not, how hard is it to modify it?

Ok, I added new function and wrote small batch script
a = bot.returnActiveLoans()
for key, value in a.iteritems():
    if key == "provided":
        for i in value:
          if i["autoRenew"] == 1:
           	print bot.toggleAutoRenew(i["id"])


Minor: Do what clippy says and clean up some code

Which issue does this PR close?
N/A
Rationale for this change
clippy says it is infallible, which it is
So make it so and remove some ?
What changes are included in this PR?
Fix  a clippy lint
Are there any user-facing changes?
No

I can't find this ability of clippy in doc, Can I ask how to use it?

I can't find this ability of clippy in doc, Can I ask how to use it?

I am not sure what you mean
In this case I found that someone had left a "#allow" command in the code (which ignores something clippy would normally flag a a warning). I removed the "allow" and then updated the code so clippy passed.

In this case I found that someone had left a "#allow" command in the code (which ignores something clippy would normally flag a a warning). I removed the "allow" and then updated the code so clippy passed.

😂


Error when pressing start.

Whenever I press start I get this error any clue why?

I have the same problem

Are you converting a non-standard replay ? if yes, osr2mp4 only supports standard mode


Lack Of Versioning Is An Issue

What version of Go are you using (go version)?
1.11.3
Which database and its version are you using?
PostgreSQL 10.6
Issue
The lack of versioning for Gorm is some what of an issue for using it within other projects, and for a library as updated as this, which receives many fixes, potentially even breaking changes, having no way of determining, and fixing what version of the code-base is in use, is an issue, and will occur at some point in time.
For example, in between the version 1.9.2 and now, a major bugfix that fixed data races was merged into the codebase.Not having this library being versioned, means that to now receive this bugfix, one must pull the code in from master. For dependency management, this creates an issue over the longrun and will lead to pulling in unexpected changes, causing unexpected results. This can extend to pulling in breaking changes, when that isn't the desired outcome. Ultimately this leads to greater difficulties when using this library.
This is an easy fix, and does not require modifying any code, it just requires regularly publishing new releases. This saves developers a lot of headache, and dependency management problems and should be something that is a must for a project as popular as GORM as it makes package maintainers, and package users have a much more streamlined experience.

Thanks @postables. From now on we will regularly publish new semver releases.
v1.9.3 was just released.


Compatibility with Thai API

This PR breaks compatibility with European and Australian (and probably Indian) API endpoints. If everything is working fine for the Thai API, we need to add new ASN.1 Entitys just for Thai and use them depending on the API endpoint. But for now we just want to get it working.


Position of Sorter and Filter from table header looks odd.

Version
1.8.0
Environment
macOS, Safari
Reproduction link
https://stackblitz.com/edit/angular-4dfruj
Steps to reproduce
https://ng.ant.design/components/table/en
What is expected?
The icon sits closely to the left label.
What is actually happening?
The icon sits far from the label and close to next label, looks like it belongs to the label on its right side.  It is even more confusing especially when the table is wide.
Other?

Ant Design specifies this. See https://ant.design/components/table/#components-table-demo-head.


White background If the screen height is bigger than the maximum height that we set

White background If the screen height is bigger than the maximum height that we set :

Is there any code I can check to reproduce or screen-record?


feat: Add simple cli tool

This adds a simple cli tool which enables users to easily make requests
using their specified server address and protocol.
The response will be returned as pretty json for both human and machine
consumption.

retrigger


Uniform dockerfiles and add options to shrink binary size

Description
This PR:

Replaces the per-component dockerfiles with a single one parametrized, to reduce code duplication, ensure consistency and simplify maintenance.
Add the -s and -w linker flags to shrink the resulting binary sizes. See this blog post for more context. BTW, Kubernetes also applies these flags when compiling their binaries: https://github.com/kubernetes/kubernetes/blob/1861e4756df1818a2d4ca60c869780bf742fff6b/hack/lib/golang.sh#L798-L804.
From a couple of initial tests:

Virtual kubelet: 69.2MB -> 52.1MB
Uninstaller: 46.$MB -> 36.1MB

Removes a legacy script which appears to me unused (let me know if I am wrong).

Fixes #(issue)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[ ] Checking the existing E2E tests succeeded.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
15 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.03%) to 50.102%

Files with Coverage Reduction
New Missed Lines
%

pkg/identityManager/certificateIdentityProvider.go
2
71.43%

internal/resource-request-operator/resourceRequest_controller.go
3
68.18%

internal/resource-request-operator/resourceRequest_controller_methods.go
3
90.0%

internal/auth-service/auth-token.go
7
57.35%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
9872

Relevant Lines:
19704

💛  - Coveralls

/hold

/unhold
The E2E test seems green


Updates

Hi @Seun-Ajayi x @theyorubayesian  ,
I have some questions and some updates;
why are we hard coding the pages here? is it possible to get all the pages for a particular language?
            "https://www.voaswahili.com/z/4658/?p={}",
            "https://www.voaswahili.com/z/4657/?p={}",
            "https://www.voaswahili.com/z/4660/?p={}",
            "https://www.voaswahili.com/z/4768/?p={}",
            "https://www.voaswahili.com/z/4659/?p={}",
            "https://www.voaswahili.com/z/2774/?p={}",
            "https://www.voaswahili.com/z/2775/?p={}",
            "https://www.voaswahili.com/z/2783/?p={}",
        ]

@Seun-Ajayi , can you extend the class to use firefox driver too? so maybe the user can select the browser they want?
@Seun-Ajayi , can we take out some of the inline comments and just leave the class comments?

@Seun-Ajayi  please checkout a new branch before attending to these.


Make it easer to detect rate limit errors

The GitHub API returns rate limit information in HTTP response headers for every request.
It might be useful if the GitHub client (optionally) inspected those values and proactively avoided hitting rate limits by blocking a subsequent request until it thinks it will have quota, then checking that it does indeed have quota, before making the request.
This would probably be prohibitively hard to get right 100% of the time, but as long as it left some slush quota in case of race conditions, it could be really useful for clients to automatically obey their rate limit without having to design for it.

As discussed in #153, automatically throttling the application is not the right behavior for this library.  However, we could make it a little easier for applications to detect rate limit errors (basically a 403 response with zero rate.Remaining) so they can respond appropriately.

As discussed in #153, automatically throttling the application is not the right behavior for this library. However, we could make it a little easier for applications to detect rate limit errors (basically a 403 response with zero rate.Remaining) so they can respond appropriately.

Agreed.

As you mention, the key is just leaving some wiggle room in case of race conditions.

Now that #255 has been done, this should be very doable.

You want to take a stab at this?

I'll take this. PR soon.
It'll be 2 PRs. First one just to add a new error type for rate limit exceeded situations and returning it when appropriate. The second PR will be an optimization (with no change to library behavior) to avoid doing unnecessary networking calls when it's known that the rate limit has been exhausted and not enough time has yet passed for it to be reset.


Docs: Missing PR template

Is your feature request related to a problem? Please describe.
The project does not have a PR template
Describe the solution you'd like
A good PR template needs to be added for making Pull requests easier for everyone.
Additional context
I would love to add a PR template if the issue is assigned to me

New feature means if any additional functionality one can add like getting weather through geo location ,etc ,Currently the data is fetched using city name.
I agree PR template is required, so go for it !

New feature means if any additional functionality one can add like getting weather through geo location ,etc ,Currently the data is fetched using city name.

thank you for clarifying


Error: Cannot find module

Describe the bug
// A clear and concise description of what the bug is.
nodejs = v16.0.0
The environment is configured according to https://hummingbot.org/gateway/installation/#run-setup-script and this error is reported when entering a command: $ yarn start --passphrase=xxxxxx. How to solve it?
Screenshots
// If applicable, add screenshots to help explain your problem.

Release version
// Include your bot's version number (Can be found at the upper left corner of your CLI).
v1.25.0
Attachments
// It is important that you attach the required files for us to be able to investigate the issue.
// Please attach the chain.yml file from your gateway "conf" folder, e.g ethereum.yml
don't have conf file
WARNING: Do NOT publish any exchange API keys or your wallet's private key. Whoever has access to them may steal your assets!
Optional: your discord username:
Sorry, I'm new to this

Hi @cxfshelter thanks for reporting this issue, please try node version v18 or higher. Our team will update the docs 🙇🏼

Hi @cxfshelter thanks for reporting this issue, please try node version v18 or higher. Our team will update the docs 🙇🏼

ok, thanks


::execute should try to call #execute if no block passed

There are possible another ways to hold it, e.g. accept a symbol (or proc) instead of block

Could you separate the actual execution of combined query from the process of its building. Sometimes it would be very useful to just get the relation as is for further modifications. Sometimes the query should be invoked immediately. So I do hope that you will add following features. I see this as returning the actual scope after all. So there is no need to call anything at the end of query building process.

They are separated.
You can call Class.new(params).<%= any method you define to execute it %> and get the execution result. But i can add instance versions of with and execute if you want to. And probably remove class method execute (but not with)


Conditional types cast never[] | {} as {}

cc @ahejlsberg
TypeScript Version:  2.7.0-dev.20180406

Search Terms:
Code
type Eq<T, U> = T extends U ? U extends T ? true : false : false;
type a = Eq<{}, never[] | {}>;

Expected behavior:
a is boolean.
Actual behavior:
a is true.
Playground Link:
Related Issues:

never[] | {} is the same as {} as far as the type system is concerned.

never[] | {} will be surely distributed to {} and never[]
type Split<T> = T extends never ? never : [T];
type a = Split<never[] | {}>; // [{}] | [never[]]

So never[] and {} must be evaluated individually, and its result is correctly false and true. Type compatibility is misdirection here.
type SplitEq<T> = T extends never ? never : [T, Eq<{}, T>];
type b = SplitEq<never[] | {}>; // [{}, ture] | [never[], false]

Eq<{}, never[] | {}> must be resolved as follows under the spec. It returns boolean correctly.
type c
  = ({} extends {} ? {} extends {} ? true : false : false)
  | (never[] extends {} ? {} extends never[] ? true : false : false); // boolean

So Eq<{}, never[] | {}> is boolean.

Given [T, U] as [{}, never[] | {}], the result of T extends U is true, and the result of U extends T is true (because every type except null and undefined extends `{}).

@ahejlsberg You mean Eq<{}, never[] | {}> won't be resolved as follows? Why?
type c
  = ({} extends {} ? {} extends {} ? true : false : false)
  | (never[] extends {} ? {} extends never[] ? true : false : false); // boolean

Not correct, WIP.

I realized my previous resolution is wrong. Eq<{}, never[] | {}> will be resolved as follows. This result is actually true. I need to distribute U at first.
type c = {} extends {} | never[] ? ({} extends {} ? true : false) | (never[] extends {} ? true : false) : false; // true


Update README about AWS IAM policy

This PR adds some explanation regarding needed permissions on AWS IAM policy to README.md

@all-contributors please add evalphobia for documentation


⚠ Bofrost.com has degraded performance

In bf63c92, Bofrost.com (https://www.bofrost.com) experienced degraded performance:

HTTP code: 200
Response time: 1026 ms

Resolved: Bofrost.com performance has improved in 31b6c36 after 9 minutes.


Initial implementation of lambda expressions

Add lambda syntax to parser: x -> x for functions and x => x for operations.
Add basic type inference. Some things could be improved later, like inferring lambda characteristics.
Add a new diagnostic for when unification would imply an infinite type.
As part of supporting lambdas that accept unit as a parameter, () -> x, empty tuple patterns are also supported elsewhere, like let () = X(q);.

👀👀👀


[BUG 0.10.2]customChild‘s child's initState func will run three times

Describe the bug
the initState fun of child widget will run three times when jump to PhotoViewGallery.builder page,
To Reproduce
just try
What is the current behavior?
Expected behavior
initState just run one time
Screenshots
If applicable, add screenshots to help explain your problem.

Is this a feature or report a bug?
bug
**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. The output of flutter doctor can help too. **
What is the expected behavior?
Which versions of Flutter/Photo View, and which browser / OS are affected by this issue? Did this work in previous versions of Photo View?
Additional context
Add any other context about the problem here.

I try to fix by above, it successed


Bigboard requirement not documented

This plugin/theme (rightfully) introduces a Bigboard button to the menu bar.
Until this plugin is not installed, this will lead to an error.
Also Bigboard is not maintained anymore and needs help https://github.com/stinnux/kanboard-bigboard/issues/20.

Bigboard is not required anymore. Thank you for contributing and I hope you like the new version better. Have a nice day!


Digits only truly clear from textfield after TWO restarts

Hi there,
nice package, good work :D I've ran into a small problem though.
Package version
I first tried package version 0.5.2+2 ,but then i thought the issue might have been fixed in the "develop" branch, so i specified it in pubspec.yaml file like this, but this issue occurs in both of them.

  intl_phone_number_input:
    git:
      url: https://github.com/natintosh/intl_phone_number_input.git
      ref: develop

Flutter version
Your current version of the Flutter SDK [e.g. 1.22.5]
To Reproduce
Steps to reproduce the behavior:

Simply use the exact example from: https://github.com/natintosh/intl_phone_number_input/blob/develop/example/lib/main.dart

Copy the examle into your fresh flutter project (main.dart)

run the app on Android emulator (in my case Pixel 4).
Leave this line as it is in the example for now: PhoneNumber number = PhoneNumber(isoCode: 'NG');
So the initial country is Nigeria, alpha2 code is 'NG' and dial code is +234.

Click into the text field and type in for example 555, don't click anything else, do not close keyboard etc. and simply click on the RESTART icon in Visual studio code. App restarts, text field seems to be clear, but when you click into it again (focus), somehow the number you have entered before the restart  (555) is automatically inserted back in. If you RESTART the app again (without adding or removing any numbers from the text field), then it is truly cleared out. Basically you have to RESTART the app twice each time for the text field to be cleared.

** Targeted platforms (please complete the following information):**
Android
best regards!

Oh yeah, this a Flutter thing. I have also experienced it in some of my projects including this too. You can follow up for more info here. https://github.com/flutter/flutter/issues/42409


revert: docs(reactive): 添加reactive笔记

Please DO NOT abuse pull requests. Do experiments in your own repo. Thanks.


nucleo-144:f767-netnsh  no debug output

Hi, guys , I am test a nucleo-f767zi board, initialize  with  tools/configure.sh  nucleo-144:f767-netnsh, and enabled all of debug options , but not have any debug info output.  I hope someone who can fixed problem , Thanks.
~$ grep "DEBUG" .config
# CONFIG_ARCH_DEBUG_H is not set
CONFIG_DEBUG_ALERT=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_ERROR=y
CONFIG_DEBUG_WARN=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_ASSERTIONS=y
# CONFIG_DEBUG_BINFMT is not set
# CONFIG_DEBUG_CRYPTO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_GRAPHICS is not set
# CONFIG_DEBUG_LIB is not set
CONFIG_DEBUG_MM=y
CONFIG_DEBUG_MM_ERROR=y
# CONFIG_DEBUG_MM_WARN is not set
# CONFIG_DEBUG_MM_INFO is not set
# CONFIG_DEBUG_NET is not set
# CONFIG_DEBUG_POWER is not set
# CONFIG_DEBUG_SCHED is not set
CONFIG_DEBUG_IRQ=y
# CONFIG_DEBUG_IRQ_ERROR is not set
# CONFIG_DEBUG_IRQ_WARN is not set
# CONFIG_DEBUG_IRQ_INFO is not set
# CONFIG_DEBUG_LEDS is not set
# CONFIG_DEBUG_GPIO is not set
# CONFIG_DEBUG_MEMCARD is not set
CONFIG_DEBUG_SPI=y
CONFIG_DEBUG_SPI_ERROR=y
CONFIG_DEBUG_SPI_WARN=y
CONFIG_DEBUG_SPI_INFO=y
# CONFIG_DEBUG_TIMER is not set
CONFIG_DEBUG_SYMBOLS=y
# CONFIG_DEBUG_NOOPT is not set
# CONFIG_DEBUG_CUSTOMOPT is not set
CONFIG_DEBUG_FULLOPT=y
CONFIG_ARCH_HAVE_HARDFAULT_DEBUG=y
CONFIG_DEBUG_HARDFAULT_ALERT=y
CONFIG_DEBUG_HARDFAULT_INFO=y
CONFIG_ARCH_HAVE_MEMFAULT_DEBUG=y
# CONFIG_DEBUG_MEMFAULT is not set
# CONFIG_NETDEV_PHY_DEBUG is not set
# CONFIG_NET_TCP_WRBUFFER_DEBUG is not set
# CONFIG_NET_UDP_WRBUFFER_DEBUG is not set
# CONFIG_IOB_DEBUG is not set
# CONFIG_NETINIT_DEBUG is not set

If I remember on this board with the configuration the link has to be up for it to get to the shell. Do you have ethernet cable plugged in? You are likely not seeing any debug info because you do not have the network debug flags turned on.

If I remember on this board with the configuration the link has to be up for it to get to the shell. Do you have ethernet cable plugged in? You are likely not seeing any debug info because you do not have the network debug flags turned on.

Hi, Yes, I did have ethernet cache plugged in. and I got a nsh shell from the ttyACM0:
NuttShell (NSH) NuttX-9.1.0
nsh>
nsh>
nsh> uname -a
NuttX stntest 9.1.0 5bb4eb39f2-dirty Sep 28 2020 18:33:47 arm nucleo-144
nsh> ifconfig
eth0    Link encap:Ethernet HWaddr 96:0f:40:c2:b0:45 at UP
        inet addr:<IP_ADDRESS> DRaddr:<IP_ADDRESS> Mask:<IP_ADDRESS>
        inet6 addr: 2409:8a55:2416:2500:940f:40ff:fec2:b045/64
        inet6 DRaddr: fe80::2276:93ff:fe00:ac08/64

lo      Link encap:Local Loopback at UP
        inet addr:<IP_ADDRESS> DRaddr:<IP_ADDRESS> Mask:<IP_ADDRESS>
        inet6 addr: ::1/128
        inet6 DRaddr: ::1/128

             IPv4  IPv6   TCP   UDP  ICMP  ICMPv6
Received     0000  0004  0000  0000  0000  0001
Dropped      0000  0003  0000  0000  0000  0000
  IPv4        VHL: 0000   Frg: 0000
  IPv6        VHL: 0000
  Checksum   0000  ----  0000  0000  ----  ----
  TCP         ACK: 0000   SYN: 0000
              RST: 0000  0000
  Type       0000  0000  ----  ----  0000  0000
Sent         0000  0006  0000  0000  0000  0006
  Rexmit     ----  ----  0000  ----  ----  ----
nsh>

The following I tried that turn on the network debug flag or disabled network ,also still not  seeing any debug info from the nsh shell.

Sorry, the debug everything is fine, this is my mistake to configured.


Required to have id present on items passed to TableBody but not documented

🙋 Documentation Request
Hi, I'm trying to build some table components in Typescript. It seems that for rendering dynamic collections, I need to include an id on the items prop assed to <TableBody>. This is not described explicitly in the docs. I expected it to be around here: https://react-spectrum.adobe.com/react-aria/useTable.html#dynamic-collections.
I also figure that the generic on TableBody should be something like
export let TableBody: <T extends { id: number | string, }>(props: TableBodyProps<T>) => JSX.Element;

To make sure that Id is passed. Not passing Ids lead to a runtime crash, so this would be very nice to catch in the types instead.
🧢 Joachim from Climaider

Just to clarify, it isn't specifically that an id is required but more that you need a unique key. We link to those docs in the state management section of useTable, but we certainly can make that callout more clear. Open to any types updates to catch this as well, probably should be on all our collection components if possible.

Hmm, not sure we can make type updates because it isn't required on the object itself. You can also set a key prop on the <Row>.
<TableBody items={rows}>
  {(item) => <Row key={item.name}>{(columnKey) => <Cell>{item[columnKey]}</Cell>}</Row>}
</TableBody>

Example

Just to clarify, it isn't specifically that an id is required but more that you need a unique key. We link to those docs in the state management section of useTable, but we certainly can make that callout more clear. Open to any types updates to catch this as well, probably should be on all our collection components if possible.

I see now! I guess I'm used to ignoring linters shouting at me for missing keys and never figured that this could be an issue causing the crash. I think adding this warning on "dynamic content" sections would make it a lot more beginner friendly.

Hmm, not sure we can make type updates because it isn't required on the object itself. You can also set a key prop on the <Row>.
<TableBody items={rows}>
  {(item) => <Row key={item.name}>{(columnKey) => <Cell>{item[columnKey]}</Cell>}</Row>}
</TableBody>

Example

I see. I think I'm still a little confused.
Which components actually need a key/id? In the above the <Cell> component manages without one? I guess the problem is that if you enforced a requirement of key (or id) on <Cell> this would worsen ergonomics in the non-dynamic case as we would then not just depend on whatever React does for generating the key?
I think I can work around this by overriding types on my components which are then based on React-aria primitives.


support for redis 3.2?

I wonder if supporting higher versions of redis is on the roadmap? it'd be awesome to see the new features introduced by redis 3.2.

Redis 3.2 provides some good features and supporting them may be just adding some new items to command table. But actually there is no 3.2 in our production environment and I think supporting 3.2 needs further tests. We are trying new redis version in progress but we will not support it very soon.

Is this just about newly introduced commands in 3.2?
The Cluster API should be fairly stable between 3.0 and 3.2 (I didn't check whether the output of CLUSTER NODES changed, I will do so tomorrow)

Yes, it's all about the new commands.
As long as the CLUSTER NODES, ASK(ING), MOVED are not changed, corvus should be able to work with redis 3.2.

CLUSTER NODES is the same in 3.0 and 3.2 so corvus should be able to work with Redis 3.2 without problems

So CLUSTER NODES is the same in 3.0 and 3.2, but it changed in unstable (it appends @<busport>.
In order to be forwards-compatible corvus could already add a check for that or switch to the more stable CLUSTER SLOTS API instead.

In fact we used CLUSTER SLOTS before #64 . The problem is after the large clusters scale up and down for several times, the slot ranges will be broken into small pieces and the response of CLUSTER SLOTS can be large and cause performance problem.

Can I assume that corvus v0.2.7 supports Redis 3.2? The release notes mention that Redis 4 is supported. Just wondering why this issue is still open? Thanks.

@joshweir corvus v0.2.7 is just compatible with Redis 3.2 and 4, but still doesn't support new commands of them.
Sorry for the misleading release notes. I will update it.

@doyoubi It's no problem. Thanks for the clarification.


stripe: accept 1-year subscriptions as valid

Description
Fixes https://github.com/dust-tt/tasks/issues/932
Risk
N/A
Deploy Plan

deploy front

PMRR

Thanks 🙏🏻


L.TileLayer.MVTSource could request tiles with invalide x an y

I have a local vector tile server based on tilesplash and use L.TileLayer.MVTSource to load the vector tile layer at the client side:
var map = L.map('map').setView([0, 0], 2);

var layer = new L.TileLayer.MVTSource({
    url: 'http://localhost:3000/my_layer/{z}/{x}/{y}.mvt'
})

map.addLayer(layer);

I notice that the L.TileLayer.MVTSource could send request with invalid x and y parameter:

x or y smaller than 0

http://localhost:3000/my_layer/2/-1/1.mvt

x or y larger than the available number based on the zoom level

http://localhost:3000/my_layer/2/4/2.mvt

Is it a bug, or just because of incorrect layer config?

I am experiencing the same problem.


Flip countdown

Hi Hilios,
How can I do the Flip countdown that showing on top of http://hilios.github.io/jQuery.countdown/ website?

Duplicated #164


add pinot upsert features to pinot common

This diff will create necessary pinot schema/constant value changes to support pinot upsert features.
The following will be changed:

add updateSchematic field to schema and table definition:
this value can be either "upsert" or "append". When it is "upsert" pinot server/broker will apply proper upsert logic to ensure that table is updating based on primary key.  a few notes:

I am planning to simplify this config to be a boolean value, but due to several of our tables are already using this config, I will need to spend some time to configure out a way to migrate this properly.
Currently, both schema & table requires this config to ensure that when we create table/schema they will have easy way to check if they are for upsert and ensure proper checks are enforced.

add primary key config:
this value will point to one of the column in this table as the primary key of this upsert table. Only matter if the table is for upsert

add offset key config:
this value will point to one of the column in this table to store the offset of this table. Only matter if the table is for upsert

design doc for pinot upsert feature:
https://cwiki.apache.org/confluence/display/PINOT/[Proposal]+Pinot+upsert+design+doc
this change focus on the sc
schema related changes are listed near top of the design doc

Codecov Report

Merging #5175 into master will decrease coverage by 0.42%.
The diff coverage is 27.77%.

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

Can you please link the design doc in the pr description so that it is easier to understand the concept of upsert?
Since this pr is touching the core configs, we need to spend some time discussing how to design the config keys because they are very hard to change in the future

Linked the design doc in the description. also google doc design doc with comments. We have discussed this a long time back but I definitely open to go through it again as things have already changed. Do you think we should do some remote meeting sync or something else?

One concern here would be that the update related configuration appears in multiple places. One thing that can simplify this PR is to add a UpdateConfig under TableConfig and move everything under that. That allows you to mark that config as beta/unstable and iterate quickly

updatesemantic (or the new name)
primarykey
offsetkey

also google doc design doc with comments.

It's asking uber login. Can you change share settings?

also google doc design doc with comments.

It's asking uber login. Can you change share settings?

remote meeting sync or something else

@kishoreg At least monthly meeting and sync up on project status will be helpful to all...

Yeah our google doc account sharing setting is kind of wanky that it doesn't allow blanket share with everyone outside our organization.  However, just submit a request to view/comment and I can add you as soon as I see it.
We originally plan to have a meeting earlier this month but the pandemic kind of mess up with all of our plans. Maybe we can have a work-group specific remote meeting (eg, upsert meeting with kishore/jackie/chethan etc) in the meantime and do the pinot committee meeting later
@Jackie-Jiang @kishoreg @ChethanUK let me know if you feel meeting is necessary or you prefer me to update the schema first and see if a remote meeting is necessary

@kishoreg @mcvsubbu I have updated the diff per suggestion you guys gave in the last meeting, please feel free to take a look
@Jackie-Jiang I have updated the diff to make sure #1: it is only related table config changes required by pinot upsert feature (see doc for details) and #2 push other pinot-common related changes for pinot upsert features to later PRs

@mcvsubbu @Jackie-Jiang updated per your feedback and make the config to be used only if the table is for upsert and clean up on naming, please take a look when you have time

hi @mcvsubbu we have updated the pr following the comments. Appreciate if you can take a look to see if anything else you feel we need to update further

minor comments, other than that, lgtm thanks

merged the comments diff, thanks for checking on those details. Do you think any further changes you want? It would be great if you can change your review status from requesting-changes so I can start merging it in

@jamesyfshao I am good with this PR, thanks.


Views are being labeled as models on hover

Bug description
Hovering over userInfo in typescript describes it as a model despite it being a view.

How to reproduce
https://github.com/Druue/prisma-debug/tree/uat/views
Expected behavior
It should be labeled as a view
Prisma information
Schema
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["views"]
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id      Int      @id @default(autoincrement())
  email   String   @unique
  name    String?
  profile Profile?
}

model Profile {
  id     Int    @id @default(autoincrement())
  bio    String
  userId Int    @unique
  user   User   @relation(fields: [userId], references: [id])
}

view UserInfo {
  id    Int    @unique
  email String
  name  String
  bio   String
}

Code
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient({
  log: ["query"],
});

// you can do middlewares on
// prisma.$use

const populate = async () => {
  if (await prisma.user.count() === 0) {
    await prisma.user.create({
      data: {
        email: "email",
        name: "name",
      }
    })
  }

  if (await prisma.profile.count() === 0) {
    const u = await prisma.user.findFirst();

    await prisma.profile.create({
      data: {
        userId: u.id,
        bio: "bio",
      }
    })
  }
};

async function test() {
  const first = await prisma.userInfo.findFirst()
  console.log(first);

  const many = await prisma.userInfo.findMany({
    where: {
      name: 'name'
    }
  })
  console.log(many[0])
}

async function main() {
  await populate();
  // console.log(process.env.DATABASE_URL);
  return test();
}

main()
  .catch((e) => console.error(e))
  .finally(async () => {
    prisma.$disconnect;
  });

Environment & setup

OS: MacOS
Database: PostgreSQL
Node.js version: 14.21.2

Prisma Version
prisma                  : 4.10.0-dev.80
@prisma/client          : 4.10.0-integration-unblock-ci.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine 9bde8bbe3bc34fa749e3cf03285929cd9c4e078a (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 9bde8bbe3bc34fa749e3cf03285929cd9c4e078a (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.10.0-74.9bde8bbe3bc34fa749e3cf03285929cd9c4e078a
Default Engines Hash    : 9bde8bbe3bc34fa749e3cf03285929cd9c4e078a
Studio                  : 0.481.0
Preview Features        : views

This is rather bad as when introspecting DMMF you cannot distinguish between models and views. The DMMF at the model/view object level does not include a database schema attribute either, so that rules out distinguishing them based on physically separate database schemas. The only way to distinguish between views and models either becomes naming conventions for views, or parsing the raw Prisma schema and trying to correlate with the emitted DMMF for a given object.


False positive with NSMutableDictionary and CoreFoundation bridging?

We are using SFHFKeychainUtils in our project and analyzing our code with Infer, I get the following error
error: MEMORY_LEAK
memory dynamically allocated to searchData by call to alloc() at line 464, column 37 is not reachable after line 468, column 3

for these lines:
291 NSMutableDictionary *searchData = [NSMutableDictionary new];
292 [searchData setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id)kSecClass];
293 [searchData setObject:serviceName forKey:(__bridge id)kSecAttrService];

295 OSStatus status = SecItemDelete((__bridge CFDictionaryRef)searchData);

I'm thinking this might be a false positive or am I overlooking something? Thanks in advance for looking into it.

Hi @lumaxis, thanks for your report. From the small snippet it's not immediately obvious what's wrong, we'll look into it.
PS: It seems that the project you linked to is gone (404 here).

Hey @jvillard, thanks for looking into this! After being online for 3 years, the project out of all days was removed now ... weird.
I updated the links in my original post to point to the part of our code where we use SFHFKeychainUtils, hope that helps debugging.

This is almost 5 years old now, probably not relevant anymore 🙂

@lumaxis as it happens, I'm currently writing a new version of this check with improved bridging. Do you still use Infer for Objective-C at all?

Hah, amazing timing 🙂
Actually, I've personally moved on from iOS/Objective-C entirely and am not involved in that ecosystem at all anymore.

Feel free to reopen this though if it's helpful for others!


400 error comes through in reportState res

If an otherwise fine data push to a sensorState via the smarthome reportState has a missing parameter, like agentUserId, then promise from reportState will still resolve and the resolved variable will contain a descriptive 400 error.
This is contra to the docs which claim that getting into the res statement of the promise is equivalent to a successful push.

This is fixed in the library in version 2.6.0.


Next delegation integration tests => next delegation unit tests

Issue Number
Follow up to #1361
Overview

afeee24084c3c417e1ee285a8ba3196c4e15da55
I have reorganized a bit integration tests for "stake pool active/next" groupping them into 5 scenarios:

STAKE_POOL_NEXT_01 - Can join/re-join another/quit stake pool
STAKE_POOL_NEXT_02 - Join 2 sp in the same epoch => delegating to the
last one in the end
STAKE_POOL_NEXT_02 - Join and quit in the same epoch =>
not_delegating in the end
STAKE_POOL_NEXT_03 - Join 2 in two subsequent epochs => delegating to
1st in epoch X + 2 and 2nd in epoch X + 3
STAKE_POOL_NEXT_03 - Join and quit in two subsequent epochs =>
delegating in epoch X + 2, not_delegating in epoch X + 3

3241e1ff51020fccf07e5c23bd5f260d7b1bf8bc
Further tests for join/quit active/next

Comments
Additional integration tests for #1342 after changes made in #1361. The tests are somewhat comprehensive but at the same time they take ~9minutes, which made CI to timeout before...
The idea would be to turn some of them into unit tests...

bors try

not afraid of CI timeouts here (in the light of the number of tests added)? When adding intial tests it managed to bite me painfully?

Closing in favor of #1392.


Kliento or ContractKit

I am building an indexer for Celo and was wondering which client is better ContractKit or kliento?
Can I use the same Celo Core Contracts on both clients or other has better support than other?
Also, I want to be able to query our archive nodes by height so I need to have ability to query contract data by height.
Thanks!

@silentlight ContractKit is the primary client for building on top of Celo. Kliento is a subset of ContractKit, so Kliento will have less capabilities. For the majority of projects, we recommend using ContractKit.

Thank you so much for the response @barbaraliau.
I am a little concerned about per height queries. For instance GoldToken contract has balanceOf method. I see that in Kliento it is possible to pass height to it but I don't really see that option in ContractKit. Am I missing something?

ContractKit does not support height specific queries and always uses latest.
This is because of the more stringent node requirements; namely, archive mode and pruning disabled to support these types of queries.
We could look into adding support for this in ContractKit if widely desired.
You can also check out the eksportisto or blockscout tools.

Thanks @yorhodes. Any idea how much it would take to add support for height specific queries?


Update to 3.1.2

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Virtualbox vagrant support changes

There are 4 issues addressed:

10.7 does not boot on the existing cpuidset. The cpuidset has been changed for 10.7 to identify as an earlier CPU (C2D) than the existing one.
The templates built into vagrant virtualbox boxes are broken because "{{.Name}}" was not expanded. This is replaced with :id instead.
Specifying a false value for UPDATE is ignored because the comparison in the shell script does not work as intended. This is replaced with the same expression present in the debian/ubuntu update shell script.
Installing the xcode CLI tools on 10.7 does not work because the installer fails from a verification failure. An extra option is provided to allow it to bypass the verification check, but it is assumed that the source is trustworthy.

There are some caveats with 10.7:

Giving a 10.7 box more than 1 CPU when using Vagrant on the packer built box may cause a kernel panic in the power management module.
10.7's software update installer may not accept the new option when installing the xcode CLI tools if updates are disabled depending on the version of the 10.7 InstallESD used.

If these caveats should be put in a README, please identify which one.
Finally, VMWare was not available for testing. Testing occurred in Virtualbox 4.3.22 only.

Anything else to be done for this PR to be accepted for merge?


GTA VC - Tommy in the wrong seat

In the intro when the ambush took place, Tommy jumps in the back of the car, but in gameplay he spawns in the front seat, I fixed it in main SCM by editing :INTRO_11983 from
set_player_coordinates $player_char at 86.428 -852.238 9.325
to 80.996 -852.123 9.325

Script issue, so out of scope. It's also fixed in https://github.com/Sergeanur/SCFIX-Miami.


Anyone used TensorRT with this repo?

Hi,
anyone tried using TRT with this repo?
If yes, how much speed increase did it give?

@AnaRhisT94 Have you tried？


multimodal genre prediction

multi_modal_genre_prediction
Новый скрипт для задачи мультимодальной классификации жанров
multi_modal_pipeline_genres
Скрипт для генерации пайплайна на базе multi_modal_pipeline
text_preprocessing
Добавил lower case в предобработку
data
Добавил генерацию таргета для multilabel output

Hello @andreygetmanov! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file cases/multi_modal_genre_prediction.py:

Line 3:121: E501 line too long (138 > 120 characters)
Line 11:1: E265 block comment should start with '# '
Line 13:1: E302 expected 2 blank lines, found 1
Line 53:5: E265 block comment should start with '# '
Line 62:5: E265 block comment should start with '# '
Line 63:5: E265 block comment should start with '# '
Line 67:5: E303 too many blank lines (2)

In the file examples/multi_modal_pipeline_genres.py:

Line 4:1: E265 block comment should start with '# '
Line 23:19: E127 continuation line over-indented for visual indent
Line 31:5: E265 block comment should start with '# '
Line 55:5: E303 too many blank lines (6)
Line 70:37: E128 continuation line under-indented for visual indent
Line 71:37: E128 continuation line under-indented for visual indent
Line 72:37: E128 continuation line under-indented for visual indent
Line 73:5: E265 block comment should start with '# '
Line 75:5: E265 block comment should start with '# '
Line 91:5: E265 block comment should start with '# '
Line 92:5: E265 block comment should start with '# '
Line 93:5: E265 block comment should start with '# '
Line 100:5: E265 block comment should start with '# '
Line 102:5: E265 block comment should start with '# '
Line 103:81: E261 at least two spaces before inline comment
Line 103:82: E262 inline comment should start with '# '
Line 104:5: E265 block comment should start with '# '
Line 109:9: E265 block comment should start with '# '
Line 114:9: E265 block comment should start with '# '
Line 129:69: E128 continuation line under-indented for visual indent
Line 130:69: E128 continuation line under-indented for visual indent
Line 131:69: E128 continuation line under-indented for visual indent


I need a hand to install the extension in colab

Hello i'm user https://colab.research.google.com/github/TheLastBen/fast-stable diffusion/blob/main/fast_stable_diffusion_AUTOMATIC1111.ipynb
And I get this message

Error loading script: tag_autocomplete_helper.py
Traceback (most recent call last):
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/scripts.py", line 170, in load_scripts
exec(compiled, module.dict)
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions/tagcomplete/scripts/tag_autocomplete_helper.py", line 77, in
write_tag_base_path()
File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions/tagcomplete/scripts/tag_autocomplete_helper.py", line 63, in write_tag_base_path
f.write(TAGS_PATH.relative_to(FILE_DIR).as_posix())
File "/usr/lib/python3.7/pathlib.py", line 900, in relative_to
.format(str(self), str(formatted)))
ValueError: '/content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions/tagcomplete/tags' does not start with '/content/gdrive/MyDrive/sd/stable-diffusion'
how can it work?

Have a look at this, it worked for another user recently:
https://github.com/TheLastBen/fast-stable-diffusion/issues/409#issuecomment-1304741272

in the last cell, change
with capture.capture_output() as cap:
  %cd /content/gdrive/MyDrive/sd/stable-diffusion-webui

to
with capture.capture_output() as cap:
  %cd /content/gdrive/MyDrive/sd/stable-diffusion

let me know if it works so I'll revert the pull request

Thank you, now working

The new fix for me seems to be
with capture.capture_output() as cap:
  %cd /content/gdrive/MyDrive/sd/stable-diffusion-webui

For https://colab.research.google.com/github/TheLastBen/fast-stable-diffusion/blob/main/fast_stable_diffusion_AUTOMATIC1111.ipynb

But I don't understand why there are two folders and why it start in one and not the other were extensions are installed. I'm not sure if this is an actual fix, probably going to ask in automatic1111 repo.


[Mobile] Add super resolution sample android app with ort-extensions support for ppp

[Mobile] Add super resolution sample android app with ort-extensions support for ppp

Basic functionality super resolution android app based on updated pt_superresolution.onnx model
To demonstrate the sample usage of ort api and ort-android/ort-extensions-mobile android aar package usage.

README.md is coming.

I have downloaded and run this app in Android Studio

can we add this example to the CI pipeline? ok if it's in another PR

can we add this example to the CI pipeline? ok if it's in another PR

thanks for the reminder. will do in a separate pr as well as for the ios one.


Client set name and version on connection

Closes #1338

@tillkruss Adding a fix for Relay connection, leads to an error in CI
https://github.com/predis/predis/actions/runs/5678238422/job/15388057449?pr=1347
Trying to run Relay tests locally, but have a problems with relay installation over homebrew.
Error: An exception occurred within a child process:   MachO::DylibUnknownError: No such dylib name: /usr/local/lib/libhiredis_ssl.dylib.1.1.0
This file actually exists and I have correct version of hiredis

Aah, maybe Relay is already setting CLIENT SET-NAME is causing the issue.

Trying to run Relay tests locally, but have a problems with relay installation over homebrew.
Error: An exception occurred within a child process: MachO::DylibUnknownError: No such dylib name: /usr/local/lib/libhiredis_ssl.dylib.1.1.0

Relay via Homebrew uses OpenSSL v3, can you try brew uninstall relay and reinstall it?

coverage: 77.719% (+0.04%) from 77.682% when pulling 15de538b0d11433b92ab4951f5007da4867f1386 on vladvildanov:vv-client-set-info-on-connect into df14e11c3a047217a16ad2430c1587a583c2268c on predis:v2.x.

In this PR add 2 commands on initialization, that's a lot of IO. It should at least be an option IMO. We saw an important load increase in production due to this PR.
Why was it bundled in a patch version?

We saw an important load increase in production due to this PR.

Can you elaborate on this and provide numbers?

We didn't have "client" call before

And here you can see the substantial change in CPU in the cluster:

it took us a while to find the culprit because we didn't expect to have a change in behavior in a patch version

@tillkruss I talked about this with other client-developers and they confirm that this should be an optional.
We can't fix it other way since it's a Redis API and we must call it twice each time. Let's merge #1370, but before we need to merge #1369 that fixes CI after Redis 7.2 update

Thank you for your feedback and thanks for helping fixing it.
Don't you think that this PR should be reverted for the next patch release (to revert the issue introduced) and the new feature (with the new set_client_info defaulting to false to not have BC) should be in a new minor version?

@BafS Totally works for me, but @tillkruss is the releases responsible person


Implement alternate layout for large screen

What it means? Like the tablet layout as samsung uses?

Yes

Is is visible on the sample app?

this is still OPEN, so still to do.


Don’t use unicode.IsDigit in tgerr

Can you please create new internal ascii package with ascii.IsDigit function and tests for it?
I want to keep semantics and maintainability.