renaming project, halo -> ray (#95)

doc/aliasing.md

@@ -1,6 +1,6 @@
 # Aliasing
 
-An important feature of Halo is that a remote call sent to the scheduler
+An important feature of Ray is that a remote call sent to the scheduler
 immediately returns object references to the outputs of the task, and the actual
 outputs of the task are only associated with the relevant object references
 after the task has been executed and the outputs have been computed. This allows
@@ -10,15 +10,15 @@ However, to provide a more flexible API, we allow tasks to not only return
 values, but to also return object references to values. As an examples, consider
 the following code.
 ```python
-@halo.remote([], [np.ndarray])
+@ray.remote([], [np.ndarray])
 def f()
   return np.zeros(5)
 
-@halo.remote([], [np.ndarray])
+@ray.remote([], [np.ndarray])
 def g()
   return f()
 
-@halo.remote([], [np.ndarray])
+@ray.remote([], [np.ndarray])
 def h()
   return g()
 ```

doc/reference-counting.md

@@ -1,6 +1,6 @@
 # Reference Counting
 
-In Halo, each object is assigned a globally unique object reference by the
+In Ray, each object is assigned a globally unique object reference by the
 scheduler (starting with 0 and incrementing upward). The objects are stored in
 object stores. In order to avoid running out of memory, the object stores must
 know when it is ok to deallocate an object. Since a worker on one node may have
@@ -11,7 +11,7 @@ information.
 ## Reference Counting
 
 Two approaches to reclaiming memory are garbage collection and reference
-counting. We choose to use a reference counting approach in Halo. There are a
+counting. We choose to use a reference counting approach in Ray. There are a
 couple of reasons for this. Reference counting allows us to reclaim memory as
 early as possible. It also avoids pausing the system for garbage collection. We
 also note that implementing reference counting at the cluster level plays nicely
@@ -77,13 +77,13 @@ because they must be passed into `AliasObjRefs` at some point).
 The following problem has not yet been resolved. In the following code, the
 result `x` will be garbage.
 ```python
-x = halo.pull(ra.zeros([10, 10], "float"))
+x = ray.pull(ra.zeros([10, 10], "float"))
 ```
 When `ra.zeros` is called, a worker will create an array of zeros and store
 it in an object store. An object reference to the output is returned. The call
-to `halo.pull` will not copy data from the object store process to the worker
+to `ray.pull` will not copy data from the object store process to the worker
 process, but will instead give the worker process a pointer to shared memory.
-After the `halo.pull` call completes, the object reference returned by
+After the `ray.pull` call completes, the object reference returned by
 `ra.zeros` will go out of scope, and the object it refers to will be
 deallocated from the object store. This will cause the memory that `x` points to
 to be garbage.

doc/scheduler.md

@@ -1,6 +1,6 @@
 # Scheduler
 
-The scheduling strategies currently implemented in Halo are fairly basic and
+The scheduling strategies currently implemented in Ray are fairly basic and
 all use a central scheduler.
 
 * The naive scheduler assigns tasks to workers just taking into account