I agree that the filtering logic is complex. However, I’m not sure that it can be improved through simplification. Using a strict or relationship would result in behaviors that, I think would be unintuitive to users. An argument file:foo.rkt line:20, for example, would result in all test that are in file foo.rkt or line 20 being run, when the user probably meant “run the test in foo.rkt on line 20.” Similarly with names, under a strict or relationship, an argument of mytest file:foo.rkt would result in all tests with the name “mytest” or the file name foo.rkt being run. The user in this circumstance probably meant “Run all the tests named ‘mytest’ in foo.rkt.” The and relationship allows users to make more specific queries, which in my opinion is more valuable than simplicity of implemenation, since a user who wishes to cast a wider net can simply run raco test multiple times.

I think the primary use case is for users who want to avoid running tests which are computationally expensive or which clutter standard output. It’s intended to be used in combination with racket pull request 1726 (https://github.com/racket/racket/pull/1726), which allows users of raco test to forward arguments to the test modules being invoked. This was inspired in part by the testing frameworks of other popular languages like Ruby and Python, which allow users to specify from the command line sets of names to run.

@mflatt I don’t know if you saw this failing test, but it seems rktio-related: http://drdr.racket-lang.org/40902/racket/share/pkgs/unix-socket-test/tests/unix-socket/unix-socket.rkt

similarly this looks like a rktio failure: http://drdr.racket-lang.org/40902/racket/collects/file/private/glob.rkt

If it would be helpful to track these elsewhere, I can do that

and http://drdr.racket-lang.org/40902/pkgs/racket-test/tests/file/cache.rkt

Thanks – I’ve been looking at those, but I haven’t yet fixed them

@ryanc I think the test failure with “unix-socket.rkt” is a bug in “unix-socket.rkt”. When the custodian-shutdown callback is triggered for a listener, the listerner struct still has a value for fd – so the prop:evt callback can recreate the semaphore for fd even though that’s not a valid file descriptor anymore. Adding a poll of reg-box before creating the semaphore makes the test to pass on my machine, but if I’m diagnosing the problem correctly, maybe there’s a better repair.

@mflatt, yes, that makes sense. But now I can’t understand why it ever worked in the past. Any idea what changed?

The way the fd-semaphore table interacts with the scheduler is probably slightly different than before

I think maybe that code is trying too hard to compose a pretty solution out of nice pieces like custodian-boxes-acting-as-evts. It might be cleaner with another custodian shutdown procedure specialized to listeners. I’ll try that.

@mflatt, just pushed a fix

my get-info function for my #lang is buggy… is there a lighter weight way to test it w/o reloading drracket left and right?

exception raised by exception handler: result arity mismatch;
 expected number of values not received
  expected: 1
  received: 7
  values...:
   "\n"
   'white-space
   #f
   12
   13
   0
   #f; original exception raised: colorer.rkt:11:5: srcloc-token: unbound identifier in module
  in: srcloc-token

ok… I have that fixed… tho I have to say I have no idea how / why the lexer coloring function works the way it does. Also seems buggy. If I type prin it in red. It should go black when I add the final t for print but then I have a word that is 80% red and 20% black. DrRacket doesn’t seem to re-lex & color the whole word as it changes?