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
Stackless issue #168: make Stackless compatible with old Cython modules #169
Conversation
… modules Many extension modules were created by Cython versions before commit 037bcf0 and were compiled with regular C-Python. These modules call PyEval_EvalFrameEx() with a broken frame object. This commit add code to recover a broken frame in PyEval_EvalFrameEx().
@kdschlosser Would you like to test pr #169 ? |
yeah I can give this a rock and roll for ya.. all i should have to do is compile my ptogram using python 2.7 and simply copy it over and see if it runs.. correct?? |
… modules Add a test case for a pathological situation.
@kdschlosser Yes, simply compile on C-Python and try to run it on Stackless. Download the DLL from https://bitbucket.org/stackless-dev/stackless/downloads/StacklessPythonDLL_32bit_2.7.15_git-287233e.zip. I'm in my annual leave for the next three weeks, so don't expect fast answers. |
I am going to give this a run either tonight or tomorrow. I have been extremely busy these past few days. I wanted to let ya know I have not forgotten ya and I will run this test. |
… modules Add another test case for a pathological situation.
OK so I finally got the chance to give this a test. And the dll I downloaded from the link above worked just fine. I used CPython 2.7 x86 and Cython to compile my dll and moved it into the site packages folder of Stackless 2.7 x86 put the downloaded python27.dll into the root of that installation. ran a test script. all seems well. I did not try it with the latest code update. I do not know if you change the dll in the download or not. Again I want to thank you for all the help with this. Cython is used in to many projects to not have it work correctly in Stackless. I am really dreading the massive code rewrite to make the project I am working on python 3 compatible. It really isn't so much our code base that is going to be the big issue. It is things like wxPython and pywin32, having to redo the whole build process because of py2exe compatibility. I think the biggest thing is probably wxPython because they do not have a 3.x version that runs in python 3. and their 4.x is a pretty large rewrite of their code and it is not API compatible with 3.x. we have over 400 plugins that are going to need to be rewritten along with the core program it's self. with only myself and one other doing all of the coding, it is going to take 2 years to do. I have thought about monkey patching all the bits that are different. I do not know if there is a code converter that actually works to handle the python 2-3 changes. I suppose I should probably start the process of writing the monkey patches for wxPython. |
The official script should work for most code: http://python3porting.com/2to3.html |
I tried the python 2to3 module. It didn't fix a whole lot out of the box with instructing it to use all of it's fixers. It didn't even correct all of the print statements. Because of the enormous variations in writing styles that we have It would probably be more difficult writing something to work properly, best to go old school on it, line by line fix what needs to be fixed. Changing the mundane things like unicode and iteritems can be done with simple replacement. I have written a bunch of monkey patches to handle the simple things like unicode and the changes to the import system for the time being and logs the usage This way I have an idea of where i need to correct things. I will see how well this is all going to work once I compile it. :S I just finished up writing a module called wxPython3to4. This I am going to make a repo for, this way if someone that uses it sees something missing they can add it. I have most of the obvious things handled. module redirection, method redirection. things of that nature. I am sure there is a heap load more I will have to add to it. But at the very least it is going to ease the workload making this change. I will be able to make the necessary hard coded changes over time and not have to do them all right out of the gate. If I had to put a finger on the number of lines of code out app is along with all of the plugins.. I just wrote something to count the lines. I did the core and maybe 50 of the 400ish plugins, 877046 lines, including blank and commented lines. So I would say 2 million lines for all the plugins and core code, only python code was counted. That is a lot of work for 2 people to accomplish in a reasonable amount of time. |
when is the EOL for 2.x supposed to take place? |
My current plan is to release a Stackless 2.7 for each C-Python 2.7. The last C-Python 2.7 release will be in early 2020. |
I really can't express my gratitude for you spending so much time working on this fix. I think it is awesome that you jumped right on it. When you get a little time you should read what a user posted in our forums. http://www.eventghost.net/forum/viewtopic.php?p=52030#p52030 EventGhost runs on Stackless. So your efforts don't go unnoticed. The person may not be directly addressing you. Your code is what runs EventGhost so you are apart of our "team". This person's comments are directed to you as much as it is to me. |
Many extension modules were created by Cython versions before commit
037bcf0 and were compiled with regular C-Python. These modules call
PyEval_EvalFrameEx() with a broken frame object.
This commit add code to recover a broken frame in PyEval_EvalFrameEx().