Brson's "someday" list


#30

@ehiggs What is the cargo command to instantiate the error-chain quickstart.rs directly from the error-chain repo (https://github.com/brson/error-chain/blob/master/examples/quickstart.rs)? I’d like the error-chain docs to say something like

To get started run:

$ cargo template whatever

(Obviously fill in with the correct syntax)


#31

$ cargo new --template https://github.com/rusttemplates/quickstart whatever

Currently there is a bug in that particular template where the name and author aren’t actually templated but I have a PR to fix it.


#32

Here’s some commentary about the ‘simple crates’:

16:32 simple crates - there are a number of unbelievably common functions i end up reimplementing a lot 16:32 and poorly 16:33 copy_dir is just a recursive directory copy. not sure if there’s a good crate for this yet 16:34 sometimes one needs to do a copy but ignoring dotfiles. i open code this with walk_dir 16:34 but there should be a common copy_dir that covers most cases and just works 16:34 remove_dir_all is broken in std on windows 16:34 so people always reimplement in 16:34 *it 16:35 while it should be fixed in std, in the meantime somebody should just publish a working version 16:35 dojob is a common routine that cargo, rustbuild and rustup use to create process groups on Windows for killing multiple processes 16:35 but they all implement it diferently and some are missing fixes 16:36 symlink_dir would be a crate that creates symlinks to directories correctly on windows, using directory junctions 16:37 homedir would be an implementation of std::env::home that uses cargo/rustup’s definition. I consider std incorrect when it considers HOME on Windows.


#33

I’ve updated the list with:

high

  • document interfaces that are not-really stable
  • port cargobomb to windows
  • add stdx ci testing
  • install more things in cargobomb docker container

low

  • run custom shootout server with additional nightly benchmarks
  • write hello.exe size test
  • switch default rustup to -gnu
  • do analysis of servo crash fixes vs firefox crash fixes
  • propose proprietary Rust testing service

#34

why proprietary?


#35

It’s not the service itself that is proprietary, but a service for regression testing proprietary Rust projects, to give us visibility into the ecosystem where we are lacking it. It would be a formal structure for setting up NDAs and compensation for running cargobomb and similar future efforts on closed-source projects.


#36

As a once and future (hopefully with rust) "Enterprise Software Developer"™, I think this could go a long way towards reassuring companies that they could rely on rust for their development future.


#37

@brson I would like to help with

  • weekly compiler-perf report;

What does it actually entail? Hope explaining what it entails doesn’t take as long as actually doing it. :slight_smile:

From the single line, I assume it has to do with measuring performance of the compiler over its development history. Sounds related to continuous integration/testing/benchmarking. Would this use gperf? Which benchmarks would you use to measure this?


#38

@pmatos The main idea is just to get information about the performance of the Rust compiler in front of people on a regular basis, to build a sense of accountability. At the time I would have said to examine perf.rust-lang.org to extract a sensible story about what happened last week, and just write it up in a consistent way, with key metrics. At the moment though perf.rlo is not working…


#39

Templates was pulled out pending an RFC. The feedback in a pre-RFC thread suggests that people don’t want it in cargo but would rather an external cargo tool like clippy.


#40

I updated the op with the following:

high

  • update platform support page with richer info about which are tested
  • teach cargobomb to print rustc version in every run
  • fix skeptic linkage issue https://github.com/brson/rust-skeptic/issues/18
  • solicit cargobomb help
  • upload libz blitz videos to youtube
  • create 1.0 crate scoreboard
  • conduct research project on structuring projects for contribution

low


#41

I updated the op with the following.

This is pretty massive list of things that I think should be done, but mostly without much info about what that something is. If any of these look interesting and you want to take a stab at it I can try to help you get going.

Presently I’m finding myself completely overwhelmed with projects I want to advance, but without the time or means to get them moving myself.

high

  • finish anthology
  • start rust on fuchsia project
  • update cargo crusader so it works again
  • outline possibilities for getting more rust funding
  • teach cargobomb to print rustc version in every run
  • fix skeptic linkage issue https://github.com/brson/rust-skeptic/issues/18
  • solicit cargobomb help
  • create 1.0 crate scoreboard
  • write irlo post about triage opportunities
  • initiate project to serdify crates
  • find somebody else to do release milestone predictions
  • write release checklist
  • switch rustup to use the win-msvc host by default
  • do panic_fmt stabilization rfc
  • update smoke in terms of cross https://github.com/japaric/smoke
  • extract cargo_home / home_dir into their own crate
    • update rustup, cargo, cargo-index-tool
  • look for project management assistant
  • solicit ‘this release in rust’
  • ask for help running cargobombs
  • advance ‘train the trainer’ idea
  • solicit help on cookbook design
  • help budziq with cookbook recipe ideas
  • write fast scrypt library
    • corrode the fastest c scrypt implementation and convert it to safe rust?

low

  • do a new “annotated std”
  • work on rust-timeline (timeline of rust history)
  • rebrand ‘thanks’ thread
  • write a post about rust jobs http://rustjobs.rs/
  • conduct research project on structuring projects for contribution
  • upload libz blitz videos to youtube
  • update platform support page with richer info about which are tested
  • run emscriptenized tests under cargobomb
  • do standard library survey
  • getopts 1.0
  • do a linux distro rust/cargo/firefox packaging summary
    • status of all three packages in many distros
    • upstream package urls
    • get updates from packagers
    • irlo thread
  • cfg-ize servo to remove js, opengl, etc.
  • run bloaty mcbloatface on rust stuff https://github.com/google/bloaty
  • teach rustup to install with no toolchain
  • update basic-http-server to use modern crates
  • set up better tracking of regressions - use version-specific tags?
  • create a local (non-Send) alloc/collections crate
  • update research papers on the forge
  • update rust highlight definitions for benchmark game http://www.andre-simon.de/doku/highlight/en/highlight.php

#42

@brson I would love to help on the Rust on fuchsia project <3


#43
  • initiate project to serdify crates

Is this about the eradication of rustc-serialize from dependency chains throughout crates.io? I went and looked at dependent crates for rustc-serialize, it seems like a lot of the top crates already only have it as an optional dependency (not sure if crates.io “optional” includes both on and off by default or only the former) or a dev-dependency, which seems like the most important part. I also did a quick drive-by PR to move the dependency to a dev.dependency in one of the top downloaded crates (from page 3 or so of the results).

  • solicit cargobomb help

What kinds of help are you looking for?


#44

@goyox86 great! I think the most important thing to do is to just start building visibility and momentum. My rough plan here was to

  • Learn how to build hello world on fuchsia
  • Blog about that and post it to /r/rust
  • Start a thread on users.rlo asking how best to get community momentum

It would be great to have somebody leading the charge on Rust on Fuchsia (that could be you!). That somebody probably needs to get involved in the Fuchsia community and begin to understand where the opportunities are. We could then probably come up with a set of really neat projects to solicit contributions for, maybe start a github.com/rust-on-fuchsia org, do some hackathons, etc.

I suspect some big opportunities are:

  • hardware drivers - Fuchsia is a microkernel with userspace drivers, which makes them fairly accessible. It’s a new architecture, so there’s need for a ground up rebuilding of the driver ecosystem. There’s lots of hardware in the world to write drivers for. Having a big set of Fuchsia Rust drivers would firmly entrench Rust in the OS. We could pick some really cool SBC and aim to get Fuchsia working on it via Rust drivers.

  • coreutils - This is a pretty neat project that is developing slowly. Would be awesome to port it to Fuchsia. Not sure the state of coreutils on Fuchsia.

And … I don’t really know what else. Somebody needs to be in closer contact with the Fuchsia community. I know @cramertj has been poking at porting tokio and would be a good ally in the Fuchsia effort.

cc @raphlinus


#45

Thanks for doing that. It is also about making sure crates are following the two serde guidelines: that types that might reasonably be included in a serialized data structure implement the traits, and that the crate uses a “serde” cfg. Doing so for the crates in this list and the top X crates, and then maybe issuing a report about the state of serdification would be a great use of time.

The biggest kind of help needed right now is actually doing regular cargobomb runs against beta and nightly, and triaging the results; and doing cargobomb runs for ‘needs-crater’ PRs - there’s a lot of angst in the lang team recently that crater is hopelessly broken and nobody is available to do crater/cargobomb testing. I probably need to write up how to do cargobomb runs and cargobomb triage, and then solicit a team to do them.

But also cargobomb needs ongoing development to support more use cases, to be more convenient, and to be distributed. There’s no roadmap currently, and there’s leadership needed here. @tom.prince has been doing a lot of architectural work and cleanup, but more is needed.


#46

@gyscos I’d be happy to help you get started with Rust on Fuchsia-- I only just started working with Fuchsia myself, so I have recent newcomer experience :smile: . There’s also been a lot of progress very recently on some tools that make Rust on Fuchsia easy (@rtsuk has been doing some really great work here). Feel free to ping me on IRC and I’ll do my best to get you up and running.


#47

@cramertj I think you meant @goyox86? :wink:


#48

[quote=“brson, post:45, topic:3948”] Thanks for doing that. It is also about making sure crates are following the two serde guidelines: that types that might reasonably be included in a serialized data structure implement the traits, and that the crate uses a “serde” cfg. Doing so for the crates in this list and the top X crates, and then maybe issuing a report about the state of serdification would be a great use of time. [/quote]Can you give me more context about that list?

[quote=“brson, post:45, topic:3948”] I probably need to write up how to do cargobomb runs and cargobomb triage, and then solicit a team to do them. [/quote]Maybe you can start with Minimum Viable Instructions, then we can see if we can flesh it out?


#49

It’s the libz blitz working list. It’s a curated list of ‘important’ crates. There are some other similarly useful lists at the bottom of the op in the libz blitz threads.

There are some instructions here: https://github.com/brson/cargobomb#operational-workflow

That’s more-or-less enough to get started locally, but not enough to publish to our s3 bucket (publish-report vs gen-report). For ‘real’ cargobomb runs you might want access to our EC2 servers, which I can provide. To start you might want to just see if you can get cargobomb running locally.