@mflatt @samth @stamourv @robby or someone else with admin privileges, gleb seems like a spam bot. (If you are a real person I apologize.)

@leif I don’t think we need to do anything unless someone spams multiple times

@samth okay

I don’t think I have any admin privileges.

@robby Oops, sorry.

Ya, I don’t know who manages this slack instance, only the #racket irc channel.

@leif I think I’m the person to talk to, or @jsyeo

Alright, good to know for future reference, thanks.

does raco test support just running a single test within a module?

jamesswaine: It doesn’t know anything about the tests in the module. It just runs the test submodule. It might be possible to use the same code that counts the number of tests to quit after a certain number of them

ah okay, bummer, i sort of figured

yeah i was looking for something like what rspec gives you (ruby testing framework), where you can run a specific test in a suite by giving either a name or source line number on the command line

@jamesswaine that would be super useful, I agree. Right now the pipe of information isn’t very rich, but there is one, so it could probably be extended. This is the current library: https://github.com/racket/rackunit/blob/master/testing-util-lib/rackunit/log.rkt

I imagine that someone could add something to say “I am interested only in tests with this name” or “on this line in this file” and then rackunit could look there and raco test could initialize it.

(not that that’d be high on your priority list, of course :wink: )

haha, well, i’ve been wanting that forever so

@georges-duperon The highlighting change you proposed is super neat and makes me wonder if you could combine scribble/lp with cover usefully

@jamesswaine I’ve found various command line forms like that very useful in python, so consider this another vote :wink:

raco setup take forever…. and mostly on scribbling docs it seems like? has anyone looked at where the bottlenecks are in that process?

>1GB of RAM for raco setup also seems a bit surprising.

@thinkmoore a lot of it is typed racket + plot

see http://build-plot.racket-lang.org\|build-plot.racket-lang.org for details

@samth what specific part of typed racket causes the speed issues? Is it some weird artifact of how typed racket is implemented or is the type checking process itself just that expensive?

we believe that the type checking process is expensive

I eagerly await absolutely abysmal Hackett compile-times

@jamesswainer @samth @robby - I think that raco test could do something like “raco test args files — more” and when it ran an individual test submodule, it could make “more” be (current-command-line-arguments) then we could change rackunit, chk. eli-tester, and other popular testing libraries to look at those arguments to determine whether to run

a test. For example, if it was empty, then they’d run everything, otherwise they’d consider it a set of tags to run, etc

@notjack thanks :slightly_smiling_face: . I added the highlighting stuff to http://docs.racket-lang.org/hyper-literate/ (online docs are not up-to-date yet). The highlighting form @hlite[name pat . code] works like @chunk[name . code], but also expects a pattern. The pattern indicates which portions of the code should be highlighted as added/removed/dimmed/normal, so e.g. {+ _ _ - _} will highlight the first two expressions in green and the third in red (patterns can be more complex than that, and I hope to add support for syntax/parse-like syntax {a:+ b:+ c:-} soon, as it is more readable for complex patterns. So I think it should be reasonably easy to generate the pattern from the coverage information, but we would have to add line numbers to hlite first, though — don’t hold your breath, it won’t happen overnight :slightly_smiling_face:.

It seems reasonable to consider a more general solution but there is something to be said (both error messagewise and human convenience wise) for a shorter command line. Maybe we can solve that with some specific shorthands, starting from the ruby experience that @jamesswaine enjoyed?

From my pytest experience, the shorthand I used most was ’-k foo’ which ran every test whose name included foo

I am often copying a single test out and running it over and over as I work towards a fix for a bug, and generally in tests suites where I didn’t bother to name the tests (like the thousands of tests in the contract system), so an option that took a line number would be great for me.

Right, I agree that the exact same thing wouldn’t be as effective in Racket

Just documenting my experience

The other option I used a lot was “stop on first failure”