These are chat archives for rust-lang/rust

13th
Nov 2018
Krzysztof Woś
@krzysztofwos
Nov 13 2018 03:33
Folks, I'm trying to figure out whether I can give a default value to a repeated option when using structopt. I want something like foos: Vec<String> with the default value being a Vec of foo, bar, baz. Using default_value = "foo" works for a single argument but I'm wondering if there's any way to specify more than one. I've tried default_value = "foo, bar, baz" and similar but no luck. There's not much in the docs on this subject
tandrysyawaludin
@tandrysyawaludin
Nov 13 2018 04:45
@pr-yemibedu actually I wanna find for how install sqlite3-devel on heroku
David Vo
@auscompgeek
Nov 13 2018 04:50
@tandrysyawaludin sounds like you have the perfect web search term
aohan237
@aohan237
Nov 13 2018 07:06
pub fn get_token(&mut self) -> impl Future {
    let https = hyper_tls::HttpsConnector::new(4).expect("TLS initialization failed");
    let client = hyper::Client::builder().build::<_, hyper::Body>(https);
    let json = r#"{"library":"hyper"}"#;
    let uri: hyper::Uri = "http://httpbin.org/post".parse().unwrap();
    let mut req = hyper::Request::new(Body::from(json));
    *req.method_mut() = hyper::Method::POST;
    *req.uri_mut() = uri.clone();
    req.headers_mut().insert(
        hyper::header::CONTENT_TYPE,
        hyper::header::HeaderValue::from_static("application/json")
    );
    let post = client.request(req).and_then(|res| {
        println!("POST: {}",res.status() );
        self.token.access_token="123";
        res.into_body().concat2()
    });
    post
}
i found that if use self in a future , there is also a life time issue
Why?
cant i update self.token in a future function?
error[E0482]: lifetime of return value does not outlive the function call. this is the error
Tim Robinson
@1tgr
Nov 13 2018 07:20
&mut self doesn’t live long enough
It only lives to the bottom of the function, it doesn’t live long enough for the and_then
@axos88 was recommending you ask for Actix advice
aohan237
@aohan237
Nov 13 2018 07:22
So how to solve?
Tim Robinson
@1tgr
Nov 13 2018 07:22
Either there is an Actix specific solution to this, which I don’t know
aohan237
@aohan237
Nov 13 2018 07:22
move a &mut self to and_then?
Tim Robinson
@1tgr
Nov 13 2018 07:22
Or you could also change
pub fn get_token(&mut self) -> impl Future<Item = ???>
to
pub fn get_token(mut self) -> impl Future<Item = (Self, ???)>
aohan237
@aohan237
Nov 13 2018 07:23
this code is only use hyper and future
Tim Robinson
@1tgr
Nov 13 2018 07:23
I see
With pure hyper/futures I would avoid mixing references and futures like this
aohan237
@aohan237
Nov 13 2018 07:24
so if i want a token auto update service , how to do this?
Tim Robinson
@1tgr
Nov 13 2018 07:25
See my suggestion just now about moving self (mut self) instead of referencing it (&mut self)
aohan237
@aohan237
Nov 13 2018 07:25
Ok…so. just not use reference
Curious about and_then . they are in the same scope? why and_then have the different lifetime?
Tim Robinson
@1tgr
Nov 13 2018 07:34
Futures seem to end up with a ’staticlifetime… trying to track down where that comes from
aohan237
@aohan237
Nov 13 2018 07:37
Static lifetime means live long as the program, then futures will have more and more static lifetime object?
and the memory growing lager?
Tim Robinson
@1tgr
Nov 13 2018 07:38
Static lifetime on the impl Future means your future can only refer to 'static things, ie things that live longer than any function
I think this can work though:
pub fn get_token<'a>(&'a mut self) -> impl Future + 'a {
And you may need:
let post = client.request(req).and_then(move |res| {
aohan237
@aohan237
Nov 13 2018 07:40
yeah
So reference issues always come with lifetime...
Future and_then confused the lifetime
Tim Robinson
@1tgr
Nov 13 2018 07:43
Note that, until get_token’s future is finished, you won’t be able to do anything with self
Because get_token’s future has exclusive access to it
aohan237
@aohan237
Nov 13 2018 07:45
but if i have a self.clone,i won affect others right?
Tim Robinson
@1tgr
Nov 13 2018 08:10
Sure, but it will set self.token on only one of the clones
aohan237
@aohan237
Nov 13 2018 08:11
that’s sad. are there any better way to do this?
Tim Robinson
@1tgr
Nov 13 2018 08:14
Yes: the advice I had earlier about using (mut self) instead of (&’mut self)
Or another common pattern is to put all your fields inside a separate struct, and wrap that in a Rc<RefCell<...>>
Then your lifetime issues go away (due to the Rc), and you can mutate whenever you need to (due to the RefCell)
aohan237
@aohan237
Nov 13 2018 08:16
Yeah,that the suggestion from actin_web author
he suggest Rev<RefCell<T>>
Thanks . i think i will go through these rust-boo chapter again. to study more
aohan237
@aohan237
Nov 13 2018 08:25
but if we you ARC<Mutext<>> will solve the problem talked above?
Tim Robinson
@1tgr
Nov 13 2018 08:35
Arc<Mutex<T>> or Rc<RefCell<T>>, yes
I think all your code here is single threaded so Rc RefCell is enough
If the compiler complains about Sync or Send, switch to Arc<Mutex<T>>
aohan237
@aohan237
Nov 13 2018 08:38
another solution?: use future to update token, and use channel to send data to a thread who update token will be better?
Both two ways have the deadlock issue
Tim Robinson
@1tgr
Nov 13 2018 08:41
There doesn’t have to be a deadlock issue, it’s straightforward to write this code so that it works
The only issue is with &mut self
aohan237
@aohan237
Nov 13 2018 08:42
will the channel way be better?
Tim Robinson
@1tgr
Nov 13 2018 08:43
With a channel, the other thread would still need a mutable reference to self
aohan237
@aohan237
Nov 13 2018 08:43
Yeah,but logical seems more simpler
Tim Robinson
@1tgr
Nov 13 2018 08:43
That means &mut self like the original code (with the same problem), or Arc<Mutex<T>>
aohan237
@aohan237
Nov 13 2018 08:54
thanks~