These are chat archives for rust-lang/rust

18th
Feb 2017
Roman Ivanov
@sirgl
Feb 18 2017 06:56
Hello! I'm trying to understand what exactly lvalue context is. How to understand where will be used Deref and where DerefMut. Can anyone explain?
Michal 'vorner' Vaner
@vorner
Feb 18 2017 08:04
@sirgl I don't know for sure what exactly it is in rust, since there's no standard for it, but basically, if it's on a left side of an assignment or something similar, then it's an lvalue context. Any place that is written into is.
VJ
@00imvj00
Feb 18 2017 08:43
guys, i am facing stack overflow issue while building simple large binary tree with recursion. plz need help.
Joonas Koivunen
@koivunej
Feb 18 2017 10:05
@i-m-v-j: do you have to use recursion?
VJ
@00imvj00
Feb 18 2017 10:49
how to do it without recursion ? i tried, again it was throwing same . @koivunej
Joonas Koivunen
@koivunej
Feb 18 2017 10:52
@i-m-v-j you loop over a local datastructure instead of recursing. it'd be easier to explain if you shared some code, for example in https://play.rust-lang.org
VJ
@00imvj00
Feb 18 2017 10:55
@koivunej https://play.rust-lang.org/?gist=fcaa38981c2c40ad6f3bf23b84028c7b&version=stable&backtrace=1 here is the code. it works fine for smaller tree, but causes stack overflow when i put about 100,000 entries.
Denis Lisov
@tanriol
Feb 18 2017 11:01
@i-m-v-j Seems like the tree is not balanced; inserting items in ascending order is actually the worst case for it.
VJ
@00imvj00
Feb 18 2017 11:02
hmm, but still it should work right ? i tried with collections btree , it was working.
it should take long time but it should't crash.
Mike Lubinets
@mersinvald
Feb 18 2017 11:02
@i-m-v-j there is a common practice to iteratively find "successor"/"predecessor" and append new nodes to them. But in any case balancing is required to make a tree effective
Joonas Koivunen
@koivunej
Feb 18 2017 11:04
@i-m-v-j yeah I cannot see why it would panic with stack overflow, testing now... getting really slow after 200k elements :)
VJ
@00imvj00
Feb 18 2017 11:05
hmm. but is it crashing ?
Sergey Noskov
@Albibek
Feb 18 2017 11:05
@koivunej , Seems like you're storing the tree itlsef on a stack. Despite performance and other issues with it, you can solve stack overflow problem by creating it on the heap with let tree = Box::new(Tree::new());. It inserts 1m nodes on my laptop, but is very slow.
VJ
@00imvj00
Feb 18 2017 11:07
how can we solve the problem of being slow ?
@Albibek any recommendations ?
Joonas Koivunen
@koivunej
Feb 18 2017 11:07
@Albibek (you probably meant to reply to @i-m-v-j), I can't see how that'd be the reason, tree contains already Option<Box<_>>
@i-m-v-j what rust version are you using and on what platform?
VJ
@00imvj00
Feb 18 2017 11:09
macos , rust 1.15
latest stable
but with binary trees , with 1M nodes, it is suppose to be slow right ?
Sergey Noskov
@Albibek
Feb 18 2017 11:10
@koivunej Option<Box<_>> still takes space on main's stack - around usize, I suppose, that's why 8Mb stack is overflown after around 100k
Joonas Koivunen
@koivunej
Feb 18 2017 11:11
@Albibek but it will be the same single usize for the lifetime of the application, or am I missing something? what would make it grow?
VJ
@00imvj00
Feb 18 2017 11:11
it is taking very much time, like more than 2 min for 1M elements
Denis Lisov
@tanriol
Feb 18 2017 11:13
@i-m-v-j Your time is quadratic (proportional to N*N) as you need to traverse all the previous elements to insert the next one. You need to balance it on insertion for it to be fast.
Joonas Koivunen
@koivunej
Feb 18 2017 11:15
i'm looking at it doing 80 insertions per sec at over 500k. I do not think it's going to stack overflow, unlikely to run out of heap either
VJ
@00imvj00
Feb 18 2017 11:16
ok.
so u Boxed it when created new tree @koivunej or same code as i sent you ?
Joonas Koivunen
@koivunej
Feb 18 2017 11:19
@i-m-v-j the code copied from play.rust-lang.org link
VJ
@00imvj00
Feb 18 2017 11:20
ok, then its ok.
but then why in my comp, it is stack orverflowing when i am adding 1M, @koivunej
i tried with boxing , then it stopped crashing but, it was slow, which is fine i guess.
Denis Lisov
@tanriol
Feb 18 2017 11:23
@i-m-v-j It should not crash. I hope you haven't tried printing it after inserting 1M elements, as this could actually crash.
VJ
@00imvj00
Feb 18 2017 11:24
@tanriol without printing, it crashed for 100K elements.
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Joonas Koivunen
@koivunej
Feb 18 2017 11:25
@i-m-v-j can you reproduce the crash?
VJ
@00imvj00
Feb 18 2017 11:28
Yes every time if it's more then 100k
It crashes
Joonas Koivunen
@koivunej
Feb 18 2017 11:34
@i-m-v-j are you sure you have a recompiled version, are you using cargo run or ....? can't get it to run out stack in debug or optimized builds
VJ
@00imvj00
Feb 18 2017 11:34
i am using cargo run
shoud i do cargo build then use it ?
Joonas Koivunen
@koivunej
Feb 18 2017 11:35
@i-m-v-j no, cargo run will compile if needed. the only thing to overflow the stack I can see is by printing out the large tree, sorry. make sure you are not doing that
VJ
@00imvj00
Feb 18 2017 11:39
i recompiled with cargo build, and it is not crashing. @koivunej
JasonKleban
@JasonKleban
Feb 18 2017 19:25
We can destructure tuple parameters of a function, but what is the syntax for aliasing the tuple and referring to it as the whole tuple also. Like |(l, r) as pair| if l = 0 { pair } else { (l - 1, r) }?
or do we have destructure with a let separately?
Sergey Noskov
@Albibek
Feb 18 2017 19:38
@JasonKleban th ebook says you can use name @ pattern syntax in match statements: https://doc.rust-lang.org/book/patterns.html
probably would work in other contexts
JasonKleban
@JasonKleban
Feb 18 2017 19:40
I tried that | pair @ (l, r) | but I got an error pattern bindings are not allowed after an '@'
Sergey Noskov
@Albibek
Feb 18 2017 19:41
oh I see, you need to specify a pattern after @, not bindings
Michal 'vorner' Vaner
@vorner
Feb 18 2017 19:56

Hello. Let's say I have an enum like this:

enum Either {
    A(A),
    B(B),
}

Furthermore, both types A and B implement some trait X. Is there a way to tell the compiler to derive the implementation for the enum Either (in the obvious way, delegating the calls to whatever is inside at the time)? Maybe some magic crate with custom derive? Somehow, I don't have an idea what to search through in crates.io.

Tim
@tikue
Feb 18 2017 22:33
@vorner I've just don't it manually
Done*
Pavel Meledin
@btbvoy
Feb 18 2017 22:37

Hi everyone, please advise a solution / workaround for such a use case:

if structcontains a & to some Fnon attempt to use #[derive(Debug)] for that struct compiler says that there is no Debug impl for Fn type. It seems I can’t provide any mimic impl since Fn type isn’t defined in my crate. Is there some workaround how to still have Debug derive for struct which contains & Fn ?

Ashley Mannix
@KodrAus
Feb 18 2017 22:58
@btbvoy you could wrap the Fn in a new type and derive debug for that, like this quick playground
I think that would be preferable to manually implementingDebug for your type, since the function wrapper can be reused for other types that can derive Debug
Pavel Meledin
@btbvoy
Feb 18 2017 23:02
@KodrAus your idea with wrapper around Fn sounds like the only possible solution :-) thanks for hint about that I didn’t think about such solution.
still would be nice to be supported out of box or at least to have ability to implement on your own
@KodrAus thanks for help :-)
Ashley Mannix
@KodrAus
Feb 18 2017 23:03
Wrapper types are your friend ;)
@btbvoy No problem! :)
Pavel Meledin
@btbvoy
Feb 18 2017 23:15
@KodrAus JFYI: There is a crate: https://github.com/mcarton/rust-derivative which allows at leat add ignore attribute (like serde does) so at least for keep having Derive for struct it works.
Ashley Mannix
@KodrAus
Feb 18 2017 23:17
@btbvoy Ah nice :+1: I'll keep that in mind for future
Pavel Meledin
@btbvoy
Feb 18 2017 23:18
@KodrAus huge thanks to @RomanAkberov who actually pointed me to that crate