[racket] universe program using 100% cpu on Mac (also poor Raspberry Pi performance)

On Jan 2, 2015, at 10:08 PM, Darren Cruse wrote:

> a.  Testing
> 
> Regarding my poor attitude towards TDD... :)  I have been trying to take everyone's comments to heart and have been attempting to get that black background stuff off of drracket for my pong program!!

HtDP is NOT TDD. (I learned 'testing' in 1984 in a Franz Lisp and Scheme system. TDD is just the popularizers' way of getting a small element of good programming out to the masses.) 

The tests/examples serve as part of the design step. How can you solve a problem w/o making examples? So HtDP is trying to create a habit. 


> I have made some progress but I did want to ask a few pragmatic questions:
> 
> a1.  Do people *truly* go for 100% coverage i.e. *truly* get rid of all the black background stuff?

No. Students are definitely allowed not to test the main function of a big-bang program. 


> a2.  One kind of funny question - I attempted to add a test of my main function - which calls big-bang - esp. since drracket's showing the black background on that.  Something like this:
> 
> (check-expect (main initial-world) expected-world)
> 
> (define (main world)
>     (big-bang world
>             [name "Pong World"]
>             [on-tick handle-tick]
>             [to-draw draw-pong-world]
>             [on-pad handle-key-down]
>             [on-release handle-key-up]
>             [on-mouse handle-mouse]
>             [stop-when quitting? draw-goodbye]))

If you wish to test such functions, and I need to do that, add another argument to main that specifies for how many ticks you want to run the program. Yes, I should create a big-bang clause

   [testing? Boolean]

so that people can test on a head-less machine, like we do for drdr. 


> a3.  I also have quite a few of these "setter"/"updater" type of functions for copying a structure but setting one of it's values.  Here's one for an example:

[It's "its" not "it's" here.]

Again, I'd expect students to test a function that uses pong-set-world-set-ball (what a name, how about set-pong-world-ball). 

In general, if you are designing f and you put g on the wish list for f, I would expect that you at most derive an example from f's suite for g's -- simply for the design of g. If it is obvious, I would say, just define the function. If f fails and g is even remotely a candidate, derive tests for g from f's test suite to rule out mistakes in g. 

This is for freshman students who have matured to a certain points. I think your pong program demonstrates that you have gotten to that point. Why don't you tackle a universe-based pong game? 

-- Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150103/e7a64395/attachment-0001.html>