bluss/indexmap 644
A hash table with consistent order and fast iteration; access items by key or sequence index
bluss/either 173
The enum Either with variants Left and Right is a general purpose sum type with two cases.
A flexible and redundant long-term storage system for Linux, using DM and XFS
A Rust allocator which makes sound when active, like a Geiger counter.
Automatic cfg for Rust compiler features
cuviper/android_device_htc_inc 2
WIP repo for CM Inc. Beware, this is where I break stuff...
A cross-platform `addr2line` clone written in Rust, using `gimli`
Abstract algebra for Rust.
This crate can help you sort order for files and folders whose names contain numerals.
issue closedrayon-rs/rayon
Parallel dynamic tree/graph search in Rayon
What is the idiomatic way to do the following in Rayon:
- Starting at a given state
- A function that, given a state, generates additional states
- Generate all states in parallel, collecting them (e.g. into a vector).
The simplest way is to use an Arc<RwLock<Vec<State>>>
and use a ThreadPoolBuilder.install(|| reach_state(first_state))
, where reach_state
will generate the sub-states, then par_iter
on each generated sub-state, pushing it into the vector and recursively invoke reach_state
on it.
This works. However, this consumes large amounts of stack stack due to the recursive calls to reach_state
.
Is there an idiomatic way to setup a queue of items, and tell Rayon to process items in parallel from the queue, where this processing may add new items to the queue? This pattern is common in graph algorithms (basically, parallel variants of Dijkstra's algorithm, with either an explicit input graph or a graph that is being built dynamically as it is being searched).
The underlying libraries (e.g. crossbeam) can obviously do this, but with nothing like Rayon's ease of use.
closed time in 10 minutes
orenbenkikiissue commentrayon-rs/rayon
Parallel dynamic tree/graph search in Rayon
@cuviper - ah, scope seems to do almost exactly what I need (with a few lines of code). I'll give it a try. Thanks!
comment created time in 28 minutes
issue commentrayon-rs/rayon
Parallel dynamic tree/graph search in Rayon
@wagnerf42 - thanks for the code. This got complex pretty fast... Especially compared to "replace
iter
withpar_iter
" :-)
well. the inner workings are not easy but the use is easy.
here is an example with a tree traversal. (i fixed a bug btw)
If you look at the main it's just a call to descendant
in order to get the parallel iterator.
the descendant
function is literally what you wanted.
use rayon::iter::plumbing::{bridge_unindexed, Folder, UnindexedConsumer, UnindexedProducer};
use rayon::prelude::*;
use std::collections::VecDeque;
use std::fmt::Debug;
use std::iter::once;
use std::marker::PhantomData;
struct TreeProducer<'b, S, B, I> {
to_explore: VecDeque<Vec<S>>, // invariant: no one is empty here
seen: Vec<S>,
breed: &'b B,
phantom: PhantomData<I>,
}
impl<'b, S, B, I> UnindexedProducer for TreeProducer<'b, S, B, I>
where
S: Send + Debug,
B: Fn(&S) -> I + Send + Sync,
I: Iterator<Item = S> + Send,
{
type Item = S;
fn split(mut self) -> (Self, Option<Self>) {
// explore while front is of size one.
while self
.to_explore
.front()
.map(|f| f.len() == 1)
.unwrap_or(false)
{
let front_node = self.to_explore.pop_front().unwrap().pop().unwrap();
let next_to_explore: Vec<_> = (self.breed)(&front_node).collect();
if !next_to_explore.is_empty() {
self.to_explore.push_back(next_to_explore);
}
self.seen.push(front_node);
}
// now take half of the front.
let f = self.to_explore.front_mut();
let right_children = f.map(|f| {
let n = f.len() / 2;
let mut c = Vec::with_capacity(n);
for _ in 0..n {
c.push(f.pop().unwrap());
}
c
});
let right = right_children.map(|c| TreeProducer {
to_explore: once(c).collect(),
seen: Vec::new(),
breed: self.breed,
phantom: PhantomData,
}); //TODO: if nothing we could split seen
eprintln!("right: {}", right.is_some());
(self, right)
}
fn fold_with<F>(self, mut folder: F) -> F
where
F: Folder<Self::Item>,
{
// start by consuming everything seen
for s in self.seen {
folder = folder.consume(s);
if folder.full() {
return folder;
}
}
// now do all remaining explorations
for mut e in self.to_explore {
while let Some(s) = e.pop() {
e.extend((self.breed)(&s));
folder = folder.consume(s);
if folder.full() {
return folder;
}
}
}
folder
}
}
struct TreeIter<S, B, I> {
initial_state: S,
breed: B,
phantom: PhantomData<I>,
}
impl<S, B, I> ParallelIterator for TreeIter<S, B, I>
where
S: Send + Debug,
B: Fn(&S) -> I + Send + Sync,
I: Iterator<Item = S> + Send,
{
type Item = S;
fn drive_unindexed<C>(self, consumer: C) -> C::Result
where
C: UnindexedConsumer<Self::Item>,
{
let producer = TreeProducer {
to_explore: once(vec![self.initial_state]).collect(),
seen: Vec::new(),
breed: &self.breed,
phantom: PhantomData,
};
bridge_unindexed(producer, consumer)
}
}
fn descendants<S, B, I>(root: S, breed: B) -> TreeIter<S, B, I>
where
S: Send,
B: Fn(&S) -> I + Send + Sync,
I: Iterator<Item = S> + Send,
{
TreeIter {
initial_state: root,
breed,
phantom: PhantomData,
}
}
#[derive(Debug)]
struct Node {
content: u32,
left: Option<Box<Node>>,
right: Option<Box<Node>>,
}
fn main() {
let t = Node {
content: 10,
left: Some(Box::new(Node {
content: 3,
left: None,
right: None,
})),
right: Some(Box::new(Node {
content: 14,
left: None,
right: Some(Box::new(Node {
content: 18,
left: None,
right: None,
})),
})),
};
let v: Vec<&Node> = descendants(&t, |r| {
r.left
.as_ref()
.into_iter()
.chain(r.right.as_ref())
.map(|n| &**n)
})
.collect();
eprintln!("v: {:?}", v);
}
comment created time in an hour
issue commentrayon-rs/rayon
Parallel dynamic tree/graph search in Rayon
@wagnerf42 - thanks for the code. This got complex pretty fast... Especially compared to "replace iter
with par_iter
" :-)
I don't suppose there's some crate somewhere that has something similar to:
fn par_deque<T>(first: T, task: Fn(T, &RwLock<VecDeque<T>>);
So I could write something along the lines of:
par_deque(first_data, |data, pending| {
... do stuff with the data ...
pending.write().unwrap().push_back(... more data ...);
... do stuff with the data ...
pending.write().unwrap().push_back(... even more data ...);
... etc. ...
});
comment created time in 4 hours
pull request commentrust-num/num-traits
Add support for euclidean division and modulation
@cuviper Is there anything left in this PR that needs to be changed? We'd really like this functionality for rust-gpu
so that we can support rem_euclid
on SPIR-V platforms. 🙂
comment created time in 5 hours
issue commentrayon-rs/rayon
Parallel dynamic tree/graph search in Rayon
hi,
here is one:
use rayon::iter::plumbing::{bridge_unindexed, Folder, UnindexedConsumer, UnindexedProducer};
use rayon::prelude::*;
use std::collections::VecDeque;
use std::fmt::Debug;
use std::iter::once;
use std::marker::PhantomData;
struct TreeProducer<'b, S, B, I> {
to_explore: VecDeque<Vec<S>>, // invariant: no one is empty here
seen: Vec<S>,
breed: &'b B,
phantom: PhantomData<I>,
}
impl<'b, S, B, I> UnindexedProducer for TreeProducer<'b, S, B, I>
where
S: Send + Debug,
B: Fn(&S) -> I + Send + Sync,
I: Iterator<Item = S> + Send,
{
type Item = S;
fn split(mut self) -> (Self, Option<Self>) {
// explore while front is of size one.
while self
.to_explore
.front()
.map(|f| f.len() == 1)
.unwrap_or(false)
{
let front_node = self.to_explore.pop_front().unwrap().pop().unwrap();
self.to_explore
.push_back((self.breed)(&front_node).collect());
self.seen.push(front_node);
}
// now take half of the front.
let f = self.to_explore.front_mut();
let right_children = f.map(|f| {
let n = f.len() / 2;
let mut c = Vec::with_capacity(n);
for _ in 0..n {
c.push(f.pop().unwrap());
}
c
});
let right = right_children.map(|c| TreeProducer {
to_explore: once(c).collect(),
seen: Vec::new(),
breed: self.breed,
phantom: PhantomData,
}); //TODO: if nothing we could split seen
(self, right)
}
fn fold_with<F>(self, mut folder: F) -> F
where
F: Folder<Self::Item>,
{
// start by consuming everything seen
for s in self.seen {
folder = folder.consume(s);
if folder.full() {
return folder;
}
}
// now do all remaining explorations
for mut e in self.to_explore {
while let Some(s) = e.pop() {
e.extend((self.breed)(&s));
folder = folder.consume(s);
if folder.full() {
return folder;
}
}
}
folder
}
}
struct TreeIter<S, B, I> {
initial_state: S,
breed: B,
phantom: PhantomData<I>,
}
impl<S, B, I> ParallelIterator for TreeIter<S, B, I>
where
S: Send + Debug,
B: Fn(&S) -> I + Send + Sync,
I: Iterator<Item = S> + Send,
{
type Item = S;
fn drive_unindexed<C>(self, consumer: C) -> C::Result
where
C: UnindexedConsumer<Self::Item>,
{
let producer = TreeProducer {
to_explore: once(vec![self.initial_state]).collect(),
seen: Vec::new(),
breed: &self.breed,
phantom: PhantomData,
};
bridge_unindexed(producer, consumer)
}
}
fn descendants<S, B, I>(root: S, breed: B) -> TreeIter<S, B, I>
where
S: Send,
B: Fn(&S) -> I + Send + Sync,
I: Iterator<Item = S> + Send,
{
TreeIter {
initial_state: root,
breed,
phantom: PhantomData,
}
}
fn main() {
let v: Vec<u32> = descendants(10, |e| {
once(e / 2).chain(once(e / 2 + 1)).filter(|&e| e > 2)
})
.collect();
eprintln!("v: {:?}", v);
}
note that you don't necessarily need to collect. if you do it also could be more efficient to fold into Vec
and collect into LinkedList<Vec>
comment created time in 6 hours
startedcuviper/autocfg
started time in 7 hours
startedcuviper/alloc_geiger
started time in 7 hours
issue openedrayon-rs/rayon
Parallel dynamic tree/graph search in Rayon
What is the idiomatic way to do the following in Rayon:
- Starting at a given state
- A function that, given a state, generates additional states
- Generate all states in parallel, collecting them (e.g. into a vector).
The simplest way is to use an Arc<RwLock<Vec<State>>>
and use a ThreadPoolBuilder.install(|| reach_state(first_state))
, where reach_state
will generate the sub-states, then par_iter
on each generated sub-state, pushing it into the vector and recursively invoke reach_state
on it.
This works. However, this consumes large amounts of stack stack due to the recursive calls to reach_state
.
Is there an idiomatic way to setup a queue of items, and tell Rayon to process items in parallel from the queue, where this processing may add new items to the queue? This pattern is common in graph algorithms (basically, parallel variants of Dijkstra's algorithm, with either an explicit input graph or a graph that is being built dynamically as it is being searched).
The underlying libraries (e.g. crossbeam) can obviously do this, but with nothing like Rayon's ease of use.
created time in 12 hours
startedcuviper/ssh-pageant
started time in 17 hours
startedcuviper/rust-libprobe
started time in a day
pull request commentrust-lang/rustc-rayon
Add bounds for WorkerLocal's Send and Sync
Note that this causes compile failures in rustc_middle currently:
Checking rustc_builtin_macros v0.0.0 (/home/joshua/rustc3/compiler/rustc_builtin_macros)
error[E0277]: `*mut u8` cannot be sent between threads safely
--> compiler/rustc_middle/src/ty/mod.rs:2788:14
|
2788 | .for_each(|&body_id| f(self.hir().body_owner_def_id(body_id)));
| ^^^^^^^^ `*mut u8` cannot be sent between threads safely
|
= help: within `rustc_arena::DropType`, the trait `Send` is not implemented for `*mut u8`
= note: required because it appears within the type `rustc_arena::DropType`
= note: required because of the requirements on the impl of `Send` for `Unique<rustc_arena::DropType>`
= note: required because it appears within the type `RawVec<rustc_arena::DropType>`
= note: required because it appears within the type `Vec<rustc_arena::DropType>`
= note: required because of the requirements on the impl of `Send` for `RefCell<Vec<rustc_arena::DropType>>`
= note: required because it appears within the type `DropArena`
= note: required because it appears within the type `Arena<'tcx>`
= note: required because of the requirements on the impl of `std::marker::Sync` for `WorkerLocal<Arena<'tcx>>`
= note: required because it appears within the type `&'tcx WorkerLocal<Arena<'tcx>>`
= note: required because it appears within the type `GlobalCtxt<'tcx>`
= note: required because it appears within the type `&'tcx GlobalCtxt<'tcx>`
= note: required because it appears within the type `context::TyCtxt<'tcx>`
= note: required because it appears within the type `&context::TyCtxt<'tcx>`
= note: required because it appears within the type `[closure@compiler/rustc_middle/src/ty/mod.rs:2788:23: 2788:74]`
error[E0277]: `*mut u8` cannot be sent between threads safely
--> compiler/rustc_middle/src/ty/context.rs:1738:13
|
1738 | sync::assert_sync::<ImplicitCtxt<'_, '_>>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `*mut u8` cannot be sent between threads safely
|
::: /home/joshua/rustc3/compiler/rustc_data_structures/src/sync.rs:420:32
|
420 | pub fn assert_sync<T: ?Sized + Sync>() {}
| ---- required by this bound in `assert_sync`
|
= help: within `rustc_arena::DropType`, the trait `Send` is not implemented for `*mut u8`
= note: required because it appears within the type `rustc_arena::DropType`
= note: required because of the requirements on the impl of `Send` for `Unique<rustc_arena::DropType>`
= note: required because it appears within the type `RawVec<rustc_arena::DropType>`
= note: required because it appears within the type `Vec<rustc_arena::DropType>`
= note: required because of the requirements on the impl of `Send` for `RefCell<Vec<rustc_arena::DropType>>`
= note: required because it appears within the type `DropArena`
= note: required because it appears within the type `Arena<'_>`
= note: required because of the requirements on the impl of `std::marker::Sync` for `WorkerLocal<Arena<'_>>`
= note: required because it appears within the type `&WorkerLocal<Arena<'_>>`
= note: required because it appears within the type `GlobalCtxt<'_>`
= note: required because it appears within the type `&GlobalCtxt<'_>`
= note: required because it appears within the type `context::TyCtxt<'_>`
= note: required because it appears within the type `ImplicitCtxt<'_, '_>`
error: aborting due to 2 previous errors
comment created time in a day
push eventrust-lang/llvm-project
commit sha 8a7661e665f60f47829646a881dcac10f1416469
[rust] Link socket/nsl on Solaris/Illumos llvm-jitlink and llvm-jitlink-executor use APIs that require the socket and nsl libraries on SunOS.
push time in a day
issue commentbluss/indexmap
No guarantees for the uniformity of the shuffle with such an ordering function in sort. There should be literature on it; IUUC it is biased. Sorting by a cached random key should be the way to go if needed.
comment created time in a day
push eventrust-lang/llvm-project
commit sha a3545a0b0777da773c5e2370622579c44a8f0f63
[Analysis][LoopVectorize] do not form reductions of pointers This is a fix for https://llvm.org/PR49215 either before/after we make a verifier enhancement for vector reductions with D96904. I'm not sure what the current thinking is for pointer math/logic in IR. We allow icmp on pointer values. Therefore, we match min/max patterns, so without this patch, the vectorizer could form a vector reduction from that sequence. But the LangRef definitions for min/max and vector reduction intrinsics do not allow pointer types: https://llvm.org/docs/LangRef.html#llvm-smax-intrinsic https://llvm.org/docs/LangRef.html#llvm-vector-reduce-umax-intrinsic So we would crash/assert at some point - either in IR verification, in the cost model, or in codegen. If we do want to allow this kind of transform, we will need to update the LangRef and all of those parts of the compiler. Differential Revision: https://reviews.llvm.org/D97047 (cherry picked from commit 5b250a27ec7822aa0a32abb696cb16c2cc60149c)
commit sha 3444f052006ca2b19052a4599dd9001b01088c25
[clang][Driver][OpenBSD] libcxx also requires pthread (cherry picked from commit b42d57a100c5df6ace68f686f5adaabeafe8a0f6)
commit sha 76e4c93ea42b3d23907611d14e347bfeae8d4b0a
clang-extra: fix incorrect use of std::lock_guard by adding variable name (identified by MSVC [[nodiscard]] error) `std::lock_guard` is an RAII class that needs a variable name whose scope determines the guard's lifetime. This particular usage lacked a variable name, meaning the guard could be destroyed before the line that it was indented to protect. This line was identified by building clang with the latest MSVC preview release, which declares the std::lock_guard constructor to be `[[nodiscard]]` to draw attention to such issues. Reviewed By: kadircet Differential Revision: https://reviews.llvm.org/D95725 (cherry picked from commit 0b70c86e2007d3f32968f0a7d9efe8eab3bf0f0a)
commit sha 8eeb3d99933a3246f2d850b807cf54f11a3a8dce
[clangd] Rename: merge index/AST refs path-insensitively where needed If you have c:\foo open, and C:\foo indexed (case difference) then these need to be considered the same file. Otherwise we emit edits to both, and editors do... something that isn't pretty. Maybe more centralized normalization is called for, but it's not trivial to do this while also being case-preserving. see https://github.com/clangd/clangd/issues/108 Fixes https://github.com/clangd/clangd/issues/665 Differential Revision: https://reviews.llvm.org/D95759 (cherry picked from commit b63cd4db915c08e0cb4cf668a18de24b67f2c44c)
commit sha d8404633401509936600b60274b72fc03f11f040
[clangd] Treat paths case-insensitively depending on the platform Path{Match,Exclude} and MountPoint were checking paths case-sensitively on all platforms, as with other features, this was causing problems on windows. Since users can have capital drive letters on config files, but editors might lower-case them. This patch addresses that issue by: - Creating regexes with case-insensitive matching on those platforms. - Introducing a new pathIsAncestor helper, which performs checks in a case-correct manner where needed. Differential Revision: https://reviews.llvm.org/D96690 (cherry picked from commit ecea7218fb9b994b26471e9877851cdb51a5f1d4)
commit sha b60110090a942078bbacf71db166c2353c340413
[clangd] Fix windows buildbots after ecea7218fb9b994b26471e9877851cdb51a5f1d4 (cherry picked from commit cdef5a7161767c2c4b3b7cb2542cf1d29b6d4a09)
commit sha 67d6fbe0f157ba78e8131964d60155dc1090f409
[clangd] Release notes for 12.x
commit sha a750a2329c433e598f7fc9655d625c5ebb6bc400
clang-tidy: Disable cppcoreguidlines-prefer-member-initializer check Fixes https://llvm.org/PR49318
commit sha da7fa7457800394d610e8cbd6befe7bc944ca7d0
[JumpThreading] Clone noalias.scope.decl when threading blocks When cloning instructions during jump threading, also clone and adapt any declared scopes. This is primarily important when threading loop exits, because we'll end up with two dominating scope declarations in that case (at least after additional loop rotation). This addresses a loose thread from https://reviews.llvm.org/rG2556b413a7b8#975012. Differential Revision: https://reviews.llvm.org/D97154 (cherry picked from commit 5e7e499b912d2c9ebaa91b5783ca123dbedeabcc)
commit sha a92ceea91116e7b95d23eff634507fa2cff86ef2
Revert "[llvm-cov] reset executation count to 0 after wrapped segment" This reverts commit e3df9471750935876bd2bf7da93ccf0eacca8592. This commit caused regressions in coverage generation for both Rust and Swift. We're reverting this in the release/12.x branch until we have a proper fix in trunk. http://llvm.org/PR49297
commit sha 99df95fd910becbcf89dd6f17f1e259353a72d27
[clang][CodeComplete] Fix crash on ParenListExprs Fixes https://github.com/clangd/clangd/issues/676. Differential Revision: https://reviews.llvm.org/D95935
commit sha 7fc6c60608e416e7f8f5c194768c6dd511449c1b
[clang][CodeComplete] Ensure there are no crashes when completing with ParenListExprs as LHS Differential Revision: https://reviews.llvm.org/D96950
commit sha 1c0a0c727eaeee7d7283f9dabe861e69881764c4
[12.0.0][llvm-symbolizer][test] Fix test broken after cherry-pick See bug https://bugs.llvm.org/show_bug.cgi?id=49227. The cherry-pick 0d4f8a3f364f introduced a test failure, as the test included use of a feature that was only recently added to lit and isn't in the release branch. This patch fixes up the test to manage without this lit change. Reviewed By: tstellar, MaskRay Differential Revision: https://reviews.llvm.org/D97272
commit sha eccac5a8aec92c995f0f8ef090ba4142e0334b46
Add auto-upgrade support for annotation intrinsics The llvm.ptr.annotation and llvm.var.annotation intrinsics were changed since the 11.0 release to add an additional parameter. This patch auto-upgrades IR containing the four-parameter versions of these intrinsics, adding a null pointer as the fifth argument. Differential Revision: https://reviews.llvm.org/D95993 (cherry picked from commit 9a827906cb95e7c3ae94627558da67b47ffde249)
commit sha 06e5dec59e0b53c5a99fc8d2ff30960b24c4f1b6
Fix test failures after a92ceea91116e7b95d23eff634507fa2cff86ef2
commit sha d56d2c8863b6ae3637b6261c32ea9479d8e1e2d6
[libc++] Fix extern template test failing on Windows See https://reviews.llvm.org/D94718#2521489 for details. (cherry picked from commit 90407b16b1d3e38f1360b6a24ceab801ab9cefc1)
commit sha 4918a3d138b907a571f496661b5367e090e1e8bb
[libc++] Fix extern-templates.sh.cpp test on Linux (cherry picked from commit bf5941afcda3ac6570ba25165758869287491e0d)
commit sha e0e6b1e39e7e402cd74a8bf98a2728efbe38310e
ReleaseNotes: add lld/ELF notes Differential Revision: https://reviews.llvm.org/D97113
commit sha 26bca233fae9ccce51f71d1be84c51fa61785142
Merge remote-tracking branch 'upstream/release/12.x' into rustc/12.0-2021-02-03
push time in a day
push eventrust-lang/llvm-project
commit sha c8a8465ee9d86c081657819109a058845250d3fd
Revert "[Support] PR42623: Avoid setting the delete-on-close bit if a TempFile doesn't reside on a local drive" This reverts commit 79657e2339b58bc01fe1b85a448bb073d57d90bb. The change regressed on Windows 7 -- rust-lang/rust#81051
push time in 2 days
PR merged rust-lang/llvm-project
… TempFile doesn't reside on a local drive"
This reverts commit 79657e2339b58bc01fe1b85a448bb073d57d90bb.
The change regressed on Windows 7 -- rust-lang/rust#81051
pr closed time in 2 days
push eventrust-lang/llvm-project
commit sha 96ae8953e4938d39c4173dd189f268459fff8c02
Revert "[Support] PR42623: Avoid setting the delete-on-close bit if a TempFile doesn't reside on a local drive" This reverts commit 6ec777c2f6496b4fe1d78cc6d6871a3dc931a185, which was cherry picked to 11.x from 79657e2339b58bc01fe1b85a448bb073d57d90bb. The change regressed on Windows 7 -- rust-lang/rust#81051
push time in 2 days
PR merged rust-lang/llvm-project
… TempFile doesn't reside on a local drive"
This reverts commit 6ec777c2f6496b4fe1d78cc6d6871a3dc931a185, which was cherry picked to 11.x from 79657e2339b58bc01fe1b85a448bb073d57d90bb.
The change regressed on Windows 7 -- rust-lang/rust#81051
pr closed time in 2 days
pull request commentrust-lang/llvm-project
Revert "[Support] PR42623: Avoid setting the delete-on-close bit if a…
We need the same revert for LLVM12, no?
I think its fine to backport #90 too, it is only relevant to unstable functionality (-Csplit-debuginfo=packed
requires -Z unstable-options
)
comment created time in 3 days
issue commentbluss/indexmap
I suppose if the item already exists at any index, you want it moved to the new location?
For my particular use-case I wish to keep the item at the current index, but I need to modify it as well. However, performance is not very critical at all, so I am completely okay with handling this by doing a second lookup.
I think you are right, that the most reasonable behavior would be to move the item it.
I guess the way to completely support my use-case would be to add shift_insert
methods to both VacantEntry
and OccupiedEntry
, but I am not sure if this is worth the added complexity.
comment created time in 3 days
issue closedrayon-rs/rayon
I wrote this simple snippet to test the panic_handler
use ndarray::{Array2, Array3, ArrayView2, Axis};
use rayon::ThreadPoolBuilder;
let panic_handler = |_| {
println!("############ Test ############");
};
ThreadPoolBuilder::new().num_threads(4).panic_handler(panic_handler).build_global().unwrap();
let data = Array3::zeros((100, 100, 100));
Zip::from(data.axis_iter(Axis(2))).par_apply(|slice: ArrayView2<f32>| {
panic!("Hola");
});
The threads do panic. I see several errors messages that look like
thread 'thread 'thread 'thread '<unnamed><unnamed><unnamed><unnamed>' panicked at '' panicked at '' panicked at '' panicked at 'HolaHolaHolaHola', ', ', ', test.rstest.rstest.rstest.rs::::10101010::::9999
idem
...
However, I never see my panic_handler
message. Why? Isn't this exactly the goal of a panic_handler?
Moreover, why do I see that many error messages? I understand that each thread must end or panic before quitting, but it looks like rayon is trying and trying again to run what I asked in Zip::from
. Can I ask rayon to never retry? To leave as soon as there an error?
closed time in 3 days
nilgoyetteissue commentrayon-rs/rayon
Oh, ok, it's clearer now :) Thank you!
comment created time in 3 days
pull request commentrust-num/num-traits
PrimInt: add reverse_bits() method
I added @tspiteri's fallback behind an autocfg gate, but I haven't been able to confirm whether it actually works as designed - I can't find any traces of the fallback method in the output binary (with stable rustc) even if I delete the method in the trait implementation entirely.
comment created time in 3 days
issue commentbluss/indexmap
I really like that sort_by
idea! Here's an example for future readers:
use indexmap::IndexSet;
use rand::{
distributions::{Distribution, Standard},
Rng,
};
use std::cmp::Ordering;
#[derive(Debug)]
struct RandomOrdering(Ordering);
impl Into<Ordering> for RandomOrdering {
fn into(self) -> Ordering {
self.0
}
}
impl Distribution<RandomOrdering> for Standard {
fn sample<R: Rng + ?Sized>(&self, rng: &mut R) -> RandomOrdering {
RandomOrdering(match rng.gen_range(0..2) {
0 => Ordering::Less,
1 => Ordering::Equal,
_ => Ordering::Greater,
})
}
}
fn main() {
let mut letters: IndexSet<char> = ('a'..='z').collect();
println!("{:?}", letters);
letters.sort_by(|_, _| rand::random::<RandomOrdering>().into());
println!("{:?}", letters);
}
comment created time in 4 days
issue commentrust-num/num-bigint
How could I get/set n-th bit of `BigInt`?
@cuviper @janmarthedal Thank you so much. Today, I confirmed that my program got faster using your bit
and set_bit
. It helped me a lot.
comment created time in 4 days
PR merged rayon-rs/rayon
- cgmath 0.17 -> 0.18
- glium 0.28 -> 0.29
- num 0.2 -> 0.3
- rand 0.7 -> 0.8
- rand_xorshift 0.2 -> 0.3
pr closed time in 4 days
push eventrayon-rs/rayon
commit sha aa063b1c00cfa1fa74b8193f657998fba46c45b3
Update test/demo dependencies - cgmath 0.17 -> 0.18 - glium 0.28 -> 0.29 - num 0.2 -> 0.3 - rand 0.7 -> 0.8 - rand_xorshift 0.2 -> 0.3
commit sha 6808e3964705f9a6aa92f871664fbe8d14085f74
Merge #829 829: Update test/demo dependencies r=cuviper a=cuviper - cgmath 0.17 -> 0.18 - glium 0.28 -> 0.29 - num 0.2 -> 0.3 - rand 0.7 -> 0.8 - rand_xorshift 0.2 -> 0.3 Co-authored-by: Josh Stone <cuviper@gmail.com>
push time in 4 days
pull request commentrayon-rs/rayon
Build succeeded:
- Check (1.36.0)
- Demo (nightly)
- Demo (stable)
- Format
- Test (macos-latest, beta)
- Test (macos-latest, nightly)
- Test (macos-latest, stable)
- Test (ubuntu-latest, beta)
- Test (ubuntu-latest, nightly)
- Test (ubuntu-latest, stable)
- Test (ubuntu-latest, stable-i686)
- Test (windows-latest, beta)
- Test (windows-latest, nightly)
- Test (windows-latest, stable)
- WebAssembly
comment created time in 4 days
push eventrayon-rs/rayon
commit sha aa063b1c00cfa1fa74b8193f657998fba46c45b3
Update test/demo dependencies - cgmath 0.17 -> 0.18 - glium 0.28 -> 0.29 - num 0.2 -> 0.3 - rand 0.7 -> 0.8 - rand_xorshift 0.2 -> 0.3
commit sha 6808e3964705f9a6aa92f871664fbe8d14085f74
Merge #829 829: Update test/demo dependencies r=cuviper a=cuviper - cgmath 0.17 -> 0.18 - glium 0.28 -> 0.29 - num 0.2 -> 0.3 - rand 0.7 -> 0.8 - rand_xorshift 0.2 -> 0.3 Co-authored-by: Josh Stone <cuviper@gmail.com>
push time in 4 days