Mailman 3 July 2003 - pypy-dev

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

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

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

Re: [pypy-dev] another website update (design-wise)
by Laura Creighton 25 Jul '03

25 Jul '03

I think things look a lot better, but doc end ups looking like a flat namespace, which it isn't. As we add things the left hand side begins to to be already too long. I think we need two things. First of all, we need a 'suggested order in which to read the docs' and secondly, we need an short discription of the document so that people who want to just read a few documents don't have to browse the lot. The lhs clickables are written in a font that has serifs. The rhs, and the docs themselves are written in a serif-less font. I would prefer a serif font for papers, but not enough to kick up a fuss. Is this the sort of thing which one can specify using ones own browser, or is this something which is set from codespeak? Just curious. Some of us have some nice slides of us working, et al. Should we put those in? Laura

2 1

new (documentation) infrastructure
by holger krekel 20 Jul '03

20 Jul '03

hello pypy, if you just want to see some results of the infrastructure-hacks: http://codespeak.net/pypy/?doc jum and me hacked the previous days on various bits of the (web)- infrastructure for the pypy project. One outcome is the spawn of a new "vpath" project which encapsulates local filesystem pathes as well as versioned subversion pathes. It makes it very easy to e.g. save/load objects to filesystem pathes (or even from the svn-repo) in a uniform "expected" way. Here is a real-world Example for gathering all (previously generated) "subversion info" and the ReST-generated html from a filesystem subtree. from vpath.local import Path from vpath.filters import endswidth, nodotdir docpath = Path('/projects/pypy/doc') for path in docpath.visit(endswith('.txt'), rfunc=nodotdir): infopath = path.newsuffix('.svninfo') info = infopath.load() info.htmlpath = path.newsuffix('.html') infolist.append(info) The idea to put this "vpath" module into its own project was made possible by a new svn-concept we discovered: you can stick a property called "svn:externals" to a directory. This property contains name-url pairs. The 'name' is put into the namespace of the directory and the bound object is taken from "importing" what the 'url' points to. Thus if you want to use the "vpath" module in your project you just do svn propset "svn:externals" \ "vpath http://codespeak.net/svn/vpath/trunk/dist" . then subsequently on "svn up" you'll get the trunk-revision of 'vpath' - externally fetched (it needn't be in the same repo). If you modify the vpath-module (because you have commit rights) the others working on it get a diff. This makes it extremely easy to couple projects in a version-controlled way. Using this and some other fresh infrastructure we now have a "doc" item in the menu-bar of the pypy-site http://codespeak.net/pypy/?doc which should make it easy to browse documentation and spot which documents are outdated etc. The web-page reflects the "trunk" version of our "doc"-directory. If you checkin new ReST-docs then on the server-side a script will generate all information which is subsequently used from the cgi to display it dynamically. Now i have a deal to offer. If someone writes a "plugin" (or whatever) for ReST that accepts parameters and is allowed to return some html fragment which is inserted in-place (where the plugin is invoked) then i'll do a syntax-highlighted cross-referenced "source-view" of the pypy source, including presenting "document-links" to a source-file (which are configured using some svn-property like "pypy:doc"). Both projects are probably a bit of work but it would certainly help to increase the "cross-referencedness" of documentation and source code (including inlining snippets from a source-file to have up-to-date examples). Please bear with me if i messed up the web-site at some places. The messiest part definitely was to get CSS-related rendering "right". so much for now, cheers, holger

2 2

Someone changed the wiki FrontPage to an old version
by amaury.forgeotdarc＠ubitrade.com 17 Jul '03

17 Jul '03

Hello, I keep an interested eye on the PyPy project, and I have just seen that the wiki's FrontPage is considerably shorter than a few days ago. http://codespeak.net/moin/pypy/moin.cgi/RecentChanges shows that the content of FrontPage was reverted to an old version. The page now talks about the "next sprint scheduled in Belgium" ;-) and links to the documentation disappeared. Is this intentional? Hopefully the diffs with the previous version are still available. You're doing a very impressive work... continue! -- Amaury Forgeot d'Arc

3 3

new pypy-funding mailing list
by holger krekel 15 Jul '03

15 Jul '03

hello pypy, i have just created the pypy-funding mailing list. The PyPy-funding list is a platform for focused discussions about funding issues such as the EU-funding proposal. I rather randomly subscribed a few people to see if everything works. They should have got a welcome-message. If you are interested to discuss those issues and/or spent some time/though trying to get funding then please subscribe here http://codespeak.net/mailman/listinfo/pypy-funding If you have problems, mail me. cheers, holger

1 0

Re: [pypy-svn] rev 1121 - in pypy/branch/builtinrefactor/pypy:interpreter module module/test
by Armin Rigo 14 Jul '03

14 Jul '03

Hello Holger, On Sat, Jul 12, 2003 at 11:50:54AM +0200, hpk(a)codespeak.net wrote: > - there is a new (experimental, of course!) approach to executing > code objects. Actually the "app2interp" method when called > makes up an "AppBuiltinCode" instance which is a simple form > of a code object. Instead of the whole "build_arguments" to-dict-locals- > and-then-get-it-out-of-locals business it constructs arguments > in a straightforward manner. Some more refactoring would be nice here. I'm posting here something we discussed at the end of the latest sprint: from the point of view of decoding the arguments, a frame is just a repository of 'fast locals' slots. Hence the idea that instead of decoding arguments and building a real 'locals' dictionary, we directly put the arguments in a frame-like class. As it only makes sense to use a real PyFrame instance when we are about to call a Python (app-level) function, we could use a base class for the general case: + ActivationFrame + PyFrame [the current frame class] + BuiltinFrame + ExecutableCode [new proposed name for PyBaseCode] + PyCode [new proposed name for PyByteCode] + BuiltinCode [new proposed name for PyBuiltinCode] ExecutableCode instances are used as the 'func_code' attribute of function objects; they would have methods to create an ActivationFrame instance of the correct corresponding class, and then the ActivationFrame's list of 'fast locals' would be populated with the generic ExecutableCode.build_arguments(). The base ActivationFrame is essentially nothing more than a 'fast locals' container. It is easy to either use that as the real 'fast locals' during interpretation in PyFrame, or pick the arguments from the list in BuiltinFrame to pass them to the built-in interpreter-level function. I think it looks like a nice way to minimize the number of times the arguments must be copied around. Armin

2 1

RE: type problems
by Hunter Peress 14 Jul '03

14 Jul '03

holger krekel That may be a good idea. I am currently hunting down a deeply nested Exception problem and knowing which frames get created executing which code helps in understanding what's going on. Without lots of print-statements this would be very difficult (not that it really gets easy :-). are you tracking these frames from within the appspace or object space ? it would probably be helpful to have a tool like ping's cgitb (which he/I ) hacked into a text-mode version, and to have it for both object and appspace, no? __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

4 3