[*] release!

ChangeLog.rst

@@ -1,3 +1,18 @@
+ayrton (0.6) UNRELEASED; urgency=medium
+
+  * Great improvements in `remote()`'s API and sematics:
+    * Made sure local varaibles go to and come back from the remote.
+    * Code block is executes syncronically.
+    * For the moment the streams are no longer returned.
+    * _python_only option is gone.
+    * Most tests actually connect to a listening netcat, only one test uses `ssh`.
+  * Fixed bugs in the new parser.
+  * Fixed globals/locals mix up.
+  * Scripts are no longer wrapped in a function. This means that you can't return values and that module semantics are restored.
+  * `ayrton` exits with status 1 when the script fails to run (SyntaxError, etc).
+
+ -- Marcos Dione <[email protected]>  Wed, 28 Oct 2015 20:57:19 +0100
+
 ayrton (0.5) unstable; urgency=medium
 
   * Much better command detection.

README.md

@@ -153,20 +153,15 @@ The cherry on top of the cake, or more like the melon of top of the cupcake, is
 (semi) transparent remote execution. This is achieved with the following construct:
 
     a= 42
-    with remote ('localhost') as streams:
-        foo= input ()
-        print (foo)
+    with remote ('localhost'):
         # we can also access variables already in the scope
         # even when we're actually running in another machine
         print (a)
+        # we can modify those variables
+        a= 27
 
-    # streams returns 3 streams: stdin, stdout, stderr
-    (i, o, e)= streams
-    # notice that we must include the \n at the end so input() finishes
-    # and that you must transmit bytes only, no strings
-    i.write (b'bar\n')
-    print (o.readlines ())
-
+    # and those modifications are reflected locally
+    assert (a, 27)
 
 The body of the `with remote(): ...` statement is actually executed in a remote
 machine after connecting via `ssh`. The `remote()` context manager accepts the