[Bug] Docs arrows for dropdown UI malfunctioning

Bug Report
Describe the bug
Something funky going on with the dropdown arrows and generally the UI here

Will be released in #112


CAD-2839 Workbench fixes

prebuild executables explicitly
work around a Nix linker purity issue due to NIX_ENFORCE_PURITY in shellHook
automatically deal with state-cluster being partially built, while it's safely default

bors r+


Add new api endpoint for getting ohshown-event-type list resource

Why

To define the ohshown-event-type resource in one place. (Part of issue https://github.com/tai271828/disfactory-backend/issues/15).

What

Define the ohshown-event-type resource in BE and add an api endpoint for FE to get it.

How

Port the ohshown-event-type list resource from src/types.ts in the FE project to the BE project and add a GET api for it.

Test

Check the new api endpoint [{host}](http://<IP_ADDRESS>:8888)/api/resources/ohshown-event-type worked well locally. (The swagger page http://<IP_ADDRESS>:8888/swagger/)

Thanks for the quick implementation. @Neilxx you may want to pay attention on this API change.

@yanghaochang104 fyi, you may want to pay attention on this API change.


Idea: a DOM node can contain contexts, and subnodes can get them by unique reference

I was looking at
https://github.com/skatejs/skatejs/blob/6d9fd2c1f6380ee1497e4286fe627660175e80d0/packages/skatejs/src/with-context.js#L10-L14
It looks like a sub-context can block one that is higher up. So if I stick a node in the middle of the tree with a context, it'll prevent a leaf node from getting a context from the top of the tree.
What does React do?
What if we change set context so that contexts inherit:
    set context(context: Object): void {
      if (!this._context)
        this._context = Object.create(this.context);

      Object.assign(this._context, context); // naive copy, could be better
    }

This reminds me of $scope in Angular 1, which inherit from parent scopes.
The problem with this would be that, if we re-parent a node that has a context to another parent, the inheritance of the context would still be based on the old location which might not make sense. To solve this we could use connected/disconnected callbacks to change the prototype of the moved node's context.

I'd prefer to stick closer to what React would do here. They don't inherit, but the way they expose the provider / consumer API, it allows you to wrap them to inherit if you want:
<Consumer>
  {value => (
    <Provider value={{...value, something: 'else' }}>{children}</Provider>
  )}
</Consumer>

I'm wondering if we can change our context implementation to behave more like this? One drawback of using the DOM like this is that updates to context don't trigger updates to subscribers. It'd be neat if we could do this.

I've been looking into how implement context for webcomponents and found the following approaches:

skatejs, that is simple implementation but has drawback, as pointed by OP, of child contexts overriding completely parent ones
wc-context by blikblum (me) that implements a sort of inheritance where child contexts only overrides the properties it exports. Currently the context properties are exported declaratively by a contextRequests hash, but i'm considering changing for a childContext / setChildContext approach
wc-context by askbeka that uses a custom element to hold the context trying to mimic the new React API

Each one have pros and cons.
All in all, IMO there's not a design that is good enough, so in any case, keeping the current implementation or changing it, i think the context mixin should be opt-in, i.e., not included in withComponent

All in all, IMO there's not a design that is good enough, so in any case, keeping the current implementation or changing it, i think the context mixin should be opt-in, i.e., not included in withComponent

The idea behind withComponent is you have to think less about what you do want, which hardly has any perf implications. Context doesn't trigger unless you access it. For 99% of the use cases, it's what you'll use.

If you mixin another context implementation (withContext(withComponent())) it will override. The two choices:

Keep withComponent
Remove withComponent

Number 1 for convenience, with the caveat that it includes everything. That should be pretty well documented. Is there a downside to keeping it? I'd prefer to keep it at all-or-nothing as the heuristic to decide what goes into withComponent might be hard to define.

The advantage of React's JSX is that it's all virtual markup, so the <Consumer> and <Provider> "elements" don't actually appear in the DOM.
If we made equivalent <sk-provider> and <sk-consumer> elements, they could interfere with layout/rendering, selectors, and other things. We'd have to come up with another way to specify the equivalent of consumer/provider, probably be via JS instead of markup.
Personally, I like the prototype inheritance approach. It's simple to use. However it's not explicit so it can make debugging more difficult, f.e. when trying to find why some context variable doesn't exist and from which context it should come from.
At the moment, implementing the prototype approach is very simple, so that's a pro in contrast to the previous con. (funny: pro skater vs con artist, both of your libs).

What could a provider/consumer API look like if it were JS based?
import {withComponent} from 'skate'
import Foo from './Foo'

export default
class App extends withComponent() {

  // any component can define one or more contexts
  static get provide() { return {
    someState: {
      someProp: 'foo',
      someAction(val) { this.someProp = val },
    },
    theme: {
      color: 'red',
    },
  }}

  render() { return

      {/* ... render components, they can use contexts ... */}
      <Foo />
      <Bar />

  }
}

customElements.define('the-app', App)

import {withComponent} from 'skate'

export default
class Foo extends withComponent() {
  // specify which contexts to use. Error if they are not available when the element is connected.
  static get consume() { return [ 'someState', 'theme' ] }
  someMethod() {
    console.log(this.context.someState.foo)
    console.log(this.context.theme.color)
  }
}

class Bar extends withComponent() {
  // use only one of the contexts
  static get consume() { return [ 'theme' ] }
  someMethod() {
    console.log(this.context.theme.color)
  }
}

class Bar extends withComponent() {
  // error when connected
  static get consume() { return [ 'blah' ] }
  someMethod() {
    console.log(this.context.blah.blah) // error too
  }
}

That's just an idea.
As for the underlying implementation of that, maybe then contexts don't inherit (unless their creator makes them have their own prototype chain), and each context is a separate property on context. Maybe context would be renamed to contexts then.
It could be possible, then, for intermediary elements to override a context by name. But then it would also be possible for intermediary elements to accidentally clash unintentionally with a context of the same name as a parent's.

Ah, to avoid the naming problems, here's an idea:
import App from './App'
class Bar extends withComponent() {

  static get consume() { return [ App.theme ] }

  someMethod() {
    console.log(this.context.[App.theme].color)
  }

}

where reference equality wins, even if components have contexts of the same name. It's a little more verbose though, and introduces the possibility for circular dependencies which might cause other problems.
What's another way we can differentiate by reference?

I gave this some thought over the weekend.

The prototype idea means that elements further down in the tree can accidentally override/clash with properties from higher up in the tree, so this is just as bad as the named context idea.
I like that most other mixins besides withContext don't rely on a DOM API, they are just logic bits that can be called from the outside. This makes it easy to have my element-behaviors implementation call the same lifecycle methods on any behavior classes that have the same methods and use the SkateJS mixins. This is nice!
The current withContext depends on a tree structure existing. It uses node.parentNode to traverse up the tree.

What if, instead of relying on the DOM tree structure to find contexts, it is tree agnostic, so that any elements that want to use it just get it (maybe import it) and use it by reference.
A context might not be a mixin in this case, but rather it would be some state container that is aware of SkateJS APIs. Custom elements might use a withContext mixin to apply certain wiring, but the context itself would be outside the tree.
Usage might look like this:
// import a context that extends from or adheres to some SkateJS Context interface or requirements
import someContext from './path/to/some/context'

import {withComponent} from 'skatejs'

class MyElement extends withComponent() {
  static get contexts() { return [ someContext ] }

  someMethod() {
    // triggers an update of all components using the context.
    someContext.someProp = "hello"
  }
}

Behind the scenes, Skate elements are hooked to a context by specifying them with the static contexts array getter. They can list any number of contexts there, by reference. This will cause the element's withUpdate functionality to be triggered (and thus re-render) whenever context state changes.
So, for example, if anything in someContext changes, then, the element will simply re-render and use the context by reference:
  renderCallback() {
    return

      The value is: {someContext.someProp}

  }

The usage is simple! They are effectively similar to EventEmitters that can be passed around arbitrarily without the requirement of a tree existing, except that they are aware of SkateJS API so they will trigger updates when/if withUpdate is being used.
If withUpdate is not being used, contexts might also have an API to observe them from any non-Skate code. It might look like this:
import someContext from './path/to/some/context'

// observe whenever the context state changes
someContext.observe(() => {
  console.log( someContext.someProp )
})

// maybe observe only specific props
someContext.observe('someProp', () => {
  console.log( someContext.someProp )
})
someContext.observe(['otherProp', 'anotherProp'], () => {
  console.log( someContext.otherProp, someContext.anotherProp )
})

The implementation of withContext mixin might use context.observe on each context to hook an element's updates to the contexts.
As far as what it might look like when defining a context, maybe it's something simple like how it is to define props on a Vue component:
// ./path/to/some/context.js
import {createContext} from 'skatejs'

export default createContext({
  someProp: 'initialValue',
  otherProp: 'foo',
  anotherProp: 'bar',
})

where createContext automatically handles setting up a getter/setter for each prop with initial values, and provides the observe API that withContext would use.
If one isn't using withUpdate, then there's no need to use withContext either, as they can just use observe directly.
Updates would be async/deferred to a microtask, so that setting many props doesn't cause many updates.
The fact that this approach would not depend on the DOM tree means that it would be very easy to hook my element-behaviors into it. :D
Thoughts on something like this?

Interestingly, if we were to make something like that previous non-tree context idea, and if it had the observe mechanism for observing specific props, then components could subscribe to certain props (in some way similar to Redux):
class MyElement extends withComponent() {
  static get contexts() { return {
    // listen just to the `foo` prop
    someContext: [ 'foo' ]
  } }

  renderCallback() {
    return
The value: {someContext.foo}

  }
}

I kind of like this direction, because of being decoupled from the tree, and because it is simple to use and explicit (in some way similar to Redux, but leaner without actions and reducers, which someone could add on top of this idea later).
Another thing that could be possible are nested contexts. If a prop of one context contains another context, then
class MyElement extends withComponent() {
  static get contexts() { return {
    // access with prop path
    someContext: [ 'nestedContext.other.prop' ]
  } }

  // ...
}

That could be useful for libs that have separate contexts that act as grouping of related data.
But I'm thinking too far ahead now. I'm curious to know what think about something like this.

Doh, I meant for the static contexts getter to have a reference to the context, so maybe it'd be something like
  static get contexts() { return [
    [ someContext, 'foo' ]
  ] }

Alright, I made a PR showing the idea: https://github.com/skatejs/skatejs/pull/1461

they could interfere with layout/rendering, selectors, and other thing

Unfortunately, this is the nature of the DOM. That said, providing components for context would be the idiomatic way to accomplish this. It also means that context gets updated when things are re-rendered, solving the problem of context updating via imperative means.
You could probably leverage `display: contents (see also: https://css-tricks.com/get-ready-for-display-contents/) in the context components to remove them from the CSS / A11y tree.

At first glance, @trusktr implementation is interesting since is closer how React declares the context, although differs how to consume or update, but it has a fundamental drawback: it's a singleton, not allowing to have different contexts in the application.
For me is clear that will not be possible to match the new React API with web components, so any implementation will have some sort of compromise be how is declared, consumed or updated

it has a fundamental drawback: it's a singleton

I was sleeping on that thought too. I am pondering how it might be possible to have one per component. I have an idea that still uses references to avoid name collisions or property overriding. I'll be back...

I recommend trying the component method (<x-provider /> / <x-consumer />); this is the closest you could get. The styling issue is solvable (see comment above).

The styling issue is solvable (see comment above).

Yeah I know, but I just wanted to explore the possibilities of doing it in JS. Plus it looks like display: contents isn't available in Edge yet (how long will it take?).
I made a new PR (on top of my previous PR to make it easier to read the diff): https://github.com/skatejs/skatejs/pull/1462
Notes:

Now the contexts are per component, and (grand)children can access them, like before.
Intermediary components do not override contexts unless they provide the same contexts.
A component can provide any number of contexts.
A (grand)child can consume any number of contexts.
Contexts are accessed by reference using the context class.
This avoids the naming collisions that can happen if we use <x-provide> and <x-consume>, because references can not be passed via HTML, only JS.

Something that came to mind: it could be possible to make my second PR implementation fall back to the no-parent-require singleton approach when there's no common Skate ancestor between Skate subtrees and a context needs to be shared between them all.

An example of this need could be a library of 3rd party components, where the library author can expect there to be any number of subtrees made using the custom elements, and they could be anywhere in the DOM, and need to share a common piece of state from the library and take advantage of it's auto-updating feature.
Here's some sample HTML, where <x-scene> and <x-sphere> are the library elements, in two subtrees, but they perhaps want to share a context without requiring a common ancestor:

foo

  <x-scene>
    <x-sphere></x-sphere>
  </x-scene>

bar

  <x-scene>
    <x-sphere></x-sphere>
  </x-scene>

An alternative to the non-tree singleton would be to remove all the body's children, place a new root Skate element (with the context) in the body, then place the body's previous children into the new root Skate element (but I like to avoid that sort of hacking, in order to avoid breaking other code that might rely on the previous structure). Plus, the user should need to think about it, it's just library stuff:

 </x-library-context>

foo

  <x-scene>
    <x-sphere></x-sphere>
  </x-scene>

bar

  <x-scene>
    <x-sphere></x-sphere>
  </x-scene>

 </x-library-context>

Now we have an element in the tree that the end user of the x- library doesn't even care about.
And then, they could make a mistake like this:

foo

 <x-library-context>

  <x-scene>
    <x-sphere></x-sphere>
  </x-scene>

 </x-library-context>

bar

 <x-library-context>

  <x-scene>
    <x-sphere></x-sphere>
  </x-scene>

 </x-library-context>

So now in this imaginary situation there are two contexts when the library author meant there to be one, otherwise there may be unexpected results. The user may have missed that one line in the hypothetical library x docs.

We could use React contexts in the skate-react renderer, and have the Skate elements pass them between the DOM layers, and that would make them unique by reference, but then that would require renderer-specific implementation.
It might be good to do that anyways, and would be powerful for people who choose the skate-react renderer to make porting to Skate super easy. That's a whole 'nother PR.
Is there some way to avoid string-naming conflicts using the <x-provide>/<x-consume> approach?

I imagine the implementation doing something like:

https://github.com/askbeka/wc-context/blob/master/create-context.js
Look at this implementation.
It export a provider constructor and a consumer mixin

@treshugart
So, if I have a component who's markup is

  <x-provider context="some-context">
    <consumer-component></consumer-component>
  </x-provider>

Then the markup of consumer-component is

  <x-consume context="some-context">

    <rainbow-text>hello there</rainbow-text>

  <x-consume>

For sake of example, suppose that rainbow-text uses this.props.rainbowHue
from the some-context context.
Then later, someone updates the consumer-component to introduce some cool new
feature:

  <rotate-effect>

    <x-consume context="some-context">

      <rainbow-text>hello there</rainbow-text>

    <x-consume>

  </rotate-effect>

Okay, now suppose for the sake of example, that <rotate-effect> is a React
component that renders a Skate element that provides another context called
some-context, so the final output looks like this:

  <x-provide context="some-context">
  <div style={`transform: rotateY( ${this.props.yRotation} )`}>

    <x-consume context="some-context">

      <rainbow-text>hello there</rainbow-text>

    <x-consume>

  </x-provide>

Then what happens? Or would the DOM structure be declared a different way?
It seems to me that if we had only an <x-provider> element, then a component
could traverse upward and check all x-provider elements that have a context
with matching name, until it finds one that also has a matching reference to the
same context constructor. In this case, there'd be no need for <x-consume>.
Because, if <x-consume> is above (or even inside of) <rainbow-text>, how
does the link happen?
In React, it takes advantage of the unique references to pass unique props into
something similar to a render callback (obtained from this.props.children
inside of <Consumer>), so React always has a clear reference-based path that
is always unique without ambiguity.
No matter how I imagine doing it with <x-provide> and <x-consume>, the
implementation seems to be too complex, and touching many DOM APIs (f.e.
compared to my second PR which touches only parentNode which is easy to mock).
The benefits of not relying heavily on the DOM (f.e. making whole-new custom
elements) is the much higher flexibility.
With my approach, any objects (not just DOM nodes) can can create, pass around,
and listen to a context with the .observe API with no DOM requirement.
.parentNode is the only DOM API to mock, which makes it easy get it working
with my element-behaviors
implementation.
More Q's

How would you imagine the element markup to look like when using <x-provide>/<x-consume>, and how would the wiring work exactly?
What benefit would it have other than contexts being apparent to the reader when they look at markup?

@blikblum
Comparing my PR to askbeka/wc-context:

My implementation makes no extra elements, no interference with DOM structure, no interference with CSS selectors. Some custom element libraries may rely on certain DOM structure. For example, look at this A-Frame demo: https://jsfiddle.net/trusktr/1ecfha5h. Now, see that the demo breaks when I insert a
 element in the middle even though it has display: contents: https://jsfiddle.net/trusktr/1ecfha5h/224/. By having the JS-only approach with no <x-provider>/<x-consumer>-like elements, we avoid those problems.
With wc-context, intermediary provider elements override any contexts that are higher up in the tree if the intermediary providers have the contexts of the same name as the ones higher up, so the overriding-context problem exists with wc-context. That problem doesn't exist in my version.
wc-context providers are static: you can't move the provider element. My idea is not static, just move any provider or consumer node around to mix and match them any time you want. As long as you put nodes under the right ancestors where contexts are available for the consumers, it will work. If you place a consumer somewhere where a provider is not available, a helpful error is thrown (we could add a link to documentation from there).
wc-context updates the consumer if anything in the whole context changes. Imagine a big app, with a big context, and many components subscribed to it: if the context changes, all components will be updated even if they only use a small subset of the props. With my idea, only components subscribed to specific changed props are updated.
with wc-context, what do we do with _onContextChange? wc-context uses it in the example to implement the subscription wiring that otherwise the functionality in my PR already gives you. If you're only using the withContext mixin of my PR and not any other Skate mixins, you still get automatic subscription wiring. Add the other Skate mixins and you get automatic update/render callbacks when contexts update.

@treshugart @blikblum What are downsides, from your perspective, around the idea of my second PR? Be harsh! I would like to see if I can solve any issues you might see with this design. :)

@blikblum Can you show a basic usage example of your wc-contexts?

@trusktr
The code in my wc-context repository is generic for any custom-element, and not created the binding to skatejs but the usage of current interaction would be:
const Component = withComponent(myWithContext())

// producer:
class Producer extends Component {
  static childContext = {
    store: function () {return this.store},
    theme: 'blue'
  }
}

class SecondProducer extends Component {
  static childContext = {
    theme: 'green'
  }
}

//consumer
class Consumer extends Component {
  connectedCallback () {
      super.connectedCallback()
      this.model = this.context.store.getModel()
  }
  render() {
     return
Current theme: {this.context.theme}

  }
}

Assuming Producer is parent of SecondProducer which is parent of Consumer.
In Consumer, context.theme will be resolved to 'green' from SecondProducer but store will be resolved from Producer
In this design, if a context changes in parent, the children that listen to context will not be rerendered so i'm looking into a new design that would allow this

With wc-context, intermediary provider elements override any contexts that are higher up in the tree if the intermediary providers have the contexts of the same name as the ones higher up

This is the expected behavior, including in React. The problem with the current implementation of skatejs context is that overrides the context completely even with different context keys  / properties, e.g., is not possible to have a context that provides a theme and, in a different level, another one that provides a store

I don't think CSS selectors interfering is a valid argument. If you render a DOM node, you expect it to be there. Much of the time you're also dealing with shadow roots, so you're dealing with atomic trees with selectors which makes things much simpler to reason about.
I like the idea that a provider updates and then a consumer fires an event / function. I've messed around with this idea a bit today: https://codesandbox.io/s/r0vjwmm2mp. The only difference to React is making it more DOM'ish, for better or worse, so it uses events to communicate changes as opposed to a child function. This could be abstracted behind a DSL or library.

The problem with the current implementation of skatejs context is that overrides the context completely even with different context keys / properties

That's the same problem with askbeka/wc-context. Or did I miss why not?

CSS selectors interfering

That's only one possibility. I didn't think deeply about it, but I'm sure there's more. display:contents doesn't prevent my above A-Frame fiddle from breaking.

If you render a DOM node, you expect it to be there

Sometimes a 3rd party is the one that makes the selectors.  I've experienced this sort of thing recently.

Much of the time you're also dealing with shadow roots, so you're dealing with atomic trees with selectors which makes things much simpler to reason about

True. This reduces the chance of the problem happening, but the chance is still above zero.

That's the same problem with askbeka/wc-context. Or did I miss why not?

with askbeka/wc-context is possible to have providers from different contexts in different levels in the same dom tree and a consumer, child of both, can access data from both providers. In the current implementation the same consumer cannot consume both at same time but is doable implementing it.
If there are two providers from same context in the same dom tree, the child overrides the parent.
I've made an example, for reference, based on the one from https://medium.com/dailyjs/reacts--new-context-api-70c9fe01596b , that demonstrates the behavior of React context.:

It's possible to have more than one provider of the same context, each one with its independent value
If two providers of same context are nested, the child overrides the parent
If there are one provider nested to a provider of different context it does not overrides the parent

https://codesandbox.io/s/2zyx8lqnx0

I just read this article on old vs new contexts in React, and wanted to compare my impl:

Mine is similar to React's old contexts in the sense of using static props. Not a biggie, it's just syntax.
More importantly, mine uses references like the new React contexts, not strings like the old contexts. I avoided markup syntax because HTML doesn't support references like JSX does.
Mine is able to update components only when specific props change. In contrast, React's new contexts take a single value, so if anything in the React context is updated, a new object needs to be made, and all components need to update. With mine, new objects don't need to be created, only values changed, and only specific components will be updated before shouldUpdate even comes into play (if we're using withUpdate).
The new-style ToggleContext implementation is easier to read because it works well with references in JSX. As much as I like the declarative context idea, I hesitate doing it in HTML, because strings. I haven't thought of a way to avoid increasing the chance of name collisions. The class-static approach increases the chance by zero.

I updated my demo and cleaned up app.js just a bit: https://codepen.io/trusktr/project/editor/XbEOMk
IMO, the usage it clean. Any ideas on alternatives that also don't increase the surface area for string-naming conflicts?

On top of already having to name custom elements, extra name-clashing exists now.

Not really sure what you mean. The consumer comes up with names for these. This is how custom elements work, for better or worse.

Any code querying the DOM can get a reference to the x-provider or x-consumer elements and listen to the change events and do strange things besides accessing potentially meant-to-be-encapsulated data.

That's how the DOM works. I don't think this is necessarily a bad thing. This can be done for any component in the DOM.

How do you consume multiple providers? It seems like it could get a little messy.

The same way it works in react: child providers override parent providers. To mix and match context, you have to compose together a consumer and provider and call a render prop with the mixed value.

I'm having a hard time parsing the different stuff together in this thread, but I'll try to summarize what I'm envisioning for the future context API. Essentially I want to mirror the React API as closely as possible.

Simple. A single value. Consumers and providers can be composed for more advanced situations.
Declarative: you use consumers and providers as components.
Decoupled from any specific component. In your example, your consumers require, specifically Time in order to work. A consumer can't provide context for Time without using the Time component, but even then they can't customize it because Time provides it internally. Decoupling these means that the consumer is used somewhere in the tree, and anyone can provide context as long as they have the corresponding provider.

In terms of display: contents, I think this is specific to the elements a-frame uses and how it renders stuff (it might read children). This shows it working for flexbox: https://codesandbox.io/s/3q52pr96mq. See also the effect it has on unusual elements.

This is how i implemented in my context library:
A dedicated provider element can be declared as
class TitleProvider extends Component {
  static props = {
    value: String
  }

  childContext = {
    title: fromProp('value')
  }

  render() {
    return html`<slot/>`
  }
}

I'm considering to move the childContext declaration to a static property
Examples
https://codesandbox.io/s/xj1k8x936w
https://codesandbox.io/s/82q46lo3x8

I'm having a hard time parsing all the activity in this thread

I had a lot more to write, but I tried to keep it short. 😆  In person or video calls would be a lot better. @treshugart @blikblum Are you both open to meeting over a video call on a weekend? I'm in Oakland, near SF, California.

The consumer comes up with names for these.

A third-party web component can come up with the name too, which may be out of the app dev's immediate control.
Thought exercise: suppose we make an app. Then we import a 3rd party context, give it a name, and use it. Then, we import a 4th party component that also uses the same 3rd party context, but gives it a different name.
Now how do we ensure the contexts override each other if they have different names (without forking the 4th party component)?
This is one of the problems React avoids by moving to reference-only contexts.
Naming contexts as elements is almost the same as naming them with strings in React's old contexts.
Maybe I'm being too purist, wanting 0% extra chance of naming complication? References let us refer to contexts uniquely.
Faithfully mimicking React's JSX patterns in the DOM might not always be ideal.

Personally I don't get much benefit from declaring contexts in HTML declaratively, as opposed to writing static members or some other JS construct.
React has the unique position in that JSX is JavaScript, so reference-passing naturally allows some interesting possibilities for writing declaratively with references. But declaring with static members is simple too.

Any code querying the DOM can get a reference to the x-provider or x-consumer elements and listen to the change events and do strange things besides accessing potentially meant-to-be-encapsulated data.
That's how the DOM works. I don't think this is necessarily a bad thing.

For regular elements, yeah, it's normal.
These context elements are different: they don't have any rendering implication at all, they are simply data containers.
Having declarative data containers was not a common pattern before JSX. If I'm making data containers, I'm happy to make JS objects and pass them around. The new declarative data containers associated by reference in React are an accidental side-effect of the existence of JSX (but they're still just data containers passed by reference association).

child providers override parent providers

This works great in JSX, 100% clash free. The DOM approach doesn't feel as clean.
A static-member approach might be ever-so-slightly less convenient to write, but it behaves as purely as JSX reference-passing does.

Essentially I want to mirror the React API as closely as possible.
Simple. A single value. Consumers and providers can be composed for more advanced situations.

Why do you want it to be as close to React as possible?
Not everything React does is the best. Let me explain:
React, for example, uses the "single-value" approach, and this causes higher memory growth because object references must be changed (cloned/copied) in order for updates to be triggered. This gives the Garabage Collector more work to do.
This is not good for things like games and animations that we wish to run as smoothly as possible.
It can cause Jank when continuous updates overload the Garabage Collector.
With a notification-based approach where object references don't change and only primitive values inside the objects change, memory growth can be kept to the bare minimum.
All of Three.js is programmed this way. Maintainers of Three.js will never choose to use immutable.js in that library, and they strongly encourage sharing single references to objects across a scene.
The best approach, IMO, would involve static objects (like in my example), though it can still be optimized.

Decoupled from any specific component

Sounds good, decoupling is good. I'm not adverse to this.
I care a lot more about the performance design; React has good examples of what we shouldn't do.

Everything I work on revolves around 3D applications involving animation and WebGL, so I've been thinking about performance a lot.
React brings about nice paradigm in terms of development patterns, but some of it's decisions aren't focused on performance.
We can make a similar API to React that performs much better.
Web Components that are faster than React components.
Imagine components that are similar to React components but much faster, and they are Web Components which makes them compatible with every framework.
It could happen like this:

we make a renderer-surplus, which renders using Surplus.

Surplus takes 1st place in Stefan Krause's (@krausest) framework benchmark; it is impressive.
Surplus uses S.js for minimal simple quick reactive data binding to pipe changes directly to DOM nodes (an approach similar to Aurelia, but much simpler and lighter.

We make static-object contexts whereby specific properties are observed (like my example) so we can have maximum performance by avoiding memory growth from cloning/copying objects.

use cases
This would result in Web Components that would live at the front of Stefan's framework benchmark, while having API features similar to React. These are the components I'd like to use for rich/interactive 3D experiences that are expressed declaratively.
Facebook's use case doesn't involve continually updating graphics/animations, so the performance problems that React has are not necessarily a concern to Facebook. If you look at any part of the Facebook website, the UI mostly never animates.  So, even if React would cause Jank in rapidly-updating cases, the Jank won't have a chance to show itself on facebook.com. No biggie for them.
I'd like to know that when I'm writing a 3D experience declaratively, that I'm doing it the most performant way that I know of (with the benefits of declarative component system). It makes dev life sooooooo nice to have the declarative layer, but the performance implications must be considered.
performance
Thinking about re-creating many new objects over and over every frame of a first-person shooter for the purpose of reading some number value is not appealing.
This is bad:
// wasteful (a whole new object made just to increment a number)
this.setState({ rotation: this.state.rotation + 1 })

This is good:
// efficient
this.state.rotation++

Skate props from withUpdate are already on the good path. Let's have contexts be on the good path by avoiding the single-value approach which forces new object creation.
It's possible to have primitive-values context, but then making a new context for many primitive values is completely not ideal (I haven't seen anyone do that).

Sidenotes:

I can live with naming contexts and using them as Custom Elements. This brings less performance than having pure JS objects though.
Everything is a mixin, so I can still use my own context mixin if I'd like.
Idea: because all features are mixins, we could possibly give users two forms of contexts: HTML-based contexts, and static-prop pure-JS contexts, and see which one they end up choosing (sort of like an A/B test).
Idea: Because features are all mixins, we could later have framework-specific contexts. f.e. Imagine a context-s.js package which might pair nicely with a renderer-surplus package, gluing the reactivity together.

OMG, sorry, that's like a book!! I hope you can at least gather the main points.
@blikblum I like how clean your examples are. What I'd like those is not single-valued contexts, so that I can avoid object cloning/copying and also avoid making many contexts (one per primitive value). I can live with string-based matching if I have to.
My use case is entirely focused on being able to make the smoothest yet declarative interactive 3D scenes, so the performance concern of continually cloning/copying objects is high.
If we can optimize the 3D always-rendering case, then we get the same optimization for 2D for free.

@treshugart About decoupling consuming from components, can you explain? I'm not sure I know what you mean.
(de)coupling?
Comparing React's contexts to my example, it seems that we have the same coupling. Here's a comparison:
A React component has to have a reference to the context, f.e.:
import * as React from 'react'

// get a reference to the context:
import TimeContext from 'some-time-library'

class GameTimer extends React.Component {
  render() {
    // use the context by reference
    return <TimeContext.Consumer> time =>
      {/* ... pass values from the context to other components ... */}
      <show-progress seconds={time.seconds} />
    </TimeContext.Consumer>
  }
}

and in my example, it has effectively the same reference coupling:
import {withComponent, withPreact} from 'skatejs'
import `withContext` from 'joes-example'

// get a reference to the context:
import TimeContext from 'some-time-library'

class GameTimer extends withContext(withPreact(withComponent(HTMLElement))) {
  static consumes = [
    [ TimeContext, 'seconds' ]
  ]

  render() {
    // use the context by reference
    const time = this.contexts.get(TimeContext)

    return

      {/* ... pass values from the context to other components ... */}
      <show-progress seconds={time.seconds}>
    </TimeContext.Consumer>
  }
}

The coupling seems exactly the same as in React. Both versions of GameTimer need a unique reference to the context.
In React JSX, you can also pass a Consumer element around via props, but that defeats the entire purpose of contexts in the first place.

The static consumes = [ is just syntax, and is reference-based. Here's other syntax ideas that can achieve exactly the same thing:
class TimeConsumingComponent extends TimeContext(['seconds'], withContext(withReact(withComponent()))) {

or
TimeContext(['seconds'],
class TimeConsumingComponent extends , withContext(withReact(withComponent())) { ... }
)

or
@TimeContext(['seconds'])
class TimeConsumingComponent extends , withContext(withReact(withComponent())) {

or
@withContexts([
  [TimeContext, 'seconds']
])
class TimeConsumingComponent extends , withReact(withComponent()) {

All of these avoid DOM performance hits and intricacies. Conceptually, this is more similar to React's new contexts in terms of functionality (reference-based). Conceptually, using named Custom Element contexts is more similar to old React string-named contexts in functionality.

I really like that the pure-JS approach lets us have the opportunity to write decorators (f.e. when using TypeScript).

Using the pure JS approach (with no strings), we can decouple components from context references like follows (arbitrarily picking one of the above syntaxes). The same pattern basically applies in React components:
import './some-element'

@withContexts([ [TimeContext, '*'] ])
class TimeDecoupler extends withReact(withComponent()) {
  render() {
    const time = this.contexts.get(TimeContext)

    // `some-element` does not need to know about the TimeContext, it is not coupled to it:
    return <some-element time={time}></some-element>
  }
}

This is example isn't much different than my previous example, but this is just pointing out that some-element is decoupled from the TimeContext. The exact same applies in React (pass context values as props to elements inside the render prop).

My particular example doesn't have to win, but what I'd really like in the context implementation that I'll use is

reference-based, no string collisions like React-old-contexts, therefore DOM-free and better performance.
contexts are objects, their references never change, only their properties change (for max performance).
consumers subscribe to specific props, this limits the number of updates (for max performance) and users don't have to write extra code in shouldUpdate methods. React makes you write extra code.
Avoid wasteful API like this.setState({ rotation: 100 * sin(time) }), prefer this.rotation = 100 * sin(time). React's <Provider value={{ rotation: 100 * sin(time) }}/> is wasteful and bad!

Those are my ideal requirements, but how it is actually implemented or what syntax looks like, I don't care so much.
If Skate eventually gets a new withContext, but they are DOM-element-based, I can just use my own mixin. That's the great thing about mixins: mixing and matching! 😄

What I'm going to have some fun doing next is implementing my above Surplus idea,

we make a renderer-surplus, which renders using Surplus.

Surplus takes 1st place in Stefan Krause's (@krausest) framework benchmark; it is impressive.
Surplus uses S.js for minimal simple quick reactive data binding to pipe changes directly to DOM nodes (an approach similar to Aurelia, but much simpler and lighter.

We make static-object string-free contexts whereby specific properties are observed (like my example) so we can have maximum performance by avoiding memory growth from cloning/copying objects.

and then see about putting it on the next round of Stefan's benchmark. It'll be impressive to see Web Components beat the others. Hopefully, creating Custom Elements and using them in the DOM doesn't introduce more overhead that we imagine. The pure-Surplus benchmark winner compiles to basically plane JS without custom elements, so adding Custom Elements will add some extra overhead, which I'm hoping is negligible with respects to the benchmark.

What i meant, re coupling, is that it requires you author a component to send context down.
I understand that it's theoretically more performant in theory and you prefer the non-DOM approach, (and that's awesome!) but I'm not willing to build that into core. I think this would best fit as a library you author and publish yourself as a mixin to web components.
The DOM approach can be a separate package that just exports a factory of components. Doesn't even need to use Skate or live inside any component constructors. I think for v6 we'll take this approach, removing the core implementation.


RoundCornerImageProcessor doesn't work on image insde of collectionviewcell - tvOS

I have an imageview inside of a collectionview cell. I tried a few processors and they work, but the RoundCornerImageProcessor doesn't work for me..
let processor = RoundCornerImageProcessor(cornerRadius: 20)   imageView.kf.setImage(with: url, placeholder: nil, options: [.processor(processor)])

It works for me well, at least in the demo app.
Any more information?

@onevcat I wish that I could give you more information, but the fact is every processor works for me except the rounded image. But when I have an imageview outside of a collection view cell then the roundedcorner processor does work properly..

Maybe take a look at the demo app in Kingfisher, which is also using image view within a collection cell.
Could it be related to this? https://github.com/onevcat/Kingfisher/blob/master/Demo/Kingfisher-Demo/CollectionViewCell.swift#L37

@onevcat sadly enough it's not related to it. I had these properties already

Can you build a sample app which could reproduce it? I'd like to have a look at it if there is a way to reproduce on my side.

Sorry for the late reaction. The problem was that the size of the image wasn't right to accomplish what I wanted. So I needed a resize processor as well.
let processor = ResizingImageProcessor(targetSize: CGSize(width: 300, height: 300)) >> RoundCornerImageProcessor(cornerRadius: 150) imageView.kf.setImage(with: url, placeholder: nil, options: [.processor(processor)])

Good to know that.
You mentioned about the shadow, which I guess is added by UIKit of tvOS to show a focus indicator?
It seems we do not have much to do with it since it is a system behavior and a almost a black-box to us. :(
Maybe it would be better to use a small round-corner image instead of a fully round image to get a nice visual effect.

@stijnwesterhof Nice man!
If someone uses it:
extension UIImageView {
    func download(url: String?, rounded: Bool = true) {
        guard let _url = url else {
            return
        }
        if rounded {
            let processor = ResizingImageProcessor(referenceSize: self.frame.size) >> RoundCornerImageProcessor(cornerRadius: self.frame.size.width / 2)
            self.kf.setImage(with: URL(string: _url), placeholder: nil, options: [.processor(processor)])
        } else {
            self.kf.setImage(with: URL(string: _url))
        }
    }
}


Add quilljs support

quilljs use caret range when change its style.
but in src/components/common/interactive.tsx:86, focus dom function call blur range of quilljs.
Remove this line seems more appropriate.

Deployed on npm @voaygerx/react-colorful


to add an Open Source Flutter App

Pocket Music Player
https://github.com/joec05/pocket-music-player
Pocket Music Player is a Music player app made with Flutter. Supports only mp3 files.
Category: Music

@ashitaprasad pls assign me this issue


how to end the conversions?

thank you for the respo,
I was just testing a new action using Watson but unfortunately, when I  need to end the conversation using words like 'cancel', 'exit'... etc., it's not working .. since I'm a fresher I don't know how to solve this. I had trained it in Watson assistant, but it is not yet working in google assistant.
thank you,

The real problem started when I deploy the action . The review said my mic is always open and need to close after specific question. but its js and confused to do how.


Error: 80004001 trying to install Fedora

LxRunOffline.exe install -n Fedora -f Fedora-Docker-Base-27-1.6.x86_64.tar.xz -d D:\WSL\Fedora

I got
Error: 80004001
Can you help me?

You have to convert that tar.xz file to tar.gz file as shown in that wiki page.


Bridge not reachable. How long button push

I followed instructions. And got to the "push bridge button" .   Fo how long?  is it the long 10 second and flash light push or a simple push.
"and press the button on the Nuki bridge. The bridge should be discovered automatically. Pressing the button allows Homebridge NB to obtain a token (API key)."    how long should I press button.
API is up and running in NUKI

But even after that I get this both from auto discovery and Aldo after using  using terminal and pushing the button shortly
**** homebridge log****
20/07/2022, 11:17:11] [Nuki] warning: <IP_ADDRESS>: request 1: GET /info
[20/07/2022, 11:17:11] [Nuki] warning: <IP_ADDRESS>: request 1: error: timeout after 15 seconds
[20/07/2022, 11:24:47] [Homebridge UI] Starting terminal session
[20/07/2022, 11:26:54] [Nuki] warning: <IP_ADDRESS>: request 1: GET /info
[20/07/2022, 11:26:54] [Nuki] warning: <IP_ADDRESS>: request 1: error: connect ECONNREFUSED <IP_ADDRESS>:8080
[20/07/2022, 11:34:02] [Homebridge UI] Terminal session ended.
Homebridge Terminal
Node.js Version: v16.16.0
Node.js Path: /opt/homebridge/bin/node
Plugin Path: /var/lib/homebridge/node_modules
Update Node.js: hb-service update-node
Install Plugin: hb-service add homebridge-plugin-name
Remove Plugin: hb-service remove homebridge-plugin-name
pi@homebridge:/var/lib/homebridge $ nb discover
nb discover: <IP_ADDRESS>: request 1: GET /info
nb discover: warning: <IP_ADDRESS>: request 1: error: connect ECONNREFUSED <IP_ADDRESS>:8080
[]
pi@homebridge:/var/lib/homebridge $ nb discover
nb discover: <IP_ADDRESS>: request 1: GET /info
nb discover: warning: <IP_ADDRESS>: request 1: error: connect ECONNREFUSED <IP_ADDRESS>:8080
[]
pi@homebridge:/var/lib/homebridge $ nb discover
nb discover: <IP_ADDRESS>: request 1: GET /info
nb discover: warning: <IP_ADDRESS>: request 1: error: connect ECONNREFUSED <IP_ADDRESS>:8080
[]
pi@homebridge:/var/lib/homebridge $

Now I get this. my range is 192.168.1.x
pi@homebridge:/var/lib/homebridge $ nb discover
nb discover: <IP_ADDRESS>: request 1: GET /info
nb discover: warning: <IP_ADDRESS>: request 1: error: timeout after 5 seconds
[]
pi@homebridge:/var/lib/homebridge $

It’s just a short press.  Doing a long, 10s, press enables BLE on the bridge, so it can be configured from the Nuki app.  I’m not sure, but I wouldn’t be surprised if that suspends the HTTP server and screws up the registration with the Nuki server.
Could you please run nb -DD discover?  Normally nb discover checks that it can reach each of the Nuki bridges returned by the Nuki server.  I think the Nuki server has registrations from some of your Internet neighbours that share or previously used your public IP address.  Please check if the response from the Nuki server includes the bridgeId for your Nuki bridge.  If not, power cycle your bridge to refresh the registration with the Nuki server.

did por cycle and then
pi@homebridge:/var/lib/homebridge $ nb -DD discover
nb discover: nuki server: request 1: GET /bridges
nb discover: nuki server: request 1: GET https://api.nuki.io/discover/bridges
nb discover: nuki server: request 1: response: {"bridges":[{"bridgeId":1862020107,"ip":"<IP_ADDRESS>","port":8080,"dateUpdated":"2022-07-20T10:43:01Z"}],"errorCode":0}
nb discover: nuki server: request 1: 200 OK
nb discover: <IP_ADDRESS>: request 1: GET /info
nb discover: <IP_ADDRESS>: request 1: GET http://<IP_ADDRESS>:8080/info
nb discover: <IP_ADDRESS>: request 1: GET /info
nb discover: warning: <IP_ADDRESS>: request 1: error: timeout after 5 seconds
[]
pi@homebridge:/var/lib/homebridge $

The good news: the bridge seems to have registered correctly and the Nuki server returns its info.
The bad news: there's no response when nb tries to connect to your bridge.  You could try nb -DD discover -t 30 to use a longer timeout.  If that doesn't help, there's probably a firewall on your server or in between your server and the Nuki bridge blocking the traffic.

that did the trick


TabNine spawning thousands of processes and clobbering computer

please complete the following information:

OS version: Windows 10
Editor version [e.g. 1.45.0-insider]:

Version: 1.53.2 (user setup)
Commit: 622cb03f7e070a9670c94bae1a45d78d7181fbd4
Date: 2021-02-11T11:48:04.245Z
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.18363

Programming language: Python
TabNine extension version: 3.2.8

Issue Details:
TabNine is spawning hundreds or thousands of child processes, clobbering the computer.
The computer starts acting normally again if you taskkill /t /im "wd-tabnine.exe" /f:

(that terminal window had one command, that whole scrollbar is killed TabNine processes)

Hi @tigerhawkvok,
Thank you for reaching out with this issue!

Can you please attach here the following:

Tabnine logs - Can be set like so:

WD-TabNine's logs - located near the log file of Tabnine and is called wd_log.txt
A screenshot of the Installation Info section from Tabnine Hub, like so:

When did this problem start to occur? Our processes are using lock files to prevent such problems, so can you think of something that changed on your machine, like permissions, paths etc.?

Kind regards,
Yoni

it also happened to me too

If this happens again to anyone, please shoot us an email at<EMAIL_ADDRESS>with screenshots of the processes and the log file obtained by writing tabnine::logs anywhere within a file in the IDE.


Add TRACE method type

TRACE is a valid HTTP method and should be in the type declaration.
Technically, the method specification claims "There are no restrictions on methods", so technically any string should be allowed as method.

Looks good to me! Thanks for the contribution! We'll get it merged right away!


TypeError: graphml is not a function

Please try the following link:
https://tonicdev.com/metincansiper/57b6c9db010a52150018085e

Please fix this @metincansiper

The problem was similar to the one in 'https://github.com/iVis-at-Bilkent/cytoscape.js-view-utilities/issues/6'. It seems to be solved now. However, I realized that 'jquery' and 'cytoscape' are peer dependencies for this extension but they are not specified as peer dependencies in 'package.json'. I could not be sure which versions of these libraries are compatible with this extension (because I do not know what is the expected behaviour for 'demo.html'), so I have not added them as peer dependencies yet. @mrsfy I think that we can release a new version after defining the peer dependancies.

@mrsfy Please allow @metincansiper to be able to publish all the extension you normally publish.

I added @metincansiper to collaborators on npmjs. It should be compatible with latest jquery and cytoscape.js. Anyway, I'll test peer dependencies and publish it.

I just published and added peer dependencies.

Thanks @mrsfy  I am closing the issue.


use chain to join generators

instead of making a copy self.totals and then adding the values in logs it would be better for performance to use the itertools chain operator

In the grand scheme of things, it does not make a difference.

thanks
2016-01-22 21:23 GMT+01:00 François Chollet<EMAIL_ADDRESS>
In the grand scheme of things, it does not make a difference.
—
Reply to this email directly or view it on GitHub
https://github.com/fchollet/keras/pull/1529#issuecomment-174036443.

--

Fabio Fumarola Ph.D.
Department of Computer Science, University of Bari "Aldo Moro"
Via E. Orabona, 4 - Bari 71025 Italy
Tel: +39 -<PHONE_NUMBER>
Mobile: +39 -<PHONE_NUMBER>
Fax: +39 -<PHONE_NUMBER>
http://www.di.uniba.it/~fumarola/
https://www.linkedin.com/pub/fabio-fumarola/7/540/605
<EMAIL_ADDRESS><EMAIL_ADDRESS>


mibdump.py fails on LSI-MegaRAID-SAS-MIB

Use mibdump.py to convert LSI-MegaRAID-SAS-MIB.
At first,I use the command
mibdump.py  LSI-MegaRAID-SAS-MIB

The mistake is Duplicate symbol found: bbuFRU at MIB LSI-MegaRAID-SAS-MIB.
So I download the file, changed it to make it not a duplicate part.Then I use this command
mibdump.py --mib-source http://<IP_ADDRESS>/ LSI-MegaRAID-SAS1-MIB

That's why I can run the locally modified file (LSI-MegaRAID-SAS-MIB).
The new mistake appeared no module "SNMPv2-SMI" in symbolTable at MIB LSI-MegaRAID-SAS-MIB.
I listened to some suggestions, use the command
mibdump.py --mib-source=http://mibs.snmplabs.com/asn1 LSI-MegaRAID-SAS1-MIB

It was not go, the mistake of Missing source MIBs: LSI-MegaRAID-SAS1-MIB.

Try adding two --mib-source options like this:
mibdump.py --mib-source http://<IP_ADDRESS>/ --mib-source http://mibs.snmplabs.com/asn1 LSI-MegaRAID-SAS1-MIB

I use the command:
mibdump.py --mib-source http://<IP_ADDRESS>/ --mib-source http://mibs.snmplabs.com/asn1 LSI-MegaRAID-SAS1-MIB
No successful conversion.Missing source MIBs: RFC-1212, RFC-1215, RFC1155-SMI, RFC1213-MIB, SNMPv2-CONF, SNMPv2-SMI, SNMPv2-TC.
I feel there's no way to get down.A little sad.

The original name of the file is LSI-MegaRAID-SAS-MIB.In order to distinguish them，I rename i to LSI-MegaRAID-SAS1-MIB.
I had also tried the command-- mibdump.py --mib-source http://<IP_ADDRESS>/ --mib-source http://mibs.snmplabs.com/asn1 LSI-MegaRAID-SAS-MIB.（rename it all to LSI-MegaRAID-SAS-MIB）
There's the same mistake.

I tried it again.
>mibdump.py --mib-source=http://<IP_ADDRESS>/ --mib-source=http://mibs.snmplabs.com/asn1 LSI-MegaRAID-SAS-MIB
Missing source MIBs: RFC-1212, RFC-1215, RFC1155-SMI, RFC1213-MIB, SNMPv2-CONF, SNMPv2-SMI, SNMPv2-TC Ignored MIBs: Failed MIBs: LSI-MegaRAID-SAS-MIB (no module "SNMPv2-SMI" in symbolTable at MIB LSI-MegaRAID-SAS-MIB)

Perhaps you are using some old pysmi version. Try this command:
mibdump.py --mib-source=http://<IP_ADDRESS>/ --mib-source=http://mibs.snmplabs.com/asn1/@mib@ LSI-MegaRAID-SAS-MIB

Oh！Yes！Thank you very much!It has been successfully converted！Cool！

Perhaps you are using some old pysmi version. Try this command:
mibdump.py --mib-source=http://<IP_ADDRESS>/ --mib-source=http://mibs.snmplabs.com/asn1/@mib@ LSI-MegaRAID-SAS-MIB

BTW, here is the documentation.

I also had the same problem, and @mib@ trick worked for me as well, thanks. However, my pysmi version is 0.3.4, seems to be the latest version right?

Yes, 0.3.4 is the latest release. Are you saying that without this @mib@ magic MIB search does not work for you?

Right, without this @mib@ magic MIB search does not work.


Threads seem to lose connection sometimes

First of all: great job on this library :)
Every now and then I get the following errors:
cypress.32683  | [80:0228/164642.193174:ERROR:connection.cc(66)] X connection error received.
cypress.32683  | [400:0228/164642.193183:ERROR:connection.cc(66)] X connection error received.
cypress.32683  | [400:0228/164642.193180:ERROR:connection.cc(66)] X connection error received.
cypress.32683  | Gdk-Message: 16:46:42.236: Cypress: Fatal IO error 11 (Resource temporarily unavailable) on X server :99.
cypress.32683  |
cypress.32683  | Thread 1 likely finished with failure count: 0
cypress.32683  | error Command failed with exit code 1.
cypress.32683  | Thread 0 likely finished with failure count: 1

But when I check the mocha results or run again none of the tests should have failed
Cypress version: cypress/included:9.5.0
Running in: docker-compose
Command:
yarn run cy:parallel \
    --threads 2 \
    --reporter mocha-junit-reporter \
    --reporterOptions mochaFile="cypress/results/${1}/junit/outcome-[hash].xml" \
    --args '"--browser chrome"' \
    --verbose

Anything I can log or do to provide more information?

@edwinveldhuizen Can you confirm the OS where you are running these tcs ? I faced the similar issue while running it in linux machine.

Yep, it’s on linux

Use 'xvfb-run -a; at the beginning of test scripts. it will work.
I think while running the tcs in parallel in same machine , all threads are using the same port for X11 server by default in linux , hence causing the issue . xvfb-run - a will help to auto assign the available ports to running thread. It is working for me and I hope it works for you as well.


Language of post reverts back to English on edit

Bug
If I create a post that is, for example, in Spanish (my default language being set as English), it is fine to set the Spanish language of the post but if I need to edit the title or something about that post, it reverts back to the default language (for me English) without editing that aspect.
E.G - I made some Spanish language graphics. Made the new post and selected Spanish as the language. I noticed a typo after it was published so edited it but it then also automatically changed the language of the post to English and did not retain the Spanish setting.
To Reproduce
Steps to reproduce the behavior:

Create a new publish and make the language for another language, not yours.
Publish
Once live, then edit it - perhaps there is a typo in the description.
If you scroll down to the language selector before republishing you will see it has reverted to your language and has not retained the original chosen.

Expected behavior
It should retain the language you set when you post.
Screenshots
If applicable, add screenshots to help explain your problem.
System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Additional context
Add any other context about the problem here.

Gonna do this issue :wink:

Cool. Let me know when you would like me to test. Cheers.

Made PR: #3481


Unity Plugin

Required Info

Camera Model
R200, F200 or SR300

Firmware Version

Operating System & Version

Kernel Version (Linux Only)

Build System
VS2013, XCode or Makefile

Hello
I was wondering is there aplugin yet to Interface Intel real sense with Unity. If yet please can you share it .
Also is it possible to do Hand tracking with lib real sense?
Awaiting your Responses
Cheers

Hi @poor21 Unity support is currently outside the scope of the librealsense project. Hand tracking is a key usage of RealSense data, however no off-the-shelf package exists to use with librealsense. You might have to adapt an existing open-source project like https://github.com/OpenGP/htrack or https://github.com/jsupancic/AStar_Dual_Tree_HandPose


openshift-goimports tool doesn't build on macOS

Describe the bug
The build wraps various helper tools in build scripts that don't seem to work reliably in all build environments.
To Reproduce
$ make imports
GOBIN=/Users/jpeach/upstream/kcp/hack/tools ./hack/go-install.sh github.com/coreydaley/openshift-goimports openshift-goimports b92214262c6ce8598aefdee87aae6b8cf1a9fc86
go: creating new go.mod: module fake/mod
# golang.org/x/sys/unix
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/syscall_darwin.1_13.go:29:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.1_13.go:27:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.1_13.go:40:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:28:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:43:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:59:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:75:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:90:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:105:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:121:3: //go:linkname must refer to declared function or variable
/Users/jpeach/go/pkg/mod/golang.org/x/sys@v0.0.0-20201109165425-215b40eba54c/unix/zsyscall_darwin_arm64.go:121:3: too many errors
make: *** [hack/tools/openshift-goimports-b92214262c6ce8598aefdee87aae6b8cf1a9fc86] Error 2

I think that if we switch to the tools pattern, I think that we can resolve this.
https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

What go version are you using?

We based the current setup on https://github.com/kubernetes-sigs/cluster-api/issues/5569 (also see the referenced Slack thread in there).

What go version are you using?

1.18 on macOS M1. The problem is that the imports tool has a golang.org/x/sys that is too old.

We based the current setup on kubernetes-sigs/cluster-api#5569 (also see the referenced Slack thread in there).

Yeh hard to tell from that thread what problems they had. Maybe module dependency hell?
[vincepri](https://app.slack.com/team/UCD11GCET)  [6 months ago](https://kubernetes.slack.com/archives/C8TSNPY4T/p1635448081211400?thread_ts=1635440307.207400&cid=C8TSNPY4T)
Kustomize brings in lots of go mod dependencies, that's why we moved away from it

Are you able to downgrade to go 1.17? Because kcp is based on internals of Kubernetes, it's easiest for us to match the go version that Kubernetes is using.

Or hopefully the openshift-goimports PR will fix things

Or hopefully the openshift-goimports PR will fix things

yeh, let's upgrade when that lands

@jpeach we fixed the test infra to get your openshift-goimports PR to merge. Would you be willing to update kcp to use the latest commit from https://github.com/openshift-eng/openshift-goimports in the Makefile?


Code Review

Changes Unknown when pulling 984e25f7c1f861c73e43387d46e3480af2c11b7a on development into ** on feedback**.

Changes Unknown when pulling 281b9165405f50ce4095a4c0cf9cad4dd0066171 on development into ** on feedback**.


GitHub Flavoured UI

The Application will look more impactful if the UI elements follow GitHub's Styling.

Agree. Thanks for creating the issue. Would you like to work on this? You can simply run the frontend react application by referring to the instructions mentioned in this readme file.

Agree. Thanks for creating the issue. Would you like to work on this? You can simply run the frontend react application by referring to the instructions mentioned in this readme file.

If this can be achieved just by editing the CSS files then, I'll love to implement it.

yes. you can create and include the scss files or if you want you can also add stylings inline to the component. I'm using MUI components and it provides several ways to style a component.

Is someone working on this? If not, I would love to pick it up..

@cool-pants
Go Ahead for sure!
Currently my college Unit Test are about to begin,
So I won't be able to start until the next Saturday.
In short,
Give it a hit.

Hey Vivek, do you mind if i start working on this?

Hey Vivek, do you mind if i start working on this?

yeah sure. @cool-pants are you working on this? if not I think @Senor-Ducky can start working on this

Hello! I suggest using the already made CSS library made by Github @cool-pants @Senor-Ducky @vivekweb2013
https://github.com/primer/css

Hello! I suggest using the already made CSS library made by Github @cool-pants @Senor-Ducky @vivekweb2013 https://github.com/primer/css

sure thing!

Hey Vivek, do you mind if i start working on this?

yeah sure. @cool-pants are you working on this? if not I think @Senor-Ducky can start working on this

Well i have started the work, and done most of it. @Senor-Ducky sorry for the late reply.

@cool-pants okay please continue.
Hey @Senor-Ducky. Could you please pick issue 49 instead.


Use property for submobjects

Overview: What does this pull request change?

Updated OpenGLMobject submobjects to use properties

Motivation and Explanation: Why and how do your changes improve the library?

#1889
When setting submobjects directly with mobject.submobjects = objects it misses out some important logic such as assembling family. This caused a bug previously #1844 that was well hidden. Using properties gives us more control in how it is set and avoids bugs like this in the future without breaking compatibility.
Links to added or changed documentation pages

Further Information and Comments

I had to check the if the attr was set to handle the first initialization. Not sure if there is a better way of doing it while still keeping the behaviour the same as set_submobjects() Tested on a collection of examples with opengl renderer and with the example #1844 with the fix reverted.

Reviewer Checklist

[ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
[ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
[ ] If applicable: newly added functions and classes are tested

Yea getting rid of the current setter makes sense, I guess we would have to deprecate it first right?

yes, let's deprecate it.

Yes but the submobjects in the init method actually triggers this setter, so in the first case the setter is called it needs to set self._submobjects and the cases after that we don't just assign submobject_list to _submobjects like most setters would, because it needs to use the setting logic that includes calling the remove method etc. I would be open to a different idea because I wasn't 100% keen on this way of doing it, but wasn't sure of an alternative
i don't think you should set the property in the __init__. Why not setting instead _submobjects ?

Ah yes that makes a lot more sense, updated now and deprecated the setter, thanks

Could you use this for points too? That is also needed.

Yea I think we could do it for points too, points uses _Data() so would prefer to do it in a separate PR in case there are any complications caused by it

Could you use this for points too? That is also needed.

Yea I think we could do it for points too, points uses _Data() so would prefer to do it in a separate PR in case there are any complications caused by it

Could you make that PR, please?

Could you use this for points too? That is also needed.

Yea I think we could do it for points too, points uses _Data() so would prefer to do it in a separate PR in case there are any complications caused by it

Could you make that PR, please? Or should I?


Tables

Hello Craig,
is is possible for you to implement the [table], [td], [tr] and [th] tags?
That would be nice!
Michael

closing as there has been no follow-up here


Tailwind prefix support

I tried your awesome datepicker, but i have a tailwind prefix in tailwind config file (prefix: "tw-")
therefor all the styles are not working because the elements in the package are without any prefix. Like in the picture -

Hi @ynonra 👋
Thank you for using our package.
Sorry for the delay. Thank you for your request. Currently, we do not support tailwind prefixes. We ask you not to use prefixes, if it is not a constraint on your project. Prefix support will be available in a future release.
PRs are always welcome 🎉.


conflicts ignore missing values

can pygrambank conflicts please ignore conflicts when one value is missing and the other is not? Currently for example, it reports a conflict for GB042 and acha1250 because CB-PE-AS_acha1250 has a missing value (due to fixhg) and SD_acha1250 has a value.

fixed now

Super, thanks!


Templates are not refreshed after updating functions runtime

Steps to reproduce:

Open a function app that is on an older version (say 0.3)
Go to function app settings, click the upgrade button.
Click new function, and select a template (e.g. HttpPOST(CRUD)-NodeJS)

Expected result:
The correct version of the template is used (0.4).
Actual result:
The older version of the template is used (0.3).
When the user activates the upgrade functionality, the portal needs to refresh which versions of the templates it uses.

I see, so a browser refresh would fix it, but within the session it's stuck to original version?

Yeah basically. If you close the function app blade and reopen it after doing the upgrade, you get the right version of the templates.


Does this sdk support Chinese?

I try this SDK on chinese PDF file, and get some garbled code.

Hi @tuhahaha, issues raised here should address problems in the samples for this repo. Closing this ticket.
Adobe community forum will be the appropriate place for the same: https://community.adobe.com/t5/document-services-apis/ct-p/ct-Document-Cloud-SDK.


Stuck at the Updating WebView URL

I've been running the bot for 9 hours, but it's always stuck at the updating WebView Url every 30 minutes or so, and it needed to be restarted once in a while. Is there a way to bypass this?

In the same boat


Create roles table

Write a script into install.sql file to create "user_roles" table and define three default roles: root, admin and client.

This submit do as expected, so now this issue will be closed.


Missing / Leftout docker.sh script in libnetwork cloud-config

Hello,
libnetwork cloud config https://github.com/projectcalico/calico-docker/blob/master/docs/getting-started/libnetwork/cloud-config/user-data-others#L37 contains a missing / leftout script: docker.sh.
This causes coreos to fail provisioning of any node apart from the first.

Fixed by #583

@crisidev - thanks for the issue - this is now fixed.

Thanks for the quick fix!


Game crashed when launching with Vulkan

Once upon a time in BC 233, a yung fello by the name of Felantrophosphorus was chillen by the balcony.
"Today is a good day" he exclaims with glee.
At a moments notice, he noticed a shadowy figure walk toward him
"STATE YOUR IDENTITY"
It is none other than Sir A$AP Rockilicious III Jr.
"All my A$AP killas got they pistols ready"
Felantrophosphorus notices a fleat of 110 men jump out of the mountains and village abodes
"These is my A$AP shooters" Sir A$AP Rockilicious III Jr. says
The shooters begin shooting at Felantrophosphorus in an attempt to assassinate him.
Felantrophosphorus jumps up and transforms into Super Felantrophosphorus and incinerates all of the A$AP shooters in one blast
"Hell na" A$AP exclaims
He then blows on his whistle, then 5 young men seemingly fade into the battle field.
"These the real a$ap killas i was talkin about"
5 young men introduce themselves as Pusha T, Kanye West, Big Sean, Yo Gotti, Chief Keef
They all gather their power together in a huge spirit bomb, all Felantrophosphorus could do was look at the giant light that betrothed upon his very eyes
"A$AP BOMB!!!" All 6 exclaim
The giant spirit bomb clashes into Felantrophosphorus and instantly kills him and eviscerates his entire body and atoms
"From this day forward, we shall rename this to the holy A$APVILLE" Sir A$AP exclaims
The villagers cheer
The end

ok


Automated cherry pick of #2005: fix: add priority for openstack secgroup rule priority

Cherry pick of #2005 on release/2.9.0.
#2005: fix: add priority for openstack secgroup rule priority

/approve

/lgtm


Command Handlers as private services

Hi,
I created some commands and command handlers that are all public services.
But in fact I never use these services and only use the command_bus service to send my commands:
$command = new FooBarCommand(...);
$commandBus->handle($command);

But when I set my command handlers as private, I get the following error:

The "FooBarCommandHandler" service or alias has been removed or inlined when the container was compiled. You should either make it public, or stop using the container directly and use dependency injection instead.

Is there any when to mark those commands as private and still continue to use the command_bus service (public)?

Hi,
It is not required to register commands as Symfony services, and from my point of view you shouldn't do it.
Commands handlers, on the other hand, are required to be registered as public services because of the way the handlers are resolved.
So to answer your question: No, not with the current implementation.


Login-SignUp Page : GSSOC'22 Contributor

Hey I want to add a login signUp page made using React that uses firebase backend.
Here's the link - https://firebase-users-auth.netlify.app/

@Nitya-S27 Thank you for your interest in the project i like the idea you implement but the login signup page that you make is consist of Firebase Authentication also so you can start working on it if there is no Firebase Authentication then the project was already in the Repo

@Nitya-S27 Thank you for your interest in the project i like the idea you implement but the login signup page that you make is consist of Firebase Authentication also so you can start working on it if there is no Firebase Authentication then the project was already in the Repo

Am I supposed to make it without firebase?
The project is based on react


Updates grid generation feature

Description

Refactors create_bounds function
Adds create_axis function
Adds new x, y, z, and attrs arguments to create_grid function
Deprecates **kwargs for create_grid function
Closes #496

Checklist

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] My changes generate no new warnings
[ ] Any dependent changes have been merged and published in downstream modules

If applicable:

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass with my changes (locally and CI/CD build)
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have noted that this is a breaking change for a major release (fix or feature that would cause existing functionality to not work as expected)

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (be3244e) 100.00% compared to head (d476a97) 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff            @@
##              main      #507   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           15        15
  Lines         1517      1562   +45
=========================================
+ Hits          1517      1562   +45

Impacted Files
Coverage Δ

xcdat/__init__.py
100.00% <ø> (ø)

xcdat/bounds.py
100.00% <100.00%> (ø)

xcdat/regridder/grid.py
100.00% <100.00%> (ø)

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


[Okex] Move the OKX streaming exchange to new module

why?

Because we cannot call the exchange using class string and in order to be
more organized. There is a confict when you call the exchange using class
string as parameters.
On Sat, Oct 15, 2022, 9:19 PM Tim Molter @.***> wrote:

why?
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/pull/4597#issuecomment-1279800094, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHIWQ72RRTHLVA5BVP2JPHLWDLYUXANCNFSM6AAAAAAREGCA4M
.
You are receiving this because you authored the thread.Message ID:
@.***>

I change the name of the module from okx to okex in order to be consistent with xchange-okex module


[Compatability Request] Party Inventory

There is no button to add item to party inventory.
Github link: https://github.com/teroparvinen/foundry-party-inventory

Thanks for reporting. As soon as I'm able, I will look into this.

Just as a little jump in; there is the "Group" actor which allows to group all people together. (Alltough not supported by Kgars Tidy)

Players even have a group Inventory then and can just yeet things in there

Getting the conversation started here: https://github.com/teroparvinen/foundry-party-inventory/issues/24
Nice tip about the Group Sheet!
On the topic of the Group Sheet, whenever New Tidy takes over the official Foundry Package ID, I will begin work on the Tidy Group Sheet. I'm also giving the group sheet some more time to evolve so I can get a clear picture of how it is meant to be used.

It seems like this is not going to become a reality. The module hasn't been updated since July 2023.
Should we give it up?

I'm going to let this one go, because the module author has not responded after a long enough time. If something changes, perhaps we can reopen the issue and try to get it going again?
Tidy now has a group sheet that utilizes the full Tidy inventory feature set, including inline containers. You can create multiple groups with shared inventories for different purposes, etc. This is worth a look, I think.
I'm sorry I couldn't establish compatibility. The module dev community seems always to be in flux, with people coming and going.


Decide how we will track data fetching progress

As a user I want to know the progress of data fetching (i.e. how many emails have been fetched, how many are left).
As a developer I need to be able to update the state of data fetching with new values.
Design a system to listen to fetch inbox and fetch messages commands and make this data available to be used in the UI.
Acceptance criteria:
1 - Description on how to implement this

This can be implemented in screen service and screen model as a small addition.
I'll make a FetchProgress class that stores data for a fetch, then have a map in screen model linking accounts to their fetch progresses. Command listeners will handle updating fetch progress.


Error 500 when trying to approve a translation

See http://www.codewars.com/kata/557b75579b03996942000061/discuss/
This is my kata which was recently approved and had no bugs as far as I remember.
Today g964 added a C# translation, which I approved. After that he did some edits in kata related to his translation on my request.
Later on, g964 added a Java translation. Now when I try to open the Java translation kumite, I get redirected to Error 500 screen. The same Error 500 appears when I try to open a discussion of that kumite (from list of translations, I can see it has 1 discussion inside).
Also, now C# translation has disappeared from kata. I tried to find out why, and therefore went to see revision history - but it yields Error 500 as well!
In addition to that, my (author's) signature disappeared from kata header, just as described in https://github.com/Codewars/codewars.com/issues/46.

Now when I try to open the Java translation kumite

Hm, I can open the Java translation. The C# translation is also still in the list and marked as "approved".

I am still getting Error 500 on both of them.

I am still getting Error 500 on both of them too.

This issue still remains, the kata is still broken as before. However, somehow the Java translation got approved (not by me). The C# translation is still missing. And I still get the 500 error when I try to view the any of the translation kumites or trying to access "Revisions" from the kata editor.


Update new-field.md

Next Page Should be Adding Validation instead of the current page.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@hgirish Nice catch! Thank you for your time to fix this, and congrats on your 1st docs contribution! This fix will go live within the next 24 hours.


Change the dimension ident to add the possibility of choosing a name

Currently the ident is generated when the packet is send with the dimension id, but I think we should do like for the biome struct and have a name field.

Fixed in #239


support sessionId (Authorization: OAuth)

Can you support sessionId?
Login with Soap is convenient(only UserId and Password are needed)
So I want to login with soap and do other stuff with your toolkit.
Thanks in advance.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
----->
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("OAuth", sessionId);

If this is still an issue (see latest updates to code) please re-open with more specifics.


Q: How to ignore generic Controller type in definitions

Using version 2.6.1
Question: I have a generic Controller that I use for all my controllers. I want to ignore the S type form the "definitions" as it is not exposed to the end user and it drags in some other types as well.
T type is ok as it is the type returned by the specific implementation of the GenericRestController.
public abstract class GenericRestController<T extends Moao, S extends IGenericService<T>> extends CommonRestController {

  @Autowired
  protected S genericService;
....

Adding S (the type) to the ignorable types doesnt work for you?

I have found the root of the problem but I am not sure why. If I have a method:
  @PostMapping("foo")   public ResponseEntity<Void> test() {     return new ResponseEntity(HttpStatus.OK);   }
It drags in all the S types but if I change this to:
  @PostMapping("foo")    @ResponseStatus(value = HttpStatus.OK)   public void test() {     return;   }
Now it does not?
Note that I have a lot of other methods returning ResponseEntity , ResponseEntity ...etc. in the same generic controller and they are not showing this issue. So I think it has to do with the void return type.

It is possible that this is a bug in classmate. Might see if I can reproduce it.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


TextDecoder.decode() TypeError hangs the whole app

Describe the bug
Postwomen keeps raising following exception on a failed request, and hanging the app. I have to use browser's task manager to kill it. Screenshot below.
TypeError: Failed to execute 'decode' on 'TextDecoder': The provided value is not of type '(ArraryBuffer or ArrayBufferView)

To Reproduce
Steps to reproduce the behavior:

Send an empty POST requests to https://www.feishu.cn/approval/openapi/v2/approval/get
See error

Expected behavior
Display the error response without hanging the app.
Screenshots

Desktop (please complete the following information):

OS: macOS 10.15.6
Browser: Edge 84.0.522.48
Postwomen Version: v1.9.7

@AndrewBastin

This seems to be an issue with the extension. I will open the issue on the extension and I will start working on a fix.

@ushuz the update with the fix is being rolled with the 0.15 browser extension update!
It is live on Firefox right now.


Support editor indent/deintent in new-issue editor

The improvements to textarea (around indenting at least) added to replies editor does not extend to the editor when creating a new issue.
In other words, I can't use tab/Shift+tab in editor while creating new issues.
Was this intended or an oversight?

It was mistakenly limited by https://github.com/sindresorhus/refined-github/pull/3256
That code just need an extra line now: pageDetect.isNewIssue I think

@fregante I will fix it


[JENKINS-33416] add support for mostRecent and Unclassified jobs filters

Related to https://issues.jenkins-ci.org/browse/JENKINS-33416

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

See my remarks to #778.

remarks considered, corrections done.


Change to Target .NET Standard 2.0

Currently only set to target .NET 5.

Following the recommendations here: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting

And here: https://docs.microsoft.com/en-us/dotnet/standard/net-standard


Failed to export from online IDE

Export from online IDE is failing with message:
An error occured during export. Please contact support
Exporting mbed-os-example-blinky seems to work fine.

@artokin Which board/compiler ? Need to check mbed export -S to see if actually a supported combination. Does it export when using the command line ?

As far as I managed to understand (thanks @geky for the explanation), the entire NVStore feature isn't seen by the online IDE until the feature is in the release, hence the failure.

Related https://github.com/ARMmbed/mbed-os-example-nvstore/issues/5

If the partnerbeta version of the online compiler is being used as per the OOB instructions then the feature should be visible...

Probably related to https://github.com/ARMmbed/mbed-os/pull/6428

That PR is now in. SOmeone mind taking another look?

ARM Internal Ref: MBOTRIAGE-589

Can't reproduce anymore
@yossi2le tested for ARM GNU eclipse, eclipse GCC_ARM and eclipse IAR for the following boards K82F, K64F and ARC_PRO all pass successfully.


[6.0.0-rc.4] Problem validate when change form's field

I'm not sure this is a bug or incorrect implementation. Example repository: https://github.com/ViZhe/redux-form-issue
For start:
npm i
npm start

Open http://<IP_ADDRESS>:3000
The steps describing the problem

I click "Send" button
Form show me 2 errors and do action "SET_SUBMIT_FAILED" - OK
I fix errors in form and submit form again
Form do action "SET_SUBMIT_SUCCEEDED" - OK
Now i can refresh the page or not
I select "second" template
In form changing some fields
I submit this form
Form do action "SET_SUBMIT_SUCCEEDED" - BAD, because ignore validate for field "Size", but the value of this field is passed to the form handler
I touch or write some thing in field "Size"
Form show me error "Size must be small"
I submit this form
Form do action "SET_SUBMIT_SUCCEEDED" - BAD, because we still ignore validate for field "Size"

Why is this happening
Form does not register new fields and not unregister old.
UPD:
if you have not added new fields and removed some of the old, then:
first, there is the reregistration of the all fields, and then unregistered the all old, and because there is a crossing of the names, unregistered new too.
If a new field was added, then:
Unregistered unused field, and the new is not registered.
Sorry for spelling. Let me know if you need anything.

I think this is resolved by the yet unreleased pull request #1486.

@jervi, Thank for you time.
My steps:
git clone git@github.com:erikras/redux-form.git -b v6
cd redux-form
npm i
npm run build
rm -rf node_modules

Then moved this folder in project/node_modules, but result remain the same.

Fixed by #1561. I'll leave another comment here when it is released.

Fix published in v6.0.0-rc.5.

@erikras Thank for this.
Confirm previous version of the repository to start working, but today I redid it and everything is broken again ;(
Following in the steps:

When entering the form loads the template "A", resulting in INITIALIZE and REGISTER_FIELD for fields: "f1", "f2". These fields don't have validation, so when the submit event, I get SET_SUBMIT_SUCCEEDED - OK
I change the template to "B"
Form do REGISTER_FIELD for "f3", "f4" and "f5". "f3" is required, but on submit, i get SET_SUBMIT_SUCCEEDED - BAD, because ignore validate for field "f3
I change the template to "C"
The following actions occur:

INITIALIZE
UNREGISTER_FIELD for f1
REGISTER_FIELD for f3
UNREGISTER_FIELD for f2
REGISTER_FIELD for f5
UNREGISTER_FIELD for f3
REGISTER_FIELD for f6
UNREGISTER_FIELD for f4
UNREGISTER_FIELD for f5
UPDATE_SYNC_ERRORS


Netherite Duplication Bug Recipe

One of my friends was looking at your Datapack, and we realized that Stonecutter Lodestone recipe gives 3 ingots, which is funny because the Lodestone needs one ingot to craft, so it's an infinite source of netherite... Lol

Oh! Hah, good catch. If you want to tweak that recipe file in a Pull Request, I'd be super grateful, as I don't have a lot of time. Otherwise, I'll get to this when I can.


Default HTTPVerb

Description
Fixes #4435 by supplying an initial string placeholder so $HTTPVerb will never be null.
Checklist:

[X] Securely signed commits
[X] Component(s) with PHPdocs
[X] Unit testing, with >80% coverage
n/a User guide updated
[X] Conforms to style guide

Alright alright you had your chance. I'm going in!


Feature: Commands API support.

This PR adds support for the Commands API, which includes:

New endpoints for the device-level Commands API.
Receiving of command delivery notifications into an array to be popped from to the user in the receive_commands generator function.

Resolves #4.

Ready for review.
@omab - When you get a chance, please review these changes and let me know if there are things I need to change.  I'm open to whatever suggestions you have about making it more idiomatic or improving it in other ways.

Got permission from @omab and @fsaravia offline, so I'm merging.

:+1:


Provide access to an instance's region from metadata

I've found myself carrying around a method to derive a region from metadata.google.internal. It's fairly analogous to projectIdFromMetadataServer from package:gcp
Usage of this method looks like:
final location = await locationFromMetadataServer();
print(location);
...
// Outputs: us-central1

I've scanned through a couple other issues, it looks like #123 is somewhat related, although is potentially larger in scope.
Would this be a welcome contribution, to be added to package:gcp?

Something for pkg:gcp sounds good to me!


Arcore 1.2 1.4 1.6 with unreal 4.21 joystick problems

I have created 1st person example map. I have built it to andorid with joysticks on. Everything works fine...BUT...when I enable Google ARCore plugin joysticks prevent looking up and down?!?!? Everything else works like it should...what can i do? Are there any google developers reading these problems...? Can Someone help me...Thanks.

Fixed in 1.9.0
https://github.com/google-ar/arcore-unreal-sdk/releases


two way data binding

Is there a way to bind the data ( using ngModel ) so the items are selected even if the user deviates away from the page?

Please check this #21


[url_launcher] Improving unit tests on mac

Add unit tests for url_launcher canLaunch and launch methods on mac with success and failure results.
Fixes #92969
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
[x] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@cbracken for secondary review, per Flutter policy.

GitHub has gotten very aggressive about requiring main to be merged in before landing even when there are no conflicts (I'm not sure why), so this needs another merge. If you ping me once that's done I can try to land it before it gets stale again.

ping


AbstractSyntacticHeap gc() return value

I think this always will return false as the syntacticItems has been reduced to match count...
return count < syntacticItems.size();

Yes, I think you're right!


Website Not Working

Hi I believe 91cb27e2cb60dd516bae55b4eaf70d110b8f4d81 caused the Github pages to no longer be live. I get a 404 when trying to access https://ballaerospace.github.io/docs/v5/

I am having the same issue. Website no longer works. 404 error when trying to access.

Sorry guys, this was the process of me moving the site back to the default domain:
https://ballaerospace.github.io/cosmos-website/
cosmosrb.com and cosmosc2.com should be setup to redirect there at least until the end of July.

Thanks Ryan! Works.


Use a YAML comment for the license info as suggested by Ladislav

Thanks, issue templates are back! :-)


makeHardcodeGsettingsPatch: Support other constructors

Description of changes
Also move it out to a separate file since glib expression is messy enough as is. And add tests.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Weirdly, the tests do not want to eval for some reason:
$ nix-build -A makeHardcodeGsettingsPatch.tests
error: cannot evaluate a function that has an argument without a value ('src')

       Nix attempted to evaluate a function as a top level expression; in
       this case it must have its arguments supplied either by default
       values, or passed explicitly with '--arg' or '--argstr'. See
       https://nixos.org/manual/nix/stable/expressions/language-constructs.html#functions.

       at /home/jtojnar/Projects/nixpkgs/pkgs/build-support/make-hardcode-gsettings-patch/default.nix:41:7:

           40|     {
           41|       src,
             |       ^
           42|       schemaIdToVariableMapping,

And while I am able to build it in nix repl:
nix-repl> :b makeHardcodeGsettingsPatch {
            src = ./pkgs/build-support/make-hardcode-gsettings-patch/test;
            schemaIdToVariableMapping = {
              "org.gnome.evolution-data-server.addressbook" = "EDS";
              "org.gnome.evolution.calendar" = "EVO";
            };
          }

This derivation produced the following outputs:
  out -> /nix/store/f3xci4y7bl3mm68bsv9w4ry9q87sa5sr-hardcode-gsettings.patch

But the produced output is an empty file.

@GrahamcOfBorg build evolutionWithPlugins

the test you added will fail if coccinnelle changes whitespace. Maybe run the code through a formatter before comparing?

Thanks, done.