- 20 5月, 2013 28 次提交
-
-
由 bors 提交于
-
由 bors 提交于
With this, the build is almost 100% warning free. One more can be fixed after the next snapshot, and there's one other that I filed an issue about already.
-
由 bors 提交于
Mostly of the 'unused imports' kind. I'm unsure about the 'no unsafe' bit, but that's what it says...
-
由 Brian Anderson 提交于
-
由 bors 提交于
Had a conversation with @cmr in IRC about some places that these docs were confusing. The functions that advance the stream now say so. In addition, I think that calling out the similarities to familliar C functions should help people coming from other languages.
-
由 bors 提交于
These imports were not being used.
-
由 Steve Klabnik 提交于
This is now 100% consistent. Whoops!
-
由 Steve Klabnik 提交于
-
由 bors 提交于
Let's actually give a top-level description of what's in here, eh?
-
由 Steve Klabnik 提交于
Mostly of the 'unused imports' kind.
-
由 bors 提交于
-
由 Steve Klabnik 提交于
These imports were not being used.
-
由 Steve Klabnik 提交于
Thanks @catamorphism!
-
由 Corey Richardson 提交于
-
由 Corey Richardson 提交于
-
由 Corey Richardson 提交于
-
由 Steve Klabnik 提交于
Let's actually give a top-level description of what's in here, eh?
-
由 bors 提交于
Added docs for stdout, stderr, print, and println.
-
由 bors 提交于
My earlier fix for #4202 would not work correctly if the trait being exported was a top-level item relative to the module from which it was being exported. An example that would not work correctly with the original patch: // foo.rs pub use Foo = self::Bar; pub trait Bar { pub fn bar() -> Self; } impl Bar for int { pub fn bar() -> int { 42 } } // bar.rs fn main() { foo::Foo::bar() } This is now supported. I believe this change will allow the GenericPath trait to be exported from core::path as Path in such a manner, which should allow #5389 to move forward.
-
由 Tom Lee 提交于
-
由 Tom Lee 提交于
-
由 Tom Lee 提交于
-
由 Steve Klabnik 提交于
-
由 bors 提交于
-
由 Steve Klabnik 提交于
Had a conversation with @cmr in IRC about some places that these docs were confusing. The functions that advance the stream now say so. In addition, I think that calling out the similarities to familliar C functions should help people coming from other languages.
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
-
由 Steve Klabnik 提交于
Added docs for stdout, stderr, print, and println.
-
- 19 5月, 2013 12 次提交
-
-
由 bors 提交于
I don't have a strong opinion on the function vs. method, but there's no point in having both. I'd like to make a `repeat` adaptor like Python/Haskell for turning a value into an infinite stream of the value, so this has to at least be renamed.
-
由 bors 提交于
-
由 Corey Richardson 提交于
-
由 bors 提交于
-
由 Huon Wilson 提交于
-
由 bors 提交于
-
由 bors 提交于
I don't see a reason to encode this information in all the `extern mod` statements, it's not a precise enough version to actually provide any sort of robustness.
-
由 Daniel Micay 提交于
-
由 bors 提交于
-
由 Daniel Micay 提交于
-
由 Daniel Micay 提交于
-
由 bors 提交于
r? This is all of my scheduler work on #4419 from the last 3 weeks or so. I've had a few failed pull requests so far but I think the problems are ironed out. * TCP * The beginnings of runtime embedding APIs * Porting various corners of core to be compatible with both schedulers * libuv timer bindings * Further refinement of I/O error handling, including a new, incomplete, `read_error` condition * Incomplete refactoring to make tasks work without coroutines and user-space scheduling * Implementations of Reader/Writer extension methods * Implementations of the most important part of core::comm I'm particularly happy with how easy the [comm types on top of the scheduler](https://github.com/brson/rust/blob/io-upstream/src/libcore/rt/comm.rs). Note that these implementations do not use pipes. If anything here needs careful review though it's this code. This branch passes 95% of the run-pass tests (with `TESTARGS=--newrt`) In the next week I'll probably spend some time adding preliminary multithreading and seeing how close we are to removing the old runtime.
-