On 11/04/2013 7:58 PM, Maciej Fijalkowski wrote:To expand on fijal's comment a bit:On Thu, Apr 11, 2013 at 6:49 PM, Roger Flores <aide...@yahoo.com> wrote:OK, I reworked (and attached) the patch for the suggestions to nt_threads.[ch]. You had no comments for dtoa.c.This is great. From inspection, there doesn't seem to be any other changes needed to the C code in rpython/translator/c for Windows 64 support. I am assuming the 'gcc' folder there does not matter. 1. Are there any other directories where C code needs to be reviewed to support Windows 64? 2. That still leaves the rpython code in rpython/translator/c. Can you show an example of where that needs fixing (regarding sizeof(long)) so I can use that as a pattern for the remaining code? 3. rpython/jit/backend/x86: it's still not clear what part needed work here Thanks, -RogerHi Roger. Seriously, while there might be any pattern there, I would *strongly* suggest you start running tests and see what breaks. Cheers, fijal _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev First see http://doc.pypy.org/en/latest/how-to-contribute.html I think we should move toward win64 support by getting win32 to pass the own-windows-x86 tests run on a buildbot ( http://buildbot.pypy.org/summary?builder=own-win-x86-32 ) . Once we get the failures down to a reasonable number, we could start to run the tests while changing the underlying int/pointer assumptions, starting with rpython and moving into pypy. My point is that we should do this in a controlled and test-driven process. Support for windows is a big job, and it would be nice to have more people involved, so Roger please do not give up! Matti |
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
