Mailman 3 October 2003 - pypy-dev

Improved Unit Test Framework
by Laura Creighton 18 Oct '03

18 Oct '03

I couldn't remember what Peter had told me about his testing framework, so I asked him. Now he is curious as to what we want to do differently. Laura ------- Forwarded Message Return-Path: peter(a)engcorp.com To: Laura Creighton <lac(a)strakt.com> Subject: Re: Unit testing References: <200310171413.h9HEDlLH014913(a)ratthing-b246.strakt.com> Laura Creighton wrote: > > DO I remember it correctly that you have extensively hacked up the > unittest module to build a nicer framework? and if so, is what you > did freely available? PyPy wants a nicer framework ... Actually, we carefully avoided touching "unittest.py" at all, as we were new to this game. Instead we've added a wrapper ('ktest') around it which provides a few features we find useful (but only under Win/DOS). - - type "unit xxxx" to run unit tests for module xxxx, expecting to find them at ./unit/xxxx_unit.py - - "unit -a" runs all tests in all ./unit subdirectories, recursively - - "unit -r" randomizes the order of the individual TestCases (but not yet the individual test methods) to help catch test-order dependencies - - all output from tests go to log files as xxxx_unit.log for later inspection - - no graphical abilities whatsoever; no pretty green/red bar (I regret the latter part) - - automatic inclusion of .pth files found in ./unit subfolders, and automatic inclusion of parent folder in the sys.path (all tests run with the ./unit folder as current directory) - - automatically use Python 2.0 or 2.2 based on flag file in ./unit folder as we have not yet migrated entirely from 2.0 - - probably a few other bits I seriously doubt that what we have would be of much use to anyone as they would likely have to adopt a completely different approach to testing than they currently use. The area where we have actually excelled, instead of where we've stuck to the entirely non-fancy console/DOS interface with limited features, is in our auxiliary test frameworks. One of them, PyJTF, has just been put up on Sourceforge (http://pyjtf.sourceforge.net/). It allows test-driven development of Javascript code for the IE browser (again, limited to Win32 :-( ) using Python and COM and Twisted to great effect. The other, as yet unreleased, incorporates a Python-based HC12 CPU simulator to allow test-driven development of embedded system code in C. Tests in Python, code in C, fairly simple interface and amazing performance (one set of 98 tests takes only 4 seconds to run). As this one matures, I hope to release it as well. If the kunit features are remotely interesting, I can forward the code and its own tests. Feel free to post any part or all of this to the PyPy mailing list, or elsewhere, as you see fit. :-) - -Peter Hansen ------- End of Forwarded Message

3 2

Maybe Ian Bicking wants our test framework.
by Laura Creighton 17 Oct '03

17 Oct '03

http://blog.colorstudy.com/ianb/weblog/2003/10/10.html#P11

4 3

IRC log: is list.append a RPython op?
by Seo Sanghyeon 16 Oct '03

16 Oct '03

I asked Armin whether list.append is a RPython op, and had a brief chat on the topic. Armin expressed his opinion, and agreed to post IRC log to this list. Any comment?

1 1

Re: [pypy-dev] PyPy on FPGA?
by Thanos Vassilakis 16 Oct '03

16 Oct '03

I have a Python on FPGA project going that is partly financed by a FPGA chip manufacture. It is early days and would be very interested in any other such projects. thanos ----------------------------------------- This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer.

1 0

PyPy on FPGA?
by Christian Tismer 16 Oct '03

16 Oct '03

Amund Tveit wrote: ... > btw, regarding the PyPy project. Are there anyone of you working on a > FPGA-port of the PyPy core? It would certainly be interesting to port the > core to a VHDLish language and make it run on low-power FPGA-chips, in > particular for potential mobile device adaption of Python. That comment > could potentially be something to put in your EU funding proposal? :-) We were of course considering PyPy for embedded systems, different hardware platforms, and we certainly will implement PyPy for different environments. See section B.6.7.11 of the proposal: "Embed in Specialized Hardware", page 69 of http://www.codespeak.net/svn/pypy/trunk/doc/funding/proposal/part_b.pdf I don't know if this will involve FPGA in the first place. But this is anyway just the beginning. By the end of this 2 year project, PyPy is either dead, or everybody will rush at us and have us port the software to whatsoever. cheers - 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 mobile +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/

1 0

LL3 abstract.
by Jonathan David Riehl 16 Oct '03

16 Oct '03

Hi all, I've attatched my first draft of a presentation abstract that I'll be submitting to LL3. This proposal is due this Friday (the 17th), so if you are interested in what I'm going to say in Boston, you might want to check this out right now and get any feedback to me ASAP. I'd especially like feedback from people that have already given presentations on PyPy or are doing development on the translator (the whole sprint was a blur to me - I'm going to need help remembering what I was witness to!) In case you don't remember what LL3 is, Dinu forwarded a call for presentations late last month, and you can look at the website at http://ll3.ai.mit.edu/. If anyone else in pypy-dev is attending, I should be there whether my presentation is accepted or not, and we should discuss hanging out. Thanks! -Jon

3 2

recent lisp support / cross-language
by holger krekel 14 Oct '03

14 Oct '03

hello pypy, i think it's nice that we start to have clisp support. but there are no unit-tests and 'translator/gencl.py' adds more code to keep in sync with our model. So without tests i wouldn't like this code to exist. I guess we need some boilerplate that allows starting lisp-programs from commandline with instructions which functions to call and parsing the results. the unittests could then do the same what they do for pyrex: checking that the function at least computes correctly. btw, I can imagine a cross-language sprint aimed at producing multiple backends (C, Pyrex, CLISP, whatever) or multiple frontends (prolog...). That would certainly help to get the wider language research/developer community get interested. A dumb side-question: can clisp-source be annotated with types or is it just another VHLL :-) ? cheers, holger P.S.: if Seo wants to maintain the lisp area for the time beeing i am for giving him commit privs.

4 5

Re: [pypy-dev] "Unwrap" Concidered Harmful
by Rocco Moretti 14 Oct '03

14 Oct '03

Armin Rigo wrote: >On Sat, Sep 13, 2003 at 02:24:51PM -0400, Rocco Moretti wrote: > > >>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". >> >> > >Right. However there are a few other cases in which the interpreter may be >interested in "probing" information about a wrapped object. Here are two I can >think of: > > * getting an integer. We need this at a few points, e.g. to know the exact >length of a tuple (which is needed to interpret something like "f(*args)"). > > * getting a (short) string. Again there is an example in arguments decoding, >to interpret "f(**kw)" we need to manipulate the keywords. > >It may be possible to remove all these uses of unwrap (e.g. the length of a >tuple can be obtained by iterating over it and counting), but I'd say that it >would only make matters more obscure. Instead, just as we have "is_true()" we >could do with a few other methods to get the integer value of an object, or >its string value. > I'd argue that the interpreter level length of an argument tuple should be determined by a specific function, and not by unwrapping the application level length. We may want to implement some object space where the application level length is different than the length at which the intepreter should view it. For example, an application level length may be "between 4 and 7, but most likely 5", but for purpouses of interpreter level execution we want it to be treated as 7. -Rocco

2 1

early sprint planning - amsterdam
by holger krekel 14 Oct '03

14 Oct '03

hello pypy-devers, hello current pypy-sprint subscribers, just wanted to gather some more feedback for the next (fifth!) PyPy-sprint. It is currently planned to take place at "Vrije Universiteit in Amsterdam", 14th-21th Dec 2003. thanks to Etienne Posthumus. There was already some agreement in Berlin about this proposal, and Armin, Michael and me told me afterwars it's likely they will come. I guess the main goal will be to complete C code generation (probably still using Pyrex as an intermediate layer). It would also be nice to work on some fun frontends to PyPy like one with pygame that visualizes interactions between interpreter and objectspace. But we will certainly need to discuss which main goals the next sprint should have. The sprint should be a rather pure coding sprint, no funding strings attached :-) short after this mail i will unsubscribe everybody (except armin, michael and me) from the pypy-sprint list. So please SUBSCRIBE yourself ASAP if you are *interested* to come to Amsterdam: http://codespeak.net/mailman/listinfo/pypy-sprint A real announcement will supposedly go soon to pypy-dev, c.l.py and python-dev. We want to fix especially the date early so that people can book cheap flights. If you want to come but really have no way at all of financing it please contact me. We will try to help but can't promise anything. cheers, holger

2 1

Re: [pypy-dev] fixeol
by Rocco Moretti 13 Oct '03

13 Oct '03

Sorry for brining up old news, but my Netscape e-mail wasn't letting me log in for more than about 2 seconds ... so I changed free email providers. I've had a backlog of messages to work through ... >>I'm still a bit worried that if fixeol actually changes content, as would be >>the case if it is run by someone on another platform than the one used to >>create it, then svn will record it as completely changed (ideal source for >>conflicts). The only solution I could imagine would be to make sure that >>people specify files to be text when they first add it to the repository. >>Somehow the default "files-are-binary" of SVN creates different, new kind of >>problems than the default "files-are-text" of CVS. Maybe a no-default >>you-must-specify-it-explicitely wouldn't have been such a bad idea. >> >> > >we could enforce this on a pre-commit hook and maybe other things >like e.g. that REST-files compile without errors. The latter would make >a checkin of documents slower but i think it's worth it IMO. > One option would be to sell our friends at subversion on the concept of repository level tagging. I would imagine that it is common to want *all* *.py, *.txt, *.c and *.h files to be handled as eol-native files throughout the repository. One way repository level tagging could work is that on the svn server is a config file that applies globally to all files and directories in the repository, setting specific property tags upon file/directory addition. For example: ['*.txt', '*.py']: svn:eol-style = native would cause any text or python files to have the svn:eol-style property be set to native. Though generally applied, it could apply to all tags and file designations. PyPy svn admins: Does this seem like a reasonable feature to request? Or is it already availible? -Rocco

2 1