JonathanSalwan / Triton

Triton is a dynamic binary analysis library. Build your own program analysis tools, automate your reverse engineering, perform software verification or just emulate code.
https://triton-library.github.io
Apache License 2.0
3.4k stars 524 forks source link

Trying to fix python autocompletion #1220

Closed Andrix44 closed 1 year ago

Andrix44 commented 1 year ago

The generated triton_autocomplete module had several errors that I fixed. grafik grafik I also added a CMAKE option to make it easier to enable generation from the cmake-gui. It was also throwing an exception because it always used triton.SOLVER.BITWUZLA even when it was not available. For this I had to make the solvers optional and turned them into script arguments (--bitwuzla, --z3). Also cleaned up the output by commenting out a print.

The built wheels should now include an autocomplete stub file which removes the need for importing a separate autocomplete package.

mrexodia commented 1 year ago

Maybe an idea is to switch to a .pyi stub file instead? That shouldn't require any additional imports to get autocomplete to work.

Andrix44 commented 1 year ago

It seems like my problem was that Python 3.11 is completely broken, it broke Triton, WSL debugging with VS Code, IDAPython etc. With 3.10 the old method still works. As for your suggestion, simply renaming the file to triton.pyi and putting it into site-packages worked for me. I'll try to make it generate prettier code and install automatically. EDIT: I don't think it's worth rewriting, top is current and bottom is what the new style would be: image

Andrix44 commented 1 year ago

It also looks like the windows wheel on pypi is broken because it copies all the files into site-packages instead of a subdirectory. I think the best option would be to put everything in site-packages/triton or site-packages/triton_library. image @cnheitman Maybe you can take a look?

cnheitman commented 1 year ago

@Andrix44 I'll try to a look at it next week.

cnheitman commented 1 year ago

The fact that it's copying files into site-packages instead of site-packages/triton_library.libs (as in the case of the manylinux version) is due to delvewheel, the tool used to repair the wheel package. This comment in the code give a hint on why: https://github.com/adang1345/delvewheel/blob/master/delvewheel/_wheel_repair.py#L559. I'm not exactly sure how to fix this.

Andrix44 commented 1 year ago

I pushed some changes that should include the stub file in newly generated wheels. By default setup.py now also builds the stub unless disabled with an environment variable. It's installed directly in site-packages to make sure it works with the Windows wheels.

Andrix44 commented 1 year ago

Appveyor failed because it exceeded some rate limit and got blocked, but everything should be working now. Tested the 3.10 wheel on WSL and remote VSCode was able to provide autocomplete.

mrexodia commented 1 year ago

I would suggest switching to GitHub Actions altogether, but that’s probably something for another PR…

On Sun, 15 Jan 2023 at 17:44, Andrix44 @.***> wrote:

Appveyor failed because it exceeded some rate limit and got blocked, but everything should be working now. Tested the 3.10 wheel on WSL and remote VSCode was able to provide autocomplete.

— Reply to this email directly, view it on GitHub https://github.com/JonathanSalwan/Triton/pull/1220#issuecomment-1383197017, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASYFGJCMQRZD2ELQQXU3G3WSQSPXANCNFSM6AAAAAATSJ53WA . You are receiving this because you commented.Message ID: @.***>