@@ -34,7 +34,7 @@ OK /sys/hoon/set/test-set-wyt
35Here, we ran a generator called `+test` with a path argument `/sys/hoon/set`. The output tells us that all tests ran successfully. Running this generator automatically appends `/tests/` to the front of the path entered, so lets look at the beginning of `/tests/sys/hoon/set.hoon` to see what the `+test` generator took as an input:
35Here, we ran a generator called `+test` with a path argument `/sys/hoon/set`. The output tells us that all tests ran successfully. Running this generator automatically appends `/tests/` to the front of the path entered, so lets look at the beginning of `/tests/sys/hoon/set.hoon` to see what the `+test` generator took as an input:
38:: Tests for +in (set logic)
38:: Tests for +in (set logic)
@@ -46,7 +46,7 @@ Here, we ran a generator called `+test` with a path argument `/sys/hoon/set`. Th
46We note that the first line that isn't a comment is `/+ *test`, which from [the previous lesson](../ford.md) you know means that we are importing the shared library `lib/test.hoon`. This is followed by a core which will contain arms that perform our tests, which we will see an example of shortly.
46We note that the first line that isn't a comment is `/+ *test`, which from [the previous lesson](../ford.md) you know means that we are importing the shared library `lib/test.hoon`. This is followed by a core which will contain arms that perform our tests, which we will see an example of shortly.
48In `lib/test.hoon`, we find a core with a few gates: `expect-eq`, `expect-fail`, and `category`. The source for `expect-eq` is:
48In `lib/test.hoon`, we find a core with a few gates: `expect-eq`, `expect-fail`, and `category`. The source for `expect-eq` is:
50++ expect-eq
50++ expect-eq
51 |= [expected=vase actual=vase]
51 |= [expected=vase actual=vase]
@@ -75,7 +75,7 @@ This is the most frequently used gate in testing, so we may conclude that any te
75## Testing the functionality of set intersection
75## Testing the functionality of set intersection
77Here's one of the testing arms in the set testing core:
77Here's one of the testing arms in the set testing core:
79++ test-set-int ^- tang
79++ test-set-int ^- tang
80 =/ s-nul=(set @) *(set @)
80 =/ s-nul=(set @) *(set @)
81 =/ s-asc=(set @) (sy (gulf 1 7))
81 =/ s-asc=(set @) (sy (gulf 1 7))
@@ -109,7 +109,7 @@ Here's one of the testing arms in the set testing core:
111This arm is used to test whether the set intersection functionality works as expected. Let's walk through it line by line.
111This arm is used to test whether the set intersection functionality works as expected. Let's walk through it line by line.
113++ test-set-int ^- tang
113++ test-set-int ^- tang
114 =/ s-nul=(set @) *(set @)
114 =/ s-nul=(set @) *(set @)
115 =/ s-asc=(set @) (sy (gulf 1 7))
115 =/ s-asc=(set @) (sy (gulf 1 7))
@@ -118,11 +118,11 @@ This arm is used to test whether the set intersection functionality works as exp
118 =/ s-dup (sy ~[1 1 4 1 3 5 9 4])
118 =/ s-dup (sy ~[1 1 4 1 3 5 9 4])
120We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds several sets to the subject which will be utilized in our tests.
120We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds several sets to the subject which will be utilized in our tests.
124`;: weld` calls `weld`, which is typically a binary function, as an n-ary function. This will allow us to concatenate all of `tang`s that are to be generated into a single `tang`.
124`;: weld` calls `weld`, which is typically a binary function, as an n-ary function. This will allow us to concatenate all of `tang`s that are to be generated into a single `tang`.
126 :: Checks with empty set
126 :: Checks with empty set
128 %+ expect-eq
128 %+ expect-eq
@@ -130,7 +130,7 @@ We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds s
130 !> (~(int in s-nul) s-asc)
130 !> (~(int in s-nul) s-asc)
132`%+` is used to call a gate with a cell sample. `expect-eq` is the gate, `!> ~` is the head of the sample, and `!> (~(int in s-nul) s-asc)` is the tail of the sample. `!>` is a rune used to wrap a noun in its type - in other words, it produces a `vase`. We've seen this rune before when we learned about the type spear `-:!>`. Thus, what this block of code is doing is checking whether the expected `vase` that is the product of `!> ~` is equal to the `vase` that is the product of `!> (~(int in s-nul) s-asc)`. `s-nul` is simply the empty set, and here we are taking the intersection of the empty set with `s-asc`, a non-empty set. This ought to produce the empty set of course, and so when this block of code runs, we compare the expected result `!> ~` (which is something we determined by hand) with the actual result `!> (~(int in s-nul) s-asc)`.
132`%+` is used to call a gate with a cell sample. `expect-eq` is the gate, `!> ~` is the head of the sample, and `!> (~(int in s-nul) s-asc)` is the tail of the sample. `!>` is a rune used to wrap a noun in its type - in other words, it produces a `vase`. We've seen this rune before when we learned about the type spear `-:!>`. Thus, what this block of code is doing is checking whether the expected `vase` that is the product of `!> ~` is equal to the `vase` that is the product of `!> (~(int in s-nul) s-asc)`. `s-nul` is simply the empty set, and here we are taking the intersection of the empty set with `s-asc`, a non-empty set. This ought to produce the empty set of course, and so when this block of code runs, we compare the expected result `!> ~` (which is something we determined by hand) with the actual result `!> (~(int in s-nul) s-asc)`.
134 %+ expect-eq
134 %+ expect-eq
136 !> (~(int in s-asc) s-nul)
136 !> (~(int in s-asc) s-nul)
@@ -138,7 +138,7 @@ We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds s
138This is another test to check if intersection works with the empty set, but we have swapped where `s-asc` and `s-nul` are. We do not know a priori whether this ordering matters (and of course it shouldn't), which is why it is important to perform both tests.
138This is another test to check if intersection works with the empty set, but we have swapped where `s-asc` and `s-nul` are. We do not know a priori whether this ordering matters (and of course it shouldn't), which is why it is important to perform both tests.
142 :: Checks with all elements different
142 :: Checks with all elements different
144 %+ expect-eq
144 %+ expect-eq
@@ -147,7 +147,7 @@ This is another test to check if intersection works with the empty set, but we h
148Now we are checking if intersection works correctly when two non-empty sets share no common elements. We expect the intersection to be empty, so our expected `vase` is `!> ~`, and we then compare it with what the set library produces when it takes the intersection of `s-dos` and `s-asc`.
148Now we are checking if intersection works correctly when two non-empty sets share no common elements. We expect the intersection to be empty, so our expected `vase` is `!> ~`, and we then compare it with what the set library produces when it takes the intersection of `s-dos` and `s-asc`.
151 :: Checks success (total intersection)
151 :: Checks success (total intersection)
153 %+ expect-eq
153 %+ expect-eq
@@ -156,7 +156,7 @@ Now we are checking if intersection works correctly when two non-empty sets shar
157`s-asc` and `s-des` both ought to be the set containing the integers 1 through 7, but `s-asc` was generated with the list `~[1,2,3,4,5,6,7]` while `s-des` was generated with the list `~[7,6,5,4,3,2,1]`. Sets have no ordering, so they ought to be the same. Thus, when we take their intersection, we should get the same set back. So, our expected `vase` is `!> s-asc` and our actual `vase` is `!> (~(int in s-asc) s-des)`.
157`s-asc` and `s-des` both ought to be the set containing the integers 1 through 7, but `s-asc` was generated with the list `~[1,2,3,4,5,6,7]` while `s-des` was generated with the list `~[7,6,5,4,3,2,1]`. Sets have no ordering, so they ought to be the same. Thus, when we take their intersection, we should get the same set back. So, our expected `vase` is `!> s-asc` and our actual `vase` is `!> (~(int in s-asc) s-des)`.
160 :: Checks success (partial intersection)
160 :: Checks success (partial intersection)
162 %+ expect-eq
162 %+ expect-eq