These are chat archives for rust-lang/rust

2nd
Apr 2018
Kelly Thomas Kline
@kellytk
Apr 02 2018 02:44
Is the intersection of concurrent and async a reasonable description for the requisite primitives of parallel?
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 10:37
How can I combine data from two results into one
Is this answer demonstrating the same thing that I want to achieve? I am not sure :/
Denis Lisov
@tanriol
Apr 02 2018 10:39
What do you want to achieve?
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 10:40
I want to send a result that has two data items. Both are received from different result objects.
VJ
@00imvj00
Apr 02 2018 10:41
@AyushyaChitransh if you are using futures streams then you can combine using select combinator.
Denis Lisov
@tanriol
Apr 02 2018 10:44
Do you want to preserve the errors?
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 10:48
No I do not want to preserve errors. And as I looked up I am not using futures
Denis Lisov
@tanriol
Apr 02 2018 10:49
Then I'd use something like
match (r1, r2) {
    (Ok(v1), Ok(v2)) => Ok((v1, v2)),
    _ => Err(()),
}
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 10:54

Let me say what I understood:

r1,r2 are the existing results, and v1,v2 are the values that I want in the new result. Am I right?

Denis Lisov
@tanriol
Apr 02 2018 10:57
Exactly.
Here I just combine them into a tuple, but you can do what you need instead :-)
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 10:57
:) thanks
Mike Cardwell
@mikecardwell
Apr 02 2018 11:01
Can anyone explain to me how I deal with the problem here - https://play.rust-lang.org/?gist=58f055508350e3d8da94fb88b190dea0&version=nightly - In the first and_then, I check if the client is authenticated. If not, I want to authenticate, otherwise I want to continue.
Denis Lisov
@tanriol
Apr 02 2018 11:37
@mikecardwell The and_then can return only one future type, but future::ok returns a FutureResult while client.login returns a different type.
Mike Cardwell
@mikecardwell
Apr 02 2018 11:39
Yeah, I understand that. I just don't know how to make it work
Do I need to cast something to something else somehow?
Do I need to annotate a type somewhere?
Implement some trait I'm unaware of?
Or is this approach a dead end?
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 11:55
How can I retrieve Option from Map<Future<Item=Option<_>>>?
I was unable to find unwind or unwrap for map, so how do we get values out of maps
Mike Cardwell
@mikecardwell
Apr 02 2018 11:56
That type is a Future which resolves to an Option. You need to run the future, and the option will then be passed to your closure (I think)
Ayushya Chitransh
@AyushyaChitransh
Apr 02 2018 11:58
Any ideas where I can know how to run future?
Mike Cardwell
@mikecardwell
Apr 02 2018 12:09
You need to use an Executor. See spawn function on https://docs.rs/futures/0.1.20-beta/futures/executor/index.html
Denis Lisov
@tanriol
Apr 02 2018 12:10
@mikecardwell There's future::Either, or you can force trait objects for that closure.
Mike Cardwell
@mikecardwell
Apr 02 2018 12:10
I was just about to say I've got around the issue by using a Boxed future
I will check out future::Either
Thanks
Fredrik Portström
@portstrom
Apr 02 2018 13:19

Can anyone tell why this fails? I have an Option<String> and I need to pass it to a function that takes an Option<&str>.

fn main() {
    b(Some("".to_owned()).as_ref());
}
fn b(_: Option<&str>) {}

https://play.rust-lang.org/?gist=84493d2593777a72f60708597851bc63&version=stable

Denis
@mexus
Apr 02 2018 13:22
because &String&str:
  = note: expected type `std::option::Option<&str>`
             found type `std::option::Option<&std::string::String>`
@portstrom consider using a generic:
fn main() {
    b(Some("".to_owned()).as_ref());
}
fn b<T: AsRef<str>>(_: Option<T>) {}
Fredrik Portström
@portstrom
Apr 02 2018 13:25
If I do &x and x is a String, that works with &str. I was expecting the same to apply within Option. I'll try the generic. Thanks.
Denis
@mexus
Apr 02 2018 13:26
yes it's a little bit complicated, since there is no conversion from T<A> to T<B> even if A implements B
but np anyhow
Fredrik Portström
@portstrom
Apr 02 2018 13:31
I'm wondering if that would cause duplicate code to be generated for the function for each type of the argument.
I could also do b(option.as_ref().map(|value| value as _)).
Denis
@mexus
Apr 02 2018 13:35
i don't think you should care about that
using a generic is so much better, you can even pass an Option<String> without taking a reference at all if you want the value to be moved, like
fn main() {
    b(Some("".to_string()));
}
fn b<T: AsRef<str>>(_: Option<T>) {}
Fredrik Portström
@portstrom
Apr 02 2018 13:46
That works. Thanks!
Denis
@mexus
Apr 02 2018 13:47
yw
Scott J Maddox
@scottjmaddox
Apr 02 2018 15:19

Hi everyone! I'm writing some embedded-style code (no-std library) for eventual wasm32 deployment, and am finding I have to break some conventions around struct initialization in order to prevent stack overflow, i.e. defining init associated functions instead of new for large structs. Since embedded is intended to be a target for epoch 2018, I thought I would see: is anyone is planning to address this issue?

I put together an example showing the stack overflow issue here: https://play.rust-lang.org/?gist=217d5a3fd60801170d99700d69444ca4&version=stable

Denis
@mexus
Apr 02 2018 15:27
hi @scottjmaddox ! i'm not into embedded, but could you please clarify a bit? i don't really get two things: how does usage a different name helps and why is the problem embedded-related (since stack overflow happens on non-embedded systems as well)?
Scott J Maddox
@scottjmaddox
Apr 02 2018 15:32
@mexus I'll put together an example of my fix, but basically instead of following the rust convention of new associated functions, I have to write init functions that take in a &mut and intialize each member.
The problem is more relevent for embedded, because you can't just Box things up
I agree that it's a bit of a problem in general, though
Denis
@mexus
Apr 02 2018 15:34
so basically it's just about the conventions isn't it? i mean one can easily pass an argument to a new method and i suppose it doesn't break anything
btw i can't find the "convention" on the internet
Scott J Maddox
@scottjmaddox
Apr 02 2018 15:43
Yes, it's partly a convention issue. A reasonable solution could certainly be to have a different convention for embedded / large structs. It would be nice to have a solution that didn't require a bunch unsafe, though. As you'll see once I finish my example, currently, the code ends up littered with unsafe. There's some fundamental reasons why this is the case, but perhaps with a new initialization primitive it could be avoided? In particular, if the rust compiler had first-class support for initializing a struct from a pointer, rather then relying on inlining optimizations, then this problem would likely go away.
And by pointer, I mean mutable reference.
Or pointer...
Or byte slice, maybe.
Denis
@mexus
Apr 02 2018 15:45
hm, let's see your example then :)
(i think i'm starting to get your point but nevertheless)
Scott J Maddox
@scottjmaddox
Apr 02 2018 15:47
Sorry, I'm stripping down some init code I have, but for some reason I'm still running into stack overflow. Once I figure out why and fix it, I'll post it
Scott J Maddox
@scottjmaddox
Apr 02 2018 15:52
Actually, I commented something wrong in it... The array init does not overflow
So, having stripped it down, it looks like it is possible to remove all of the unsafe code around the actual initialization.
So I think you were right, @mexus . This is really just a convention issue.
Denis
@mexus
Apr 02 2018 15:58
ah now i see your point
and why don't you pass the memory chunk as an argument to an associated function?
Scott J Maddox
@scottjmaddox
Apr 02 2018 15:59
Yeah, i was just about to say that I could do that
I think that's the right direction to go
Have a new function that requires a sufficiently large slice to be passed in.
Or, even better, an array, so that the size can be compile-time guaranteed
Denis
@mexus
Apr 02 2018 16:04
i'd say arrays have a big disadvantage in a way that you can't split them
so if you have more than one field.. well, you have a problem :)
Scott J Maddox
@scottjmaddox
Apr 02 2018 16:06
Well, you can with mem::transmute, but then I guess you're bringing unsafe back in. But yeah, in the general case, it's unsafe no matter what. If the unsafe can be contained in the new, that's not too bad
Array is good, because then the OS (or whatever), can use the type system to decide the alloc size
No chance for error
Denis
@mexus
Apr 02 2018 16:07

idk if you can transmute it:

mem::transmute<T, U> takes a value of type T and reinterprets it to have type U. The only restriction is that the T and U are verified to have the same size.

Scott J Maddox
@scottjmaddox
Apr 02 2018 16:12
Still working out the details, but the idea is to pass in an array of the proper size, and return the new Struct.
I'm not sure this will work though, because I would still be depending on the compiler to inline the function
Denis
@mexus
Apr 02 2018 16:13
(just want to mention that it's possible to force the LLVM to inline a function of your choice)
Scott J Maddox
@scottjmaddox
Apr 02 2018 16:14
Yeah, I might try to use that. Does inline(always) work even on debug builds?
Denis
@mexus
Apr 02 2018 16:16
tbh i've never checked, but i don't see any reason for the debug build to be anyhow special on the directive
Denis
@mexus
Apr 02 2018 16:23
btw isn't this receiving uninitialized memory from the embedded OS just a.. heap allocation?
and what you really need is simply heap-allocated objects rather than stack-allocated ones? at least for certain cases. which is btw also the case for non-embedded environments
Michal 'vorner' Vaner
@vorner
Apr 02 2018 16:33
Hello. I'd like to try implementing a procedural macro (I want an attribute that decorates functions passed to it, but it needs to examine the prototype to do that). Is there an up-to-date documentation? I've seen https://tinkering.xyz/introduction-to-proc-macros/ ‒ is it up to date or does the world around them move too fast? (and I know they are nightly only for now)
Denis
@mexus
Apr 02 2018 16:36
@scottjmaddox as i mentioned before i'm not into embedded (though i'd like to give it a try at some point of time), but i was told there is a very nice blog on the topic -- https://os.phil-opp.com/ , which also covers custom allocators and stuff
Scott J Maddox
@scottjmaddox
Apr 02 2018 16:38
@mexus thanks, I'll check it out
Denis
@mexus
Apr 02 2018 16:38
np, hope it helps
Scott J Maddox
@scottjmaddox
Apr 02 2018 16:40
@mexus regarding your question about heap-allocated objects, yes, you're correct. But in embedded, it's typical to have many different custom allocators, so a simple box syntax won't work. As far as I'm aware, Rust does not really support many specific allocators, and hence the challenges I'm facing.
Also, I would prefer to stay on stable.
Denis
@mexus
Apr 02 2018 16:41

it's typical to have many different custom allocators

never knew that

well probably it'd be better to wait for someone who has some experience with embedded in rust
not like me :)
Scott J Maddox
@scottjmaddox
Apr 02 2018 16:42
Really, I should say it's common in game dev. In embedded (like really small processors), it's common to statically allocate everything
In modern large embedded, it's probably fine to use a single allocator
Denis
@mexus
Apr 02 2018 16:43
btw have you tried asking the question on the irc?
it seems to me that this slack channel is not as popular as #rust on irc.mozilla.org
Scott J Maddox
@scottjmaddox
Apr 02 2018 16:43
Good to know. No, I haven't
Thanks for the tip
Denis
@mexus
Apr 02 2018 16:44
:+1:
Denis Lisov
@tanriol
Apr 02 2018 16:53
@scottjmaddox There was an RFC accepted for "placement new", which is in process of being unaccepted (summary).
Scott J Maddox
@scottjmaddox
Apr 02 2018 18:09
@tanriol Thanks, was just reading through the relevant issues, etc., and left a comment requesting a ptr::write-like intrinsic
Dylan DPC
@Dylan-DPC
Apr 02 2018 18:52

it seems to me that this slack channel is not as popular as #rust on irc.mozilla.org

Don't forget the user's forum :P