Do you have more info on this?
This link could be wrong.
Do you have more info on this?
This link could be wrong.
I added these two links to the error handling item:
But basically what I want to do is take the in-tree Error trait and put it in its own crate, name it
Error2 perhaps, then create various crates around it that prove it can support all the patterns one might want, some of which are discussed in the linked threads, some of which are just notions in my head that may be lost already. The end result I want though is that other people can write support crates that allow the easiest-possible error handling solutions for newbies and those that don’t want to think hard about it. Potential requirements: it is possible to define an error type in one crate, and reuse it conveniently in other crates; don’t need to define a local error type or variants, but can reuse other crates error types; don’t need to define any conversions to support
? (i.e. box everything); preserve the cause chain with minimal work (ala error-chain).
Then see if its possible to create easy conversions between
Error2 so that
Error2 can be viable without merging into std as
Error and breaking the world.
Fixed the poisoning link.
Do you have a loose bucketing of priorities for these items? Might be good to have them grouped by “top priority”, “second-highest priority”, etc
Or someday, some later day, someday much later
What is this (in brief)?
I’ve split it into high/low.
It’s important for funding of Rust development to diversify, and right now there is no directed action toward this goal. One potentially engaging option is to explore whether it’s possible to kickstart any amount of Rust feature work. Consider that community is Rust’s strength and we have high visibility on social media compared to many software projects. Though software is hard to crowd-fund we may have a chance. Figuring out how to formulate it in a successful way would be tricky: need to have an especially inspiring pitch; the kinds of devs with the skills to have a big short-term impact on Rust can demand a high price.
My best idea on this front is to ahead of time discuss in the community the most impactful way to spend a 3 month contract, get lots of buy in and excitement. Make arrangements with one of the many talented students who work on Rust and have a strong reputation to complete a 3 month project for some (relatively low) fixed price. As students they can tolerate lower income and have motivation to do a high-profile contract as a prestigious resume builder. They would have to be prepared for extreme scrutiny.
We have a lot of experience with contracting for Rust so there’s some evidence we could pull it off.
If we could do it once successfully on a very small scale, then we could build off that success to do it over and over.
High risk and a lot of effort just to plan.
write cross-compile roadmap
I’d do that, though I have about 2 weeks before my time for side things will shrink a lot.
contact fuschia team about rust
That sounds fun!
That would be amazing. Even just a rough sketch would help.
I don’t know what timescale you were thinking, but my long-term roadmap for cross-compilation “done right” is:
cargo build -p stdjust works.
Thanks @Ericson2314. That’s a great start! I’ll try to augment that with my thoughts soon.
New someday tasks (updated in the op):
cargo testfor cross-targets, maybe
What kind of people are you picturing as “Rust reps”, and what needs to be done to organize this? I think I understand Rust philosophically and am eager to use it more, and in fact I’ve nicknamed myself “Rust evangelist” on my company’s internal IM client. However, I haven’t actually done any coding in Rust beyond some tutorials, because we currently use C++ at work, and my family life has been pretty all-consuming outside of work these last few years.
@BatmanAoD Regarding “Rust reps”, the kernel of the idea came from a conversation I had with @Manishearth where he mentioned that he was at a non-Rust related Mozilla event, and people were excited to talk to him about Rust. And I have that experience a fair bit too - I tell people I work on Rust and they’re excited to hear about it. So it seems to me there’s a lot of recognition we could achieve just by having Rust folks seen in various relevant social settings.
So the way I pictured it is that we would have people just get out and attend the normal industry events they usually would (though maybe more-so - I know I don’t get out enough), and be known as “the Rust guy/girl”. In particular, we’re in a phase where we’re in a period where we’re trying to raise the profile of Rust in the Mozilla community, so I figured we would start by just having Rust folks go to Mozilla events (there are a lot of them). That’s really safe: they would be welcome there and not have much risk of coming off as pushy sales people. We could of course also think about expanding to all sorts of events in relevant industries.
The big risk though with such an imitative is representing Rust poorly. It’s easy for evangelism to turn into salesmanship or zealotry, and some already have a negative opinion of the boundless enthusiasm of Rust fans. So we’d want to make sure reps were well prepared with an approach that is consistent with Rust values.
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.
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).
@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.
I’ve updated the op with the following new tasks:
Do you know why so many targets are red?
So right now I’m running all these tests on all the non-windows targets:
The current HEAD of the repository now runs all these tests even if one of them fails (I basically
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
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.
RUST_TEST_THREADS=1to limit the number of unit tests that runs concurrently to one but a single unit test may still spawn several threads.
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 :-).
Thanks for the details. This is great stuff.