These are chat archives for rust-lang/rust

10th
Apr 2019
Javier L. Velasquez
@nycjv321_gitlab
Apr 10 01:13
If I bind to a UdpSocket and send a broadcast message to an ip should I expect that UdpSocket#recv to recieve data that is sent back as a part of broadcast message? Trying to test SSDP and I'm not understanding why data is never sent to recv. After sending the packet via UdpSocket#send I configure the socket to be nonblocking and loop ignoring io::ErrorKind::WouldBlock errors. Nothing is ever received. I do notice data sent back to the source ip over wireshark. So I know I'm doing something wrong. I just don't know what.
    // bindingSocket is a UdpSocket 
    bindingSocket.connect("239.255.255.250:1900").expect("connect function failed");
    bindingSocket.send(message.as_bytes()).expect("couldn't send data");

    bindingSocket.set_nonblocking(true).unwrap();

    let mut buf = [0; 10];
    let num_bytes_read = loop {
        match bindingSocket.recv(&mut buf) {
            Ok(n) => break n,
            Err(ref e) if e.kind() == io::ErrorKind::WouldBlock => {
              println!("waiting") // it basically loops printing infintely. 
            }
            Err(e) => panic!("encountered IO error: {}", e),
        }
    };
kandyjam
@kandyjam
Apr 10 03:09
hi,anyone ,would you please tell me how to parse html from hyper response?
Denis Lisov
@tanriol
Apr 10 07:18
@kellytk I'm not sure about the actors and actix-web, but when working with plain tokio .wait() is usually a mistake. If this is happening in futures context, it is likely to hang.
In futures context, .wait() is almost never correct. The only correct usage I know is waiting on a receiving side of a futures channel in a sync thread.
Kelly Thomas Kline
@kellytk
Apr 10 07:20
Thanks @tanriol. Using Client::new() the code behaves as expected so it seems fine but perhaps when changing to using with_connector() the potential wait() issue you describe comes into play?
Kelly Thomas Kline
@kellytk
Apr 10 07:25
Do you know how I can avoid using .wait()?
Kelly Thomas Kline
@kellytk
Apr 10 09:11
It's solved. Thank you @tanriol for the clue
svraghavan
@svraghavan
Apr 10 21:32
Hi, Can anyone pls point me to good Rust blogs that I can read to improve my Rust knowledge.
Denis Lisov
@tanriol
Apr 10 21:59
There are lots of links to various blog posts from the this week in Rust digest.
Georg Semmler
@weiznich
Apr 10 22:21
I assume that there is no way to make something like this working without specialization?
To elaborate a bit on my use case: I need something that is able to decide at compile time if two closures are equal or not and implement a certain trait based on that information.
Denis Lisov
@tanriol
Apr 10 22:23
Note that equality for closures is a nontrivial question :-)
Why do you need to do that, especially in compile time?
Georg Semmler
@weiznich
Apr 10 22:35
I know that closure types are only equal if they refer to the same closure, so I try to abuse that to differentiate between several user created values (The alternative here is to require them to create new types for each call to that method, which involves a overhead that is to big for that functionality in my opinion). Now it is required by some outside constrains that this type implements a given trait and basically sets Output = True if the type parameter of the trait is equal with self and otherwise Output = false. For most of the other impl's of that trait those impl's are written in a brute force manner, meaning each affected type has it's own concrete impl. That strategy obviously won't work if one of the type parameters is a closure because I cannot specify this type :(
Denis Lisov
@tanriol
Apr 10 22:40
And you do understand that the user can create multiple closure values of the same type with different behavior when they're called, correct?
AFAIK, yes, without specialization this will not work in compile-time, only in runtime.
Georg Semmler
@weiznich
Apr 10 22:43
The closures aren't called anywhere, they are just use as marker types so the runtime behavior does not matter here.
Ichoran
@Ichoran
Apr 10 22:45
It's really easy to create empty enums as marker types. If you just want markers, why not do that instead of abusing closures?
Georg Semmler
@weiznich
Apr 10 22:47
The markers are created by a macro. Creating a empty enum there would require to get a valid ident from somewhere.
Ichoran
@Ichoran
Apr 10 22:48
How is the user supposed to call this code?
Georg Semmler
@weiznich
Apr 10 22:50
my_macro!(existing_identifier)
Denis Lisov
@tanriol
Apr 10 22:50
You can create structs in a macro as well (example), but then you'll have the problem of implementing the comparison for them :-)
Ichoran
@Ichoran
Apr 10 22:51
Okay, and some of these existing_identifiers can be made into something that has a type parameter equal to itself, and some can't?
Georg Semmler
@weiznich
Apr 10 22:52
I don't have the required information in that macro to implement all required traits for the marker.
Ichoran
@Ichoran
Apr 10 22:57
Well, my instinct would be--with my very limited understanding of the problem--would be to make them create a new type for each call. It's not terribly hard, and if the behavior depends on a nonobvious type computation it may be better to make it explicit.
Denis Lisov
@tanriol
Apr 10 23:02
My instinct would be to recheck whether this has to be done in compile time to make it compile or may be done in runtime likely optimized to compile-time anyway.
Georg Semmler
@weiznich
Apr 10 23:06
Yes this has to be a compile time thing because otherwise it does not fit well into the safety scheme of that crate :wink:
I will think about if it's possible to use a concrete marker type there, but spontaneously I think that I missing information about other types there. Getting those information there would complicate the api by magnitudes. (Like instead of 1 argument having 10 or so…)
Anyway, at least that tells me that I didn't miss something obvious here, so thanks for the help.
Denis Lisov
@tanriol
Apr 10 23:10
Usually safety-related checks don't need a boolean telling whether the types are equal, just a compile error if they are not :-) anyway, if you decide the problem is worth sharing, I'll try to help :-)
Georg Semmler
@weiznich
Apr 10 23:18
Oh, that thing is part of a bigger machinery that needs the information because it checks if something is used never, once or multiple times (and prevents the later one).
Sharing that problem is probably not worth the trouble, because that part of diesel and that means you need to understand probably a bigger portion of diesel :wink:
(Generally speaking: I've trying to find a approach for table aliasing that does not require defining types in multiple different locations)
Denis Lisov
@tanriol
Apr 10 23:38
Point taken, domain-specific safety requirements are a difficult area :-) will think about that.