Go to file
joeduffy 3a5217d722 Fix truncated output...again
The prior workaround to avoid truncated pending stdout writes, it
turns out, doesn't actually work.  (Piping output leads to more buffering
and asynchrony, and turned up additional problems.)  Digging through some
GitHub issues led me to these "best practices":

    https://nodejs.org/api/process.html#process_process_exit_code

    The reason this is problematic is because writes to process.stdout in
    Node.js are sometimes non-blocking and may occur over multiple ticks of
    the Node.js event loop. Calling process.exit(), however, forces the
    process to exit before those additional writes to stdout can be performed.

    Rather than calling process.exit() directly, the code should set the
    process.exitCode and allow the process to exit naturally by avoiding
    scheduling any additional work for the event loop.

This change adopts this part of the best practices, by simply setting
exitCode upon normal termination and letting the event loop quiesce.

Note that I am still not obeying the other part of the guidance:

    If it is necessary to terminate the Node.js process due to an error
    condition, throwing an uncaught error and allowing the process to
    terminate accordingly is safer than calling process.exit().

Somewhat confusingly, writes to process.stderr do not suffer from these
same problems, because writes to stderr are synchronous.  We prefer to
tear down the process gracefully, without an unhandled exception, and
we are okay losing some stdout writes as a result, given that all error-
related ones will have gone to stderr.
2017-01-17 14:54:15 -08:00
cmd Add scaffolding for mu apply, compile, and plan 2017-01-17 14:40:55 -08:00
docs Start a MuJS design document 2017-01-17 11:42:49 -08:00
examples Add a example web crawler Mu blueprint 2017-01-12 14:59:18 -08:00
lib Update the library mu examples to the latest 2016-12-16 11:23:37 -08:00
pkg Track module imports 2017-01-17 09:50:32 -08:00
sdk/javascript Make the Mu library a Node package; get it compiling 2016-12-12 17:56:13 -08:00
tools/mujs Fix truncated output...again 2017-01-17 14:54:15 -08:00
.gitignore Gitignore *.swp files 2016-11-16 09:28:46 -08:00
.gitmodules Add Docker Compose and Kubernetes conversions as submodules 2016-11-01 10:30:39 -07:00
glide.lock Switch back to the official YAML repo 2016-12-09 11:59:05 -08:00
glide.yaml Switch back to the official YAML repo 2016-12-09 11:59:05 -08:00
main.go Move glogging into Mu command startup/teardown 2016-11-19 16:42:27 -08:00
Makefile Test packages when making the project 2016-11-15 19:25:06 -08:00
README.md Add a README pointer to the overview doc 2017-01-01 15:19:22 -08:00

Mu

Mu is a framework and toolset for creating reusable stacks of services.

If you are learning about Mu for the first time, please see the overview document.

Building and Testing

To build Mu, first clone it into a standard Go workspace:

$ mkdir -p $GOPATH/src/github.com/marapongo
$ git clone git@github.com:marapongo/mu $GOPATH/src/github.com/marapongo/mu

A good default value for GOPATH is ~/go.

Mu needs to know where to look for its runtime, library, etc. By default, it will look in /usr/local/mu, however you can override this with the MUPATH variable. Normally it's easiest just to create a symlink:

$ ln -s $GOPATH/src/github.com/marapongo/mu /usr/local/mu

There is one additional build-time dependency, golint, which can be installed using:

$ go get -u github.com/golang/lint/golint

And placed on your path by:

$ export PATH=$PATH:$GOPATH/bin

At this point you should be able to build and run tests from the root directory:

$ cd $GOPATH/src/github.com/marapongo/mu
$ make

This installs the mu binary into $GOPATH/bin, which may now be run provided make exited successfully.