There are small typos in:
- docs/source/commandline.md
- tools/isobuild/compiler-deprecated-compile-step.js
- tools/utils/buildmessage.js
Fixes:
- Should read `libraries` rather than `libaries`.
- Should read `file name` rather than `filenanme`.
- Should read `compatibility` rather than `compitability`.
Signed-off-by: Tim Gates <tim.gates@iress.com>
* rename
* we don't need underscore to check whether an array is empty
* add types, resolve type issues
* remove unused markTop in run.js
* Make the type a little more consistent
* Tweak a check for an empty array
Co-Authored-By: Marcelo T Prado <marceloterreiroprado@gmail.com>
I noticed recently that progress messages were no longer displayed (though
the ASCII spinner was still animating). I bisected the problem to the
progress.ts conversion in #10650, and I attempted to reproduce the
conversion, step by step. The problem ended up being the renaming of
._title to .title, which was a mistake because external code accesses
progress._title. Once I updated those invasive access points, progress
messages began displaying once again.
Whenever you're looking at a stack trace generated by the command-line
tool, you see tons and tons of useless stack frames for withValue,
enterJob, and/or capture.
Each of these function calls has its own try-finally block, which is
probably the real reason this pattern is slow, though the excess of
unnecessary stack frames is subjectively gross as well.
Initial build times for the `meteor create --full` app on my machine are
about 4.4 seconds with Meteor 1.8, and just 2.8 seconds after this change,
which is a nice 36% improvement. Rebuild times are not noticeably
different, however.
Looking to the future, flattening this function call pyramid should make
it easier to introduce non-Fiber-based async/await into the buildmessage
system, so that we can start properly propagating promises up the stack.
Since markBoundary is essentially creating a bound wrapper function,
there's no reason we can't actually bind the function to a specific
context (this) object at the same time, instead of having to bind the
function and then wrap it with buildmessage.markBoundary.
This adds a memoized helper function for detecting Emacs throughout the
CLI tool and automatically resorts to "ProgressDisplayStatus" mode when
Emacs is enabled.
In my tests with both Emacs 22 and 27, this nearly doubled performance
when using Meteor from within the Emacs shell (i.e. `M-x shell`).
This means running `meteor update` on Windows with an existing (pre-1.6)
installation of Meteor will install a 32-bit version of Meteor 1.6, even
if the underlying machine architecture could handle a 64-bit version.
To get a native 64-bit version of Meteor, Windows developers should
reinstall Meteor 1.6 from scratch using the new and improved Windows
installer (👋 @abernix), rather than running `meteor update`.
If we really want to make `meteor update` just work ✨, we can
revisit this change in Meteor 1.6.1.
Since we can't change the springboarding logic of existing Meteor
releases, this decision has to be made by the springboarded-to Meteor 1.6
release, and may result in a second springboarding.
Once Windows developers update to a 64-bit version of Meteor 1.6, they may
still wish to run apps using older versions of Meteor where only 32-bit
builds of meteor-tool are available. This commit makes that possible.
