Mailman 3 August 2003 - pypy-dev

"Unwrap" Concidered Harmful
by roccomoretti＠netscape.net 03 Sep '03

03 Sep '03

Maybe I overstate the subject line, but there are serious limitations on the .unwrap() concept. The limitation stems from the "blackbox" concept for object spaces. In general, we cannot be sure that unwrap will give a valid object. It may work for a direct representation of Python objects (such as trivial and standard object spaces), but when we start to use object space representations that do not exactly mirror Python semantics, unwrap isn't guarranteed to work. For example, if an annotation-like object space represents obects as type & bool (for truth tracking, for example), upon calling wrap(), it discards all information about value. So there is no way we can say that s.unwrap(s.wrap(x)) == x. Even if an object space keeps some kind of info on the wrapped object such that it can be unwrapped, there is no guarrantee that something valid will remain after any sort of operations on it, as a different object space may induce a different or multiple path(s) through the code. This is probably tractable within the object space itself, as any sort of vagarities in the wrapping can be compensated for on a space by space basis. However, if we wish to have a general code evaluation framework for multiple object spaces, the code evaluation code has to be general. At the moment there are a number of places in the code evaluation framework which call unwrap(). - I think it is mostly for unwrapping code objects. The reason I bring this up is I think that this is the reason the general builtin-module import code I posted earlier crashes for the annotation object space. The code attemped to unwrap attributes of the sys module, assuming that normal Python sematics are valid. This doesn't hold for annotation object space ... hence the crash. So if we wish to be general in the execution framework, we need to limit the use of unwrap() to uses which are guarranteed to be semantically valid by the obect space interface. (At least for the subset of object spaces we wish to use for a particular code execution framework.) A small but significant correllary to this is that the semantics of the operations within a general object space should not be assumed to be Python-like. That is, operations on object space obects should be performed for object space effects, not for execution level effects. This poses significant problems for the application space helpers to compute execution level relevant results. I'm not sure how to address this yet. -Rocco P.S. I appologize if this has been discused before on IRC. Has any progress been made in creating an archive of IRC logs? I get the impression a fair number of significant points have been made on IRC, and it would be best to archive them such that others not present can benefit from them as well. __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

3 3

funding and so
by holger krekel 01 Sep '03

01 Sep '03

hello pypy-devers, i long wanted to clarify my position on pypy-funding issues. During the Louvain-La-Neuve sprint i probably was the most skeptical/critical person regarding getting EU-funding for the pypy-project and its developers. That wasn't because i dislike the idea of getting EU-funding in itself. Quite the opposite. But I thought that the group of developers who attended our three sprints weren't organized and prepared enough to actually make the funding in good shape. I know from friends and EU-experienced people that setting up an EU project usually takes half a year (at best). The other problem i saw was that quickly moving into a development model where some people get payed and others don't is a risk in itself. The deadline seems to be the 15th of October, btw. Some people understood that i am just plainly against getting funding which is not true. In fact i want to help to make funding possible but i am not going to lead much efforts there. Laura and Jacob has been active in preparing the start of a proposal but i don't know if they find enough time to move it forward. I sure hope so. Also Anders has been investing time and contacting people which is great. Still we should make ours minds up if and how we want to go for the October 15th deadline. My priorities with PyPy definitely lie in development and dev-infrastructure issues. Also because i am already co-managing a bigger housing/artists project in my spare time (some of you know it) and also have to manage myself money-earning wise. cheers, holger

2 1

Sprint in Berlin, 31.9. - 6/7.10.2003
by Tomek Meka 11 Aug '03

11 Aug '03

Hello everybody! Now we have it! Thanks to the DG 2 FIRM (http://www.dg2.de/) we have 2 rooms, each 25 sqm, in the centre of Berlin, Ackerstr. 3a (Mitte). There are many cafes there, a university cafeteria is about ten minutes walk from there. There is also a cheap, clean hotel close-by (about 16 euros per night). I'll post you more details this week. It is also possible, that we (Christian and I) find free accomodation by our friends. Holger, could we arrange a wiki-page, so that everybody, who is coming to the sprint, could post up, when he/she is arriving, what is the flight number, phone number (mobile)? Bye for today! Tomek

2 1

opcodes bundled in a class?
by holger krekel 09 Aug '03

09 Aug '03

hello pypy, with the builtinrefactor branch i am at the point where i want to eliminate the 'appfile' concept alltogether in favour of intermingling app-level and interp-level code directly. And before i start to fix the stdobjspace (which still isn't working) i'd like to get rid of 'opcode_app.py' so that the interpreter is 'appfile'-free. It's easier to do this when the implementation of the opcodes (interp- or applevel) lives in methods of a to-be-created "Opcode" class. That's because a class can naturally be instantiated (with a space argument) and all app-level functions can be processed so they end up beeing an 'InterpretedFunction' instance which you can seemlessly/natively invoke at interp-level. e.g. def BUILD_CLASS(self, f): w_meths = f.valuestack.pop() w_bases = f.valuestack.pop() w_name = f.valuestack.pop() w_newclass = self.build_class(w_name, w_bases, w_meths, f.w_globals) f.valuestack.push(w_newclass) # not callable as is, takes no self-argument def app_build_class(name, bases, meths, globals): ... return metaclass(name, bases, namespace) I also think that our internal 'InterpretedFunction' or 'Code' object should be responsible for delivering an 'opcode' class specific to its code and space. This would also allow using a different opcode-set (and implementation) for certain functions. Eventually it might be possible to implement or invent bytecodes at app-level. The key task here is to have a compiler package that produces code objects with a specific 'Opcode' class indication. However, is anybody against putting the opcodes/helpers in a class? Note that the 'visilibity' feature that Armin mentioned ealier is currently not done. But there already is a concept called 'AppVisibleModule' also living in the gateway module. It wraps itself into an app-visible module. E.g. the 'builtin' or 'sys' module are classes that inherit from 'AppVisibleModule'. At wrapping-time all 'w_*' attributes are made visible on the corresponding wrapped module instance. Thus you can access the same (wrapped) object from App-Level or Interp-Level. There is some wrappings taking place but just look at the docstring :-) cheers, holger

3 10

update
by Laura Creighton 04 Aug '03

04 Aug '03

Jacob and I have managed to catch something, so far unknown, which has made us very sick, the sort where getting out of bed and making dinner is an accomplishment. We've been like this for more than a week now, for me more than two, and our brains have turned into potato salad. So we are very quiet, because most of the time, we are sleeping. back to bed, Laura

1 0

next sprint time
by holger krekel 04 Aug '03

04 Aug '03

Hello, on the last sprint in Belgium we discussed the next sprint place and time. The idea was End of September in Berlin. Because we couldn't find the right place in Berlin, yet, i asked someone in Amsterdam and he is now also checking if it's possible there. At least one person from the US wants to attend so Amsterdam wouldn'be the worst choice in that respect. However, even more important than the place is to find the right time. From the last discussions i take it that end of september/beginning of October is the earliest possible date. Also for quite a few people it's important to know the date as long in advance as possible. So i try to set up some reasanable choices: 22th-28th of September 29th-5th of October 5th-12th of October Please, if you are interested to come at any of the above the dates (or at all of them) please send me a private mail. I'll post the results by the end of the week and would pick the date where most people can come. From Jum and Armin i already have some information (and Armin seems to be able to come to any of the above but also wants to know early). If you have a better suggestion how to fix the next sprint time feel free to chime in. cheers, Holger --

1 0

Python parsers...
by Jonathan David Riehl 04 Aug '03

04 Aug '03

Hi all, I have a Python parser done in "pure" Python (no C extension module dependencies, etc...). I even have an implementation of pgen in Python. Now, I am wondering what the next step is. Shall I continue onward to bytecode compilation? Eventually, I am going to need some instruction about integrating my code in with pypy. I would be more than happy to press onward and attempt to reimplement a static Python to C translator, and I am also interested in more blue sky stuff like adding optional static typing or playing with type inference stuff. Let me know what ya'll think. Thanks! -Jon

4 6

another website update (design-wise)
by holger krekel 02 Aug '03

02 Aug '03

hello everybody, just a short notice that another cleanup-update to the web-page just took place. it's still far from perfect but now the layout has been unified to not use tables (yay!). Btw, the diffs for webpage updates are not sent to pypy-svn (unless somebody screems for those). At least all layout of the page elements should now be pretty stable through all the applications we use (some cgi-scripts, roundup, moin, mailman). I think it's a good time to cleanup the doc-hierarchy because it is now nicely visible from the web :-) cheers, holger

2 3