Log Wrapper and Gambatte

[fregapple]

Hi there! I am currently putting together a little self project making a frontend for your code. I am a bit of a beginner and so teaching myself and rewriting a lot of my stuff over and over as I learn a better way.

However, I can't get the Variadic Log Wrapper Module to load. Even when using cmd with the Complex Emulator and Gambatte Core.

Just coming up with "ImportError("cannot import name 'cext'",)

Cheers,

[fregapple]

Hey,

Just an update on the Ticket.

I found the reason I was having this issue was because there wasn't a cext file and that I needed to run the setup.py file.

I have now done that, however run into another problem. I reach an OverflowError: Python int too large to convert to C long. Did a bit of looking up on that error and people have said that it could be that because I am on Windows, python int it returning a 32 bit int, when this might need a 64 bit one.

Are you guys running this on Windows? if not, how do you think I should get around this? Perhaps using numpy as they have a int64 module?

Also, after the overflowerror, it tries to keep booting, but then exits on an OSError: exception: access violation writing x.

[lifning]

Hi! I haven't run Windows in years now, but if I had to guess, the issue might be that the compiler setup.py found could've built the cext for a mismatched bitness with your Python interpreter (and libretro core).

The logging module isn't required for the bindings to function, but it is helpful for seeing what's going wrong in a core that's not working.

Are you using 32- or 64- bit Python / libretro cores? (And what cores have you tried loading?)

[fregapple]

Hey! Thanks for replying!

I am currently trying to find ways around it, so good timing to see your message pop up!

I am able to run the binding without the logging, however hitting this road block has made me determined why I can't implement it myself!

I think you could be right that the setup.py file perhaps could have created a missmatched cext file.

However, to answer your questions, I am running 64 bit Python / Libretro cores. And of the cores I have tried Parallel, Gambatte, vba_next and snes9x. All these cores work with the games without the logging, though run into that issue otherwise.

You've given me an idea to try the 32 bit cores though, as maybe they'll give a c_long length int instead. I'll try that right now!

[fregapple]

Hey!

So, installing a 32bit python and using the 32 bit cores work with the logging!

Is there much performance decrease using 32bit python compared to 64 bit? How should we get the cext to work with 64 bit?

[lifning]

There's no performance decrease for 32-bit code in this case. Other than the Dolphin core, which we can't even load with this project yet (needs OpenGL implemented), there aren't really any libretro cores coming to mind that need or even benefit from 64-bit.

Working on very dated memory here: Getting the cext to work with 64-bit might involve running the setup.py from a command prompt with the appropriate x64-oriented Visual Studio variables set, which I think it leaves shortcuts for in the Start menu. The name "VCVARSALL.BAT" is coming to mind, too, if that gives you any breadcrumbs for research.

Sadly I'll be of limited help with the Windows-specifics :( But great to hear you got it working!

[fregapple]

That is good to know! Though I would like to eventually work on some openGL as well so getting it to work on 64 bit will be ideal for me. 64 bit works with Linux well as I tested that earlier today.

You are bang on with "VCVARSALL.BAT". I had to use the x64 console of VS to set DISTUTILS_USE_SDK=1 and then I was able to install the setup.py. Looking through the install output, it doesn't have any errors or warnings, so I assume it completes properly.

I looked through on the Core.py:

"data: ctypes.c_void_p" seems to be what brings in the int and gives it to:

the cext.handle_env_get_log_interface( ).

Doing a bit of research on python versions across OS'. Windows int on 64 bit is just a c_long. Which I think is why I am getting an error of overflow, as the 64 bit core is giving me a c_longlong.

I think one way of solving this would be having the code accept a c_longlong over a default Python int or allowing me to use numpy and have it accept a numpy.int64. But I don't where it is even requesting for an int. I have tried following the functions, but not sure where it is.

Could you perhaps have a look and let me know where it is asking for this int value?

[fregapple]

Hey! I think I can close this now!

I made a little converter just before it takes the information:

It converts it to 32bit and boots up properly, whilst also doing the full log!