AppRunner.stop needs to be able to cause any Future which the AppRunner
is waiting on to return, so that it can get back to the top level of its
loop and return. (This is because for some reason it is important that
AppRunner.stop does not return until the app is guaranteed to be
stopped.) This had not been the place for the injected "wait for mongo
to start up before running the AppProcess" future.
This also means we can't use f.future() any more, because that code
assumes that it is the only code allowed to resolve its future (it
unconditionally resolves the future when the wrapped function returns,
which is an error if it is already resolved).
This is tested by 'run errors' which was failing. Also, the test should
only expect 2 unexpected exit code messages, not 3, since we don't print
the message the first time which didn't have a kill before it.
No need to introduce the LayeredCatalog anywhere it's not needed.
Simplify some more things about LayeredCatalog:
- remove unused containingCatalog link from localCatalog to
layeredCatalog
- because of that, simplify LayeredCatalog initialization to occur after
localCatalog (no more circular references required)
- drop some other dead LayeredCatalog methods
If you Blaze.remove a View that is a template rendered by Blaze.renderWithData, or included with an implicit “with” as in `{{> myTemplate someData}}`, Blaze will now remove the DOM of the template, and also remove the implicit “with” (in both cases).
As background, Blaze.remove only works on Views that were attached directly under a DOM element, not inside another View. Blaze.render always attaches the resulting View directly under a DOM element, but Blaze.renderWithData creates a “with” View around the template View. Previously, you could Blaze.remove the “with” View (which is returned by renderWithData), but if you got access to the template’s View some other way and tried to remove it directly, nothing would happen. Now, the correct thing happens (the View is destroyed and the DOM is removed).
In the future, we should consider whether Blaze.remove should work on arbitrary Views, not just Views attached under a DOM element.
Rename Console.directory to Console.path.
Do not attempt to automatically escape spaces in file paths -- it is
hard to define a function that does this only sometimes, rather than all
the time. This is something that we could change later, once we have a better
idea of when we use it.
Directories should not wrap, but, also, we should make sure to automatically
escape spaces ("/ab/a\ b.js" vs "/ab/a b.js"). Because we might need to deal with
user input, we don't know if the user has already escaped the spaces before getting
the string. As such, we should only escape spaces that haven't already been escaped.
I think that this makes the API too complicated, but we might want to treat
directories the same way that we do commands (use some chalk when needed,
do not wrap, etc). This introduces the Console.directory function.
Of course, it is not really clear to me what happens if a directory is inside a command.
(ex: 'cd <directory>'). Right now, there is no difference. It makes sense to me that
we might want to keep the entire command the same style, so I am not wrapping those
in additional Console.directory units for now.
