llvm dev - Feb 2006 - [LLVMdev] PyPy sprint announcement: PyCon 2006, Texas, Feb 27st - March 2nd

Hello LLVM-ers,

The next sprint of PyPy will be held in Dallas, Texas, at the PyCon
conference.  Most of you know about the LLVM back-end of PyPy.  So far,
we use mostly the static compilation features of LLVM, but as we are
progressing on the JIT side we are considering starting sometime soon
working on just-in-time machine code generation backends.  Clearly, LLVM
might prove to be a good target for that.

The full announcement follows.  Although LLVM-JIT is not explicitly
mentioned, as it is still an experimental idea for us, feel free to show
up.  Not all PyPy core developers will be present, so we will focus on
whatever the people present are interested in.  There will be people
knowledgeable in both PyPy and LLVM around, ready to help newcomers to
work on this topic.

                             - * - * -

Post-PyCon PyPy Sprint: February 27th - March 2nd 2006 
===========================================================
The next PyPy sprint is scheduled to take place right after 
PyCon 2006 in Dallas, Texas, USA. 

We hope to see lots of newcomers at this sprint, so we'll give
friendly introductions.  Note that during the Pycon conference 
we are giving PyPy talks which serve well as preparation.  

Goals and topics of the sprint 
------------------------------

While attendees of the sprint are of course welcome to work on what
they wish, we offer these ideas:

  - Work on an 'rctypes' module aiming at letting us use a ctypes
    implementation of an extension module from the compiled pypy-c.

  - Writing ctypes implementations of modules to be used by the above
    tool. 

  - Experimenting with different garbage collection strategies.

  - Implementing Python 2.5 features in PyPy

  - Implementation of constraints solvers and integration of dataflow
    variables to PyPy.

  - Implement new features and improve the 'py' lib and py.test 
    which are heavily used by PyPy (doctests/test selection/...).

  - Generally experiment with PyPy -- for example, play with
    transparent distribution of objects or coroutines and stackless
    features at application level.

  - Have fun!

Location
--------

The sprint will be held wherever the PyCon sprints end up being held,
which is to say somewhere within the Dallas/Addison Marriott Quorum
hotel.

For more information see the PyCon 06 sprint pages:

  - http://us.pycon.org/TX2006/Sprinting
  - http://wiki.python.org/moin/PyCon2006/Sprints

Exact times 
-----------

The PyPy sprint will from from Monday February 27th until Thursday
March 2nd 2006. Hours will be from 10:00 until people have had enough.

Registration, etc.
------------------ 

If you know before the conference that you definitely want to attend
our sprint, please subscribe to the `PyPy sprint mailing list`_,
introduce yourself and post a note that you want to come.  Feel free
to ask any questions or make suggestions there!

There is a separate `PyCon 06 people`_ page tracking who is already
planning to come.  If you have commit rights on codespeak then you can
modify yourself a checkout of

  http://codespeak.net/svn/pypy/extradoc/sprintinfo/pycon06/people.txt

.. _`PyPy sprint mailing list`:
http://codespeak.net/mailman/listinfo/pypy-sprint
.. _`PyCon 06 people`:
http://codespeak.net/pypy/extradoc/sprintinfo/pycon06/people.txt

Hi Armin,
> The next sprint of PyPy will be held in Dallas, Texas, at the PyCon
> conference.  Most of you know about the LLVM back-end of PyPy.  So  
> far,
> we use mostly the static compilation features of LLVM,
How are you using the static compilation features?  Are you able to  
do this via API calls or generating code that will be processed by  
tools?

Thanks,

Marcel

Hi Marcel,

On Fri, 10 Feb 2006, Marcel Weiher wrote:
> How are you using the static compilation features?  Are you able to do this
> via API calls or generating code that will be processed by tools?
For static compilation, currently pypy's genllvm emits ll code and the cfe 
is also used for external system calls, where the c code is shared (or 
borrowed) from pypy's genc.  There are some half baked ideas wrt to using 
the api instead of emitting ll code.  Also there is work going on in 
rctypes (see Armin's original mail) which may eliminate the need for the 
front end compiler.

Cheers,
Richard