flok 0.0.102 → 0.0.103

data/docs/kernel_handbook/find_view.md

@@ -0,0 +1,34 @@
+#find_view
+`find_view(bp, spider_payload)` is a way to grab a set of sub-views of a **controller** and return a listing of base-pointers to the **views**. Originally
+designed to allow selection of sub-views during transition interceptors (hooks). This would usually upset the abstraction barrier between controllers, which
+are not supposed to know about their children, but for practical and performance reasons, we have decided to go with this style of implementation.
+
+A spider payload is a specially crafted cascading hash (usually created statically by macros) that represents a multi-branch view-hierarchy *regular* expression
+that is able to capture views on it's way through traversal.  It supports common operations of regular expressions such as *any* (`.`) and *one or more* (`+`) operator.
+Thus, the spider payload is also able to select groups of views which is useful if you are doing a pushed view stack and need to know all except the top two views.
+
+The following expressions are supported:
+
+  * `.+` - This means *at least one* view. It returns a group.
+  * `.` - This means *exactly one view*. It returns a single view.
+  * `my_view` - This is simply a named view.
+
+Additionally, expressions may contain a *named* capture by adding a `:$NAME` to the expression:
+  
+  * `.+:my_group`
+  * `.:my_view`
+  * `my_view:my_view`
+
+An expression is then a selection tree:
+
+```ruby
+.
+  my_view
+    +
+      my_other_sub_view:content
+  my_other_view
+```
+
+> It is important to note that a selection will fail unless both all views in the selector are satisfied and that all views are satisfied have matching super-trees. In the above example, if there were two `my_view` descendents of our current controller we are selecting off, then `my_view` could not match half the selector on one descedent and then the other half on another descendent.
+> 
+> 

data/docs/kernel_handbook/hooks.md

@@ -1,4 +1,15 @@
 # Hooks in the kernel
 
 ## How user-generators work
-As mentioned in the [User Handbook | Hooks](../user_handbook/hooks.md), user-generators are compiled into the kernel when the 
+As mentioned in the [User Handbook | Hooks](../user_handbook/hooks.md), user-generators are compiled into the kernel when the user
+defines hooks in `./config/hooks.rb`. These hooks are then interpreted when the `flok` user binary runs through build process 
+via `UserHooksToManifestOrchestrator`. The orchestrator then evaluates the `./config/hooks.rb` through the `UserHooksDSL` which
+captures each hook request as an unvalidated expression; that expression is then run through a generator block which yields
+a hook manifest entry that can be added to the hooks manifest. The hooks compiler then takes the manifest and runs over the source
+code with the manifest to inject code where needed.
+
+## How hook entry points get placed in source
+Hook entry points are not magical.  They are hand placed, typically via ERB, into source as they require some JSON encoded data.
+
+## Hook events
+Hooks are emitted into user-space via the `hook` module [Hook](../mod/hooks.md).

data/docs/mod/controller.md

@@ -6,6 +6,7 @@
 ### Functions
 `if_controller_init(bp, rvp, name, context)` - Initialize a controller that manages the view at `rvp` and contains the address `bp`. All events are sent to `bp` should be handled appropriatlely.
 The `rvp` pointer will always be an initialized (but not attached) view. When receiving an action, the view is guaranteed to be attached at that time. Context is what the controller was initialized with.
+**All controllers should be the same name as their views, there is a 1-1 relationship between views and controllers that was not originally true in the first version. Now views and contollers act as one**
 
 ### Spec helpers
 
@@ -28,8 +29,10 @@ special meanings based on the `name` field of the event:
 but have not been destroyed.
 
 ### Spec fixtures (driver side)
-There should be a special controller called `__test__` that can be initialized and should respond in the following ways when it receives an action and
+There should be two identical controllers called `spec_one_spot` and `spec_blank` that can be initialized and should respond in the following ways when it receives an action and
 event:
-  Note: an event is **not** a raw message, it is through the message of `int_event`, i.e. `[3, "int_event", "event_name", info]`
+  Note: an event is **not** a raw message, it is through the message of `int_event`, i.e. `[3, $NAME, bp, "custom_event", info]`. The event name may either be `foo` or `bar`
   Sends a **event** back called `action_rcv` containing `{from: from, to: to, info: info}` when an action is received
   Sends a **event** back called `custom_rcv` containing a hash that looks like `{name: name, info: event}` when a custom event is received
+
+  Additionally, add a controller named `spec_blank_sends_context` that sends back the initialization context when it is created via the event named `context` with the initialization (context) parameters.

data/docs/mod/hook.md

@@ -4,6 +4,7 @@ The hook module allows the client to receive hook_event messages. This is a requ
 ###Driver messages
 `if_hook_event(name, info)` - The name of the hook event and the information received.
 
-####Driver spec functions (only required in debug mode)
-`if_hook_spec_dump_rcvd_events` - Schedules the event `if_hook_spec_dump_res` to be sent out with a message in the form of `[1, "if_hook_spec_dump_rcvd_events_res", [{name:name, info:info}, ...]}` where the array contains
-the parameters to all the calls to `if_hook_event` with the example hash and in sequential order where the oldest is the greatest index.
+###Spec requirements
+When built for spec testing, the client should have two hook handlers for the hook events named `test` and `test2`.
+These hooks should both respond with a interrupt named `hook_dump_res` with the info `{name: "XXXX", info: info}`
+where the name is either `test` or `test2` and the info is the received payload.

data/docs/mod/persist.md

@@ -1,5 +1,5 @@
 #Persist (persist.js)
-Persistance management. Loosely based on redis.
+Persistance management. Loosely based on redis. Value's can be any javascript object.
 
 ###Driver messages
 `if_per_set(ns, key, value)` - Set a key and value

data/docs/mod/ui.md

@@ -22,6 +22,7 @@
 `spec_one_spot` - "A blank view with with one spot named `content` that takes up the entire view"
 `spec_two_spot` - "A blank view with with one spot named `a` and one spot named `b`.
 
+
 ------
 
 ## Overview 

data/docs/user_handbook/hooks.md

@@ -4,7 +4,7 @@
 ##### There are two questions that *Hooks* were designed to solve.
 
 1. Animation segues.  When a controller switches actions, often time it is swapping out view controllers. Adding animations at this time would be the optimal time to do so.  However, different clients, take blackberry and iOS, may either have fully-automated-animations, gesture controlled animations, cancelable-animations, synchronous-blocking, and the list goes on-and-on. Clearly, animations are handled differently on each platform, so how do we allow each platform to manage animation-segues?
-2. There are times when a client, e.g. chrome, need to support semantics that are platform dependent.  *For example*, you may need the back button in your web client to trigger a view controller to go back a page. However, this semantic does not make much sense when you have multiple view controllers; e.g. What view controller receives the back clicked event?
+2. There are times when a client, e.g. android, need to support semantics that are platform dependent.  *For example*, you may need the back button on your mobile phone to trigger a view controller to go back a page. However, this semantic does not make much sense when you have multiple view controllers; e.g. *(What view controller receives the back clicked event?)*
 
 ##### Additionally, these questions must be solved with these constraints
 1. Allowing the client to choose interception points at runtime would be prohibitively slow.  Therefore, care should be taken to make sure hooks are as static as possible and do not add un-necessary runtime overhead.
@@ -12,12 +12,13 @@
 -------
 
 ##### How hooks solves these problems:
-*Hooks* solves these questions and constraitns by allowing the user to define triggers in their project under `./config/hooks.rb` using a *DSL* which in-turn notifies the client. The client then handles each hook in an appropriate fashion.
-
+*Hooks* solves these questions and constraitns by allowing the user to define triggers in their project under `./config/hooks.rb` using a *DSL* which is used to create hook emitters at compile-time.  These hook emitters send the hook notification to the client.
 ## Hooking by example with `./config/hooks.rb`
 
 **Here is an example of a `./config/hooks.rb` which tells flok to notify the client that the `supports_back_clicked` hook triggered whenever a controller instance of a `"my_controller"` controller switches to an action via Goto that has an event handler defined with `back_clicked`:**
 
+Here is an example of a hook configuration file with *one* hook.  The hook generator is called `goto`, you may think of the generators as a set of helper DSL functions that have there own unique parameters.  The first line, `hook :goto => :supports_back_clicked` denotes that we are using the `goto` generator and the emitted event is called `:supports_back_clicked`.
+
 ```ruby
 # $USER_POJECT_ROOT/config/hooks.rb
 hook :goto => :supports_back_clicked do
@@ -25,21 +26,31 @@ hook :goto => :supports_back_clicked do
   to_action_responds_to? "back_clicked"
   controller_name "my_controller"
   
-  #Configuration methods
-  is_sync
+  #View hierarchy selectors
+  before_views({
+    "." => {
+      "__leaf__" => "foo"
+    }
+  })
 end
 ```
 
-**The basic format of each hook looks like:**
+A break down of this code is:
+
 ```ruby
-hook :hook_generator_name => :hook_notification_name do
-  #Selector methods & Configuration specific to the hook generator
+hook :generator_name => :my_hook_name do
+  #Selectors To Hook on
+
+  #Various configuration
+
+  #View hierarchy to forward to hook
 end
 ```
 
 Selectors for each hook generator create more specific requirements for a trigger. By convention, all hook generators, if supplied no selector arguments will select all possible.  **For example, this would hook all Goto statements in all controllers**:
+
 ```ruby
-hook :hook_generator_name => :hook_notification_name do
+hook :goto => :all_goto do
 end
 ```
 
@@ -47,7 +58,8 @@ end
 ---
 The client, in-turn must handle the hook notification, in this example, the hook notification is named `supports_back_clicked`. The hook notifications typically includes a set of parameters, but the parameters are dependent on the *hook generator* used.  In the above example, we are using the `goto` hook generator. See below for the different `hook generators` specifics.
 
-** See client docs for how to handle hook notifications, here is an example in pseudo code: **
+See client docs for how to handle hook notifications, here is an example in pseudo code:
+
 ```ruby
 handleHook("supports_back_clicked", function(hookInfo) {
   var to_action_name = hookInfo.to_action_name;
@@ -61,6 +73,14 @@ handleHook("supports_back_clicked", function(hookInfo) {
       * `to_action_responds_to? "event_name"` - Whenever a controller switches **to** an action that contains an `on "event_name", %{...}` handler
       * `from_action_responds_to? "event_name"` - Whenever a controller switches **from** an action that contains an `on "event_name", %{...}` handler
       * `controller "controller_name"` - Only applies to controllers with the name `"controller_name"`
+    * `Completion`
+      * The `completion` event is expected to be raised via `int_event` for all goto events. This is because the old view is not destroyed until the `completion` event is called
+        to allow you to use the view in animations.
+    * `Cancellation`:
+      * Unlike other semantics, `Goto` has issues with *cancellation* because the old views are destroyed. In order to work around this, you must call, after the completion
+        event, the `back` segue that you have described checking whether or not a transition was in progress (interactive) based on the view-controller itself.
+    * `info`:
+      * `ctp` - Completion telepointer, you should raise an `int_event` with this base-pointer.
 
 ## How the hook generators are defined & hooking internals
 See [Kernel Handbook | Hooks](../kernel_handbook/hooks.md)
@@ -70,7 +90,7 @@ The user's `./config/hooks.rb` file is compiled and then evaluated statically to
 and inserts code at particular hook detection points; the nature of the insertions is up to the particular hooking context.
 
 ##Synchronous vs Asynchronous Hooks
-Whether a hook is synchronous or not synchronous depends entirely on the type of hook in question. An example of a possible synchronous hook is a hook jkkkkkkkkkk..j
+There are situations where you may want a synchronous hook. Examples include 
 
 ##Hooking check points
 Each controller has a plethora of functions that determine it's lifetime and behaviours. These functions include the actions of creation, destruction, embedding, pushing actions, talking to services, etc.
@@ -83,14 +103,18 @@ the following JSON format:
 The name is the hook name and the params is context specific inforamtion the compiler has embedded. Live variables that are in the context of the hook detection point are described in each hook detection point below.
 
   * `controller_will_goto` - The controller is about to invoke the Goto macro and switch actions or it has just entered the first action from choose_action (which is a Goto).
-    * params (static generated)
+    * params (static generated in the hook info)
       * `controller_name` - The controller name that this entry effects
       * `from_action` - The name of the action we are coming from
       * `to_action` - The name of the action we are going to
-    * Useful (dynamic) variables
+    * Useful (dynamic/local JS) variables
       * `old_action` - The previous action, equal to `from_action` but in dynamic form. If there is no action, this is set to `choose_action`. Not sure why you would use this
       * `__info__.action` - The name of the new action
-  * `${controller_name}_did_destroy` - The controller has *just* been destroyed
+  * `controller_did_goto` - The controller has completed the goto switch
+    * params (static)
+      * `controller_name` - The controller name that this entry effects
+      * `from_action` - The name of the action we are coming from
+      * `to_action` - The name of the action we are going to
 
 ##Hooks Compiler
 The hooks compiler is able to take the hook entry points and inject code into them via a set of `HooksManifestEntries` which are bound togeather via a `HooksManifest`. The actual

data/flok.gemspec

@@ -34,6 +34,8 @@ Gem::Specification.new do |spec|
   spec.add_runtime_dependency "rake", "~> 10.3"
   spec.add_runtime_dependency 'naturalsort', "~> 1.0"
   spec.add_runtime_dependency 'awesome_print', "~> 1.6"
+  spec.add_runtime_dependency 'file-tail', "~> 1.1"
   spec.add_development_dependency "therubyracer", "~> 0.12"
+  spec.add_runtime_dependency "xcpretty", "~> 0.2"
   spec.executables << 'flok'
 end

data/lib/flok/user_compiler.rb

@@ -183,15 +183,29 @@ module Flok
             var old_action = __info__.action;
             __info__.action = "#{action_name}";
 
+            var __free_asap = true;
             //HOOK_ENTRY[controller_will_goto] #{{"controller_name" => @controller.name, "might_respond_to" => @ctx.might_respond_to, "actions_responds_to" => @ctx.actions_respond_to, "from_action" => @name, "to_action" => action_name}.to_json}
 
+            //If views are configured to not free right away, set up a new stack of views to free
+            //This is usually picked up by the hook GOTO
+            if (__free_asap === false) {
+              var views_to_free_id = gen_id();
+              views_to_free[views_to_free_id] = views_to_free[views_to_free_id] || [];
+            }
+
             //Remove all views, we don't have to recurse because removal of a view
             //is supposed to remove *all* view controllers of that tree as well.
             var embeds = __info__.embeds;
             for (var i = 0; i < __info__.embeds.length; ++i) {
               for (var j = 0; j < __info__.embeds[i].length; ++j) {
                 //Free +1 because that will be the 'main' view
-                main_q.push([1, "if_free_view", embeds[i][j]+1]);
+
+                //Free if 'free_asap' is not set, this is usually configured via the 'goto' hook
+                if (__free_asap === true) {
+                  main_q.push([1, "if_free_view", embeds[i][j]+1]);
+                } else {
+                  views_to_free[views_to_free_id].push(embeds[i][j]+1);
+                }
 
                 //Call dealloc on the controller
                 tel_deref(embeds[i][j]).cte.__dealloc__(embeds[i][j]);
@@ -223,6 +237,7 @@ module Flok
             //located in ctable
             __info__.cte.actions[__info__.action].on_entry(__base__)
 
+            //HOOK_ENTRY[controller_did_goto] #{{"controller_name" => @controller.name, "might_respond_to" => @ctx.might_respond_to, "actions_responds_to" => @ctx.actions_respond_to, "from_action" => @name, "to_action" => action_name}.to_json}
             //'choose_action' pseudo-action will be sent as 'null' as it's the initial state
             if (old_action === "choose_action") {
               old_action = null;
@@ -233,6 +248,7 @@ module Flok
               from: old_action,
               to: "#{action_name}"
             }]);
+
           }
           out.puts res
         elsif l =~ /Push/
@@ -589,7 +605,7 @@ module Flok
           self.instance_eval(&macro)
         @current_action = nil
       else
-        raise "No macro found named: #{method}"
+        raise "No macro found named: #{method} for controller #{@controller.name} in action #{@name}"
       end
     end
   end

data/lib/flok/user_compiler_templates/ctable.js.erb

@@ -76,6 +76,7 @@ ctable = {
                       var __info__ = tel_deref(__base__);
                       var context = __info__.context;
                       var current_action = __info__.action;
+                      var push_count = __info__.stack.length;
 
                       <%= e[:src] %>
                     },

data/lib/flok/user_hook_generators/goto.rb

@@ -2,10 +2,12 @@ require_relative 'helpers'
 
 module Flok
   class GotoHooksDSLEnv
-    attr_accessor :selectors
+    attr_accessor :selectors, :before_view_spider, :after_view_spider
 
     def initialize
       @selectors = []
+      @before_view_spider = {}
+      @after_view_spider = {}
     end
 
     def controller name
@@ -50,6 +52,14 @@ module Flok
       end
     end
     #################################################################################
+
+    def before_views spider
+      @before_view_spider = spider
+    end
+
+    def after_views spider
+      @after_view_spider = spider
+    end
   end
 
   UserHooksToManifestOrchestrator.register_hook_gen :goto do |manifest, params|
@@ -61,14 +71,32 @@ module Flok
     dsl_env = GotoHooksDSLEnv.new
     dsl_env.instance_eval(&block)
 
+    ns = "_#{SecureRandom.hex[0..5]}"
+
     #Inject into HOOK_ENTRY[controller_will_goto] that match the given selectors from the DSL
     #based on the hook entry static parameters
-    entry = HooksManifestEntry.new("controller_will_goto", dsl_env.selectors) do |entry_hook_params|
+    manifest << HooksManifestEntry.new("controller_will_goto", dsl_env.selectors) do |entry_hook_params|
       next %{
-        SEND("main", "if_hook_event", "#{hook_event_name}", {});
+        var #{ns}_before_views = find_view(__base__, #{dsl_env.before_view_spider.to_json});
+        __free_asap = false;
       }
     end
 
-    manifest << entry
+    manifest << HooksManifestEntry.new("controller_did_goto", dsl_env.selectors) do |entry_hook_params|
+      next %{
+        //The completion callback will share a pointer to the views_to_free key index
+        reg_evt(views_to_free_id, hook_goto_completion_cb);
+
+        var #{ns}_after_views = find_view(__base__, #{dsl_env.after_view_spider.to_json});
+        var #{ns}_info = {
+          views: #{ns}_after_views,
+          cep: views_to_free_id
+        };
+        for (var k in #{ns}_before_views) {
+          #{ns}_info.views[k] = #{ns}_before_views[k];
+        }
+        SEND("main", "if_hook_event", "#{hook_event_name}", #{ns}_info);
+      }
+    end
   end
 end

data/lib/flok/version.rb

@@ -1,3 +1,3 @@
 module Flok
-  VERSION = "0.0.102"
+  VERSION = "0.0.103"
 end

data/spec/env/iface.rb

@@ -27,6 +27,10 @@ shared_context "iface:driver" do
   include SpecHelpers
   before(:each) do 
     @pipe = IO.popen("rake pipe:driver", "r+") 
+    wait_for_load = @pipe.readline
+    $stderr.puts "waiting for LOADED from pipe"
+    raise "Your pipe should have emitted LOADED at the start when it was ready, instead got #{wait_for_load.inspect}" if wait_for_load.strip != "LOADED"
+    $stderr.puts "got LOADED from pipe"
     @pid = @pipe.pid
     @mods = Flok::Platform.mods ENV['FLOK_ENV']
   end
@@ -47,6 +51,10 @@ def mods
   Flok::Platform.mods ENV['FLOK_ENV']
 end
 
+def defines
+  Flok::Platform.defines ENV['FLOK_ENV']
+end
+
 def config_yml
   Flok::Platform.config_yml ENV['FLOK_ENV']
 end
@@ -58,6 +66,20 @@ def module_dep name
   end
 end
 
+#Similar to module_dep this checks for a defines as well, useful for optional specs
+def module_dep_defines(name:, defines:)
+  before(:each) do
+    if mods.include? name
+      unless (Flok::Platform.defines ENV["FLOK_ENV"])[defines]
+        skip "#{ENV["PLATFORM"].inspect} does support #{name.inspect} module but does not define #{defines} in config.yml"
+      end
+    else
+        skip "#{ENV["PLATFORM"].inspect} does not support #{name.inspect} module in config.yml"
+    end
+  end
+end
+
+
 #Require a key value to be a apart of the config yml
 def settings_dep key, value
   raise "#{ENV["PLATFORM"].inspect} does not support #{key.inspect} configuration in config.yml" unless config_yml.include? key
@@ -78,3 +100,19 @@ def restart_driver_but_persist
     raise "Tried to restart driver but timed out waiting for 'RESTART OK'"
   end
 end
+
+#Do not persist
+def hard_restart_driver
+  #Ensure the pipe is fully drained before sending RESTART
+  @pipe.puts [[0, 0, "ping"]].to_json; @pipe.readline_timeout
+
+  @pipe.puts "HARD_RESTART"
+  begin
+    Timeout::timeout(10) do
+      expect(@pipe.readline).to eq("RESTART OK\n")
+    end
+  rescue Timeout::Error
+    raise "Tried to HARD restart driver but timed out waiting for 'RESTART OK'"
+  end
+end
+

data/spec/env/kern.rb

@@ -177,9 +177,13 @@ shared_context "kern" do
     #for non-existant messages
     def ignore_up_to msg_name, priority=nil, &block
       @did_get = []
+      @original_q = @q == nil ? nil : JSON.parse(@q.to_json)
+      @original_cq = @cq == nil ? nil : JSON.parse(@cq.to_json)
 
       loop do
         if @q.count == 0 and @cq.count == 0
+          @q = @original_q
+          @cq = @original_cq
           raise "Waited for the message #{msg_name.inspect} but never got it... did get: \n * #{@did_get.join("\n * ")}"
         end
         #Dequeue from multi-priority queue if possible

data/spec/iface/driver/controller_spec.rb

@@ -16,18 +16,18 @@ RSpec.describe "iface:driver:controller" do
   end
 
   #Create a controller with the given base pointer and attach view to a spot pointer (rspace)
-  def init_controller(bp, view_name="spec_blank", rspace=0)
+  def init_controller(bp, view_name="spec_blank", rspace=0, context={})
     #Views are always bp+1, the bp points to an array with ['vc', 'main', spots...]
     #                                                        bp     bp+1  bp+n
     #Create a new view 'spec_blank' at bp+1
-    if view_name == "spec_blank"
+    if view_name == "spec_blank" || view_name == "spec_blank_sends_context"
       @pipe.puts [[0, 4, "if_init_view", view_name, {}, bp+1, ["main"]]].to_json
     elsif view_name == "spec_one_spot"
       @pipe.puts [[0, 4, "if_init_view", view_name, {}, bp+1, ["main", "content"]]].to_json
     end
 
     #Initilaize the view controller
-    @pipe.puts [[0, 4, "if_controller_init", bp, bp+1, "__test__", {}]].to_json
+    @pipe.puts [[0, 4, "if_controller_init", bp, bp+1, view_name, context]].to_json
 
     #Attach that view to the root
     @pipe.puts [[0, 2, "if_attach_view", bp+1, rspace]].to_json
@@ -57,17 +57,36 @@ RSpec.describe "iface:driver:controller" do
     expect(@pipe).to readline_and_equal_json_x_within_y_seconds([3, "int_event", bp, "action_rcv", {"from" => nil, "to" => to_action}], 6.seconds)
   end
 
-  it "Does send back a message for the test controller custom action" do
+  it "Does send back a message for the test controller custom action named 'foo'" do
     bp = 332
     init_controller(bp)
 
     #Send an action event
-    custom_name = SecureRandom.hex
+    custom_name = "foo"
     custom_info = {"info" => SecureRandom.hex}
     send_event(bp, custom_name, custom_info)
     expect(@pipe).to readline_and_equal_json_x_within_y_seconds([3, "int_event", bp, "custom_rcv", {"name" => custom_name, "info" => custom_info}], 6.seconds)
   end
 
+  it "Does send back a message for the test controller custom action named 'bar'" do
+    bp = 332
+    init_controller(bp)
+
+    #Send an action event
+    custom_name = "bar"
+    custom_info = {"info" => SecureRandom.hex}
+    send_event(bp, custom_name, custom_info)
+    expect(@pipe).to readline_and_equal_json_x_within_y_seconds([3, "int_event", bp, "custom_rcv", {"name" => custom_name, "info" => custom_info}], 6.seconds)
+  end
+
+  it "Does receive the context on initialization" do
+    bp = 332
+    init_controller(bp, "spec_blank_sends_context", 0, {"foo" => "bar"})
+
+    expect(@pipe).to readline_and_equal_json_x_within_y_seconds([3, "int_event", bp, "context", {"foo" => "bar"}], 6.seconds)
+  end
+
+
   it "When a view is deleted that was associated with a view controller, the view controller should no longer exist" do
     bp = 332
     init_controller(bp)
@@ -91,7 +110,7 @@ RSpec.describe "iface:driver:controller" do
     expect(@pipe).to readline_and_equal_json_x_within_y_seconds([1, "spec", [bp0, bp1]], 6.seconds)
   end
 
-  it "Can initialize a controller that embeds a controller and delete all supb-controllers when a parent view is destroyed" do
+  it "Can initialize a controller that embeds a controller and delete all sub-controllers when a parent view is destroyed" do
     bp0 = 332
     bp1 = 335
     init_controller(bp0, "spec_one_spot")