ES modules exports (implements #2718)

Ready for review but not ready for merging; see "before merging" notes below.
Purpose
Reformatting the underscore source code to use ES6 exports, in order to facilitate treeshaking with tools such as rollup. See #2718.
Non-purposes

Converting other parts of the code to ES6+. I didn't introduce any const, let, async or arrow functions.
Modularization. All the underscore functions are still in a single module, in the same order.

I agree with and followed https://github.com/jashkenas/underscore/issues/2718#issuecomment-575725274 and https://github.com/jashkenas/underscore/issues/2718#issuecomment-575728627. One change at a time.
This is also one of the reasons this isn't ready for merge yet; the move to ES6 exports obviates one level of indentation, but I kept that indentation for now in order to ease review.
What I did

Renamed underscore.js to underscore-source.js, because the former will be generated from the latter as of this PR. The generated underscore.js is functionally equivalent (except for some minor differences detailed below) to the former underscore.js. underscore-source.js is just a working name; see notes under "before merging".
Removed the IIFE wrapper, firstly because ES6 export statements must be at module level and secondly because rollup will generate an IIFE for the UMD bundle.
Removed the hand-coded UMD logic.
Reformatted the exports as well as internal functions in underscore-source.js in the following ways:

Replaced _.name = function(){}; by export function name(){}.
Replaced _.name = expression; by export var name = expression;.
Replaced var internalName = function(){}; by function internalName(){} for consistency with 1. and also for brevity and a little added convenience (i.e., hoisting).
Replaced internal uses of _.name by just name, except for _.iteratee and _.templateSettings because users may override these.

Changed some internal names without affecting the exported interface. The removal of the _. namespace for internal use introduced some naming conflicts, which I solved as follows:

There was both an internal has and an exported has. I renamed the latter to _has for internal use, because the non-exported has is used more. _has also resembles the old _.has.
Likewise for flatten/_flatten.
The exported isNaN has a counterpart that is an ES builtin. I renamed the former to _isNaN for internal use.
Likewise for isFinite/_isFinite.
keys is used very often as a local variable inside functions. I renamed the exported keys to _keys for internal use.
now is also the name of a local variable in throttle, which is the return value of the exported now. I renamed the local variable to _now.

Added an auxiliary underscore-module.js (working name) which takes all the exports from underscore-source.js and mixes them into _. This is a trick to avoid hand-coding all the exports twice, i.e., to avoid having to write both export name and _.name = name.
Set the module field in the package.json to the underscore-module.js, so that tools like rollup will be able to find the export-based version while everyone else can continue using the UMD bundle.
Added an auxiliary underscore-umd.js (working name) that re-exports only the default export from underscore-module.js. This facilicates the UMD bundling by rollup.
Added rollup configuration to generate the UMD bundle, making sure to produce an UMD bundle which is as close to the hand-written original as possible. I used an outdated version of rollup so I could use the legacy option, which prevents rollup from generating getters, which would be incompatible with IE8.
Delegated the creation of the noConflict function to rollup, which has an option for this.
Added tests to verify that treeshaking is enabled and not overzealous. See notes about treeshaking below under "quantitative changes".
Added commands (scripts) to the package.json to generate the UMD bundles (both the underscore.js and two bundles for the treeshaking tests) and prepended these commands to other commands that depend on their existence.
Updated and configured eslint, and added a plugin, to enable the linter to process import/export syntax.

I did not convert the tests to ES module syntax; in fact, they still import from the (now generated) underscore.js.
Interface changes

The UMD wrapper generated by rollup exposes the same interfaces to the same module systems (CommonJS/AMD/window embed). However, it is a bit less refined than the former hand-written version. I don't expect it to cause issues, but I should still mention that it isn't 100% equivalent.
The noConflict method generated by rollup is 100% equivalent to the fomer hand-written version. However, it is only added in the window embed scenario. ESM, AMD and CommonJS module users will not see the method anymore, although they shouldn't need it, either.

I believe that the published UMD interface is otherwise completely identical to what is currently on the master branch.
This PR shows a comparison between the former hand-written underscore.js and the new reformatted underscore-source.js. In order to appreciate the interface changes, one might want to see a comparison between the former hand-written underscore.js and the new rollup-generated underscore-js instead. I pushed a secondary branch to make this possible. The diff can be found over here: https://github.com/jashkenas/underscore/compare/master...jgonggrijp:es-module-compiled?expand=1#diff-0f36b362a0b81d6f4d4bfd8a7413c75d (you may have to click "load diff").
Quantitative changes
The amount of code to maintain decreases very slightly.

.
hand-written underscore.js
proposed _source + _module + _umd

total lines of code
1692
1684

gzipped kB
16.32
16.04

The weight of the published gzipped + minified UMD bundle increases by 240 bytes.

.
hand-written UMD module
rollup generated UMD module

minified + gzipped kB
6.5
6.74

In exchange, users get the option to treeshake when using tools like rollup. If a user imports only map (from underscore-source.js), underscore's contribution to her UMD bundle decreases by 900 lines of code compared to the present situation. This is substantial, if not as spectacular as one might expect. This is due to rollup not being clever enought about side effects and erring on the side of caution.
As an experiment, I also created a completely modularized version where each function lives in a separate module (not published). This enabled rollup to shave off another 460 lines of code. Rollup also surprised me by pointing out circular dependencies, which it apparently cannot do if all code is in one module. I suspect that solving these circularities might cut map's size in half again, but I have not tried this.

.
rollup treeshaken size of map in lines of code

present situation
1692

proposed changes
786

modularized (experimental, unpublished)
329

While the minified + gzipped UMD bundle weight has increased a bit, these numbers make me believe that using ES exports is definitely a move forward. In addition, solving circular dependencies might also decrease the weight again.
Before merging

[x] The obsolete level of indentation (and the comment at the top explaining it) still has to be removed.
[ ] The generated underscore.js should probably be commited. What do you think would be the right policy for this, @jashkenas?
[ ] Decide how to name underscore-{source,module,umd}.js. Perhaps modules/{index-unmixed,index,index-umd-wrapper}.js?

Edit 2020-03-7: Changed suggested names from modules/{underscore,index,umd}.js to modules/{index-unmixed,index,index-umd-wrapper}.js because the former might be problematic if we modularize the whole library in a subsequent PR.

@jashkenas I'm done writing. I would be very grateful if you could find the time to review this. My apologies for the long opening post and the big diff (despite my best attempts to keep the diff minimal)!
@lohfu @mjeanroy FYI.

Wow! 👏👏👏.
Thanks for taking the time to actually make a stab at this — many people have talked a lot about it over the years, but it takes a rare soul to follow through.
I'm actually starting a month of parental leave next week, so should have a good chunk of time to look at this more closely soon. Please pester me if I don't get back to you soon enough...

@jashkenas It's a pleasure. I love this library, thank your for making it. Good luck with parenting!

@jashkenas Any updates?

Not yet, and we have a wedding to attend this weekend, but thanks for the
ping!
On Fri, Mar 6, 2020, 2:45 PM Julian Gonggrijp<EMAIL_ADDRESS>wrote:

@jashkenas https://github.com/jashkenas Any updates?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jashkenas/underscore/pull/2826?email_source=notifications&email_token=AAABE7HAYZNI36TQINZRIATRGEZBVA5CNFSM4K5GBDFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOCHDCA#issuecomment-595882376,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAABE7AN3M7EA5PYO3M7FZLRGEZBVANCNFSM4K5GBDFA
.

@jashkenas Here's another ping. My apologies if this is too soon. I hope you had a nice weekend and wedding.
I'd like to draw your attention to #2829 as well. If you approve of that one, I'd prefer it to be merged before this one. #2829 is a very small change.
On another note, would you appreciate some help with triaging open issues and PRs? Rather than spamming your notifications by responding to each of them individually, I could create a single issue ticket with a list of PRs than can be closed, a list of issues that can be closed, a list of PRs that require review, etcetera. If you like.

This is looking truly great. Thank you for taking the time to create such a solid draft of an ES-modularization. I really just have a few minor notes around the edges:

It would be nice if the UMD build of Underscore continued to support ES3 — there are a lot of folks who use Underscore, for example, in Adobe Illustrator and Photoshop under ExtendScript. It would be even better if we could find a way to assert that compatibility in the tests. If we change this in the future, and start using const, async and friends, it should be part of a bigger push to provide more asynchronous/promise-based functional logic in Underscore.

I'd prefer getting rid of the additional underscore-module.js file, and just including the _.name = function assignment in the main source file. It certainly is a neat trick though.

Naming: Since this change will become Underscore 2.0, I think it's fine for the main "underscore.js" to switch from being UMD formatted to a clean ES module. My preferred naming scheme would be:

underscore.js The main source ES module, which is also the module that should be directly imported when using ES modules. (No separate -module version.)

underscore-umd.js If it would be possible to eliminate this file by having Rollup read from underscore.js directly (now that it includes the correct default export), that would be great. Otherwise, we can leave this file in place.

dist/underscore-min.js Minified UMD

dist/underscore-min.js.map

It would be nice if the internal _names followed a consistent pattern (regardless of frequency of use), so: name for exports and _name for internal functions only.

It looks like it may be possible to have more current versions of Rollup avoid the use of getters by using the --no-externalLiveBindings option, which will make things IE8 compatible.

Overall — and even if it looks like it makes life easier for Rollup — I'd still strongly prefer to keep everything in a single underscore.js, ES module file. Perhaps there’s something we can do with respect to the code organization, or avoiding function hoisting, or circular dependencies, that can solve the treeshaken LOC problem in a different way.

Bravo! 👏

Thank you for taking the time to review this. I'm happy to hear it looks so good to you. This weekend, I'm going to try to address your concerns as well as I can. Some comments in advance:

It would be nice if the UMD build of Underscore continued to support ES3 — there are a lot of folks who use Underscore, for example, in Adobe Illustrator and Photoshop under ExtendScript. It would be even better if we could find a way to assert that compatibility in the tests.

This is a tall order, but I agree with the sentiment in principle and I will investigate the options.

If we change this in the future, and start using const, async and friends,

Please observe that this is by no means my intention, not even for a subsequent pull request. The current PR introduces no new syntax other than import/export. In my opinion, it is not necessary at this time to introduce other ES6+ syntax. In fact, not doing that has the advantage that no transpiler is needed.

it should be part of a bigger push to provide more asynchronous/promise-based functional logic in Underscore.

I'm not sure about this. I'm not sure more async belongs in underscore at all, because there is already a perfectly fine library available for that purpose. I'm not sure such an introduction would require modern async/await syntax, either, since you can work with promises without that syntax, too. And finally, the syntax used in the source code bears little relevance to the functionality available to the end user, since she will always see a version of the library that is encoded in old syntax, either as written by hand or transpiled down from modern syntax.

I'd prefer getting rid of the additional underscore-module.js file, and just including the _.name = function assignment in the main source file. It certainly is a neat trick though.

Why do you want to keep everything in one file?
The purpose of the module/source divide is not just avoiding repetition, although I think there is great value in DRY. It is also the only way to enable any treeshaking at all. I realize I didn't emphasize this before, but treeshaking only works when the user imports from the underscore-source, not when importing from the underscore-module. Treeshaking works when importing from the underscore-source, exactly because it doesn't contain the _.name = function assignments; those assignments constitute side effects and they force tools like rollup to always include all of the source.
I'll be frank: there is no point in accepting this pull request unless you resign to the idea of splitting the source into at least two modules.
However, I'm very certain that you have valid, well-thought reasons for wanting to keep everything together. I want to fully understand these reasons and I want to address them to the best of my ability. Do they perhaps include the wonderful annotated source edition that you can read through in one go? Name all of it, and I will fight dragons so we can keep as many of the advantages of a single module as possible.

Naming: Since this change will become Underscore 2.0,

Why will it? Isn't this mostly new functionality rather than a radical interface change?

I think it's fine for the main "underscore.js" to switch from being UMD formatted to a clean ES module. My preferred naming scheme would be:

underscore.js The main source ES module, which is also the module that should be directly imported when using ES modules. (No separate -module version.)

As I wrote above, this wish is impossible to grant while also having treeshaking. In addition to that, if you continue to call the UMD bundle underscore.js and use some other name for the main ESM entry point, nobody will need to change the path from which they import underscore, not even people who use ESM imports, because the module field of the package.json can transparently point them to the correct underlying file.

underscore-umd.js If it would be possible to eliminate this file by having Rollup read from underscore.js directly (now that it includes the correct default export), that would be great. Otherwise, we can leave this file in place.

Unfortunately, no, that file cannot be eliminated. The problem is not in the way the default export is arrived at (I could have done mixin(allExports) ; export { default } from 'underscore-source' instead), but in the way rollup treats files that contain both named exports and a default export. It insists on setting module.exports to a plain object in that case, which means that if people do
var _ = require('underscore');

, their _ is not anymore the OOP chain wrapper/partial placeholder/iteratee override holder it should be. For that, they would need to use
var _ = require('underscore').default;

instead. The only way to make the first scenario work, which I really think it should, is to offer rollup a module that has a default export and no other exports.

It would be nice if the internal _names followed a consistent pattern (regardless of frequency of use), so: name for exports and _name for internal functions only.

I do agree with this and I will do as you suggest.

It looks like it may be possible to have more current versions of Rollup avoid the use of getters by using the --no-externalLiveBindings option, which will make things IE8 compatible.

No, actually I tried that first, with rollup version 1.31.1. It still insisted on creating getters for some of the exports, probably because they were aliases of other exports. The only way to get rid of the getters entirely was the legacy option. This also indicates a potential problem with rollup; they don't seem very committed to supporting legacy systems.
I think there are three main options:

Accept that we need to lag behind the rollup releases. It is only a (minor) problem for the developer, not for the user. The rollup version I used is only two or three years outdated, and apart from the getters and the use of Object.freeze (both of which are only lacking because of the legacy option), the generated code is identical to what recent versions of rollup generate.
Drop support for IE8 (and probably ExtendScript). It hurts, but if you really intend to make this a 2.0, maybe it is an acceptable sacrifice. It would definitely help to shake some weight.
Do a final transpilation+polyfill pass on the UMD bundle. This allows you to be as backwards-compatible as you want, but it comes at an ugly cost: additional layers of complexity in the tooling and potentially a lot of extra weight.

Overall — and even if it looks like it makes life easier for Rollup — I'd still strongly prefer to keep everything in a single underscore.js, ES module file. Perhaps there’s something we can do with respect to the code organization, or avoiding function hoisting, or circular dependencies, that can solve the treeshaken LOC problem in a different way.

Let me begin by repeating that I believe you have good reasons for this and that I want to address those reasons as well as I can. Please do explain those reasons to me in detail.
Rollup (and the hard problem of JavaScript treeshaking in general) is mainly sensitive to two things: side effects and dependency. Apart from that, the way the code is organized does not really affect its resuts. Whether one function goes before the other or the other way round does not matter, as long as neither depends on the other or writes to an object that the other might read from. Especially the question of side effects quickly becomes intractable as more common variables are involved. This is why treeshaking becomes more effective as the size of modules decreases: modules have isolated namespaces, so the finer the modularization, the less potential common state.
I truly believe that further modularization, up to the point of putting every function in a separate module, would be good for underscore. I didn't do it in this PR because I believe in evolutionary change and because I wanted to keep the review as digestible as possible. But I believe it should be the next step.
Apart from dramatically improving treeshaking, splitting out the source code into many small modules has a few other clear advantages:

As I said before, it enables rollup to report circular depencies.
It makes it possible to publish not only a monolithic UMD bundle, but also modularized AMD and CJS versions. In this way, even people who use require.js or browserify will have the opportunity to benefit from treeshaking, even also while using the same import paths as ESM users. The latter also means that one could write ESM code that uses underscore, transpile it to AMD, and then use dynamic treeshaking right from IE. It is just a matter of passing the preserveModules: true option to rollup, setting the browser field in the package.json for browserify users and setting a single path alias on the end of AMD users.
When creating a monolithic bundle, rollup will linearize the code in strict order of dependency, at least where the dependencies are noncyclic. Since there is some freedom in this, you can also guide the produced order to some extent by chosing the order of the imports in the index module. This could help to enhance readability, for example in generating the annotated source. Imagine a monolithic ESM module in strict order of dependency; it would be very clean.

By extension of the above, I believe that fine modularization goes before any attempt at solving circular dependencies.

Bravo! 👏

Thank you!

Thanks for the detailed response!

Please observe that this is by no means my intention, not even for a subsequent pull request. The current PR introduces no new syntax other than import/export. In my opinion, it is not necessary at this time to introduce other ES6+ syntax. In fact, not doing that has the advantage that no transpiler is needed.

👍

I'm not sure about this. I'm not sure more async belongs in underscore at all, because there is already a perfectly fine library available for that purpose.

👍

I think there are three main options:

Accept that we need to lag behind the rollup releases.

👍 That sounds fine. I'm sorry to hear that the --no-externalLiveBindings doesn't work as described.

I'll be frank: there is no point in accepting this pull request unless you resign to the idea of splitting the source into at least two modules.

That’s fine, if it's necessary. If we end up with one file as the straight ES Module exports, one as the complete mixed API, and one file as the single-object UMD export — as you have it today — that's cool with me.

However, I'm very certain that you have valid, well-thought reasons for wanting to keep everything together. I want to fully understand these reasons and I want to address them to the best of my ability.

Simply because it's the soul of this (now venerable) project. Underscore has always tried — and has succeeded and failed over the years, as waves of pull requests have come and gone — to be a simply-written, single-file tour through some useful functional programming idioms in JavaScript. It’s an exercise that’s supposed to be as pedagogical as it is practical. There’s a balance between performance and organizational complexity on the one hand, and readability and source code simplicity on the other. Being a short, single-file library with no dependencies is at the heart of that identity. Also, Lodash already exists.
But I don't think that should be a dealbreaker — since, if we separate the -module or -source file as you suggest, it should make no difference to Rollup, or any other tool, if the source code happens to live in one file or many. It should be possible to syntactically determine where the seams lie between the functions, and achieve equal (or close to equal) results. And if they're not, it's either a hidden circular dependency (that we can fix), or a bug in Rollup (that can be fixed). Right?
If there are any other open questions you feel like I haven't addressed, please let me know.

If we end up with one file as the straight ES Module exports, one as the complete mixed API, and one file as the single-object UMD export — as you have it today — that's cool with me.

Great!

... reasons for wanting to keep everything together.

Simply because it's the soul of this (now venerable) project. Underscore has always tried — and has succeeded and failed over the years, as waves of pull requests have come and gone — to be a simply-written, single-file tour through some useful functional programming idioms in JavaScript. It’s an exercise that’s supposed to be as pedagogical as it is practical. There’s a balance between performance and organizational complexity on the one hand, and readability and source code simplicity on the other.

I know what you mean. Underscore is a very elegant library, venerable indeed. While I had read the docco rendering before, I became more intimately familiar with the code while preparing this PR and it only strengthened my opinion. It's like a good, well-paced story in which everything comes full circle at the end. With enlightening ingenuity.

Being a short, single-file library with no dependencies is at the heart of that identity. Also, Lodash already exists.

I full-heartedly agree about the succinctness and the self-sufficiency. As far as I'm concerned, those can and should stay. I also see the value of the "single read", but I think there might be other ways to address that than necessarily keeping all the primary source code in one file. Maybe it is enough if we generate a monolithic, well ordered ESM using rollup and then feed that into docco. To me, it seems like that might actually be the best of both worlds. Underscore could at the same time present a holistic story and also be a prime example of how to write elegant modular code.
As for Lodash. I'm a bit hurt by the remark. I don't believe that modularity is some kind of gliding scale that separates Lodash from Underscore, or even that it is the most significant difference between the libraries. As far as I'm concerned, Lodash is what it is for very different reasons. And I'm definitely not going to repeat that history. To begin with, I will not fork Underscore under any condition.

But I don't think that should be a dealbreaker — since, if we separate the -module or -source file as you suggest, it should make no difference to Rollup, or any other tool, if the source code happens to live in one file or many. It should be possible to syntactically determine where the seams lie between the functions, and achieve equal (or close to equal) results. And if they're not, it's either a hidden circular dependency (that we can fix), or a bug in Rollup (that can be fixed). Right?

Sorry, but no, wrong. Observe that there is a factor two treeshaking difference between the underscore-source from the current PR and the experimental, fully modularized version that I didn't publish, despite both containing the exact same code with the same circular dependencies and despite me using the exact same version of rollup in both cases.
As a matter of fact, it makes a great deal of difference whether the source code lives in one file or many. I can see why you don't want this to be true, ideologically speaking, but it is true nonetheless. Rollup is over its neck in the murky business of trying to statically track side effects in an impure, weakly typed dynamic language, while Underscore is a little paradise of functional, orthogonal style. Getting a factor two treeshaking improvement by changing Underscore is many orders of magnitude easier than getting that same improvement by changing Rollup. I know; I got a factor four treeshaking improvement in less than a week of editing Underscore (a factor two by splitting it in two and then another factor two by splitting it in 146), working all alone, while the Rollup team has been working on Rollup for years and they never managed such a dramatic treeshaking improvement on anything whatsoever.
I'm not just talking pragmatics. There are strong, fundamental reasons for this. In 2050, ES code distributed over many files will still be more effectively treeshaken than monolithic source code. I'll bet on that.
Besides that, hidden circular dependencies are uncovered by splitting everything in tiny modules and then having a tool tell you where the circularities are. That, or many hours of brain-melting static analysis by a human (assuming the human won't give up). I don't know about you, but I'm not going to repeat that effort every time we suspect there might be a circular dependency (which we might not always suspect). Given the choice, I'd rather have it modularized permanently and get an instant hint from a tool whenever somebody introduces a circularity.

If there are any other open questions you feel like I haven't addressed, please let me know.

Yes. I don't fully understand yet why you feel that modularity is at odds with the elegance of Underscore. So far I see no conflict, only harmony. What makes you feel different?

As I said, it’s an aesthetic preference that — to me — lies quite close to the heart of Underscore’s raison d'être, and is a matter of prioritization. To me, keeping Underscore a single file that can be copied, read through in a sitting, and used without any additional tooling, is very important, and a large part of the library’s original usefulness and popularity. Whether or not we support tree-shaking at all is much less important to me. (In fact, there are good arguments against encouraging it, and promoting the single, CDN-cached, 6.5k version of Underscore instead.)
But let's put that aside. When you're ready with this PR, let's take a few representative functions, and you can also do them in the modularized form — and I'll take a stab at trying to satisfy Rollup’s internal logic to see if I can come close to matching them with the single-source file. And if I can't approach your results, we'll discuss it again.

As I said, it’s an aesthetic preference that — to me — lies quite close to the heart of Underscore’s raison d'être, and is a matter of prioritization. To me, keeping Underscore a single file that can be copied, read through in a sitting, and used without any additional tooling, is very important, and a large part of the library’s original usefulness and popularity.

Alright. I can really relate to this. But this is not lost; the generated UMD bundle can be copied, read through in a single sitting and used without any additional tooling. Only the developer is seeing a change in this regard.

Whether or not we support tree-shaking at all is much less important to me. (In fact, there are good arguments against encouraging it, and promoting the single, CDN-cached, 6.5k version of Underscore instead.)

It may surprise you, but I fully agree with this. If you're using substantial portions of Underscore client side, a monolithic CDN embed is far better than a subset included in your own (probably already heavy) application bundle. Because of the caching, as you said, and also because requests to different hosts can run in parallel. I always use a mix of jsDelivr and cdnizer for this same reason.
On the other hand, there definitely are valid use cases for treeshaking. I can imagine a client side application that makes heavy use of _.partial but no other Underscore functions, or a server side application that needs to make do with very limited working memory.

But let's put that aside. When you're ready with this PR, let's take a few representative functions, and you can also do them in the modularized form — and I'll take a stab at trying to satisfy Rollup’s internal logic to see if I can come close to matching them with the single-source file. And if I can't approach your results, we'll discuss it again.

Fine by me. I'm about to push my finished work, stay tuned.

Comment in progress...

I almost forgot, regarding the following:

It would be nice if the UMD build of Underscore continued to support ES3 — there are a lot of folks who use Underscore, for example, in Adobe Illustrator and Photoshop under ExtendScript. It would be even better if we could find a way to assert that compatibility in the tests.

I checked, and the UMD bundle produced by rollup is ES3. I did not find an easy way to test for compatibility with ExtendScript, but I'm thinking that it might be possible to have eslint check for this on the UMD bundle. I'm working on resolving #2827 separately and I hope I will be able to do it in a way that continues to work after the rollup conversion.

Oh, and another thing I forgot to mention. I did not move the minified version of the UMD bundle to a dist folder, as you suggested, because it would break the embed lines for everyone who takes them from CDN.
Also, I did not commit the generated UMD bundle. I think we still need to decide on a policy for this. Maybe never commit it, just include it when publishing to NPM? This can be automated with the prepare or prepublishOnly script in the package.json. We could do the same for the minified version. If going this route, the minified bundle and its sourcemap should be removed from git and then all generated files should be added to the .gitignore.

@jashkenas

When you're ready with this PR, let's take a few representative functions, and you can also do them in the modularized form — and I'll take a stab at trying to satisfy Rollup’s internal logic to see if I can come close to matching them with the single-source file. And if I can't approach your results, we'll discuss it again.

Apart from the need to make definitive decisions about module names and a UMD bundle commit policy, I think this PR is finished (see https://github.com/jashkenas/underscore/pull/2826#issuecomment-598776404 in case you missed the edit). So I'd like to agree on some game rules for this "treeshaking challenge".
Most importantly, I'd like to settle a specific date on which we'll decide whether you were able to approach my results or not. I want this in order to prevent the decision from being postponed indefinitely. On this date, the "winner" should publish his code to prove his claims.
I suggest that you grant yourself somewhere in the order of 24 hours of total programming time to work on this and then pick the nearest date before which you're confident you can spend that much time. 24 hours is approximately the total time it took me to create a noncircular modular version in which every function lives in a separate module.
Furthermore,

You will be trying to prove that it isn't necessary to split modules/index.js any further, so you will not do this, not even temporarily in order to obtain information.
You will not make any breaking interface changes to the UMD bundle as it is currently produced on the es-module branch (i.e., a3f6e76), since my modularized versions don't introduce breaking changes, either.

I already have modularized versions locally, with and without circular dependencies, so I'm ready to test treeshaking performance on any function you choose.
Right now, the es-module branch is set up for measuring the treeshaking performance on _.map. You can measure the performance by running npm run bundle-treeshake (this installs and runs the latest version of rollup automatically using npx) and then counting the number of lines in test-treeshake/map-umd.js. We can extend this to other functions if you like.
At the time of writing, I'm measuring the following performance.

Version
Size of _.map in lines of code

monolithic (master branch, no treeshaking)
1696

semimonolithic (es-module branch)
821

modular with circular dependencies (unpublished modularized branch)
350

modular without circular dependencies (unpublished noncircular branch)
276

(The test-treeshake/map-umd.js generated in the noncircular version appears to contain almost exclusively code that _.map actually depends on, so it probably can't be much smaller than 276 lines.)
I suggest that you win if, by the deadline, you manage to get the size of _.map within 10% of the circular modular version. So that would be anything under 385 lines of code. Otherwise, I win, and we discuss further modularization again as you proposed. We can extend this 10% margin to other functions as well.

@jashkenas My apologies for the previous comment, it was too early to discuss game rules and I was being a bit rude as well.
May I suggest that we proceed in the following order:

Merge (or reject) #2831 and #2830.
Merge the current PR. See https://github.com/jashkenas/underscore/pull/2826#issuecomment-598776404, https://github.com/jashkenas/underscore/pull/2826#issuecomment-598815168. I made another comment between those about ES3 compatibility, but the latest state is different: the UMD bundle is linted to check that all syntax is ES3 compatible and I have a permanent fix for ExtendScript in #2831.
Discuss game rules for the treeshake challenge, using https://github.com/jashkenas/underscore/pull/2826#issuecomment-599089184 as a starting point, pretending that it was entirely formulated in a civil way.

No worries! I didn't take any offense — and I think that most of your game rules sound fine. I just didn't want to commit to a particular date without knowing when I would be able to look at this further.
Yesterday, they announced the closure of the borders here in Chile, and we’ve been scrambling around weighing the pros and cons of cancelled flights and shelter in place orders to try to get back home. Hopefully things will quiet down after we manage to make it back.

No problem, best of luck getting home!

@jashkenas I'm mostly asking this out of personal concern: how are the circumstances for you and your family?

We’re good! When they announced the impending border closure, and our Aeromexico flight was cancelled, we turned around, drove 6 hours back north to Santiago, and grabbed a flight (one of the last?) back home to go hunker down.

@jashkenas I'd really like to move on with this PR. Could you give me a status update?

I went back to work on Monday, and haven't had a chance to take a look at this again ... but I'll try to soon. Sorry for the slowness.

Alright! I took a good long crack at playing around with Rollup’s treeshaking this morning, and feel like a learned a lot about what kinds of patterns it can and can’t treeshake, how /*@__PURE__*/ doesn’t work, and the types of things that we do in basic Underscore that end up being included in the bundle if they're present in the imported module, regardless of use.
For example, here’s a pattern that Rollup can tree-shake away (it’s a reduced test case of our isArguments function):
function _toString() {}
export var isArguments = (function() {
  return _toString(arguments) === '[object Arguments]' ? 0 : 1;
}());

And here’s the version we need to use, that Rollup can’t:
function _toString() {}
export var isArguments = (function() {
  return _toString.call(arguments) === '[object Arguments]' ? 0 : 1;
}());

The difference in this case is .call().
Flowing through functions, this means that anything that depends on Object.prototype.toString.call(...) — which we use heavily to test types, can't be treeshaken if called at the top level, even if not exported directly.
Many of the other places where we call functions at the top level can't be treeshaken by Rollup, although some simpler patterns can.
So, what does that mean for this PR?
Ultimately, although I'd be happy to publish a version of Underscore that provides both ES Module and UMD flavors, I think that the module should be a monolithic one, given the small size of Underscore, its presence in the CDNjs cache, and the current state of treeshaking tooling. I'm still not interested in either chopping it up into tiny files, or in littering the codebase with /*@__PURE__*/ annotations (even if they worked, which they don’t) in order to satisfy Rollup’s current limitations.
That said, if you want to publish your fully modularized version as a different npm package, godspeed. I'd be happy to link to it from the top of the Underscore homepage. I hope that's not too disappointing.

Alright! I took a good long crack at playing around with Rollup’s treeshaking this morning, and feel like a learned a lot about what kinds of patterns it can and can’t treeshake, how /*@__PURE__*/ doesn’t work, and the types of things that we do in basic Underscore that end up being included in the bundle if they're present in the imported module, regardless of use.

You surprise me! I was prepared to wait a long time before you'd even announce a deadline for the treeshaking challenge, and now you've already completed the challenge. You did a really good job at it as well.

So, what does that mean for this PR?
Ultimately, although I'd be happy to publish a version of Underscore that provides both ES Module and UMD flavors, I think that the module should be a monolithic one, given the small size of Underscore, its presence in the CDNjs cache, and the current state of treeshaking tooling. I'm still not interested in either chopping it up into tiny files, or in littering the codebase with /*@__PURE__*/ annotations (even if they worked, which they don’t) in order to satisfy Rollup’s current limitations.
That said, if you want to publish your fully modularized version as a different npm package, godspeed. I'd be happy to link to it from the top of the Underscore homepage.

That's really nice of you, but no, I don't want to do that because it would amount to forking Underscore. I believe the world doesn't need yet another fork of Underscore. I only want Underscore to be modular if you are on board.

I hope that's not too disappointing.

If the current, semi-monolithic PR can still be merged, I'm happy enough. How about that?
And I'll try again later to interest you in chopping everything into tiny modules. ;-)

Okay, great! In that case I think that we’re almost there.
At least before I can merge it — and perhaps as a general policy — we need to provide a built version of underscore.js in the repo. For many years, there has been a link to test out the "Edge version" on the homepage: https://raw.github.com/jashkenas/underscore/master/underscore.js ... and it would be great if that could continue to work, as changes are made to the master branch.
So perhaps using Husky to define a pre-commit hook that makes sure that underscore.js is always kept up-to-date with modules/index.js ?
And then prepublish can handle the -min.js and -min.js.map variants, and the annotated source.
As to the actual roll-out, how would you like to handle it? I think this could merit a 2.0 release, with appropriate revisions to the homepage/documentation. Would you like to be added as a collaborator on this repo to help make that happen? I think you’ve clearly earned your stripes.

And as to the treeshaking — my experiments make me feel like (even with a single source file), it's tantalizingly close. Rollup is able to eliminate all of the obvious non-dependencies, in terms of function declarations at the top level.
It's only with our use of function calls at the top level, in order to define other functions, that it has problems, and even then, only some of the time.
Things like:
export var omit = restArguments(function(obj, _keys) {
  var iteratee = _keys[0], context;
  if (isFunction(iteratee)) {
    iteratee = negate(iteratee);
    if (_keys.length > 1) context = _keys[1];
  } else {
    _keys = map(_flatten(_keys, false, false), String);
    iteratee = function(value, key) {
      return !contains(_keys, key);
    };
  }
  return pick(obj, iteratee, context);
});

... because of the call to restArguments, even though that function obviously has no side effects.
I feel like there might be a more general pattern of dynamic function export creation we could find that would allow Rollup to treat each export in isolation ... but I wasn't able to discover it, despite my best efforts.

Okay, great! In that case I think that we’re almost there.

Hooray!

At least before I can merge it — and perhaps as a general policy — we need to provide a built version of underscore.js in the repo. For many years, there has been a link to test out the "Edge version" on the homepage: https://raw.github.com/jashkenas/underscore/master/underscore.js ... and it would be great if that could continue to work, as changes are made to the master branch.
So perhaps using Husky to define a pre-commit hook that makes sure that underscore.js is always kept up-to-date with modules/index.js ?

Sure, I'll look into it.

And then prepublish can handle the -min.js and -min.js.map variants, and the annotated source.

prepublish or prepublishOnly? I don't mind either, but in the first case, I'd prefer to call it prepare.

As to the actual roll-out, how would you like to handle it? I think this could merit a 2.0 release, with appropriate revisions to the homepage/documentation.

Regardless of the version number, I definitely think some additions to the documentation would be in order.
I really appreciate that you want to celebrate this with a 2.0 release, but I adhere to semver quite strictly and I think this should be 1.10. All of the old interface is still there, all of the backwards compatibility is still there and the source code still looks mostly the same. Users just get the new option to treeshake with rollup. I don't want to "shock" users with a 2.0 if it isn't actually disruptive.
If, in some hypothetical future, we chop everything into tiny modules, I think that might merit a 2.0 release though... ;-)

Would you like to be added as a collaborator on this repo to help make that happen? I think you’ve clearly earned your stripes.

That's an honour, thank you. I definitely want to help. If making me a collaborator helps to make me help, I'm all for it. :-)
As for your second comment about treeshaking: I feel your frustration! However, keep in mind that the size of _.map is already cut in half. That's already a pretty big win. There are probably functions that are treeshaken even more as well.

prepublish or prepublishOnly?

Right, prepublishOnly is what I meant.

I really appreciate that you want to celebrate this with a 2.0 release, but I adhere to semver quite strictly and I think this should be 1.10.

Okay, 1.10 it is.

That's an honour, thank you. I definitely want to help. If making me a collaborator helps to make me help, I'm all for it. :-)

Done and done.

As for your second comment about treeshaking: I feel your frustration! However, keep in mind that the size of _.map is already cut in half. That's already a pretty big win. There are probably functions that are treeshaken even more as well.

From my understanding, not so much! Most of the half of the codebase that is currently included along with treeshaken map does not have anything to do with map directly. It's just top-level function calls that Rollup cannot determine are side-effect-free, and everything that those top-level function calls depend on. All of that same code will be included in every treeshaken individual export, no matter which one it is. And if we can restructure those top-level function calls to treeshake cleanly, conversely, all Underscore functions should export cleanly from the single file.

@jashkenas I think we're ready for the merge. I can now push the merge button by myself, but I'll give you a chance to review the new commits first.
Regarding the Husky hooks, I had to explicitly invoke git add inside the pre-commit hook to ensure that the UMD bundle would actually be committed. Apparently, doing this inside a pre-commit hook causes the autogenerated files to still appear in the diff and the index after git commit completes. To fix this, I had to add an explicit git reset in the post-commit hook as well.
How to continue from here? Merge the current PR first, then start a new branch in your repo to update the documentation?

Given your approval, I went ahead and pushed the merge button. Hope you don't mind.
This is a big milestone. Thanks so much!


Fix various style issues under newer RuboCop

https://github.com/Homebrew/brew/pull/16338

Thanks @Bo98!


Camera Zoom Vector does the reverse of the expected behavior

Godot version
4.0.Beta1
System information
Windows 10
Issue description
Increasing the Zoom Vector of a Camera Node decreases the size seen in viewport rather than the expected behavior of the size in viewport seen to increase and vice-versa as according to the previous versions of Godot and also the Documentation.
Steps to reproduce

Create a new 2D Scene
Add a Camera node
Increase the Zoom Vector and the Camera Zoom actually decreases and vice-versa.

Minimal reproduction project
Camera Bug.zip

related to #57392

documentation is out of date on this. Behavior was changed on purpose by the PR that Sauermann linked above

Oh! Thank you for explaining. Good day to you all.


Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled. (IDFGH-12617)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.
Core  1 register dump:
PC      : 0x40089fe8  PS      : 0x00060530  A0      : 0x800dd8f4  A1      : 0x3ffd8cf0
A2      : 0x00000000  A3      : 0x3ffb2330  A4      : 0x00000800  A5      : 0x00000000
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x00000004
A10     : 0x3ffb5e68  A11     : 0x80000001  A12     : 0x80091180  A13     : 0x3ffd8be0
A14     : 0x00000003  A15     : 0x00060023  SAR     : 0x00000016  EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000  LBEG    : 0x40089fe4  LEND    : 0x40089ffa  LCOUNT  : 0x0000007f
Backtrace: 0x40089fe5:0x3ffd8cf0 0x400dd8f1:0x3ffd8d00 0x400d464b:0x3ffd8d40
Decoding stack results
0x400dd8f1: i2s_read at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/driver/i2s.c line 2283
0x400d464b: i2s_rec(void*) at C:\Users\yokfr\OneDrive\Documents\Arduino\MonitorRec/MonitorRec.ino line 352
This problem occurred when my recording task was created a second time but it worked fine the first time that it was created.
I'm working with ESP32-WROOM-32E on an Arduini IDE.

Hi @sRubyy,
To understand the register dump, please take a look at this document: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/fatal-errors.html#loadprohibited-storeprohibited. In this case, StoreProhibited exception with EXCVADDR: 0x00000000 indicates that the program has tried writing something to a NULL pointer. Please check your code and make sure you are not passing a NULL pointer argument to i2s_read in MonitorRec.ino line 352.
Perhaps when you create the task the second time, memory allocation fails and the buffer you are using is NULL.
I'll close the issue since it doesn't look like a bug on ESP-IDF side. If you think the issue is in ESP-IDF, please try to narrow it down to a smaller sample program you can share with us.


Update JNI version to released 22.10.0 [databricks]

Signed-off-by: Peixin Li<EMAIL_ADDRESS>Seems inconsistent PR info within github, the github action cannot update check status correctly.
re-create PR to update JNI version

build


Update index.html

fixed h1 title sizing

Hi @Arpit-mohankar,
We thank you for your interest in this project.
We don't want to nest an h1 tag in the title tag.


fix(module:select): allow using arrow buttons on empty list

Prevent the error Cannot read property 'nzValue' of undefined
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?
Using arrow button on empty list will throw an error "Cannot read property 'nzValue' of undefined"
Issue Number: N/A
What is the new behavior?
Select component will not throw the error
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

outdated, close #7018


Minor fixes to make 1.23 as default version in test, support 1.23 to …

…1.24 test upgrades, and remove hardcoding of Kubernetes versions

What this PR does / why we need it:
Changes the default test versions to 1.23, Fix the CRS used by tests to latest CCM version, and fix upgrade test so that machine deployments also use correct version
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 #

e2e test
• [SLOW TEST:1046.247 seconds]
Workload cluster creation
/home/ubuntu/go/src/github.com/oracle/cluster-api-provider-oci/test/e2e/cluster_test.go:50
  Custom networking NSG [PRBlocking]
  /home/ubuntu/go/src/github.com/oracle/cluster-api-provider-oci/test/e2e/cluster_test.go:287
------------------------------
STEP: Tearing down the management cluster

Ran 5 of 22 Specs in 1935.809 seconds
SUCCESS! -- 5 Passed | 0 Failed | 0 Pending | 17 Skipped

Ginkgo ran 1 suite in 32m20.027145867s

upgrade tests
• [SLOW TEST:1484.843 seconds]
Cluster Upgrade Tests
/home/ubuntu/go/src/github.com/oracle/cluster-api-provider-oci/test/e2e/upgrade_test.go:43
  Upgrade of control-plane nodes and worker nodes
  /home/ubuntu/go/src/github.com/oracle/cluster-api-provider-oci/test/e2e/upgrade_test.go:105
------------------------------
STEP: Tearing down the management cluster

Ran 1 of 22 Specs in 1600.069 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 21 Skipped


ci: add job to publish iOS release artifact on merge to master

Adds a job that runs on master and builds/uploads a zip artifact of the Envoy.framework for iOS using the release configurations. This should make it easier for consumers to utilize the most recent iOS versions of Envoy Mobile.
Resolves https://github.com/lyft/envoy-mobile/issues/547.
Tested against this PR, which resulted in the expected artifacts being uploaded successfully:

Signed-off-by: Michael Rebello<EMAIL_ADDRESS>

I thought at some point we had filters on the aar run to only execute when the common or android code was changed in order to prevent wasted CI time on iOS or documentation changes. Do we still want to do something like that, or do we want to create fresh artifacts on every commit to master?

@junr03 please see https://github.com/lyft/envoy-mobile/pull/561 for context 😃

@junr03 please see #561 for context 😃

I see. I guess that is fair. Unfiltered artifacts makes a better experience for maintainers and for users, even if it means burning a bit more CI time.

I see. I guess that is fair. Unfiltered artifacts makes a better experience for maintainers and for users, even if it means burning a bit more CI time.

Right. I'd rather we optimize for the CI experience we want and obtain the machines as necessary rather than limit our functionality up front


Frame out Tokensoft fair queue settings against known limits

Problem
We are currently hoping to use Tokensoft fair queue feature to reduce load during our initial airdrop claim
We dont know exactly how this will look in practice. We should spec that all out in advance now to avoid any surprises.

Impact
This could make or break our user experience of the token launch
Proposed Solution
Assume

300/min Gelato cap from previous testing
Users all are crosschain claiming and claim as soon as their queue period ends
Our goal is <=5 min user claiming xcall delay
Arbitrum is the home chain, therefore not in scope for crosschain claims

Then what would we need in terms of fair queue settings for users to have max 5 min crosschain claim wait?
Example contract is here https://goerli.etherscan.io/address/0xeEDB0e8e589F9ADf6768fc006BaA1C6462f5e563#readContract
Acceptance Criteria

[ ] We have a spec / settings we would need for an incoming user queue to ensure we do not exceed 5min/claim waits
[ ] We can adjust this relatively easily with more data i.e. if 1K/min works

The fair queue creates a random user-specific queue or delay for completing on-chain actions. There is only one parameter to specify: the max queue time. If you set a max queue time of 3600 seconds / 1 hour, then users are randomly assigned a delay between 0 minutes and 1 hour. The max queue time can be updated by the contract owner at any time (e.g. if the queue is taking too long you can shorten it, or if the queue is emptying too quickly, you can lengthen it).
When used with a distributor, the fair queue delays the time at which a user can claim tokens from a tranche. In the Connext case, all tokens will vest in a single tranche. For example, if the tokens vest at 9 am pacific time on August 23 and the fair queue is set to 0 seconds, all users will be able to claim tokens at exactly 9 am pacific time. If the fair queue time is set to one day (86400 seconds), then each user will have a delay ranging from 0 seconds (they can claim immediately at 9 am) to 86400 seconds (they can claim a day later beginning at 9 am August 24).
The random delay for each user is roughly uniform, so in this example about 1/4 of the users will be able to claim within the first 6 hours (by 3 pm pacific time), about 1/2 of the users will be able to claim in the first 12 hours (by 9 pm pacific time), and 3/4 of the users will be able to claim after the first 18 hours (3 am pacific time on August 24).
Here's the comment section directly from the code
/**

@title FairQueue
@notice Fairly assigns a delay time to each address from a uniform distribution over [0, maxDelayTime]
@dev The delay is determined by calculating a distance between the user's address and a pseudorandom value based on a provided salt and a blockhash
using the XOR distance metric. Do not use this contract if the event is public because users could grind addresses until they find one with a low delay.
*/

/**
@notice get a fixed delay for any address by drawing from a unform distribution over the interval [0, maxDelay]
@param user The address for which a delay should be calculated. The delay is deterministic for any given address and pseudorandom value.
@dev The delay is determined by calculating a distance between the user's address and a pseudorandom value using the XOR distance metric (c.f. Kademlia)
Users cannot exploit the fair delay if:

The event is private, i.e. an access list of some form is required
Each eligible user gets exactly one address in the access list
There is no collusion between event participants, block validators, and event owners

The threat of collusion is likely minimal:

the economic opportunity to validators is zero or relatively small (only specific addresses can participate in private events, and a lower delay time does not imply higher returns)
event owners are usually trying to achieve a fair distribution of access to their event
*/

Current estimates of the MAX wait time input to fair queue that is required for a given Gelato rate.
Note:

Only rates <500 /min have been load tested.
Though Gelato rate limiting is per domain, in this estimate we are assuming we have already factored that in, and this is the net average gelato rate after combining rates from all domains.

Wait Time Estimates:

Gelato Rate
MAX Fair Queue Wait
Avg Claim (Connext) Wait

300 req/min
2.77 hours (166 minutes)
80 seconds

400 req/min
2.08 hours (125 minutes)
80 seconds

500 req/min
1.7 hours (100.0 minutes)
80 seconds

600 req/min
1.39 hours (83.33 minutes)
80 seconds

700 req/min
1.19 hours (71.43 minutes)
80 seconds

800 req/min
1.04 hours (62.5 minutes
80 seconds

900 req/min
0.93 hours (55.56 minutes)
80 seconds

1000 req/min
0.83 hours (50.0 minutes)
80 seconds

1500 req/min
0.56 hours (33.33 minutes)
80 seconds

2000 req/min
0.49 hours (29.41 minutes)
80 seconds

what's the next action item here?
cc: @LayneHaber

@alexwhte data is provided, next step is to decide on the params.


Update index.md to check 3 grants

Check first delivery of Societal Grant2
Check Supersig Phase 2 as completed
Check Societal Saas Pricing as completed

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Is it possible to use this with attribute selectors?

I'm trying to do this:
@nest [class^=&] {

but that includes the leading . from the classname. Is there any way around this?

Unlikely because & equals whatever the selector is, e.g. .foo {}, foo {}.
You can work around it by writing this:
foo {
    @nest .& {
        color: red;
    }

    @nest [class=^'&'] {
        color: cyan;
    }
}

Thanks for that, @woble. Yes, that would be a solid workaround.


Moving useTransition -> useNavigation

This PR updates to minimum Remix v1.15 and preparing for v2 by moving from useTransition to useNavigation.

Thanks! The test failures are a bit out of scope for this PR so I'm going to merge and fix them after.

Fixes #261


Add setup details/steps done so far to wiki

Link: https://github.com/beeldengeluid/dane-example-worker/wiki/Setting-up-a-new-worker
@Veldhoen @Kathleendeboer @Martaesplo could you check if things are clear and well-structured? I can't really open a PR because the wiki is separate from the repository sadly (unless there is a different way that I'm unaware of).

Yes, looks good so far. I moved the bit on linting to a separate section on code style. The Docker-bit can probably be updated after the workshop this Thursday (for instance, to refer to a Dockerfile in this repo once it's there).


While running "predict.py" a memory leakage occured

Before running 'predict.py', I had already run 'train.py',it's fine. But when I was running 'predict.py', the terminal started  printing “1/1 [==============================] - 0s 10ms/step“, until my memory usage reached 63.8/64GB, and still don't stop!

Thank you for your question. The memory overflow issue arises from the need to predict over 2 million samples. If we predict these samples sequentially on a CPU without using a GPU, it can indeed lead to memory overflow.
We have addressed this in our new codes version by predicting only 100 samples at a time and then outputting the results, which resolves the memory overflow issue. In the future, we will guide users on how to use GPUs for parallel prediction to further accelerate the process, which is currently under development.
If you have any more questions, please feel free to ask, and I'd be happy to help you with your inquiries.

For GPU usage, employ predict-gpu.py to significantly enhance the prediction output rate, offering a 500x speedup compared to the CPU version.

Thank you for your reply. I have seen the latest release and hope it will works. Also, I'm curious why you used TensorFlow instead of pytorch since pytorch has stronger support for cuda versions than TensorFlow, which could be more convenient to install in different version of OS.
------------------ 原始邮件 ------------------
发件人:                                                                                "youxch/Inverse-design-of-patch-antennas"                                                                                @.>;
发送时间: 2024年4月9日(星期二) 下午5:08
@.>;
<EMAIL_ADDRESS>主题: Re: [youxch/Inverse-design-of-patch-antennas] While running "predict.py" a memory leakage occured (Issue #2)
For GPU usage, employ predict-gpu.py to significantly enhance the prediction output rate, offering a 500x speedup compared to the CPU version.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

So, after a moment of debug, it works, but after a night of running of "predict.py"which runs on RTX A5000. I found that Cuda doesn't occupy it at all, but the graphics memory is full, and as the running time goes by, the inference time for each step also increases from 20ms to 200ms. Is this normal?

Thank you for your feedback. Regarding your first question (why not use PyTorch), it’s because the Keras code logic is more beginner-friendly. We will launch a PyTorch version in the future, so please stay tuned for updates.
For your second question, I have two suggestions: 1)  You can use the predict-gpu code, which is more efficient than using the CPU. 2) In our predict.py, we output a total of 2 million samples, which is a very large number (and not actually necessary). You can reduce the number of iterations in the for loop to decrease the number of prediction samples. Hopefully, this will address your issue.

What is the correspondence between 'ScaleSlot', 'Uw3' in the code and the variables in the paper? I’d appreciate that if you could tell me the correspondence between the parameters in the output txt files and the paper.Thanks a loooot!!

Thank you for your question. You can refer to the new schematic diagram I made below. Figure 1 is the original structure by Professor K. L. Wong. Figure 2 is the structural parameters extracted from the original structure (which correspond exactly to the code). Figure 3 is the annotation of the meaning of each variable (which also corresponds exactly to the code). I hope this helps you. Please feel free to ask any questions.


Change version numbers in the readme

Readme's versions of sequelize now match what they have been updated to in npm.
Closes #31

Codecov Report

Merging #36 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #36   +/-   ##
======================================
  Coverage    94.5%   94.5%
======================================
  Files          65      65
  Lines         692     692
  Branches       91      91
======================================
  Hits          654     654
  Misses         14      14
  Partials       24      24

Continue to review full report at Codecov.

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


Update German localization

Added missing translations and fixed some typos and wording.

Sorry that I did not use Transifex, but it was faster for me do to it directly in the json instead of first signing up to some website and translating it there.

Ok, I'll merge this. But anyway the whole set of translation string will be re-organized before v0.9 because of the UI changes — and also we should take advantage of advanced i18n features such as plural strings.

I agree, just ping me whenever there are new translations needed and I will look into it, making them properly. (BTW why is Github still showing the always failing travis-ci checks here?)

Merged, thanks :)
It's really easier for me to manage these things on Transifex. Currently the project is a bit frozen until I update the new keys, but may I add you to the German team?
As for Travis CI failure, I think it's just that the test has been executed when you submitted the PR, and it was not updated again when a changed Travis CI configuration (ie, when I disabled it)

Sure, feel free to add me to the German team.


⚠ Samsung has degraded performance

In f2b06f4, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1960 ms

Resolved: Samsung performance has improved in 92f4414.


Writing a VSCode extension, want to enable "Attach Visual Studio Code" to kubectl pod

Hi there!
I'm writing a VSCode extension and want to be able to add an "Attach Visual Studio Code" to a Kubectl pod button to my UI. I want to build an experience that closely matches this Kubernetes demo (but with my own custom list of pods). However, after a few days looking through this repo, I'm still struggling to find how to implement this.
Screenshot from Kubernetes demo is here:
I'd be really grateful if you could either point me towards a tutorial for setting this up, or if you could explain the steps that would be great.
Thanks!
Ben

Thanks for opening! If you install the VS Code Dev Containers extension and right click, I believe this attach option is added when exploring containers from the Docker extension. Does installing the Dev Containers extension help?

Yes, sorry if I wasn't clear enough. I am trying to add a "Attach Visual Studio Code" to my own VSCode extension so I need to know the code behind how this feature is implemented.

I've been doing some digging and found a seemingly related question that proposes the following syntax:
code --folder-uri "vscode-remote://attached-container+<SOMETHING>"

I suspect that the "Attach Visual Studio Code" menu option I screenshotted above is launching a terminal command like this. I've tried lots of variants of hex values etc. to try and launch a VSCode window connected to my kubectl pod but haven't yet had any success.
I'd be really grateful if you could share the command to connect to a pod (shown graphically here).
Thanks!

Aha, I found the answer. This fantastic contributor solved it.
cmd = f"code --folder-uri "vscode-remote://k8s-container%2Bcontext%3D{context}+podname={podname}+namespace={namespace}+name={container_name}{some_path}"

Be careful to escape any slashes with %2F in the URI.


Canvas doesn't cover full height

I'm learning svelte-canvas and unable to fit the height of the canvas to the window. The height would stay 640px and if I use append class h-full, the window would overflow. The width works as expected which confuses me.
Here's my setup:
<script>
    import { Canvas } from 'svelte-canvas';
    let width, height;
</script>

<div bind:clientWidth={width} bind:clientHeight={height}>
  <Canvas
    {width}
    {height}
    style="cursor: pointer"
  >
  </Canvas>
</div>

<style>
  div {
    width: 100%;
    height: 100%;
    background-color: white;
  }
</style>

It seems to work as expected in a Svelte REPL.

Percentage height in CSS only works if all of an element's parents (including html and body) have an explicit height as well. The other option is to use height: 100vh, which will work on its own.


Skip callbacks in Api::BaseController inherited from ApplicationController

reset_toolbar sets the @toolbars variable back to {}, but it is
never used in the API code
set_session_tenant sets a value in the session which is never used
in the API code. Besides, current_user will be nil
set_user_time_zone sets a value in the session and Time.zone to
the user timezone, but since current_user is nil it will just set
it to the server timezone.
set_gettext_locale I believe is not needed, since we don't support
Accept-Language in the JSON API
allow_websocket - websockets are not utilized in JSON API calls

@abellotti @Fryguy I may be making some assumptions here, so please keep me honest.
This change comes from https://github.com/ManageIQ/manageiq/pull/11085 where I originally wanted to remove ApplicationController from the Api::BaseController inheritance tree. Since I removed that from that PR as it was too big a change, I'm laying out the first steps here in this separate PR
@miq-bot add-label api, technical debt
@miq-bot assign @abellotti

set_user_time_zone sets a value in the session and Time.zone to the user timezone, but since current_user is nil it will just set it to the server timezone.

Why is current_user nil?  I am sure you need it for RBAC.

@Fryguy ah, I'm mistaken. It's set here: https://github.com/ManageIQ/manageiq/blob/master/app/controllers/api/base_controller/authentication.rb#L25, we just seem to use @auth_user_obj in place of User.current_user throughout the API code. :confused:
I should add a test to prove timezone-related stuff is currently working in the API, since this turned green.

yes, we added setting User.current_user with the Tenancy work.

User.current_user has been around forever, using thread local storage.  But yeah, that method is the important one.  When you stated current_user I thought you were talking about User.current_user

@abellotti @Fryguy this should be :white_check_mark: , but codeclimate hasn't marked it off

I disabled CodeClimate so it's in that in-between state where it will just stay yellow.  That's fine.

👍  🎵

Euwe Backport details:
$ git log
commit d93982449e4a01a65a50cba688958562bb229e9f
Author: Alberto Bellotti<EMAIL_ADDRESS>Date:   Mon Oct 3 16:21:27 2016 -0400

    Merge pull request #11480 from imtayadeway/api/inherited-callbacks

    Skip callbacks in Api::BaseController inherited from ApplicationController
    (cherry picked from commit f29e625cac7939a3412abe534841767cd979e0f8)


Add an option to stash changes before running hooks

In order to ensure any pre-commit tests are run against the files as they will appear in the commit, this PR adds an option to run git stash to save any changes to the working tree before running the scripts, then restore any changes after the scripts finish.
The save/restore procedure is based on Chris Torek's StackOverflow answer to a question asking how to do exactly this.  This implementation does not do a hard reset before restoring the stash by default, since it assumes that if scripts modify tracked files the changes should be kept.  But it does provide this behavior, and git clean, as configurable options.
It follows the convention requested in #4 by making the new stash option default to off.  Although there are no known implementation issues (with the exception of the git bug noted in Torek's SO answer), current scripts may expect modified/untracked files to exist or modify untracked files in a way which prevents applying the stash, making default-on behavior backwards-incompatible.
The tests are split into a separate file.  Since each stash option is tested against a project repository and a clean/reset is done between each test, the tests are somewhat slow.  By splitting the tests into a separate file, we can avoid running them by default.  They can instead be run as test-stash, as part of test-all, and as part of test-travis.
This commit is based off of the work of Christopher Hiller in #47, although the implementation differs significantly due to the use of Promises in place of async, which I found to be significantly clearer, more flexible, and they make the tests significantly more concise.
Thanks for considering,
Kevin
Fixes: #4

Thanks for your pull request, @Swaagie Any opinions?


Tweak: Pipeline release review docs

Adjust headers for better table of contents
Add that shared module code doesn't have to be reviewed

@nf-core-bot fix linting pretty pleeeeaasseee

@nf-core-bot fix linting pretty pleeeeaasseee


Persistent MQTT messaged

Hello,
Thank you for this amazing app.
There might be a way to make the MQTT messages persistent however I have been unable to find the settings in the app.
The issue is that when the alarm is armed from the app and home-assistant is restarted, the alarm is unarmed. I have already made the MQTT messages persistent so when the alarm is armed from within home-assistant I don't have this issue.

That’s entirely up to Home Assistant, the alarm state is set by Home Assistant.  So if you set the alarm to home fine the application, it’s actually Home Assistant se sing back the alarm home via MQTT to change the state of the application.
So you need to find out how to restart Home Assistant and retain the alarm state.  I think this is discussed in the Home Assistant community forums.
This is not an application issue or feature.


Incorrect "Boosters needed" count

It's telling me that an Esper Control list missing 11 rare wildcards only needs 7 more boosters than a White Weenie list missing 4 rare wildcards.

Here's the full Esper list

Weenie list

Thank you for your message. We will investigate your issue.

Hi! I have already investigated your issue. So, what do we have? For Esper list you need 8+22+4=34 different wildcards. They include wildcards that you have in collection and wildcards that you do not have ( you do not have 13 wildcards in screenshot  - 11+2). In deck screenshot you can see, that you need 34 cards without sideboard. So everything shows correctly.


fix: retry on 204 instead of 200

What this PR changes/adds
Changes the status code of the retry from 200 to 204
Why it does that
Briefly state why the change was necessary.
Further notes
Refactor also the TransferProcessApiClient to use Result on the return  so the DataPlaneManagerImpl can act accordingly
Linked Issue(s)
Closes #3468

yeah in this case the controller return void in both cases. But i guess we could also support 200

Codecov Report
Patch coverage: 94.44% and project coverage change: +0.03% :tada:

Comparison is base (f981237) 72.09% compared to head (140fec6) 72.13%.
Report is 3 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3471      +/-   ##
==========================================
+ Coverage   72.09%   72.13%   +0.03%
==========================================
  Files         836      836
  Lines       16985    16996      +11
  Branches      947      950       +3
==========================================
+ Hits        12246    12260      +14
+ Misses       4335     4332       -3
  Partials      404      404

Files Changed
Coverage Δ

...ent/transferprocess/TransferProcessHttpClient.java
82.35% <83.33%> (+3.56%)
:arrow_up:

...aplane/framework/manager/DataPlaneManagerImpl.java
85.96% <100.00%> (+0.77%)
:arrow_up:

... and 6 files with indirect coverage changes

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


Disable DataDog agent in the proper way

After #8 there is a way to selectively disable agent.
That approach does not work as expected. Dynos are crashed after this https://github.com/miketheman/heroku-buildpack-datadog/blob/master/extra/run-dogstatsd.sh#L5 line. This is happening because of the "Dyno crash restart policy":

A dyno “crash” represents any event originating with the process running in the dyno that causes the dyno to stop. That includes the process exiting with an exit code of 0 (or any other exit code).

This PR looks like a proper fix

Hi @bronislav !
Thanks for pointing this out - it must have slipped through.
In surfacing this, I'm wondering if we're doing it the wrong way all along.
The Heroku Buildpack API has the detect script that, if exit 0, uses this buildback.
https://devcenter.heroku.com/articles/buildpack-api#bin-detect
I wonder if it is more appropriate to move the envvar detection to the detect script, so as to prevent the entire package installation to begin with.
I'm not sure which is a better method yet, so let's discuss.
/cc @dreid for previous approach

@miketheman I thought about a way to manage agent by env variables.
About "detect" approach. Detect script runs during "build" phase and there is no way to execute it without rebuilding slug (obviously). But it is OK to rebuild slug if we can make it working.

@bronislav I'm not sure I understand the part about needing to rebuild the slug.
I thought that as each buildpack starts, it looks for the conditions in detect and then acts on those.
The action of setting/removing an envvar triggers a redeploy, does it not?

@miketheman setting/removing env var triggers dyno restart with new environment, but not slug (application container) rebuild. Rebuild is triggered only on the deployment of new code.

Thanks!


Bump prod version numbers for 0.20.2

Issue #, if available:
Description of changes:
Testing (if applicable):
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


extra char in the downloaded private key file

Pull request template
Checklist

[ ] I have read the CONTRIBUTING guide
[ ] branch rebased on develop
[ ] styleguide check npm run validate
[ ] good naming
[ ] keep simple
[ ] video or screenshot attached
[ ] testing instruction attached
[ ] check your PR once again

Description

При выпиле bch сломал сохранение ключей. Это фикс.
Video or screenshot

What and how to test


Use an AtomicInt32 to count pendingUnitCount instead of using AsyncQueue

Adding an item to AsyncQueue<Serial> is linear in the number of pending queue items, thus adding n items to an AsyncQueue before any can execute is in O(n^2). This decision was made intentionally because the primary use case for AsyncQueue was to track pending LSP requests, of which we don’t expect to have too many pending requests at any given time.
SourceKitIndexDelegate was also using AsyncQueue to track the number of pending units to be processed and eg. after indexing SourceKit-LSP, I have seen this grow up to ~20,000. With the quadratic behavior, this explodes time-wise.
Turns out that we don’t actually need to use a queue here at all, an atomic is sufficient and much faster.
Independently, we should consider mitigating the quadratic behavior of AsyncQueue<Serial> or AsyncQueue in general.

@swift-ci Please test


aws_lambda_function.terminate_runner_instances sometimes shows changes that are unrelated to code changes

Describe the bug
We are invoking the module with various different configurations (E.g. different instance_types, AMIs, etc.) to offer a broad range of runners to our development teams. Sometimes when running terraform plan we get a plan output that isn't related to a change we made to our terraform code (E.g.: a simple update to the versions.tf done by Renovate), see example:
  # module.aws-arm64-runner-medium.module.terminate_agent_hook.aws_lambda_function.terminate_runner_instances will be updated in-place
  ~ resource "aws_lambda_function" "terminate_runner_instances" {
        id                             = "arm64-docker-medium-terminate-instances"
      ~ last_modified                  = "2024-08-14T07:10:48.000+0000" -> (known after apply)
      ~ qualified_arn                  = "arn:aws:lambda:eu-central-1:<redact>:function:arm64-docker-medium-terminate-instances:25" -> (known after apply)
      ~ qualified_invoke_arn           = "arn:aws:apigateway:eu-central-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-central-1:<redact>:function:arm64-docker-medium-terminate-instances:25/invocations" -> (known after apply)
      ~ source_code_hash               = "STtJd0//CpU4WGQcc2ojckEcEHtCrD8W2fpx9E1TL64=" -> "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="
        tags                           = {
            "Environment"                            = "arm64-docker-medium"
            "Name"                                   = "arm64-docker-medium"
            "monitoring"                             = "true"
            "runner-sizing"                          = "arm64-docker-medium"
            "tf-aws-gitlab-runner:instancelifecycle" = "spot:yes"
        }
      ~ version                        = "25" -> (known after apply)
        # (24 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

  # module.aws-arm64-runner-medium.module.terminate_agent_hook.aws_lambda_permission.current_version_triggers must be replaced
-/+ resource "aws_lambda_permission" "current_version_triggers" {
      ~ id                  = "TerminateInstanceEvent" -> (known after apply)
      ~ qualifier           = "25" # forces replacement -> (known after apply) # forces replacement
      + statement_id_prefix = (known after apply)
        # (5 unchanged attributes hidden)
    }

Expected behavior
Only actual code changes cause a terraform plan output that contains changes related to resources that are being created by the module.
Additional context
It seems that not all lambda functions are effected. By having a look at our most recent invocations of terraform, it seems that only ~2-3 of the total of 10 modules are affected. The plan output is always related to such changes, which then leads to a new version as shown above.
      ~ last_modified                  = "2024-07-25T05:00:08.000+0000" -> (known after apply)
      ~ qualified_arn                  = "arn:aws:lambda:eu-central-1:<redact>:function:amd64-small-terminate-instances:4" -> (known after apply)
      ~ qualified_invoke_arn           = "arn:aws:apigateway:eu-central-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-central-1:<redact>:function:amd64-small-terminate-instances:4/invocations" -> (known after apply)
      ~ source_code_hash               = "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=" -> "STtJd0//CpU4WGQcc2ojckEcEHtCrD8W2fpx9E1TL64="

Maybe related? https://github.com/hashicorp/terraform-provider-aws/issues/29085


fix: inflection input selector

Updates the input selector to work after inflection have made changes to their ui.
Closes: #245

thank you!


feat(cloud-sources): implement test API

Description
Implement the test API for the cloud source integration type by creating a client from the cloud source and attempt to fetch discovered clusters.
We ignore the returned data, and either return an error or not, similar to how other integrations implement their test functionality.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Here I tell how I validated my change

see CI.

Reminder for reviewers
In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.

Current dependencies on/for this PR:

master

PR #9860   👈

This stack of pull requests is managed by Graphite.

/retest


HTML

HTML
User Story
AS A marketing agency
I WANT a codebase that follows accessibility standards
SO THAT our own site is optimized for search engines.
Acceptance Criteria
GIVEN a webpage meets accessibility standards
WHEN I view the source code
THEN I find semantic HTML elements
WHEN I view the structure of the HTML elements
THEN I find that the elements follow a logical structure independent of styling and positioning
WHEN I view the image elements
THEN I find accessible alt attributes
WHEN I view the heading attributes
THEN they fall in sequential order
WHEN I view the title element
THEN I find a concise, descriptive title

Has:
a header element. (7 points)
a nav element. (7 points)
a main element. (7 points)
more than one section element. (7 points)
an aside element. (7 points)
a footer element. (7 points)

CLOSED PREMATURELY, now closed.


⚠ Bofrost.es has degraded performance

In c8ae55d, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1257 ms

Resolved: Bofrost.es performance has improved in 1e11cec after 6 minutes.


Allow nested errors for nested models, fixes #131

This allows for nested DRF model error messages, such as:
{
"billing_email":["Oppgi en gyldig e-postadresse"],
"account":
    {"email":["Oppgi en gyldig e-postadresse"]}
}

This allows for serializers like this:
class CustomerSerializer(serializers.ModelSerializer):
    account = UserSerializer(read_only=False)

class UserSerializer(serializers.ModelSerializer):

    class Meta:
        model = User
        fields = ('...')

@peec Thanks for this. Could you write a test to ensure this continues to work as we update the adapter for newer versions of ember and ember-data? Thanks.

Hi @peec — are you able to add tests for this?

I am going to resubmit this under a new PR with tests.

Actually, merging this and will submit tests separately.


Fix race in LogcatMonitor

CC @valschneider

nope! still a race, updating shortly

Fixed. I hope the commit message makes sense..

Fixed. I hope the commit message makes sense..

What happens if stop() is called before start() ? It is illegal, but we want a better failure mode than "wait forever".
Proposed solution: Make sure _stopped is set inside __init__, unset it inside start,  immediately return from stop if _stopped is set.

@setrofim Couldn't we just use this:
if not self.is_active()
    return

The way I see it, self.is_active() answers the question "have I called start?"

Updated with the check for is_alive


Can not run local again

Hi,
I've downloaded the source code and run it on local, the first time it is run success and finish.
After that I run again but I got a message:
WARN  The following Key-value store directory contains a previous state:       .../apify_storage/key_value_stores/default       If you did not intend to persist the state - please clear the respective directory and re-start the actor. node_modules/@apify/log/logger.js:32 WARN  The following Request queue directory contains a previous state:       .../apify_storage/request_queues/default       If you did not intend to persist the state - please clear the respective directory and re-start the actor. node_modules/@apify/log/logger.js:32 ERROR    Error: You need to provide something to be extracted
I debug jump to the function
`const createAddProfile = (requestQueue) => async (handle, replies = false) => {
if (!handle) {
return;
}
const isUrl = `${handle}`.includes('twitter.com');

return requestQueue.addRequest({
    url: isUrl
        ? handle
        : `https://twitter.com/${cleanupHandle(handle)}${replies ? '/with_replies' : ''}`,
    userData: {
        label: LABELS.HANDLE,
        handle: cleanupHandle(handle),
    },
});

};`
But after that, the queue was still empty.
How can I fix it?
Thanks and regards,

I fixed the issues.
Thanks.


[suggestion] pass the arguments to the task for running task in parallel

The user story: In many cases, we need to perform file tasks in parallel, simultaneous processing of multiple files.
Could you add an option object(optional) argument to pass into the task. like this:
taker.task('processFile', function(file){
  return new Promise(function(resolve, reject){
    // process a file
    ...
    resolve();
  });
});

taker.task('processAll', function(files, cb){
  Promise.map(files, function(file){
    return take.task('processFile', file)
  }).nodeify(cb);
});

Just pass the wanted array to Promise.map. It's not needed to come from the task.
var files = ['foo', 'bar', 'baz']
taker.task('processAll', function(cb){
  Promise.map(files, function(file){
    return take.task('processFile', file)
  }).nodeify(cb);
});

@tunnckoCore : It's just a sample to describe the scene. And for your question, this means the task 'processAll' can not be reused to another place. But it's an user's choose, you can do such thing.

Hm. Okey, then you can bind it to function.
var files = ['foo', 'bar', 'baz']
function processAll () {
  return Promise.map(this.files, function(file){
    return take.task('processFile', file)
  })
}
taker.task('processAll', processAll.bind({files: files}));
taker.task('all', processAll.bind({files: files}));

Please do not abuse the binding.

All of these examples are confusing and incorrect.  If you want to reuse a "task" just make a module that is the function and require it in each place.  The taker.task API you keep referencing doesn't do magic things like call your function, it just returns one to you or registers on in the system.

Ok, that's all right If the undertaker just serve the 'src()' only. But this is not enough as a general task manager. I've implemented the Folder object in the custom-file to collect the files in the folder. It  provides another way to process for gulp4 except src If undertaker can support it.
Anyway, very thanks the great gulp4 processor. I think it is the best practice of KISS. The gulp4 is a "nothing" processor. So I think undertaker should be one too. It's a little pity.


On linux, binding failed because of Invalid object name

On windows, it doesn't have any issue. Only on linux, the sql generation works. Failed when calling ToListAsync. The database name doesn't have issue because it works on windows and it happened after fetch the data. I have similar entity with integer as id which works. I will try to change another EntityName
Exception message: System.Data.SqlClient.SqlException: Invalid object name 'Experiences'
Stack trace:

Microsoft.EntityFrameworkCore.Storage.IRelationalCommandBuilderFactory:Information: Executed DbCommand (70ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT [x].[Id], [x].[CenterGeoJson], [x].[Disabled], [x].[Information], [x].[InformationHtml], [x].[Instruction], [x].[InstructionHtml], [x].[Publication], [x].[PublicationEdition], [x].[TrackGeoJson], [x].[TrackName], [x].[TrackNum]
FROM [Experiences] AS [x]
WHERE [x].[Id] IN (N'4WD_Adventures_Track_11')
ORDER BY [x].[Id]
Loaded '/root/.nuget/packages/system.diagnostics.stacktrace/4.3.0/lib/netstandard1.3/System.Diagnostics.StackTrace.dll'. Cannot find or open the symbol file.
Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.2/System.Reflection.Metadata.dll'. Cannot find or open the symbol file.
Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.2/System.IO.MemoryMappedFiles.dll'. Cannot find or open the symbol file.
Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.2/System.IO.UnmanagedMemoryStream.dll'. Cannot find or open the symbol file.
fail: Microsoft.EntityFrameworkCore.Query.Internal.SqlServerQueryCompilationContextFactory[1]
      An exception occurred in the database while iterating the results of a query.
      System.Data.SqlClient.SqlException: Invalid object name 'Experiences'.
         at System.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__107_0(Task`1 result)
         at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
         at System.Threading.Tasks.Task.Execute()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
         at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.<ExecuteAsync>d__26.MoveNext()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
         at Microsoft.EntityFrameworkCore.Query.Internal.AsyncQueryingEnumerable.AsyncEnumerator.<BufferlessMoveNext>d__9.MoveNext()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at Microsoft.EntityFrameworkCore.Storage.Internal.SqlServerExecutionStrategy.<ExecuteAsync>d__6`2.MoveNext()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
         at Microsoft.EntityFrameworkCore.Query.Internal.AsyncQueryingEnumerable.AsyncEnumerator.<MoveNext>d__8.MoveNext()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at Microsoft.EntityFrameworkCore.Query.Internal.AsyncLinqOperatorProvider.SelectAsyncEnumerable`2.SelectAsyncEnumerator.<MoveNext>d__4.MoveNext()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
         at Microsoft.EntityFrameworkCore.Query.AsyncQueryMethodProvider.IncludeAsyncEnumerable`1.IncludeAsyncEnumerator`1.<MoveNext>d__7.MoveNext()
      --- End of stack trace from previous location where exception was thrown ---
         at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
         at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
         at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
         at Microsoft.EntityFrameworkCore.Query.Internal.AsyncLinqOperatorProvider.ExceptionInterceptor`1.EnumeratorExceptionInterceptor.<MoveNext>d__5.MoveNext()
      ClientConnectionId:48b1b12f-faa1-4d27-8e8e-b1f9654ca457
      Error Number:208,State:1,Class:16

Steps to reproduce
var query = _db.Experiences.Where(x => ids.Contains(x.Id));
            return includeMedia
                ? await query.Include(x => x.Media).AsNoTracking().ToListAsync()
                : await query.AsNoTracking().ToListAsync();

Further technical details
EF Core version: Microsoft.EntityFrameworkCore 1.1.2
Database Provider: Microsoft.EntityFrameworkCore.SqlServer 1.1.2
Operating system: Linux (docker image: microsoft/aspnetcore:1.1)
IDE: Visual Studio 2017

This can be closed. I found the issue. It wasn't a bug


Please invite me to the community

Name
xie xie
Additional Context
I am here to be #1

Invitation sent to join the GitHub Organization. Welcome to Infraform 🎉Please check your mail to accept the invitation sent by GitHub! 🤖About usInfraform is a remarkable open-source solution tailored for serverless platforms, aimed at empowering creators to craft their infrastructure solutions. 💻 We're thrilled to welcome you into our vibrant community! ✨ We eagerly anticipate your valuable contributions! 🤓 Don't forget to explore our community on Github and connect with us on LinkedIn 💜 Feel free to spread the word about our community to like-minded individuals interested in development, DevOps, technology, and collaborative contributions. 👉💜👈


Document a simple way to type-check .vscode-test.js

Testing #196332
This would also enable IntelliSense. The only way I could get it working is by changing the require to an import, but that then fails at runtime suggesting to use "type": "module" in the package.json.

I think this is something in TS. It seems like require() types recently(?) stopped working in commonjs .js files. For instance, making a new file foo.js in the vscode repo doesn't get types for requiring TypeScript. It also doesn't get types for built-in Node modules, in spite of them appearing as completions.

Intellisense did work in commonjs files when I first made it a few weeks ago.