Thank you for the explanation, Armin. It's as I thought. OK, then a brief announcement for potential sandbox champions on this list :)
Our early-stage startup (Grist Labs <https://www.getgrist.com/jobs>) is looking for an engineer who can also be a pypy sandbox champion! Competitive salary, benefits, equity, plus the ability (and encouragement) to contribute to pypy. For the moment, we are only offering a full-time position in New York City, but if you have a strong interest elsewhere, let's talk anyway. I hope this isn't an abuse of this list, but really: the pypy sandbox is an important and promising tools for us. We'd like to contribute what we can. Dmitry On Tue, Jun 9, 2015 at 2:46 AM, Armin Rigo <ar...@tunes.org> wrote: > Hi Dmitry, > > On 9 June 2015 at 05:10, Dmitry Sagalovskiy <dmi...@getgrist.com> wrote: > > More generally, my team needs to decide if we can rely on the pypy > sandbox to use in our product. It seems brilliantly designed, fast, and > overall impressive. But there are these gaps in missing sandbox wrappers > (there are others too, fcntl is just one that I don't know how to avoid). > And I noticed some code that indicates that it is not supported on Windows > -- is that the case? > > What are the sandbox's prospects, within the larger future of pypy? > > The sandbox code is there and "mostly working", but it is lacking a > champion. It has been in this state for many years now (it is > actually impressive that it still roughly works). Realistically, > though, to answer the question of its prospects, it depends entirely > on whether someone would be ready to become involved in PyPy and help > maintain and develop it. As usual with Open Source, we can't predict > when (and if) this will occur. From our point of view, it seems to > attract occasional attention like yours, but we just have too many > things to work on. > > > If anyone can suggest what I might be doing wrong, I would greatly > > appreciate. > > You're not doing anything wrong, just stumbling on a mixture of old > and new code. In the case of 'pypy_jit_depthmap_add', it's because we > recently added vmprof support and didn't think about sandboxing. The > fix is probably easy: we need a few "sandboxsafe=True" keyword > arguments in rpython/jit/backend/llsupport/codemap.py. The issue with > 'fcntl' is more obscure and involves much older code. In that case we > need the sandboxed interpreter to ask the outside what to do---which > should occur automatically, but doesn't, for reasons I'm still > investigating. I suspect it's related to the XXX in the comment of > select_function_code_generators() in rpython.translator.c.node. (I > think with minimal effort we can finally get rid of the "oldstyle" > functions mentioned there.) > > > A bientôt, > > Armin. >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
