4 ms·

it does an ok job with this task: use std::fs::File; use std::io::{self, BufReader, Read}; fn read_file_character_by_character(path: &str) -> io::

by raggi 3y ago

it does an ok job with this task: use std::fs::File; use std::io::{self, BufReader, Read}; fn read_file_character_by_character(path: &str) -> io::Result<()> { // Open the file in read-only mode. let file = File::open(path)?; // Create a buffered reader to read the file more efficiently. let reader = BufReader::new(file); // `chars` method returns an iterator over the characters of the input. // Note that it returns a Result<(char, usize), io::Error>, where usize is the byte length of the char. for char_result in reader.chars() { match char_result { Ok(c) => print!("{}", c), Err(e) => return Err(e), } } Ok(()) } fn main() { let path = "path/to/your/file.txt"; if let Err(e) = read_file_character_by_character(path) { eprintln!("Error reading file: {}", e); } }

woodruffw 3y ago
If we're being sticklers, this isn't reading character-by-character: it's performing a buffered read, which then gets iterated over.
- raggi 3y ago
  here's what it does if i feed your nit pick into it verbatim: use std::fs::File; use std::io::{self, Read}; use std::str::from_utf8; fn read_file_character_by_character(path: &str) -> io::Result<()> { // Open the file in read-only mode. let mut file = File::open(path)?; let mut buffer = [0; 4]; // UTF-8 character max byte length let mut temp_buffer = vec![]; while let Ok(bytes_read) = file.read(&mut buffer[..1]) { // Read byte by byte if bytes_read == 0 { // End of file break; } temp_buffer.push(buffer[0]); if let Ok(s) = from_utf8(&temp_buffer) { if s.chars().count() == 1 { // Complete character read print!("{}", s); temp_buffer.clear(); // Clear temp buffer for next character } } } Ok(()) } fn main() { let path = "path/to/your/file.txt"; if let Err(e) = read_file_character_by_character(path) { eprintln!("Error reading file: {}", e); } }
  - comex 3y ago
    Unlike the original version, this version compiles and seems to basically work correctly. However, the design is misleading: `buffer` is declared as an array of 4 bytes but only the first byte is ever used. The code also has suboptimal performance and error handling, though that's not the end of the world.
    - raggi 3y ago
      all true, as I said in another fork of the thread, this comes down to part of what humans will still be valuable for in this loop: distilling poor requirements into better requirements.
- noncoml 3y ago
  I wouldn't say it's a nit. The file may be 10s of GB. Do you want to read it to a string?
  - raggi 3y ago
    The buffered read didn’t do that, it used the default buffered reader implementation. IIRC that implementation currently defaults to 8kb buffer windows which is a little too small to be efficient enough for high throughput, but substantially more performant than making a syscall per byte, and without spending too much memory.
    - noncoml 3y ago
      I was talking about this: let mut file = File::open(path)?; let mut contents = String::new(); file.read_to_string(&mut contents)?;
- deathanatos 3y ago
  The original prompt is a bit under-specified. (But hey, that certainly matches the real world!) You're going to have to buffer at least a little, to figure out where the USV / grapheme boundary is, depending on our definition of "character". To me, a BufReader is appropriate here; it avoids lots of tiny reads to the kernel, which is probably the right behavior in a real case. To me, "read character by character" vaguely implies something that's going to yield a stream of characters. (Again, for some definition there.)
raggi 3y ago
fwiw, the benchmark that matters really has nothing to do with authoring code. the typing of code is the easy part even though it's a part a lot of folks are somewhat addicted to. the things which have far more value are applying value judgements to requirements, correlating and incorporating sparse and inaccurate diagnostic information into a coherent debugging strategy, and so on. there will come a time when it can assist with these too, probably first on requirements distillation, but for more complex debugging tasks that's a novel problem solving area that we've yet to see substantial movement on. so if you want to stave off the robots coming for you, get good at debugging hard problems, and learn to make really great use of tools that accelerate the typing out of solutions to baseline product requirements.
comex 3y ago
Only problem is that the critical `chars` method doesn't actually exist. Rust's standard library has a `chars` method for strings, but not for Readers. (Also, the comment about the iterator element type is inconsistent with the code following it. Based on the comment, `c` would be of type `(char, usize)`, but then trying to print it with {} would fail because tuples don't implement Display.)
- raggi 3y ago
  good catch. feeding it the error output of rustc it then produces: use std::fs::File; use std::io::{self, Read}; fn read_file_character_by_character(path: &str) -> io::Result<()> { let mut file = File::open(path)?; let mut contents = String::new(); file.read_to_string(&mut contents)?; for c in contents.chars() { println!("{}", c); } Ok(()) } fn main() { let path = "path/to/your/file.txt"; if let Err(e) = read_file_character_by_character(path) { eprintln!("Error reading file: {}", e); } }
  - phaer 3y ago
    But this doesn't read the file char-by-char, but uses buffering to read it into a string
    - scottlamb 3y ago
      What would you expect? There's no OS API for "read one character", except in say ASCII where 1 byte = 1 code point = 1 character. And it'd be hideously inefficient anyway. So you either loop over getting the next N bytes and getting all complete characters so far (with some extra complexity around characters that cross chunk boundaries) or you read the whole thing into a single buffer and iterate the characters. This code does the latter. If this tool doesn't have the ability to respond by asking requirements questions, I'd consider either choice valid. Of course, in real life, I do expect to get requirements questions back from an engineer when I assign a task. Seems more practical than anticipating everything up-front into the perfect specification/prompt. Why shouldn't I expect the same from an LLM-based tool? Are any of them set up to do that?

by raggi 3y ago

woodruffw 3y ago

If we're being sticklers, this isn't reading character-by-character: it's performing a buffered read, which then gets iterated over.

raggi 3y ago
here's what it does if i feed your nit pick into it verbatim: use std::fs::File; use std::io::{self, Read}; use std::str::from_utf8; fn read_file_character_by_character(path: &str) -> io::Result<()> { // Open the file in read-only mode. let mut file = File::open(path)?; let mut buffer = [0; 4]; // UTF-8 character max byte length let mut temp_buffer = vec![]; while let Ok(bytes_read) = file.read(&mut buffer[..1]) { // Read byte by byte if bytes_read == 0 { // End of file break; } temp_buffer.push(buffer[0]); if let Ok(s) = from_utf8(&temp_buffer) { if s.chars().count() == 1 { // Complete character read print!("{}", s); temp_buffer.clear(); // Clear temp buffer for next character } } } Ok(()) } fn main() { let path = "path/to/your/file.txt"; if let Err(e) = read_file_character_by_character(path) { eprintln!("Error reading file: {}", e); } }
- comex 3y ago
  Unlike the original version, this version compiles and seems to basically work correctly. However, the design is misleading: `buffer` is declared as an array of 4 bytes but only the first byte is ever used. The code also has suboptimal performance and error handling, though that's not the end of the world.
  - raggi 3y ago
    all true, as I said in another fork of the thread, this comes down to part of what humans will still be valuable for in this loop: distilling poor requirements into better requirements.
noncoml 3y ago
I wouldn't say it's a nit. The file may be 10s of GB. Do you want to read it to a string?
- raggi 3y ago
  The buffered read didn’t do that, it used the default buffered reader implementation. IIRC that implementation currently defaults to 8kb buffer windows which is a little too small to be efficient enough for high throughput, but substantially more performant than making a syscall per byte, and without spending too much memory.
  - noncoml 3y ago
    I was talking about this: let mut file = File::open(path)?; let mut contents = String::new(); file.read_to_string(&mut contents)?;
deathanatos 3y ago
The original prompt is a bit under-specified. (But hey, that certainly matches the real world!) You're going to have to buffer at least a little, to figure out where the USV / grapheme boundary is, depending on our definition of "character". To me, a BufReader is appropriate here; it avoids lots of tiny reads to the kernel, which is probably the right behavior in a real case. To me, "read character by character" vaguely implies something that's going to yield a stream of characters. (Again, for some definition there.)

raggi 3y ago

fwiw, the benchmark that matters really has nothing to do with authoring code. the typing of code is the easy part even though it's a part a lot of folks are somewhat addicted to. the things which have far more value are applying value judgements to requirements, correlating and incorporating sparse and inaccurate diagnostic information into a coherent debugging strategy, and so on. there will come a time when it can assist with these too, probably first on requirements distillation, but for more complex debugging tasks that's a novel problem solving area that we've yet to see substantial movement on. so if you want to stave off the robots coming for you, get good at debugging hard problems, and learn to make really great use of tools that accelerate the typing out of solutions to baseline product requirements.

comex 3y ago

Only problem is that the critical `chars` method doesn't actually exist. Rust's standard library has a `chars` method for strings, but not for Readers. (Also, the comment about the iterator element type is inconsistent with the code following it. Based on the comment, `c` would be of type `(char, usize)`, but then trying to print it with {} would fail because tuples don't implement Display.)

raggi 3y ago
good catch. feeding it the error output of rustc it then produces: use std::fs::File; use std::io::{self, Read}; fn read_file_character_by_character(path: &str) -> io::Result<()> { let mut file = File::open(path)?; let mut contents = String::new(); file.read_to_string(&mut contents)?; for c in contents.chars() { println!("{}", c); } Ok(()) } fn main() { let path = "path/to/your/file.txt"; if let Err(e) = read_file_character_by_character(path) { eprintln!("Error reading file: {}", e); } }
- phaer 3y ago
  But this doesn't read the file char-by-char, but uses buffering to read it into a string
  - scottlamb 3y ago
    What would you expect? There's no OS API for "read one character", except in say ASCII where 1 byte = 1 code point = 1 character. And it'd be hideously inefficient anyway. So you either loop over getting the next N bytes and getting all complete characters so far (with some extra complexity around characters that cross chunk boundaries) or you read the whole thing into a single buffer and iterate the characters. This code does the latter. If this tool doesn't have the ability to respond by asking requirements questions, I'd consider either choice valid. Of course, in real life, I do expect to get requirements questions back from an engineer when I assign a task. Seems more practical than anticipating everything up-front into the perfect specification/prompt. Why shouldn't I expect the same from an LLM-based tool? Are any of them set up to do that?