These are chat archives for rust-lang/rust

6th
Dec 2017
Fra ns
@snarf95_twitter
Dec 06 2017 07:25
Sweet thanks
Adil Ilhan
@adililhan
Dec 06 2017 12:25
hi, i'm trying to understand the lifetime in Rust.
what is the difference between these two code?
Zakarum
@omni-viral
Dec 06 2017 12:27
i32 is an integer
&i32 is a reference to i32
Basically an address to where it is in memory
&'a i32 means that this reference lives in particular scope 'a.
You can't specify such scopes manually. Compiller will do it for you.
There are rules you need to follow when you deal with lifetimes.
Adil Ilhan
@adililhan
Dec 06 2017 12:32

There are rules you need to follow when you deal with lifetimes.

yeah, that's why i'm trying to understand it tho

Zakarum
@omni-viral
Dec 06 2017 12:32
If you have &'a i32 you can't return it from function that returns &'b i32. Unleass 'b is declared as 'a: 'b
Which means that 'b is subscope of 'a
You can specify it in where clause
fn foo<'a, 'b>(...) where 'a: 'b
Adil Ilhan
@adililhan
Dec 06 2017 12:34
could you please show me an example code, which works on play.rust-lang?
Alternatively you can specify 'a: 'b along with declaration of 'a
This message was deleted
Adil Ilhan
@adililhan
Dec 06 2017 12:41
trying to get the "where" word now lol, thanks
ok, i understood purpose of the where word.
the only difference is the "where" word there
Zakarum
@omni-viral
Dec 06 2017 12:45
No.
Also foo returns &'a u32 in first example
And &'b u32 if second
In second example you get error because foo may return both &x and &y. And you try assign reference to the z. Ana z lives longer than y
And you can't have a reference to the dead value
In C you'll have dangling pointer. Everything would compile just fine. But in runtime it will cause undefined behaviour
Zakarum
@omni-viral
Dec 06 2017 12:50
when you dereference pointer to destroyed value
In Rust you have compile-time error.
Which is awesome
Adil Ilhan
@adililhan
Dec 06 2017 13:28
thank you for explanation
Ilya Bogdanov
@vitvakatu
Dec 06 2017 13:29
To clarify, you will rarely work with lifetimes. In most situations compiler takes care of them under the hood.
Zakarum
@omni-viral
Dec 06 2017 13:53
But you will get errors about incompatible lifetimes.
So you need to understand basics to fix those errors
Ravi Teja
@tekjar
Dec 06 2017 15:15
Hi. Is anyone using failure crate? How do I derive From for members of Fail type?
Zakarum
@omni-viral
Dec 06 2017 15:16
Is it better than error_chain?
Steve Klabnik
@steveklabnik
Dec 06 2017 15:17
i think so, opinions may differ
that said, i haven't used From stuff with it explicitly; it's always Just Worked with ?. i thought maybe it already did that
Ravi Teja
@tekjar
Dec 06 2017 15:18
@steveklabnik I think it's only doing from on inbuilt Error
Michal 'vorner' Vaner
@vorner
Dec 06 2017 15:19
I used failure and even used Error::from around futures (futures really need support for ? too). And yes, it Just Worked.
Ravi Teja
@tekjar
Dec 06 2017 15:33
@vorner
#[macro_use]
extern crate failure;

use std::result::Result;
use std::sync::mpsc::SendError;
use std::sync::mpsc::channel;

#[derive(Debug, Fail)]
pub enum ClientError {
    #[fail(display = "Failed sending request to connection thread. Error = {}", _0)]
    MpscSend(SendError<i32>)
}

fn test() -> Result<(), ClientError> {
    let (tx, rx) = channel();
    tx.send(1)?
}
You mean this works?
Michal 'vorner' Vaner
@vorner
Dec 06 2017 15:59
Huh, likely not. I don't know. However, if your result is Result<(), failure::Error>, then it should.
Sherab Giovannini
@Shaddy
Dec 06 2017 16:30
guys
am I able to compile native rust implementations such like this: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/handle.rs
Steve Klabnik
@steveklabnik
Dec 06 2017 16:32
i'm not sure what you're asking, exactly
that code is in the rust standard library; so it certainly works (well, all software has bugs, but you know what i mean :wink: )
Sean
@seanr707
Dec 06 2017 16:41
Almost finished my first Rust project (and only my 2nd GTK project) :smile:
Sherab Giovannini
@Shaddy
Dec 06 2017 16:47
@steveklabnik I'm doing an implementation that requires to manually handle native windows objects
So I would like to borrow some native windows implemented code
but well you're right, the code is in the std but just propagated xD
Steve Klabnik
@steveklabnik
Dec 06 2017 16:49
i'd look at the winapi crate
Sherab Giovannini
@Shaddy
Dec 06 2017 16:49
I've been using winapi crate
but since my goal is to create some thread channels that are not being used as a common Rust thread/channel
I need to create some bindings to winapi and borrow some std accessible windows implementations
Sherab Giovannini
@Shaddy
Dec 06 2017 17:21
I think I should modify my question
is it possible to create a Rust native threads, and signaling them with native (windows events) by in some way specifying the Handle to wait for?
Steve Klabnik
@steveklabnik
Dec 06 2017 17:26
i don't know windows' apis (even though i use windows) well enough
but i'd assume so, somehow, given that rust threads are os threads
Sherab Giovannini
@Shaddy
Dec 06 2017 17:33
I'm trying to figure out how, at least, which is the most raw way to create threads?
Ryan
@rnleach
Dec 06 2017 17:33
Isn't there a method to get a native handle in threads?
Steve Klabnik
@steveklabnik
Dec 06 2017 17:33
Sherab Giovannini
@Shaddy
Dec 06 2017 17:34
lol
this is the way I want to avoid, its the easiest one
xD
:)
Sherab Giovannini
@Shaddy
Dec 06 2017 17:34
yeah, I know how to create threads, but I would like to have "rusty" threads with Rust guarantees at somepoint
and just wait for a different handle rather than his own handle
Sherab Giovannini
@Shaddy
Dec 06 2017 17:35
yep
but it looks like its used to wait for handle objects
Steve Klabnik
@steveklabnik
Dec 06 2017 17:35
yeah, so you could do as_raw_handle
Sherab Giovannini
@Shaddy
Dec 06 2017 17:35
which points to RawHandle contained in thread
Sherab Giovannini
@Shaddy
Dec 06 2017 17:37
but seems it extracts raw handle from the thread itself
I think I should read a bit more and come back to improve my questions
what I want to do is just have a thread running, that is being signaled with 2 native windows handles (events)
Steve Klabnik
@steveklabnik
Dec 06 2017 17:38
i would assume that you can take the RawHandle and give it to the appropriate winapi function that deals with events
Ryan
@rnleach
Dec 06 2017 17:38
Yeah, I've never done it, but I think if you create the thread with rust, then get the raw handle you can pass it to native FFI etc.
Sherab Giovannini
@Shaddy
Dec 06 2017 17:39
"create the thread with rust" is equal to thread::Builder::new()?
Steve Klabnik
@steveklabnik
Dec 06 2017 17:39
or thread::spawn
Judson Lester
@nyarly
Dec 06 2017 17:39
Is there an equivalent to quick_main in failure?
Steve Klabnik
@steveklabnik
Dec 06 2017 17:39
i don't belive so
Judson Lester
@nyarly
Dec 06 2017 17:42
Not a huge deal, but wanted to be sure before I undertook it
(to be clear: for this code here)
Sherab Giovannini
@Shaddy
Dec 06 2017 17:42
uhm, I guess a way to findout how to wait for a windows object
bah, I don't need anything guys, just thank for the time
just as you said, I need to spawn threads and implement a bind to WaitForSingleObject, what I wanted is to find a std way to reach WaitForSingleObject for a windows handle
and rust only implements WaitForSingleObject for thread.join() process.wait() and to acquire a global lock
so seems that there isn't a clear path to wait for a RawHandle
Judson Lester
@nyarly
Dec 06 2017 17:51
Actually: it's a copy and paste...
Sean
@seanr707
Dec 06 2017 17:58
Gitter app on mobile or just the app (web app) in general?
Judson Lester
@nyarly
Dec 06 2017 18:29
Hrm. I'm trying to switch from chain_error to failure, and I've got a method that returns a boxed Future... Future<_, Error=failure::Error> isn't Sized
Judson Lester
@nyarly
Dec 06 2017 18:35
Do I need to build my own error just to Box?
Sean
@seanr707
Dec 06 2017 18:37
don't box
Judson Lester
@nyarly
Dec 06 2017 18:38
Can't not - trying to return a Future
Sean
@seanr707
Dec 06 2017 18:38
Nvmnd then, sorry about that
Judson Lester
@nyarly
Dec 06 2017 20:06
So, do you prefer Ok(f()?) or f().map_err(|e| Error::from(e))?
Sherab Giovannini
@Shaddy
Dec 06 2017 22:11
This (question) one is really stupid, how do I pass arguments to a predefined function, passed to a thread?
hopefully I'm not required to only use a closure
Denis Lisov
@tanriol
Dec 06 2017 22:13
Why not use a closure to pass them?
std::thread::spawn(|| thread_main_function(arg1, arg2));
Steve Klabnik
@steveklabnik
Dec 06 2017 22:13
@Shaddy it's not 100% clear to me what you're asking exactly
Sherab Giovannini
@Shaddy
Dec 06 2017 22:18
today is not my day, honestly
xD
Steve Klabnik
@steveklabnik
Dec 06 2017 22:19
it's all good <3
Sherab Giovannini
@Shaddy
Dec 06 2017 22:19
xD
Sherab Giovannini
@Shaddy
Dec 06 2017 22:30
how do I send "unsafe *mut ptr's" between threads?
http://japaric.github.io/inherent/book/unsafe.html <= here should be the solution, just ignore
Denis Lisov
@tanriol
Dec 06 2017 22:35
That one looks out of date.
Steve Klabnik
@steveklabnik
Dec 06 2017 22:36
yeah wow
Sherab Giovannini
@Shaddy
Dec 06 2017 22:36
I'm trying to send a *c_void through a thread, the shortcut I did is to just convert to a u64 and move it, then reconvert
Steve Klabnik
@steveklabnik
Dec 06 2017 22:36
that's an old edition of the book
Sherab Giovannini
@Shaddy
Dec 06 2017 22:36
but guess that its not the best way
Denis Lisov
@tanriol
Dec 06 2017 22:36
Normally you don't send raw pointers. Why the need?
Sherab Giovannini
@Shaddy
Dec 06 2017 22:37
I'm doing native windows stuff
I have a winapi::HANDLE wich maps to a *mut c_void
a HANDLE normally is defined as PVOID in Windows but it is also a u64
so in this case, is not a problem
but what do you do in such cases?
Denis Lisov
@tanriol
Dec 06 2017 22:42
I'd probably wrap it in some other type and impl Send for that type. Once I read the documentation and am sure that the underlying object can be used from other threads.
Steve Klabnik
@steveklabnik
Dec 06 2017 22:44
same
Sherab Giovannini
@Shaddy
Dec 06 2017 22:55
thanks, that is what I was about to do, but not sure if its the right way