New implementation of lost counter
Updated lost counter
Merge branch 'lab3' into lost-counter

* lab3:
  Fixed missing curly brackets in one-stmt if-while constructor
  bug fixes (ignoring empty lines in CPVar)
  Added support for one-statement if and while bodies
  working string indexing
  Working string initilaizer
  string type compiles to char array

Conflicts:
	PTCORE/RTFM-SRC/counter.coore
Always reset all instances
Better naming
Merge branch 'lab3' into lost-counter

* lab3:
  Handle local function calls
Handle functions returning values

This commit changes when resources are claimed. We now expect all methods defined on an object that returns a value (i.e. not void) to not do any operations that needs the object to be locked. If such operations are needed this must be done in a void function which then will be called with sync or async and lock the object.
New branch for GraphViz support
Add linebreak to print
Added complete support for graphviz representation of class>task>function hierarchy
Added working flags for -gv_obj, -gv_task and -gv_res. The three different "graphical" modes will show different levels of the hierarchy.
Added websocket files
Make cOOre generate correct -core code
Change cOOre compiler to add local as suffix

See: http://rtfm.codeplex.com/wikipage?title=Bindings1&referringTitle=2nd%20Challenge

Recall, that the local definitions were introduced a while back as a means to run under the claim of the parenting object. Without distinguishing local from ordinary function we would run into the situation where we try to re-claim a lock, that we have already taken (causing a sort of deadlock). We chose to allow re-claiming ONLY the case is stems from a direct synchronous call from within the same object (and hence discarding re-claims occurring in sync chains.)

This leads us into the first discussion on how this can be be achieved by the -cOOre/-core compilers.

Looking deeper at the problem, both -cOOre and -core perform specialisation, (-cOOre on basis of object instances, while -core on basis of task and function instances.)

For this example, the -cOOre compiler will generate an instance of root (of the class definition Root). Any tasks and functions will be pre-pended with root_, e.g., the function f(...) in the root instance is assumed the qualified name root_f(...) and the local function root_f_local(...) accordingly. (Notice the subtle change of post pending local instead of prepending it, the reason will soon be revealed...)

To get this working, we need the collaboration of the -core compiler. We have given the definition for f_local(...), but for the correct composition with the caller assuming root_f_local(...) we need to instruct -core to specialise the inclusion of "ExtRoot.core".
Add handling of include <file> as "str"

See: http://rtfm.codeplex.com/wikipage?title=Bindings1&referringTitle=2nd%20Challenge

In order to handle external code in cOOre we need to specialise function names to be prefixed with the parent object of the cOOre object in the -core compiler.
Add example for first step
Added support for state acces from external code
Add all examples from docs
Allow implicit claims and for external bindings
Specialize more statements

We need to specialize some function calls as well in order to allow external code to call functions on the parent object.