Mailman 3 April 2009 - pypy-dev

PyPy 1.1 final released!
by Samuele Pedroni 28 Apr '09

28 Apr '09

========================================== PyPy 1.1: Compatibility & Consolidation ========================================== Welcome to the PyPy 1.1 release - the first release after the end of EU funding. This release focuses on making PyPy's Python interpreter more compatible with CPython (currently CPython 2.5) and on making the interpreter more stable and bug-free. PyPy's Getting Started lives at: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html Highlights of This Release ========================== - More of CPython's standard library extension modules are supported, among them ctypes, sqlite3, csv, and many more. Most of these extension modules are fully supported under Windows as well. http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html http://morepypy.blogspot.com/2008/06/pypy-improvements.html - Through a large number of tweaks, performance has been improved by 10%-50% since the 1.0 release. The Python interpreter is now between 0.8-2x (and in some corner case 3-4x) slower than CPython. A large part of these speed-ups come from our new generational garbage collectors. http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html - Our Python interpreter now supports distutils as well as easy_install for pure-Python modules. - We have tested PyPy with a number of third-party libraries. PyPy can run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow, Pinax: http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.ht… http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html - A buildbot was set up to run the various tests that PyPy is using nightly on Windows and Linux machines: http://codespeak.net:8099/ - Sandboxing support: It is possible to translate the Python interpreter in a special way so that the result is fully sandboxed. http://codespeak.net/pypy/dist/pypy/doc/sandbox.html http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox Other Changes ============= - The ``clr`` module was greatly improved. This module is used to interface with .NET libraries when translating the Python interpreter to the CLI. http://codespeak.net/pypy/dist/pypy/doc/clr-module.html http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html http://morepypy.blogspot.com/2008/01/improve-net-integration.html - Stackless improvements: PyPy's ``stackless`` module is now more complete. We added channel preferences which change details of the scheduling semantics. In addition, the pickling of tasklets has been improved to work in more cases. - Classic classes are enabled by default now. In addition, they have been greatly optimized and debugged: http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html - PyPy's Python interpreter can be translated to Java bytecode now to produce a pypy-jvm. At the moment there is no integration with Java libraries yet, so this is not really useful. - We added cross-compilation machinery to our translation toolchain to make it possible to cross-compile our Python interpreter to Nokia's Maemo platform: http://codespeak.net/pypy/dist/pypy/doc/maemo.html - Some effort was spent to make the Python interpreter more memory-efficient. This includes the implementation of a mark-compact GC which uses less memory than other GCs during collection. Additionally there were various optimizations that make Python objects smaller, e.g. class instances are often only 50% of the size of CPython. http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html - The support for the trace hook in the Python interpreter was improved to be able to trace the execution of builtin functions and methods. With this, we implemented the ``_lsprof`` module, which is the core of the ``cProfile`` module. - A number of rarely used features of PyPy were removed since the previous release because they were unmaintained and/or buggy. Those are: The LLVM and the JS backends, the aspect-oriented programming features, the logic object space, the extension compiler and the first incarnation of the JIT generator. The new JIT generator is in active development, but not included in the release. http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html http://morepypy.blogspot.com/2009/03/good-news-everyone.html http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html What is PyPy? ============= Technically, PyPy is both a Python interpreter implementation and an advanced compiler, or more precisely a framework for implementing dynamic languages and generating virtual machines for them. The framework allows for alternative frontends and for alternative backends, currently C, Java and .NET. For our main target "C", we can "mix in" different garbage collectors and threading models, including micro-threads aka "Stackless". The inherent complexity that arises from this ambitious approach is mostly kept away from the Python interpreter implementation, our main frontend. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far as it has without the coding, feedback and general support from numerous people. Have fun, the PyPy release team, [in alphabetical order] Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo, Carl Friedrich Bolz, Christian Tismer, Holger Krekel, Maciek Fijalkowski, Samuele Pedroni and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html

3 4

unladen/swallow, pyjs+pyv8, pyjs+python-spidermonkey: accessing c python modules from optimised python compilers
by Luke Kenneth Casson Leighton 24 Apr '09

24 Apr '09

http://groups.google.com/group/unladen-swallow/browse_thread/thread/6f6bfac… i thought you might like to know that discussions which i believe may be of benefit to pypy are underway. you will have heard of unladen/swallow, an effort to replace the stack machine of http://python.org with a LLVM JIT compiler. you may also have heard of the experiments to combine http://pyjs.org with http://code.google.com/p/pyv8 and also of the experiment to combine http://pyjs.org with python-spidermonkey. the "fly in the ointment" is that for "full" optimisation to occur, it is necessary to "break out" from the prison that intobject.c, longobject.c etc. make. once this prison is opened, by turning the hard-coded python types into a more flexible and dynamically-overridable architecture, you (the pypy developers) will be free to write modules that will allow interoperability between [admittedly recompiled] c-based python modules, with no effort [other than recompilation] required on the part of the users. if you believe that this is something that would be of benefit to pypy, you should consider participating in the discussion and design of the dynamic architecture which will allow _all_ the "python optimisers" to be free of the restrictions imposed by the "original" c-based python implementation. the google engineers of unladen/swallow have absolutely no qualms about making, and maintaining, a fork of the "original" http://python.org and so it will be a simple matter to tell pypy users "yes, go get the version of python unladen/swallow, recompile your c-based module and then pypy will be able to talk to your c-based module, unmodified." l.

3 9

How hard would it be to generate PyPy for the Dalvik Virtual Machine?
by Laura Creighton 23 Apr '09

23 Apr '09

This showed up on another list I read. ------- Forwarded Message From: Roland Orre <roland.orre(a)gmail.com> Date: Wed, 22 Apr 2009 10:05:15 +0200 To: cafe(a)ffii.org Subject: Re: [Cafe] android g1 X-BeenThere: cafe(a)ffii.org I also have a Google G1 now with a developers account. It is cool to have a telephone which I can ssh from and where I can set up an ftp server. I intended to start porting some applications like some HP calculator (I have HP42S and HP48GX), and probably openssl, openssh and a vpn client. One tricky aspect with the Android system is that it has it's own noncompatible VM which is the Dalvik virtual machine, which shold be more memory efficient than the standard JVM. This JVM is written by Dan Bornstein and released with Apache license v2. The tricky thing is that this gets around Sun's grip on the JVM but also implies that platform independent code is no longer platform independent... JVM bytecode can be converted to DalvikVM code though, but there is no just in time compiler for JVM to DalvikVM yet though, so e.g. Jython is not really nice implemented on it yet, although there is jythonroid http://code.google.com/p/jythonroid/ The current ARM chip is claimed to have hardware support for JVM though, even though Android should not be platform dependent of course. Any opinion about the JVM - DalvikVM issue? /Roland On Wed, Apr 22, 2009 at 08:39, Ivan F. Villanueva B. <ivan(a)ffii.org> wrote: > [moved to cafe@] > > El Tue, Apr 21, 2009 11:28:36PM +0200, Alberto Barrionuevo escribió: >> On Tuesday 21 April 2009 14:05:42 Ivan F. Villanueva B. wrote: >> > At the moment Google has his own modified implementation of a JRE for his >> > operating system Android. Maybe interesting to check if they call it Java >> > and related issues. >> > >> > Anyway, It seems the mobile Market will boom soon, with all the Internet >> > applications, and Java will be very important again. I have an Android G1 >> > mobile phone myself, and it is like a device coming from the future. >> > Applications are programed in the Google JRE. I'm just testing it, and you >> > have: - no need for backups, everything is synchronized with your Google >> > account (which is of course not nice for privacy issues, but it works just >> > without doing anything) - ssh, irc, jabber, email, facebook, twitter, rss, >> > etc. Even with notifications. - google maps, youtube, music, Internet >> > radio, etc. >> > - translations from among others google >> > - webpages like, wikipedia, etc. >> > >> > No Voice over IP though, but I there is a hack to get root access on the >> > phone. >> >> And you can install Debian on it. We are testing this in OPENTIA right now... > > Please share the results > > -- > Iván F. Villanueva B. > > _______________________________________________ > Cafe mailing list > Cafe(a)ffii.org > https://lists.ffii.org/mailman/listinfo/cafe > _______________________________________________ Cafe mailing list Cafe(a)ffii.org https://lists.ffii.org/mailman/listinfo/cafe ------- End of Forwarded Message

5 7

re-boxing of CPython types.
by Luke Kenneth Casson Leighton 23 Apr '09

23 Apr '09

>> if you can add in "assembly-level-like" infusion, where javascript >> snippets can be substituted directly into the resultant javascript >> output, then you are on to a winner. the pyjamas compiler uses this >> technique to directly interface with the DOM model of the browser. > > I'm not going to comment on the merits of this (I actually think javascript > is a better language to write javascript code in), but if this is exactly > what pyjamas is doing, why would we want to do it on pypy? the benefits of having a generic "assembler" mechanism in a compiler should be already clear, just as the "asm { ... }" statement shows in gcc. so i can safely assume that that's not what you're asking. which leaves the implication that it should be pypy that provides direct access to web browsers' DOM model, which most definitely is not the case. pyjamas comprises three parts: 1) a stand-alone python-to-javascript compiler [that has an "assembler" directive called JS()] 2) an independent library called DOM.py which mostly comprises JS() assembler directives. 3) an independent ui "widget" library which uses DOM.py to provide a widget set that is startlingly similar to python-qt4 and python-gtk2. the js tutorial which has been removed (so i cannot look at it) i remember it used mochikit, somehow, to do the same thing as DOM.py that implies that somehow there was the means to call javascript functions "as if from python". which, i can tell you from experience, makes a bit of a mess of the compiler as well as making a meal out of the interface between python and javascript. >> however i believe that it would be relatively easy to go from this >> "good enough" / "relaxed" mode to "full python compliance" - the >> "strict" mode as i call it. > > > Exactly how? How do you map real python to javascript without killing the > performance gain any js interpreter is going to give you? ahh, i'm _so_ glad you asked :) one way to explain it is: i'm looking to replace cpython's PyType_IntObject, in intobject.h: typedef struct { PyObject_HEAD long ob_ival; } PyIntObject; with this: typedef struct { PyObject_HEAD JSObject *ob_ival; } PyIntObject; and in intobject.c, replace this: static PyObject * int_div(PyIntObject *x, PyIntObject *y) { long xi, yi; long d, m; CONVERT_TO_LONG(x, xi); CONVERT_TO_LONG(y, yi); switch (i_divmod(xi, yi, &d, &m)) { case DIVMOD_OK: return PyInt_FromLong(d); case DIVMOD_OVERFLOW: return PyLong_Type.tp_as_number->nb_divide((PyObject *)x, (PyObject *)y); default: return NULL; } } with this: static PyObject * int_div(PyIntObject *x, PyIntObject *y) { JSObject *d; /* the js object associated with x will have a javascript function __div__. get it, and call it. */ JSFunction *js_div_fn = get_js_function(x->ob_ival, "__div__"); d = call_js_function(js_div_fn, x->ob_ival, y->ob_ival); return PyInt_FromJSObject(d); } the function "int.__div__" will start off as a python class that will be compiled to javascript. in this way, i expect to gain the benefit of the aggressive JIT javascript JIT compilation of e.g. Google V8, _and_ keep interoperability with http://python.org's c-based modules (after a recompile, of course). i haven't quite worked out how the "coerce" function fits in to all this. and also someone kindly warned me about garbage collection, which i don't have a handle on, yet. in this way, all code that is actually python will end up being compiled to aggressively-JIT-optimised assembler. there will be no "checking" of CPython types. there will be no "conversion" to/from CPython types, because all CPython types will become is "boxes" around Javascript Objects. this is the approach that the unladen/swallow team will have to take, in their "Phase 2". they are _going_ to do this. so, i figured i might as well get a handle on it, in advance, to see if it's possible, and try to "get on the bandwagon" so to speak. also, i figured that there must be a way that you could also leverage this. there _has_ to be. in a generic way: typedef struct { PyObject_HEAD void *ob_ival; /* for DSO-loadable modules to override with something */ } PyIntObject; l.

4 5

pypy appears to have entirely removed all mention of javascript back-end support from web site
by Luke Kenneth Casson Leighton 22 Apr '09

22 Apr '09

hi, i was just checking http://wiki.python.org/moin/WebBrowserProgramming specifically the python-to-javascript compiler section and was surprised to find that the link to the "JS Using" tutorial no longer works. on further investigation, it would appear that pypy have completely removed all mention of javascript as a back-end from the pypy documentation. all tutorials are gone. the demo "bnb" fails. as the lead developer of pyjamas, the python-to-javascript compiler, this leaves me slightly ... concerned, as it implies that pyjamas is now the sole and exclusive free software python compiler which can be used seriously by developers to create web applications. what seems to be the problem? is there a technical / language-translation issue that cannot be overcome? someone said (on the LLVM unladen/swallow list) that adding advanced features like metaclass support would be hard - this was proven to be incorrect, by writing an implementation of "type()" for pyjamas in under 24 hours and about 100 lines of javascript. pyjamas is tiny by comparison (it uses the existing AST / Compiler module / translator) to pypy, so there is very little actually going on, which makes it that much easier to follow its example. the main pyjs compiler is what... 1400 lines of python, and pyjslib.py which contains the majority of the builtins (dict, list, tuple, str) is a further 1400 lines. so - what seems to be the problem? or am i mistaken and the javascript back-end support is just in the process of being rewritten? l.

5 11

PyPy 1.1 beta release
by Samuele Pedroni 22 Apr '09

22 Apr '09

Today we are releasing a beta of the upcoming PyPy 1.1 release. There are some Windows and OS X issues left that we would like to address between now and the final release but apart from this things should be working. We would appreciate feedback. The PyPy development team. ========================================== PyPy 1.1: Compatibility & Consolidation ========================================== Welcome to the PyPy 1.1 release - the first release after the end of EU funding. This release focuses on making PyPy's Python interpreter more compatible with CPython (currently CPython 2.5) and on making the interpreter more stable and bug-free. PyPy's Getting Started lives at: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html Highlights of This Release ========================== - More of CPython's standard library extension modules are supported, among them ctypes, sqlite3, csv, and many more. Most of these modules extension are fully supported under Windows as well. http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html http://morepypy.blogspot.com/2008/06/pypy-improvements.html - Through a large number of tweaks, performance has been improved by 10%-50% since the 1.0 release. The Python interpreter is now between 0.8-2x (and in some corner case 3-4x) of the speed of CPython. A large part of these speed-ups come from our new generational garbage collectors. http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html - Our Python interpreter now supports distutils as well as easy_install for pure-Python modules. - We have tested PyPy with a number of third-party libraries. PyPy can run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow, Pinax: http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.ht… http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html - A buildbot was set up to run the various tests that PyPy is using nightly on Windows and Linux machines: http://codespeak.net:8099/ - Sandboxing support: It is possible to translate the Python interpreter in a special way so that the result is fully sandboxed. http://codespeak.net/pypy/dist/pypy/doc/sandbox.html http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox Other Changes ============= - The ``clr`` module was greatly improved. This module is used to interface with .NET libraries when translating the Python interpreter to the CLI. http://codespeak.net/pypy/dist/pypy/doc/clr-module.html http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html http://morepypy.blogspot.com/2008/01/improve-net-integration.html - Stackless improvements: PyPy's ``stackless`` module is now more complete. We added channel preferences which change details of the scheduling semantics. In addition, the pickling of tasklets has been improved to work in more cases. - Classic classes are enabled by default now. In addition, they have been greatly optimized and debugged: http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html - PyPy's Python interpreter can be translated to Java bytecode now to produce a pypy-jvm. At the moment there is no integration with Java libraries yet, so this is not really useful. - We added cross-compilation machinery to our translation toolchain to make it possible to cross-compile our Python interpreter to Nokia's Maemo platform: http://codespeak.net/pypy/dist/pypy/doc/maemo.html - Some effort was spent to make the Python interpreter more memory-efficient. This includes the implementation of a mark-compact GC which uses less memory than other GCs during collection. Additionally there were various optimizations that make Python objects smaller, e.g. class instances are often only 50% of the size of CPython. http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html - The support for the trace hook in the Python interpreter was improved to be able to trace the execution of builtin functions and methods. With this, we implemented the ``_lsprof`` module, which is the core of the ``cProfile`` module. - A number of rarely used features of PyPy were removed since the previous release because they were unmaintained and/or buggy. Those are: The LLVM and the JS backends, the aspect-oriented programming features, the logic object space, the extension compiler and the first incarnation of the JIT generator. The new JIT generator is in active development, but not included in the release. http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html http://morepypy.blogspot.com/2009/03/good-news-everyone.html http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html What is PyPy? ============= Technically, PyPy is both a Python interpreter implementation and an advanced compiler, or more precisely a framework for implementing dynamic languages and generating virtual machines for them. The framework allows for alternative frontends and for alternative backends, currently C, Java and .NET. For our main target "C", we can can "mix in" different garbage collectors and threading models, including micro-threads aka "Stackless". The inherent complexity that arises from this ambitious approach is mostly kept away from the Python interpreter implementation, our main frontend. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far as it has without the coding, feedback and general support from numerous people. Have fun, the PyPy release team, [in alphabetical order] Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo, Carl Friedrich Bolz, Christian Tismer, Holger Krekel, Maciek Fijalkowski, Samuele Pedroni and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html

10 10

Re: [pypy-dev] PyPy 1.1 beta release
by Laura Creighton 21 Apr '09

21 Apr '09

It is also hard for people to process fractional numbers when they are thinking about speed. '2 times the speed' feels a lot easier to understand than '2.1' times the speed. And once you get to numbers less than 1, things break down altogether. If you want to tell me that something is slower, I don't expect to hear it as 'some number less than 1' times the speed. I want a very hard break at the point 0, and for you then to go about telling me how many times slower than something that something else is. For most measurements, I would be happy if nobody mentioned the words 'speed', 'faster' and 'slower' at all. What I am _really_ interested, is a measurement of time. And I have a much easier time understanding time quantities, which I am used to dealing with, than speed quantites which rarely show up in life. So while I am always a bit hazy on what 'x times the speed' really means, when you change this to 'this program runs in half the time, one quarter of the time, twice the time, or even .8 of the time' I have a much easier time of it. I'm used to measuring time, and I expect it to be linear. I'm not used to measuring speed, and I keep worrying 'is this linear'? 'is this logarithmic?' 'is this exponential?'. It is only when I get to measure the actual times taken to do some sort of task, say a benchmark, that I get any real sense of whether a change seems to be a trivial small improvement, or a colossal major one. I wonder if others feel the same way. Laura

7 8

Re: [pypy-dev] PyPy 1.1 beta release
by Laura Creighton 21 Apr '09

21 Apr '09

In a message of Tue, 21 Apr 2009 17:34:17 +0200, Laura Creighton writes: <snip> >less than 1' times the speed. I want a very hard break at the point >0, and for you then to go about telling me how many times slower than >something that something else is. Aargh! I meant at the point 1, of course. Which may indicate that inside my head I would like positive numbers to mean 'faster' and negative numbers to mean 'slower' or some such nonsense. :) Laura

1 0

Created a release branch for 1.1
by Samuele Pedroni 19 Apr '09

19 Apr '09

Hi, here at the sprint we have created a release branch for 1.1: http://codespeak.net/svn/pypy/release/1.1.x/ we are working on producing a beta out of it today. The final 1.1 release will also be produced from this branch. If you fix relevant failures (buildbot current failures) please consider merging them on the branch but be mindful of possible regressions. We have setup a battery of buildbot runs for this branch too. We will check tomorrow if that worked. Samuele for the team

3 2

including jasmin.jar
by Niko Matsakis 17 Apr '09

17 Apr '09

Hello, I would like to include jasmin.jar into the main PyPy source tree. In this way, the only thing that a user would have to install to build and run PyPy-JVM is a recent JDK. Furthermore, it avoids the incompatibilities between different versions of Jasmin (such as the one installed by Debian). Looking at the license for Jasmin (reproduced below), it seems that this would require a notice such as the following to be added to PyPy's LICENSE file: > License for 'pypy/translator/jvm/src/jasmin.jar' > ================================================ > > The file 'pypy/translator/jvm/src/jasmin.jar' is copyright (c) > 1996-2004 Jon Meyer > and distributed with permission. The use of Jasmin by PyPy does not > imply > that PyPy is endorsed by Jon Meyer nor any of Jasmin's > contributors. Furthermore, > the following disclaimer applies to Jasmin: > > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > "AS IS" AND ANY EXPRESS OR IMPLIED > WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > MERCHANTABILITY AND FITNESS FOR A > PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > OWNER OR CONTRIBUTORS BE LIABLE FOR > ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF > USE, DATA, OR PROFITS; OR BUSINESS > INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER > IN CONTRACT, STRICT LIABILITY, OR > TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF > THE USE OF THIS SOFTWARE, EVEN IF > ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Are there any objections? regards, Niko --------------------------------------------------------------------------------------- Jasmin's license: /* * Copyright (c) 1996-2004, Jon Meyer * All rights reserved. * * Redistribution and use in source and binary forms, with or without modification, are permitted provided * that the following conditions are met: * * Redistributions of source code must retain the above copyright notice, this list of conditions * and the following disclaimer. * * Redistributions in binary form must reproduce the above copyright notice, this list of conditions * and the following disclaimer in the documentation and/or other materials provided with the * distribution. * * Neither the name of the Jon Meyer nor the names of its contributors may be used to * endorse or promote products derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * Jasmin was written by Jon Meyer, www.cybergrain.com * The Jasmin website is jasmin.sourceforge.net. */

4 6