-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor CodeChange code #91
Comments
Slight change to the plan for AbstractChange after thinking and working on it for a bit: Planning on having Additions, Deletions, and Rename subchanges -- the Rename change will have a new name where None will represent a deletion, and a Rename when the file does not exist will represent a creation |
I really like the idea of decoupling the LLM specified file change format and our internal file change object. I wonder if instead of calling them
Let me know it my summary and understanding aren't quite right but I think the dichotomy is more like Raw/Parsed than Concrete/Abstract. |
@jakethekoenig completely agree! Last week while I was making these changes I realized that concrete change wasn't really needed, and mapped out a completely different architecture that I really like with @biobootloader. I'll keep this issue as-is, but in #94 I lay out the new structure we agreed upon; it pretty much turns the AbstractChange into FileEdit (although FileChange would be a good name too) and removes the ConcreteChange completely. |
Can we close this issue? |
Refactoring CodeChange into a concrete and abstract format; the concrete format would manage parsing the model's output and would be able to convert into an abstract change. The abstract change would use an internal format and would handle actually changing files. This would allow us to easily create new formats and test them out, without having to change anything outside of the parsing (and maybe streaming?) logic. After talking with @biobootloader here is the current plan:
Overview
Concrete Change: Contains logic for parsing different model formats; can be converted to an abstract change. Can also be converted from an abstract change so that we can automatically generate examples for different models (and possibly tests) from a single example set.
Additions/Deletions: Make up an Abstract Change. These will be the simplest possible changes, either adding a block of code at a certain line or deleting a certain block of code. Ideally any conflicts will be resolved by the concrete change parser, but even if they aren't the Additions and Deletions will be processed in order and so conflicts shouldn't be an issue.
Abstract Change: Will be stored per file; each file will contain a list of Additions and Deletions; additionally, each Addition and Deletion will be marked with a specific Concrete Change; this will allow the user to use interactive mode to accept or reject (and eventually maybe ask the model to change?) specific changes that it outputs.
Plan
Possible alternative?
Another design choice we could have made is to have Abstract Changes represent an entire file, and simply be the text of the file after applying all changes rather than having Additions and Deletions; this would resolve some problems with conflicts and renaming, but wouldn't let us be able to reference specific Concrete Changes from the Abstract Changes, meaning we would mostly likely end up simply using hunks (groups of changed lines) in interactive mode. For now, @biobootloader and I have decided to go with the previous plan to allow interactive mode to be more powerful.
The text was updated successfully, but these errors were encountered: