bud 0.0.3 → 0.0.4

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: bud
 version: !ruby/object:Gem::Version 
-  hash: 25
+  hash: 23
   prerelease: 
   segments: 
   - 0
   - 0
-  - 3
-  version: 0.0.3
+  - 4
+  version: 0.0.4
 platform: ruby
 authors: 
 - Peter Alvaro
@@ -18,7 +18,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2011-04-07 00:00:00 -07:00
+date: 2011-06-01 00:00:00 -07:00
 default_executable: rebl
 dependencies: 
 - !ruby/object:Gem::Dependency 
@@ -64,7 +64,7 @@ dependencies:
   type: :runtime
   version_requirements: *id003
 - !ruby/object:Gem::Dependency 
-  name: i18n
+  name: getopt
   prerelease: false
   requirement: &id004 !ruby/object:Gem::Requirement 
     none: false
@@ -78,7 +78,7 @@ dependencies:
   type: :runtime
   version_requirements: *id004
 - !ruby/object:Gem::Dependency 
-  name: msgpack
+  name: i18n
   prerelease: false
   requirement: &id005 !ruby/object:Gem::Requirement 
     none: false
@@ -92,7 +92,7 @@ dependencies:
   type: :runtime
   version_requirements: *id005
 - !ruby/object:Gem::Dependency 
-  name: nestful
+  name: json
   prerelease: false
   requirement: &id006 !ruby/object:Gem::Requirement 
     none: false
@@ -106,7 +106,7 @@ dependencies:
   type: :runtime
   version_requirements: *id006
 - !ruby/object:Gem::Dependency 
-  name: ParseTree
+  name: msgpack
   prerelease: false
   requirement: &id007 !ruby/object:Gem::Requirement 
     none: false
@@ -120,7 +120,7 @@ dependencies:
   type: :runtime
   version_requirements: *id007
 - !ruby/object:Gem::Dependency 
-  name: ruby-graphviz
+  name: nestful
   prerelease: false
   requirement: &id008 !ruby/object:Gem::Requirement 
     none: false
@@ -134,7 +134,7 @@ dependencies:
   type: :runtime
   version_requirements: *id008
 - !ruby/object:Gem::Dependency 
-  name: ruby2ruby
+  name: ParseTree
   prerelease: false
   requirement: &id009 !ruby/object:Gem::Requirement 
     none: false
@@ -148,7 +148,7 @@ dependencies:
   type: :runtime
   version_requirements: *id009
 - !ruby/object:Gem::Dependency 
-  name: sexp_path
+  name: ruby-graphviz
   prerelease: false
   requirement: &id010 !ruby/object:Gem::Requirement 
     none: false
@@ -162,7 +162,7 @@ dependencies:
   type: :runtime
   version_requirements: *id010
 - !ruby/object:Gem::Dependency 
-  name: superators
+  name: ruby2ruby
   prerelease: false
   requirement: &id011 !ruby/object:Gem::Requirement 
     none: false
@@ -176,7 +176,7 @@ dependencies:
   type: :runtime
   version_requirements: *id011
 - !ruby/object:Gem::Dependency 
-  name: syntax
+  name: sexp_path
   prerelease: false
   requirement: &id012 !ruby/object:Gem::Requirement 
     none: false
@@ -190,7 +190,7 @@ dependencies:
   type: :runtime
   version_requirements: *id012
 - !ruby/object:Gem::Dependency 
-  name: tokyocabinet
+  name: superators
   prerelease: false
   requirement: &id013 !ruby/object:Gem::Requirement 
     none: false
@@ -204,7 +204,7 @@ dependencies:
   type: :runtime
   version_requirements: *id013
 - !ruby/object:Gem::Dependency 
-  name: uuid
+  name: syntax
   prerelease: false
   requirement: &id014 !ruby/object:Gem::Requirement 
     none: false
@@ -217,6 +217,20 @@ dependencies:
         version: "0"
   type: :runtime
   version_requirements: *id014
+- !ruby/object:Gem::Dependency 
+  name: uuid
+  prerelease: false
+  requirement: &id015 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - ">="
+      - !ruby/object:Gem::Version 
+        hash: 3
+        segments: 
+        - 0
+        version: "0"
+  type: :runtime
+  version_requirements: *id015
 description: A prototype of the Bloom distributed programming language, as a Ruby DSL.
 email: 
 - bloomdevs@gmail.com
@@ -224,6 +238,7 @@ executables:
 - rebl
 - budplot
 - budvis
+- budtimelines
 extensions: []
 
 extra_rdoc_files: []
@@ -239,31 +254,36 @@ files:
 - lib/bud/deploy/countatomicdelivery.rb
 - lib/bud/deploy/deployer.rb
 - lib/bud/deploy/ec2deploy.rb
-- lib/bud/deploy/localdeploy.rb
+- lib/bud/deploy/forkdeploy.rb
+- lib/bud/deploy/threaddeploy.rb
 - lib/bud/errors.rb
 - lib/bud/graphs.rb
 - lib/bud/joins.rb
+- lib/bud/monkeypatch.rb
 - lib/bud/rebl.rb
 - lib/bud/rewrite.rb
 - lib/bud/rtrace.rb
 - lib/bud/server.rb
 - lib/bud/state.rb
+- lib/bud/storage/dbm.rb
 - lib/bud/storage/tokyocabinet.rb
 - lib/bud/storage/zookeeper.rb
 - lib/bud/stratify.rb
 - lib/bud/viz.rb
+- lib/bud/viz_util.rb
 - lib/bud.rb
+- lib/bud.rb.orig
 - bin/budplot
+- bin/budtimelines
 - bin/budvis
 - bin/rebl
 - docs/bfs.md
-- docs/bfs.raw
 - docs/bfs_arch.png
 - docs/bloom-loop.png
 - docs/bust.md
+- docs/c.html
 - docs/cheat.md
 - docs/deploy.md
-- docs/diffs
 - docs/getstarted.md
 - docs/intro.md
 - docs/modules.md
@@ -273,8 +293,6 @@ files:
 - docs/ruby_hooks.md
 - docs/visualizations.md
 - examples/basics/hello.rb
-- examples/basics/out
-- examples/basics/out.new
 - examples/basics/paths.rb
 - examples/bust/bustclient-example.rb
 - examples/bust/bustinspector.html
@@ -284,8 +302,11 @@ files:
 - examples/chat/chat_protocol.rb
 - examples/chat/chat_server.rb
 - examples/chat/README.md
+- examples/deploy/deploy_ip_port
+- examples/deploy/keys.rb
 - examples/deploy/tokenring-ec2.rb
-- examples/deploy/tokenring-local.rb
+- examples/deploy/tokenring-fork.rb
+- examples/deploy/tokenring-thread.rb
 - examples/deploy/tokenring.rb
 - examples/README
 - README
@@ -302,7 +323,7 @@ require_paths:
 required_ruby_version: !ruby/object:Gem::Requirement 
   none: false
   requirements: 
-  - - ">="
+  - - ~>
     - !ruby/object:Gem::Version 
       hash: 57
       segments: 

data/docs/bfs.raw

@@ -1,251 +0,0 @@
-# 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,
-``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)
- * [nonce generation](https://github.com/bloom-lang/bud-sandbox/blob/master/ordering/nonce.rb)
- * a [heartbeat protocol](https://github.com/bloom-lang/bud-sandbox/blob/master/heartbeat/heartbeat.rb)
-
-## High-level architecture
-
-![BFS Architecture](bfs_arch.png?raw=true)
-
-BFS implements a chunked, distributed file system (mostly) in the Bloom
-language.  BFS is architecturally based on [BOOM-FS](http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf), which is itself based on
-the Google File System (GFS).  As in GFS, a single master node manages
-file system metadata, while data blocks are replicated and stored on a large
-number of storage nodes.  Writing or reading data involves a multi-step
-protocol in which clients interact with the master, retrieving metadata and
-possibly changing state, then interact with storage nodes to read or write
-chunks.  Background jobs running on the master will contact storage nodes to
-orchestrate chunk migrations, during which storage nodes communicate with
-other storage nodes.  As in BOOM-FS, the communication protocols and the data
-channel used for bulk data transfer between clients and datanodes and between
-datanodes is written outside Bloom (in Ruby).
-
-## [Basic File System](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/fs_master.rb)
-
-Before we worry about any of the details of distribution, we need to implement the basic file system metadata operations: _create_, _remove_, _mkdir_ and _ls_.
-There are many choices for how to implement these operations, and it makes sense to keep them separate from the (largely orthogonal) distributed file system logic.
-That way, it will be possible later to choose a different implementation of the metadata operations without impacting the rest of the system.
-Another benefit of modularizing the metadata logic is that it can be independently tested and debugged.  We want to get the core of the file system
-working correctly before we even send a whisper over the network, let alone add any complex features.
-
-### Protocol
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|12-20
-
-We create an input interface for each of the operations, and a single output interface for the return for any operation: given a request id, __status__ is a boolean
-indicating whether the request succeeded, and __data__ may contain return values (e.g., _fsls_ should return an array containing the array contents).
-
-### Implementation
-
-We already have a library that provides an updateable flat namespace: the key-value store.  We can easily implement the tree structure of a file system over a key-value store
-in the following way:
-
- 1. keys are paths
- 2. directories have arrays containing child entries (base names)
- 3. files values are their contents
-
-<!--- (**JMH**: I find it a bit confusing how you toggle from the discussion above to this naive file-storage design here.  Can you warn us a bit more clearly that this is a starting point focused on metadata, with (3) being a strawman for data storage that is intended to be overriden later?)
---->
-Note that (3) is a strawman: it will cease to apply when we implement chunked storage later.  It is tempting, however, to support (3) so that the resulting program is a working
-standalone file system.
-
-We begin our implementation of a KVS-backed metadata system in the following way:
-
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|33-36
-
-If we wanted to replicate the master node's metadata we could consider mixing in a replicated KVS implementation instead of __BasicKVS__ -- but more on that later.
-
-### Directory Listing 
-
-The directory listing operation is implemented by a simple block of Bloom statements:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|51-57
-
-If we get a __fsls__ request, probe the key-value store for the requested by projecting _reqid_, _path_ from the __fsls__ tuple into __kvget__.  If the given path
-is a key, __kvget_response__ will contain a tuple with the same _reqid_, and the join on the second line will succeed.  In this case, we insert the value
-associated with that key into __fsret__.  Otherwise, the third rule will fire, inserting a failure tuple into __fsret__.
-
-
-### Mutation
-
-The logic for file and directory creation and deletion follow a similar logic with regard to the parent directory:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|61-71
-
-Unlike a directory listing, however, these operations change the state of the file system.  In general, any state change will involve 
-carrying out two mutating operations to the key-value store atomically:
-
- 1. update the value (child array) associated with the parent directory entry
- 2. update the key-value pair associated with the object in question (a file or directory being created or destroyed).
-
-The following Bloom code carries this out:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|73-73
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|80-108
-
-
-<!--- (**JMH**: This next sounds awkward.  You *do* take care: by using <= and understanding the atomicity of timesteps in Bloom.  I think what you mean to say is that Bloom's atomic timestep model makes this easy compared to ... something.)
-Note that we need not take any particular care to ensure that the two inserts into __kvput__ occur together atomically.  Because both statements use the synchronous 
--->
-Note that because both inserts into the __kvput__ collection use the synchronous operator (`<=`), we know that they will occur together in the same fixpoint computation or not at all.
-Therefore we need not be concerned with explicitly sequencing the operations (e.g., ensuring that the directory entries is created _after_ the file entry) to deal with concurrency:
-there can be no visible state of the database in which only one of the operations has succeeded.
-
-If the request is a deletion, we need some additional logic to enforce the constraint that only an empty directory may be removed:
-
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|74-78
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|110-115
-
-
-Recall that when we created KVSFS we mixed in __TimestepNonce__, one of the nonce libraries.  While we were able to use the _reqid_ field from the input operation as a unique identifier
-for one of our KVS operations, we need a fresh, unique request id for the second KVS operation in the atomic pair described above.  By joining __nonce__, we get
-an identifier that is unique to this timestep.
-
-
-## [File Chunking](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/chunking.rb)
-
-Now that we have a module providing a basic file system, we can extend it to support chunked storage of file contents.  The metadata master will contain, in addition to the KVS
-structure for directory information, a relation mapping a set of chunk identifiers to each file
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|26-26
-
-and relations associating a chunk with a set of datanodes that host a replica of the chunk.  
-
-==https://github.com/bloom-lang/bud-sandbox/raw/5c7734912e900c28087e39b3424a1e0191e13704/bfs/hb_master.rb|12-12
-
-(**JMH**: ambiguous reference ahead "these latter")
-The latter (defined in __HBMaster__) is soft-state, kept up to data by heartbeat messages from datanodes (described in the next section).
-
-To support chunked storage, we add a few metadata operations to those already defined by FSProtocol:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|6-16
-
- * __fschunklist__ returns the set of chunks belonging to a given file.  
- * __fschunklocations__ returns the set of datanodes in possession of a given chunk.
- * __fsaddchunk__ returns a new chunkid for appending to an existing file, guaranteed to be higher than any existing chunkids for that file, and a list of candidate datanodes that can store a replica of the new chunk.
-
-We continue to use __fsret__ for return values.
-
-### Lookups
-
-Lines 34-44 are a similar pattern to what we saw in the basic FS: whenever we get a __fschunklist__ or __fsaddchunk__ request, we must first ensure that the given file
-exists, and error out if not.  If it does, and the operation was __fschunklist__, we join the metadata relation __chunk__ and return the set of chunks owned
-by the given (existent) file:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|47-49
-
-### Add chunk
-
-If it was a __fsaddchunk__ request,  we need to generate a unique id for a new chunk and return a list of target datanodes.  We reuse __TimestepNonce__ to do the former, and join a relation
-called __available__ that is exported by __HBMaster__ (described in the next section) for the latter:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|69-76
-
-Finally, it was a __fschunklocations__ request, we have another possible error scenario, because the nodes associated with chunks are a part of our soft state.  Even if the file
-exists, it may not be the case that we have fresh information in our cache about what datanodes own a replica of the given chunk:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|54-58
-
-Otherwise, __chunk_cache__ has information about the given chunk, which we may return to the client:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|61-64
-
-
-## Datanodes and Heartbeats
-
-### [Datanode](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/datanode.rb)
-
-A datanode runs both Bud code (to support the heartbeat and control protocols) and pure Ruby (to support the data transfer protocol).  A datanode's main job is keeping the master 
-aware of it existence and its state, and participating when necessary in data pipelines to read or write chunk data to and from its local storage.
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|11-15
-
-By mixing in HeartbeatAgent, the datanode includes the machinery necessary to regularly send status messages to the master.  __HeartbeatAgent__ provides an input interface
-called __payload__ that allows an agent to optionally include additional information in heartbeat messages: in our case, we wish to include state deltas which ensure that
-the master has an accurate view of the set of chunks owned by the datanode.  
-
-When a datanode is constructed, it takes a port at which the embedded data protocol server will listen, and starts the server in the background:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|61-62
-
-At regular intervals, a datanode polls its local chunk directory (which is independently written to by the data protocol):
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|26-31
-
-We update the payload that we send to the master if our recent poll found files that we don't believe the master knows about:
-
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|33-40
-
-Our view of what the master ``knows'' about reflects our local cache of acknowledgement messages from the master.  This logic is defined in __HBMaster__.
-
-### [Heartbeat master logic](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/hb_master.rb)
-
-On the master side of heartbeats, we always send an ack when we get a heartbeat, so that the datanode doesn't need to keep resending its
-payload of local chunks:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/5c7734912e900c28087e39b3424a1e0191e13704/bfs/hb_master.rb|30-32
-
-At the same time, we use the Ruby _flatmap_ method to flatten the array of chunks in the heartbeat payload into a set of tuples, which we
-associate with the heartbeating datanode and the time of receipt in __chunk_cache__:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/5c7734912e900c28087e39b3424a1e0191e13704/bfs/hb_master.rb|22-28
-
-We periodically garbage-collect this cached, removing entries for datanodes from whom we have not received a heartbeat in a configurable amount of time.
-__last_heartbeat__ is an output interface provided by the __HeartbeatAgent__ module, and contains the most recent, non-stale heartbeat contents:
-
-==https://github.com/bloom-lang/bud-sandbox/raw/5c7734912e900c28087e39b3424a1e0191e13704/bfs/hb_master.rb|34-36
-
-
-## [BFS Client](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/bfs_client.rb)
-
-One of the most complicated parts of the basic GFS design is the client component.  To minimize load on the centralized master, we take it off the critical 
-path of file transfers.  The client therefore needs to pick up this work.
-
-We won't spend too much time on the details of the client code, as it is nearly all _plain old Ruby_.  The basic idea is:
-
- 1. Pure metadata operations 
-     * _mkdir_, _create_, _ls_, _rm_
-     * Send the request to the master and inform the caller of the status.
-     * If _ls_, return the directory listing to the caller.
- 2. Append
-     * Send a __fsaddchunk__ request to the master, which should return a new chunkid and a list of datanodes.
-     * Read a chunk worth of data from the input stream.  
-     * Connect to the first datanode in the list.  Send a header containing the chunkid and the remaining datanodes.
-     * Stream the file contents.  The target datanode will then ``play client'' and continue the pipeline to the next datanode, and so on.
- 2. Read
-     * Send a __getchunks__ request to the master for the given file.  It should return the list of chunks owned by the file.
-     * For each chunk,
-         * Send a __fschunklocations__ request to the master, which should return a list of datanodes in possession of the chunk (returning a list allows the client to perform retries without more communication with the master, should some of the datanodes fail).
-         * Connect to a datanode from the list and stream the chunk to a local buffer.
-     * As chunks become available, stream them to the caller.
-
-
-## [Data transfer protocol](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/data_protocol.rb)
-
-The data transfer protocol comprises a set of support functions for the bulk data transfer protocol whose use is described in the previous section.
-Because it is _plain old Ruby_ it is not as interesting as the other modules. It provides:
-
-  * The TCP server code that runs at each datanode, which parses headers and writes stream data to the local FS (these files are later detected by the directory poll).
-  * Client API calls to connect to datanodes and stream data.  Datanodes also use this protocol to pipeline chunks to downstream datanodes.
-  * Master API code invoked by a background process to replicate chunks from datanodes to other datanodes, when the replication factor for a chunk is too low.
-
-## [Master background process](https://github.com/bloom-lang/bud-sandbox/blob/master/bfs/background.rb)
-
-So far, we have implemented the BFS master as a strictly reactive system: when clients make requests, it queries and possibly updates local state.
-To maintain the durability requirement that `REP_FACTOR` copies of every chunk are stored on distinct nodes, the master must be an active system
-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.  
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/background.rb|24-27
-
-After defining some helper aggregates (__chunk_cnts_chunk__ or replica count by chunk, and __chunk_cnt_host__ or datanode fill factor), 
-
-==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/background.rb|29-36

data/docs/diffs

@@ -1,181 +0,0 @@
-24c24
-< channel used for communication (**JMH**: "bulk data transfer"?) between clients and datanodes and between
----
-> channel used for communication between clients and datanodes and between
-35,43c35
-<     module FSProtocol
-<       state do
-<         interface input, :fsls, [:reqid, :path]
-<         interface input, :fscreate, [] => [:reqid, :name, :path, :data]
-<         interface input, :fsmkdir, [] => [:reqid, :name, :path]
-<         interface input, :fsrm, [] => [:reqid, :name, :path]
-<         interface output, :fsret, [:reqid, :status, :data]
-<       end
-<     end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|12-20
-57,58d48
-< (**JMH**: I find it a bit confusing how you toggle from the discussion above to this naive file-storage design here.  Can you warn us a bit more clearly that this is a starting point focused on metadata, with a strawman for data storage to be overriden later?)
-< 
-62,65c52
-<     module KVSFS
-<       include FSProtocol
-<       include BasicKVS
-<       include TimestepNonce
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|33-36
-67c54
-< If we wanted to replicate the metadata master (**JMH**: "the master node's metadata"?), we could consider mixing in a replicated KVS implementation instead of __BasicKVS__ -- but more on that later.
----
-> If we wanted to replicate the metadata master, we could consider mixing in a replicated KVS implementation instead of __BasicKVS__ -- but more on that later.
-71c58
-< The directory listing operation is implemented by a simple block of Bloom statements:
----
-> The directory listing operation is very simple:
-73,81c60
-<       bloom :elles do
-<         kvget <= fsls.map{ |l| [l.reqid, l.path] }
-<         fsret <= join([kvget_response, fsls], [kvget_response.reqid, fsls.reqid]).map{ |r, i| [r.reqid, true, r.value] }
-<         fsret <= fsls.map do |l|
-<           unless kvget_response.map{ |r| r.reqid}.include? l.reqid
-<             [l.reqid, false, nil]
-<           end
-<         end
-<       end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|51-59
-96d74
-< (**JMH**: Transition: "The following Bloom code carries this out for ...")
-98,134c76
-<         dir_exists = join [check_parent_exists, kvget_response, nonce], [check_parent_exists.reqid, kvget_response.reqid]
-<     
-<         check_is_empty <= join([fsrm, nonce]).map{|m, n| [n.ident, m.reqid, terminate_with_slash(m.path) + m.name] }
-<         kvget <= check_is_empty.map{|c| [c.reqid, c.name] }
-<         can_remove <= join([kvget_response, check_is_empty], [kvget_response.reqid, check_is_empty.reqid]).map do |r, c|
-<           [c.reqid, c.orig_reqid, c.name] if r.value.length == 0
-<         end
-<     
-<         fsret <= dir_exists.map do |c, r, n|
-<           if c.mtype == :rm
-<             unless can_remove.map{|can| can.orig_reqid}.include? c.reqid
-<               [c.reqid, false, "directory #{} not empty"]
-<             end
-<           end
-<         end
-<     
-<         # update dir entry
-<         # note that it is unnecessary to ensure that a file is created before its corresponding
-<         # directory entry, as both inserts into :kvput below will co-occur in the same timestep.
-<         kvput <= dir_exists.map do |c, r, n|
-<           if c.mtype == :rm
-<             if can_remove.map{|can| can.orig_reqid}.include? c.reqid
-<               [ip_port, c.path, n.ident, r.value.clone.reject{|item| item == c.name}]
-<             end
-<           else
-<             [ip_port, c.path, n.ident, r.value.clone.push(c.name)]
-<           end
-<         end
-<     
-<         kvput <= dir_exists.map do |c, r, n|
-<           case c.mtype
-<             when :mkdir
-<               [ip_port, terminate_with_slash(c.path) + c.name, c.reqid, []]
-<             when :create
-<               [ip_port, terminate_with_slash(c.path) + c.name, c.reqid, "LEAF"]
-<           end
-<         end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/fs_master.rb|74-110
-136d77
-< (**JMH**: This next sounds awkward.  You *do* take care: by using <= and understanding the atomicity of timesteps in Bloom.  I think what you mean to say is that Bloom's atomic timestep model makes this easy compared to ... something.)
-150c91
-<         table :chunk, [:chunkid, :file, :siz]
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|26-26
-154c95
-<         table :chunk_cache, [:node, :chunkid, :time]
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/5c7734912e900c28087e39b3424a1e0191e13704/bfs/hb_master.rb|12-12
-156d96
-< (**JMH**: ambiguous reference ahead "these latter")
-161,171c101
-<     module ChunkedFSProtocol
-<       include FSProtocol
-<     
-<       state do
-<         interface :input, :fschunklist, [:reqid, :file]
-<         interface :input, :fschunklocations, [:reqid, :chunkid]
-<         interface :input, :fsaddchunk, [:reqid, :file]
-<         # note that no output interface is defined.
-<         # we use :fsret (defined in FSProtocol) for output.
-<       end
-<     end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|6-16
-185,187c115
-<         chunk_buffer <= join([fschunklist, kvget_response, chunk], [fschunklist.reqid, kvget_response.reqid], [fschunklist.file, chunk.file]).map{ |l, r, c| [l.reqid, c.chunkid] }
-<         chunk_buffer2 <= chunk_buffer.group([chunk_buffer.reqid], accum(chunk_buffer.chunkid))
-<         fsret <= chunk_buffer2.map{ |c| [c.reqid, true, c.chunklist] }
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|47-49
-191d118
-< (**JMH**: Ambiguous ref "If it")
-195,202c122
-<         minted_chunk = join([kvget_response, fsaddchunk, available, nonce], [kvget_response.reqid, fsaddchunk.reqid])
-<         chunk <= minted_chunk.map{ |r, a, v, n| [n.ident, a.file, 0] }
-<         fsret <= minted_chunk.map{ |r, a, v, n| [r.reqid, true, [n.ident, v.pref_list.slice(0, (REP_FACTOR + 2))]] }
-<         fsret <= join([kvget_response, fsaddchunk], [kvget_response.reqid, fsaddchunk.reqid]).map do |r, a|
-<           if available.empty? or available.first.pref_list.length < REP_FACTOR
-<             [r.reqid, false, "datanode set cannot satisfy REP_FACTOR = #{REP_FACTOR} with [#{available.first.nil? ? "NIL" : available.first.pref_list.inspect}]"]
-<           end
-<         end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|69-76
-204d123
-< (**JMH**: Ambiguous ref "If it")
-208,212c127
-<         fsret <= fschunklocations.map do |l|
-<           unless chunk_cache.map{|c| c.chunkid}.include? l.chunkid
-<             [l.reqid, false, "no datanodes found for #{l.chunkid} in cc, now #{chunk_cache.length}"]
-<           end
-<         end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|54-58
-216,219c131
-<         chunkjoin = join [fschunklocations, chunk_cache], [fschunklocations.chunkid, chunk_cache.chunkid]
-<         host_buffer <= chunkjoin.map{|l, c| [l.reqid, c.node] }
-<         host_buffer2 <= host_buffer.group([host_buffer.reqid], accum(host_buffer.host))
-<         fsret <= host_buffer2.map{|c| [c.reqid, true, c.hostlist] }
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/chunking.rb|61-64
-229,233c141
-<     module BFSDatanode
-<       include HeartbeatAgent
-<       include StaticMembership
-<       include TimestepNonce
-<       include BFSHBProtocol
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|9-13
-241c149
-<         @dp_server = DataProtocolServer.new(dataport)
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|53-53
-245,250c153
-<         dir_contents <= hb_timer.flat_map do |t|
-<           dir = Dir.new("#{DATADIR}/#{@data_port}")
-<           files = dir.to_a.map{|d| d.to_i unless d =~ /^\./}.uniq!
-<           dir.close
-<           files.map {|f| [f, Time.parse(t.val).to_f]}
-<         end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|24-29
-255,259c158
-<         to_payload <= join([dir_contents, nonce]).map do |c, n|
-<           unless server_knows.map{|s| s.file}.include? c.file
-<             [n.ident, c.file, c.time]
-<           end
-<         end
----
-> ==https://github.com/bloom-lang/bud-sandbox/raw/master/bfs/datanode.rb|31-35
-275d173
-< ### I am autogenerated.  Please do not edit me.