[ANN] PrettyTables.jl v0.12

[Ronis_BR]

Hi!

I just released PrettyTables.jl v0.12. As I mentioned in my last post, it has some deprecations (nothing is breaking) because two things:

1. The backend is now selected using Val instead of a symbol. Hence, backend = :html must be backend = Val(:html). The old version will work, but with a very bad performance.
2. The header is now selected by header keyword and it is a tuple of vectors instead of a matrix.

I apologize for such changes, but it was necessary to drastically reduce the time to print the first table, mainly in HTML and LaTeX backends. Take a look at the new numbers:

Notice that for HTML and LaTeX it takes now 4x less to print the first table.

This will (hopefully) be the last release before 1.0. I planning to wait one or two weeks for bugs before tagging 1.0. If you find anything weird, please, fill an issue in Github!

I would also like to thanks @bkamins to pointing the directions I need to follow to reduce these times. Furthermore, I want to thanks the developers of two amazing tools: SnoopCompiler.jl and Cthulhu.jl. I wouldn’t be able to optimize the package without those two packages.

[Oscar_Smith]

The speed like great! Any reason you went for this approach rather than defining a HTML struct for dispatch and using that instead?

[Ronis_BR]

It automatically identifies the table structure you are using. Hence, if you select tf = tf_html_default, then it automatically calls the HTML backend. The keyword is used when you just want the default table format.

I keep this backend keyword because of some backend I like to add like Markdown. It is a text backend (and will use everything we have in text) except for some minor differences.

[bkamins]

Bravo! This will greatly improve DataFrames.jl experience in 1.0 release for text/plain (and in the future also HTML and LaTeX).

[Ronis_BR]

Oops, I forgot to mention that the timing in the second run are in [ms], the rest are in [s].

[piever]

Really nice work! Having a performant “cross table type” solution for formatting can avoid a lot of code duplication across table implementations.

@Ronis_BR

I keep this backend keyword because of some backend I like to add like Markdown. It is a text backend (and will use everything we have in text) except for some minor differences.

Definitely looking forward to the Markdown backend. I find that markdown is a pretty good format to write reports, and it’s very helpful to be able to just embed a table there. (As a stopgap for now it already works to insert the HTML in the markdown.)

[rveltz]

Very cool work!

Can we print the table like an iterator, for example to log some computation progress?

[Ronis_BR]

@piever

Definitely looking forward to the Markdown backend. I find that markdown is a pretty good format to write reports, and it’s very helpful to be able to just embed a table there. (As a stopgap for now it already works to insert the HTML in the markdown.)

Nice! It would be somewhat easy, I just need to decide which features I will implement or not. For example: do we want cropping when using Markdown? Markdown is used to create that that will be renderer somewhere, I don’t know if we need to take care of cropping due to display size.

@rveltz

Very cool work!

Can we print the table like an iterator, for example to log some computation progress?

Thanks! No, but this is a very nice idea

[rikh]

You might be interested to learn that Latexify.jl can also convert DataFrames to Markdown tables