Hi everyone, i have finally managed to have a pypy plugin into uWSGI via libpypy-c. The first step was exporting a bunch of symbols in libpypy-c: "RPython_StartupCode", "pypy_g_ObjSpace_startup", "pypy_g_call_startup", "pypy_g_State_startup", "pypy_g_Module_startup", "pypy_g_pypy_module_cpyext_state_State" pypy_g_ObjSpace_startup and pypy_g_Module_startup are not strictly required, i have used them only for debugging some very specific areas. Attached there is a patch for latest tip. After that, i have defined a Py_Initialize() replacement: http://projects.unbit.it/uwsgi/browser/plugins/python/python_plugin.c#L8 and placed a bunch of #ifdef for unsupported functions (like PyFile_FromFile) Finally i have built libpypy with pypy translate.py -Ojit --shared and the uWSGI plugin with LDFLAGS="-L." pypy-c uwsgiconfig.py --plugin plugins/pypy core (LDFLAGS is used as i have libpypy-c in the current dir) Run uWSGI with the welcome app (and a bunch of processes): uwsgi --http-socket :8080 --plugin pypy --module welcome --master --processes 8 Incredibly the whole uwsgi api (that it is pretty complex, involving tons of c code) works flawlessly as well as the custom wsgi.input object (the whole upload test suite passes). Running python threads from the WSGI app works too, but mapping python threads to already available pthreads is a no go (all explodes, i will investigate on that) Importing applications as modules works normally, but importing via file requires implementing a bunch of c-api in pypy (i will address that soon) virtualenv, sys.argv and setting programname is not supported (no c api available) i can get rid of this too in the next few days. Important thing: i have tested it only on OSX -- Roberto De Ioris http://unbit.it
Hi Roberto, On 27.03.2012, Roberto De Ioris <roberto@unbit.it> wrote:
Hi everyone, i have finally managed to have a pypy plugin into uWSGI via libpypy-c.
Great! Are you still working on it? We can accept patches; for us it would also be cool if you can work on a clone of the repository and issue "pull requests" on bitbucket.org. A bientôt, Armin.
Hi Roberto,
On 27.03.2012, Roberto De Ioris <roberto@unbit.it> wrote:
Hi everyone, i have finally managed to have a pypy plugin into uWSGI via libpypy-c.
Great!
Are you still working on it? We can accept patches; for us it would also be cool if you can work on a clone of the repository and issue "pull requests" on bitbucket.org.
Hi Armin, yes i am still working on it, i would like to have multithread support working before sending other patches. -- Roberto De Ioris http://unbit.it
Hello Roberto, If you need help with code or testing I would be glad in help. Is this work available in some repository? cheers Felipe 2012/4/1 Roberto De Ioris <roberto@unbit.it>
Hi Roberto,
On 27.03.2012, Roberto De Ioris <roberto@unbit.it> wrote:
Hi everyone, i have finally managed to have a pypy plugin into uWSGI via libpypy-c.
Great!
Are you still working on it? We can accept patches; for us it would also be cool if you can work on a clone of the repository and issue "pull requests" on bitbucket.org.
Hi Armin, yes i am still working on it, i would like to have multithread support working before sending other patches.
-- Roberto De Ioris http://unbit.it _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Hello Roberto,
If you need help with code or testing I would be glad in help.
Is this work available in some repository?
cheers Felipe
Hi, i have started committing here: https://bitbucket.org/pypy/pypy The current Py_Initialize() implementation is very skeletal. It should get some of the bin/py.py (included importing site.py) in the next few hours. -- Roberto De Ioris http://unbit.it
Hello Roberto,
If you need help with code or testing I would be glad in help.
Is this work available in some repository?
cheers Felipe
Hi, i have started committing here:
Sorry, i mean https://bitbucket.org/unbit/pypy ;)
The current Py_Initialize() implementation is very skeletal. It should get some of the bin/py.py (included importing site.py) in the next few hours. -- Roberto De Ioris http://unbit.it
-- Roberto De Ioris http://unbit.it
On Tue, Apr 3, 2012 at 7:47 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Hello Roberto,
If you need help with code or testing I would be glad in help.
Is this work available in some repository?
cheers Felipe
Hi, i have started committing here:
Sorry, i mean
https://bitbucket.org/unbit/pypy
;)
The current Py_Initialize() implementation is very skeletal. It should get some of the bin/py.py (included importing site.py) in the next few hours. -- Roberto De Ioris http://unbit.it
-- Roberto De Ioris http://unbit.it _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Hi Isn't Py_Initialize clashing name with stuff exported from cpyext? Can it be named PyPy_Initialize or something? Cheers, fijal
On Tue, Apr 3, 2012 at 7:47 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Hello Roberto,
If you need help with code or testing I would be glad in help.
Is this work available in some repository?
cheers Felipe
Hi, i have started committing here:
Sorry, i mean
https://bitbucket.org/unbit/pypy
;)
The current Py_Initialize() implementation is very skeletal. It should get some of the bin/py.py (included importing site.py) in the next few hours. -- Roberto De Ioris http://unbit.it
-- Roberto De Ioris http://unbit.it _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Hi
Isn't Py_Initialize clashing name with stuff exported from cpyext? Can it be named PyPy_Initialize or something?
Py_Initialize() is only used for app embedding python. It is not usable (or used) in c extensions. For me there is no problem in renaming it, but i suppose bigger apps (like blender) would prefer avoiding #ifdef's :) -- Roberto De Ioris http://unbit.it
On Tue, Apr 3, 2012 at 11:12 AM, Roberto De Ioris <roberto@unbit.it> wrot
On Tue, Apr 3, 2012 at 7:47 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Hello Roberto,
If you need help with code or testing I would be glad in help.
Is this work available in some repository?
cheers Felipe
Hi, i have started committing here:
Sorry, i mean
https://bitbucket.org/unbit/pypy
;)
The current Py_Initialize() implementation is very skeletal. It should get some of the bin/py.py (included importing site.py) in the next few hours. -- Roberto De Ioris http://unbit.it
-- Roberto De Ioris http://unbit.it _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Hi
Isn't Py_Initialize clashing name with stuff exported from cpyext? Can it be named PyPy_Initialize or something?
Py_Initialize() is only used for app embedding python. It is not usable (or used) in c extensions.
For me there is no problem in renaming it, but i suppose bigger apps (like blender) would prefer avoiding #ifdef's :)
-- Roberto De Ioris http://unbit.it
Ok I see. Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
Ok I see.
Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
I am about to add: Py_SetPythonHome Py_SetProgramName Py_Finalize i will put them into module/cpyext/src/pythonrun.c Do you think Py_Initialize should go there too ? -- Roberto De Ioris http://unbit.it
On Tue, Apr 3, 2012 at 11:32 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Ok I see.
Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
I am about to add:
Py_SetPythonHome Py_SetProgramName Py_Finalize
i will put them into
module/cpyext/src/pythonrun.c
Do you think Py_Initialize should go there too ?
-- Roberto De Ioris http://unbit.it
Sounds like a good idea. Should I merge the pull request now or wait for the others? Cheers, fijal
On Tue, Apr 3, 2012 at 11:32 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Ok I see.
Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
I am about to add:
Py_SetPythonHome Py_SetProgramName Py_Finalize
i will put them into
module/cpyext/src/pythonrun.c
Do you think Py_Initialize should go there too ?
-- Roberto De Ioris http://unbit.it
Sounds like a good idea. Should I merge the pull request now or wait for the others?
I think it is better to wait. Moving that to cpyext will avoid messing with translators (adding more exported symbols) too. -- Roberto De Ioris http://unbit.it
On Tue, Apr 3, 2012 at 11:32 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Ok I see.
Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
I am about to add:
Py_SetPythonHome Py_SetProgramName Py_Finalize
i will put them into
module/cpyext/src/pythonrun.c
Do you think Py_Initialize should go there too ?
-- Roberto De Ioris http://unbit.it
Sounds like a good idea. Should I merge the pull request now or wait for the others?
I think it is better to wait. Moving that to cpyext will avoid messing with translators (adding more exported symbols) too.
Ok, i am pretty satisfied with the current code (i have made a pull request). I have implemented: Py_Initialize Py_Finalize Py_SetPythonHome Py_SetProgramName all as rpython-cpyext except for Py_Initialize being splitted in a c part (it requires a call to RPython_StartupCode) Successfully tested with current uWSGI tip. Py_SetPythonHome add flawless support for virtualenv. -- Roberto De Ioris http://unbit.it
Hello everyone! I got some errors while i was building the embedded-pypy branch with python translate.py -Ojit --shared. Could anybody help me with it, please? The defautl branch builds without any errors. [translation:ERROR] In file included from debug_print.c:16:0: [translation:ERROR] common_header.h:18:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default] [translation:ERROR] /usr/include/features.h:215:0: note: this is the location of the previous definition [translation:ERROR] In file included from ../module_cache/module_11.c:157:0: [translation:ERROR] /home/e-max/workspace/pypy/pypy/translator/c/src/dtoa.c:132:0: warning: "PyMem_Malloc" redefined [enabled by default] [translation:ERROR] /home/e-max/workspace/pypy/pypy/module/cpyext/include/pymem.h:8:0: note: this is the location of the previous definition [translation:ERROR] /home/e-max/workspace/pypy/pypy/translator/c/src/dtoa.c:133:0: warning: "PyMem_Free" redefined [enabled by default] [translation:ERROR] /home/e-max/workspace/pypy/pypy/module/cpyext/include/pymem.h:9:0: note: this is the location of the previous definition [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 2017, in <module> [translation:ERROR] tracker.process(f, g, filename=fn) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1910, in process [translation:ERROR] tracker = parser.process_function(lines, filename) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1425, in process_function [translation:ERROR] table = tracker.computegcmaptable(self.verbose) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 52, in computegcmaptable [translation:ERROR] self.parse_instructions() [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 207, in parse_instructions [translation:ERROR] insn = meth(line) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1047, in visit_jmp [translation:ERROR] return FunctionGcRootTracker.visit_jmp(self, line) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 710, in visit_jmp [translation:ERROR] raise NoPatternMatch(repr(self.lines[tablelin])) [translation:ERROR] __main__.NoPatternMatch: '\t.long\t.L370-.L376\n' [translation:ERROR] make: *** [jit_backend_llsupport_descr.gcmap] Error 1 [translation:ERROR] make: *** Waiting for unfinished jobs.... [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 2017, in <module> [translation:ERROR] tracker.process(f, g, filename=fn) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1910, in process [translation:ERROR] tracker = parser.process_function(lines, filename) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1425, in process_function [translation:ERROR] table = tracker.computegcmaptable(self.verbose) [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 65, in computegcmaptable [translation:ERROR] return self.gettable() [translation:ERROR] File "/home/e-max/workspace/pypy/pypy/translator/c/gcc/trackgcroot.py", line 99, in gettable [translation:ERROR] localvar) [translation:ERROR] AssertionError: pypy_g_generate_tokens: %r10 [translation:ERROR] make: *** [interpreter_pyparser_pytokenizer.gcmap] Error 1 [translation:ERROR] """) On Wed, Apr 4, 2012 at 19:55, Roberto De Ioris <roberto@unbit.it> wrote:
On Tue, Apr 3, 2012 at 11:32 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Ok I see.
Is the rest of the API used going to be cpyext? If so, then Py_Initialize is indeed a perfect choice.
I am about to add:
Py_SetPythonHome Py_SetProgramName Py_Finalize
i will put them into
module/cpyext/src/pythonrun.c
Do you think Py_Initialize should go there too ?
-- Roberto De Ioris http://unbit.it
Sounds like a good idea. Should I merge the pull request now or wait for the others?
I think it is better to wait. Moving that to cpyext will avoid messing with translators (adding more exported symbols) too.
Ok, i am pretty satisfied with the current code (i have made a pull request).
I have implemented:
Py_Initialize Py_Finalize Py_SetPythonHome Py_SetProgramName
all as rpython-cpyext except for Py_Initialize being splitted in a c part (it requires a call to RPython_StartupCode)
Successfully tested with current uWSGI tip. Py_SetPythonHome add flawless support for virtualenv.
-- Roberto De Ioris http://unbit.it _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Hi, 2012/4/11 Max Lavrenov <max.lavrenov@gmail.com>
Hello everyone!
I got some errors while i was building the embedded-pypy branch with python translate.py -Ojit --shared. Could anybody help me with it, please?
trackgcroot.py does not recognize some constructs used when compiling with -fPIC. I thought I fixed them though... Anyway it will crash at runtime: because of code relocation, function pointers are actually addresses into a translation table, which contains the real code address. I already fixed this for Windows a long time ago. Meanwhile, the best thing to do is to avoid assembler magic, and translate with the option: --gcrootfinder=shadowstack -- Amaury Forgeot d'Arc
Thank you! Finally I've built libpupy.so and uwsgi with it. On Wed, Apr 11, 2012 at 11:22, Amaury Forgeot d'Arc <amauryfa@gmail.com>wrote:
Hi,
2012/4/11 Max Lavrenov <max.lavrenov@gmail.com>
Hello everyone!
I got some errors while i was building the embedded-pypy branch with python translate.py -Ojit --shared. Could anybody help me with it, please?
trackgcroot.py does not recognize some constructs used when compiling with -fPIC. I thought I fixed them though... Anyway it will crash at runtime: because of code relocation, function pointers are actually addresses into a translation table, which contains the real code address. I already fixed this for Windows a long time ago.
Meanwhile, the best thing to do is to avoid assembler magic, and translate with the option: --gcrootfinder=shadowstack
-- Amaury Forgeot d'Arc
On Wed, Apr 11, 2012 at 4:42 PM, Max Lavrenov <max.lavrenov@gmail.com>wrote:
Thank you! Finally I've built libpupy.so and uwsgi with it.
Cool! Feel free to share your story with either us or via some blog if you find it interesting! Cheers, fijal
On Wed, Apr 11, 2012 at 11:22, Amaury Forgeot d'Arc <amauryfa@gmail.com>wrote:
Hi,
2012/4/11 Max Lavrenov <max.lavrenov@gmail.com>
Hello everyone!
I got some errors while i was building the embedded-pypy branch with python translate.py -Ojit --shared. Could anybody help me with it, please?
trackgcroot.py does not recognize some constructs used when compiling with -fPIC. I thought I fixed them though... Anyway it will crash at runtime: because of code relocation, function pointers are actually addresses into a translation table, which contains the real code address. I already fixed this for Windows a long time ago.
Meanwhile, the best thing to do is to avoid assembler magic, and translate with the option: --gcrootfinder=shadowstack
-- Amaury Forgeot d'Arc
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
I am afraid it's not interesting. I just wanted to test it with our small project - geoip server which resolves ip address to region. Now we use bjoern wsgi server for running this project. Basically it's does nothing but bisect search on array.array. When i run this code without wsgi wrapper using pypy it shows about 400% speed boots. Unfortunately uwsgi with pypy plugin shows me pretty same perfomance as usual uwsgi. When i wrote simple application which loop over "for" cycle and increment some variable, i got same result. I'll try running more tests to figure out what I'm doing wrong. I am a fan of your work and looking forward to using pypy in our production project. On Thu, Apr 12, 2012 at 14:52, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Wed, Apr 11, 2012 at 4:42 PM, Max Lavrenov <max.lavrenov@gmail.com>wrote:
Thank you! Finally I've built libpupy.so and uwsgi with it.
Cool! Feel free to share your story with either us or via some blog if you find it interesting!
Cheers, fijal
On Wed, Apr 11, 2012 at 11:22, Amaury Forgeot d'Arc <amauryfa@gmail.com>wrote:
Hi,
2012/4/11 Max Lavrenov <max.lavrenov@gmail.com>
Hello everyone!
I got some errors while i was building the embedded-pypy branch with python translate.py -Ojit --shared. Could anybody help me with it, please?
trackgcroot.py does not recognize some constructs used when compiling with -fPIC. I thought I fixed them though... Anyway it will crash at runtime: because of code relocation, function pointers are actually addresses into a translation table, which contains the real code address. I already fixed this for Windows a long time ago.
Meanwhile, the best thing to do is to avoid assembler magic, and translate with the option: --gcrootfinder=shadowstack
-- Amaury Forgeot d'Arc
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
I am afraid it's not interesting. I just wanted to test it with our small project - geoip server which resolves ip address to region. Now we use bjoern wsgi server for running this project. Basically it's does nothing but bisect search on array.array. When i run this code without wsgi wrapper using pypy it shows about 400% speed boots. Unfortunately uwsgi with pypy plugin shows me pretty same perfomance as usual uwsgi. When i wrote simple application which loop over "for" cycle and increment some variable, i got same result. I'll try running more tests to figure out what I'm doing wrong. I am a fan of your work and looking forward to using pypy in our production project.
Hi, when you compile libpypy, the translator should generate a pypy-c binary. Try to run your code without the wsgi wrapper with this new binary, to check if you still have a 400 times improvement. If you get 'slower' values over a standard binary release of pypy, it means you have compiled it wrongly (maybe without the jit). In my tests, 99% of the webapps (being IO-based) do not gain too much power on pypy, but if you have a CPU-bound webapp (like you), you will end screaming WOOOW all of the time :) And take in account that in uWSGI we suggest using lua-jit for all of the need-to-be-fast parts, so to make us scream you have to be faster than it :) I would like to suggest you another approach, vastly pushed in the past years in pypy talks. It includes a bit of overhead, but you will end with a more solid platform: delegate the CPU-bound part to a pypy daemon (listening on unix sockets or whatever you want) and run your public webapp with your server of choice running on cpython. In your webapp you simply 'enqueue' tasks to the pypy daemon and wait for the result. Do not make the error to use a complex protocol for it. Go line-based. No need to add more overhead i often see. If for some reason the pypy daemon crashes (come on it happens ;), you can simply automatically restart it without propagating the down to your public web-services (if it crashes during a request you can simply re-enqueue it in the same transaction) With this approach you can continue using bjoern for the public IO-bound part, and abuse pypy for the cpu-heavy one. In uWSGI this kind of approach is a lot easier (from a sysadmin point-of-view) as you can use the --attach-daemon option, allowing you to 'attach' an external process (your pypy daemon) that will be monitored (and respawned) automatically. -- Roberto De Ioris http://unbit.it
On Fri, Apr 13, 2012 at 8:15 AM, Roberto De Ioris <roberto@unbit.it> wrote:
I am afraid it's not interesting. I just wanted to test it with our small project - geoip server which resolves ip address to region. Now we use bjoern wsgi server for running this project. Basically it's does nothing but bisect search on array.array. When i run this code without wsgi wrapper using pypy it shows about 400% speed boots. Unfortunately uwsgi with pypy plugin shows me pretty same perfomance as usual uwsgi. When i wrote simple application which loop over "for" cycle and increment some variable, i got same result. I'll try running more tests to figure out what I'm doing wrong. I am a fan of your work and looking forward to using pypy in our production project.
Hi,
when you compile libpypy, the translator should generate a pypy-c binary.
Try to run your code without the wsgi wrapper with this new binary, to check if you still have a 400 times improvement.
I think he said 400%, that's not as good ;-)
If you get 'slower' values over a standard binary release of pypy, it means you have compiled it wrongly (maybe without the jit).
In my tests, 99% of the webapps (being IO-based) do not gain too much power on pypy, but if you have a CPU-bound webapp (like you), you will end screaming WOOOW all of the time :)
working on it...
And take in account that in uWSGI we suggest using lua-jit for all of the need-to-be-fast parts, so to make us scream you have to be faster than it :)
FYI we outperform luajit on richards (giving *ample* warmup, luajit warms up *so* fast), did not measure on anything else. Just sayin
I would like to suggest you another approach, vastly pushed in the past years in pypy talks. It includes a bit of overhead, but you will end with a more solid platform:
delegate the CPU-bound part to a pypy daemon (listening on unix sockets or whatever you want) and run your public webapp with your server of choice running on cpython. In your webapp you simply 'enqueue' tasks to the pypy daemon and wait for the result. Do not make the error to use a complex protocol for it. Go line-based. No need to add more overhead i often see.
If for some reason the pypy daemon crashes (come on it happens ;), you can simply automatically restart it without propagating the down to your public web-services (if it crashes during a request you can simply re-enqueue it in the same transaction)
I think crashes are less of an issue (pypy is relatively stable) compared to the libraries that you have to interface with (like lxml).
With this approach you can continue using bjoern for the public IO-bound part, and abuse pypy for the cpu-heavy one.
In uWSGI this kind of approach is a lot easier (from a sysadmin point-of-view) as you can use the --attach-daemon option, allowing you to 'attach' an external process (your pypy daemon) that will be monitored (and respawned) automatically.
-- Roberto De Ioris http://unbit.it
Thanks for insights Roberto! I'm really glad uWSGI community is interested *and* seem to be taking a reasonable, non-overhyped approach Cheers, fijal
Hi Roberto, On Wed, Apr 4, 2012 at 5:55 PM, Roberto De Ioris <roberto@unbit.it> wrote:
Ok, i am pretty satisfied with the current code (i have made a pull request).
Trying to figure out what is the status of the pending pull requests, I came across: https://bitbucket.org/pypy/pypy/pull-request/68/pyfile_fromfile-pysys_setarg... Should we still try to merge unbit/pypy to pypy/pypy? It seems that nowadays the differences are mostly only in cpyext, adding new functions like Py_Initialize(). Moreover, if the asmgcc failure is still present, I would just set the options so that "translate --shared" forces "--gcrootfinder=shadowstack". Does it seem ok for us to merge in these conditions? A bientôt, Armin.
Hi Roberto,
On Wed, Apr 4, 2012 at 5:55 PM, Roberto De Ioris <roberto@unbit.it> wrote:
Ok, i am pretty satisfied with the current code (i have made a pull request).
Trying to figure out what is the status of the pending pull requests, I came across:
https://bitbucket.org/pypy/pypy/pull-request/68/pyfile_fromfile-pysys_setarg...
Should we still try to merge unbit/pypy to pypy/pypy? It seems that nowadays the differences are mostly only in cpyext, adding new functions like Py_Initialize(). Moreover, if the asmgcc failure is still present, I would just set the options so that "translate --shared" forces "--gcrootfinder=shadowstack". Does it seem ok for us to merge in these conditions?
Hi Armin, the whole "newer" code is under cpyext. Last time i checked (a week ago) the asmgcc failure was still there, so i think it is better to force shadowstack when --shared is specified. -- Roberto De Ioris http://unbit.it
Hi Roberto, On Sat, Jun 9, 2012 at 11:34 AM, Roberto De Ioris <roberto@unbit.it> wrote:
Hi Armin, the whole "newer" code is under cpyext. Last time i checked (a week ago) the asmgcc failure was still there, so i think it is better to force shadowstack when --shared is specified.
Ok, done. And I closed the pull request then. Armin
2012/4/3 Maciej Fijalkowski <fijall@gmail.com>:
Isn't Py_Initialize clashing name with stuff exported from cpyext? Can it be named PyPy_Initialize or something?
cpyext does not provide Py_Initialize() yet. This patch should use more RPython code, and probably be moved to cpyext. -- Amaury Forgeot d'Arc
participants (6)
-
Amaury Forgeot d'Arc -
Armin Rigo -
Felipe Cruz -
Maciej Fijalkowski -
Max Lavrenov -
Roberto De Ioris