Brson's "someday" list

Updating with:

Updated with:

high

low

1 Like

Updated op with these. A lot are pretty opaque. Sorry about that.

High:

  • write security roadmap
  • write release qa checklist
  • investigate rustup disk usage during transactions
  • change rustup to panic=abort
  • write rust packaging guidelines
  • get rustup working via powershell one-liner
  • add cargo-template quickstart instructions to error-chain docs
  • set up static linking for msvc rustc
  • fix rustup windows dojob issue (make cargo and rustup use the same dojob code)
  • simple crates in need - extract these from rustup/cargo and share
    • copy_dir
    • remove_dir_all
    • dojob
    • flock
    • symlink_dir
    • homedir
  • implement the update framework

Low:

2 Likes

What's this one?

Sounds like you should be able to just run cargo template quickstart my-new-project and get a project setup to use error-chain.

1 Like

Neat. Should it work in conjunction with this PR for cargo or some other way?

I believe my intent was to make error-chain/examples/quickstart.rs at master Ā· rust-lang-deprecated/error-chain Ā· GitHub compatible with GitHub - pwoolcoc/cargo-template: create cargo projects from existing templates, in anticipation of compatibility with your cargo PR in the future.

Templating was merged into Cargo yesterday.

The following project can be used as a quickstart template (I made a PR to use {{name}} and {{author}} templates:

2 Likes

Thanks @ehiggs!

@ehiggs What is the cargo command to instantiate the error-chain quickstart.rs directly from the error-chain repo (error-chain/examples/quickstart.rs at master Ā· rust-lang-deprecated/error-chain Ā· GitHub)? 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)

$ 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.

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.

1 Like

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

why proprietary?

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.

5 Likes

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.

@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?

@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ā€¦

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.

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