| 12 Jan 2024 |
 scanmountgoat | There may be a way to pass in a dedicated reader if the types impl BinRead. If not, you could try making an issue or PR. It should be a simple change. | 18:38:37 |
| scanmountgoat | * There should be a way to pass in a dedicated reader if the types impl BinRead. If not, you could try making an issue or PR. It should be a simple change. | 18:38:59 |
 awesomerly | can you explain what you mean by pass in a dedicated reader; i know that certain structs(?) or struct params(?) can have their own custom readers and writers | 18:39:20 |
| awesomerly | * can you explain what you mean by pass in a dedicated reader; don't certain structs(?) or struct params(?) have the ability to have their own custom readers and writers | 18:39:36 |
| awesomerly | i think that hacking on this is going to be my next project because I would want this to be more general to different versions of BSP | 18:40:39 |
| awesomerly | because this is particular to the TF2 version | 18:40:49 |
| awesomerly | maybe I should talk to the person who made this library once i'm more familiar with it | 18:41:07 |
| scanmountgoat | The binread trait is generic over anything that is Read + Seek. Some people opt to add read methods that take bytes or a file path for convenience. If a type T implements BinRead, you can use something like T::read_le(...) to read it or reader.read_le(...). https://docs.rs/binrw/latest/binrw/trait.BinRead.html | 18:41:20 |
| awesomerly | yea | 18:41:42 |
| scanmountgoat | It's possible they fully parse the file, so you would only be able to save not storing the entire file bytes in memory at once. | 18:42:12 |
| awesomerly | can you elaborate | 18:42:42 |
| awesomerly | but it does seem that way bc like the person who made this did a tf2 map viewer with it | 18:43:05 |
| awesomerly | so when you call the bsp::read(& [u8]) it goes thru the entire thing and parses it | 18:43:23 |
| awesomerly | the bsp file format has 64 lumps which point to different types of data like the bsp tree, lighting, etc | 18:44:27 |
| scanmountgoat | What I mean is that you might have the entire "file" in memory as a Rust struct already. If you really need to save memory, you may need to rewrite it to support reading part of the data. Personally, I would assume that most people have 8+ GB of ram and just read it into memory. Your needs may differ of course depending on where you're running your code. | 18:45:51 |
| awesomerly | yup | 18:46:13 |
| awesomerly | im sure that it's not that bad lol | 18:46:23 |
| scanmountgoat | Some projects opt to just read the header and read the data sections from the file as needed if the file is multiple GB in size | 18:46:36 |
| awesomerly | that's what I was planning on doing | 18:46:46 |
| 16 Jan 2024 |
 maya | Hi there, simple question, does BinRead::read support non blocking I/O using TcpStream::set_nonblocking(true) ? I have issues and I need to know if I'm doing something wrong or this is simply unsupported 🙂 | 16:28:10 |
| maya | I mean I'm fine if the call block while inside the BinRead::read function, inside the packet, but it would be great if the first read ended-up in a WouldBlock state if the error could bubble up | 16:31:33 |
 snover | maya: any i/o error other than Interrupted should return immediately | 16:45:07 |
| maya | But WouldBlock could be returned mid packet, loosing data, right ? | 16:45:54 |
| snover | i don’t know when this error occurs; the example in documentation for set_nonblocking suggests it would not be mid-packet since it always retries to fill the same buffer if this error is received, but i could imagine that it might happen for data that spans multiple packets, or it might not and it is only raised like during socket establishment or something | 16:51:17 |
| 17 Jan 2024 |
| maya | I've checked deeper, and it fills the &mut buf partially and then returns WouldBlock, which in the end, is the same as blocking, but the key is that it is retried on the same buffer | 22:55:03 |
| maya | * I've checked deeper, and it fills the &mut buf partially and then returns WouldBlock, which in the end, is the same as blocking if you retry till EOF, but the key is that it is retried on the same buffer | 22:55:27 |
| maya | I think the retry mechanism would need to be implemented on calls to read_exact in implementations of BinRead | 22:57:08 |
| maya | Until the buffer is fully read | 22:57:20 |
| maya | Which is unideal because binrw isn't aware of how to wait for the fd readiness | 22:58:10 |
| 24 Jan 2024 |
|  alice joined the room. | 03:18:23 |
