Rust libz blitz!

CommonMark doesn’t have tables, does it?

Not natively, but GitHub Flavored Markdown introduced an extension for it. To implement CommonMark we’ll be using markdown-it, which already supports the GFM table extension.

1 Like

The tracking issue for memmap is up. Thanks @sfackler and @danburkert.

@crlf0710 Thank you for the excellent suggestions. Offhand I agree about all of them and think you can go ahead and add them to the op, maybe with the exception of gc - I don't know much about this crate and the Rust GC story is really immature yet.

Most of the issues filed so far are tagged 'easy' or 'help wanted', and posted to the twir thread. I don't have contributor access to the memmap crate, so none of those are tagged, but there are relatively few filed against it.

I’ve updated the schedule through 7/11. I moved error-chain from 6/13 to 6/27 and set @aturon as the lead. @Yamakaky I hope you will be interested in helping with the evaluation and attending the libs team meeting.

To fill out the rest of the schedule I just moved crates from the “on-deck” section, which is now empty, into the schedule. So walkdir is 6/13, mio is 7/11, and gcc is 7/25. All of them still need leads. Please say so if you would like to volunteer.

walkdir is interesting because it could rightfully be in std, probably has some cross-platform considerations. mio is big so the evaluation we should expect to be quite involved. gcc is going to be the first tooling glue crate we’ve looked at.

Feel free to suggest or make tweaks.

@library_subteam let me know if this doesn’t work for you. @carllerche I believe you’ve previously expressed assent to evaluating mio here, and I hope this schedule will work for you.

There have been a bunch of good suggestions for other crates made on thread, and the op should be updated to include them somewhere. I may get back to that later today.

I've updated the schedule through 7/11. I moved error-chain from 6/13 to 6/27 and set @aturon as the lead. @Yamakaky I hope you will be interested in helping with the evaluation and attending the libs team meeting.

Of course! Don't hesitate @aturon.

1 Like

I signed up to eval the gcc crate.

2 Likes

Can I chime in just to suggest a crate? I think chrono is in need of work, and it seems to be the go-to solution for datetimes for many commonly used crates. Especially now that the time crate is deprecated, (btw. chrono still depends on it which I find unfortunate!) I think that much more work on chrono is needed.

6 Likes

Yes, I agree chrono is very important, and needs work. I expect to make a call for a more thorough design review of it soon. I think rand is in a similar category.

Like a chrono design review, there are several other useful library tasks that don't quite fit into the structure of the libz blitz that I'm hoping to get moving soon.

@fitzgen suggested today that cfg-if is worth a look. It fits into the category of things that could reasonably belong in std.

Might I suggest openssl?

Ok, here are all the additional crates suggested on thread so far that are not on the crate list.

I am in agreement about most of these, but I don’t know much about daggy, linked-hash-map, or matrix. I think the gc crate is quite experimental and would consider it out of scope today.

Can I suggest itertools and nom? Nom might be outside of the lib-blitz scope as it is currently ~2.2 but it could use some love.

1 Like

thread-id is another fundamental crate.

Won’t thread-id be subsumed by std::thread::ThreadId? #21507

I took the liberty of adding bytes, syslog, lzw, ring, openssl, petgraph, daggy, typenum, image, cfg-if, and itertools to the crate list. Others suggested may be good candidates, but I have less certainty.

nom I think is obviously an important and high-quality crate, but I’m not sure I consider parser generators in scope here. That’s not something I usually associate with batteries included standard libraries.

There are a number of additional library ecosystem tasks that don’t fit into the blitz structure that I would like to move forward sometime this summer. Just to telegraph that a bit, here is a braindump.

  • Standard library survey - Last year the libs team started a survey of batteries included standard libraries, but never finished. The intent was to get a handle on the set of features typically expected out of a language’s runtime stack, and then identify areas where we are lacking and need to focus effort.
  • rand design review - The rand crate has long been unsatisfactory to the libs team, and needs some focused design work. People that love random numbers are needed. I know @bstrie indicated he was keen about this.
  • chrono design review - This crate provides comprehensive date/time solutions, but it my experience using it (and I gather others’), it can be difficult to discover how to do some fairly basic tasks. I recall my biggest pain point was understanding how to deal with all the timezone concerns that are represented in the type system. It may be that just writing cookbook examples for a number of tasks would help. It also still depends on the time crate, which is destined to be deprecated. cc @lifthrasiir I hope you will be amenable.
  • A 1.0 crate scoreboard - Just a simple motivator. Create a thread on urlo that lists, in reverse chronological order, the crates that hit 1.0, their dates, and their authors. This clearly would be gameable, but that’s fine. At least it conveys consistently that 1.0 crates are important, and crate authors should endeavor to get there. It would be pretty easy to maintain with a script. Once a week post an update to the op, and a comment indicating all the updates and thanking the crate authors.
  • A cookbook roadmap and urlo thread - I’d like to define what a 1.0 cookbook looks like so there’s a clear destination, make regular point releases and status updates.

I’ve just discovered that docs.rs displays a crate’s GitHub README. Can you tell the difference between these two pages:

I was quite confused, and I think all this redundant information makes a poor experience.

In any case, we have no guidelines for crate READMEs, and since this is a crucial part of the documentation UI, it seems like we must establish some, then go back and review the crates we’ve done. cc @dtolnay

4 Likes

Yep, I'll have to bring this up in the front page styleguide RFC https://github.com/rust-lang/rfcs/pull/1687.