This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
r? @brson
links to issues: #7065 the race that's fixed; #7066 the perf improvement I added. There are also some minor cleanup commits here.
To measure the performance improvement from replacing the exclusive with an atomic uint, I edited the ```msgsend-ring-rw-arcs``` bench test to do a ```write_downgrade``` instead of just a ```write```, so that it stressed the code paths that accessed ```read_count```. (At first I was still using ```write``` and saw no performance difference whatsoever, whoooops.)
The bench test measures how long it takes to send 1,000,000 messages by using rwarcs to emulate pipes. I also measured the performance difference imposed by the fix to the ```access_lock``` race (which involves taking an extra semaphore in the ```cond.wait()``` path). The net result is that fixing the race imposes a 4% to 5% slowdown, but doing the atomic uint optimization gives a 6% to 8% speedup.
Note that this speedup will be most visible in read- or downgrade-heavy workloads. If an RWARC's only users are writers, the optimization doesn't matter. All the same, I think this more than justifies the extra complexity I mentioned in #7066.
The raw numbers are:
```
with xadd read count
before write_cond fix
4.18 to 4.26 us/message
with write_cond fix
4.35 to 4.39 us/message
with exclusive read count
before write_cond fix
4.41 to 4.47 us/message
with write_cond fix
4.65 to 4.76 us/message
```
The code compiles and runs under windows now, but I couldn't look up any
symbol from the current executable (dlopen(NULL)), and calling looked
up external function handles doesn't seem to work correctly under windows.
This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
This fixes the strange random crashes in compile-fail tests.
This reverts commit 96cd61ad03.
Conflicts:
src/librustc/driver/driver.rs
src/libstd/str.rs
src/libsyntax/ext/quote.rs
I would appreciate if someone could help out with the Windows code on this pull request. I tried to test it using WINE but I couldn't figure out a way to set that up.
The Str trait collects the various strings types and provides a method
for coercing to a slice, so that functions and impls can be written for
generic types containing strings (e.g. &[~str], &[&str], ...) without
having to write one for each string type (assuming that the impl only
needs a slice).
The confusing mixture of byte index and character count meant that every
use of .substr was incorrect; replaced by slice_chars which only uses
character indices. The old behaviour of `.substr(start, n)` can be emulated
via `.slice_from(start).slice_chars(0, n)`.
LLVM provides these functions as intrinsics, and will generate calls to
libc when appropriate. They are exposed in the `ptr` module as
`copy_nonoverlapping_memory`, `copy_memory` and `set_memory`.
@graydon: r?
LLVM provides these functions as intrinsics, and will generate calls to
libc when appropriate. They are exposed in the `ptr` module as
`copy_nonoverlapping_memory`, `copy_memory` and `set_memory`.
There is a pointer to #4760, which is a closed issue. The real issue is
the more general problem described in #4653. Correct the comment.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
As the title suggests, this marks all the fns on the impls on the atomic types in std::unstable::atomics as pub, which makes them significantly more usable (they are rather unusable otherwise).
r?
`std::hashmap::HashMap.insert_or_update_with()` is basically the opposite
of `find_or_insert_with()`. It inserts a given key-value pair if the key
does not already exist, or replaces the existing value with the output
of the passed function if it does.
This is useful because replicating this with existing functionality is awkward, especially with the current borrow-checker. In my own project I have code that looks like
if match map.find_mut(&key) {
None => { true }
Some(x) => { *x += 1; false }
} {
map.insert(key, 0);
}
and it took several iterations to make it look this good. The new function turns this into
map.insert_or_update_with(key, 0, |_,x| *x += 1);
Add new private hashmap function
fn mangle(&mut self,
k: K,
not_found: &fn(&K) -> V,
found: &fn(&K, &mut V)) -> uint
Rewrite find_or_insert() and find_or_insert_with() on top of mangle().
Also take the opportunity to change the return type of find_or_insert()
and find_or_insert_with() to &'a mut V. This fixes#6394.
Closes#5090 by using the excellent new generic deriving code
Promotes the unreachable code attribute to a lint attribute (instead of always being a warning)
Fixes some edge cases when creating hashmaps/hashsets and also when consuming them. (fixes#5998)
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
Calls to the libc versions of fmin and fmax were relatively slow (perhaps because they could not be inlined?). This pull request provides f32 and f64 with fmin and fmax written in Rust, and shows a significant speed increase on my system; I used https://github.com/thiez/rustray as my benchmark, with --opt-level 3 it brings the ray-tracing time down from 10.8 seconds to about 9.2, which seemed significant to me.
r?
This works with pandoc linked against highlighting-kate >= 0.5.3.8. It seems to just be a no-op with earlier versions, because I successfully ran this through `try`.
This also fixes some consistency issues (like making `Example`/`Examples` always a header and always using three tildes).
There were several old `#[doc(hidden)]` attributes in libstd and
libextra, left over from when rustdoc didn't hide private
definitions, tagged with `FIXME #3538`.
Since #3538 is now closed, I removed the `#[doc(hidden)]` attributes
as well as the FIXMEs, but I left `#[doc(hidden)]` in
libstd/task/spawn.rs and libstd/task/rt.rs since those two are
apparently `pub`, as well as in libextra/std.rc since std/extra is
`pub`.
directory to be the parent of the current-current directory,
instead of changing to the tmp directory, which was causing
issues with OS X and its /tmp => /private/tmp symlink.
mentioned in #2625.
This change makes the module more oriented around
Process values instead of having to deal with process ids
directly.
Apart from issues mentioned in #2625, other changes include:
- Changing the naming to be more consistent - Process/process
is now used instead of a mixture of Program/program and
Process/process.
- More docs/tests.
Some io/scheduler related issues remain (mentioned in #2625).
Changes the int/uint modules to all use macros instead of using the `merge` attribute. It would be nice to have #4375 resolved as well for this, but that can probably come at a later date.
Closes#4219.
This adds a lint mode for detecting unnecessary allocations on the heap. This isn't super fancy, currently it only has two rules
1. For a function's arguments, if you allocate a `[~|@]str` literal, when the type of the argument is a `&str`, emit a warning.
2. For the same case, emit warnings for boxed vectors when slices are required.
After adding the lint, I rampaged through the libraries and removed all the unnecessary allocations I could find.
* Add ARC::get method and implements the function from it.
* Add an example showing a simple use of ARC.
Update PR #6622 to avoid git noise.
I will remove the function get later.
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.
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.
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual code, leaving stubs to refer the user to
the new syntax.
This is mostly for `std::rc` and `std::arc` (but I haven't implemented it for ARC yet).
Implementing it correctly for managed boxes is *very* non-trivial. It would probably require an unholy mix of reflection and TLS.
Addressing issue #6037, this Scheme-style conditional helps to improve code clarity in instances where the `if`, `else if`, and `else` keywords obscure predicates undesirably.
Here is an example:
~~~rust
let clamped =
if x > mx { mx }
else if x < mn { mn }
else { x };
~~~
Using `cond!`, the above could be written as:
~~~rust
let clamped = cond!(
(x > mx) { mx }
(x < mn) { mn }
_ { x }
);
~~~
The optional default case is denoted by `_`.
I have altered `std::fun_treemap` to demonstrate it in use. I am definitely interested in using it for some of the numeric functions, but I will have to wait for it to reach `stage0` first.
`std::ratio` module contains `BigRational` type, but the type is not usable by following reasons.
* `Ratio::new` requires `T: Copy + Num + Ord`, but `BigInt` is not implicitly copyable, because it contains unique vector.
* `BigInt` is not implements `Num`
So, I rewrite `Ratio` as follows.
* `Ratio` requires `T: Clone + Integer + Ord`.
* `Copy` -> `Clone`: to be able to use `BigRational`
* `Num` -> `Integer`: It is incorrect that a rational number constructed by two non-integer numbers.
* `BigInt` implements `Num` and `Orderable` which are required by `Integer` bound
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
