Mailman 3 May 2006 - pypy-dev

Security ideas
by Armin Rigo 18 Jul '06

18 Jul '06

Hi all, On Monday I was at an inspiring seminar about (a specific form of) language-level security. I've collected the PyPy-ification of these ideas there: http://codespeak.net/svn/pypy/dist/pypy/doc/discussion/security-ideas.txt Although the focus is different, it makes me think that we could also use similar ideas to implement a form of 'rexec' (restricted execution), with functions compiled by secure() as in the draft above, but running at a priviledge level which is lower than the default ambiant level instead of higher. A bientot, Armin

6 7

Missed pypy-sync
by Antonio Cuni 30 May '06

30 May '06

Hi all, I've realized just now that I've missed the pypy-sync yesterday... sorry! Btw, here is my activity report: LAST: work on unifying rpython/ and cli/ tests; basic string support in gencli NEXT: DDorf sprint BLOCKERS: uni stuffs ciao Anto

1 0

SoC
by Maciek Fijalkowski 29 May '06

29 May '06

Maybe that's a little bit late, but I've got broadband finally. I would like to thank all of pypy team for helping me with my SoC.

3 2

Ootypesystem based genjs (genjs2)
by Maciek Fijalkowski 29 May '06

29 May '06

I've added what I've done in last week with genjs, altough I'm not very happy with some issues. - LoopFinder does not find nested whiles (I think it's also gensquek problem) - Inheritance is not implemented - Dict support is not implemented - There is some code redundancy, because of copying from gencli. I hope to refactor it with antonio at DDorf sprint. - I don't like builtin method and function mapping solution, especially copying whole misc.js at the beginning of source file. Some function should be copied on higher, some on lower level.

1 0

pypy-sync Monday 29th 5pm UTC+2
by hpk＠trillke.net 27 May '06

27 May '06

Hi folks, the DDorf sprint, EuroPython talk deadlines and the 0.9 release are all jointly and quickly approaching. Let's have a brief #pypy-sync meeting Monday afternoon 5pm UTC+2, 29th May with these topics and try to co-ordinate last preps and efforts. And please have your "last/next/blockers" lines ready. have a nice weekend! best, holger

2 1

Re: [pypy-dev] [pypy-svn] r27660 - in pypy/branch/njriley-trans/pypy: rpython/lltypesystem translator/c
by Michael Hudson 24 May '06

24 May '06

njriley(a)codespeak.net writes: > Author: njriley > Date: Wed May 24 20:48:13 2006 > New Revision: 27660 > > Modified: > pypy/branch/njriley-trans/pypy/rpython/lltypesystem/rclass.py > pypy/branch/njriley-trans/pypy/translator/c/exceptiontransform.py > pypy/branch/njriley-trans/pypy/translator/c/node.py > Log: > Make exceptions thread-local Would this change make sense on the trunk too? Cheers, mwh -- Hmmm... its Sunday afternoon: I could do my work, or I could do a Fourier analysis of my computer's fan noise. -- Amit Muthu, ucam.chat (from Owen Dunn's summary of the year)

2 1

llvm backend
by Simon Burton 24 May '06

24 May '06

Hi, I'm exploring the llvm backend of pypy. Does it work without llvm-gcc ? I tried the example at doc/getting-started.html and it seems to first compile to c code then invoke llvm-gcc. >>> f = t.compile_llvm() (calls to llvm-gcc) But I'm also looking at the source for the llvm translator and there is code there for generating llva directly. Now I'm trying to run the demos in pypy/translator/llvm/demo. I assume I can use my regular python to run these.. somehow.. $ python run.py Traceback (most recent call last): ... File "/mnt/hda9/simonb/local/pypy-svn/pypy/annotation/bookkeeper.py", line 16, in ? from pypy.annotation.listdef import ListDef, MOST_GENERAL_LISTDEF ImportError: cannot import name ListDef ? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

3 5

Re: [pypy-dev] pypy-dev Digest, Vol 310, Issue 5
by Grégoire Dooms 24 May '06

24 May '06

> Date: Fri, 12 May 2006 12:42:17 +0200 > From: Aur?lien Camp?as <aurelien.campeas(a)logilab.fr> > Subject: Re: [pypy-dev] Thread cloning (coroutine cloning, really) > To: Armin Rigo <arigo(a)tunes.org> > Cc: pypy-dev(a)codespeak.net > Message-ID: <20060512104217.GB28391(a)crater.logilab.fr> > Content-Type: text/plain; charset=iso-8859-1 > <snip> > We could restrict the programming style for code to be running inside > comp. spaces but if it is possible to effectively clone everything > (for some ill-defined notion of everything) then it'l be fine. I'm not > 100% sure. Here are some of the constraints : > > In principle, side-effects on the parent space and the outer world > should be forbidden from within a running comp. space ('cause the jury > is still out on its outcome). > If I can throw in my two cents, you should really try to remove this limitation of Mozart. This is a real pain in the ass when you want to know what happens in a space (I used to need that in Mozart for debugging or statistics). In Mozart it is possible to use a hack in order to have side effects out of a space (ie modifiy state outside the space) by using ports. I think a design which would allow it would be much more Pythonic (we are between consenting adults :-) Best, -- Grégoire

2 1

MetaVM design
by Antonio Cuni 21 May '06

21 May '06

Hi Maciek, I all as I announced in my previous e-mail here are some ideas on how to use metavm for genjs2. I think the best way to use metavm for your purposes is to write a bunch of MicroInstruction classes designed for emitting source code. For example I guess that some rpython low level instruction need to be mapped to infix operator (such as int_add & co.) while others need to be mapped to some support function (such as int_abs). You could write something like this: class InfixOperator(MicroInstruction): def __init__(self, operator): self.operator = operator def render(self, generator, op): generator.emit('(%s %s %s)' %\ (op.args[0], self.operator, op.args[1]) class CallHelper(MicroInstruction): def __init__(self, helper): self.helper = helper def render(self, generator, op): arglist = ... # compute arglist from op.args generator.emit('%s(%s)' % (self.helper, arglist) Then, in your opcodes.py: opcodes = { 'int_add': InfixOperator('+'), 'int_abs': CallHelper('abs') } The difficult thing here is to design the Generator interface in a way that is suitable for emitting both asm code and source code. Maybe we try to separate the two worlds, in this way: genoo/metavm.py --------------- class Generator: def function_signature(self, graph): pass # put here all methods shared by both AsmGenerator and SourceGenerator class StackBasedGenerator(Generator): def emit(self, instr, *args): pass def call(self, func_name): pass def load(self, v): pass def store(self, v): pass ... class SourceCodeGenerator(Generator): def emit(self, expression): pass # and so on genoo/function.py ----------------- class Function(Node, Generator): # some shared code ... class StackBasedFunction(Node, StackBasedGenerator): ... class SourceCodeFunction(Node, SourceCodeGenerator): ... gencli/function.py ------------------ class CliFunction(StackBasedFucntion): ... genjs2/function.py ------------------ class JsFunction(SourceCodeFunction): ... Once we have this design, each MicroInstruction subclass can decide whether to target the generic Generator interface or one of its subinterfaces. ciao Anto

1 0

Re: [pypy-dev] gencli checkin
by Antonio Cuni 21 May '06

21 May '06

Hi Maciek, hi all Maciek Fijalkowski wrote: > I've just checked in my changes to gencli which are essential for genjs > to use gencli. It does not brake any more tests (7 failed as was > before). I hope I don't get in conflict with your actual edits. sorry for the very late response; I'm cc:ing to pypy-dev so that others can read. I've read your changes, good work: I think that now the best thing to do is to collect the modules used by both backends in a proper place, e.g. a genoo package or so (better names are welcome :-). Here are some comments on the modules that might be moved to genoo: class_.py, function.py, record.py: they contain both generic code and gencli specific code (such as Class.get_base_class() and and Class._ctor() methods). We could put generic 'Class', 'Function' and 'Record' class in genoo and subclass it in the backends. cts.py: this is CLI specific, but each backend need a similar module: we should at least put the interface specification in genoo, and possibly some shared code. database.py: there are both generic and specific parts, too. We should provide a more flexible way to handle constants, and maybe we can integrate it with the code from gensqueak that implements a sort of priority queue for emitting things in the right order. IMHO each backends should be able to decide whether to emit things in sequential order (as gencli does, should be faster) or in "declaration order" (as gensqueak and genjs2 need). ilgenerator.py: same as cts.py. oopspec.py: same as class_.py, function.py, record.py: some code can be shared, some need to be backend-specific. rte.py: its goal is to automatically compile a DLL every time the source if modified: this could be useful for all backends that need to compile some runtime environment "offline". sdk.py: very cli-specific. metavm.py: the code here is of three types: - generic code that can be used by all backends: the Generator/MicroInstrucion/InstructionList architecture is designed to be as much generic as possible, so it's not a problem to reuse it (note that the Generator interface is not very up-to-date, see Function.py). - some classes are not cli-specific but they have been designed for emitting code on stack-based machines; I guess they are not very useful for genjs2, but they could be useful for a hypotetic genjava, for example. - some code is very cli-specific, such as the _RuntimeNew class. I wrote some ideas on how you can use and extend metavm for your goal, but I decided to move them to a fresh e-mail so we don't mix the two discussions. At last we need a way to tell genoo where to find the code specific to each backend. I've seen that at the moment you decided to separately pass things such as CTS, Function, opcodes etc as arguments to GenCli constructor, but perhaps it would be better to collect them in a sort of 'container' class and pass this all around; something like this: class CliFunction: ... class CliClass: ... class CTS: ... cli_opcodes = { ... } class CliBackend: Function = CliFunction Class = CliClass TypeSystem = CTS opcodes = cli_opcodes ... Better names other than CliBackend are welcome, too :-). What do you think about this design? Valentino, Nikh, Seo and other that are working on high level backends: do you think that such a genoo could be useful for gensqueak and gencl, too? ciao Anto

1 0

pypy-dev May 2006