so that it doesn't automatically bounce mail from non-subscribers
but instead holds them? Now that we are on python.org we won't
drown in spam as python.org is most excellent at catching it before
it reaches the mailing list. If you make me a list admin, I promise
to do all the work in approving
Hi Gertjan,
With PyPy at the horizon, I am not so sure anymore. For one I'm not sure if
PyPy will ever be able to use the C module, or use it efficiently
it's only the crossing into and out of a C extension module through cpyext
that is less than optimal. If that crossing does not happen often
Yes, I should have looped Noah in sooner.
I have all the keys / passwords. Right now we need:
1. codespeed
2. benchmark runners
I've installed a very basic system with Django, apache, mod_wsgi
On Tue, Aug 30, 2011 at 8:35 PM, Alex Gaynor wrote:
> I've gotten Noah Kantrowitz on here, he's doing
I've gotten Noah Kantrowitz on here, he's doing some other infrastructure
stuff for the PSF, and would like to include speed.python.org in the proper
organization of the machines, rather than ad-hoc "everyone installs what
they think it needs" :)
Alex
On Tue, Aug 30, 2011 at 8:28 PM, Jesse Noller
(Re-sending intentionally - I wasn't subbed to pypy-dev and got rejected)
On Tue, Aug 30, 2011 at 8:22 PM, Jesse Noller wrote:
> Here's a summary (nicely put together by Nick Coghlan):
>
> - OSU/OSL have set up the machine itself (details in the July list archives)
> - I am the machine admin (I h
2011/8/30 Aaron DeVore
> Possible solution [who uses it for CPython]:
> 1) pypy arbitrary, pypy2 for Python 2, pypy3 for Python 3 [PEP 394, Gentoo]
> 2) pypy for Python 2, pypy3 for Python 3, no pypy2 [Debian family]
> 3) pypy for Python 2, pypy2 for Python 2, pypy3 for Python 3 [Red Hat
> family
Dear all,
Following today's blog post [1] about wrapping C++ libraries, I would like
to take the opportunity to get some opinions from the PyPy community on a
related topic. I hope this mailing list is the appropriate place for this
sort of discussion.
My name is Gertjan van Zwieten and I have be
>From what I can tell, PyPy doesn't have a policy on how package
maintainers should differentiate between Python 2 and Python 3
executables. I brought up adding "pypy2" on #pypy in March, but the
conversation quickly died.
CPython ran into the no-policy problem when Arch Linux decided to
switch /u
On 8/21/2011 2:32 PM, Carl Friedrich Bolz wrote:
Solving the problem of persisting source code is *seriously* hard, and
I agree with Armin, I'm not going to invest any time in it.
One interesting side note: The implementors of v8 decided that the best
and most compact representation of sourc
