At Tue, 29 Nov 2011 15:48:32 -0500,
Stephen Bloch wrote:
> Those are probably the only REASONABLE sequences, but novice
> programmers will always find unreasonable ways to do it -- and those
> are the students I'm most worried about.
>
> To reduce the space of possible mistakes, I'm sorta leaning
Matthias 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
Thos
That would also work.
Robby
On Tue, Nov 29, 2011 at 8:43 AM, Matthias Felleisen
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
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
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
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 w
Those two seem like they can combine in strange ways.
Robby
On Mon, Nov 28, 2011 at 9:08 PM, Matthias Felleisen
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,
>> Mat
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
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
alto
Robby Findler writes:
> On Mon, Nov 28, 2011 at 1:30 AM, Michael Sperber
> 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 stude
On Nov 28, 2011, at 8:39 AM, Kathy Gray wrote:
> I don't recall our original reasoning, but I envision that with such a macro
> students will think they are only disabling the tests "below" the "call" and
> become confused. This isn't to say we shouldn't switch to a macro
I propose
1. to re
> 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 "nothi
On Nov 28, 2011, at 8:39 AM, Kathy Gray wrote:
> I don't recall our original reasoning, but I envision that with such a macro
> students will think they are only disabling the tests "below" the "call" and
> become confused.
I can see why they might expect that. I can also see why they (or I)
On Mon, Nov 28, 2011 at 1:30 AM, Michael Sperber
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 curr
I don't recall our original reasoning, but I envision that with such a
macro students will think they are only disabling the tests "below"
the "call" and become confused. This isn't to say we shouldn't switch
to a macro
-Kathy
On 28 Nov 2011, at 13:23, Matthias Felleisen
wrote:
Why
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 writes:
>
>> [ moved to dev ]
>>
>> Apparently this broke somewhere in between v5.0 (June 2010)
Robby Findler 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
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 wrote:
> On Sun, Nov 27, 2011 at 11:22 PM, Robby Findler
> wrote:
>> Does anyone know how to grep backwards through the
Apparently, disabling the tests with version 5.0 successfully disables
them with version 5.1 and the latest in git. Of course, attempting to
re-enable them in the later versions has no effect on the actual
tests, but re-enabling them with 5.0 does.
So I guess that's a clue. :)
Robby
_
On Sun, Nov 27, 2011 at 10:46 PM, Sam Tobin-Hochstadt wrote:
> On Sun, Nov 27, 2011 at 11:42 PM, Robby Findler
> wrote:
>> 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
>>
On Sun, Nov 27, 2011 at 11:42 PM, Robby Findler
wrote:
> 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.
That seems hard to bel
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
On Sun, Nov 27, 2011 at 11:22 PM, Robby Findler
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 br
I think you want "git log -Ssought -- path/to/file"
On Sun, Nov 27, 2011 at 8:22 PM, Robby Findler
wrote:
> Does anyone know how to grep backwards through the history of a file, using
> git?
>
> Robby
> _
> For list-related administrative tasks:
>
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
[ 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
n
26 matches
Mail list logo
