`max_by` method returns the element that gives the maximum value from the specfied function.
`max_by`/`min_by` are convenient when you want to get the value which has greatest/smallest scores.
Inspired by [ruby's Enumerable module](http://ruby-doc.org/core-2.0/Enumerable.html).
Mostly just low-haning fruit, i.e. function arguments that were @ even
though & would work just as well.
Reduces librustc.so size by 200k when compiling without -O, by 100k when
compiling with -O.
Mostly just low-haning fruit, i.e. function arguments that were @ even
though & would work just as well.
Reduces librustc.so size by 200k when compiling without -O, by 100k when
compiling with -O.
r? @brson (or @graydon if available) rustpkg/api.rs provides functions intended for package scripts to call.
It will probably need more functionality added to it later, but this is
a start.
Added a test case checking that a package script can use the API.
Closes#6401
... through yields
This avoids the following pathological scenario that makes threadring OOM:
1) task calls C using fast_ffi, borrowing a big stack from the scheduler.
2) task returns from C and places the big stack on the task-local stack segment list
3) task calls further Rust functions that require growing the stack, and for this reuses the big stack
4) task yields, failing to return the big stack to the scheduler.
5) repeat 500+ times and OOM
(reopening after incoming fallout. *do not r+*. broken)
Both extra::treemap::TreeMap and extra::treemap::TreeSet have
corresponding iterators TreeMapIterator and TreeSetIterator.
Unfortunately, the tests and extra::serialize use the older .each.
Update all the dependent code, and remove .each.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
This avoids the following pathological scenario that makes threadring OOM:
1) task calls C using fast_ffi, borrowing a big stack from the scheduler.
2) task returns from C and places the big stack on the task-local stack segment list
3) task calls further Rust functions that require growing the stack, and for this reuses the big stack
4) task yields, failing to return the big stack to the scheduler.
5) repeat 500+ times and OOM
Conflicts:
src/rt/rust_task.cpp
Add method .move_from() to MutableVector, which consumes another vector
and moves elements into the receiver.
Add new trait MutableCloneableVector with one method .copy_from(), which
clones elements from another vector into the receiver.
Remove PriorityQueue::each and replace it with PriorityQueue::iter,
which ultimately calls into vec::VecIterator via PriorityQueueIterator.
Implement iterator::Iterator for PriorityQueueIterator. Now you should
be able to do:
extern mod extra;
let mut pq = extra::priority_queue::PriorityQueue::new();
pq.push(5);
pq.push(6);
pq.push(3);
for pq.iter().advance |el| {
println(fmt!("%d", *el));
}
just like you iterate over vectors, hashmaps, hashsets etc. Note that
the iteration order is arbitrary (as before with PriorityQueue::each),
and _not_ the order you get when you pop() repeatedly.
Add an in-file test to guard this.
Reported-by: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Move all the colors into a nested mod named color instead of prefixing
with "color_".
Define a new type color::Color, and make this a u16 instead of a u8 (to
allow for easy comparisons against num_colors, which is a u16).
Remove color_supported and replace it with num_colors.
Teach fg() and bg() to "dim" bright colors down to the normal intensity
if num_colors isn't high enough.
Remove unnecessary copies, and fix a bug where a terminfo parse failure
would try to use the wrong error and end up failing.
flat_map_ produces an iterator that maps each element to an iterator,
and yields the elements of the produced iterators.
This is the monadic bind :: M a -> (a -> M b) -> M b for iterators.
Named just like the vec method, but with a trailing underline until the
method resolution bug is resolved.
We discussed the name chain_map, but I decided to go with flat_map_ for consistency with vec.
Since it.map(f).flatten() would be the same as it.flat_map(f), we could choose
to just implement a flatten method instead. Either way the possibilities are the same but flat_map is more convenient.
This allows macros to both be conditionally defined, and expand
to items with #[cfg]'s.
This seems to have a performance improvement, e.g. for `std`:
```
# Before
time: 1.660 s expansion
time: 0.125 s configuration
# After
time: 0.080 s configuration 1
time: 1.127 s expansion
time: 0.132 s configuration 2
```
And for `extra`:
```
# Before
time: 0.593 s expansion
time: 0.062 s configuration
# After
time: 0.047 s configuration 1
time: 0.147 s expansion
time: 0.058 s configuration 2
```
(This seems a little peculiar, but it is possibly because the expansion AST traversal is very slow, so removing as much as possible as early as possible has big benefits.)
