These are chat archives for rust-lang/rust

26th
Jun 2018
Sylwester Rąpała
@xoac
Jun 26 2018 11:53
unsplit works only with split_off?
Dmitriy
@dpogretskiy
Jun 26 2018 11:54
If BytesMut objects were not contiguous originally, they will be extended.
probably not
Sylwester Rąpała
@xoac
Jun 26 2018 11:56
I did unsplit in back-order of split_to (3times) and that didn't work to well.
Kelly Thomas Kline
@kellytk
Jun 26 2018 13:29
With https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/29 in mind, how commonplace is that sentiment? I would hope that comprehensibility of code isn't being put behind making it easier or faster to write. Also https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/19
Dylan DPC
@Dylan-DPC
Jun 26 2018 13:31
what's the concern?
tsoernes
@tsoernes
Jun 26 2018 18:48

On Fedora 28, with rust installed via rustup:

cargo clippy
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/home/torstein/.cargo/bin/clippy-driver rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 127)
--- stderr
/home/torstein/.cargo/bin/clippy-driver: error while loading shared libraries: librustc_driver-0b3edd563eb3dc22.so: cannot open shared object file: No such file or directory

results from locate librustc are all from /home/torstein/.rustup/toolchains/ subfolders.

'Fixes' from various git issues, e.g. sudo ldconfig /usr/local/lib and appending said folder to LD_LIBRARY_PATH does not work
(which is to be expected since the folder does not exist at all on fedora)
Andrey Lesnikov
@ozkriff
Jun 26 2018 18:51
Have you updated/switched rustup's toolchains after clippy was built?
tsoernes
@tsoernes
Jun 26 2018 18:53
no
Installed rustup and rust just now; clippy right after
(rust is not installed by package manger in addition by the way)
Andrey Lesnikov
@ozkriff
Jun 26 2018 18:55
rustup show?
tsoernes
@tsoernes
Jun 26 2018 18:57
ustup show
Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.27.0 (3eda71b00 2018-06-19)
Andrey Lesnikov
@ozkriff
Jun 26 2018 18:58
what happens if you run cargo +nightly clippy?
what command have you used to build clippy?
tsoernes
@tsoernes
Jun 26 2018 19:01
running with +nightly works, thanks!
Andrey Lesnikov
@ozkriff
Jun 26 2018 19:03
:thumbsup:
tsoernes
@tsoernes
Jun 26 2018 19:16
Clippy complains about my ndarray usage. Am I doing something wrong?
warning: immediately dereferencing a reference
  --> src/main.rs:62:23
   |
62 |     neighs1.slice_mut(s![0, 0, 0, ..]).assign(&Array::ones(2));
   |                       ^^^^^^^^^^^^^^^
The numpy equivalent of the above would be neighs1[0, 0, 0, :] = [1, 1]which in turn is equivalent to neighs1[0, 0, 0] = 1
Ingvar Stepanyan
@RReverser
Jun 26 2018 19:20
It's likely just an artifact of macro implementation which it complains about, rather than your usage
    ($($t:tt)*) => {
        // The extra `*&` is a workaround for this compiler bug:
        // https://github.com/rust-lang/rust/issues/23014
        &*&s![@parse ::std::marker::PhantomData::<$crate::Ix0>, [] $($t)*]
    };
particularly this
(from s! implementation)
tsoernes
@tsoernes
Jun 26 2018 19:24
i see.
Michal 'vorner' Vaner
@vorner
Jun 26 2018 19:47
I've noticed one thing. With a PR to rust repo, a doctest failed with a warning. But if I run doctests in my crate, warnings don't fail the test, they don't even show. Does anyone know how to enable the deny-warnings mode?
tsoernes
@tsoernes
Jun 26 2018 20:31
How to do polymorphism for array sizes?
// the type placeholder `_` is not allowed within types on item signatures (not allowed in type signatures) (rust-cargo)
fn nonzero(array: &Array<bool, _>) -> Vec<usize> {
    array
        .indexed_iter()
        .filter_map(|(index, &item)| if item { Some(index) } else { None })
        .collect()
}
Ingvar Stepanyan
@RReverser
Jun 26 2018 20:32
You can't, generics over constants are not supported yet
But you can accept array as a slice
since you don't really care about size and always return Vec and not parametrised version
so fn nonzero(array: &[bool]) -> Vec<usize>
Err, wait
Array here is from ndarray and not native one?
tsoernes
@tsoernes
Jun 26 2018 20:34
ndarray ye
Ingvar Stepanyan
@RReverser
Jun 26 2018 20:34
Then ignore my comment
Something like fn nonzero<D: Dimension>(array: &Array<bool, D>) -> Vec<usize> should work
Basically, you need explicit type param and not _ for generics
added : Dimension to satisfy Array's own constraint
if you're using latest Rust, fn nonzero(array: &Array<bool, impl Dimension>) -> Vec<usize> should also work
tsoernes
@tsoernes
Jun 26 2018 20:39
both of them trigger the same error, which is:
// fn nonzero<D: Dimension>(array: &Array<bool, D>) -> Vec<usize> {
fn nonzero(array: &Array<bool, impl Dimension>) -> Vec<usize> {
    array
        .indexed_iter()
        .filter_map(|(index, &item)| if item { Some(index) } else { None })
        .collect()
    // the trait bound `std::vec::Vec<usize>: std::iter::FromIterator<<D as ndarray::Dimension>::Pattern>` is not satisfied (a collection of type `std::vec::Vec<usize>` cannot be built from an iterator over elements of type `<D as ndarray::Dimension>::Pattern`) (rust-cargo)
    //  the trait `std::iter::FromIterator<<D as ndarray::Dimension>::Pattern>` is not implemented for `std::vec::Vec<usize>` (rust-cargo)
    //    consider adding a `where std::vec::Vec<usize>: std::iter::FromIterator<<D as ndarray::Dimension>::Pattern>` bound (rust-cargo)
}
Possibly because collect does not work for Ix0
Ingvar Stepanyan
@RReverser
Jun 26 2018 20:39
Well that's another problem :)
No, the reason is that Vec<usize> can be collected only from usizes but you are using index from ndarray::Array which can be of different type (as it's multidimensional)
That's pretty much what the error message says
a collection of type std::vec::Vec<usize> cannot be built from an iterator over elements of type <D as ndarray::Dimension>::Pattern
tsoernes
@tsoernes
Jun 26 2018 20:42
I'm not sure I understand. If you drop polymorphism and instantiate with e.g. Ix1 then it compiles without error. How would you specify the number of dims if not with usize?
Ah, forgive me, only Ix1 works, not > 1
Ingvar Stepanyan
@RReverser
Jun 26 2018 20:44
But you're not returning number of dims, you're returning dimensions themselves (combined index)
https://docs.rs/ndarray/0.11.2/ndarray/trait.Dimension.html#associatedtype.Pattern - so yeah, it happens to be usize for Ix1 but for other dimensions it will be different, which is what the error is about
You need to change return type as per signature from error message or just Vec<D::Pattern> if you want to accept any of them
tsoernes
@tsoernes
Jun 26 2018 20:45
Yes, that makes sense. For a 2D array, the index will be (usize, usize) and so on. Thank you
Ingvar Stepanyan
@RReverser
Jun 26 2018 20:47
:+1:
tsoernes
@tsoernes
Jun 26 2018 23:34
Any way to pattern match/deconstruct in a for loop? Sometime like (with ndarray)
let arr = array![[1, 2]];
for [r, c] in arr.into_iter() {
    println!("{}", r)
}