No description
Find a file
joeduffy 69b23ca2ea Implement structured token binding
This change fixes a whole host of issues with our current token binding
logic.  There are two primary aspects of this change:

First, the prior token syntax was ambiguous, due to our choice of
delimiter characters.  For instance, "/" could be used both as a module
member delimiter, in addition to being a valid character for sub-modules.
The result is that we could not look at a token and know for certain
which kind it is.  There was also some annoyance with "." being the
delimiter for class members in addition to being the leading character
for special names like ".this", ".super", and ".ctor".  Now, we just use
":" as the delimiter character for everything.  The result is unambiguous.

Second, the simplistic token table lookup really doesn't work.  This is
for three reasons: 1) decorated types like arrays, maps, pointers, and
functions shouldn't need token lookup in the classical sense; 2) largely
because of decorated naming, the mapping of token pieces to symbolic
information isn't straightforward and requires parsing; 3) default modules
need to be expanded and the old method only worked for simple cases and,
in particular, would not work when combined with decorated names.
2017-02-08 14:10:16 -08:00
cmd Add a mu verify command 2017-02-03 19:27:37 -08:00
docs Add a couple TODOs to the resources design doc 2017-02-02 11:20:08 -08:00
examples Add a tsconfig to the Thumbnailer example 2017-02-03 12:14:40 -08:00
lib Minor comment update 2017-02-03 05:40:22 -08:00
pkg Implement structured token binding 2017-02-08 14:10:16 -08:00
tools/mujs Implement structured token binding 2017-02-08 14:10:16 -08:00
.gitignore Check in a missing test file 2017-02-01 19:41:13 -08:00
.gitmodules Add Docker Compose and Kubernetes conversions as submodules 2016-11-01 10:30:39 -07:00
glide.lock Update the glide file 2017-02-01 20:06:31 -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 Clean up the Makefile 2017-01-27 15:42:55 -08:00
README.md Remove an errant * 2017-02-02 11:14:10 -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.

Architecture

Architecture

Prerequisites

Mu is written in Go and uses Glide for dependency management. They must be installed:

If you wish to use the optional lint make target, you'll also need to install Golint:

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

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
$ glide update
$ make

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

Compilers

The Mu compilers are built and tested independently from the Mu tool and runtime written in Go. Please see the respective pages for details on this process for each compiler:

Debugging

The Mu tools have extensive logging built in. In fact, we encourage liberal logging in new code, and addding new logging when debugging problems. This helps to ensure future debugging endeavors benefit from your sleuthing.

All logging is done using Google's Glog library. It is relatively barebones, and adds basic leveled logging, stack dumping, and other capabilities beyond what Go's built-in logging routines offer.

The Mu command line has two flags that control this logging and that can come in handy when debugging problems. The --logtostderr flag spews directly to stderr, rather than the default of logging to files in your temp directory. And the --verbose=n flag (-v=n for short) sets the logging level to n. Anything greater than 3 is reserved for debug-level logging, greater than 5 is going to be quite verbose, and anything beyond 7 is extremely noisy.

For example, the command

$ mu compile blueprint.yaml --logtostderr -v=5

is a pretty standard starting point during debugging that will show a fairly comprehensive trace log of a compilation.