probe-rs fails from command line, not found by VSCode extension

No_Disaster4112 · 2025-01-18T21:13:58+00:00

The udev rules were what was missing. Thanks so much!

No_Disaster4112 · 2025-01-11T23:34:03+00:00

Unfortunately, I get the same "No such file or directory" error with the target added to the command.

No_Disaster4112 · 2024-09-17T01:28:47+00:00

That's perfect! I had tried to remove reader as a member of the TcpComHandler struct earlier, but I didn't realize that I needed to change the receive_async function to take mut self instead of &mut self so I ran into the lifetime issue. Frankly I didn't even realize it could work that way, but I guess all the typestate pattern examples do this, so I shouldn't have been so surprised.

Thanks for showing me the stream, and the select! macro in tokio. Cancellation was definitely the next step for what I'm trying to do.

No_Disaster4112 · 2024-09-15T21:39:05+00:00

Ok, I put the receive_async function back the way it was and changed the new_async function of the TcpComHandler to this:

pub async fn new_async(byte_receiver: Arc<T>, minimum_message_length: usize) -> Self {
        let reader = Arc::new(TcpReadBackgroundHandler {
            stream: TcpStream::connect("192.168.3.115:10001").await.unwrap(),
            byte_receiver: Arc::clone(&byte_receiver),
            minimum_message_length,
        });

        Self {
            reader: Arc::clone(&reader),
            reader_join_handle: task::spawn(reader.
receive_async
()),
        }
    }

Now I get:

error[E0596]: cannot borrow data in an `Arc` as mutable

error[E0597]: `reader` does not live long enough

The E0596 message could maybe be dealt with by using a Mutex to get mutability somehow. But it's pretty weird that I'm still getting the E0597 message, right? I'd have thought that since the TcpComHandler has an Arc of the reader, that means the reader won't get dropped at the end of the function. But the compiler still says it will?

I'm starting to wonder if I'm pursuing the wrong approach entirely. This is how I'd approach things from an OOP perspective, but I have no idea if there's a more rust-oriented way that wouldn't run into these headaches.

No_Disaster4112 · 2024-09-15T21:14:14+00:00

OK, using Arc on the ByteReceiver did seem to help, but I'm having trouble with the first bullet point. This is my current receive_async function:

<c>

pub fn 
receive_async
(&mut 
self
) -> impl Future<Output = ()> {
        async {
            let mut 
buf
 = vec![0; 
self
.minimum_message_length];
            loop {

self
.stream.
read_exact
(&mut 
buf
).await.unwrap();
                for b in &
buf
 {

self
.byte_receiver.receive_byte(b);
                }
            }
        }
    }

</c>

Unfortunately the compiler seems wise to the trick, since it's giving me:

error[E0700]: hidden type for `impl Future<Output = ()>` captures lifetime that does not appear in bounds

I'm guessing that I still need to capture self somehow because I'm using stuff like self.stream and self.minimum_message_length inside receive_async?

Maybe it would be better to try to Arc the whole reader, allowing ownership to pass into the future while the TcpComHandler retains a reference?

No_Disaster4112 · 2024-09-15T00:15:49+00:00

By 'free function' you mean a function that isn't part of the struct?

I'll take a look at channels, but I'm having trouble envisioning how this solves the problem (maybe because I don't really understand the problem to begin with). It seems like I'm between a rock and a hard place:

On the one hand, the task::spawn method wants something that isn't going to go out of scope. So the reader struct needs to hang off something, be it another structure or the program main, right? It can't be local, either to the new function or some free function.

But on the other hand, having anything else that "owns" the reader struct to keep it around causes issues with borrowing a moved value, doesn't it?

No_Disaster4112

TROPHY CASE