Re: [pypy-dev] Sandboxing pypy
Hi, On Tue, Mar 23, 2010 at 10:46:50PM +0100, Søren Laursen wrote: I have tried different things using the pypy_interact.py (just love the ?timeout parameter J), looked at code but have not been able to read files or write files using the pypy_interact.py. You get indeed a VFS (virtual file system) which is read-only so far. You can read any file from the virtual path /tmp/xxx if you start pypy_interact.py with the option --tmp=some/path. There is no support yet to allow writes. It could be easily added by editing vfs.py. A bientot, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] dvcs conversation of pypy and maybe all the other projects in the repo, too
Hi, since pypy's history itself is kinda unsuitable for practically all converters/importers out there, i started to experiment with analysis of it in order to eventually convert to a dag based dvcs (most likely hg). Since that repository carries various other projects as well i wonder if anyone else is interested in converting to a dvcs. The needs of pypy's history alone create the need of a very powerfull tool anyway, so converting the other projects would be a nice sideeffect. -- Ronny ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Nightly builds are unavailable
On Tue, Mar 23, 2010 at 7:43 PM, Gasper Zejn z...@kiberpipa.org wrote: Nope, not working. The directory listing works, but not the links. Did you click on any of the links provided on that url? Ah no, sorry. My fault, the links indeed don't work. ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Sandboxing pypy
Le mardi 23 mars 2010 22:46:50, Søren Laursen a écrit : The project I am working with Minimum Intrusion Grid : MiG ( http://sites.google.com/site/minimumintrusiongrid/) are looking into using pypy. I would like to use it for sandboxing user code in MiG, more specific allow the users to develop their own “scheduler” . The MiG, it self is written in Python so we might even be able to run it on pypy. But right now it is the sandboxing that I am working with. FYI I wrote a new sandbox project for CPython: http://github.com/haypo/pysandbox/ It's currently very specific to CPython: it uses evil tricks to create a read only view of the __builtins__ super global dictionary. It's completly different to the PyPy sandbox: if you escape from the sandbox, you get a full access to all Python functions. A long description: http://mail.python.org/pipermail/python-dev/2010-February/097701.html -- Victor Stinner http://www.haypocalc.com/ ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Branches
Hi Armin, On 03/23/2010 10:43 PM, Armin Rigo wrote: Can we decide if the following branches have been merged, are useful enough to be merged, need more work, maybe one day, are very outdated, or turned out just to be a plain bad idea? The numbers are the rev number of the last change. Also, what about separating in-development branches that we expect to merge or kill soon, from the branches that are for some other idea, e.g. effect-analysis, which may not be merged in a long while but still we may want to keep around? Maybe just have a dir parallel to branch called inactive? or some other name. * 71164 abort-no-asm (fijal, cfbolz) Keep around, I want to reconsider this eventually. * 70752 bridges-experimental (cfbolz) Same. * 71270 kill-can-inline (cfbolz) Same. * 66009 type-celldict (cfbolz) Killed this one. * 70890 unroll-safe-if-const-arg (fijal, cfbolz, arigo) Would keep this around, even if it ultimately didn't work. Cheers, Carl Friedrich ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Branches
On Tue, Mar 23, 2010 at 3:43 PM, Armin Rigo ar...@tunes.org wrote: Hi all, Can we decide if the following branches have been merged, are useful enough to be merged, need more work, maybe one day, are very outdated, or turned out just to be a plain bad idea? The numbers are the rev number of the last change. Also, what about separating in-development branches that we expect to merge or kill soon, from the branches that are for some other idea, e.g. effect-analysis, which may not be merged in a long while but still we may want to keep around? * 70689 jit-profiling (pedronis, fijal) Killed * 55472 judy-trees (fijal) Killed * 64690 pypycpp (igorto) I suppose that's to-be-killed * 70890 unroll-safe-if-const-arg (fijal, cfbolz, arigo) I would like this to be kept around until jit is powerful enough to handle that. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] GSoC Project/Bachelor's Thesis
Hi Everyone, My name is Kai Aras, I'm a Computer-Science student from Germany and I'm very interested in doing my Bachelor's Thesis on PyPy and possibly also combine that with a GSoC project. I became aware of the PyPy-Project by the Chaosradio Express (CRE088) episode about PyPy from 2008. Last year, I had the opportunity to take some time to play around with PyPy in order to present it at my University, ever since that I became more and more attracted to the Python Language and the PyPy-Project itself, so writing my Bachelor's Thesis about something PyPy-related occured to me quite early. Now, as the time has come, combining my Thesis with a GSoC Project would be a great opportunity. During the last year, I've worked on a smarthome project using CPython on embedded-linux platforms, as the project grew bigger, more and more problems arised and the need for some spezialized Python Runtime grew bigger as well. I know that targeting Embedded Platforms was an Issue in the original EU-Project and there was that Maemo thing last year, so I'm guessing this could be a general topic for a GSoC Project as well as a Bachelor's Thesis, what do you guys think ? Is this something you would like to see as well ? Personally, I'd love to use PyPy on openWRT, could this might be a target of general interest ? This is just something I thought about from time to time but never really had the time to experiment with, so I'm open to all suggestions, please let me know if you have any ideas that could be suitable for such a project. Thanks, Kai ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
