make test
no LC at this point
no LC at this point
comment failing tests
Merge pull request #176 from francoisfonteyn/Make-test

Allow "make test"
base/type.oz
try new ozs
forgot 2 passing tests
base/type.oz
Merge branch 'Make-more-test' into Make-test
Merge pull request #177 from francoisfonteyn/Make-test

New tests passing/adapted
tests for utf-8
remove test with Thread.resume
Merge pull request #178 from francoisfonteyn/Make-test

Tests: type.oz and thread.oz
Remove unused methods BoostBasedVM::setApplication{URL,Args}

* Application URL and args are put in the registry directly by emulator.cc.
Add a BoostVM class to hold what needs a VM in a Boost environment

* BoostBasedVM::boostVMFor() needs to be fixed.
  We could extend VirtualMachine or find
  another smarter way to have constant-time boostVMFor().
* UUID generation should be per vm if we want to avoid locking
  on the random generator.
* Boost classes taking a reference to a BoostBasedVM now take a BoostVM
  since they need to access BoostVM features. An alternative could be to pass
  the BoostVM as the first argument in the different methods,
  but the constructor needs it too and it is much easier with the lambdas.
Let each BoostVM run in its own thread, and the main thread do the ASIO

* We reuse the _conditionWorkToDoInVM condition variable to wait
  efficiently between VM runs since it is unused outside of run().
* Added VMs should be start()'ed but it should not be needed to call run(vm)
  on the main thread, unless the previous VMs died and we want that one
  to outlive others.
Have a saner implementation of BoostVM::forVM(): inherit from VirtualMachine

* Actually, it is quite a similar layout (VirtualMachine storage in BoostVM),
  except now the VM pointer also happens to be a BoostVM pointer.
Wrap the VM initialization process in a lambda

* So we can reuse that code later to initialize other VMs.
* As we are in main() it is safe to pass by reference, but
  we prefer to copy captured variable to avoid any possible
  side-effects between VMs.
Make the VM initialize itself in its own thread

* This is a much simpler and saner design.
* The thread is started at the end of the constructor, and BoostVM::run()
  is naturally blocking since it is executing on the same thread as the caller!
* There is only a single invocation of BoostBasedVM::runIO() in the main thread.
* No more waiting from VM threads, they are doing both initialization
  and running the VM and only do that.