mirror of
https://github.com/jehna/humanify.git
synced 2026-04-27 09:35:58 +03:00
[GH-ISSUE #67] Error while renaming a variable. (TypeError: Duplicate declaration) #32
Labels
No labels
bug
enhancement
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/humanify#32
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Anooxy17 on GitHub (Aug 28, 2024).
Original GitHub issue: https://github.com/jehna/humanify/issues/67
Console output:
@0xdevalias commented on GitHub (Aug 29, 2024):
See also:
@brianjenkins94 commented on GitHub (Oct 18, 2024):
Is there a workaround or anything for this? Or is this blocked by the effort to understand how to perform the rename without collision?
I would be totally okay if it just became
variable$1.@jehna commented on GitHub (Oct 18, 2024):
@brianjenkins94 did you try with v2.1.3 yet? It should have a better logic against invalid identifiers
@jehna commented on GitHub (Oct 18, 2024):
If the identifier conflicts with another identifier that's not generated by Humanify, then there's no valid fix yet.
I wonder what should be done in case of an identifier that we cannot rename? A quick solution would be to prefix it with an underscore
@jehna commented on GitHub (Oct 18, 2024):
I suppose the best solution could be that Humanify would retry with a prompt like:
@brianjenkins94 commented on GitHub (Oct 18, 2024):
Yes, I am using
humanifyv2.1.3 with:which resolves to
webcrackv2.14.1.I don't think that's the problem I'm having, all my variables are named
v1,p1, etc.That's what I was saying, if it could just add a
$1suffix, likeesbuilddoes to avoid collisions.here's my repo:
https://github.com/brianjenkins94/reverse-engineered-nodebox
@jehna commented on GitHub (Oct 18, 2024):
Okay, I think I found the issue. Fixing this now
@brianjenkins94 commented on GitHub (Oct 18, 2024):
I updated my test harness so I can test against the main branch. I'll see if it gets further this time.
Aside: Can I run humanify against multiple files simultaneously? Or would that run the risk of making requests too fast?
@jehna commented on GitHub (Oct 18, 2024):
Just released
v2.2.0, should fix this issue for now.I'd say it depends solely on your OpenAI subscription level. Unfortunately there's not that good rate limit throttling/retry logic built into Humanify yet.
@jehna commented on GitHub (Oct 18, 2024):
Added some thoughts about parallelism to issue #167
@0xdevalias commented on GitHub (Oct 20, 2024):
See also:
@0xdevalias commented on GitHub (Oct 20, 2024):
@jehna That's what's been proposed in the past, eg.
https://github.com/jehna/humanify/pull/164 feels a bit like a workaround rather than an optimal solution.
@0xdevalias commented on GitHub (Oct 20, 2024):
Related context (from secondary comment on another issue):
@brianjenkins94 commented on GitHub (Oct 21, 2024):
In trying to produce benchmark results for #172, I have determined that simultaneous runs cause 429s and cause the application to crash.
Just closing the loop.