bud 0.0.2 → 0.0.3

data/docs/README.md

@@ -3,11 +3,13 @@ Welcome to the documentation for *Bud*, a prototype of Bloom under development.
 
 The documents here are organized to be read in any order, but you might like to try the following:
 
-* [intro.md](intro.md): A brief introduction to Bud and Bloom
-* [getstarted.md](getstarted.md): A quickstart to teach you basic Bloom concepts, the use of `rebl` interactive terminal, and the embedding of Bloom code in Ruby via the `Bud` module.
-* [operational.md](operational.md): an operational view of Bloom, to provide a more detailed  model of how Bloom code is evaluated by Bud.
-* [Bud RubyDoc](http://rubydoc.info/github/bloom-lang/bud/): RubyDoc on the language constructs and runtime hooks provided by the Bud module
-* [cheat.md](cheat.md): A concise "cheat sheet" to remind you about Bloom syntax.
-* [ruby_hooks.md](ruby_hooks.md): Bud module methods that allow you to interact with the Bud evaluator from other Ruby threads.
-* [bud-sandbox](http://github.com/bloom-lang/bud-sandbox): a github repository including lots of useful libraries and examples.
-* [bfs.md](bfs.md):  A walkthrough of the Bloom distributed filesystem.
+* **intro.md**: A brief introduction to Bud and Bloom
+* **getstarted.md**: A quickstart to teach you basic Bloom concepts, the use of `rebl` interactive terminal, and the embedding of Bloom code in Ruby via the `Bud` module.
+* **operational.md**: an operational view of Bloom, to provide a more detailed  model of how Bloom code is evaluated by Bud.
+* **cheat.md**: A concise "cheat sheet" to remind you about Bloom syntax.
+* **modules.md**: An overview of Bloom's modularity features.
+* **ruby_hooks.md**: Bud module methods that allow you to interact with the Bud evaluator from other Ruby threads.
+* **visualizations.md**: Overview of the `budvis` and `budplot` tools for visualizing Bloom program analyses.
+* **bfs.md**:  A walkthrough of the Bloom distributed filesystem.
+* **bud-sandbox**: a github repository including lots of useful libraries and examples.
+* **Bud RubyDoc**: The Bud gem ships with RubyDoc on the language constructs and runtime hooks provided by the Bud module.  (To see rdoc, you run `gem server` from a command line and open [http://0.0.0.0:8808/](http://0.0.0.0:8808/))

data/docs/bfs.md

@@ -1,6 +1,6 @@
 # BFS: A distributed file system in Bloom
 
-In this document we'll use what we've learned to build a piece of systems software using Bloom.  The libraries that ship with BUD provide many of the building blocks we'll need to create a distributed,
+In this document we'll use what we've learned to build a piece of systems software using Bloom.  The libraries that ship with Bud provide many of the building blocks we'll need to create a distributed,
 ``chunked'' file system in the style of the Google File System (GFS):
 
  * a [key-value store](https://github.com/bloom-lang/bud-sandbox/blob/master/kvs/kvs.rb) (KVS)
@@ -360,20 +360,42 @@ To maintain the durability requirement that `REP_FACTOR` copies of every chunk a
 that maintains a near-consistent view of global state, and takes steps to correct violated requirements.  
 
 __chunk_cache__ is the master's view of datanode state, maintained as described by collecting and pruning heartbeat messages.  
+After defining some helper aggregates (__chunk_cnts_chunk__ or replica count by chunk, and __chunk_cnt_host__ or datanode fill factor), 
 
         cc_demand <= (bg_timer * chunk_cache_alive).rights
         cc_demand <= (bg_timer * last_heartbeat).pairs {|b, h| [h.peer, nil, nil]}
         chunk_cnts_chunk <= cc_demand.group([cc_demand.chunkid], count(cc_demand.node))
         chunk_cnts_host <= cc_demand.group([cc_demand.node], count(cc_demand.chunkid))
 
-After defining some helper aggregates (__chunk_cnts_chunk__ or replica count by chunk, and __chunk_cnt_host__ or datanode fill factor), 
+we define __lowchunks__ as the set of chunks whose replication factor is too low:
+
 
         lowchunks <= chunk_cnts_chunk { |c| [c.chunkid] if c.replicas < REP_FACTOR and !c.chunkid.nil?}
-    
-        # nodes in possession of such chunks
+
+We define __chosen_dest__ for a given underreplicated chunk as the datanode with
+the lowest fill factor that is not already in possession of the chunk:
+
         sources <= (cc_demand * lowchunks).pairs(:chunkid => :chunkid) {|a, b| [a.chunkid, a.node]}
         # nodes not in possession of such chunks, and their fill factor
         candidate_nodes <= (chunk_cnts_host * lowchunks).pairs do |c, p|
           unless chunk_cache_alive.map{|a| a.node if a.chunkid == p.chunkid}.include? c.host
             [p.chunkid, c.host, c.chunks]
-### I am autogenerated.  Please do not edit me.
+          end
+        end
+    
+        best_dest <= candidate_nodes.argagg(:min, [candidate_nodes.chunkid], candidate_nodes.chunks)
+        chosen_dest <= best_dest.group([best_dest.chunkid], choose(best_dest.host))
+
+and the __best_src__ as any arbitrary node that is in possession of the chunk:
+
+        best_src <= sources.group([sources.chunkid], choose(sources.host))
+
+Finally, we initiate a background replication job for a given chunk by inserting
+the chosen chunkid, source and destination into __copy_chunk__
+
+        copy_chunk <= (chosen_dest * best_src).pairs(:chunkid => :chunkid) do |d, s|
+          [d.chunkid, s.host, d.host]
+        end
+
+
+

data/docs/bfs.raw

@@ -1,6 +1,6 @@
 # BFS: A distributed file system in Bloom
 
-In this document we'll use what we've learned to build a piece of systems software using Bloom.  The libraries that ship with BUD provide many of the building blocks we'll need to create a distributed,
+In this document we'll use what we've learned to build a piece of systems software using Bloom.  The libraries that ship with Bud provide many of the building blocks we'll need to create a distributed,
 ``chunked'' file system in the style of the Google File System (GFS):
 
  * a [key-value store](https://github.com/bloom-lang/bud-sandbox/blob/master/kvs/kvs.rb) (KVS)

data/docs/bust.md

@@ -1,4 +1,4 @@
-BUST stands for BUd State Transfer and it is a REST interface to BUD.  BUST consists of a Bud implementation of a client and server.  The client implements bindings to a subset of the Ruby Nestful library, and the server is a lightweight HTTP server written in Ruby.  Note that the BUST server currently sets the "Access-Control-Allow-Origin: *" HTTP header to override web browsers' same-origin policy.
+BUST stands for BUd State Transfer and it is a REST interface to Bud.  BUST consists of a Bud implementation of a client and server.  The client implements bindings to a subset of the Ruby Nestful library, and the server is a lightweight HTTP server written in Ruby.  Note that the BUST server currently sets the "Access-Control-Allow-Origin: *" HTTP header to override web browsers' same-origin policy.
 
 Right now BUST supports "GET" and "POST" requests, and may support "DELETE" and "PUT" requests in the future.
 
@@ -18,7 +18,7 @@ In your class, make sure to:
 
     include Bust
 
-That's it!  Now a BUST server will be started up when your class is instantiated.  By default, this server will listen on port 8080, but you can change this by passing a port via the "bust_port" option when you instantiate your class.
+That's it!  Now a BUST server will be started up when your class is instantiated.  This server will listen on an open port; it will print out "Bust server listening on port xxxxx" to let you know which port it has selected.  But you can select a specific port by passing a port via the "bust_port" option when you instantiate your class.
 
 You can test out the BUST server using Ruby's "net/http" library if you want, and you can also check out "BUST Inspector", a sample AJAX application that allows you to view the state of a bud instance.
 

data/docs/cheat.md

@@ -55,7 +55,7 @@ Default attributes: `[:@address, :val] => []`
 (Bloom statements with channel on lhs must use async merge (`<~`).)
 
     channel :msgs
-    channel :req_chan, [:@address, :cartnum, :storenum] => [:command, :params]
+    channel :req_chan, [:cartnum, :storenum, :@server] => [:command, :params]
 
 ### periodic ###
 System timer manifested as a scratch collection.<br>
@@ -97,7 +97,7 @@ Left-hand-side (lhs) is a named `BudCollection` object.<br>
 Right-hand-side (rhs) is a Ruby expression producing a `BudCollection` or `Array` of `Arrays`.<br>
 BloomOp is one of the 5 operators listed below.
 
-## Bloom Operators ##
+### Bloom Operators ###
 merges:
 
 * `left <= right` &nbsp;&nbsp;&nbsp;&nbsp; (*instantaneous*)
@@ -115,7 +115,7 @@ insert:<br>
 Note that unlike merge/delete, insert expects a single fact on the rhs, rather
 than a collection.
 
-## Collection Methods ##
+### Collection Methods ###
 Standard Ruby methods used on a BudCollection `bc`:
 
 implicit map:
@@ -154,7 +154,7 @@ implicit map:
 
     stdio <~ bc.inspected
 
-`chan.payloads`: shorthand for `chan {|t| t.val}`, only defined for channels
+`chan.payloads`: projects `chan` to non-address columns. only defined for channels
 
     # at sender
     msgs <~ requests {|r| "127.0.0.1:12345", r}
@@ -183,6 +183,8 @@ implicit map:
 * Summary aggs: `count`, `sum`, `avg`
 * Structural aggs: `accum`
 
+Note that custom aggregation can be written using `reduce`.
+
 ## Collection Combination (Join) ###
 To match items across two (or more) collections, use the `*` operator, followed by methods to filter/format the result (`pairs`, `matches`, `combos`, `lefts`, `rights`).
 
@@ -225,7 +227,7 @@ Like `pairs`, but implicitly includes a block that projects down to the left ite
 `rights(`*hash pairs*`)`: 
 Like `pairs`, but implicitly includes a block that projects down to the right item in each pair.
 
-`flatten`<br>
+`flatten`:<br>
 `flatten` is a bit like SQL's `SELECT *`: it produces a collection of concatenated objects, with a schema that is the concatenation of the schemas in tablelist (with duplicate names disambiguated.) Useful for chaining to operators that expect input collections with schemas, e.g. group:
 
     out <= (r * s).matches.flatten.group([:a], max(:b))

data/docs/getstarted.md

@@ -107,14 +107,14 @@ See how the second tick produced no output this time?  After the first timestep,
 ### Summing Up ###
 In these initial examples we learned about a few simple but important things:
 
-* **rebl**: the interactive Bloom terminal and its `/` commands.
-* **Bloom collections**: unordered sets of items, which are set up by collection declarations.  So far we have seen persistent `table` and transient `scratch` collections.  By default, collections are structured as \[key,value\] pairs.
+* **rebl**: the interactive Bloom terminal and its slash (`/`) commands.
+* **Bloom collections**: unordered sets of items, which are set up by collection declarations.  So far we have seen persistent `table` and transient `scratch` collections.  By default, collections are structured as \[key,val\] pairs.
 * **Bloom statements**: expressions of the form *lhs op rhs*, where the lhs is a collection and the rhs is either a collection or an array-of-arrays.   
 * **Bloom timestep**: an atomic single-machine evaluation of a block of Bloom statements.
 * **Bloom merge operators**:
   * The `<=` merge operator for *instantaneously* merging things into a collection.
-  * The `<~` merge operator for *asynchronously* merging things into collections outside the control of tick evaluation: e.g. terminal output.* 
-* **stdio**: a built-in Bloom collection that, when place on the rhs of an asynch merge operator `<~`, prints its contents to stdout.
+  * The `<~` merge operator for *asynchronously* merging things into collections outside the control of tick evaluation: e.g. terminal output.
+* **stdio**: a built-in Bloom collection that, when placed on the lhs of an asynch merge operator `<~`, prints its contents to stdout.
 * **inspected**: a method of Bloom collections that transforms the elements to be suitable for textual display on the terminal.
 
 ## Chat, World! ##
@@ -147,7 +147,7 @@ This defines a [Ruby mixin module](http://www.ruby-doc.org/docs/ProgrammingRuby/
 1. It contains a Bloom `state` block, containing collection declarations.  When embedding Bloom in Ruby, all Bloom collection declarations must appear in a `state` block of this sort.
 2. This particular state block uses a kind of Bloom collection we have not seen before: a `channel`.  A channel collection is a special kind of scratch used for network communication.  It has a few key features:
 
-  * Unlike the default \[key,value\] structure of scratches and tables, channels default to the structure \[address,payload\]: the first field is a destination IP string of the form 'host:port', and the second field is a payload to be delivered to that destination--typically a Ruby array.  (For the record, the default key of a channel collection is the *pair* \[address,payload\]).
+  * Unlike the default \[key,val\] structure of scratches and tables, channels default to the structure \[address,val\]: the first field is a destination IP string of the form 'host:port', and the second field is a payload to be delivered to that destination--typically a Ruby array.  (For the record, the default key of a channel collection is the *pair* \[address,val\]).
   * Any Bloom statement with a channel on the lhs must use the async merge (`<~`) operator.  This instructs the runtime to attempt to deliver each rhs item to the address stored therein. In an async merge, each item in the collection on the right will appear in the collection on the lhs *eventually*.  But this will not happen instantaneously, and it might not happen atomically--items in the collection on the rhs may "straggle in" individually over time at the destination.  And if you're unlucky, this may happen after an arbitrarily long delay (possibly never).  The use of `<~` for channels reflects the typical uncertainty of real-world network delivery.  (Don't worry, the Bud sandbox provides libraries to wrap that uncertainty up in convenient ways.)
 
 Given this protocol (and the Ruby constant at the bottom), we're now ready to examine `examples/chat/chat_server.rb` in more detail:
@@ -188,7 +188,7 @@ The first is pretty simple:
 
      nodelist <= connect.payloads
 
-This says that whenever messages arrive on the channel named "connect", their payloads (i.e. their non-address field) should be instantaneously merged into the table nodelist, which will store them persistently.  Note that nodelist has a \[key/value\] pair structure, so we expect the payloads will have that structure as well.
+This says that whenever messages arrive on the channel named "connect", their payloads (i.e. their non-address field) should be instantaneously merged into the table nodelist, which will store them persistently.  Note that nodelist has a \[key/val\] pair structure, so we expect the payloads will have that structure as well.
 
 The next Bloom statement is more complex.  Remember the description in the "basic idea" at the beginning of this section: the server needs to accept inbound chat messages from clients, and forward them to other clients.  
 
@@ -196,16 +196,16 @@ The next Bloom statement is more complex.  Remember the description in the "basi
     
 The first thing to note is the lhs and operator in this statement.  We are merging items (asynchronously, of course!) into the mcast channel, where they will be sent to their eventual destination.  
 
-The rhs is our first introduction to the `*` operator of Bloom collections, and the `pairs` method after it.  You can think of the `*` operator as "all-pairs": it produces a Bloom collection containing all pairs of mcast and nodelist items.  The `pairs` method iterates through these pairs, passing them through a code block via the block arguments `m` and `n`. Finally, for each such pair the block produces an item containing the `key` attribute of the nodelist item, and the `val` attribute of the mcast item.  This is structured as a proper \[address, value\] entry to be merged back into the mcast channel.  Putting this together, this statement *multicasts inbound payloads on the mcast channel to all nodes in the chat*.
+The rhs is our first introduction to the `*` operator of Bloom collections, and the `pairs` method after it.  You can think of the `*` operator as "all-pairs": it produces a Bloom collection containing all pairs of mcast and nodelist items.  The `pairs` method iterates through these pairs, passing them through a code block via the block arguments `m` and `n`. Finally, for each such pair the block produces an item containing the `key` attribute of the nodelist item, and the `val` attribute of the mcast item.  This is structured as a proper \[address, val\] entry to be merged back into the mcast channel.  Putting this together, this statement *multicasts inbound payloads on the mcast channel to all nodes in the chat*.
 
 The remaining lines of plain Ruby simply instantiate and run the ChatServer class (which includes the `Bud` module) using an ip and port given on the command line (or the default from ChatProtocol.rb).
 
 #### `*`'s and Clouds ####
 You can think of out use of the `*` operator in the rhs of the second statement in a few different ways:
 
-* If you're familiar with event-loop programming, this implements an *event handler* for messages on the mcast channel: whenever an mcast message arrives, this handler performs lookups in the nodelist table to form new messages.  (It is easy to add "filters" to these handlers.)  The resulting messages are dispatched via the mcast channel accordingly.  This is a very common pattern in Bloom programs: handling channel messages via lookups in a table.
+* If you're familiar with event-loop programming, this implements an *event handler* for messages on the mcast channel: whenever an mcast message arrives, this handler performs lookups in the nodelist table to form new messages.  (It is easy to add "filters" to these handlers as arguments to `pairs`.)  The resulting messages are dispatched via the mcast channel accordingly.  This is a very common pattern in Bloom programs: handling channel messages via lookups in a table.
 
-* If you're familiar with SQL databases, the rhs is essentially a query that is run at each timestep, performing a CROSS JOIN of the mcast and nodelist "tables", with the SELECT clause captured by the block. (It is easy to add WHERE clauses to these joins.)  The resulting "tuples" are "inserted" into the lhs asynchronously (and typical on remote nodes).  This is a general-purpose way to think about the * operator. But as you've already seen, many common use cases for Bloom's * operator don't "feel" like database queries, because one or more of the collections is a scratch that is "driving" the program.
+* If you're familiar with SQL databases, the rhs is essentially a query that is run at each timestep, performing a CROSS JOIN of the mcast and nodelist "tables", with the SELECT clause captured by the block. (It is easy to add WHERE clauses to these joins as arguments to `pairs`.)  The resulting "tuples" are "inserted" into the lhs asynchronously (and typical on remote nodes).  This is a general-purpose way to think about the * operator. But as you've already seen, many common use cases for Bloom's * operator don't "feel" like database queries, because one or more of the collections is a scratch that is "driving" the program.
 
 We expect that people doing distributed programming are probably familiar with both of these metaphors, and they're both useful.  It's fairly common to think about rules in the first form, although the second form is actually closer to the underlying semantics of the language (which come from a temporal logic called [Dedalus](http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.html)).
 
@@ -222,36 +222,34 @@ And here's the code:
       include Bud
       include ChatProtocol
 
-      def initialize(nick, server, opts)
+      def initialize(nick, server, opts={})
         @nick = nick
         @server = server
         super opts
       end
 
-      # send connection request to server on startup
       bootstrap do
         connect <~ [[@server, [ip_port, @nick]]]
       end
 
-      bloom :chatter do
-        # send mcast requests to server
+      bloom do
         mcast <~ stdio do |s|
           [@server, [ip_port, @nick, Time.new.strftime("%I:%M.%S"), s.line]]
         end
-        # pretty-print mcast msgs from server on terminal
-        stdio <~ mcast do |m|
-          [left_right_align(m.val[1].to_s + ": " \
-                            + (m.val[3].to_s || ''),
-                            "(" + m.val[2].to_s + ")")]
-        end
+
+        stdio <~ mcast { |m| [pretty_print(m.val)] }
       end
 
       # format chat messages with timestamp on the right of the screen
-      def left_right_align(x, y)
-        return x + " "*[66 - x.length,2].max + y
+      def pretty_print(val)
+        str = val[1].to_s + ": " + (val[3].to_s || '')
+        pad = "(" + val[2].to_s + ")"
+        return str + " "*[66 - str.length,2].max + pad
       end
     end
 
+
+
     if ARGV.length == 2
       server = ARGV[1]
     else
@@ -260,13 +258,13 @@ And here's the code:
 
     puts "Server address: #{server}"
     program = ChatClient.new(ARGV[0], server, :read_stdin => true)
-    program.run
+    program.run_fg
 
 The ChatClient class has a typical Ruby `initialize` method that sets up two local instance variables: one for this client's nickname, and another for the 'IP:port' address string for the server.  It then calls the initializer of the Bud superclass passing along a hash of options.
 
 The next block in the class is the first Bloom `bootstrap` block we've seen.  This is a set of Bloom statements that are evaluated only once, just before the first "regular" timestep of the system.  In this case, we bootstrap the client by sending a message to the server on the connect channel, containing the client's address (via the built-in Bud instance method `ip_port`) and chosen nickname.  
 
-After that comes a bloom block, with the name `:chatter`.  It contains two statements: one to take stdio input from the terminal and send it to the server via mcast, and another to receive mcasts and place them on stdio output.  The first statement has the built-in `stdio` scratch on the rhs: this includes any lines of terminal input that arrived since the last timestep.  For each line of terminal input, the `do...end` block formats an `mcast` message destined to the address in the instance variable `@server`, with an array as the payload.  The rhs of the second statement takes `mcast` messages that arrived since the last timestep.  For each message `m`, the `m.val` expression in the block returns the message payload; the call to the Ruby instance method `left_right_align` formats the message so it will look nice on-screen.  These formatted strings are placed (asynchronously, as before) into `stdio` on the left.
+After that comes a bloom block, with the name `:chatter`.  It contains two statements: one to take stdio input from the terminal and send it to the server via mcast, and another to receive mcasts and place them on stdio output.  The first statement has the built-in `stdio` scratch on the rhs: this includes any lines of terminal input that arrived since the last timestep.  For each line of terminal input, the `do...end` block formats an `mcast` message destined to the address in the instance variable `@server`, with an array as the payload.  The rhs of the second statement takes `mcast` messages that arrived since the last timestep.  For each message `m`, the `m.val` expression in the block returns the message payload; the call to the Ruby instance method `pretty_print` formats the message so it will look nice on-screen.  These formatted strings are placed (asynchronously, as before) into `stdio` on the left.
 
 The remaining lines are Ruby driver code to instantiate and run the ChatClient class (which includes the `Bud` module) using arguments from the command line.  Note the option `:read_stdin => true` to `ChatClient.new`: this causes the Bud runtime to capture stdin via the built-in `stdio` collection.
 

data/docs/intro.md

@@ -1,6 +1,6 @@
 # *Bud*: Ruby <~ Bloom #
 
-Bud is a prototype of the [*Bloom*](http://bloom-lang.org) language for distributed programming, embedded as a DSL in Ruby.  "Bud" stands for *Bloom under development*.  The current 0.0.1 release is the initial alpha, targeted at "friends and family" who would like to engage at an early stage in the language design.
+Bud is a prototype of the [*Bloom*](http://bloom-lang.org) language for distributed programming, embedded as a DSL in Ruby.  "Bud" stands for *Bloom under development*.  The current release is the initial alpha, targeted at "friends and family" who would like to engage at an early stage in the language design.
 
 ## Distributed Code in Bloom ##
 The goal of Bloom is to make distributed programming far easier than it has been with traditional languages.  The key features of Bloom are:
@@ -15,22 +15,22 @@ The goal of Bloom is to make distributed programming far easier than it has been
 
 ## Alpha Goals and Limitations ##
 
-We had three main goals in preparing this release.  The first was to flesh out the shape of the Bloom language: initial syntax and semantics, and the "feel" of embedding it as a DSL.  The second goal was to build tools for reasoning about Bloom programs: both automatic program analysis, and tools for surfacing that analysis to developers.
+We had three main goals in preparing this release.  The first was to flesh out the shape of the Bloom language: initial syntax and semantics, and the "feel" of embedding it as a DSL.  The second goal was to build tools for reasoning about Bloom programs: both automatic program analyses, and tools for surfacing those analyses to developers.
 
 The third goal was to start a feedback loop with developers interested in the potential of the ideas behind the language.  We are optimistic that the principles underlying Bloom can make distributed programming radically simpler.  But we realize that those ideas only matter if programmers can adopt them naturally.  We intend Bud to be the beginning of an iterative design partnership with developers who see value in betting early on these ideas, and shaping the design of the language.  
 
-In developing this alpha release, we explicitly set aside some issues that we intend to revisit in future.  The first limitation is performance: Bud 0.0.1 is not intended to excel in single-node performance in terms of either latency, throughput or scale.  We do expect major improvements on all these fronts in future releases: many of the known performance problems have known solutions that we've implemented in prior systems, and we intend to revisit them for our beta release.  The second main limitation involves integration issues embedding Bloom as a DSL in Ruby.  In the spectrum from flexibility to purity, we leaned decidedly toward flexibility.  The barriers between Ruby and Bloom code are very fluid in the alpha, and we do relatively little to prevent programmers from ad-hoc mixtures of the two.  Aggressive use of Ruby within Bloom statements is likely to do something *interesting*, but not necessarily predictable or desirable.  This is an area where we expect to learn more from experience, and make some more refined decisions for the beta release.
+In developing this alpha release, we explicitly set aside some issues that we intend to revisit in future.  The first limitation is performance: Bud alpha is not intended to excel in single-node performance in terms of either latency, throughput or scale.  We do expect major improvements on all these fronts in future releases: many of the known performance problems have known solutions that we've implemented in prior systems.  The second main limitation involves integration issues embedding Bloom as a DSL in Ruby.  In the spectrum from flexibility to purity, we leaned decidedly toward flexibility.  The barriers between Ruby and Bloom code are very fluid in the alpha, and we do relatively little to prevent programmers from ad-hoc mixtures of the two.  Aggressive use of Ruby within Bloom statements is likely to do something *interesting*, but not necessarily predictable or desirable.  This is an area where we expect to learn more from experience, and make some more refined decisions for the beta release.
 
 ### Friends and Family: Come On In ###
-Although our team has many years of development experience, Bud is still open-source academic software built on a decidedly personal scale.
+Although our team has many years of development experience, Bud is still open-source academic software built by a small group of researchers.
 
-This 0.0.1 alpha is targeted at "friends and family", and at developers who'd like to become same.  This is definitely the bleeding edge: we're in a rapid  cycle of learning about this new style of programming, and exposing what we learn in new iterations of the language.  If you'd like to jump on the wheel with us and play with Bud, we'd love your feedback--both success stories and constructive criticism.
+This alpha is targeted at "friends and family", and at developers who'd like to become same.  This is definitely the bleeding edge: we're in a rapid  cycle of learning about this new style of programming, and exposing what we learn in new iterations of the language.  If you'd like to jump on the wheel with us and play with Bud, we'd love your feedback--both success stories and constructive criticism.
 
 ## Getting Started ##
 We're shipping Bud with a [sandbox](http://github.com/bloom-lang/bud-sandbox) of libraries and example applications for distributed systems.  These illustrate the language and how it can be used, and also can serve as mixins for new code you might want to write.  You may be surprised at how short the provided Bud code is, but don't be fooled.
 
-To get you started with Bud, we've provided a [quick-start tutorial](getstarted.md), instructions for [deploying distributed Bud](deployer.md) programs on Amazon's EC2 cloud, and a number of other docs you can find linked from the [README](README.md).
+To get you started with Bud, we've provided a [quick-start tutorial](getstarted.md), instructions for [deploying distributed Bud](deploy.md) programs on Amazon's EC2 cloud, and a number of other docs you can find linked from the [README](README.md).
 
-We welcome both constructive criticism and (hopefully occasional) smoke-out-your-ears, hair-tearing shouts of frustration.  Please point your feedback cannon at the [Bloom mailing list](http://groups.google.com/group/bloom-lang) on Google Groups.
+We welcome both constructive criticism and (hopefully occasional) smoke-out-your-ears, hair-tearing shouts of frustration.  Please point your feedback cannon at the [Bloom mailing list](http://groups.google.com/group/bloom-lang).
 
 Happy Blooming!

data/docs/modules.md

@@ -1,19 +1,19 @@
-# Code Structuring and Reuse in BUD
+# Code Structuring and Reuse in Bud
 
 ## Language Support
 
 ### Ruby Mixins
 
-The basic unit of reuse in BUD is the mixin functionality provided by Ruby itself.  BUD code is structured into modules, each of which may have its own __state__ and__bootstrap__ block and any number of __bloom__ blocks (described below).  A module or class may mix in a BUD module via Ruby's _include_ statement.  _include_ causes the specified module's code to be expanded into the local scope.
+The basic unit of reuse in Bud is the mixin functionality provided by Ruby itself.  Bud code is structured into modules, each of which may have its own __state__ and __bootstrap__ block and any number of __bloom__ blocks (described below).  A module or class may mix in a Bud module via Ruby's _include_ statement.  _include_ causes the specified module's code to be expanded into the local scope.
 
 ### Bloom Blocks
 
-While the order and grouping of BUD rules have no semantic significance, rules can be grouped and tagged within a single module using __bloom__ blocks.  Bloom blocks serve two purposes:
+While the order and grouping of Bud rules have no semantic significance, rules can be grouped and tagged within a single module using __bloom__ blocks.  Bloom blocks serve two purposes:
  
  1. Improving readability by grouping related or dependent rules together.
  2. Supporting name-based overriding.
 
-(1) is self-explanatory.  (2) represents one of several extensibility mechanisms provided by BUD.  If a Module B includes a module A which contains a basket X, B may supply a bloom block X and in so doing replaces the set of rules defined by (A.)X with its own set.  For example:
+(1) is self-explanatory.  (2) represents one of several extensibility mechanisms provided by Bud.  If a Module B includes a module A which contains a basket X, B may supply a bloom block X and in so doing replaces the set of rules defined by (A.)X with its own set.  For example:
 
     require 'rubygems'
     require 'bud'
@@ -46,11 +46,11 @@ While the order and grouping of BUD rules have no semantic significance, rules c
 The program above will print "Hello, 1", because the module HelloTwo overrides the bloom block named __hi__.  If we give the bloom block in HelloTwo a distinct name, the program will print "Hello, 1" and "Hello, 2" (in no guaranteed order).
 
 
-### The BUD Module Import System
+### The Bud Module Import System
 
 For simple programs, composing modules via _include_ is often sufficient.  But the flat namespace provided by mixins can make it difficult or impossible to support certain types of reuse.  Consider a module Q that provides a queue-like functionality via an input interface _enqueue_ and an output interface _dequeue_, each with a single attribute (payload).  A later module may wish to employ two queues (say, to implement a scheduler).  But it cannot include Q twice!  It would be necessary to rewrite Q's interfaces so as to support multiple ``users.'' 
 
-In addition to _include_, BUD supports the _import_ keyword, which instantiates a BUD module under a namespace alias.  For example:
+In addition to _include_, Bud supports the _import_ keyword, which instantiates a Bud module under a namespace alias.  For example:
 
     module UserCode
       import Q => :q1
@@ -67,18 +67,18 @@ In addition to _include_, BUD supports the _import_ keyword, which instantiates
 
 ### Structuring 
 
-In summary, BUD extends the basic Ruby code structuring mechanisms (classes and modules) with bloom blocks, for finer-granularity grouping of rules 
+In summary, Bud extends the basic Ruby code structuring mechanisms (classes and modules) with bloom blocks, for finer-granularity grouping of rules 
 within modules, and the import system, for scoped inclusion.
 
 ### Composition
 
-Basic code composition can achieved using the Ruby mixin system.  If the flat namespace causes ambiguity (as above) or hinders readability, the import system provides the ability to scope code inclusions.
+Basic code composition can achieved using the Ruby mixin system.  If the flat namespace causes ambiguity (as above) or hinders readability, the Bud import system provides the ability to scope code inclusions.
 
 ### Extension and Overriding
 
-Extending the existing functionality of a BUD program can be achieved in a number of ways.  The simplest (but arguably least flexible) is via bloom block overriding, as described in the Hello example above.  
+Extending the existing functionality of a Bud program can be achieved in a number of ways.  The simplest (but arguably least flexible) is via bloom block overriding, as described in the Hello example above.  
 
-The import system can be used to implement finer-grained overriding, at the collection level.  Consider a module BlackBox that provides an input interface __iin__ and an output interface __iout__.  Suppose that we wish to "use" BlackBox, but need to provide additional functionality.  We may extend one or both of its interfaces by _import_'ing BlackBox, redeclaring the interfaces, and gluing them together.  For example, the module UsesBlackBox shown below interposes additional logic (indicated by ellipses) upstream of BlackBox's input interface, and provides ``extended'' BlackBox functionality.
+The import system can be used to implement finer-grained overriding, at the collection level.  Consider a module BlackBox that provides an input interface __iin__ and an output interface __iout__.  Suppose that we wish to "use" BlackBox, but need to provide additional functionality.  We may extend one or both of its interfaces by _import_-ing BlackBox, redeclaring the interfaces, and gluing them together.  For example, the module UsesBlackBox shown below interposes additional logic (indicated by ellipses) upstream of BlackBox's input interface, and provides ``extended'' BlackBox functionality.
 
     module UsesBlackBox
       import BlackBox => :bb

data/docs/operational.md

@@ -1,7 +1,7 @@
 # An Operational View Of Bloom #
-You may ask yourself: well, what does a Bloom program *mean*?  You may ask yourself: How do I read this Bloom code?  ([You may tell yourself, this is not my beautiful house.](http://www.youtube.com/watch?v=I1wg1DNHbNU)  But I digress.)
+You may ask yourself: well, what does a Bloom program *mean*?  You may ask yourself: How do I read this Bloom code?  ([You may tell yourself, this is not my beautiful house.](http://www.youtube.com/watch?v=I1wg1DNHbNU))
 
-There is a formal answer to these questions about Bloom, but there's also a more more approachable answer.  *Very* briefly, the formal answer is that Bloom's semantics are based in model theory, via a temporal logic language called *Dedalus* that is described in [a paper from Berkeley](http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.html). 
+There is a formal answer to these questions about Bloom, but there's also a more more approachable answer.  Briefly, the formal answer is that Bloom's semantics are based in finite model theory, via a temporal logic language called *Dedalus* that is described in [a paper from Berkeley](http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.html). 
 
 While that's nice for proving theorems (and writing [program analysis tools](visualizations.md)), many programmers don't find model-theoretic discussions of semantics terribly helpful or even interesting. It's usually easier to think about how the language *works* at some level, so you can reason about how to use it.
 
@@ -16,7 +16,7 @@ Each machine runs an evaluator that works in a loop, as depicted in this figure:
 
 Each iteration of this loop is a *timestep* for that node; each timestep is associated with a monotonically increasing timestamp (which is accessible via the `budtime` method in Bud). Timesteps and timestamps are not coordinated across nodes; any such coordination has to be programmed in the Bloom language itself.
 
-A Bloom timestep has 3 main phases:
+A Bloom timestep has 3 main phases (from left to right):
 
 1. *setup*: All scratch collections are set to empty.  Network messages and periodic timer events are received from the runtime and placed into their designated `channel` and `periodic` scratches, respectively, to be read in the rhs of statements.  Note that a batch of multiple messages/events may be received at once.
 2. *logic*: All Bloom statements for the program are evaluated.  In programs with recursion through instantaneous merges (`<=`), the statements are repeatedly evaluated until a *fixpoint* is reached: i.e. no new lhs items are derived from any rhs.
@@ -31,7 +31,7 @@ It is important to understand how the Bloom collection operators fit into these
 
 ## Atomicity: Timesteps and Deferred Operators ##
 
-The only instantaneous Bloom operator is a merge (`<=`), which can only introduce additional items into a collection--it can not delete or change existing items.  As a result, all state within a Bloom timestep is *immutable*: once an item is in a collection at timestep *T*, it stays in that collection throughout timestep *T*.
+The only instantaneous Bloom operator is a merge (`<=`), which can only introduce additional items into a collection--it can not delete or change existing items.  As a result, all state within a Bloom timestep is *immutable*: once an item is in a collection at timestep *T*, it stays in that collection throughout timestep *T*.  (And forever after, the fact that the item was in that collection at timestep *T* remains true.)
 
 To get atomic state change in Bloom, you exploit the combination of two language features: 
 
@@ -45,7 +45,7 @@ State "update" is achieved in Bloom via a pair of deferred statements, one posit
 
 This atomically replaces the entry for key 1 with the value "newval" at the start of the next timestep.
 
-Any reasoning about atomicity in Bloom programs is built on this simple foundation.  It's really all you need.  In the bud-sandbox we show how to build more powerful atomicity constructs using it, including things like enforcing [message ordering across timesteps](https://github.com/bloom-lang/bud-sandbox/tree/master/ordering), and protocols for [agreeing on ordering of distributed updates](https://github.com/bloom-lang/bud-sandbox/tree/master/paxos) across all nodes.
+Any reasoning about atomicity in Bloom programs is built on this simple foundation.  It's really all you need.  In the bud-sandbox we show how to build more powerful atomicity constructs using it, including things like enforcing [ordering of items across timesteps](https://github.com/bloom-lang/bud-sandbox/tree/master/ordering), and protocols for [agreeing on ordering of distributed updates](https://github.com/bloom-lang/bud-sandbox/tree/master/paxos) across all nodes.
 
 ## Recursion in Bloom ##
 Because Bloom is data-driven rather than call-stack-driven, recursion may feel a bit unfamiliar at first.
@@ -69,7 +69,7 @@ Have a look at the following classic "transitive closure" example, which compute
     
 The recursion in the second Bloom statement is easy to see: the lhs and rhs both contain the path collection, so path is defined in terms of itself.
 
-You can think of this being computed by reevaluating the bloom block over and over--within a single timestep--until no more new paths are found.  In each iteration, we find new paths that are one hop longer than the longest paths found previously.  When no new items are found in an iteration, we are at what's called a *fixpoint*.
+You can think of this being computed by reevaluating the bloom block over and over--within phase 2 of a single timestep--until no more new paths are found.  In each iteration, we find new paths that are one hop longer than the longest paths found previously.  When no new items are found in an iteration, we are at what's called a *fixpoint*, and we can move to phase 3.
 
 Hopefully that description is fairly easy to understand.  You can certainly construct more complicated examples of recursion--just as you can in a traditional language (e.g., simultaneous recursion.)  But understanding this example of simple recursion is probably sufficient for most needs.
 
@@ -85,7 +85,7 @@ The `argmax` expression in the rhs of this statement finds the items in path tha
   
 It's interesting to think about how to evaluate this statement.  Consider what happens after a single iteration of the path-finding logic listed above.  We will have 1-hop paths between some pairs.  But there will likely be multi-hop paths between those pairs that cost more.  So it would be premature after a single iteration to put anything out on stdio.  In fact, we can't be sure what should go out to stdio until we have hit a fixpoint with respect to the path collection.  That's because `argmax` is a logically *non-monotonic* operator: as we merge more items into its input collection, it may have to "retract" an output they would previously have produced. 
 
-The Bud runtime takes care of this problem for you under the covers, by breaking your statements in *strata* (layers) via a process called *stratification*.  The basic idea is simple.  The goal is to postpone evaluating non-monotonic operators until fixpoint is reached on their input collections.  Stratification basically breaks up the statements in a Bloom program into layers that are separated by non-monotonic operators, and evaluates the layers in order.  
+The Bud runtime takes care of this problem for you under the covers, by breaking your statements in *strata* (layers) via a process called *stratification*.  The basic idea is simple.  The goal is to postpone evaluating non-monotonic operators until fixpoint is reached on their input collections.  Stratification basically breaks up the statements in a Bloom program into layers that are separated by non-monotonic operators, and evaluates the layers in order.  (Note: the singular form of strata is *stratum*).
 
 For your reference, the basic non-monotonic Bloom operators include `group, reduce, argmin, argmax`.  Also, statements that embed Ruby collection methods in their blocks are often non-monotonic--e.g., methods like `all?, empty?, include?, none?` and `size`.
 

data/docs/ruby_hooks.md

@@ -1,7 +1,7 @@
 ## Ruby/Bloom interactions in Bud ##
-Bud embeds Bloom as a [DSL](http://en.wikipedia.org/wiki/Domain-specific_language) in Ruby.  On a given node, it is often useful to run a Ruby thread, and pass information to and from Bloom-land and Ruby-land.  If nothing else, this allows the Ruby process hosting the Bud evaluator to monitor its progress.
+Bud embeds Bloom as a [DSL](http://en.wikipedia.org/wiki/Domain-specific_language) in Ruby.  On a given node, it is often useful to run a Ruby thread, and pass information between one vanilla Ruby thread, and another one running Bloom code.
 
-As described in the [Getting Started](getstarted.md) document, we embed Bloom code into Ruby by including the `Bud` module in some Ruby class, and putting Bloom blocks into the class.  We then typically allocate a new instance of that class in Ruby, and invoke either its `run` method or `run_bg` method.  Since the Bud runtime typically runs indefinitely, the blocking `run` call essentially hands the thread over to Bud.  The `run_bg` call puts the Bud runtime into a second thread and returns to the caller.
+As described in the [Getting Started](getstarted.md) document, we embed Bloom code into Ruby by including the `Bud` module in some Ruby class, and putting Bloom blocks into the class.  We then typically allocate a new instance of that class in Ruby, and invoke either its `run_fg` method or `run_bg` method.  Since the Bud runtime typically runs indefinitely, the blocking `run_fg` call essentially hands the thread over to Bud.  The `run_bg` call puts the Bud runtime into a second thread and returns to the caller.
 
 To support the `run_bg` case further, the Bud runtime provides hooks for  Ruby threads to register code with the runtime for execution during Bloom timesteps.  These hooks always run at the end of a timestep, after all Bloom statements have been processed for that timestep.  There are two basic types of hooks:
 
@@ -12,7 +12,7 @@ To support the `run_bg` case further, the Bud runtime provides hooks for  Ruby t
 ## Bud and Ruby-driven Side Effects ##
 The Bloom language itself is a pure logic language based in Dedalus.  Like any logic language, it has no notion of "mutable state" or "side effects".  Each item that appears in a Bloom collection at timestep T will *forever* be recorded as having been in that collection at timestep T, at least in a formal sense. The temporal logic of Dedalus is a lot like a versioning system, where old versions of items are never removed.
 
-In the context of the existing Bud prototype, though, it easy to step outside the bright lines of pure Bloom using straight Ruby code and libraries.  Methods like `sync_do` and callbacks allow Ruby code to be run that can mess with Bloom collections in a way that Bloom doesn't model.  Similarly, Ruby blocks *within* the rhs of a Bloom statement (e.g. after a collection name or a `pairs` call) can produce visible side-effects in unpredictable ways.  In particular, be aware that side-effecting Ruby code within a Bloom block may be called an *arbitrary* number of times during a single Bloom timestep, as it works its way to fixpoint.  
+In the context of the existing Bud prototype, though, it easy to step outside the bright lines of pure Bloom using straight Ruby code and libraries.  Methods like `sync_do` and callbacks allow Ruby code to be run that can mess with Bloom collections in a way that Bloom doesn't model.  Similarly, Ruby blocks *within* the rhs of a Bloom statement (e.g. after a collection name or a `pairs` call) can produce visible side-effects in unpredictable ways.  In particular, be aware that any side-effect-producing Ruby code within a Bloom block may be called an *arbitrary* number of times during a single Bloom timestep, as Bud works its way to fixpoint.  
 
 If you must pollute your Bloom statements with side-effecting Ruby, please do it with *idempotent* side-effecting Ruby.  Thank you.
 

data/docs/visualizations.md

@@ -1,8 +1,8 @@
 # Visualizations
 
-BUD programs compile naturally to dataflows, and dataflows have a natural graphical representation.  Plotting a program as a graph can be useful to developers at various stages of program design, implementation and debugging.  BUD predicate dependency graphs (or PDGs) are described on [[PDGs]].
+Bud programs compile naturally to dataflows, and dataflows have a natural graphical representation.  Plotting a program as a graph can be useful to developers at various stages of program design, implementation and debugging.  Bud predicate dependency graphs (or PDGs) are described on [[PDGs]].
 
-BUD ships with two visualization utilities, __plotter__ and __visualizer__.  Both use _GraphViz_ to draw a directed graph representing the program state and logic.  __plotter__ provides a static analysis of the program, identifying sources and sinks of the dataflow, unconnected components, and points of order corresponding to logically nonmonotonic path edges. __visualizer__ is an offline debugging tool that analyses the trace of a (local) BUD execution and provides an interactive representation of runtime state over time.
+Bud ships with two visualization utilities, __plotter__ and __visualizer__.  Both use _GraphViz_ to draw a directed graph representing the program state and logic.  __plotter__ provides a static analysis of the program, identifying sources and sinks of the dataflow, unconnected components, and points of order corresponding to logically nonmonotonic path edges. __visualizer__ is an offline debugging tool that analyses the trace of a (local) Bud execution and provides an interactive representation of runtime state over time.
 
 ## The Plotter 
 
@@ -22,7 +22,7 @@ The __plotter__ is a visual static analysis tool that aids in design and early i
     USAGE:
     ruby budplot LIST_OF_FILES LIST_OF_MODULES
 
-As its usage message indicates, __plotter__ expects a list of ruby input files, followed by a list of BUD modules to mix in.
+As its usage message indicates, __plotter__ expects a list of ruby input files, followed by a list of Bud modules to mix in.
 
     $ ruby budplot kvs/kvs.rb ReplicatedKVS
     Warning: underspecified dataflow: ["my_id", true]
@@ -43,7 +43,7 @@ __ReplicatedKVS__ includes the __MulticastProtocol__ and __MembershipProtocol__
 
 [[https://github.com/bloom-lang/bud/blob/master/util/budvis]]
 
-To enable tracing, we need to set __:trace => true__ in the __BUD__ constructor, and optionally provide a __:tag__ to differentiate between traces by a human-readable name (rather than by object_id).  I modified the unit test `test/tc_kvs.rb` as follows:
+To enable tracing, we need to set __:trace => true__ in the __Bud__ constructor, and optionally provide a __:tag__ to differentiate between traces by a human-readable name (rather than by object_id).  I modified the unit test `test/tc_kvs.rb` as follows:
 
     - v = BestEffortReplicatedKVS.new(@opts.merge(:port => 12345))
     - v2 = BestEffortReplicatedKVS.new(@opts.merge(:port => 12346))

data/examples/bust/bustserver-example.rb

@@ -15,4 +15,4 @@ class BustExample # :nodoc: all
   end
 end
 
-BustExample.new.run_fg
+BustExample.new(:bust_port => 8080).run_fg

data/examples/deploy/tokenring.rb

@@ -30,7 +30,7 @@ module TokenRing
   bloom :pass_token do
     # Persist the token for as long as necessary
     token_persist <= token
-    token_persist <- join([token_persist, next_node]).map {|t,_| [t]}
+    token_persist <- join([token_persist, next_node]).map {|t,_| [t.loc]}
     # Pass on the token
     token <~ join([token_persist, next_node]).map {[next_node[[]].node]}
     stdio <~ token.map {["#{ip_port}: Got token!"]}

data/lib/bud.rb

@@ -17,6 +17,8 @@ require 'bud/storage/tokyocabinet'
 require 'bud/storage/zookeeper'
 require 'bud/viz'
 
+$em_stopped = Queue.new
+
 # We monkeypatch Module to add support for Bloom state and code declarations.
 class Module
   
@@ -165,7 +167,6 @@ module Bud
     @budtime = 0
     @inbound = []
     @done_bootstrap = false
-    @em_stopped = Queue.new
     @joinstate = {}  # joins are stateful, their state needs to be kept inside the Bud instance
 
     # Setup options (named arguments), along with default values
@@ -372,7 +373,7 @@ module Bud
     if stop_em
       schedule_shutdown(true)
       # Wait until EM has completely shutdown before we return.
-      @em_stopped.pop
+      $em_stopped.pop
     else
       schedule_and_wait do
         do_shutdown(false)
@@ -519,7 +520,7 @@ module Bud
         q << true
       end
       # Executed only after EventMachine::stop_event_loop is done
-      @em_stopped << true
+      $em_stopped << true
     end
     # Block waiting for EM's event loop to start up.
     q.pop

data/lib/bud/bust/bust.rb

@@ -10,6 +10,7 @@ HTTP_VERBS = ["GET", "POST"] #, "DELETE"]
 # a RESTful interface to Bloom code
 module Bust
   include Bud
+  attr_reader :bust_port
 
   # used this for inspiration:
   # http://blogs.msdn.com/b/abhinaba/archive/2005/10/14/474841.aspx
@@ -33,7 +34,7 @@ module Bust
       BustClass.new(bud, q)
     end
     # Wait for socket to be ready before we return from bootstrap.
-    q.pop
+    @bust_port = q.pop
   end
 
   class BustClass
@@ -100,9 +101,11 @@ module Bust
 
     def initialize(bud, q)
       # allow user-configurable port
-      server = TCPServer.new(bud.ip, (bud.options[:bust_port] or 8080))
+      server = TCPServer.new(bud.ip, (bud.options[:bust_port] or 0))
+      port = server.addr[1]
+      puts "Bust server listening on #{bud.ip}:#{port}"
       # We're now ready to accept connections.
-      q << true
+      q << port
 
       loop do
         session = server.accept

data/lib/bud/collections.rb

@@ -298,7 +298,7 @@ module Bud
     public
     def insert(o) # :nodoc: all
       # puts "insert: #{o.inspect} into #{tabname}"
-      do_insert(o, @delta)
+      do_insert(o, @storage)
     end
 
     # instantaneously place an individual item from rhs into collection on lhs

data/lib/bud/deploy/ec2deploy.rb

@@ -160,8 +160,8 @@ module EC2Deploy
                   raise "Couldn't open a PTY on #{t.node}" if !success
                 end
                 channel.exec("sudo gem update --no-ri --no-rdoc bud")
-                channel.wait
               end
+              channel.wait
               # Run the ruby_command
               session.exec!('nohup ' + ruby_command[[]].cmd + ' ' + t.localip +
                             ' ' + t.node + ' >metarecv.out 2>metarecv.err </dev/null &')

data/lib/bud/deploy/localdeploy.rb

@@ -7,17 +7,27 @@ require 'bud/deploy/deployer'
 module LocalDeploy
   include Deployer
 
-  trap("CLD") {
-    pid = Process.wait
-    puts "Child pid #{pid}: terminated"
-  }
+  def stop_bg
+    super
+    for p in @pids
+      Process.kill("INT", p)
+    end
+    Process.waitall
+    trap("CLD", "DEFAULT")
+  end
 
   deploystrap do
+    trap("CLD") {
+      pid = Process.wait
+      puts "Child pid #{pid}: terminated"
+    }
+
     read, write = IO.pipe
     if node_count[[]]
       print "Forking local processes"
+      @pids = []
       (0..node_count[[]].num-1).map do |i|
-        Process.fork do
+        @pids << Process.fork do
           # Don't want to inherit our parent's random stuff.
           srand
           foo = self.class.new
@@ -34,6 +44,8 @@ module LocalDeploy
       (0..node_count[[]].num-1).map do |i|
         node << [i, "localhost:" + read.readline.rstrip]
       end
+      read.close
+      write.close
       puts "done"
     end
   end

data/lib/bud/rewrite.rb

@@ -1,7 +1,7 @@
 require 'rubygems'
 require 'ruby2ruby'
 
-class RuleRewriter < Ruby2Ruby #:nodoc: all
+class RuleRewriter < Ruby2Ruby # :nodoc: all 
   attr_accessor :rule_indx, :rules, :depends
 
   def initialize(seed, bud_instance)

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: bud
 version: !ruby/object:Gem::Version 
-  hash: 27
+  hash: 25
   prerelease: 
   segments: 
   - 0
   - 0
-  - 2
-  version: 0.0.2
+  - 3
+  version: 0.0.3
 platform: ruby
 authors: 
 - Peter Alvaro
@@ -18,7 +18,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2011-04-06 00:00:00 -07:00
+date: 2011-04-07 00:00:00 -07:00
 default_executable: rebl
 dependencies: 
 - !ruby/object:Gem::Dependency