Brson's "someday" list

japaric 2016-09-03 17:13:58 UTC #15

I've been working on something like this. Basically, docker + travis + appveyor to test as many (cross) targets as possible. The repository is here. So far I count a test coverage of 21 of 49 targets.

My original goal was to create something where we could test our binary releases of std because, right now, those are untested on most platforms but I guess this could be turned into a general purpose cross testing framework for other Rust projects.

BatmanAoD 2016-09-04 16:57:28 UTC #16

That makes sense.

I do think that the really big problem right now is incorrect assumptions about Rust based on what little people have heard about it. For instance, in a discussion in which I was criticizing C++14's failure to permit std::function to contain a std::unqiue_ptr (or any other non-copyable object), someone was defending C++ by stating that my original design had a "logical" error, and that in fact "given the pedal-to-the-metal nature of C++, this specific issue is unavoidable". (This idea among the C++ community that all of its flaws are necessary flaws for a "power language" is frighteningly prevalent.) I explained that this issue would be avoidable if std::function supported move-semantics, and that this gave me the feeling that C++'s move-semantics are a "tacked-on" part of the language rather than a core part of the design as in Rust. The person responded by saying that his "theory" was that Rust handles this situation is "garbage-collected pointers". I of course explained that Rust does not have garbage collection, but I think the discussion highlights a fairly common misunderstanding--that memory-safe languages necessarily use garbage collection. And in the C++ community, garbage collection seems to be anathema (despite the fact that Bjarne Stroustrup has stated that he has no doubt C++ will some day incorporate garbage collection--a prediction I think is actually pretty unlikely).

brson 2016-09-06 18:41:09 UTC #17

@japaric Yay, this is exactly what I was hoping for! Do you know why so many targets are red (and why the badge says the build is passing)? I updated the op to link to your project.

brson 2016-09-06 18:44:02 UTC #18

I've updated the op with the following new tasks:

write packaging guidelines https://github.com/rust-lang/rust/issues/29563
convert niko's tutorial deck to an HTML format https://github.com/nikomatsakis/rust-tutorials-keynote
continue producing weekly project changelogs (like https://users.rust-lang.org/t/rust-project-changelog-for-2016-07-15/6555)
write up ideal rust reporting/accounting/triage procedures
update and maintain regression sheet https://docs.google.com/spreadsheets/d/1t3Wb77_hNsfnD2ZsCRiBaMYCw3qBQoVhUyP9hPNiczg/edit#gid=0
weekly compiler-perf report
commission rust artworks
investigate opportunities for a lustre-like in Rust
- http://www-verimag.imag.fr/The-Lustre-Programming-Language.html

japaric 2016-09-07 02:23:43 UTC #19

Do you know why so many targets are red?

So right now I'm running all these tests on all the non-windows targets:

println!("Hello, world!")
panic!()
Basic unit testing: #[test], #[should_panic]
catch_panic
libc_test
unit tests of each standard crate (e.g. libcollectionstest)

The current HEAD of the repository now runs all these tests even if one of them fails (I basically
re-implemented make's "keep going" flag) and report at the end which tests failed (if any). That
report looks like this:

FAILURES
--------
std.debug
std.release
libc_test

That's for the aarch64-unknown-linux-gnu.

So far I'm seeing the targets fail for these reasons:

catch_panic: this doesn't work on the i686-musl target. This is a legit failure and has been
reported to the rust-lang/rust issue tracker.
libc_test: these seem to be due to the glibc/toolchain version I'm using. Note that the test
suite doesn't actually fail, instead it doesn't even compile (compiling libc-test involves
compiling an auto-generated C file, that file doesn't compile). Most of the targets that appear as
failing in my repo pass the test suite on the libc repo, but the libc repo is using older
glibcs/toolchains. cf. rust-lang/libc#23 and rust-lang/libc#357
QEMU is broken for this arch: This is the case for powerpc64le. qemu-ppc64le segfaults when I try
to run any binary for this architecture. cf. Debian bug
libstd's unit tests segfault: This only happens on cross targets whose unit tests are run under
QEMU. And I think these may be false positive caused by QEMU limitation of handling several threads.
Because I've tested a few of these targets locally (also under QEMU) but running only the test
that fails (instead of the whole test suite) and on some runs the test passes and on some runs the
test segfaults. NOTE that in all cases (also in the repository), I always run unit tests with RUST_TEST_THREADS=1 to
limit the number of unit tests that runs concurrently to one but a single unit test may still
spawn several threads.
libstd's unit tests hang: Pretty much the same as above. I think this may be caused by QEMU.

These are the libstd unit tests I've seen fail so far:

fs::tests::canonicalize_works_simple
net::tcp::tests::connect_loopback
net::tcp::tests::multiple_connect_interleaved_greedy_schedule
net::tcp::tests::set_nonblocking
sync::mpsc::tests::stress_recv_timeout_shared

I've yet to dig deeper into these unit tests to figure out which are real failures and which are false
positives with 100% certainty though.

The good news is that all the other standard crates (libcoretest, librand, etc) pass their test
suites with 100% success on all the targets .

and why the badge says the build is passing

I think you were observing the build result of a branch that was not yet merged. The badge is no
longer green now :-).

brson 2016-09-07 14:45:16 UTC #20

Thanks for the details. This is great stuff.

brson 2016-09-19 19:43:07 UTC #21

Updating with:

fix emscripten unwinding and unimplemented symbols
- https://github.com/rust-lang/rust/issues/36514
- https://github.com/rust-lang/rust/issues/36515
investigate emscripten patch without fastcomp https://github.com/rust-lang/rust/issues/36356
organize bors-next effort
- https://github.com/rust-community/bors
- https://github.com/rust-community/team/issues/58
- https://github.com/AelitaBot/aelita
- http://github.com/servo/homu
- @ locks, @ booya, @ notriddle, @ aLi, @ frewsxcv, @ Manishearth
follow up on bitcode issue https://github.com/rust-lang/rust/issues/35968
write typescript / spidermonkey bindings for tokio

brson 2016-10-13 17:36:31 UTC #22

Updated with:

high

investigate aws deployment and bindings in rust
implement tuf https://github.com/rust-lang-nursery/rustup.rs/issues/241#issuecomment-253394566
do 1.13 relnotes
create beta/nightly testing system for rust projects via travis/appveyor
- maybe inspired by https://github.com/ember-cli/ember-try
- reporting to the mothership
- create list of projects and help authors deploy it
continue work on platform abstraction layer
create rust-wasm showcase site (maybe http://www.hellorust.com/emscripten/)
write some easy fmt rfcs https://github.com/rust-lang-nursery/fmt-rfcs/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3AE-easy
make P-high changes - either introduce release milestones or add P-critical
loosen bootstrap key logic https://github.com/rust-lang/rust/issues/36548

low

look at emscripten bug https://github.com/rust-lang/rust/issues/37130
make issue about reducing giant rustc stacks

brson 2017-01-17 19:17:36 UTC #23

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:

file issue about cap-lints + macro expansion re https://github.com/rust-lang/rust/issues/38977
fix rust-skeptic resolve bug
document error-chain backtrace feature
link rustc statically on windows
create mostly-Rust userspace from https://github.com/docker-library/busybox
convert FreeRTOS to Rust
write LAPACK -> Rust transpiler

ehiggs 2017-01-20 09:05:27 UTC #24

What's this one?

Nemo157 2017-01-20 09:13:05 UTC #25

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

ehiggs 2017-01-20 11:01:54 UTC #26

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

brson 2017-01-21 07:44:49 UTC #27

I believe my intent was to make https://github.com/brson/error-chain/blob/master/examples/quickstart.rs compatible with https://github.com/pwoolcoc/cargo-template, in anticipation of compatibility with your cargo PR in the future.

ehiggs 2017-02-02 10:16:32 UTC #28

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:

brson 2017-02-08 02:18:22 UTC #29

Thanks @ehiggs!

brson 2017-02-08 02:21:27 UTC #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)

ehiggs 2017-02-08 14:57:57 UTC #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.

brson 2017-02-23 00:37:53 UTC #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.

brson 2017-02-28 19:37:47 UTC #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

tshepang 2017-02-28 21:23:50 UTC #34

why proprietary?