These are chat archives for rust-lang/rust

27th
Dec 2017
Michael Thomas
@Michaelt293
Dec 27 2017 00:55
I also ran rustup update (coincidentally by mistake, overzealous up arrowing, ha). Now in Atom, I have the following errorrls-preview was not found on nightly - Try configuring another toolchain, like a previous nightly or beta. Why did this happen after rustup update?
Michael Thomas
@Michaelt293
Dec 27 2017 01:18
Also, a programming question, is there a nice way I can do something like this in Rust? -
>>> data Config =  Config { path :: Maybe String, date :: Maybe String } deriving Show
>>> :{
Prelude Control.Applicative Data.Monoid| instance Monoid Config where
Prelude Control.Applicative Data.Monoid|   mempty = Config Nothing Nothing
Prelude Control.Applicative Data.Monoid|   mappend (Config p1 d1) (Config p2 d2) = Config (p1 <|> p2) (d1 <|> d2)
Prelude Control.Applicative Data.Monoid| :}
>>> Config (Just "Docs") Nothing <> Config (Just "Default") (Just "2017")
Config {path = Just "Docs", date = Just "2017"}
Roman Proskuryakov
@kpp
Dec 27 2017 01:53
Hello! How do I make some methods pub in my unit test module ?
Michael Thomas
@Michaelt293
Dec 27 2017 03:03
For monoid append, I could use + by implementing the Add trait. I wonder whether there is a way to have the same behaviour as the Alternative type class provides for combining Options..
Michael Thomas
@Michaelt293
Dec 27 2017 03:27
The method or defined for Options seems to do what I want. Sorry for spamming.
str4d
@str4d
Dec 27 2017 09:42

I'm having trouble figuring out this error message:

error[E0277]: the trait bound `transport::ntcp::Session: actix::Handler<_>` is not satisfied
    --> src/transport/ntcp/mod.rs:1328:25
     |
1328 |                 session.send(msg);
     |                         ^^^^ the trait `actix::Handler<_>` is not implemented for `transport::ntcp::Session`
     |
     = help: the following implementations were found:
               <transport::ntcp::Session as actix::Handler<transport::ntcp::Frame, std::io::Error>>

I have impl Handler<Frame, io::Error> for Session. Handler is defined as pub trait Handler<M, E = ()>, so I'm wondering if this caused by some interaction with the default value for the type parameter?

msg above is a Frame, so is the problem perhaps that the compiler can't infer the second type parameter? And if so, how could I go about annotating it?
red75prime
@red75prime
Dec 27 2017 09:59
What is the type of session?
It needs to be Address<Session> or SyncAddress<Session>, it seems.
str4d
@str4d
Dec 27 2017 10:09
@red75prime Session is a struct
And I did try specifying Address<Session>, but I get the same error (so it seems that the compiler is able to infer that at least)
str4d
@str4d
Dec 27 2017 10:21
cc @fafhrd91 ^
red75prime
@red75prime
Dec 27 2017 10:22
It seems trait bound for Address<A>::send(msg: M) requires A: Handler<M> that is A: Handler<M, ()>, not Handler<M, io::Error>
str4d
@str4d
Dec 27 2017 10:23
Mmm, so it's the default type parameter causing me issues
str4d
@str4d
Dec 27 2017 10:28
Yep, adding a separate handler with a () error fixes the compiler issue. Thanks @red75prime :)
Ville Hakulinen
@vhakulinen
Dec 27 2017 15:14
Hi, can I somehow make macro out of the following (last 2 lines):
/code let ctx: Arc<Mutex<Option<Context>>> = ...
let ctx = ctx.lock().unwrap();
let ctx = ctx.as_ref().unwrap();
let ctx: Arc<Mutex<Option<Context>>> = ...
let ctx = ctx.lock().unwrap();
let ctx = ctx.as_ref().unwrap();
I tried to write one earlier but hit a problem with lifetime where the ctx doesn't live long enough
this is the macro I had:
```
macro_rules! locked_option_as_ref {
    ($locked:ident) => {{
        let unlocked = $locked.lock().unwrap();
        unlocked.as_ref().unwrap()
    }}
}
Ville Hakulinen
@vhakulinen
Dec 27 2017 15:20
It probably would work with a callback which the macro would the call before dropping the unlocked but thats not really ideal since it would result in a lot of nested code
Ville Hakulinen
@vhakulinen
Dec 27 2017 16:03
macro_rules! locked_option_to_ref {
    ($locked:ident) => (
        let $locked = $locked.lock().unwrap();
        let $locked = $locked.as_ref().unwrap();
    );
}
this seems to work :)
Sherab Giovannini
@Shaddy
Dec 27 2017 17:04
Hi guys, I'm trying to do something similar to this: https://play.rust-lang.org/?gist=3fc4e438604a4ed37db3884f67d90ad1&version=stable
just take in mind that Reference in my real implementation has a Drop implemented, which finishes closing an OS Handle
It may be solved by using Arc or similar (I'm not sure) but (I'm still not sure) probably the Drop will be called many times
is there any way to do what I want, which is to create the "next" effect w/o having the problem of the "borrowing"
?
Denis Lisov
@tanriol
Dec 27 2017 17:19
An Arc seems to be the proper solution. The Drop will be called once on the internals.
Sherab Giovannini
@Shaddy
Dec 27 2017 17:40
Oh, I will try then, I was not sure about the internal functionality
Thanks
works like a charm with ARC