Introduces a "Patience" class which lets CPU-bound operations like the
constraint solver yield every so often, and print messages if an
operation (CPU-bound or not) are taken or not.
There was a race condition between the bundle process and when we established
the client watch set. We now store the future for the old bundle process so
that it cannot be invalidated.
- If they're in deferred-registration state, give them their
registration link and exit.
- Before running the login prompt, mention that it's a Meteor developer
account which you can sign up for on www.meteor.com.
Now ServiceConnection's guarantee is that once a DDP connection is
successfully negotiated, it won't restart. This relies on the assumption
that the only use of reconnect({_force: true}) is DDP protocol
negotiation!
Drop some unnecessary (and flawed, for this application) `disconnect`
stream events.
Also, remove some unnecessary `new` calls.
Fixes 'meteor mongo some-galaxy app'.
_.once has the problem that if you call the once'd function while it is
still in progress (re-entrantly or in another Fiber), it returns
undefined immediately. That's bad for uniload! uniload already has a
cache, so just use that. (In the future, perhaps detect an attempt to
uniload something that's currently in the process of being uniloaded in
another fiber and block until the other fiber is ready.)
Using instanceof with things you've uniloaded is a little sketchy: maybe
two different uniload calls will end up with two different copies of
Package.meteor.Meteor.Error, and it seems kind of hairy to ensure you're
not mixing and matching copies. However, Meteor.Errors are all tagged
with a string errorType, which fills me with much less fear,
uncertainty, and doubt than instanceof.
- ServiceConnection should never try to reconnect. It's already the case
that we don't hold open ServiceConnections over long periods while
idle; it makes the class much simpler if it corresponds to a single
TCP connection. This also means that as soon as we have one connection
failure (eg you're offline) we can fail instantly instead of retrying
pointlessly.
- Drop the explicit timeout code in ServiceConnection. There's already
timeout handling in stream_client, and now that we don't retry, it
actually takes effect.
- Be more rigorous about uses of Future in ServiceConnection. Ensure
that each Future is only used once (ie, avoid "Future resolved more
than once" errors). Hopefully fixes#2390.
- ServiceConnection constructor now blocks until it's connected (and
throws if there's a connection failure). Maybe this introduces a tiny
bit more latency to the connection, but it makes it much easier to
handle errors properly.
- In packageClient.handlePackageServerConnectionError, show the error
message corresponding to the connection failure.
- In Node, the (newish) error passed to the Stream callback is now a
"DDP.ConnectionError" object. We can detect this in the tool (and we
don't even need to do some complex uniload/instanceof dance, since
error classes made with Meteor.makeErrorType label themselves with a
string errorType). We also no longer have a special
ServiceConnection.ConnectionTimeoutError.
You'd think that when making a commit with a name like 'fix
reports-stats test from release', this "glasser" fellow would consider
checking to see if he broke the other use case, but that's apparently
too much to ask.
This means that we won't have to bump the version number of every
npm-using package every time we do a patch update of Node. (Though we
will have to do it right now, once.) (That's because the .node_version
file is part of the package's contents... which is semantically
correct.)
The point of the other catalogs is to allow local packages to override
server packages. This has nothing to do with releases. So rather than
keep release metadata in memory multiple times and force developers to
wonder "what's the different between catalog.complete.getReleaseTrack
and catalog.official.getReleaseTrack?", now it really just only exists
on catalog.official.
This should be a performance win (no need to load constraint-solver
unless you actually need to use it!), and it's what I wanted to do
initially instead of lazily loading mori, but it wasn't feasible with
the old super-recursive catalog.
This fixes an issue where running 'curmeteor rebuild' twice (!) died the
second time with a "Can't load npm module 'mori'" error. This is because
uniload (when run from a checkout) sets up Npm.require to read directly
from PACKAGE/.build.PACKAGE/npm/node_modules, which might get deleted
later in the process! There are some complex and maybe slow ways to
resolve this general issue (copy the node_modules somewhere else?) but
for now, the easiest way to avoid the issue is just to load Npm modules
immediately inside packages which need to be uniloaded.
- The checkout catalog.uniload now does not uniload a resolver, and
instead just has a trivial implementation of resolveConstraints.
(The 'built' catalog.uniload already didn't use the resolver.)
- catalog.complete.resolveConstraints now throws an error if there's
no resolver; this is OK, because creating the resolver now only
uses the distinct catalog.uniload, so there's no recursion issue.
- don't record version dependencies in packages during uniload (this
protects against using release.current before it is initialized)
- PackageLoader should never download packages during uniload (this
protects against using catalog.uniload.isLocalPackage before it is
initialized)
