mattjquinn

Current print code has a large amount of overlap due to need to detect table column widths; format specifiers are used multiple times rather than in a single place. This...

Will improve performance when using large arrays that either: - don't have their internal elements accessed at all (i.e., `$ 100 100 100 $ 9999`) - only have parts of...

i.e., ```j a =: 2 3 $ 1.2323 4.43435 9.23333333333333 8.32 9.1121111111111 5 a ``` currently causes an unsupported message/exit. Add in appropriate snprintf/printf calls as was done for integers.

Use `criterion`'s comparison feature to compare benchmarks with the previous commit; if a performance decrease occurs, the build should fail.

Using `cargo doc-upload` gives inconsistent results from the Travis build; it worked at one point but now it doesn't. Rather than use GitHub pages, something like S3 should be used...

A subset of J programs that use a wide subset of J should be benchmarked to ensure compiler/runtime changes don't cause performance regressions.

For performance reasons, as much as possible should be allocated on the stack. Currently malloc calls are favored to keep the code understandable in its early stages, but in the...

- Possibly use Cargo's workspace feature to contain both the compiler crate and the dylib runtime crate so that they can share definitions such as type and verb enums.

Run with all warnings switched on, stop build if any warnings/errors.