-
-
Notifications
You must be signed in to change notification settings - Fork 7k
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
potential fix for some/dir/ bug #928 #930
Conversation
I think the Also not sure if this is the right place/time, but I've had great success by writing save codeblocks like this:
And similarly for patch, simply:
I think this might be a superior format overall, but not sure what your experiences with the current one is. |
Thanks for input @ErikBjare ! I actually made feature request for a third idea #869 For now, as I said, I will try just removing the placeholder. |
This should at least partially address the concern in #928, by removing the part of the prompt that misleads the LLM to append some/dir to paths I have also added an additional test for the case that we are editing a new file (works) and overwriting an existing file (works). This, as I understand should address #952 , which I will close. Correct me if I'm misunderstanding something here @Wheaties466 . |
@ATheorell Thank you for the response! Yes, as I understand it. It should address that concern I raised in #952. If you need or want a test lmk which branch has the fix and I can pull/build/test. |
Great! I merged to main |
The problem in bug #928 is that "some/dir/" is used as a placeholder to indicate that a filename should be represented by a relative path. The placeholder is introduced in the preprompt improve. Occasionally, the LLM misunderstands this intention and appends "some/dir/" explicitly to file names. This fix adds a clarification to the LLM the "some/dir/" is a placeholder.