Earlier quoted context omitted.
If we're being sticklers, this isn't reading character-by-character: it's performing a buffered read, which then gets iterated over.
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]) { // Rea…
Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
21–30 of 150 posts
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#22Earlier quoted context omitted.
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 Res…
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.)
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);
}
}Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#23Earlier quoted context omitted.
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]) { // Rea…
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.
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#24Very cool project! I've experimented in this direction previously, but found agentic behavior is often chaotic and leads to long expensive sessions that go down a wrong rabbit hole and ultimately fail. It's great that you succeed on 12% of swe-bench, but what happens the other 88% of the time? Is it useless wasted work and token costs? Or does it make useful progress that can be salvaged? Also, I think swe-bench is f…
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#25If you are afraid that LLMs will replace you at your job, ask an LLM to write Rust code for reading a utf8 file character by character Edit: Yes, it does write some code that is "close" enough, but in some cases it is wrong, in others it doesn't not do exactly what asked. I.e. needs supervision from someone who understands both the requirements, the code and the problems that may arise from the naive line that the LL…
But, for most of the debates I've seen, I don't think it the answer matters all too much.
Once we have models that can act as full senior SWEs.. the models can engineer the models. And then we've hit the recursive case.
Once models can engineer models better and faster than humans, all bets are off. Its the foggy future. Its the singularity.
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#26If you are afraid that LLMs will replace you at your job, ask an LLM to write Rust code for reading a utf8 file character by character Edit: Yes, it does write some code that is "close" enough, but in some cases it is wrong, in others it doesn't not do exactly what asked. I.e. needs supervision from someone who understands both the requirements, the code and the problems that may arise from the naive line that the LL…
Hypothetically, which ticker symbols would you buy put contracts on, at what strike prices, and at what expiration dates? As far as I can tell, a lot of people are betting a lot of money that you are wrong, but actually I think you are right.
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#27A 1/8 chance of fixing a bug at the cost of a careful review and some corrections is not bad. 0% -> 12% improvement is not bad for two years either (I'm somewhat arbitrary picking the release date of ChatGPT). If this can be kept up for a few years we will have some extremely useful tooling. The cost can be relatively high as well, since engineering time is currently orders of magnitude more expensive than these tool…
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#28A 1/8 chance of fixing a bug at the cost of a careful review and some corrections is not bad. 0% -> 12% improvement is not bad for two years either (I'm somewhat arbitrary picking the release date of ChatGPT). If this can be kept up for a few years we will have some extremely useful tooling. The cost can be relatively high as well, since engineering time is currently orders of magnitude more expensive than these tool…
Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#29Re: Princeton group open sources "SWE-agent", with 12% fix rate for GitHub issues
#30Earlier quoted context omitted.
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.)
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_charac…