Re: [racket-dev] [racket] Disable/Enable Tests
I see two sequences: -below ;; disables up to -above ;; here; disables up to -below and re-enables tests or -above ;; disables everything up to here and enables tests up to -below ;; here; disables tests below. Anything else? -- Matthias On Nov 28, 2011, at 10:09 PM, Robby Findler wrote: Those two seem like they can combine in strange ways. Robby On Mon, Nov 28, 2011 at 9:08 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I can see adding both disable-tests-above and disable-tests-below. On Nov 28, 2011, at 3:44 PM, Vincent St-Amour wrote: At Mon, 28 Nov 2011 11:54:06 -0500, Matthias Felleisen wrote: I propose 1. to remove the menu and its functionality 2. to add a macro disable-tests-below 3. and be prepared to add a macro enable-tests-below. `disable-tests-below' makes it easy to accidentally skip running tests altogether. Consider this scenario: - A student works on an assignment, one problem at a time. - Once a problem is done, he doesn't touch the code anymore, and wants to disable the tests. - With `disable-tests-below', he needs to add it at the top of the file, and to add `enable-tests-below' before the problem he's now working on. - If he forgets to add `enable-tests-below', no tests get run at all. `disable-tests-above' would accomodate this workflow better. If the student forgets to move it as he solves problems, then more tests get run. No problem. That sounds like a better default to me. However, I'm a bit uncomfortable with `disable-tests-above' affecting the behavior of what comes before it. It may lead to confusing situations. A region-based solution also sounds good. Especially since (I assume) only a small number of tests are actually expensive. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
That would also work. Robby On Tue, Nov 29, 2011 at 8:43 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: I think we're over-complexifying the whole situation. Perhaps we should allow only one of these things to appear in the definitions buffer. We're talking about novice programmers. I don't expect them to use check-expect after semester 1 (or perhaps part of 2). I just don't think that this is a big deal. -- Matthias On Nov 29, 2011, at 9:38 AM, Robby Findler wrote: If I put two -above's in a row does that push past the previous -below? :) In all seriousness, this seems like a way for students to get confused about what their programs are or aren't doing. It seems easy to lose track of where the aboves and belows are. If I understand correctly, this is not a performance issue, but an issue of keeping track of which test cases are the interesting ones while working on one part of a program. That is, we want a mechanism to focus in on a section of the program and its test cases. If that's correct, then I think we have two better routes to pursue: - multi-file programs - better support in the GUI for showing us only some of the test results (perhaps something to focus in on test cases that test specific functions or something like that). Robby On Tue, Nov 29, 2011 at 7:03 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: I see two sequences: -below ;; disables up to -above ;; here; disables up to -below and re-enables tests or -above ;; disables everything up to here and enables tests up to -below ;; here; disables tests below. Anything else? -- Matthias On Nov 28, 2011, at 10:09 PM, Robby Findler wrote: Those two seem like they can combine in strange ways. Robby On Mon, Nov 28, 2011 at 9:08 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I can see adding both disable-tests-above and disable-tests-below. On Nov 28, 2011, at 3:44 PM, Vincent St-Amour wrote: At Mon, 28 Nov 2011 11:54:06 -0500, Matthias Felleisen wrote: I propose 1. to remove the menu and its functionality 2. to add a macro disable-tests-below 3. and be prepared to add a macro enable-tests-below. `disable-tests-below' makes it easy to accidentally skip running tests altogether. Consider this scenario: - A student works on an assignment, one problem at a time. - Once a problem is done, he doesn't touch the code anymore, and wants to disable the tests. - With `disable-tests-below', he needs to add it at the top of the file, and to add `enable-tests-below' before the problem he's now working on. - If he forgets to add `enable-tests-below', no tests get run at all. `disable-tests-above' would accomodate this workflow better. If the student forgets to move it as he solves problems, then more tests get run. No problem. That sounds like a better default to me. However, I'm a bit uncomfortable with `disable-tests-above' affecting the behavior of what comes before it. It may lead to confusing situations. A region-based solution also sounds good. Especially since (I assume) only a small number of tests are actually expensive. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
Why does this have to be a menu? Why not add a macro to the test-engine code so that students can write (disable-tests) On Nov 28, 2011, at 2:30 AM, Michael Sperber wrote: Robby Findler ro...@eecs.northwestern.edu writes: [ moved to dev ] Apparently this broke somewhere in between v5.0 (June 2010) where it works and v5.1 (Feb 2011) where it doesn't. I can't use git bisect to find the precise commit because the earlier version doesn't compile on either my windows or my mac machine (mac is lion and windows uses too new of a version of visual studio). And I *hate* touching this code because something always ends up broken. I got really mad last time this code broke and so I hope we have better test suites now because of that, but I'm really not excited by the prospect of trying to change it again. Not only is the code hard to understand because it is poorly written, it is also unclear what parts of DrRacket it influences. Given all of this, my inclination is to simply remove this option. So far the only one who has spoken in favor of it gave a reason that (thankfully) no longer applies. Any objections? Comments? Mike? Some tests (especially check-property-based tests) are expensive, and you don't always want to run them - especially with world/universe-based code. Is there a way to have that option only with the student languages? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
On Mon, Nov 28, 2011 at 1:30 AM, Michael Sperber sper...@deinprogramm.de wrote: Some tests (especially check-property-based tests) are expensive, and you don't always want to run them - especially with world/universe-based code. Is there a way to have that option only with the student languages? The option currently affects only the student languages, I believe. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
It would be a whole lot nicer to insert (disable-tests) and (enable-tests) in the code, or perhaps to wrap a bunch of lines of code in (with-tests-disabled ...) or (with-tests-enabled ...) The Tracer does essentially this in reverse: by default you use the Tracer language and nothing happens (ie, code runs and produces answers but there's no visible tracing), but you can turn on tracing with: 1.1 (trace-failed-checks) Adding (trace-failed-checks) will trace only failing checks, including failed instances of check-expect, check-within, check-error, check-member-of, and check-range. 1.2 (trace-all) Adding (trace-all) will trace all top level expressions and failed checks. 1.3 (trace-explicit) Adding (trace-explicit) will trace failing checks and any expression wrapped in (trace ...). Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
At Mon, 28 Nov 2011 11:54:06 -0500, Matthias Felleisen wrote: I propose 1. to remove the menu and its functionality 2. to add a macro disable-tests-below 3. and be prepared to add a macro enable-tests-below. `disable-tests-below' makes it easy to accidentally skip running tests altogether. Consider this scenario: - A student works on an assignment, one problem at a time. - Once a problem is done, he doesn't touch the code anymore, and wants to disable the tests. - With `disable-tests-below', he needs to add it at the top of the file, and to add `enable-tests-below' before the problem he's now working on. - If he forgets to add `enable-tests-below', no tests get run at all. `disable-tests-above' would accomodate this workflow better. If the student forgets to move it as he solves problems, then more tests get run. No problem. That sounds like a better default to me. However, I'm a bit uncomfortable with `disable-tests-above' affecting the behavior of what comes before it. It may lead to confusing situations. A region-based solution also sounds good. Especially since (I assume) only a small number of tests are actually expensive. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
Those two seem like they can combine in strange ways. Robby On Mon, Nov 28, 2011 at 9:08 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I can see adding both disable-tests-above and disable-tests-below. On Nov 28, 2011, at 3:44 PM, Vincent St-Amour wrote: At Mon, 28 Nov 2011 11:54:06 -0500, Matthias Felleisen wrote: I propose 1. to remove the menu and its functionality 2. to add a macro disable-tests-below 3. and be prepared to add a macro enable-tests-below. `disable-tests-below' makes it easy to accidentally skip running tests altogether. Consider this scenario: - A student works on an assignment, one problem at a time. - Once a problem is done, he doesn't touch the code anymore, and wants to disable the tests. - With `disable-tests-below', he needs to add it at the top of the file, and to add `enable-tests-below' before the problem he's now working on. - If he forgets to add `enable-tests-below', no tests get run at all. `disable-tests-above' would accomodate this workflow better. If the student forgets to move it as he solves problems, then more tests get run. No problem. That sounds like a better default to me. However, I'm a bit uncomfortable with `disable-tests-above' affecting the behavior of what comes before it. It may lead to confusing situations. A region-based solution also sounds good. Especially since (I assume) only a small number of tests are actually expensive. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
[ moved to dev ] Apparently this broke somewhere in between v5.0 (June 2010) where it works and v5.1 (Feb 2011) where it doesn't. I can't use git bisect to find the precise commit because the earlier version doesn't compile on either my windows or my mac machine (mac is lion and windows uses too new of a version of visual studio). And I *hate* touching this code because something always ends up broken. I got really mad last time this code broke and so I hope we have better test suites now because of that, but I'm really not excited by the prospect of trying to change it again. Not only is the code hard to understand because it is poorly written, it is also unclear what parts of DrRacket it influences. Given all of this, my inclination is to simply remove this option. So far the only one who has spoken in favor of it gave a reason that (thankfully) no longer applies. Any objections? Comments? Mike? Robby On Sun, Nov 27, 2011 at 8:24 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: It doesn't appear to do anything at the moment -- it's only effect is to set a preference (buggily) which is only examined by the menu item, not by any testing code. I've been unable to determine when it stopped working via code archeology, but it was probably quite a while ago. On Sun, Nov 27, 2011 at 8:17 PM, Mark Engelberg mark.engelb...@gmail.com wrote: In the latest version of Racket, I see a menu item to disable and enable tests. What testing library does this work with? The htdp testing library, rackunit, something else? Thanks, Mark _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
Does anyone know how to grep backwards through the history of a file, using git? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
On Sun, Nov 27, 2011 at 11:22 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Does anyone know how to grep backwards through the history of a file, using git? I'd do this: % cd collects/test-engine % git log -p -Senable . where 'enable' might be something else. However, that exact query shows that either you broke the code in commit 1b29fd590b which I find unlikely from the text of the commit, or it was something not found by that query. :( -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
Okay. Thanks, Sam and Eric. It appears that in 5.1 check-expect didn't work at all (is that possible?!) so I guess that trying to look through the history to find something helpful is probably a waste of time. And, FWIW, the commit I did below could have been the source of problems, as it changes the timing of how preferences work (especially related to saving prefs in drracket's space thread and then looking them up in the user's space) which could easily have had something to do with breaking this feature. (It is a bad idea for code to expect to trying to communicate between those two places via the filesystem, but that's no excuse for me missing this problem. Sigh.) Robby On Sun, Nov 27, 2011 at 10:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sun, Nov 27, 2011 at 11:22 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Does anyone know how to grep backwards through the history of a file, using git? I'd do this: % cd collects/test-engine % git log -p -Senable . where 'enable' might be something else. However, that exact query shows that either you broke the code in commit 1b29fd590b which I find unlikely from the text of the commit, or it was something not found by that query. :( -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Disable/Enable Tests
Turns out that this commit was part of the problem. I didn't udpate all of the uses of those preferences properly. Robby On Sun, Nov 27, 2011 at 10:30 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sun, Nov 27, 2011 at 11:22 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Does anyone know how to grep backwards through the history of a file, using git? I'd do this: % cd collects/test-engine % git log -p -Senable . where 'enable' might be something else. However, that exact query shows that either you broke the code in commit 1b29fd590b which I find unlikely from the text of the commit, or it was something not found by that query. :( -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
