Mailman 3 September 2003 - pypy-dev

Re: [pypy-dev] Extended goals
by Laura Creighton Sept. 16, 2003

Sept. 16, 2003

In a message of Tue, 16 Sep 2003 13:24:12 +0200, Dinu Gherman writes: >I forgot to mention: if you really want EU money, you should, under >all circumstances, find a good explanation for how PyPy only can >fuel the world's most sophisticated future E-Government platforms! > >No joke! Combine this with the mobile devices I mentioned before! ;-) > >Dinu Well, given that next month AB Strakt is announcing at the scandianavian government conference -- ITOS, where we are the gold sponsor -- http://www.itos.se/ a total procurement system for the EU, and we want PyPy, in part, for reasons of scalability, that shouldn't be too hard. I can drown them in the marketing materials we are making for the conference .... Laura

1 0

Re: [pypy-dev] Extended goals
by Laura Creighton Sept. 16, 2003

Sept. 16, 2003

In a message of Tue, 16 Sep 2003 11:35:35 +0200, Christian Tismer writes: >Nicolas Chauvat wrote: >... > >> Ideally, we should have technical/research partners and end-user partne >rs. >> >> Do we have both at the moment ? Who are the end users? Having on board >> new end-users will be close to impossible in the upcoming month, but we >> can try. >> >> By the way, do we have both small and big partners ? > >I'm not sure. As I understood Laura, there are two >not so small companies interested. >That's why I'm talking about load balancing in distributed >networks, and maybe creating a tiny OS in PyPy. > >ciao - chris >-- They are interested but we cannot count on them. 3 months is hellishly fast for them to make a decision. (And you wonder why SMEs generate the most wealth for a nation). Laura

1 0

Boost your sexiness-boost your L|ps size
by Female Trends Sept. 15, 2003

Sept. 15, 2003

1 0

how to help with PyPy right now
by holger krekel Sept. 15, 2003

Sept. 15, 2003

Hello PyPy developers and observers, currently we are setting up (led by Laura Creighton) some documents in preparation for applying to EU funding. We know that this is far-too-close timing especially considering the private workload of everybody and the approaching "Berlin" sprint and its organization. That's why everyone is warmly welcomed to read the evolving documents in the "funding" section of the website, e.g. http://codespeak.net/pypy/index.cgi?doc/funding/B2.0.0_background.html If you have any suggestions, corrections or additions to contribute that would most certainly help. Btw, with each document you find a "ReST-source" link at a ReST-text file which is the source for each documentation page. Please feel free to send corrected/extended versions to pypy-funding(a)codespeak.net so we can incorporate them. Alterternatively if you have an svn-client you can check out the documents at http://codespeak.net/svn/pypy/trunk/doc/funding thanks for any help, Holger & Laura P.S.: Laura is overworked, and may not answer you as quickly as you deserve, but is greatful for any help.

1 0

Re: [pypy-dev] Extended goals
by roccomoretti＠netscape.net Sept. 15, 2003

Sept. 15, 2003

Christian Tismer <tismer(a)tismer.com> wrote: >holger krekel wrote: > >> where the main idea was to have PyPy perform syscalls directly >> (without any glibc etc.). this would make for a very efficient >> and small runtime platform. Driving hardware directly (without the >> help of some linux-kernel) is certainly possible but i wouldn' t >> propose this for the next years unless someone like James Tauber is >> to join the project :-) > >Well, may this could be started using the Linux kernel, >and gradually move over to direct hardware support. >This also gives us the opportunity to extend the >project quite, if funding allows and there is interest. I hate to be the one to bring up licensing issues, but ... I might recommend using a *BSD instead of Linux, to avoid having to manage GPL code portions. If an (admittedly optimistic) goal of PyPy is to become the reference implementation of Python, licensing concerns need be addressed, as I get the impression that Guido et al. would much prefer not to have to deal with the GPL/FSF. It's not that I'm against taking advantage of existing work when availible, its just that interoperability with the core Python developers (as well as the Python-using community in general) would be enhanced by sticking to the BSD/MIT (i.e. original Python) licensing scheme as much as possible. Next-week-I'll-bring-up-Emacs-vs-Vi-ly'rs, ;-) -Rocco __________________________________________________________________ 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

2 1

RE: [pypy-dev] "Unwrap" Concidered Harmful
by roccomoretti＠netscape.net Sept. 15, 2003

Sept. 15, 2003

Armin Rigo <arigo(a)tunes.org> wrote: >On Sat, Aug 23, 2003 at 09:00:58PM -0400, Rocco Moretti wrote: >> all information about value. So there is no way we can say that >> s.unwrap(s.wrap(x)) == x. > >I am now coming closer to the idea that wrap() should be redefined as well, >because it is used not only on simple types but also on "internal interpreter >structures", like code objects plus others more internals than that. Let me see if I can clarify my present understanding. (Thinking out loud follows...) When we use wrap(x), we mean one of two things: 1) Give me an application level object that is equivalent to x. 2) Make the interpreter level object x available at application level. Case 1 ------ Michael advocates calling use 1) "build". For the build case, it is wrong to assume that unwrap(wrap(x)) == x, as, in general, an application level object may not have a 1-to-1 correspondence with an interpreter level object. My opinion is that "unbuild" should not exist. Once an object is built, there is no guarantee that it will ever again correspond directly to an interpreter level object. If we need an interpreter level object out of an application level one, we should do it in a very restricted way, for a specified purpose. If we want an interpreter level object, it is so that we can do manipulations on it, but in general, unwrap and manipulations are not associative: space.unwrap(space.str(w_x)) != str(space.unwrap(w_x)) space.is_true() is an example of such a limited use function. In my mind, is_true() exists for a single purpose - to determine if a wrapped object is true so that the interpreter can determine if a JUMP_IF_TRUE type branch should be taken. Any other use would be considered a "hack". I can perhaps see the need for a .to_string(x) function, with the semantics that "the results of this function are going to be presented directly to the user - I don't care what sort of bizarre and twisted data structure 'x' actually represents, just make a reasonable string so that the human at the keyboard has some kind of feedback for debugging purposes." Use of the output for any other purpose would be highly discouraged. - I would hesitate to add any more such functions until a compelling need for one is demonstrated. Case 2 ------ This is what we are looking for when we say .wrap(frame). Here the role of unwrap depends on how wrap behaves. [If unwrap_2 exists, it should *always* have the semantics that unwrap(wrap(x)) == x] - Possible alternative names for this functionality include shadow() or proxy(). As I interpret it, Armin indicates wrap_2() should create an application level object that shadows an interpreter level object. That is: y = space.wrap(x) print x # <'xyz'> space.fubar(y) #.fubar alters y print x # <'yzw'> and also: y = space.wrap(x) print y # <'xyz'> x.fubar() print y # <'npq'> In implementation, y is just a proxy which passes along the modifications or attribute acesses to the underlying interpreter object, and (unwrap(wrap(x)) is x) is True. An alternative is to have wrap_2() create a new object which retains enough information to recreate an interpreter level object when unwrap() is called. In this case there would be no differences in output for the print statements above, and (unwrap(wrap(x)) is not x) is True. We still have a problem with unwrap if we allow the application level to modify objects produced by wrap_2. Say we have a function object. What happens when someone says: fun.func_name = name in application level code? What if name is generated from the application level and contains an object that represents "92% chance of the string 'MyFun', 7% chance of a class with the .__str__ method hooked up to the fortunes generator, and 1% chance of rain."? The only solution I see is to limit the rvalue to objects that were also created with wrap_2 and thus have their interpreter level values still attached. So in effect, our black box objects become a black hole - values go in, but can never come back out to interpreter level. -Rocco P.S. On further consideration, there is a third solution. We *can* allow an "unbuild" function, with the directive that it is nervous, and raises an exception every time it is the least bit confused at what to do. This allows for free flow of information in the regular cases when we aren't doing anything tricky with the object spaces. My concern would be that we would become dependant on a well behaved unbuild, and require it in a critical piece of code, making development of the clever object spaces difficult to impossible. I'd disapprove of it's use in any code that would be exercised in interpreting the majority of Python scripts. Discourage its use and save it for implementing the dusty introspection/self referential corners of Python only - and be sure to document the expected behavior of the return values well, so any conflicts can be anticipated. __________________________________________________________________ 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

2 1

new section B4.2_other_countries.txt
by Laura Creighton Sept. 15, 2003

Sept. 15, 2003

Don't be impressed, it's just a list of questions not to forget to ask Stockholm. You are free to add your own, of course. I wish you _would_. Make us a list so we don't forget stuff. Call it Stockholm_Questions.txt or some such and stick it in the doc directory. Thanks, Laura

1 0

HELP! I can't do svn up!
by Laura Creighton Sept. 14, 2003

Sept. 14, 2003

Error follows: At revision 1289. Fetching external item into trunk/www/service/vpath svn: RA layer request failed svn: REPORT response handling failed to complete the editor drive

2 1

history of PyPy
by Laura Creighton Sept. 14, 2003

Sept. 14, 2003

Holger wrote something about 'how Armin, Christian and Holger started discussing this on the german python mailing list' for the history of the project. I've since lost it. Anybody have that, also the exact dates for the Sprints? Laura

2 2

Re: [pypy-dev] history of PyPy
by Laura Creighton Sept. 14, 2003

Sept. 14, 2003

In a message of Sun, 14 Sep 2003 09:32:15 +0200, holger krekel writes: >Hello Laura, > >[Laura Creighton Sat, Sep 13, 2003 at 04:51:47PM +0200] >> Holger wrote something about 'how Armin, Christian and Holger >> started discussing this on the german python mailing list' for >> the history of the project. I've since lost it. Anybody >> have that, also the exact dates for the Sprints? > >Here is the posting where i offer to organize the first "Minimal >Python" sprint which quickly turned into "PyPy". It is a response >to Christian Tismer who said in a "P.S." [1] to Gerson Kurz that >writing "a totally minimzed python" would be quite interesting. > >http://starship.python.net/pipermail/python-de/2003q1/002925.html > >Christian and me involved Armin (in private mails) in the next weeks >and we quickly agreed to send out the first sprint announcement and >invitation to the "Hildesheim" sprint (containing the exact dates): > >http://mail.python.org/pipermail/python-dev/2003-January/032427.html > >Actually, i came to the idea of doing that sprint because i attended >Zope3 sprints and liked several aspects about them. The problem here >obviously was that we started out from nothing which is not >common but proved to be workable. > >hope that helps, if not, ask for more detais. > >cheers, > > holger > > >[1] Never underestimate the potential of a P.S. :-) Oh man, this is perfect. They want Agile Methodologies!!! ------------ New paragraph should be something like: ---------- Meanwhile, on the German Python mailing list, http://starship.python.net/mailman/listinfo/python-de an unrelated discussion was about to bear fruit. FOOTNOTE: Here's the mail that started it all, http://starship.python.net/pipermail/python-de/2003q1/002925.html include full text. Academically trained Python programmers were pondering writing an implementation of Python in itself. This group included Armin Rigo, author of Psyco http://psyco.sourceforge.net/introduction.html, a specialising Just-In-Time compiler for Python, and Christian Tismer, author of Stackless Python, http://www.stackless.com/ an implementation of Python which does not use the C stack. These people knew and were interested in doing exactly that as part of the design. It is useful to quote Armin Rigo, stating the goals of Psyco in full, from its website: My goal in programming Psyco is to contribute to reduce the following wide gap between academic computer science and industrial programming tools. While the former develops a number of programming languages with very cool semantics and features, the latter stick with low-level languages principally for performance reasons, on the ground that the higher the level of a language, the slower it is. Althought clearly justified in practice, this belief is theoretically false, and even completely inverted --- for large, evolving systems like a whole operating system and its applications, high-level programming can deliver much higher performances. The new class of languages called "dynamic scripting languages", of which Python is an example, is semantically close to long-studied languages like Lisp. The constrains behind their designs are however different: some high-level languages can be relatively well statically compiled, we can do some type inference, and so on, whereas with Python it is much harder --- the design goal was different. We now have powerful machines to stick with interpretation for a number of applications. This, of course, contributes to the common belief that high-level languages are terribly slow. Psyco is both an academic and an industrial project. It is an academic experiment testing some new techniques in the field of on-line specialization. It develops an industrially useful performance benefit for Python. And first of all it is a modest step towards: High-level languages are faster than low-level ones! FIXME Footnote to: http://psyco.sourceforge.net/introduction.html PyPy would be a more ambitious step, of course. Also instrumental was Holger Krekel, at TrillkeGut a (what the heck do you call it?? in Hildesheim). Holger Krekel was experienced in one of the latest in Agile Software methodologies, Sprint-driven development, from his experience in the Zope HOLGER WRITE ME A PARAGRAPH HERE PLEASE ABOUT WHY THIS IS COOL This was precisely what the Python Business Forum members had been looking for. Academics conversant in the latest in compiler theory who were interested in producing the Python interpreter which they needed. We began discussing the possibility of collaboration, both on mailing lists, FIXME list our mailing list and in our first face-to-face meeting at Hildesheim, Germany Feb 17-23 2003. We decided to make a prototype to test the proof of concept, and our ability to work together. We would get together every six weeks in our own time, and work on the prototype in intense work sessions which are known as 'Sprints'. FIXME Etymology of Sprint? After the first Sprint at TrillkeGut in Hildesheim, we held subsequent Sprints at AB Strakt in Gothenburg, Sweden, and at the University of Louvain-La-Neuve in Belgium. By the time the Louvain-La-Neuve Sprint, which was held June 20-24, ended, the PyPy project had produced a working prototype. There existed a working interpreter and standard implementation of 90% of the python types, as well as such language features as nested scopes, generators and metaclasses. We had begun work on a type inference engine. Perhaps most importantly, we had the enthusiastic support of the Python community. Guido van Rossum, author of Python, not only endorsed the PyPy project, but attended our Louvain-La-Neuve Sprint. No work had been done on actually Optimising the code, so it ran FIXME 30,000 times(?) slower than existing Python. But for a proof of concept, approximately three weeks work total, it was a success. It was time to look for funding.

1 0