These are chat archives for rust-lang/rust

12th
Dec 2017
Thibault Delor
@thibaultdelor
Dec 12 2017 02:50 UTC
@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 UTC
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 UTC
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 UTC
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 UTC
Hmm, 1.22 was released around 22nd of November
Thibault Delor
@thibaultdelor
Dec 12 2017 03:09 UTC
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 UTC
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 UTC
nope, but… maybe my company proxy is caching stuff
:O
Hans W. Uhlig
@huhlig
Dec 12 2017 03:14 UTC
they shouldn't cache anything over an https connection
unless you've been MITMed
Ryan
@rnleach
Dec 12 2017 03:16 UTC
Well, the good news is at least it (probably) isn't a problem with rustup.
Thibault Delor
@thibaultdelor
Dec 12 2017 03:16 UTC
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 UTC
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 UTC
jesus
that is gross
Thibault Delor
@thibaultdelor
Dec 12 2017 03:23 UTC
It is
Trevor Joynson
@akatrevorjay
Dec 12 2017 03:23 UTC
You work somewhere that does this?
Quit
Thibault Delor
@thibaultdelor
Dec 12 2017 03:23 UTC
Contracting for 4 months ;)
Thibault Delor
@thibaultdelor
Dec 12 2017 03:31 UTC
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 UTC
nice
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:19 UTC
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 UTC
@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 UTC
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 UTC
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 UTC
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 UTC
Hm, there shoudn't be genuine cycles there...
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:26 UTC
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 UTC
Its probably rust-lang/cargo#4066
Michal 'vorner' Vaner
@vorner
Dec 12 2017 12:29 UTC
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 UTC
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 UTC
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 UTC
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 UTC
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 UTC
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 UTC
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 UTC
window?
nope. It return iter over slice of a certain size.
Restioson
@Restioson
Dec 12 2017 15:12 UTC
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 UTC
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 UTC
You mean like tails in Haskell?
An iterator over suffixes of an array?
mnivoliez
@mnivoliez
Dec 12 2017 15:14 UTC
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 UTC
Yes.
That’s an array suffix iterator.
mnivoliez
@mnivoliez
Dec 12 2017 15:15 UTC
I havent tried haskell yet
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:15 UTC
Is there not one in itertools by that name?
Either tails or suffixes or something?
mnivoliez
@mnivoliez
Dec 12 2017 15:16 UTC
in std, the split at could do
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:16 UTC
Oh, or you could use slicing.
arr[i..]
mnivoliez
@mnivoliez
Dec 12 2017 15:17 UTC
like this?
let subnodes = nodes[node..];
Restioson
@Restioson
Dec 12 2017 15:18 UTC
personally i like to slice rotate
just because its a cool feature
however
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:18 UTC
You slice with an index, not a node.
But otherwise yes.
Restioson
@Restioson
Dec 12 2017 15:19 UTC
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 UTC
hum. the enumerate() method could come in handy
Restioson
@Restioson
Dec 12 2017 15:19 UTC
that should work i think
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:20 UTC
@Restioson Insufficiently lazy, I’m thinking.
mnivoliez
@mnivoliez
Dec 12 2017 15:20 UTC
@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 UTC
how? ;P
lol
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:20 UTC
That next call is only happening once.
Oh, I see, it’s a cycling, never mind.
Restioson
@Restioson
Dec 12 2017 15:21 UTC
you can always do a.iter().take(1)
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:21 UTC
Yeah.
Restioson
@Restioson
Dec 12 2017 15:23 UTC
we need a skip for iterators or something
Restioson
@Restioson
Dec 12 2017 15:23 UTC
rotate, sorry
Steve Klabnik
@steveklabnik
Dec 12 2017 15:23 UTC
ah
:)
Restioson
@Restioson
Dec 12 2017 15:24 UTC
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 UTC
That wouldn’t be skip
Restioson
@Restioson
Dec 12 2017 15:29 UTC
whoops rip
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:29 UTC
That would be a majorly inefficient no-op
Restioson
@Restioson
Dec 12 2017 15:29 UTC
i am not smart xP
mnivoliez
@mnivoliez
Dec 12 2017 15:29 UTC
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 UTC
@Restioson You’ve forgotten the Option part.
Restioson
@Restioson
Dec 12 2017 15:30 UTC
:thought_balloon:
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:31 UTC
@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 UTC
arg
mnivoliez
@mnivoliez
Dec 12 2017 15:31 UTC
hum.
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:32 UTC
Really, slicing is your best bet here.
Restioson
@Restioson
Dec 12 2017 15:32 UTC
ok, map
// map
|| {
    loop {
        yield iter.next().and_then(f);
    }
}
mnivoliez
@mnivoliez
Dec 12 2017 15:33 UTC
@Restioson you mean for me?
Restioson
@Restioson
Dec 12 2017 15:33 UTC
no
Alexander Ronald Altman
@pthariensflame
Dec 12 2017 15:35 UTC
@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 UTC
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 UTC

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

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 UTC
forget it, it is working well just by &*ptr instead
Fra ns
@snarf95_twitter
Dec 12 2017 18:32 UTC
&* solves all problems
Restioson
@Restioson
Dec 12 2017 18:32 UTC
All praise. Always rust.
mnivoliez
@mnivoliez
Dec 12 2017 19:06 UTC
@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 UTC
Do folks use Gotham?
It looks cool but not quite baked. I like the "Rust stable" approach for sure.