Mailman 3 March 2003 - pypy-dev

Re: we need to discuss setting up a PyPy foundation and how
by Laura Creighton 31 Mar '03

31 Mar '03

In a message of Mon, 31 Mar 2003 12:52:51 -0800, Armin Rigo writes: >Hi Laura, > >On Mon, Mar 31, 2003 at 05:28:59PM +0200, Laura Creighton wrote: >> to fund it. I have starter capital now. This is going to work. >> We need a board so we can decide how to spend money. > >Oh oh. I see that you are trying to pull me into a money thing. All right, but >I guess you are aware that I have no experience in the domain. But I would be >glad to give directions on what I think could be interesting to finance. Cool. What we mostly need is your credentials. One of the reasons why we can tell the EU that it is not going to waste its money by giving us some is that your Psyco experience is exactly what they want. So we need to read them well enough that we can thoroughly answer the question 'what is it that the EU wants that we have got?'. Then you write that up, in painstaking detail, and call it a funding proposal. I have done this many times before, and this is the trick to getting funded. Answer the question 'what is it that you want that I have got' and then write that up. If you try to foolthem with promising them things they want but you do not have, then things go to hell quickly. But I think things are great for us. We only have to ask for money to do what we want to do, because they want us to do that. We just have to ask in such a way that makes it clear that we have common interest here. > >In fact I believe it would be very exciting to get funding for Python in >general and PyPy in particular. Alisair talked about getting academic sup >port >and linking PyPy's potentially small footprint with embedded devices -- t >hese >are exactly the two areas where I can help. The EU project I'm part of si >nce >tomorrow is all about specialization (Psyco) for embedded devices. This g >ives >strong links, even to the point that we could consider active collaborati >on >between the two projects, and maybe use the existing EU project to financ >ially >spawn the PyPy project. > > >Armin Sounds perfect to me. Laura

1 0

Re: we need to discuss setting up a PyPy foundation and how
by Armin Rigo 31 Mar '03

31 Mar '03

Hi Laura, On Mon, Mar 31, 2003 at 05:28:59PM +0200, Laura Creighton wrote: > to fund it. I have starter capital now. This is going to work. > We need a board so we can decide how to spend money. Oh oh. I see that you are trying to pull me into a money thing. All right, but I guess you are aware that I have no experience in the domain. But I would be glad to give directions on what I think could be interesting to finance. In fact I believe it would be very exciting to get funding for Python in general and PyPy in particular. Alisair talked about getting academic support and linking PyPy's potentially small footprint with embedded devices -- these are exactly the two areas where I can help. The EU project I'm part of since tomorrow is all about specialization (Psyco) for embedded devices. This gives strong links, even to the point that we could consider active collaboration between the two projects, and maybe use the existing EU project to financially spawn the PyPy project. Armin

1 0

Re: [pypy-dev] I want to get PyPy EU funding
by Laura Creighton 31 Mar '03

31 Mar '03

In a message of Mon, 31 Mar 2003 20:30:25 +0200, holger krekel writes: >[Laura Creighton Mon, Mar 31, 2003 at 07:21:57PM +0200] >> http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 >> >> Can we schedule a meeting on irc some time to discuss doing this? >> Time is getting a bit short with an April deadline for next batch >> of proposals. I am at Python-UK next week, but will try to keep >> in touch. > >We talked about this at the last sprint already and i am >interested. > >I still have no time to do much stuff relating to >computers. If you could stop the war that would probably >help a bit. > >greetings, > > holger Oh Holger, if I _could_, I _would_ already .... Laura

1 0

I want to get PyPy EU funding
by Laura Creighton 31 Mar '03

31 Mar '03

http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 Can we schedule a meeting on irc some time to discuss doing this? Time is getting a bit short with an April deadline for next batch of proposals. I am at Python-UK next week, but will try to keep in touch. Laura

2 1

Alisair Burt on getting EU funding.
by Laura Creighton 31 Mar '03

31 Mar '03

I say polish off our academic credentials, and also make the 'alternative to java for business' pitch and whatever else we can come up with as a good idea. Laura ------- Forwarded Message Return-Path: burt(a)dfki.de Sender: burt(a)dfki.de To: Laura Creighton <lac(a)strakt.com> Cc: lac(a)strakt.com Subject: EU Projects and Python From: Alastair Burt <burt(a)dfki.de> Date: Mon, 31 Mar 2003 18:10:34 +0200 Laura Creighton <lac(a)strakt.com> (2003-03-31): > I am interested in acquiring EU funding for Python in general, and the > PyPy project in particular. I realise that it is a long, involved, slow > process which takes years. (I've worked on EU projects before, just > never on the funding it end). I am here for the duration, but I need to > get taught what to do. Is this something that you would be willing to > teach me? If this teaching is something that you do professionally, I > would be most interested in taking a course, tutorial, or whatever else > it is that you do. I have some funding now, and matching funding is > something I want to investigate. Also I would be interested in doing > this via the Python Business Forum, where I am the Treasurer. I am not sure that I am the fountain of information that Nicolas thinks I am, and, to a large extent, I benefit from the infrastructure here at the DFKI. Here are some general points: - There are far more sources of EU funding than I know about. The main one for computing is the current IST call: http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 You are probably too late for the April deadline but another one in October should be fine. There are other sources of funding for e-learning, cross border cooperation between neighbours (Interreg), e-content generation, e-government (from IDA). But I do not have more exact pointers to hand, or much experience in submission to them. - The EU is not going to fund simple application development per se. So somehow you are going to have to show that you innovating in the direction that the EU is explicitly funding, and you will probably want to work with a consortium whose goals are more general than language implementation. I think if were trying to get PyPy funded, I would try to build some bridges with academic research, and I would make it clear how PyPy fits in with the big ideas that the EU is funding, such as ambient computing. In as much as PyPy would seem to make Python more portable and implementable on small devices, I think you could make a good case here. - I guess having EU project administration experience in the consortium would not hurt. The DFKI could do this, but there are actually many small firms these days that specialise in this. You could use one of them and let them handle the paper work. - Whatever you do, having a trustworthy, balanced consortium is the key to a good proposal and successful execution. - The EU themselves are helpful. If you see an EU call that looks fruitful, email the project officer. They will give you pointers. I would like to see Python be advanced by EU funding. I am not sure how much help I can be, but if you have specific questions, just ask. - --- Alastair - --- - ---- Alastair Burt German Centre for AI (DFKI), Stuhlsatzenhausweg 3 Saarbrücken 66123, Germany Email: burt(a)dfki.de Tel: +49 681 302 2565 Fax: +49 681 302 2235 http://www.aswad-project.org/ ------- End of Forwarded Message

1 0

I am back from 1 months' raod show.
by Laura Creighton 30 Mar '03

30 Mar '03

Has this list gone dead? I went to reenable mail, and it seems I never disabled it. But I have received no mail on this in a month. I would like an irc meeting with pypy people at some time. When? I am back in europe now, and mornings and afternoons are both good for me though I will be going to python-uk next week. Laura

2 1

Re: [pypy-dev] Why is there a separate ExecutionContext?
by roccomoretti＠netscape.net 17 Mar '03

17 Mar '03

Sorry for the weeks of radio silence, life has a way of taking up your time. >> > Actually, in the interest of generality, I'd argue that >> > ExecutionContexts >> > should not contain a link to the object space - it should be >> > a per frame value. There seems to be confusion on what I mean, so let me see if I can clarify. I hope we all agree that one of the powers of the ObjectSpace concept is the possibility of using multiple ObjectSpaces in the same program. We already have this implicitly with Python objects and C language objects. We could have an ObjectSpace for Psyco-ized code, or allow legacy ObjectSpaces - run 1.5.2 semantic objects in otherwise 2.5.3 codebase. So in this use of multiple ObjectSpaces, I'm mostly thinking in terms of libraries. You, personally, would likely stick to one ObjectSpace, but you may need to call into a library that uses a 1.5.2 object space, or a Prolog object space. Thus arises the concept that a function in one object space would have to call a function in another object space. But this meams that the Execution Context is not in a stable object space. In the parent function it has one object space, and when the library function is called, a function with a different object space is pushed onto the frame stack. Unless ...<thinking outloud> execution contexts can be nested. The calling function is in one execution context, and that spawns a daughter execution context in a different objectspace that handles the called function. The concept change (at least for me) is from that of a monolithic execution context that has global scope and static duration to more flexible execution contexts that have a more fleeting existence. In any case, the trick is interfacing between the different object spaces. A Prolog list does not behave like a Python list, so what happens when you try to concatanate them? This exchange of object spaces can happen in two locations - argument/return value passing and global values. I'm not sure how this should be handled. I'd advocate delaying the descision until we have two or more substantial object spaces we want to interface. But for initial musings, I'd probably caution against a mixed approach where each object retains it's semantics when it traverses into a different object space. It probably would get too confusing to track down bugs and dependancies, and the possible interactions would increase exponentially. (As well as defeting the purpouse of having seperate Object Spaces). I'd probably advocate for an interface based approach. As arguments are passed into a different object space, there are conversion routines which define how a particular object from one object space is converted into a native object in the other object space. The same happens in the reverse direction. If a cross-ObjectSpace global lookup occurs, the interpreter catches it and does the appropriate conversion. If it is nonsensical or impossible to convert the object, an exception is raised. A problem that immediately comes to mind is what to do about mutable objects which are passed to the function and then altered. How are they passed back? (What if the parent object space doesn't have "mutable" objects, but the called one does?) I hope that clears things up, -Rocco __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455

1 0

"unit" definition
by Armin Rigo 14 Mar '03

14 Mar '03

Hello everybody, Here is a proposal for organizing our files and particularly putting them in relation. As the Python tests are "unit tests" I suggest the name "unit" for a body of work composed of a couple of related files. A unit is roughly something as big as a Python module, but could also be used for something like built-in types. For example: * 'Builtins module' unit: module/test/test_builtin.py CPython's original unit test file module/builtin.py module/builtin_app.py maybe CPython's __builtin__ module for the interface (docstrings...) * 'Integer object' unit: objspace/std/test/test_integer.py objspace/std/test/test_intobject.py objspace/std/intobject.py objspace/std/intobject_app.py A unit is something explicitely defined somewhere. It starts abstractedly, like with only the tests and the interface of the module (function signatures, docstrings), and it is later "completed", i.e. (possibly incrementially) implemented, with new implementation-specific tests and docs. Example assuming Python syntax, using subclassing for "completing": class BuiltinsModule(pypy.unit.ModuleUnit): "Expected interface for the Python __builtin__ module." modulename = "__builtin__" test1 = pypy.unit.Test("module/test/test_builtin.py") rawinterface = pypy.unit.InterfaceFromCPython("__builtin__") #...and possibly somewhere else... class MyBuiltins(path.to.the.above.BuiltinsModule): impl = pypy.unit.RPythonImplementation("./my_builtin.py") implapp = pypy.unit.PurePythonImplementation("./my_builtin_app.py") impltest = pypy.unit.Test("./test/test_my_builtin.py") maintainer = "arigo" # some tests are known to fail right now # (the following line is done with a __get__ method on pypy.unit.Test # so that we can refer to MyBuiltins' status of test1) MyBuiltins.test1.known_failing += ['test_zip', 'test_unichr'] # some functions I have not implemented right now MyBuiltins.rawinterface.known_missing += ['filter', 'reduce'] # Note that the base BuiltinsModule class has no implementation, # hence tests won't be tested directly on it. # Also note that there are only a couple of magic attribute names, # like 'modulename' and 'maintainer'; all the pypy.unit.Xxx() # instances can be found by enumerating all attributes. The purpose of the classes of pypy.unit is to define the "roles" that each file can assume within that unit. They contains the magic to collect the data together when we actually want to run the tests or pypy itself. For example, RPythonImplementation would search for all functions defined in the specified file and insert them as "built-in function objects" into the proper application-level module (or maybe not all the functions, but only the ones specially tagged, or only the ones that are said to be part of the module interface). Instead of the above Python syntax for the definition of units, it could also be done with a dedicated syntax; here XML: module/builtinsmodule.xml: <unit kind="Module"> <modulename>__builtin__</modulename> <test id="test1">module/test/test_builtin.py</test> <interface id="raw" source="CPython">__builtin__</interface> </unit> module/arigo/mybuiltins.xml: <unit extends="module/builtinsmodule.xml"> <doc>blah blah blah</doc> <implementation lang="RPython">./my_builtins.py</implementation> <implementation lang="PurePython">./my_builtins_app.py</implementation> <test>./test/test_my_builtins.py</test> <maintainer>arigo</maintainer> <status> <failing test_id="test1"> test_zip test_unichr </failing> <missing interface_id="raw"> filter reduce </missing> </status> </unit> Not too bad either, althought having the power of the Python language to express things like 'known_failing += [...]' is more flexible. Opinions? Opinions on the whole idea are welcome too, of course! As you might have noticed I have located mybuiltins.xml in "module/arigo/", following Laura's idea of separating our in-development files from the main ones. I have not specified here anything about the actual "release" of the files, i.e. the process of moving them from these per-user subdirectories into the mainstream "module/". For now I'd say it could be as easy as moving up the .xml file and the files it links to, and that we'll see later if we need to agree on a more precise policy for that. Also note that contributing a test file that you expect to work on any implementation of a module means just adding a line in the (base) unit corresponding to the empty module interface. We should then precisely define the pypy.unit role classes, e.g. how Test() files are called, what function signatures RPythonImplementation() expect (including how to do the PyArg_ParseTuple() trick more declaratively), and how interfaces and possibly doc files are written. We also probably need another kind of implementation, like LibraryImplementation, a file containing just ctypes-like declarations of library function calls (e.g. for the posix module). I hope that this could give the frame that everybody is waiting for to start the actual work! A bientôt, Armin.

2 2

RE: [pypy-dev] Pypy frontend/ testall.py
by roccomoretti＠netscape.net 14 Mar '03

14 Mar '03

"logistix" <vze55z8s(a)verizon.net> wrote: >I've written a small script that'll allow you to run .py scripts via >pypy. Ultimately, it'll incorporate all of the functionality of calling >'python' from the command-line. Great! I wanted something like this over the weekend. (Have you been borrowing Guido's time machine?) >Normally, I'd get some more work done >before distributing it, but it is enough to run testall.py in the test >directory, so I thought it might be of interest. N.B. If you look at the implementation of testall.py (at least for 2.2.2) it's just a hack which fiddles with sys.argv and then calls into test.regrtest (I mention this because regrtest.py has different output formating features which look much nicer than the verbose output of testall.py. >It should be noted that testall.py fails quite spectacularly, as can be >expected at this point, and aborts execution. That's interesting - Which platform and ObjSpace were you using? When I tried this weekend with TrivialObjSpace under Python 2.2.2 on Win98 the results were encouraging - most of the tests passed (eventually). One MAJOR caveat on that issue is that I had to edit regrtest.py to get it to work. Out of the box all the tests failed miserably with "Module Not Found Errors". regrtest.py assumes that tests are in test_???.py files in the current package level (Lib/test, but the level is implicit). However, when the pypy interpreter runs an import, the import runs local in the Lib/pypy/interpreter package - no test_??? files are found. Additionally, when testing, an "import test" opens the "test" submodule of Lib/pypy/interpreter. If you delete/rename the test directory, and edit regrtest.py such that it does an absolute import: Change: the_module = __import__(test, globals(), locals(), []) to: the_module = __import__("test", globals(), locals(), [test]) then testall/regrtest is happy. (No, I don't think this is a long-term solution to the problem ...) -Rocco __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

5 7

Re: Base Object library (was: stdobjspace status)
by Christian Tismer 09 Mar '03

09 Mar '03

Stephan Diehl wrote: Once again on this: > def __init__(w_self, rintval): > w_self.intval = rintval > > where rintval is already the restricted intval. > Am I right here? As said, I'm not sure if rintval will be an r_int already, it depends on the rest of the implementation which is quite a bit foggy to me, still. Maybe I define intval as a slot, and give it a setter method that always enforces the primitive r_int type. Also there will be a basic notation of primitive arrays. They might be built using the array module, but I think I like it better to implement it using derived list objects, with a restricted type attribute. And then, these objects are meant to describe just plain memory arrays, no Python objects. The are, but they don't behave like that. For instance, r_objectarray would be a list, which is restricted that it only can hold references to W_Object, or None which acts as NULL. r_objectarray would also override Python operators like "+" and "*", since these don't exist in RPython's arrays: An array can only be created once, with a fixed size. There is no concatenation or repetition. Instead, this has to be built upon that, in terms of the primitive arrays. So, W_ListObject would have some fields like self.objarray # r_objectarray self.maxlen # r_uint self.actlen # r_uint It has been suggested to not use maxlen, since we could use len(self.objarray), but I believe this is wrong to do. If we are modelling primitive arrays, then they don't support len() at all. Now, for example, the definition of concatenation for our new lists could read like so: class r_range(object): def __init__(self, *args): self.xr = xrange(*args) def __getitem__(self, idx): return r_int(self.xr[idx]) class W_ListObject(W_Object): __slots__ = ["objarray", "maxlen", "actlen"] def __init__(self, lng, data=None): self.objarray = newobjarray(lng) if data: for i in r_range(lng): self.objarray[i] = data[i] self.actlen = lng else: self.actlen = 0 self.maxlen = lng def list_list_add(space, w_lis1, w_lis2): lng1 = w_lis1.actlen lng2 = w_lis2.actlen lng = lng1 + lng2 res = W_ListObject(lng) for i in r_range(lng1): res.objarray[i] = w_lis1.objarray[i] for i in r_range(lng1, lng): res.objarray[i] = w_lis2.objarray[i] res.actlen = lng return res Maybe this is just very rough, but give a little an idea how things can work. Wile we are at it, Stephan, you wrote the longobject.py . You are probably aware of the fact that this implementation is slightly not what we need? You coded, for instance: def long_long_sub(space, w_long1, w_long2): x = w_long1.longval y = w_long2.longval try: z = x - y # <== ick! We don't have that! except Error,e: raise OperationError(Error, e) return W_LongObject(z) This is ok, if you rely on the existance of long objects. But for a real implementation, we need to use integer arrays like in longobject.c, and implement everything by hand. So how to fill longobject.py with real life? I think, we first need some basic structure like r_integerarray or maybe even better r_uintarray, and based upon that, we must build every and all the necessary loops. Anybody wants to try it? ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

7 16