[racket-dev] Compiling tests

A few minutes ago, Robby Findler wrote:
> On Fri, Mar 30, 2012 at 10:02 AM, Eli Barzilay <eli at barzilay.org> wrote:
> > Yesterday, Robby Findler wrote:
> >> This has caused me some trouble and I'm not sure it is a good way to
> >> go, in general. Specifically, I'd like to think that our newer tests
> >> will more and more be things we'd want to compile.
> >>
> >> My desire to compile the tests is the same reason I want to compile
> >> any Racket file: so it loads faster.
> >
> > (To be clear, you're not talking about any other benefits besides
> > being able to run your tests faster, right?  Since drdr (or the
> > nightly build, for those tests) will still run them and report.)
> 
> I find it valuable to work with compiled racket files when I build
> racket software, tests or not. The drracket tests, in particular, have
> non-trivial libraries that go with them, more than just a sequences of
> inputs and outputs.

(The question was what is that value, other than speed?)


> > This sounds like a very minor damage: it's only you who wants to run
> > your tests, and even that happens only when you're testing...  It
> > seems that the benefit is also a minor improvement in tree setup
> > speed, but that one is done much more frequently, and by much more
> > people, so we get:  minor ⋘ minor * much².  Even more: I think that in
> > all cases that I ran test code, it happens while I'm editing the code
> > that is tested and/or the tests -- so I don't even get that small
> > benefit in my workflow.
> 
> I thought you said that disabling the eopl tests gets most of that
> benefit. Assuming that was right, I would prefer to do that (this is
> what I was trying to say in my previous message).

The problem is future additions.  (Which is why I don't want to go
back to selective exclusions.)

In any case: poll?


> > In any case, I have no principle objection here...  For the nightly
> > build (and for my own builds), I can easily just hack it to add the
> > `compile-omit-paths' definition before it builds the tree -- but given
> > the above, I think that most people would prefer to enjoy the shorter
> > build times.  (Kind of obvious when most people don't run these tests
> > on a regular basis.)  If not, I'll do that hack.
> >
> > Alternatively, add a flag to setup that is similar to `-D' to omit
> > compiling tests (and have it on by default).
> >
> >
> >> So, I'd like to go back to the old way: I can try disabling eopl
> >> tests and look at any other problematic collections if that would
> >> help with your original concern in a different way.
> >
> > [The problem with that approach is that new collections are being
> > added when nobody's looking, and having no global `compile-omit-paths'
> > means that they get compiled by default.  So I'd rather go with the
> > above hack than go back to selective exclusions.]
> 
> I'm fine with the nightly-build-based hack, but would prefer not to go
> with a new "-D"-like flag -- not sure which of those you're referring
> to here.

IMO a flag is a proper solution, but either way is fine.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!