Mailman 3 April 2007 - pypy-dev

Forward: Dyla 07
by Terry Reedy May 8, 2007

May 8, 2007

Posted on c.l.p., but possibly more relevant here: ------------- Dear colleges, You might want to consider Dyla'07 as a good venue to present your work and your favourite programming language. Regards, Alexandre ************************************************************************** Call for Papers Dyla 2007: 3rd Workshop on Dynamic Languages and Applications July 31, 2007, Berlin (Collocated with ECOOP 2007) http://dyla2007.unibe.ch ************************************************************************** Objective ========= The goal of this workshop is to act as a forum where we can discuss new advances in the conception, implementation and application of object-oriented languages that radically diverge from the statically typed class-based reflectionless doctrine. The goal of the workshop is to discuss new as well as older "forgotten" languages and features in this context. Topics of interest include, but are certainly not limited to: - agents, actors, active object, distribution, concurrency and mobility - delegation, prototypes, mixins - first-class closures, continuations, environments - reflection and meta-programming - (dynamic) aspects for dynamic languages - higher-order objects & messages - ... other exotic dynamic features which you would categorize as OO - multi-paradigm & static/dynamic-marriages - (concurrent/distributed/mobile/aspect) virtual machines - optimisation of dynamic languages - automated reasoning about dynamic languages - "regular" syntactic schemes (cf. S-expressions, Smalltalk, Self) - Smalltalk, Python, Ruby, Scheme, Lisp, Self, ABCL, Prolog, ... - ... any topic relevant in applying and/or supporting dynamic languages. We solicit high-quality submissions on research results and/or experience. Submitted papers must be unpublished and not submitted for publication elsewhere. Submissions should not exceed 10 pages, LNCS format (www.springer.com/lncs). Submission ========== Prospective attendees are requested to submit a position paper or an essay (max 10 pages, references included) on a topic relevant to the workshop to Alexandre Bergel (Alexandre.Bergel(a)cs.tcd.ie). Submissions are demanded to be in .pdf format and should arrive before May 13, 2007. A selection of the best papers will be made, which will require an extension for an inclusion in a special issue in Electronic Communications of the EASST (eceasst.cs.tu-berlin.de). For this purpose, a new deadline will be set after the workshop. Moreover, Springer publishes a Workshop-Reader (as in the case of previous ECOOPs) which appears after the Conference and which contains Workshop-Reports (written by the organizers) and not the position papers submitted by the participants. Important dates =============== Submission due: May 13, 2007 Notification of Authors: May 31, 2007 ECOOP'07 Early Registration Date: June 15th. Workshop: July 31, 2007 Organisers ========== Alexandre Bergel Wolfgang De Meuter Stéphane Ducasse Oscar Nierstrasz Roel Wuyts Program committee ================= Alexandre Bergel (LERO & Trinity College Dublin, Ireland) Johan Brichau (Université catholique de Louvain, Belgium) Pascal Costanza (Vrije Universiteit Brussel, Belgium) Wolfgang De Meuter (Vrije Universiteit Brussel, Belgium) Stéphane Ducasse (University of Annecy, France) Erik Ernst (University of Aarhus, Denmark) Robert Hirschfeld (Hasso-Plattner-Institut, University of Potsdam, Germany) Oscar Nierstrasz (University of Bern, Switzerland) Matthew Flatt (University of Utah, USA) Dave Thomas (Bedarra Research Labs, Canada) Laurence Tratt (King's College London, UK) Roel Wuyts (IMEC & Université Libre de Bruxelles, Belgium)

4 7

What about a Slate front-end?
by Paul deGrandis May 2, 2007

May 2, 2007

Hi all, Not too long ago there was a discussion about possible front-ends. I know someone here is part of the tunes project... so how about a slate front end? There has been recent talk on the slate mailing list about the deficiencies with the current VM and some weird setup and handling of the stack... perhaps pypy is a better setup for the language. Just a thought. Regards, Paul

2 1

Re: [pypy-dev] PyPy JVM Backend
by Antonio Cuni April 30, 2007

April 30, 2007

Hi Niko, hi Paul! Here are some remarks/suggestions about your discussion. I'm also CC-ing pypy-dev, so we can also catch someone else's suggestions, if any :-). > First, there are those things are absolutely necessary to do to get PyPy > to translate: > > 1. weak refs > 2. I don't know what else goes here --- try and see I guess Apart from weak refs, I think the other big feature missing is support for external functions (mostly I/O functions). Unfortunately this part is a bit of a mess: since in the old days pypy's only targets were low-level platforms the I/O model of RPython is modeled after the unix file descriptors. This means that at the moment high level backends need to emulate the fd interface and forward the real work to the native I/O functions: to see how gencli does, look at the ll_os class in translator/cli/src/ll_os.cs. I guess this would be the easiest way also for genjvm, and probably for now we should pick this solution. I know, this it's both ugly and hackish; the good news is that I and Carl did some work towards a better solution: at the moment all the I/O inside the standard interpreter is done using the (interp-level) rlib/streamio.py library, which in turns uses the low-level file descriptor interface; the long-term solution would be to provide an alternative implementation of streamio.py that uses .NET/Java streams and let the backends using that instead of the current one. Finally, let me add another task that I think it's very important: 3. make most of existing tests passing with genjvm Look at cli/test directory: you will find a lot of files that import tests from somewhere else (mostly from rpython/test). genjvm do the same, but a lot of tests are still missing; once you get all those tests passing you can be quite confident (but still not sure, of course) that pypy would translate. Some of the tests in cli/tests are cli-specific or very old and not conforming to the new test framework; here is a list of the tests you should port these tests to jvm: - test_range.py - test_constant.py - test_tuple.py - test_float.py - test_builtin.py - test_int.py - test_exception.py Moreover, there is test_runtest, which test a bit of the gencli test framework itself; if the genjvm test framework is similar to the gencli's one, it could make sense to port this also this one. Niko, what do you think? > New features: > > 1. allow Java code to be invoked (need to look at the CLI work here) > 2. JSR 223 I have to admit that I don't know very much about JSR-223: Paul, could you send me the specification, please? I don't feel like to register to sun's website :-). If I understand correctly the level of integration provided by JSR-223 is simpler/less powerful than the one offered by Jython, right? If this is the case, it could make sense to implement JSR-223 first (also because it's part of Paul's SoC proposal), then try to provide the same level of integration as Jython (or IronPython for the .NET side); for the latter task, I think that some code could be shared between gencli and genjvm. > Internal Changes That "Would Be Nice": > > 1. Estimate the maximum size of the stack, rather than giving some > arbitrary "high" number as we do know. this would also be useful for gencli :-) > 2. Deal with JVM size limits for very large methods and classes. (never > hit those yet but probably will) probably this falls into the "try to translate pypy-jvm and see" task :-). > 3. Find a better way to handle exceptions. One suggestion was not to > map rpython's "Object" to the class Object but rather to an interface. Indeed. Also useful for gencli. > 4. Use protected access modifiers rather than public. Pedronis seems to > think this would be important. I don't see how it could be so important at this point. Am I missing something? > 5. Speed and performance optimizations, similar to those being done for C# let me add another point: 6. once we get pypy-jvm, run Python's regression tests and try to pass as much of them as possible. I personally think that point 6 is more important than point 5 at the beginning. > Of these ideas, I am not sure which are best for a "first project". I > would be happy to handle weakrefs, since it seems like they may be quite > easy for me but time consuming for you, but if you wanted to look into > them, that's fine with me too. Adding support for weakrefs to gencli was a very easy task: just wrap/unwrap the objects into the System.WeakReference when requested. > Antonio, you said you tried to translate PyPy as a whole with the JVM > backend? It seems that is the best way to find the list of things that > need doing, but I haven't done it myself yet. Yes, I tried: after a bit of hacking on the interpreter code I could get rid of weakrefs, but the translations failed on a KeyError inside jvm/database.py, then I gave up. To sum up, I think that priority wise the most important thing to do is to port the remaining tests to genjvm and make them passing: weakrefs and external functions are subtasks of this; then try-fail-fix-try until we get a running pypy-jvm. ciao Anto

5 12

Re: [pypy-dev] Fwd: New Javascript parser in the works
by Laura Creighton April 28, 2007

April 28, 2007

In a message of Sat, 28 Apr 2007 18:22:50 +0200, Carl Friedrich Bolz writes: >would be valid. This opens its own set of problems such as: > > a = b > ++ c > >Which would most likely be parsed to be equivalent to: > > a = b++; > c; > >Whereas with the spec it is: > > a = b; > ++c; > >No clue how to fix that, yet. > >Cheers, > >Carl Friedrich In the Canadian military for an analagous set of problems we did the following: First of all you do the laxness move -- i.e. you get rid of the semicolon restictions. Then you get a big a sample space of the problem you have as you are willing to deal with. In some way determine that it is 'typical' -- which is a research topic in itself, but if you are not in the field, then the rule is 'make a good guess, refine it later when you are wrong'. Then determine where it is better to stick in the semi based on how the language is actually used. So, should the spec differ from what you do, that is actually of no problem until you find that people really write code like the above and want the spec, not the way you parsed it. You would be surprised at how many of those problems go away because no human ever writes things like that. Should your problem space be dominated by machine-generated code, though, your personal ideas of 'how often will somebody write this' goes out the window. Laura, who thinks that the W3C validation project may be interested in what you are doing and have already got some problematic use cases to worry about.

2 1

Fwd: New Javascript parser in the works
by Leonardo Santagada April 28, 2007

April 28, 2007

Forgot to send to pypy-dev. And now I commited code that was supposed to do what I wanted with the tests in revision 42384. But the code is ugly, my visitor somehow don't visit everyone it should and I am to sleepy to code. Am I doing things the wrong way or doing what I wanted with the tests that hard? Iniciar mensagem reenviada: > De: Leonardo Santagada <santagada(a)gmail.com> > Data: 27 de abril de 2007 19h24min15s GMT-03:00 > Para: Carl Friedrich Bolz <cfbolz(a)gmx.de> > Assunto: Re: [pypy-dev] New Javascript parser in the works > > > Em 27/04/2007, às 17:11, Carl Friedrich Bolz escreveu: > >> Carl Friedrich Bolz wrote: >>> Just looking at the grammar made me note the following problem: >> [snip] >> >> hm, now that I found this problem, which grammar are you using >> exactly? The one at >> > the one in the standard, as you sugestd to me... it is at: > http://www.ecma-international.org/publications/standards/Ecma-262.htm > >> http://www.mozilla.org/js/language/js20/formal/parser-grammar.html >> >> gives the rules for addition correctly: >> >> AdditiveExpression ==> >> MultiplicativeExpression >> | AdditiveExpression + MultiplicativeExpression >> | AdditiveExpression - MultiplicativeExpression >> >> or did you just rewrite it incorrectly? >> > > I both rewritten it incorrectly and also there is a problem, if I > put MultiplicativeExpression first like on the standard and in the > mozilla one I get code like 5+4 interpreted as having one > multiplicative expression with 5 and somehow it doesn't consume all > the input and still thinks it is valid. > > The other problem was that I didn't know how to fix it, so I just > did what I could expecting that with some code people would help me > more (this one I got right :). The biggest problem with parsing is > that there is no one using it besides you... at least you help me a > lot so i'm not really complaning. > > About tests I'm having this problem, I want to create generator > tests like some that I have but I would like to do something like > having lots of lines of tests, maybe with comments and maybe > setting what would be the start simbol to try to match it. Also I > would like to be able compare the results doing tests like: > checking the number of a type of node on the tree (eg: 5+5 should > have 2 numeric literals). The perfect thing would be able to print > how the trace of the packratparser, seeing what rules it is > executing. But I really want to have a better testing suite, but > like just failing some test for a reason I do not know or passing a > test but doing things completely wrong is not sufficient for me > now... I will work to make this test tool. > > Now about semicolons, how should I deal with them? in the spec the > grammar doesn't deal with them and in the mozilla one I don't see > how they are doing it also. As we have set that as the parsing > module works today it is not possible to do automatic semicolon > insertion, can we do "forced semicolon presence" as seen on C and > Java? (some lightbulb just lightened up here, maybe I should look > for the grammar of any of those two languages) > > > >> Cheers, >> >> Carl Friedrich > > -- > Leonardo Santagada > santagada(a)gmail.com > > > -- Leonardo Santagada santagada(a)gmail.com

3 4

New Javascript parser in the works
by Leonardo Santagada April 27, 2007

April 27, 2007

I started development of the javascript parser, based on the pythongrammar.txt file on parsing test dir. The thing is still in its infancy, but I just wanted to say that I am working on it, and would love any help. It is living in users/santagada/newjsparser for now... will move to js when it is at least kind of working. About the parsing lib I have some questions (should be asking cfbolz but I don't seem to find him on irc lately): * ParsingError should print something like lineno: self.lineno+1 collum: self.collum+1 (I know there is a pretty error function, but still) * IGNORE and friends, how do I make then work? * I don't know why when it recognizes something (or I think it should) it just gives me list index out of bounds (I will check what is happening, but if someone know why it would be better). About the grammar: * based on python grammar, so automatic semicolon insertion is OFF. You have optional semicolons at the end of lines though * No regex literals (ahh someday maybe, i'm not really interested in them) * Lot's of work to be done still :) -- Leonardo Santagada santagada(a)gmail.com

2 4

Re: [pypy-dev] Who's developing language interpreters in PyPy
by Robert Schmitt April 24, 2007

April 24, 2007

> Well, you can always try to build a dynamically extensible Pascal > environment with automatic memory management :-) Pascal? A nice university language for its time, but the type system makes practical use an absurd attempt (cf http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-pascal.html) > Which reminds me to mention that a Smalltalk environment would be a nice > project in PyPy. What about a C/C++ interpreter/compiler, there would be some real benefit if people could transpile C code to python. Plus, there's an existing C interpreter project out there, maybe there is a way to reuse some parts or at least some ideas of it. (This is probably too big a project for one person, but if there's any interest in this I'd be happy to join :-).

3 3

Motivation for re-implementing R (GNU S) in PyPy (perhaps?)
by Maurice Ling April 24, 2007

April 24, 2007

Well, R is free and open sourced. It is based on S and Splus, which the developers decided to close-source after a while (after achieving success). R is also known as GNU S for that matter. IMHO, R itself is a simple language and a relatively simple platform. It is a language that manipulates data but philosophically, it is not a statistical or mathematical language. The R core team seems to adhere to the view that R is a programming language where (by chance and intent) a lot of statistical tools are built on. Hence, most of the statistical libraries for R are written in R. I believe that the entire Bioconductor is written in R. Hence, the motivation for considering implementing or re-implementing R in PyPy is "natively" to bring in the strength of R (huge amounts of statistical libraries and data sets) into Python. I have to admit that my skills in this area (langauage interpreters/compilers) is rather limited to undergraduate level but I'm willing to learn more. So I'm currently reading codes on language interpreters for esoteric languages like BrainFuck simply because they are tiny but provides the relevant concepts. So, anyone like to support the idea of (re-)implementing R on PyPy? I'll need some "emotional" strength to go on this route. Also willing to hear other radical options... Another thing of interest to me is implementing modeling/simulation languages in PyPy as it will help in my future career route but my knowledge of even the simulation languages are rather limited. Please advice and comment. Cheers maurice

3 3

EuroPython 2007 - call for refereed papers
by arigo＠tunes.org April 24, 2007

April 24, 2007

Hi all, He're a reminder to submit a talk at EuroPython! Like each year, we have both the regular conference (see call at http://indico.cern.ch/conferenceCFA.py?confId=13919) and a somewhat separated Refereed Papers section. Here is the call for the latter. The deadline for both is the 18th of May. ======================================================================== EuroPython 2007 Vilnius, Lithuania 9-11 July Call for Refereed Papers http://www.europython.org/ ======================================================================== EuroPython is the only conference in the Python world that has a properly prestigious peer-reviewed forum for presenting technical and scientific papers. Such papers, with advanced and highly innovative contents, can equally well stem from academic research or industrial research. We think this is an important function for EuroPython, so we are even making some grants available to help people with travel costs. We will be happy to consider papers in subject areas including, but not necessarily limited to, the following: * Python language and implementations * Python modules (in the broadest sense) * Python extensions * Interoperation between Python and other languages / subsystems * Scientific applications of Python * Python in Education * Games * Agile Methodologies and Testing * Social Skills We are looking for Python-related scientific and technical papers of advanced, highly innovative content that present the results of original research (be it of the academic or "industrial research" kind), with proper attention to "state of the art" and previous relevant literature/results (whether such relevant previous literature is itself directly related to Python or not). We do not intend to let the specific subject area block a paper's acceptance, as long as the paper satisfies other requirements: innovative, Python-related, reflecting original research, with proper attention to previous literature. Abstracts ========= Please submit abstracts of no more than 200 words to the refereeing committee. You can send submissions no later than 18 May 2007. We shall inform you whether your paper has been selected and announce the conference schedule on the 25 May 2007. For all details regarding the submission of abstracts, please see the EuroPython website (http://www.europython.org). WARNING: Independently of their topic, all abstracts must be submitted *in the Refereed Papers track* in order to be considered by the refereeing committee! If your abstract is accepted, you must submit your corresponding paper before 29 June 2006. Last-minute changes will be accepted until the start of the conference. You should submit the paper as a PDF file, in A4 format, complete, "stand-alone", and readable on any standards-compliant PDF reader (basically, the paper must include all fonts and figures it uses, rather than using external pointers to them; by default, most PDF-preparation programs typically produce such valid "stand-alone" PDF documents). There are no strict typesetting rules. Refereeing ========== The refereeing committee, selected by Armin Rigo, will examine all abstracts and papers. The committee may consult external experts as it deems fit. Referees may suggest or require certain changes and editing in submissions, and make acceptance conditional on such changes being performed. We expect all papers to reflect the abstract as approved and reserve the right, at our discretion, to reject a paper, despite having accepted the corresponding abstract, if the paper does not substantially correspond to the approved abstract. Presentation ============ The paper must be presented at EuroPython by one or more of the authors. Presentation time will be between half an hour and an hour, including time for questions and answers, depending on each paper's details, and also on the total number of talks approved for presentation. Proceedings =========== We will publish the conference's proceedings in purely electronic form. By presenting a paper, authors agree to give the EuroPython conference non-exclusive rights to publish the paper in electronic forms (including, but not limited to, partial and total publication on web sites and/or such media as CDROM and DVD-ROM), and warrant that the papers are not infringing on the rights of any third parties. Authors retain all other intellectual property rights on their submitted abstracts and papers excepting only this non-exclusive license. Subsidised travel ================= We have funds available to subsidise travel costs for some presenters who would otherwise not be able to attend EuroPython. When submitting your abstract, please indicate if you would need such a subsidy as a precondition of being able to come and present your paper. (Yes, this possibility does exist even if you are coming from outside of Europe. Papers from people in New Zealand who can only come if their travel is subsidised, for example, would be just fine with us...). -+- Armin Rigo

1 0

Who's developing language interpreters in PyPy
by Maurice Ling April 23, 2007

April 23, 2007

Hi, I've been reading up on pypy and is really interested in the idea of implementing X language interpreters in pypy, where X can be any known programming language. Do we have a knowledge of who is developing or interested in which X-to-pypy interpreter so there's no competition nor duplication of work? Personally I have some interests in a few languages that I know, such as R and pascal. Cheers maurice

7 8