profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/cuviper/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

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.

agrover/froyo 59

A flexible and redundant long-term storage system for Linux, using DM and XFS

cuviper/alloc_geiger 37

A Rust allocator which makes sound when active, like a Geiger counter.

cuviper/autocfg 35

Automatic cfg for Rust compiler features

cuviper/android_device_htc_inc 2

WIP repo for CM Inc. Beware, this is where I break stuff...

cuviper/addr2line 0

A cross-platform `addr2line` clone written in Rust, using `gimli`

cuviper/alga 0

Abstract algebra for Rust.

cuviper/alphanumeric-sort 0

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

orenbenkiki

issue 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!

orenbenkiki

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 with par_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);
}
orenbenkiki

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. ...
});
orenbenkiki

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. 🙂

SparrowLii

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>

orenbenkiki

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
ammaraskar

comment created time in a day

push eventrust-lang/llvm-project

Nikita Popov

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.

view details

push time in a day

issue commentbluss/indexmap

Shuffling an IndexSet

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.

lovesegfault

comment created time in a day

push eventrust-lang/llvm-project

Sanjay Patel

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)

view details

Brad Smith

commit sha 3444f052006ca2b19052a4599dd9001b01088c25

[clang][Driver][OpenBSD] libcxx also requires pthread (cherry picked from commit b42d57a100c5df6ace68f686f5adaabeafe8a0f6)

view details

Conrad Poelman

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)

view details

Sam McCall

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)

view details

Kadir Cetinkaya

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)

view details

Kadir Cetinkaya

commit sha b60110090a942078bbacf71db166c2353c340413

[clangd] Fix windows buildbots after ecea7218fb9b994b26471e9877851cdb51a5f1d4 (cherry picked from commit cdef5a7161767c2c4b3b7cb2542cf1d29b6d4a09)

view details

Sam McCall

commit sha 67d6fbe0f157ba78e8131964d60155dc1090f409

[clangd] Release notes for 12.x

view details

Tom Stellard

commit sha a750a2329c433e598f7fc9655d625c5ebb6bc400

clang-tidy: Disable cppcoreguidlines-prefer-member-initializer check Fixes https://llvm.org/PR49318

view details

Nikita Popov

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)

view details

Tom Stellard

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

view details

Kadir Cetinkaya

commit sha 99df95fd910becbcf89dd6f17f1e259353a72d27

[clang][CodeComplete] Fix crash on ParenListExprs Fixes https://github.com/clangd/clangd/issues/676. Differential Revision: https://reviews.llvm.org/D95935

view details

Kadir Cetinkaya

commit sha 7fc6c60608e416e7f8f5c194768c6dd511449c1b

[clang][CodeComplete] Ensure there are no crashes when completing with ParenListExprs as LHS Differential Revision: https://reviews.llvm.org/D96950

view details

Tom Stellard

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

view details

Andy Kaylor

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)

view details

Nikita Popov

commit sha 06e5dec59e0b53c5a99fc8d2ff30960b24c4f1b6

Fix test failures after a92ceea91116e7b95d23eff634507fa2cff86ef2

view details

Louis Dionne

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)

view details

Louis Dionne

commit sha 4918a3d138b907a571f496661b5367e090e1e8bb

[libc++] Fix extern-templates.sh.cpp test on Linux (cherry picked from commit bf5941afcda3ac6570ba25165758869287491e0d)

view details

Fangrui Song

commit sha e0e6b1e39e7e402cd74a8bf98a2728efbe38310e

ReleaseNotes: add lld/ELF notes Differential Revision: https://reviews.llvm.org/D97113

view details

Nikita Popov

commit sha 26bca233fae9ccce51f71d1be84c51fa61785142

Merge remote-tracking branch 'upstream/release/12.x' into rustc/12.0-2021-02-03

view details

push time in a day

push eventrust-lang/llvm-project

Josh Stone

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

view details

push time in 2 days

PR merged rust-lang/llvm-project

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

+0 -14

1 comment

1 changed file

cuviper

pr closed time in 2 days

push eventrust-lang/llvm-project

Josh Stone

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

view details

push time in 2 days

PR merged rust-lang/llvm-project

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

+0 -14

3 comments

1 changed file

cuviper

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)

cuviper

comment created time in 3 days

issue commentbluss/indexmap

Feature request: shift_insert

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.

TethysSvensson

comment created time in 3 days

issue closedrayon-rs/rayon

panic handler behavior

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

nilgoyette

issue commentrayon-rs/rayon

panic handler behavior

Oh, ok, it's clearer now :) Thank you!

nilgoyette

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.

Xiretza

comment created time in 3 days

issue commentbluss/indexmap

Shuffling an IndexSet

I really like that sort_by idea! Here's an example for future readers:

Rust Playground

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);
}
lovesegfault

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.

kazunetakahashi

comment created time in 4 days

PR merged rayon-rs/rayon

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
+382 -530

2 comments

13 changed files

cuviper

pr closed time in 4 days

push eventrayon-rs/rayon

Josh Stone

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

view details

bors[bot]

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>

view details

push time in 4 days

push eventrayon-rs/rayon

Josh Stone

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

view details

bors[bot]

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>

view details

push time in 4 days