Thanks for sharing the code! This is a terrific question. Great job
writing contracts and examples, which make understanding the issue in
the code here much more straightforward.
Note that the 0 out of 2 tests passed is telling us something
important about the behavior of the next-state-tick method as
implemented (screenshot attached for one of the test failures).
That message is saying that the *expected* value for the result of
sunset(300 + 50, 20 - 10)
I totally agree with this – it also matches the contract for
next-state-tick, which consumes a sunsetState and produces a
sunsetState. (I will note that it doesn't quite match the purpose
statement, which says the x coordinate should grow by 8 and the y
coordinate should shrink by 4.)
However, the result *produced* from calling next-state-tick is not a
sunset value, but rather an Image.
This should draw our attention to the body of the next-state-tick
function definition, which isn't producing the kind of value we said
we wanted in the contract and the example.
The step in the Design Recipe where we create the function body tells
us that we should take our examples, find what changed, and build the
function body by replacing the parts that change with information from
the function's parameters.
In this case, it looks like this was done, but then an *extra*
function call to draw-state was added in next-state-tick. Adding this
Image creation step makes the result of next-state-tick not match the
contract and examples we decided on, which is where the test failures
is coming from.
Based on this, how should next-state-tick change to match its examples
It's important that the contract for next-state-tick is sunsetState ->
sunsetState, because the on-tick handler of the reactor is expected to
consume and produce a value of the same type. The error when running
the *reactor* happens because on the first tick, the next-state-tick
function produces an Image, which becomes the reactor's state. This
Image is then used as the argument to draw-state, which is expecting a
sunsetState, not an Image, causing the field-not-found error (Images
don't have an xpos field, sunsetStates do).
There are a few lessons here:
- The test failures tell use useful information that can pinpoint the
error based on examples – here the error when running the reactor
appeared to blame draw-state, but the problem is in next-state-tick
- When we get a test failure about mismatched values, we should
consult the contract and examples for the function that didn't pass
the tests to see where we made a mistake
Let us know if you have more questions!
On January 15, 2019 at 9:38:08 AM, Matthew Dunn
> I am just getting started with the Boostrap Reactive. I did copy and pasted the code into
> Pyret and pressed run. Results 0 out of 2 Tested failed. Is there additional code necessary
> to get the solution to work. Do program solutions exist for each unit and other exercises.
> Matthew Dunn, MBA, MA
> Business & Technology Instructor
> Interboro High School
> From: bootstra...@googlegroups.com
> on behalf of Reetu Singh