These are chat archives for rust-lang/rust

12th
Dec 2017
Thibault Delor
@thibaultdelor
Dec 12 2017 02:50
@seanr707 @rnleach I have reinistalled rustup and same problem. After digging it seems that https://static.rust-lang.org/dist/channel-rust-stable.toml is not matching the sha256
Thibault Delor
@thibaultdelor
Dec 12 2017 02:57
ok I definitely found the bug in rustup, https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256 has the hash value of channel-rust-1.21.0
Ryan
@rnleach
Dec 12 2017 02:59
Wow. That is really weird. I also got a new computer and just installed rust on it. Maybe 3 days before you asked the question on here originally and didn't have that problem at all.
Thibault Delor
@thibaultdelor
Dec 12 2017 03:07
even weirder, accroding to the timestamps here nothing has changed since the 23rd of November. I don’t understand how no one got the error
Ryan
@rnleach
Dec 12 2017 03:09
Hmm, 1.22 was released around 22nd of November
Thibault Delor
@thibaultdelor
Dec 12 2017 03:09
exactly, nothing changed since then
So… how come am I the only one to gert the error???
coz obviously the sha256 is wrong
do you have the same output ?
$ curl https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256
b37882b34881acbb436d0cddaf4e827ceedb770271e5fe777024221b8020bf3c  channel-rust-stable.toml
$ curl -ssf  https://static.rust-lang.org/dist/channel-rust-stable.toml | shasum -a 256
5e837251d054df566fa4f390a0ef841a7cba086e4e47f11a74695e449ce157d7  -
Ryan
@rnleach
Dec 12 2017 03:12
When I do the first command I get the SHA256 key that you posted as the result of your second command.
Is it possible curl cached the old version of the SHA256 or something?
Yeah, I ran both commands and came up with the 5e8372.....157d7 key both times.
Thibault Delor
@thibaultdelor
Dec 12 2017 03:14
nope, but… maybe my company proxy is caching stuff
:O
Hans W. Uhlig
@huhlig
Dec 12 2017 03:14
they shouldn't cache anything over an https connection
unless you've been MITMed
Ryan
@rnleach
Dec 12 2017 03:16
Well, the good news is at least it (probably) isn't a problem with rustup.
Thibault Delor
@thibaultdelor
Dec 12 2017 03:16
yup indeed ^^
I am puzzled… maybe a cdn problem where this specific files haven’t been replicated well
clearing my cache doesn’t help
$ curl -v  https://static.rust-lang.org/dist/channel-rust-1.21.0.toml.sha256
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 3128 (#0)
* Establish HTTP proxy tunnel to static.rust-lang.org:443
> CONNECT static.rust-lang.org:443 HTTP/1.1
> Host: static.rust-lang.org:443
> User-Agent: curl/7.54.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
< Connection: close
<
* Proxy replied OK to CONNECT request
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: static.rust-lang.org
* Server certificate: ProdWebSSLCA1
* Server certificate: CBAInternalRootCA
> GET /dist/channel-rust-1.21.0.toml.sha256 HTTP/1.1
> Host: static.rust-lang.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: binary/octet-stream
< Content-Length: 91
< Date: Tue, 12 Dec 2017 02:55:58 GMT
< Last-Modified: Thu, 12 Oct 2017 15:46:52 GMT
< ETag: "c430db8e03ef2781faa27792b2b3ade0"
< x-amz-version-id: 74NHQhSMDCWwqbXHdeEbpssGrFGcB3fA
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Miss from cloudfront
< Via: 1.1 522ee68b99951dfce3f866ad7d8a295f.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: J4ZwoRcy2-l_dh5BLmygHFLjO9fuBcLCxY9NQIZ0AeFZBZG3uakJsg==
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Age: 1351
<
b37882b34881acbb436d0cddaf4e827ceedb770271e5fe777024221b8020bf3c  channel-rust-1.21.0.toml
* Connection #0 to host 127.0.0.1 left intact
obviously it’s served via cloud front, maybe that’s the problem
Thibault Delor
@thibaultdelor
Dec 12 2017 03:22
As you can see the https connection is rewritten with my company proxy
so they can definitely cache things
I guess that’s what is happening…..
Trevor Joynson
@akatrevorjay
Dec 12 2017 03:22
jesus
that is gross
Thibault Delor
@thibaultdelor
Dec 12 2017 03:23
It is
Trevor Joynson
@akatrevorjay
Dec 12 2017 03:23
You work somewhere that does this?
Quit
Thibault Delor
@thibaultdelor
Dec 12 2017 03:23
Contracting for 4 months ;)
Thibault Delor
@thibaultdelor
Dec 12 2017 03:31
Clearing my company cache using http headers fixed it…
curl -H 'Cache-Control: no-cache' https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256
5e837251d054df566fa4f390a0ef841a7cba086e4e47f11a74695e449ce157d7  channel-rust-stable.toml
omg can’t believe it
Thanks all for your help :)
Trevor Joynson
@akatrevorjay
Dec 12 2017 03:36
nice
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:19
Hello. A travis job is repeatedly getting stuck on „updating registry“. I tried 3 times over the span of like 16 hours. Is it some kind of global problem, or is it just me? The same job on appveyor is also stuck. https://travis-ci.org/vorner/slog-retry/jobs/314996772 But it works on my machine.
Hmm. Maybe it doesn't. It shows „Resolving dependency graph here“, but is stuck too :-|
Aleksey Kladov
@matklad
Dec 12 2017 12:22
@vorner sometems, cargo takes 2^n time to resolve dependencies, because it's an NP-complete problem
this might be the case here?
Is it waiting for IO, or is CPU on 100%
You can also try the nightly Cargo, it has some better diagnostics about what exactly it is doing at the moment.
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:23
100% CPU. But the only change since it worked was fixing a category in the metadata section. And yes, this is nightly.
But maybe something changed in the dependencies.
Aleksey Kladov
@matklad
Dec 12 2017 12:24
Yeah, so what might help is changing dependencies in Cargo.toml to make them more strict
Perhaps there are better ways to figure out which dependnecy exactly is causing problems, but I don't know them.
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:25
With RUST_LOG=debug it seems to be cycling.
DEBUG:cargo::core::registry: load/precise  registry `https://github.com/rust-lang/crates.io-index`
DEBUG:cargo::core::registry: load/precise  registry `https://github.com/rust-lang/crates.io-index`
DEBUG:cargo::core::registry: load/precise  registry `https://github.com/rust-lang/crates.io-index`
DEBUG:cargo::core::resolver: checking if unicode-xid v0.0.4 is already activated
DEBUG:cargo::core::resolver: checking if synom v0.11.3 is already activated
DEBUG:cargo::core::resolver: checking if quote v0.3.15 is already activated
DEBUG:cargo::core::resolver: checking if syn v0.11.11 is already activated
all over again and again.
Aleksey Kladov
@matklad
Dec 12 2017 12:26
Hm, there shoudn't be genuine cycles there...
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:26
I guess this is worth an issue on cargo.
Thanks for the hints what to look for.
Aleksey Kladov
@matklad
Dec 12 2017 12:27
Its probably rust-lang/cargo#4066
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:29
That doesn't seem so. That one suggests it is progressing somewhere, that it only takes a really long time. When I see the same messages over and over again, I guess it goes nowhere and would cycle forever.
Aleksey Kladov
@matklad
Dec 12 2017 12:30
Yeah, if that a true cycle, then it's def a bug! But it may be switching some version upper on the stack? Attaching a full RUST_LOG=debug output to the issue would be really useful!
Hm, wait
@vorner could it be rust-lang/cargo#4806 ?
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:33
It might be. Checking cargo --version, I didn't get that bugfix from rustup yet. And commenting out dev-dependencies fixes the problem. No, let's see what happened.
Hmm. Uncommenting them one by one and running cargo check in between fixed the problem. Now I have everything enabled and it works.
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:46
Doesn't seem to be the same one. That one talks about pushing infinitely onto a vector and the process is not growing in memory at all. And I don't think there are cycles in the dependencies, but who knows :-|.
mnivoliez
@mnivoliez
Dec 12 2017 14:57
Hello!
I got a question:
Let say that I got a loop over a collection:
for node in nodes {

}
I would like inside this for, iterate other all next element of nodes
like this kind of list ]node, lastNode]
Is there any way to acheive that?
mnivoliez
@mnivoliez
Dec 12 2017 15:03
Maybe with iterator and a second one after it?
let node = nodes.iter();
let nextnodes = node;
nextnodes.next();
Michal 'vorner' Vaner
@vorner
Dec 12 2017 15:05
Look into the itertools crate.
I think you look for the window method there, but I'm not 100% (either of my memory for the name and what exactly you try to do)
mnivoliez
@mnivoliez
Dec 12 2017 15:08
window?
nope. It return iter over slice of a certain size.
Restioson
@Restioson
Dec 12 2017 15:12
what do you mean 'all next element of nodes'
oh, like for a list of
[1, 2, 3, 4]
iterator like
[(1, 2), (2, 3), (3, 4), (4, ?)]
mnivoliez
@mnivoliez
Dec 12 2017 15:13
I think I found what i was looking for. The split at could do the trick
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:13
You mean like tails in Haskell?
An iterator over suffixes of an array?
mnivoliez
@mnivoliez
Dec 12 2017 15:14
Like, if ine the first loop, i am at element #3, I want to make a second for over [#4,...,..#n]
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:15
Yes.
That’s an array suffix iterator.
mnivoliez
@mnivoliez
Dec 12 2017 15:15
I havent tried haskell yet
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:15
Is there not one in itertools by that name?
Either tails or suffixes or something?
mnivoliez
@mnivoliez
Dec 12 2017 15:16
in std, the split at could do
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:16
Oh, or you could use slicing.
arr[i..]
mnivoliez
@mnivoliez
Dec 12 2017 15:17
like this?
let subnodes = nodes[node..];
Restioson
@Restioson
Dec 12 2017 15:18
personally i like to slice rotate
just because its a cool feature
however
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:18
You slice with an index, not a node.
But otherwise yes.
Restioson
@Restioson
Dec 12 2017 15:19
let a = [1, 2, 3, 4];

a.iter()
    .zip(a.iter()
            .skip(1)
            .chain(a.iter().take(1))
        )
but here's some meme magic if you want it
mnivoliez
@mnivoliez
Dec 12 2017 15:19
hum. the enumerate() method could come in handy
Restioson
@Restioson
Dec 12 2017 15:19
that should work i think
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:20
@Restioson Insufficiently lazy, I’m thinking.
mnivoliez
@mnivoliez
Dec 12 2017 15:20
@Restioson say no more, I have to try this slick thingy thing you just get out of your hat
Restioson
@Restioson
Dec 12 2017 15:20
how? ;P
lol
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:20
That next call is only happening once.
Oh, I see, it’s a cycling, never mind.
Restioson
@Restioson
Dec 12 2017 15:21
you can always do a.iter().take(1)
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:21
Yeah.
Restioson
@Restioson
Dec 12 2017 15:23
we need a skip for iterators or something
Restioson
@Restioson
Dec 12 2017 15:23
rotate, sorry
Steve Klabnik
@steveklabnik
Dec 12 2017 15:23
ah
:)
Restioson
@Restioson
Dec 12 2017 15:24
if its a slice i do
let a = [1, 2, 3, 4];

a.iter().zip(a.rotate(1).iter())
because rotate is just cool
i wonder if iterator methods could be written as generators
// skip
|| {
    for _ in 0..n {
        yield iter.next();
    }
    loop {
        yield iter.next();
    }
}
for instance
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:29
That wouldn’t be skip
Restioson
@Restioson
Dec 12 2017 15:29
whoops rip
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:29
That would be a majorly inefficient no-op
Restioson
@Restioson
Dec 12 2017 15:29
i am not smart xP
mnivoliez
@mnivoliez
Dec 12 2017 15:29
could I do that:
for (node, next_nodes) = nodes.iter().zip(nodes.iter().skip(1)) {
/* loop */
}
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:30
@Restioson You’ve forgotten the Option part.
Restioson
@Restioson
Dec 12 2017 15:30
:thought_balloon:
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:31
@mnivoliez That will give you the same as windows(2)
That’s not what you want, from you description.
Restioson
@Restioson
Dec 12 2017 15:31
arg
mnivoliez
@mnivoliez
Dec 12 2017 15:31
hum.
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:32
Really, slicing is your best bet here.
Restioson
@Restioson
Dec 12 2017 15:32
ok, map
// map
|| {
    loop {
        yield iter.next().and_then(f);
    }
}
mnivoliez
@mnivoliez
Dec 12 2017 15:33
@Restioson you mean for me?
Restioson
@Restioson
Dec 12 2017 15:33
no
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:35
@mnivoliez
for (i, nodes) in nodes.iter().enumerate() {
    let subnodes = &nodes[(i+1)..];
    ...
}
s/(i, nodes)/(i, node)/
mnivoliez
@mnivoliez
Dec 12 2017 16:01
and what about that:
let mut other_nodes = nodes;
while let Some((first, elements)) = other_nodes.split_first() {
    other_nodes = elements;
    println!("{}, {:?}", first, other_nodes);
}
mnivoliez
@mnivoliez
Dec 12 2017 16:19

if a method return me a vec of struct containing reference to object that I pass as parameter under this format:

fn generate_edges_from_nodes(nodes: &Vec<Node>) -> Vec<Edge> {
     let mut edges = Vec::new();
       let mut other_nodes = nodes.as_slice();
   while let Some((node, others)) = other_nodes.split_first() {
            other_nodes = others;
            println!("node: {:?}, other nodes: {:?}", node, other_nodes);
            for other in other_nodes {
                edges.push(Edge {
                    first: &node,
                    second: &other,
                    weight: ((other.x - node.x).powi(2) + (other.y - node.y).powi(2)).sqrt(),
                })
            }
        }
        edges
    }

The compiler complains that &nodes does not live long enought. Should I replace that by Rc? or something else?

Ilya Bogdanov
@vitvakatu
Dec 12 2017 17:35
@mnivoliez don't pass &Vec<...>, use &[...]
Regarding your question, can I see Edge definition?
Ilya Bogdanov
@vitvakatu
Dec 12 2017 17:55
Try to use generate_edges_from_nodes<'a>(nodes: &'a [Node]) -> Vec<Edge<'a>>?
Sherab Giovannini
@Shaddy
Dec 12 2017 18:18

Hi, I'm aware this is unsafe as hell but sometimes required. There is a problem while trying to interpret an enum, inside a repr(C) struct. Why is it allowed?

https://play.rust-lang.org/?gist=ac74197bb4dafb44118aa183b98f6090&version=nightly

Sherab Giovannini
@Shaddy
Dec 12 2017 18:24
forget it, it is working well just by &*ptr instead
Fra ns
@snarf95_twitter
Dec 12 2017 18:32
&* solves all problems
Restioson
@Restioson
Dec 12 2017 18:32
All praise. Always rust.
mnivoliez
@mnivoliez
Dec 12 2017 19:06
@vitvakatu still got
error[E0597]: `nodes` does not live long enough
  --> src/main.rs:77:47
   |
77 |         let edges = generate_edges_from_nodes(nodes.as_slice());
   |                                               ^^^^^ does not live long enough
...
85 |     }
   |     - borrowed value only lives until here
   |
note: borrowed value must be valid for the anonymous lifetime #1 defined on the method body at 75:5...
  --> src/main.rs:75:5
   |
75 | /     fn new(ctx: &mut Context) -> GameResult<MainState> {
76 | |         let nodes = generate_nodes(50, GRID_X, GRID_Y);
77 | |         let edges = generate_edges_from_nodes(nodes.as_slice());
78 | |         let s = MainState {
...  |
84 | |         Ok(s)
85 | |     }
   | |_____^
Judson Lester
@nyarly
Dec 12 2017 19:56
Do folks use Gotham?
It looks cool but not quite baked. I like the "Rust stable" approach for sure.