Hi Tom,
On 30 April 2015 at 00:21, wrote:
> 1) Am I correct in assuming that these are imports?
Yes.
> 2) Can these be eliminated? These opens are problematic in the absence of a
> file system.
Try running pypy with the -s option. Likely, it doesn't remove them
all; you have to provide the
When I kick off the interctive sand-boxed version of PyPy I'm seeing it
open a significant number of .py files.
1) Am I correct in assuming that these are imports?
2) Can these be eliminated? These opens are problematic in the
absence of a file system.
Thanks,
Tom
On Tue, 28 Apr 2015 22:5
Hi Tom,
On 28 April 2015 at 19:56, wrote:
> Correction: " non-functional without the *peer* class
> VirtualizedSandboxedProc"
Modern PyPy versions try to get some environ variables, at least as
documented in rpython/doc/logging.rst. It makes the
do_ll_os__ll_os_getenv() method necessary (undef
Correction: " non-functional without the *peer* class
VirtualizedSandboxedProc"
On Tue, 28 Apr 2015 09:33:01 -0600, t...@twhanson.com wrote:
I'm confused about the relationship between
SimpleIOSandboxedProc and VirtualizedSandboxedProc.
Looking at pypy_interact.py I see that it is multip
I'm confused about the relationship between SimpleIOSandboxedProc and
VirtualizedSandboxedProc.
Looking at pypy_interact.py I see that it is multiply dependent from
SimpleIOSandboxedProc and VirtualizedSandboxedProc. I expected that
I'd be able to drop VirtualizedSandboxedProc and tweak the cod
Hi Tom,
On 27 April 2015 at 18:10, wrote:
> We can't hard-code the scripts into the binary becuase their purpose is to
> adapt behavior to new configurations. Because of this the scripts will be
> read from an external source and then executed. This is what makes the the
> stdin/stdout streami
Armin,
A good thought. Sandboxing may actually be an advantage from a
security standpoint. We'll be developing all of the scripts to be
run, but there's always the chance of hacking.
We can't hard-code the scripts into the binary becuase their purpose is
to adapt behavior to new configuratio
Hi Tom,
On 25 April 2015 at 01:32, Maciej Fijalkowski wrote:
> On Sat, Apr 25, 2015 at 1:13 AM, wrote:
>> Thanks for the idea. I played with the sandboxed version and it looks like
>> it has potential.
It's not necessarily the only option. A sandboxed process comes with
a lot of other constr
Maciej,
Thanks for the idea. I played with the sandboxed version and it looks
like it has potential.
I searched the web for a C/C++ version of the controller but with no
luck. I saw questions about it and interest expressed but couldn't
find anyone who had actually built one. Do you (or do
On Sat, Apr 25, 2015 at 1:13 AM, wrote:
> Maciej,
>
>
>
> Thanks for the idea. I played with the sandboxed version and it looks like
> it has potential.
>
>
>
> I searched the web for a C/C++ version of the controller but with no luck.
> I saw questions about it and interest expressed but couldn
pypy generally needs to find a bunch of files for it's standard
library. I would suggest trying something a-la the sandboxed version
where all the external calls go via a special proxy that you can write
in C++. it's a bit of effort though. What are you trying to achieve if
you have no filesystem?
I'm evaluating PyPy for use in an application where it will be running in an
RTOS (Greenhills Integrity) which is congifured without a file system at
runtime. The rest of the application is C/C++.
Is there a way to build PyPy for this environment? The issue I see is that
pypy_setup_home()req
12 matches
Mail list logo
