|
| 1 | + |
| 2 | +# Testing |
| 3 | + |
| 4 | +- Run `make fmt` to format the code before presentingcode. This is |
| 5 | + mandatory and PRs that don't follow the coding style are rejected. |
| 6 | +- Run `racket src/main.rkt report bench/tutorial.fpcore tmp` to test |
| 7 | + that your changes work; this should take about 5-10 seconds and all |
| 8 | + of the tests should pass, getting basically perfect accuracy. |
| 9 | +- You can also run the unit tests with `raco test <file>`, when unit |
| 10 | + tests exist. Often they don't. |
| 11 | + |
| 12 | +# Profiling |
| 13 | + |
| 14 | +- Herbie generates a profile by default; run the `report` command |
| 15 | + above and look at `tmp/<benchmark>/profile.json`. |
| 16 | +- You can also run with `--enable dump:trace` to output |
| 17 | + `dump-trace.json` in chrome://tracing format |
| 18 | +- Additionally `--enable dump:rival` outputs all Rival commands it |
| 19 | + executes, which can be useful for debugging Rival & |
| 20 | + arbitrary-precision code. |
| 21 | + |
| 22 | +# Timeline |
| 23 | + |
| 24 | +- The timeline is Herbie's observability tooling. Timeline information |
| 25 | + goes into `timeline.json` and `timeline.html`. |
| 26 | +- A timeline is a list of phases, each of which is a hash table from |
| 27 | + key to "table", where a table is a list of rows each of which is a |
| 28 | + fixed-length array. Define new timeline types in |
| 29 | + `src/utils/timeline.rkt` and add/change HTML generation in |
| 30 | + `src/reports/timeline.rkt`. |
| 31 | +- Add to the timeline with `(timeline-push! 'type val1 val2 ...)`. The |
| 32 | + `val`s must be JSON-compatible; this mostly means you have to |
| 33 | + convert symbols to strings. |
| 34 | + |
| 35 | +# Documentation |
| 36 | + |
| 37 | +- Documentation lives in `www/doc/2.3/` and is HTML-formatted. Update |
| 38 | + it if you change any user-visible options. |
| 39 | + |
| 40 | +# PRs |
| 41 | + |
| 42 | +- PR descriptions should be 1-3 paragraphs in length. Describe the |
| 43 | + current behavior and why you changed it. Avoid bullet points. |
| 44 | +- Be explicit about the expected impact: "should be faster", "should |
| 45 | + be more accurate", "pure refactor, no changes", and so on. |
0 commit comments