WIP: SAT Solver

This PR adds internal/{solver,package}/, which implements a pseudo-Boolean SAT solver. The solver is used to obtain a result on which charts, shared and optional dependencies are going to be installed on hypper install foo.
TODOs:

[ ] bug: non-deterministic order of pkgs in output (which makes goldenfiles differ): order s.PkgResultSet.
[ ] bug: Loading a chart from local files makes the resulting wantedPkg not to have dependency relations.
[ ] Rework and reenable pkg/action/install_test.go.
[ ] Add solver.Strategy field, implement upgrades in solver by slightly changing constraints creation.
[ ] Prettier hypper install output.
[ ] skip installing shared and shared-optional dependencies (but solve for them) if hypper install foo --no-shared-deps.
[ ] code docs update, including solver/docs.go, etc.
[ ] clobber the code, there's a bunch of commented uneeded code.

force-pushed to fix last WIP (so it compiles) and rebased to squash all the fixup! commits.

Still working on this. Missing things:

Make cmd/hypper/{install_test.go, upgrade_test.go} pass
hypper upgrade has a fork in the code: if the chart is not installed, it will install with the SAT solver. If it is to be upgraded, it justs calls Helm's action.Install.Run(). We may leave like that for this PR.
Print and install charts in specific order: first parent, then dependencies: build graph of resulting packages for that.
Performance issues with repositories with a lot of chart versions (E.g: https://charts.bitnami.com/bitnami):
The bottleneck is in adding the charts to the package database, and in creating the constraints for them (see with hypper install --debug). We should paralelize those tasks.

@mattfarina thanks for looking into it. The bug comes from chart demo and demo-opt sharing the same release name, demoit. On pkg.action.BuildWorld() the created packages from them would get merged into one, giving the chart demo the optional deps from demo-opt.
Fixed the bug by adding pkg.ChartName to the fingerprint and base fingerprint (effectively making it part of the unique key).
A race condition when generating the constraints appeared, and I didn't see why. I have reverted the commit adding that concurrency.
Changing the order of installation of the packages is yet to be done.

Found another issue. Here's how I ran into it with my testing...
$ hypper install ./demo
🛳  Installing dependencies of chart "demo":
🛳    Installing chart "demo-a" as "demo-a" in namespace "demo-a"…
🛳    Installing chart "demo-b" as "demo-b" in namespace "demo-b"…
🛳  Installing chart "demo" as "demoit" in namespace "demo"…
👏 Done!

$ hypper uninstall demoit -n demo
🔥  uninstalling demoit
✅  release "demoit" uninstalled

$ hypper install ./demo
ERROR: ❌

Found another issue with resolving versions, I think.
The demo chart in v0.1.0 had been set to look for demo-b at ^0.1.0 which means > 0.1.0 < 0.2.0. So, it didn't pick up v0.2.0 that depends on the demo-c chart. I updated the demo chart to a v0.2.0 release with the following Chart.yaml file...
apiVersion: v2
name: demo
description: A Helm chart for Kubernetes
type: application
version: 0.2.0
appVersion: "1.16.0"
annotations:
  hypper.cattle.io/release-name: demoit
  hypper.cattle.io/namespace: demo
  hypper.cattle.io/shared-dependencies: |
    - name: demo-a
      version: "^0.1.0"
      repository: "https://mattfarina.github.io/demo-hypper-charts/repo"
    - name: demo-b
      version: "^0"
      repository: "https://mattfarina.github.io/demo-hypper-charts/repo"

On install it still resolves to demo-b at v0.1.0. I get the same result if I set the version for demo-b to *. If I explicitly set the demo-b version to 0.2.0 it works to install that. So, it finds it. It just doesn't select it.
Note, the repo I'm using for testing is https://mattfarina.github.io/demo-hypper-charts/repo
Note, each time I'm testing this stuff I'm starting with a fresh Kubernetes setup. I wipe the cluster prior to attempting install. So, there is nothing previously left from a past install

The indentation of the Installing dependencies of chart "demo-b": and Installing chart "demo-b" as "demo-b" in namespace "demo-b"… lines doesn't feel right. Should the line Installing dependencies of chart "demo-b": even be present?

Going with the latest repo, demo-b depends on demo-c. Hence why the line Installing dependencies of chart "demo-b": is present.
If there's no indentation, then one can not easily discern which installation comes in because of a dependency.
We could instead do for example:

❯ hypper install ./demo
🛳  Installing dependencies of chart "demo":
🛳    Installing chart "demo-a" as "demo-a" in namespace "demo-a"…
🛳    Installing dependencies of chart "demo-b":
🛳      Installing chart "demo-c" as "demo-c" in namespace "demo-c"…
🛳    Installing chart "demo-b" as "demo-b" in namespace "demo-b"…
🛳  Installing chart "demo" as "demoit" in namespace "demo"…
👏 Done!

❯ hypper install ./demo
🛳  Installing chart "demo-a" as "demo-a" in namespace "demo-a"…
🛳  Installing chart "demo-c" as "demo-c" in namespace "demo-c"…
🛳  Installing chart "demo-b" as "demo-b" in namespace "demo-b"…
🛳  Installing chart "demo" as "demoit" in namespace "demo"…
👏 Done!

I have another situation I can't quite figure out. I created the situation where I have demo depend on demo-b, demo-b depend on demo-c, and demo-c depend on demo-e. So, demo -> b -> c -> e. Multiple levels. In this situation I cannot get demo-e to install. I did this mostly on disk using file:// repos.
❯ hypper install ./demo --debug
DEBUG: Original chart version: ""
DEBUG: CHART PATH: /Users/mfarina/code/mattfarina/demo-hypper-charts/charts/demo
DEBUG: Building package DB…
DEBUG: Dependency "demo-d" not found in repos, loading chart
DEBUG: CHART PATH: /Users/mfarina/code/mattfarina/demo-hypper-charts/charts/demo-d
DEBUG: Asking for each optional deps of package demoit_0.2.0_demo_demo if they should be promoted
DEBUG: Building constraints…
DEBUG: Solving…
DEBUG: Result: SAT
🛳  Installing dependencies of chart "demo":
DEBUG: Installing package: fp: demo-a_0.1.0_demo-a_demo-a Currentstate: 0 DesiredState: 0 PinnedVersion: 0.1.0 ChartName: demo-a
DEBUG: CHART PATH: /Users/mfarina/code/mattfarina/demo-hypper-charts/charts/demo-a
DEBUG: Original chart version: "0.1.0"
🛳    Installing chart "demo-a" as "demo-a" in namespace "demo-a"…
DEBUG: creating 1 resource(s)
DEBUG: creating 3 resource(s)
🛳  Installing dependencies of chart "demo-b":
DEBUG: Installing package: fp: demo-c_0.1.0_demo-c_demo-c Currentstate: 0 DesiredState: 0 PinnedVersion: 0.1.0 ChartName: demo-c
DEBUG: CHART PATH: /Users/mfarina/code/mattfarina/demo-hypper-charts/charts/demo-c
DEBUG: Original chart version: "0.1.0"
🛳    Installing chart "demo-c" as "demo-c" in namespace "demo-c"…
DEBUG: creating 1 resource(s)
DEBUG: creating 3 resource(s)
DEBUG: Installing package: fp: demo-b_0.2.0_demo-b_demo-b Currentstate: 0 DesiredState: 0 PinnedVersion: 0.2.0 ChartName: demo-b
          DepRel: &{demo-c demo-c ^0.1.0 demo-c}
DEBUG: CHART PATH: /Users/mfarina/code/mattfarina/demo-hypper-charts/charts/demo-b
DEBUG: Original chart version: "0.2.0"
🛳    Installing chart "demo-b" as "demo-b" in namespace "demo-b"…
DEBUG: creating 1 resource(s)
DEBUG: creating 3 resource(s)
DEBUG: Installing package: fp: demo-d_0.2.0_demo-d_demo-d Currentstate: 0 DesiredState: 0 PinnedVersion: 0.2.0 ChartName: demo-d
DEBUG: CHART PATH: /Users/mfarina/code/mattfarina/demo-hypper-charts/charts/demo-d
DEBUG: Original chart version: "0.2.0"
🛳    Installing chart "demo-d" as "demo-d" in namespace "demo-d"…
DEBUG: creating 1 resource(s)
DEBUG: creating 3 resource(s)
DEBUG: Installing package: fp: demoit_0.2.0_demo_demo Currentstate: 0 DesiredState: 1 PinnedVersion: 0.2.0 ChartName: demo
          DepRel: &{demo-a demo-a ^0.1.0 demo-a}
          DepRel: &{demo-b demo-b 0.2.0 demo-b}
          DepRel: &{demo-d demo-d 0.2.0 demo-d}
DEBUG: Original chart version: "0.2.0"
🛳  Installing chart "demo" as "demoit" in namespace "demo"…
DEBUG: creating 1 resource(s)
DEBUG: creating 3 resource(s)
👏 Done!

demo-c has a Chart.yaml of...
apiVersion: v2
name: demo-c
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"
annotations:
  hypper.cattle.io/release-name: demo-c
  hypper.cattle.io/namespace: demo-c
  hypper.cattle.io/shared-dependencies: |
    - name: demo-e
      version: "^0.1.0"
      repository: "file://../demo-e"

It doesn't appear to try the dependencies at this level. Am I missing something?
The demo-e Chart.yaml is...
apiVersion: v2
name: demo-e
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"
annotations:
  hypper.cattle.io/namespace: demo-e

demo-c is being pulled from disk yet it's not picking up the dependency in the annotation.

@viccuad I would go with display option 2.

Implemented display option 2, and added more output when hypper install --debug.

I'll try to walk through my past few comments on re-testing with the latest code...
The issue with the error:

$ hypper install ./demo
ERROR: ❌

After clearing my hypper cache I can no longer reproduce this issue. If I experience this again I will collect more debugging information and open a new issue. This is good for now.
I like the new indentation, too.

Found one issue that can be dealt with in a follow-up. See #178

Approved as things are working in my tests


Replace rvest with readLines() applied over URL

this could be done much simpler than using rvest

not required at this time


Exception when running yo command in VSCode

When I press F1, type in 'yo' then [Enter] I get the following Exception:
Uncaught Exception:  TypeError: Cannot read property 'split' of undefined
TypeError: Cannot read property 'split' of undefined
    at new Range (C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\node_modules\semver\semver.js:720:19)
    at outside (C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\node_modules\semver\semver.js:1123:11)
    at Function.ltr (C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\node_modules\semver\semver.js:1111:10)
    at C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\out\yo\yo.js:37:49
    at Array.map (native)
    at Yeoman.getGenerators (C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\out\yo\yo.js:25:21)
    at C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\out\extension.js:90:37
    at Environment.resolver.lookup (C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\node_modules\yeoman-environment\lib\resolver.js:50:12)
    at Immediate._onImmediate (C:\Users\Anthony\.vscode\extensions\samverschueren.yo-0.8.4\out\extension.js:89:33)
    at processImmediate [as _immediateCallback] (timers.js:374:17)

Digging in the code led me to the following line in yo.js: 37 :
=>  generatorMeta.isCompatible = semver.ltr('0.17.6', generatorVersion);
generatorVersion's value is ~0.20.3
I had to patch the offending code in semver to handle the case where range object is null with a (range||'') to get it working (L720):
I also tried to upgrade semver to the latest version (5.1.0) but with no luck.
Feel free to let me know if you need further details.

Hi,
I managed to find the root cause of my problem. I had a yeoman generator (custom made for testing only and "npm link'd") with the following package.json:
{
  "name": "package",
  "version": "0.0.0",
  "dependencies": {}
}

The side effect is that generatorVersion returned in yo.js (L33) is null in this case thus breaking semver.ltr function later on.
I'll submit a PR to manage this border case.
Love your extension btw, gret job!

Thanks for looking into this! PR more then welcome.

Hi! I'm experiencing the same problem when I install this yeoman generator.
I get the following exception:
Uncaught Exception:  TypeError: Cannot read property 'split' of undefined
TypeError: Cannot read property 'split' of undefined
    at new Range (/Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/node_modules/semver/semver.js:720:19)
    at outside (/Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/node_modules/semver/semver.js:1123:11)
    at Function.ltr (/Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/node_modules/semver/semver.js:1111:10)
    at /Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/out/yo/yo.js:37:49
    at Array.map (native)
    at Yeoman.getGenerators (/Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/out/yo/yo.js:25:21)
    at /Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/out/extension.js:90:37
    at Environment.resolver.lookup (/Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/node_modules/yeoman-environment/lib/resolver.js:50:12)
    at Immediate._onImmediate (/Users/grega/.vscode/extensions/samverschueren.yo-0.8.4/out/extension.js:89:33)
    at tryOnImmediate (timers.js:534:15)
    at processImmediate [as _immediateCallback] (timers.js:514:5)

Anyone has a clue what could be wrong?

The PR that solved this issue was not released yet, did a new one. Make sure the generator you are using depends on yeoman-generator.

Thank you for releasing new version with patched isssue. Now it's working fine!

Great 👍  :)


[api_generator] API path builder update

Handling of more complex sets of URLs.
Previously, the api_generator assumed that all URL paths of the same x-operation-group shared the same static components (i.e. if you remove all {path_param} components in each path, the paths are identical):
For example these 4 paths of the nodes.stats group have an identical set of static components of _nodes and stats

/_nodes/{node_id}/stats/{metric}/{index_metric}
/_nodes/{node_id}/stats/{metric}
/_nodes/{node_id}/stats
/_nodes/stats

And the generator would build the path as
const path = ['/_nodes/', node_id, '/stats/', metric, '/', index_metric].filter(c => c).join('').replace('//', '/');

However this assumption not true for some operation groups like cluster.stats:

/_cluster/stats/{metric}/{index_metric}/nodes/{node_id}
/_cluster/stats/{metric}/nodes/{node_id}
/_cluster/stats/nodes/{node_id}
/_cluster/stats

Notice that the first 3 paths have _cluster, stats and nodes as their static components while the last one only has _cluster and stats. Therefore the following path that the generator use to make is incorrect:
const path = ['/_cluster/', metric, '/', index_metric, 'stats/nodes/', node_id].filter(c => c).join('').replace('//', '/');

because when none of the path params are provided, we would end up with const path = '/_cluster/states/nodes', which is not a valid path. With this PR, the generator will be able to detect this edge case and generate a more complex path building strategy for cluster.stats:
let path;
if (metric != null && index_metric != null && node_id != null) {
  path = '/_cluster/stats/' + metric + '/' + index_metric + '/nodes/' + node_id;
}  else if (metric != null && node_id != null) {
  path = '/_cluster/stats/' + metric + '/nodes/' + node_id;
}  else if (node_id != null) {
  path = '/_cluster/stats/nodes/' + node_id;
}  else {
  path = '/_cluster/stats';
}

Streamlined path building code
The generated path building logic for operation groups with uniform static path components is now simpler and more performant. Here are a few examples of old vs new code:
const path = ['/_nodes/', node_id, '/stats/', metric, '/', index_metric].filter(c => c).join('').replace('//', '/');
const path = ['/_nodes', node_id, 'stats', metric, index_metric].filter(c => c).join('/');

const path = ['/', index, '/_alias/', name].filter(c => c).join('').replace('//', '/');
const path = ['', index, '_alias', name].filter(c => c).join('/');

const path = ['/', index, '/_validate/query'].filter(c => c).join('').replace('//', '/');
const path = ['', index, '_validate/query'].filter(c => c).join('/');

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Why are these in the same operation group when they are different APIs?
/_cluster/stats/{metric}/{index_metric}/nodes/{node_id}
/_cluster/stats/{metric}/nodes/{node_id}
/_cluster/stats/nodes/{node_id}
/_cluster/stats

Should they be in separate operation groups?
cluster_stats_nodes
/_cluster/stats/{metric}/{index_metric}/nodes/{node_id}
/_cluster/stats/{metric}/nodes/{node_id}
/_cluster/stats/nodes/{node_id}

cluster_stats
/_cluster/stats

@dblock that's how it's specified in the spec. The fix should be in the spec, if that's an error. Regardless, this code gen will now be able to handle this edge case if it appears in the spec.

I dont think we should change the groups because of how it's implemented on a client. That will also result in a breaking change for all clients.


Making instanceOf work for stamps

ES6 has Symbol.hasInstance which allows you to control the function run to determine if an object is an instance of another object. Usually, as we know, it simply checks the prototype chain. If stampit kept a track of the objects / propertyDescriptors  combined to create the objects returned from a stamp, those objects could have an overridden Symbol.hasInstance method that checks the list of combined objects / propertyDescriptors to determine instanceOf.

JFYI. You can write a stamp which would keep track of stamps any stamp is
made of. Sounds insane. But easy doable. I'll do. 😊
On Tue, 23 May 2017, 00:37 Robert Goldsmith<EMAIL_ADDRESS>wrote:

ES6 has Symbol.hasInstance which allows you to control the function run to
determine if an object is an instance of another object. Usually, as we
know, it simply checks the prototype chain. If stampit kept a track of the
objects / propertyDescriptors combined to create the objects returned from
a stamp, those objects could have an overridden Symbol.hasInstance method
that checks the list of combined objects / propertyDescriptors to determine
instanceOf.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stampit-org/stampit/issues/312, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjCLxOs_2fM3bU2CkvFFmDVnvxfDVzgks5r8Z2mgaJpZM4Nicpe
.

@far-blue https://github.com/stampit-org/stampit/issues/44#issuecomment-70051741

My suggestion is to reuse a broken element of js to turn it into a helpful facility by replacing the original broken behaviour with well defined stamp-compatible behaviour without having to invent a new interface :) wouldn't rescuing instanceof and recycling it be a good thing?

@far-blue And did you ask yourself a question if it's actually needed? Stamps are so different concept than classes, that instanceOf is just misleading than being helpful. If anything, it could be stampOf to denote the difference, but going with the same naming is just for confusing people.

Anyway, you are surely welcome to create a PR in our monorepo that would handle that. It's a kinda beauty of stamps that not everybody needs to use all crazy ideas someone has :)

shrugs It doesn't impact me either way as it's easy enough for me to implement myself for my own use. I'm just suggesting ideas - such as extending what instanceOf actually does (rather than what people think it does) to cover multiple prototypal delegation using new capabilities in ES6 others may not be aware of.
 It's possible that what I find as a "crazy idea", it might actually make a transition to stamps easier for other people coming from Java-like languages that are used to this. Later they might realize it's not needed, but that's another story.

Since ES6 allows us to fix the broken instanceof behavior, I think it's not actually a terrible idea.
I'm open to discussing this as an addition to the specification.

I'd argue this needs to be a specification change. It can also be a stamp!
Here is how how you can do it: scroll down to Collecting a stamp’s origins.
const InstanceOf = stampit()
  .composers(({stamp, composables}) => {
    // get or create the configuration metadata
    const conf = stamp.compose.configuration || {};
    stamp.compose.configuration = conf;
    // concatenate new composables with the previous list
    conf.wasComposedOf = composables.concat(conf.wasComposedOf);
    // de-duplicate the array
    conf.wasComposedOf = _.uniq(conf.wasComposedOf);
    const wasComposedOf = conf.wasComposedOf;

    // get or create the methods metadata
    const methods = stamp.compose.methods || {};
    stamp.compose.methods = methods;
    // add or overwrite the method which returns the composables
    methods.getOrigins = () => wasComposedOf;

    // get or create the statics metadata
    const statics = stamp.compose.statics || {};
    stamp.compose.statics = statics;
    // add or overwrite the `instanceof` method
    statics[Symbol.hasInstance] = (instance) =>
      _.union(instance.getOrigins(), wasComposedOf).length === instance.getOrigins().length)
  });

InstanceOf() instanceof InstanceOf; // true

const Derived = compose(Stamp1, InstanceOf, Stamp2);
Derived() instanceof InstanceOf; // true

Please ignore performance of the code. It can be improved any time. Spot the idea. Base on it.

@koresar It surely can be stamp, but as @ericelliott said here  it would be another implicit dependency you would need to add to every stamp to expect instanceOf working. In this case especially if you don't compose with that stamp you would get nasty surprise of instanceOf working differently. So yea, it should be probably part of spec.

it would be another implicit dependency you would need to add to every stamp to expect instanceOf working.

It's the only downside, which can be corrected on the module level (like "stampit").
But think about huge performance implications both CPU and Memory. Also think about majority of the users who don't need that feature. Why should they suffer? Because Eric Elliott change his mind on the instanceof topic? :)

Well, the details of which entities were used in the creation of a factory function would be stored in the factory function, not the objects it creates. Each factory would have a method each object it creates then references. The factory could hold (possibly weak) references to the factories or propertyDescriptors themselves and allow a recursive search or, alternatively, some form of uuid could be used and each factory could gather an array of all the uuid strings. The first likely uses less memory if you have thousands of stamps. The second is likely faster. A third option would be something like immutable.js's trie structure which could be shared and extended but that introduces a dependency.

@far-blue you have described exactly the code above (same code in this article).

The factory (stamp) stores the entities in stamp.compose.configuration.wasComposedOf
Recursive search is where the _.union() is used

The UUID solution is something very unique.
=====
Few notes though.

It's too hard to create thousands of stamps (aka factories). But surely it is possible to create thousands of object instances.
You are confusing propertyDescriptors with "stamp descriptors". Totally different things. (I wish we named it "stamp metadata" instead.)

When all the additional memory use, little as it is, and cpu time is only consumed in the creation of the factories then the impact is going to be small.
Sorry, yes, you are right. It's a stamp descriptor object, not a propertyDescriptor. To be absolutely clear for everyone, I mean objects that look like this: https://github.com/stampit-org/stamp-specification#the-stamp-descriptor

I'd like to remind everyone that instanceof would rely on the composers feature. Which is experimentally implemented atm in the "stampit" module.

Because Eric Elliott changed his mind on the instanceof topic? :)

Let's not get crazy. instanceof's default behavior is deeply problematic, and I have not changed my mind about that.
However, making instanceof work by looking up a string-based tag (NOT identity based) could work across execution contexts, could work even if a prototype changes (just declare that the new prototype satisfies some tag's contract), and basically has none of the problems with the original instanceof behavior.
When circumstances change, we're allowed to adapt our stance. In fact, if you don't adapt your stance, you could get knocked over. ;)
That said, if it disables hidden class optimizations, that sucks. Which reminds me, engineering tradeoffs and stupidity are often indistinguishable if you're unaware of the tradeoffs. Turning off optimizations globally due to custom instanceof behavior in local objects strikes me as stupidity. Clearly I'm unaware of some tradeoffs in V8. ;)

@ericelliott
I'd test the new V8 v5.9.  We might want to come back to this topic.
It's good you mention the ES6 Symbol for String Tags.
Looks like it's working already in the current stamp spec:
$ node
> var o = Object.assign({}, {[Symbol.toStringTag]: 'MyFoo'})
o.toString()
'[object MyFoo]'

We could utilise that for the instanceof implementation.
    const stampStringTag = stamp.compose.properties[Symbol.toStringTag];
    statics[Symbol.hasInstance] = (instance) =>
      instance.toString() === `[object ${stampStringTag}]`

Or something like that.

A single instance could belong to any number of stamp type classes. Just space separate them in the string tag. Then you'll get a list of type classes satisfied by the instance. Cool?

In the short term, we could update a generic is util to see if an instance satisfies a stamp contract based on string tag.

A single instance could belong to any number of stamp type classes. Just space separate them in the string tag. Then you'll get a list of type classes satisfied by the instance. Cool?

Sorry, I didn't understand.
When talking about code I prefer code. Can you show some code of how you gonna separate stamp descriptors (not stamps)?

An instance is not made of a single stamp. An instance is made of a whole bunch of stamps which may allow that instance to conform to a lot of different interfaces. When looking at instances, we typically want to know "does this thing support this interface I want to use to manipulate this thing?"
The code in question usually doesn't know about or care about what particular stamp the thing popped out of.
For example... do we really need to know if the thing we're looking at is an array, or can we deal with anything that has a working .map(), .concat(), and .reduce()?
Usually, it's the latter. Anything with a compliant version of those methods will satisfy the following type classes:

Functor
Semigroup
Foldable

Looking at the particular stamp that produced an object should generally be considered an antipattern.
Looking at the interfaces satisfied by the object is a much more reliable way to program. Remember the Gang of Four advice: "Program to an interface, not an implementation."
Looking for the name of a particular stamp is equivalent to looking for a particular implementation.
In other words, it's not very useful to have instanceof look for === equality for a particular stamp name.
Instead, we could have the string tag for the above say Functor Semigroup Foldable instead of MyArrayLikeStamp.
Then our instanceof code could do:
const hasTypeClass = string => stringTag => stringTag.includes(string);

"does this thing support this interface I want to use to manipulate this thing?"
const hasInterface = interface => stringTag => stringTag.includes(interface);

That is similar to what my code above is doing. But it's using === reference equality instead of String.includes():
_.union(instance.getOrigins(), wasComposedOf) ...

Probably it's not the best solution. I'm more inclined toward the string tags as you suggest @ericelliott. It's more explicit, more developer and performance friendly.
Now, we need to solve last thing.
What API will be giving a (interface) name to a stamp?
My initial proposal: The Named stamp.
Tl;DR:
import Named from '@stamp/named'

const MyNamedStamp = MyRegularStamp.compose(Named).setName('MyNamedStamp')

But there could be better ES6 solutions.


https://ez4mods.com/

Link
https://ez4mods.com/
Version
Manifest-v2
What browser(s) are you using?
Chrome browsers (includes brave, edge, opera, etc)
What platform are you using?
Computer (Windows, Linux, MacOS)
(Optional) Anything else?
https://ez4mods.com/viber-messenger-mod-patched-unlocked/

ez4mods isn't the site that needs to be bypassed, it just has the download buttons that in this case redirected to

so please edit the issue to reflect that (oh and mv2 is expired)


npm run build fails from fresh pull

Current Behavior
When running npm run build after npm i from a fresh pull on my system I run into an error.
Any ideas what I might be doing wrong?
m:pixi.js m$ npm run build

> pixi.js-monorepo@ prebuild /Users/m/pixi.js
> npm run clean:build

> pixi.js-monorepo@ clean:build /Users/m/pixi.js
> rimraf "{bundles,packages,packages/canvas,packages/filters}/*/{lib,dist}"

> pixi.js-monorepo@ build /Users/m/pixi.js
> npm run build:dev

> pixi.js-monorepo@ build:dev /Users/m/pixi.js
> rollup -c

packages/constants/src/index.js → packages/constants/lib/constants.js, packages/constants/lib/constants.es.js...
created packages/constants/lib/constants.js, packages/constants/lib/constants.es.js in 73ms

packages/constants/src/index.js → packages/constants/dist/constants.js...
created packages/constants/dist/constants.js in 31ms

packages/math/src/index.js → packages/math/lib/math.js, packages/math/lib/math.es.js...
created packages/math/lib/math.js, packages/math/lib/math.es.js in 353ms

packages/math/src/index.js → packages/math/dist/math.js...
created packages/math/dist/math.js in 214ms

packages/polyfill/src/index.js → packages/polyfill/lib/polyfill.js, packages/polyfill/lib/polyfill.es.js...
created packages/polyfill/lib/polyfill.js, packages/polyfill/lib/polyfill.es.js in 59ms

packages/polyfill/src/index.js → packages/polyfill/dist/polyfill.js...
created packages/polyfill/dist/polyfill.js in 141ms

packages/runner/src/index.js → packages/runner/lib/runner.js, packages/runner/lib/runner.es.js...
created packages/runner/lib/runner.js, packages/runner/lib/runner.es.js in 54ms

packages/runner/src/index.js → packages/runner/dist/runner.js...
created packages/runner/dist/runner.js in 29ms

packages/settings/src/index.js → packages/settings/lib/settings.js, packages/settings/lib/settings.es.js...
created packages/settings/lib/settings.js, packages/settings/lib/settings.es.js in 38ms

packages/settings/src/index.js → packages/settings/dist/settings.js...
created packages/settings/dist/settings.js in 66ms

packages/unsafe-eval/src/index.js → packages/unsafe-eval/lib/unsafe-eval.js, packages/unsafe-eval/lib/unsafe-eval.es.js...
created packages/unsafe-eval/lib/unsafe-eval.js, packages/unsafe-eval/lib/unsafe-eval.es.js in 75ms

packages/unsafe-eval/src/bundle.js → packages/unsafe-eval/dist/unsafe-eval.js...
created packages/unsafe-eval/dist/unsafe-eval.js in 74ms

packages/ticker/src/index.js → packages/ticker/lib/ticker.js, packages/ticker/lib/ticker.es.js...
created packages/ticker/lib/ticker.js, packages/ticker/lib/ticker.es.js in 103ms

packages/ticker/src/index.js → packages/ticker/dist/ticker.js...
created packages/ticker/dist/ticker.js in 67ms

packages/utils/src/index.js → packages/utils/lib/utils.js, packages/utils/lib/utils.es.js...
created packages/utils/lib/utils.js, packages/utils/lib/utils.es.js in 124ms

packages/utils/src/index.js → packages/utils/dist/utils.js...
created packages/utils/dist/utils.js in 444ms

packages/display/src/index.js → packages/display/lib/display.js, packages/display/lib/display.es.js...
created packages/display/lib/display.js, packages/display/lib/display.es.js in 200ms

packages/display/src/index.js → packages/display/dist/display.js...
created packages/display/dist/display.js in 142ms

packages/core/src/index.js → packages/core/lib/core.js, packages/core/lib/core.es.js...
created packages/core/lib/core.js, packages/core/lib/core.es.js in 937ms

packages/core/src/index.js → packages/core/dist/core.js...
created packages/core/dist/core.js in 759ms

packages/mixin-get-child-by-name/src/index.js → packages/mixin-get-child-by-name/lib/mixin-get-child-by-name.js, packages/mixin-get-child-by-name/lib/mixin-get-child-by-name.es.js...
created packages/mixin-get-child-by-name/lib/mixin-get-child-by-name.js, packages/mixin-get-child-by-name/lib/mixin-get-child-by-name.es.js in 38ms

packages/mixin-get-child-by-name/src/index.js → packages/mixin-get-child-by-name/dist/mixin-get-child-by-name.js...
created packages/mixin-get-child-by-name/dist/mixin-get-child-by-name.js in 10ms

packages/mixin-get-global-position/src/index.js → packages/mixin-get-global-position/lib/mixin-get-global-position.js, packages/mixin-get-global-position/lib/mixin-get-global-position.es.js...
created packages/mixin-get-global-position/lib/mixin-get-global-position.js, packages/mixin-get-global-position/lib/mixin-get-global-position.es.js in 15ms

packages/mixin-get-global-position/src/index.js → packages/mixin-get-global-position/dist/mixin-get-global-position.js...
created packages/mixin-get-global-position/dist/mixin-get-global-position.js in 11ms

packages/canvas/canvas-display/src/index.js → packages/canvas/canvas-display/lib/canvas-display.js, packages/canvas/canvas-display/lib/canvas-display.es.js...
created packages/canvas/canvas-display/lib/canvas-display.js, packages/canvas/canvas-display/lib/canvas-display.es.js in 20ms

packages/canvas/canvas-display/src/index.js → packages/canvas/canvas-display/dist/canvas-display.js...
created packages/canvas/canvas-display/dist/canvas-display.js in 17ms

packages/extract/src/index.js → packages/extract/lib/extract.js, packages/extract/lib/extract.es.js...
created packages/extract/lib/extract.js, packages/extract/lib/extract.es.js in 42ms

packages/extract/src/index.js → packages/extract/dist/extract.js...
created packages/extract/dist/extract.js in 38ms

packages/loaders/src/index.js → packages/loaders/lib/loaders.js, packages/loaders/lib/loaders.es.js...
created packages/loaders/lib/loaders.js, packages/loaders/lib/loaders.es.js in 38ms

packages/loaders/src/index.js → packages/loaders/dist/loaders.js...
created packages/loaders/dist/loaders.js in 235ms

packages/mesh/src/index.js → packages/mesh/lib/mesh.js, packages/mesh/lib/mesh.es.js...
created packages/mesh/lib/mesh.js, packages/mesh/lib/mesh.es.js in 77ms

packages/mesh/src/index.js → packages/mesh/dist/mesh.js...
created packages/mesh/dist/mesh.js in 64ms

packages/particles/src/index.js → packages/particles/lib/particles.js, packages/particles/lib/particles.es.js...
created packages/particles/lib/particles.js, packages/particles/lib/particles.es.js in 92ms

packages/particles/src/index.js → packages/particles/dist/particles.js...
created packages/particles/dist/particles.js in 78ms

packages/sprite/src/index.js → packages/sprite/lib/sprite.js, packages/sprite/lib/sprite.es.js...
created packages/sprite/lib/sprite.js, packages/sprite/lib/sprite.es.js in 58ms

packages/sprite/src/index.js → packages/sprite/dist/sprite.js...
created packages/sprite/dist/sprite.js in 44ms

packages/canvas/canvas-extract/src/index.js → packages/canvas/canvas-extract/lib/canvas-extract.js, packages/canvas/canvas-extract/lib/canvas-extract.es.js...
created packages/canvas/canvas-extract/lib/canvas-extract.js, packages/canvas/canvas-extract/lib/canvas-extract.es.js in 23ms

packages/canvas/canvas-extract/src/index.js → packages/canvas/canvas-extract/dist/canvas-extract.js...
created packages/canvas/canvas-extract/dist/canvas-extract.js in 22ms

packages/canvas/canvas-renderer/src/index.js → packages/canvas/canvas-renderer/lib/canvas-renderer.js, packages/canvas/canvas-renderer/lib/canvas-renderer.es.js...
created packages/canvas/canvas-renderer/lib/canvas-renderer.js, packages/canvas/canvas-renderer/lib/canvas-renderer.es.js in 128ms

packages/canvas/canvas-renderer/src/index.js → packages/canvas/canvas-renderer/dist/canvas-renderer.js...
created packages/canvas/canvas-renderer/dist/canvas-renderer.js in 91ms

packages/filters/filter-alpha/src/index.js → packages/filters/filter-alpha/lib/filter-alpha.js, packages/filters/filter-alpha/lib/filter-alpha.es.js...
created packages/filters/filter-alpha/lib/filter-alpha.js, packages/filters/filter-alpha/lib/filter-alpha.es.js in 20ms

packages/filters/filter-alpha/src/index.js → packages/filters/filter-alpha/dist/filter-alpha.js...
created packages/filters/filter-alpha/dist/filter-alpha.js in 14ms

packages/filters/filter-blur/src/index.js → packages/filters/filter-blur/lib/filter-blur.js, packages/filters/filter-blur/lib/filter-blur.es.js...
created packages/filters/filter-blur/lib/filter-blur.js, packages/filters/filter-blur/lib/filter-blur.es.js in 49ms

packages/filters/filter-blur/src/index.js → packages/filters/filter-blur/dist/filter-blur.js...
created packages/filters/filter-blur/dist/filter-blur.js in 45ms

packages/filters/filter-color-matrix/src/index.js → packages/filters/filter-color-matrix/lib/filter-color-matrix.js, packages/filters/filter-color-matrix/lib/filter-color-matrix.es.js...
created packages/filters/filter-color-matrix/lib/filter-color-matrix.js, packages/filters/filter-color-matrix/lib/filter-color-matrix.es.js in 72ms

packages/filters/filter-color-matrix/src/index.js → packages/filters/filter-color-matrix/dist/filter-color-matrix.js...
created packages/filters/filter-color-matrix/dist/filter-color-matrix.js in 65ms

packages/filters/filter-displacement/src/index.js → packages/filters/filter-displacement/lib/filter-displacement.js, packages/filters/filter-displacement/lib/filter-displacement.es.js...
created packages/filters/filter-displacement/lib/filter-displacement.js, packages/filters/filter-displacement/lib/filter-displacement.es.js in 23ms

packages/filters/filter-displacement/src/index.js → packages/filters/filter-displacement/dist/filter-displacement.js...
created packages/filters/filter-displacement/dist/filter-displacement.js in 59ms

packages/filters/filter-fxaa/src/index.js → packages/filters/filter-fxaa/lib/filter-fxaa.js, packages/filters/filter-fxaa/lib/filter-fxaa.es.js...
created packages/filters/filter-fxaa/lib/filter-fxaa.js, packages/filters/filter-fxaa/lib/filter-fxaa.es.js in 17ms

packages/filters/filter-fxaa/src/index.js → packages/filters/filter-fxaa/dist/filter-fxaa.js...
created packages/filters/filter-fxaa/dist/filter-fxaa.js in 14ms

packages/filters/filter-noise/src/index.js → packages/filters/filter-noise/lib/filter-noise.js, packages/filters/filter-noise/lib/filter-noise.es.js...
created packages/filters/filter-noise/lib/filter-noise.js, packages/filters/filter-noise/lib/filter-noise.es.js in 19ms

packages/filters/filter-noise/src/index.js → packages/filters/filter-noise/dist/filter-noise.js...
created packages/filters/filter-noise/dist/filter-noise.js in 16ms

packages/accessibility/src/index.js → packages/accessibility/lib/accessibility.js, packages/accessibility/lib/accessibility.es.js...
created packages/accessibility/lib/accessibility.js, packages/accessibility/lib/accessibility.es.js in 61ms

packages/accessibility/src/index.js → packages/accessibility/dist/accessibility.js...
created packages/accessibility/dist/accessibility.js in 62ms

packages/app/src/index.js → packages/app/lib/app.js, packages/app/lib/app.es.js...
created packages/app/lib/app.js, packages/app/lib/app.es.js in 28ms

packages/app/src/index.js → packages/app/dist/app.js...
created packages/app/dist/app.js in 29ms

packages/graphics/src/index.js → packages/graphics/lib/graphics.js, packages/graphics/lib/graphics.es.js...
created packages/graphics/lib/graphics.js, packages/graphics/lib/graphics.es.js in 285ms

packages/graphics/src/index.js → packages/graphics/dist/graphics.js...
created packages/graphics/dist/graphics.js in 271ms

packages/mesh-extras/src/index.js → packages/mesh-extras/lib/mesh-extras.js, packages/mesh-extras/lib/mesh-extras.es.js...
created packages/mesh-extras/lib/mesh-extras.js, packages/mesh-extras/lib/mesh-extras.es.js in 72ms

packages/mesh-extras/src/index.js → packages/mesh-extras/dist/mesh-extras.js...
created packages/mesh-extras/dist/mesh-extras.js in 70ms

packages/mixin-cache-as-bitmap/src/index.js → packages/mixin-cache-as-bitmap/lib/mixin-cache-as-bitmap.js, packages/mixin-cache-as-bitmap/lib/mixin-cache-as-bitmap.es.js...
created packages/mixin-cache-as-bitmap/lib/mixin-cache-as-bitmap.js, packages/mixin-cache-as-bitmap/lib/mixin-cache-as-bitmap.es.js in 37ms

packages/mixin-cache-as-bitmap/src/index.js → packages/mixin-cache-as-bitmap/dist/mixin-cache-as-bitmap.js...
created packages/mixin-cache-as-bitmap/dist/mixin-cache-as-bitmap.js in 39ms

packages/sprite-animated/src/index.js → packages/sprite-animated/lib/sprite-animated.js, packages/sprite-animated/lib/sprite-animated.es.js...
created packages/sprite-animated/lib/sprite-animated.js, packages/sprite-animated/lib/sprite-animated.es.js in 35ms

packages/sprite-animated/src/index.js → packages/sprite-animated/dist/sprite-animated.js...
created packages/sprite-animated/dist/sprite-animated.js in 32ms

packages/sprite-tiling/src/index.js → packages/sprite-tiling/lib/sprite-tiling.js, packages/sprite-tiling/lib/sprite-tiling.es.js...
created packages/sprite-tiling/lib/sprite-tiling.js, packages/sprite-tiling/lib/sprite-tiling.es.js in 53ms

packages/sprite-tiling/src/index.js → packages/sprite-tiling/dist/sprite-tiling.js...
created packages/sprite-tiling/dist/sprite-tiling.js in 49ms

packages/spritesheet/src/index.js → packages/spritesheet/lib/spritesheet.js, packages/spritesheet/lib/spritesheet.es.js...
created packages/spritesheet/lib/spritesheet.js, packages/spritesheet/lib/spritesheet.es.js in 36ms

packages/spritesheet/src/index.js → packages/spritesheet/dist/spritesheet.js...
created packages/spritesheet/dist/spritesheet.js in 33ms

packages/canvas/canvas-particles/src/index.js → packages/canvas/canvas-particles/lib/canvas-particles.js, packages/canvas/canvas-particles/lib/canvas-particles.es.js...
created packages/canvas/canvas-particles/lib/canvas-particles.js, packages/canvas/canvas-particles/lib/canvas-particles.es.js in 27ms

packages/canvas/canvas-particles/src/index.js → packages/canvas/canvas-particles/dist/canvas-particles.js...
created packages/canvas/canvas-particles/dist/canvas-particles.js in 23ms

packages/canvas/canvas-sprite/src/index.js → packages/canvas/canvas-sprite/lib/canvas-sprite.js, packages/canvas/canvas-sprite/lib/canvas-sprite.es.js...
created packages/canvas/canvas-sprite/lib/canvas-sprite.js, packages/canvas/canvas-sprite/lib/canvas-sprite.es.js in 30ms

packages/canvas/canvas-sprite/src/index.js → packages/canvas/canvas-sprite/dist/canvas-sprite.js...
created packages/canvas/canvas-sprite/dist/canvas-sprite.js in 32ms

packages/text-bitmap/src/index.js → packages/text-bitmap/lib/text-bitmap.js, packages/text-bitmap/lib/text-bitmap.es.js...
created packages/text-bitmap/lib/text-bitmap.js, packages/text-bitmap/lib/text-bitmap.es.js in 70ms

packages/text-bitmap/src/index.js → packages/text-bitmap/dist/text-bitmap.js...
created packages/text-bitmap/dist/text-bitmap.js in 118ms

packages/text/src/index.js → packages/text/lib/text.js, packages/text/lib/text.es.js...
created packages/text/lib/text.js, packages/text/lib/text.es.js in 206ms

packages/text/src/index.js → packages/text/dist/text.js...
created packages/text/dist/text.js in 153ms

packages/canvas/canvas-graphics/src/index.js → packages/canvas/canvas-graphics/lib/canvas-graphics.js, packages/canvas/canvas-graphics/lib/canvas-graphics.es.js...
created packages/canvas/canvas-graphics/lib/canvas-graphics.js, packages/canvas/canvas-graphics/lib/canvas-graphics.es.js in 56ms

packages/canvas/canvas-graphics/src/index.js → packages/canvas/canvas-graphics/dist/canvas-graphics.js...
created packages/canvas/canvas-graphics/dist/canvas-graphics.js in 60ms

packages/canvas/canvas-mesh/src/index.js → packages/canvas/canvas-mesh/lib/canvas-mesh.js, packages/canvas/canvas-mesh/lib/canvas-mesh.es.js...
created packages/canvas/canvas-mesh/lib/canvas-mesh.js, packages/canvas/canvas-mesh/lib/canvas-mesh.es.js in 102ms

packages/canvas/canvas-mesh/src/index.js → packages/canvas/canvas-mesh/dist/canvas-mesh.js...
created packages/canvas/canvas-mesh/dist/canvas-mesh.js in 70ms

packages/canvas/canvas-sprite-tiling/src/index.js → packages/canvas/canvas-sprite-tiling/lib/canvas-sprite-tiling.js, packages/canvas/canvas-sprite-tiling/lib/canvas-sprite-tiling.es.js...
created packages/canvas/canvas-sprite-tiling/lib/canvas-sprite-tiling.js, packages/canvas/canvas-sprite-tiling/lib/canvas-sprite-tiling.es.js in 18ms

packages/canvas/canvas-sprite-tiling/src/index.js → packages/canvas/canvas-sprite-tiling/dist/canvas-sprite-tiling.js...
created packages/canvas/canvas-sprite-tiling/dist/canvas-sprite-tiling.js in 18ms

packages/interaction/src/index.js → packages/interaction/lib/interaction.js, packages/interaction/lib/interaction.es.js...
created packages/interaction/lib/interaction.js, packages/interaction/lib/interaction.es.js in 170ms

packages/interaction/src/index.js → packages/interaction/dist/interaction.js...
created packages/interaction/dist/interaction.js in 132ms

packages/prepare/src/index.js → packages/prepare/lib/prepare.js, packages/prepare/lib/prepare.es.js...
created packages/prepare/lib/prepare.js, packages/prepare/lib/prepare.es.js in 63ms

packages/prepare/src/index.js → packages/prepare/dist/prepare.js...
created packages/prepare/dist/prepare.js in 51ms

packages/canvas/canvas-text/src/index.js → packages/canvas/canvas-text/lib/canvas-text.js, packages/canvas/canvas-text/lib/canvas-text.es.js...
created packages/canvas/canvas-text/lib/canvas-text.js, packages/canvas/canvas-text/lib/canvas-text.es.js in 17ms

packages/canvas/canvas-text/src/index.js → packages/canvas/canvas-text/dist/canvas-text.js...
created packages/canvas/canvas-text/dist/canvas-text.js in 16ms

bundles/pixi.js/src/index.js → bundles/pixi.js/lib/pixi.js, bundles/pixi.js/lib/pixi.es.js...
created bundles/pixi.js/lib/pixi.js, bundles/pixi.js/lib/pixi.es.js in 126ms

bundles/pixi.js/src/index.js → bundles/pixi.js/dist/pixi.js...
created bundles/pixi.js/dist/pixi.js in 2.9s

packages/canvas/canvas-prepare/src/index.js → packages/canvas/canvas-prepare/lib/canvas-prepare.js, packages/canvas/canvas-prepare/lib/canvas-prepare.es.js...
created packages/canvas/canvas-prepare/lib/canvas-prepare.js, packages/canvas/canvas-prepare/lib/canvas-prepare.es.js in 109ms

packages/canvas/canvas-prepare/src/index.js → packages/canvas/canvas-prepare/dist/canvas-prepare.js...
created packages/canvas/canvas-prepare/dist/canvas-prepare.js in 18ms

bundles/pixi.js-legacy/src/index.js → bundles/pixi.js-legacy/lib/pixi-legacy.js, bundles/pixi.js-legacy/lib/pixi-legacy.es.js...
created bundles/pixi.js-legacy/lib/pixi-legacy.js, bundles/pixi.js-legacy/lib/pixi-legacy.es.js in 16ms

bundles/pixi.js-legacy/src/index.js → bundles/pixi.js-legacy/dist/pixi-legacy.js...
created bundles/pixi.js-legacy/dist/pixi-legacy.js in 3.2s

> pixi.js-monorepo@ postbuild /Users/m/pixi.js
> npm run types

> pixi.js-monorepo@ types /Users/m/pixi.js
> npm run types:legacy && npm run types:default

> pixi.js-monorepo@ types:legacy /Users/m/pixi.js
> mkdirp dist/types && jsdoc -c types/jsdoc-legacy.conf.json && node types/assemble pixi.js-legacy

There are no input files to process.
	fs.js:115
throw err;
^

Error: ENOENT: no such file or directory, open '/Users/m/pixi.js/dist/types/pixi.js-legacy.d.ts'
at Object.openSync (fs.js:436:3)
at Object.readFileSync (fs.js:341:35)
at Object.<anonymous> (/Users/m/pixi.js/types/assemble.js:19:17)
	at Module._compile (internal/modules/cjs/loader.js:688:30)
	at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10)
	at Module.load (internal/modules/cjs/loader.js:598:32)
	at tryModuleLoad (internal/modules/cjs/loader.js:537:12)
	at Function.Module._load (internal/modules/cjs/loader.js:529:3)
	at Function.Module.runMain (internal/modules/cjs/loader.js:741:12)
	at startup (internal/bootstrap/node.js:285:19)
	npm ERR! code ELIFECYCLE
	npm ERR! errno 1
	npm ERR! pixi.js-monorepo@ types:legacy: `mkdirp dist/types && jsdoc -c types/jsdoc-legacy.conf.json && node types/assemble pixi.js-legacy`
	npm ERR! Exit status 1
	npm ERR!
	npm ERR! Failed at the pixi.js-monorepo@ types:legacy script.
	npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

	npm ERR!      /Users/m/.npm/_logs/2019-07-21T05_19_45_203Z-debug.log
	npm ERR! code ELIFECYCLE
	npm ERR! errno 1
	npm ERR! pixi.js-monorepo@ types: `npm run types:legacy && npm run types:default`
	npm ERR! Exit status 1
	npm ERR!
	npm ERR! Failed at the pixi.js-monorepo@ types script.
	npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

	npm ERR!      /Users/m/.npm/_logs/2019-07-21T05_19_45_225Z-debug.log
	npm ERR! code ELIFECYCLE
	npm ERR! errno 1
	npm ERR! pixi.js-monorepo@ postbuild: `npm run types`
	npm ERR! Exit status 1
	npm ERR!
	npm ERR! Failed at the pixi.js-monorepo@ postbuild script.
	npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

	npm ERR!      /Users/m/.npm/_logs/2019-07-21T05_19_45_256Z-debug.log

Environment

pixi.js version: 5.1
Browser & Version: Chrome 75
OS & Version: MacOS 10.14.5

What Node.js version are you running?

@bigtimebuddy I was running v10.14.1 so upgraded to v10.16.0 LTS but no dice :(

@mudcube I have the same problem
`> pixi.js-monorepo@ docs /Users/vvadmin/work/pixi.js

mkdirp dist && jsdoc -c jsdoc.conf.json -R README.md

fs.js:130
throw err;
^
Error: ENOENT: no such file or directory, open 'fs'
at Object.openSync (fs.js:451:3)
at Object.readFileSync (fs.js:353:35)
at loadSource (/Users/vvadmin/work/pixi.js/node_modules/requizzle/lib/loader.js:132:32)
at Object.createWrapper (/Users/vvadmin/work/pixi.js/node_modules/requizzle/lib/loader.js:158:8)
at Requizzle.requizzle (/Users/vvadmin/work/pixi.js/node_modules/requizzle/lib/requizzle.js:87:19)
at infectProxy (/Users/vvadmin/work/pixi.js/node_modules/requizzle/lib/loader.js:82:28)
at Module.targetModule.require (/Users/vvadmin/work/pixi.js/node_modules/requizzle/lib/loader.js:101:11)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/Users/vvadmin/work/pixi.js/node_modules/jsdoc/lib/jsdoc/fs.js:7:10)
at Module._compile (internal/modules/cjs/loader.js:945:30) {
errno: -2,
syscall: 'open',
code: 'ENOENT',
path: 'fs'
}`

@mudcube I have a same problem,and I find the error throw in node_modules/requizzle/lib/requizzle.js:87:19
function isNativeModule(targetPath, parentModule) { 	var lookupPaths = Module._resolveLookupPaths(targetPath, parentModule); 	if (lookupPaths && lookupPaths[0] === targetPath && lookupPaths[1].length === 0) { 		return true; 	} 	return false; }

@mudcube I have a same problem,and I find the error throw in (node_modules/requizzle/lib/requizzle.js)
function isNativeModule(targetPath, parentModule) {
	var lookupPaths = Module._resolveLookupPaths(targetPath, parentModule);
	if (lookupPaths[0] === targetPath && lookupPaths[1].length === 0) {
		return true;
	}
	return false;
}

You can update the version of JSDoc in package.json, and run npm install again: for example:
"jsdoc": "^3.6.3",

isNativeModule(targetPath, parentModule) {
var lookupPaths = Module._resolveLookupPaths(targetPath, parentModule);
if (lookupPaths[0] === targetPath && lookupPaths[1].length === 0) {
return true;
}
return false;

isNativeModule(targetPath, parentModule) {
var lookupPaths = Module._resolveLookupPaths(targetPath, parentModule);
if (lookupPaths[0] === targetPath && lookupPaths[1].length === 0) {
return true;
}
return false;[isNativeModule(targetPath, parentModule) { 	var lookupPaths = Module._resolveLookupPaths(targetPath, parentModule); 	if (lookupPaths[0] === targetPath && lookupPaths[1].length === 0) { 		return true; 	} 	return false;](isNativeModule(targetPath, parentModule) { 	var lookupPaths = Module._resolveLookupPaths(targetPath, parentModule); 	if (lookupPaths[0] === targetPath && lookupPaths[1].length === 0) { 		return true; 	} 	return false;)


balloons: set frequency scaling governor only when requested

Avoid enforcing the frequency scaling governor if the user hasn't explicitly requested it. Previously, we attempted to set it regardless, leading to unnecessary error logs. Furthermore, fix formatting issue when logging error case.

Thanks @askervin for spotting the bug. PTAL
cc @klihub

@klihub I have now removed the leftover loop.

Looking at the governor solution in high level (first implementation and this patch), I'm starting to think that we are adding unnecessary complexity. And I'm slightly worried about it, as we should be adding here other controls as well. If we'd follow the same pattern then, there would be possibly third enforeCpufreqXXX (C-state controls and/or something else) that would needed to be called in the sequence of these two. Currently the two already have different assumption on who is checking if the class exists.
Instead of this complexity and introducing new function --- please tell me if I'm mistaken --- we could add only a single if to the original enforeCpufreq() after checking that the class exists. If governor is defined, then set it to the CPUs, and that's it. We would not need to introduce extra function, or have different error paths.
What do you think, @fmuyassarov and @klihub , could this be stripped down to single "if", which would make much easier to add new controls in the future in the same two-line manner?

Looking at the governor solution in high level (first implementation and this patch), I'm starting to think that we are adding unnecessary complexity. And I'm slightly worried about it, as we should be adding here other controls as well. If we'd follow the same pattern then, there would be possibly third enforeCpufreqXXX (C-state controls and/or something else) that would needed to be called in the sequence of these two. Currently the two already have different assumption on who is checking if the class exists.
Instead of this complexity and introducing new function --- please tell me if I'm mistaken --- we could add only a single if to the original enforeCpufreq() after checking that the class exists. If governor is defined, then set it to the CPUs, and that's it. We would not need to introduce extra function, or have different error paths.
What do you think, @fmuyassarov and @klihub , could this be stripped down to single "if", which would make much easier to add new controls in the future in the same two-line manner?

I think it makes sense.

Looking at the governor solution in high level (first implementation and this patch), I'm starting to think that we are adding unnecessary complexity. And I'm slightly worried about it, as we should be adding here other controls as well. If we'd follow the same pattern then, there would be possibly third enforeCpufreqXXX (C-state controls and/or something else) that would needed to be called in the sequence of these two. Currently the two already have different assumption on who is checking if the class exists.
Instead of this complexity and introducing new function --- please tell me if I'm mistaken --- we could add only a single if to the original enforeCpufreq() after checking that the class exists. If governor is defined, then set it to the CPUs, and that's it. We would not need to introduce extra function, or have different error paths.
What do you think, @fmuyassarov and @klihub , could this be stripped down to single "if", which would make much easier to add new controls in the future in the same two-line manner?

Sounds like a really good idea to me. We should consider the governor part of the freq. setting and things get much cleaner.

@askervin @klihub I have refactored the code now. PTAL.

In my opinion, we should not introduce a fatal failure due to missing parameters for a CPU class.

+1. Definitely not.

ping @askervin


More Detailed NZBGet Info

As it stands, if an item in NZBget is doing anything but downloading, it just says paused. More detailed info would be amazing

Status (string)- Status of the group:
QUEUED - queued for download;
PAUSED - paused;
DOWNLOADING - item is being downloaded;
FETCHING - nzb-file is being fetched from URL (Kind=URL);
PP_QUEUED - queued for post-processing (completely downloaded);
LOADING_PARS - stage of par-check;
VERIFYING_SOURCES - stage of par-check;
REPAIRING - stage of par-check;
VERIFYING_REPAIRED - stage of par-check;
RENAMING - processed by par-renamer;
UNPACKING - being unpacked;
MOVING - moving files from intermediate directory into destination directory;
EXECUTING_SCRIPT - executing post-processing script;
PP_FINISHED - post-processing is finished, the item is about to be moved to history.

I'm a little pressed for time this week, but it's a very easy request so I will get it done

@slamanna212 Was this latest changed enough info for you?

Much better! Thanks a ton!


Update Readme (>= RN 0.29 for android)

Hello,
Added in README the note that the plugin needs at least RN 0.29 for Android.  (issue #19)
Thx :)

thanks!


[Music] Add "Generate Playlist" Command

Extension
https://www.raycast.com/fedevitaledev/music
Description
I would love a "Generate Playlist" Command like in the Spotify Extension.
Who will benefit from this feature?
No response
Anything else?
No response

Hey this is not possible due to api limitations. I'm sorry.

@raycastbot close this issue


Add a naive canvas animation system

This PR adds an animated canvas drawing system for the canvas components. Similarly to the regular animation system it runs on d3-interpolate, however we have to do the animation work ourself, because we are directly manipulating the canvas. This addresses #417

It runs a little clumsily when there are multiple animations running at once. Would be delighted to hear what someone who knows this stuff better has to say. That said, when it runs well, it runs significantly more smoothly than the same svg animations for medium volume data
(This PR Also update canvas so that there is a margin on the canvas itself.)

review bump?


[Snackbar] Make on request close optional

[x] PR has tests / docs demo, and is linted.
[ ] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[ ] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

Closes #3485

@rkmax I think that this PR can be a single one line change. If you want to add some test, that's awesome, but I think that you can do it in another PR. If you don't have time to restart this PR. I can take care of this. Thanks.

@rkmax ping! Can you clean up the linting errors?

of course @nathanmarks

@nathanmarks ping! linting errors were fixed

@rkmax cheers!

@rkmax that looks good! Could you squash down the commits?

@oliviertassinari thanks!!!

@oliviertassinari let me know if the new squashed commit format is correct

@rkmax Thanks :+1:.


Validate control on copy in group controls

Related to https://github.com/datalens-tech/datalens/issues/89

i18n-check

The following components have not been translated
dash.group-controls-dialog.edit (ru)dash.group-controls-dialog.edit (en)

Wait for the reviewers to check your changes in Weblate and try running github action again.


Key Stroke combination in example gif

Issue Type: Feature Request
Can you include the key stroke alongwith the example in the gif or any animation that you provide as an exmaple of Extenstion under the Details section.
VS Code version: Code 1.38.1 (b37e54c98e1a74ba89e03073e5a3761284e3ffb0, 2019-09-11T13:35:15.005Z)
OS version: Windows_NT x64 10.0.18362

Extension authors provide this content, so your request needs to be logged at each extension's repo.


[Feature]Calendar begin with Sunday

Hi
I really love this tools
Very flexible!
Thanks for sharing
the feature that setting Calendar begin with Sunday will make the experience better and good for different  habits people
Thank you!

concur; it's easy to change in the javascript code, but ideally pulled out as a configuration item.
set firstDay:0 in $:/plugins/nico/projectify/ui/widgets/date-picker.js
Big fan of projectify!

Thank you! It’s work!

Done in commit 30f8ed0, closing.


Lego Dimensions won’t connect to Wii u

I have a Raspberry Pi Zero W with Raspberry Pi OS Lite (legacy, bullseye) installed (because that was the only one I could get to work) and it won’t communicate with the Wii U, I have the server up and running but no connection, any suggestions?

Please give this: https://github.com/Berny23/LD-ToyPad-Emulator/discussions/188 a try.
Should be easier to start with.

I fixed it by using Raspberry Pi Lite Legacy Bullseye instead of Raspberry Pi Lite bookworm otherwise you will get error such file or directory, open '/dev/hidg0' and then tried a bunch of different cables in order to ensure it has data transmission but thank you :)

Also had issues with the latest releases. Will  update the "step-by-step" guide.


Unable to get Reflex CLI working

Hi,
I'm unable to get the Reflex CLI working properly in my environment. When I try to run any reflex command like reflex --help or reflex init, I get errors saying it's not a valid command.
I'm running:
macOS 13.4.1 (c)
Python 3.11.3
pip 22.2.1
browser: Arc
Steps I've tried:
Installing reflex-cli via pip and pipx, brew
Creating a new virtual environment
Reinstalling reflex-cli in the activated virtualenv
Using full path to reflex
Ensuring virtualenv bin directory is on PATH
Output of diagnostics:

pip list:
reflex-cli 1.3.3

which reflex
/Users/gmaria/willowhealth/willow_health/llm_project/llm_pet_project/venv/bin/reflex

reflex --help
'build' is not a reflex command. See 'reflex --help'.

Do you have any advice on other things I could try or reasons this might be happening? I'm unable to initialize or deploy Reflex projects due to the CLI commands not being recognized.

Hi @mariascedasticity the reflex cli comes with the reflex package, I believe what you want to do is install reflex via pip install reflex. Also make sure to install reflex in a virtual environment(poetry, venv, pyenv, etc)

I thought I tried it as well, but now it's working. Thanks!


Missing config files

Hey @agoose77 the repository is missing the .xyz configuration files (git ignore, prettier and eslint). If you started the repo with the cookiecutter template, you probably miss them in the first commit as their names start with a dot. Could you please push them?

Huh, good catch. Let me restore them


feat: Compare card of subgroup to card of group

Includes new lemmas, one that shows that the cardinality of a subgroup is at most the cardinality of the ambient group, and others which shows that the cardinality of the top group is equal to that of the ambient group, and that in fact this is iff.
Co-authored-by: Floris van Doorn

Maintainers, let me know if we are not accepting PRs to ported files yet

new results are fine to add (maybe not new instances, depending on the situation), but refactors will probably be forced to wait until after the port. Also, just FYI, we no longer specify the filename in the PR description.

Ok cool no refactors here, just new lemmas

bors merge


ClangdSwitchSourceHeader causes lua error on Nvim 0.6.x due to signature change of vim.lsp.buf_request

nvim --version: NVIM v0.6.0-dev+227-gc1f573fbc
nvim-lspconfig version(commit hash): 01153c5
What language server (If the problem is related to a specific language server): clangd
Can you reproduce this behavior on other language server clients (vscode, languageclient-neovim, coc.nvim, etc.): -
Can you reproduce this behavior on other language servers offered in the nvim-lspconfig repo? (pyls -> pyright): -
Is the problem isolated to a particular language server: vim.lsp.buf_request also appears in rust_analyzer and texlab, so I imagine the same problem exists there.
Operating system/version: Linux

How to reproduce the problem from neovim startup

Go to a directory containing a C++ project with two files, test.h and test.cpp
Open test.h
When the language server has successfully attached, run :ClangdSwitchSourceHeader

Actual behaviour
The error Error executing vim.schedule lua callback: .../tools/neovim/install/share/nvim/runtime/lua/vim/uri.lua:96: attempt to call method 'match' (a nil value) is raised
Expected behaviour
The file test.cpp is opened for editing.
Minimal init.vim or init.lua and code sample
require('packer').startup(function(use)
  use 'wbthomason/packer.nvim'
  use {
    'neovim/nvim-lspconfig',
    config = function()
      local lspconfig = require('lspconfig')
      lspconfig.clangd.setup({
        cmd = { 'clangd', '--background-index'},
      })
  }
end)

Health check

Checkhealth result
health#lspconfig#check
========================================================================
## Checking language server protocol configuration
  - INFO: clangd: configuration checked.

LSP log
I'll skip this.
Diagnosis
Apparently, the signature of vim.lsp.buf_request has changed from the 0.5.x release to the current 0.6.x nightly build. In particular, the function handler signature is now function(err, result, ctx, config) (see :help lsp-handler), while it was function(err, method, result, client_id, bufnr, config) in 0.5.x.
As a result, the function switch_source_header in clangd.lua passes the ctx param to vim.uri_to_fname instead of the intended result param, which leads to aforementioned error.

The linked bisect shows which commit in neovim broke it.


JS has only made partial progress to catch up to UIKit

This was a really weird random error. I'll do my best to explain what happened. I have a 3 deep nested layout. So the first page is a list of models. then you click on the models to get master detail lists. When I click around a lot in the master detail page and go back to the dashboard, it gives me this error.
I feel like it has to do with me clicking too fast and triggering things too fast, but how can I prevent this?
[error][tid:main][RCTNavigator.m:471] JS has only made partial progress to catch up to UIKit

This has been reported a bunch already, #65 being the earliest report of it :smile:
I'd recommend searching issues in the future when you run into issues like this, you might even find a solution that way!


same aka deepEquals failed when object has anonymous function

The following will failed:
test("deepEqual shouldn't fail when objects contain anonymous functions", function(t) {
  var a = { val: 5, ano: function() { return val } }
  var b = { val: 5, ano: function() { return val } }

  t.deepEquals(a, a)
  t.end()
})

The culprit is line 58 in only-shallow
My use case is testing Functors.
const plus3 = x => x+3

const fmap = (f, F) => {
  if(F instanceof Nothing) return F
  return F.fmap((f(F.val)))
}
function Just(val) {
  if(this == undefined) return new Just(val)
  this.val = val
  this.fmap = x => new Just(x)
}
function Nothing() {
  if(this == undefined) return new Nothing
  this.fmap = x => new Nothing
}
function Maybe(val) {
  if(val == undefined) return new Nothing
  return new Just(val)
}

tap.same(fmap(plus3, Just(2)), Just(5), "fmap knows how to apply functions to values that are wrapped in a context.")

The above fails:
TAP version 13
not ok 1 - fmap knows how to apply functions to values that are wrapped in a context.
  ---
  found:
    val: 5
    fmap: x => new Just(x)
  wanted:
    val: 5
    fmap: x => new Just(x)

I suggest testing for functions in shallower_ and do a char by char comparison of function.toString(), similar to tap.equal("hello", "hello")

Discussed and explained here: https://github.com/othiym23/only-shallow/issues/4#issuecomment-218922265
Working as designed, sorry.

No hard feelings @isaacs  :) I was just puzzled for while and a bit distracted by a deadline in an arguable more important project.

@isaacs just wanna add that t.like is awesome! I'm trying to grok Functors and in this kind of experiments t.like is like magic dust spread out from unicorns!
While I know what return values I want from my functions, I've been making small changes to the return type etc. But t.like still gets what I mean!
Here it is in its entirety:
"use strict"

// http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
// run with node  --harmony_rest_parameters Functor.js

const tap = require("tap")

// Test function
const plus3 = x => x + 3
const plus2 = x => x + 2

// Functors
// (a->b), fa -> fb
const fmap = (f, F) => F.fmap( x => f(x) )

function Just(val) {
  if(!new.target) return new Just(val)
  this.fmap = f => f(val)
}

function Maybe(val) {
  return val == undefined ? new Nothing : new Just(val)
}

function Nothing() {
  if(!new.target) return new Nothing
  this.fmap = () => Nothing
}

class List extends Array {
  constructor(...args) {
    super(...args.map(x => Maybe(x)))
  }
  fmap(f) {
    return this.map(fa => fa.fmap(f))
  }
}

Function.prototype.fmap = function(f) {
  const self = this
  return x => self(f(x))
}

// Tests
tap.like( Just(2), Just, "fmap knows how to apply functions to values that are wrapped in a context.")
tap.like( fmap(plus3, Just(2)), 5, "fmap knows how to apply functions to values that are wrapped in a context.")

tap.like( fmap(plus3, Nothing()), Nothing, "you start with Nothing, and you end up with Nothing!")

tap.like( Maybe(2), Just, "Maybe is a Functor. It specifies how fmap applies to Justs and Nothings.")
tap.like( Maybe(), Nothing, "Maybe is a Functor. It specifies how fmap applies to Justs and Nothings.")
tap.like( fmap(plus3, Maybe(2)), 5, "Maybe is a Functor. It specifies how fmap applies to Justs and Nothings.")
tap.like( fmap(plus3, Maybe()), Nothing, "Maybe is a Functor. It specifies how fmap applies to Justs and Nothings.")

tap.like( fmap(getPostTitle, findPost(1)), 'Anakia', "findPost sometimes return null but the return value will always be wrapped in a Maybe")
tap.like( fmap(getPostTitle, findPost(2)), Nothing, "findPost sometimes return null but the return value will always be wrapped in a Maybe")

tap.like( new List(2,4,6) , [Just,Just,Just] , "What happens when you apply a function to a list? Should be Just objects." )
tap.like( fmap(plus3, new List(2,4,6)) , [5,7,9] , "What happens when you apply a function to a list? 3 higher than input." )
tap.like( fmap(plus3, new List(2,null,6)) , [5,Nothing,9] , "What happens when you apply a function to a list? Null values are wrapped in Nothing" )

const foo = fmap( plus3, plus2 )
tap.like(foo(10), 15, "So functions are Functors too!")

function getPostTitle (post) { return post.title }
function findPost(n) {
  return new Maybe(
    n === 1 ? { title: 'Anakia' } : null
  )
}


Test sriov over vlan

What this PR does / why we need it:
we need to improve sriov testing.
so in this pr we:

Change pingVirtualMachine to return
a error and move the assertion outside of it's scope.
This is done so that we can assert that the ping failed as well.

warped the http requests for creating network function and deleting
network attachment definitions.

Test  connectivity between two
VMs that share vlan over an SRIOV network.
A third vm without which do not share the
vlan should not get connected.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

second commit relies on the change in the first one, because as a part of the test we check that a ping to a vm which is not connected to vlan- fails.
if this PR would be approved , we will add follow up PR to wrap all not pretty http requests in functions. I thought it was not related to this PR so I made it just in the SRIOV scope.
Release note:

/retest

Overall, quite good.
I do request you split the one big test into 2 smaller ones, which helps readability.
Plus, please rework the commit messages on the commits.

"make pingVirtualMachine a helper function" => it was already an helper function. now you just return the error, to perform extra asserts on it. Which, I'm unsure asserting the error string is required - I haven't seen that much (if at all) on kubevirt project.

Yeah, we apparently sometimes do: https://github.com/kubevirt/kubevirt/pull/3268/commits/5c566d6e6dcecef813de9530faebb10a0a8de2b5
Not sure your scenario warrants it though. But feel free to keep it.

"Test connectivity with vlan over SRIOV network" => some of typos there (shoould vs should), and the line length is not properly used: the limit is 80 chars. Feels like you're limiting yourself to use 40.

Shouldn't this change include [test_id:3958], to automate https://polarion.engineering.redhat.com/polarion/#/project/CNV/workitem?id=CNV-3958? I can't find it.

Shouldn't this change include [test_id:3958], to automate https://polarion.engineering.redhat.com/polarion/#/project/CNV/workitem?id=CNV-3958? I can't find it.

Thank you @yossisegev   for the catch.
Changed that.

Overall, quite good.
I do request you split the one big test into 2 smaller ones, which helps readability.
Plus, please rework the commit messages on the commits.

"make pingVirtualMachine a helper function" => it was already an helper function. now you just return the error, to perform extra asserts on it. Which, I'm unsure asserting the error string is required - I haven't seen that much (if at all) on kubevirt project.
"Test connectivity with vlan over SRIOV network" => some of typos there (shoould vs should), and the line length is not properly used: the limit is 80 chars. Feels like you're limiting yourself to use 40.

Thanks @maiqueb for the thorough review, made the changes you asked and some other.
Also replied to your comments with some questions, and I would appreciate  your answer :)

Reviewed automation of [test_id:3958] - LGTM (both positive and negative flow of this test-case are covered).

Reviewed automation of [test_id:3958] - LGTM (both positive and negative flow of this test-case are covered).

Thanks @yossisegev

Thank you @maiqueb for the review. removed the comment.
I don't think this PR is related to the failed CI. let's see if it happens again

/retest

/retest

@alonSadan seems like the new test is failing.
Are you working on it? I prefer to do the review on a working test.

@AlonaKaplan
yes, working on that.
It's weird because on my local env it passes...
I will update what came up.
Thanks

@AlonaKaplan  This time the test didn't fail, another one did, and the after-suite. For the after-suite I think this https://github.com/kubevirt/kubevirt/pull/3734 addresses the issue.
Also locally it passes.
Do you think now you can review it?
Tnx

@AlonaKaplan This time the test didn't fail, another one did, and the after-suite. For the after-suite I think this #3734 addresses the issue.
Also locally it passes.
Do you think now you can review it?
Tnx

Did you change something to make it pass?

@AlonaKaplan This time the test didn't fail, another one did, and the after-suite. For the after-suite I think this #3734 addresses the issue.
Also locally it passes.
Do you think now you can review it?
Tnx

Did you change something to make it pass?

@AlonaKaplan
I did add link_state = enable to the NAD, so now it will be up independently of the PF state.  This might have did the trick...

/retest

@alonSadan next time please add review changes to a separate commit.

/approve

/test pull-kubevirt-e2e-kind-1.17-sriov

/hold
@alonSadan you can remove the hold once the sriov lane is passing - https://prow.apps.ovirt.org/?repo=kubevirt%2Fkubevirt&pull=3479

/lgtm

@alonSadan please update the release note to NONE (currently the PR has do-not-merge/release-note-label-needed label)

@alonSadan please update the release note to NONE (currently the PR has do-not-merge/release-note-label-needed label)

@AlonaKaplan Thanks.
Done.

Commits that are responding to reviews should not reach the master branch.
The main branch should have a proper change history with logical changes and proper commit messages.
Please squash the needed into the appropriate commits.

Thanks @EdDev. Done.

/test pull-kubevirt-e2e-k8s-1.16

Thank you @EdDev  for the review and I am sorry for the commit mix-up. I responded with some questions to some of your comments, and I would much appreciate a re-review , after CI will pass.

about https://github.com/kubevirt/kubevirt/pull/3479#discussion_r458305968
(for some reason it won't let me replay directly to the comment...)
I forgot to respond there  back then so will respond here:
there is no point to state the IP because we are pinging the domain. I changed the
error formatting to be "VMI %s was not able to ping google.com domain"
and I hope this will make it clearer.

about https://github.com/kubevirt/kubevirt/pull/3479#discussion_r458305172
Done

/retest

/test pull-kubevirt-e2e-kind-1.17-sriov

/retest

Thanks @EdDev.
you are invited for another round:)

/approve cancel
since 28 days passed since the PR was approved and it was significantly changed I'm removing the approve.
@alonSadan please let me know when the Pr has lgtm so I will re-review.

/retest

/test pull-kubevirt-e2e-k8s-1.17

Hey @AlonaKaplan
since @EdDev  lgtmed there were almost no changes (one nit or so), and the failing CI seems to not be related to change.
I think the PR is ready for a re-review. Would you?
Thanks.

The SRIOV lane is no longer running due to other problems.
/hold cancel

You can run sriov lane manually with:
/test pull-kubevirt-e2e-k8s-1.17

/test pull-kubevirt-e2e-k8s-1.17

@ormergi
you can tale a look here https://github.com/kubevirt/kubevirt/pull/3479#discussion_r465523745
regarding the error formatting in the Expect

/test pull-kubevirt-e2e-k8s-1.17

/lgtm

/retest

/approve

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

removed redundant batcher.ExP which cause trouble (and the tests to fail) with the new safe expect.batcher. made that change in a different commit.

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/retest

/retest

/retest

/retest

/lgtm

removed redundant batcher.ExP which cause trouble (and the tests to fail) with the new safe expect.batcher. made that change in a different commit.

removed this change since this is handled here : https://github.com/kubevirt/kubevirt/pull/4001

@AlonaKaplan can you take a look at this?
Plus, two more changes to the test itself:

added a check for a successful configuration of the pinging interface
adjusted the pingFromVMConsole args to not include prompt.

update: The test I added passes, but it seems as though our SRIOV lane is a bit flaky now, and some other tests won't pass.
even on my local machine on master.

/retest

/approve cancel
This PR changed quite a bit since the approval.

/hold

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

a lot of changes since the last time worked on this. most of them cosmetics, but the main diff is that the sriov name is now found using it's mac. also divided the one big context before to two different context , I think it is more understandable this way.

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

Review of the first commit:
Please split it into multiple commits, each doing a single logical change that can be reasoned for.
There is no need to explain "how" that change was done, unless it is too complex to read from the code. It should focus on "why" and maybe a sentence about the what (e.g. "extracted into helpers").
A an example, why mac is required now to build the VMI spec is not explained.

Thank you @EdDev  for the review, I split the first commit, and   addresses most of your comments. Also  replied  to some

I warped the ping command in an Eventually in the spirit of  @qinqon  change

commit: tests, vmi_multus: test Sriov with Vlan

I think you do not need 2 new NAD/s, one with a VLAN definition should be enough.

All tests are using a flat structure, but the new tests added here indent multiple contexts in which seems more confusing than helpful.

Creating a SRIOV VMI with VLAN definition is a test by itself, no? If so, it does not need to be in the fixture.

It seems to me that the most appropriate thing to do here is to re-use createSriovVMs somehow. (maybe by changing its signature to: func(networkName string, cidrs ...string))

I would expect to see here no additional contexts or max one.
e.g.:

Context("With VLAN") // Create one VMI with VLAN
It("has connectivity to a VMI on the same VLAN...")
It("has connectivity to a VMI that is not on the same VLAN...")

I do not think you need the "test_id", if these are needed the relevant contributors should add it.

commit: tests, vmi_multus: test Sriov with Vlan

I think you do not need 2 new NAD/s, one with a VLAN definition should be enough.

Done. Further discussion

All tests are using a flat structure, but the new tests added here indent multiple contexts in which seems more confusing than helpful.

Done.

Creating a SRIOV VMI with VLAN definition is a test by itself, no? If so, it does not need to be in the fixture.

Done.

It seems to me that the most appropriate thing to do here is to re-use createSriovVMs somehow. (maybe by changing its signature to: func(networkName string, cidrs ...string))

I think it complicates things because at least for the non-vlan negative test, I will have to pass two networks, so I can't use it.
I can use it only for the positive test, but I think it is better to keep the the two test as a negative mirror image of each other.
is that acceptable ?

I would expect to see here no additional contexts or max one.
e.g.:

Context("With VLAN") // Create one VMI with VLAN
It("has connectivity to a VMI on the same VLAN...")
It("has connectivity to a VMI that is not on the same VLAN...")

I do not think you need the "test_id", if these are needed the relevant contributors should add it.

Done.
Thank you @EdDev for the review. did most of what you asked. commented back about using the existing function "createSriovVMS".

rebased on master

/test pull-kubevirt-e2e-kind-1.17-sriov

Thank @ormergi  for the review. made some of your suggested changes. please refer to my replies about the IPAM and the optional mac.

Thanks @EdDev  for the notes. I removed the helpers I added and used the existing createSriovVms. I modified it to accept also network names as arguments, so that it will be suitable for my tests that creates two sriov vms on two different networks.
about:

I mainly do not like the lambda here and the fact that is handles the error assertion.
The pool does not need to be managed more than it is now, e.g.:

var randomMac [3]string
for i := randomMac {
randomMac[i], err := tests.GenerateRandomMac()
Expect(err).ToNot(HaveOccurred())
}
This is no longer neeedd because the lambda was removed as well , and I am using the existing createSriovVms.

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test  pull-kubevirt-e2e-k8s-1.18

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

/test pull-kubevirt-e2e-kind-1.17-sriov

added more retries to the ping command

made ping send 4 packets instead of one

Thanks!
/lgtm

fixed some white spaces issues and rebased on master

made ping send 4 packets instead of one

Reverting this change as discussed here:
https://github.com/kubevirt/kubevirt/pull/3479#discussion_r546731537

/retest

/hold cancel


CustomDatasetFromCSV.getitem Lacks Vectorization

The current approach of reshaping an image in the CustomDatasetFromCSV class uses a slow for loop rather than a vectorized implementation.
See the following reshape logic in CustomDatasetFromCSV.__getitem__:
img_as_np = np.ones((28, 28), dtype='uint8')
# Fill the numpy array with data from pandas df
for i in range(1, self.data.shape[1]):
    row_pos = (i-1) // self.height
    col_pos = (i-1) % self.width
    img_as_np[row_pos][col_pos] = self.data.iloc[index][i]

Best practice here should probably be to use np.reshape.
When doing something very simple like loading a CSV copy of the MNIST dataset, this can cause a significant slowdown (e.g. my local machine training a very simple CNN on pytorch-cpu can take <1 min for an epoch with a vectorized approach versus >30 min with the current example).

Hello, thanks for the feedback! I will have a look.


Clusters created via Director client don't show up in the Director UI

Is it by design that clusters spawned via the director client don't show up in the director ui?

That's expected if you use the client with the bootstrap command. All state is local. If you use the bootstrap-remote command the cluster will be created by the server.


Emit for the implicit j.l.Object supertype. [phab:D951]

Created by benjyw at 2016-07-08 06:34:40:
All Java classes with no explicit superclass extend java.lang.Object.
Similarly, all type parameters with no explicit upper bound are
bounded by java.lang.Object.
Prior to this change Kythe would emit this information only if the
code explicitly mentioned the Object supertype. However since the
ability to omit an explicit "extends Object" is merely a convenience
offered by the compiler, Kythe should behave the same regardless
of whether the supertype is implicit or explicit.
This change ensures that Kythe always emits for the implicit
superclass and for the implicit type bound.
See discussion here:
https://groups.google.com/forum/#!topic/kythe/JebekjFn_HE

schroederc commented inline (context lost during migration) at 2016-07-08 22:07:21:
Please ensure this is the correct node by adding an explicit reference to Object elsewhere in this file (a Object obj; field works) and adding a goal that it refers to the same Object goal variable.

schroederc commented inline (context lost during migration) at 2016-07-08 22:07:21:
Why the change?

schroederc required changes at 2016-07-08 22:07:21

schroederc closed via commit 2f10c61be67be42c27e1c23cfc64658d29d4de8a at 2016-07-11 20:27:43


fixes #104059

This PR fixes #104059
checks if "editor.parameterHint.enabled" is true before showing parameter hints if *.suggest.completeFunctionCalls is enabled.
To test this create a javascript or typescript file and try to complete a function with and without "editor.parameterHints.enabled" set to true.

Fix looks good. It's pretty late for our current release thought so I'm marking this for august

Awesome! So does that mean my PR doesnt get merged until after July 2020 is released?

Thanks! Will be in the first 1.49 insiders build

Awesome thanks!


Usage in Native Base Tabs on Android

I'm developing an app which I want to use swiper in; but I'm seeing an issue on Android, whereas iOS works as expected.
The app is using a native-base tab view to display a number of tabs; within each tab I'm using Swiper to switch between two full screen (tab) Views by scrolling Vertically (to display two different sets of options for each tab).
This works as expected on iOS - horizontal swipes are picked up by the tab view and vertical swipes by the Swiper however on Android only the horizontal swipes are picked up by the tab controller.
Not sure if this is a Swiper issue or a Native Base tabs issue but wondered if anyone else has seen/tried this (will investigate some more).

I'd hit a newbie issue which is quite well documented elsewhere - https://github.com/facebook/react-native/issues/8024


MLX5_INFINIBAND variant of error: call to '__read_overflow2'

When investigating one specific failure (thanks to rule-based decision tree):
rawtuxdata.query("MLX5_INFINIBAND == 'm' & GENERIC_ALLOCATOR == 'n' & DRM_VBOXVIDEO != 'y' & WANXL_BUILD_FIRMWARE != 'y' & AIC7XXX_BUILD_FIRMWARE != 'y' & AIC79XX_BUILD_FIRMWARE != 'y'")[['cid', 'vmlinux', 'IPV6', 'UBSAN_SANITIZE_ALL', 'INFINIBAND_ADDR_TRANS', 'FORTIFY_SOURCE', 'UBSAN_ALIGNMENT', 'UBSAN_NULL', 'NET_FOU_IP_TUNNELS']]
I was surprised to notice similar error messages as in #142 and #145
######## configuration cid 70585
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 'amdgpu_bo_create_restricted':
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:378:2: warning: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Wcpp]
 #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
  ^~~~~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:378:2: warning: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Wcpp]
 #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
  ^~~~~~~
drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
drivers/gpu/drm/radeon/radeon_object.c:242:2: warning: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Wcpp]
 #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
  ^~~~~~~
drivers/gpu/drm/radeon/radeon_object.c:242:2: warning: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Wcpp]
 #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
  ^~~~~~~
In file included from ./include/linux/bitmap.h:8:0,
                 from ./include/linux/cpumask.h:11,
                 from ./arch/x86/include/asm/cpumask.h:4,
                 from ./arch/x86/include/asm/msr.h:10,
                 from ./arch/x86/include/asm/processor.h:20,
                 from ./arch/x86/include/asm/cpufeature.h:4,
                 from ./arch/x86/include/asm/thread_info.h:52,
                 from ./include/linux/thread_info.h:37,
                 from ./arch/x86/include/asm/preempt.h:6,
                 from ./include/linux/preempt.h:80,
                 from ./include/linux/spinlock.h:50,
                 from drivers/infiniband/core/core_priv.h:37,
                 from drivers/infiniband/core/roce_gid_mgmt.c:33:
In function 'memcpy',
    inlined from 'rdma_ip2gid' at ./include/rdma/ib_addr.h:175:3,
    inlined from 'addr_event.isra.1.constprop' at drivers/infiniband/core/roce_gid_mgmt.c:691:2,
    inlined from 'inetaddr_event' at drivers/infiniband/core/roce_gid_mgmt.c:714:9:
./include/linux/string.h:305:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
    __read_overflow2();
    ^~~~~~~~~~~~~~~~~~
make[3]: *** [drivers/infiniband/core/roce_gid_mgmt.o] Error 1
make[2]: *** [drivers/infiniband/core] Error 2
make[1]: *** [drivers/infiniband] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
######### (end)

Again, we have our friend FORTIFY_SOURCE, IPV6 to n and UBSAN checking)
So here again it's not a masking effect, but a possible misclassification of the decision tree that "fails" to group together some options...

Similar story:
rawtuxdata.query("GPIO_GRGPIO == 'm' & ISDN_DIVAS_USERIDI == 'm' & GPIO_GRGPIO & MLX5_INFINIBAND == 'n' & GENERIC_ALLOCATOR == 'n' & DRM_VBOXVIDEO != 'y' & WANXL_BUILD_FIRMWARE != 'y' & AIC7XXX_BUILD_FIRMWARE != 'y' & AIC79XX_BUILD_FIRMWARE != 'y'")[['cid', 'vmlinux', 'IPV6', 'UBSAN_SANITIZE_ALL', 'INFINIBAND_ADDR_TRANS', 'FORTIFY_SOURCE', 'UBSAN_ALIGNMENT', 'UBSAN_NULL', 'NET_FOU_IP_TUNNELS']]
######## configuration cid 50174
In file included from ./include/linux/uaccess.h:13:0,
                 from ./include/linux/highmem.h:8,
                 from fs/binfmt_elf.c:28:
fs/binfmt_elf.c: In function 'load_elf_binary':
./arch/x86/include/asm/uaccess_64.h:143:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(4[(u16 *)src], 4 + (u16 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
./arch/x86/include/asm/uaccess_64.h:143:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(4[(u16 *)src], 4 + (u16 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
./arch/x86/include/asm/uaccess_64.h:154:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(1[(u64 *)src], 1 + (u64 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
./arch/x86/include/asm/uaccess_64.h:154:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(1[(u64 *)src], 1 + (u64 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
In file included from ./include/linux/uaccess.h:13:0,
                 from ./include/linux/highmem.h:8,
                 from fs/binfmt_elf.c:28,
                 from fs/compat_binfmt_elf.c:131:
fs/binfmt_elf.c: In function 'load_elf_binary':
./arch/x86/include/asm/uaccess_64.h:143:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(4[(u16 *)src], 4 + (u16 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
./arch/x86/include/asm/uaccess_64.h:143:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(4[(u16 *)src], 4 + (u16 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
./arch/x86/include/asm/uaccess_64.h:154:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(1[(u64 *)src], 1 + (u64 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
./arch/x86/include/asm/uaccess_64.h:154:20: warning: array subscript is above array bounds [-Warray-bounds]
    __put_user_asm(1[(u64 *)src], 1 + (u64 __user *)dst,
                    ^
./arch/x86/include/asm/uaccess.h:468:16: note: in definition of macro '__put_user_asm'
        : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))
                ^
In file included from ./include/linux/bitmap.h:8:0,
                 from ./include/linux/cpumask.h:11,
                 from ./arch/x86/include/asm/cpumask.h:4,
                 from ./arch/x86/include/asm/msr.h:10,
                 from ./arch/x86/include/asm/processor.h:20,
                 from ./arch/x86/include/asm/cpufeature.h:4,
                 from ./arch/x86/include/asm/thread_info.h:52,
                 from ./include/linux/thread_info.h:37,
                 from ./arch/x86/include/asm/preempt.h:6,
                 from ./include/linux/preempt.h:80,
                 from ./include/linux/spinlock.h:50,
                 from drivers/infiniband/core/core_priv.h:37,
                 from drivers/infiniband/core/roce_gid_mgmt.c:33:
In function 'memcpy',
    inlined from 'rdma_ip2gid' at ./include/rdma/ib_addr.h:175:3,
    inlined from 'addr_event.isra.2.constprop' at drivers/infiniband/core/roce_gid_mgmt.c:691:2,
    inlined from 'inetaddr_event' at drivers/infiniband/core/roce_gid_mgmt.c:714:9:
./include/linux/string.h:305:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
    __read_overflow2();
    ^~~~~~~~~~~~~~~~~~
make[3]: *** [drivers/infiniband/core/roce_gid_mgmt.o] Error 1
make[2]: *** [drivers/infiniband/core] Error 2
make[1]: *** [drivers/infiniband] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
######### (end)


release v3.14.7

[v3.14.7] (May 23, 2024)
Fixes

Fixed issue where files that failed to compress were not being sent
Cleaned up the props of the ChannelSettings component to ensure all missed props are applied
Exported the ChannelSettingsHeader component as defaultimport ChannelSettingsHeader from '@sendbird/uikit-react/ChannelSettings/components/ChannelSettingsHeader'

Fixed the issue where the mention feature did not work properly in the input component
Fixed the issue where unnecessary spaces were added between mention texts when editing an already mentioned message
Improved the scroll position flickering issue when loading previous messages
Implemented an attempt to load based on screen size threshold
Added data-testid to the UI components for making it easily to select them in the QE test

/bot create ticket

[Creating Ticket] 🔖 Done https://sendbird.atlassian.net/browse/SDKRLSD-1289


Faiss requirement missing in install.sh and readme.md

For tatoeba, it seems like user have to install faiss (utils_retrieve.py)

cc @JunjieHu

@anlausch the anaconda environment should include the faiss during the installation. Please check this line. Could you install the environment by conda create --name xtreme --file conda-env.txt and see if faiss is successfully installed?


Possible issues with reading data from RPi

This is how we read the data from the Raspberry Pi:
String allDataFromPi;
if (Serial.available() > 0) {
    allDataFromPi = Serial.readStringUntil('\n');
    for (int i = 0; i < 16; i++) {
         m_channelData[i] = allDataFromPi.substring(1, allDataFromPi.indexOf(",")).toInt();
         allDataFromPi = allDataFromPi.substring(allDataFromPi.indexOf(",") + 1);
    }
}

There may be some issues here:

When we start to read data from the Pi, we may start to read a line mid way, so we will not read all 16 numbers. A possible solution can be to put a certain character at the beginning of every message (e.g., M or something)
It is not impossible that the Pi sends garbage data every now and then.
We can try to increase the baud rate. The Pi supports baud rates up to 2M. The ESP32 can allegedly go up to 5M, although some users have reported issues above 2M. I would try 500,000.
We can decrease the size of the message. We can encode the state of the switches as 0/1.

The suggestions have been adapted and tested in #52. After testing, no issues were found. Closing this issue.

Reopening because the PR has not been reviewed/merged