http://packages.pypy.org/
Question about the web site -- does PyPy currently have anything similar to
> this page for Python 3?
> http://py3readiness.org/
>
> I think a page like this, showing which major libraries are compatible
> with PyPy, could really help drive adoption of PyPy. I know for
the success of this would be somewhat limited
based on user expectations and without PyPy it maybe to slow for many
applications.
On Thu, Mar 24, 2016 at 1:11 PM, John Camara <john.m.cam...@gmail.com>
wrote:
> Hi Armin,
>
> At a minimum tighter execution is required as well as
org> wrote:
> Hi John,
>
> On 24 March 2016 at 13:22, John Camara <john.m.cam...@gmail.com> wrote:
> > (...) Thus the need for a jffi library.
>
> When I hear "a jffi library" I'm thinking about a new library with a
> new API. I think what you would really li
story for numpy first, but
> then feel free to send those corporate interest people my way, we can
> maybe organize something. If you want us to do community service to
> push Python solutions in the area I have very little clue about
> however, I would like to politely decline.
>
> C
1:49, "Armin Rigo" <ar...@tunes.org> wrote:
> >
> > Hi John,
> >
> > On 23 March 2016 at 19:16, John Camara <john.m.cam...@gmail.com> wrote:
> > > I would like to suggest one more topic for the workshop. I see a big
> need
> > > for a
dedicated effort from someone I'm worried it would not go anywhere.
> It's kind of separated from the other goals of the summit
>
> On Wed, Mar 23, 2016 at 8:16 PM, John Camara <john.m.cam...@gmail.com>
> wrote:
> > Hi Nathaniel,
> >
> > I would like to suggest one m
Hi Nathaniel,
I would like to suggest one more topic for the workshop. I see a big need
for a library (jffi) similar to cffi but that provides a bridge to Java
instead of C code. The ability to seamlessly work with native Java
data/code would offer a huge improvement when python code needs to
I meant to mention them in my email as both of them are great options when
you don't mind sacrificing some compression for significant improvements in
compression and decompression speeds. These libraries are I/O bound when
saving to a hard drive unless you are using a very low powered processor.
Hi Fijal,
To recap and continue the discussion from irc.
We already discussed that the stack id are based on a counter which is good
but I also want to confirm that the ids have locality associated with the
code. That is similar areas of the code will have similar ids. Just to
make sure are
Hi Kevin,
More up to date information can be found on the FAQ page
http://doc.pypy.org/en/latest/faq.html#do-cpython-extension-modules-work-with-pypy
The best approach for PyPy is either use a pure Python module if possible
or use a cffi wrapped extension instead of an extension that uses the
On Thu, Feb 7, 2013 at 4:33 AM, Maciej Fijalkowski fij...@gmail.com wrote:
On Thu, Feb 7, 2013 at 6:41 AM, John Camara john.m.cam...@gmail.com
wrote:
Fijal,
In the past you have complained about it being hard to make money in open
source. One way to make it easier for you is grow
Fijal,
In the past you have complained about it being hard to make money in open
source. One way to make it easier for you is grow the popularity of PyPy.
So I would think you would at least have some interest in thinking of ways
to accomplish that.
I'm not trying to dictate what PyPy should do
Hi Armin,
It's even worse I'm asking you to support X and I don't even need it.
When I posted this thread it was getting rather long and unfortunately I
didn't really make all the points I wanted to make. At this point, and
even for some time now PyPy has a great foundation but it's use remains
On Mon, Feb 4, 2013 at 3:42 AM, Maciej Fijalkowski fij...@gmail.com wrote:
Seriously which ones? I think msgpack usage is absolutely legit. You
seem to have different opinions about the design of that software, but
you did not respond to my concerns even, not to mention the fact that
it
a responsibility to try to promote good
programming practices when we can.
[1] - https://github.com/msgpack/msgpack-python/blob/master/msgpack/fallback.py
[2] - http://blog.affien.com/archives/2013/01/29/msgpack-for-pypy/
John
On Sun, Feb 3, 2013 at 12:39 PM, John Camara john.m.cam
Let me rephrase it. Where did you look for such a warning and you did
not find it so you assumed it's ok?
Cheers,
fijal
Having a warning on https://bitbucket.org/pypy/jitviewer would be good.
On Sun, Feb 3, 2013 at 3:08 PM, John Camara john.m.cam...@gmail.com wrote:
What makes you
Also, looking at the msgpack - this code is maybe not ideal, but if
you're dealing with buffer-level protocols, you end up with code
looking like C a lot.
I do agree that this type a code will likely end up looking like C but it's
not necessary for all of it to look like c. Like there should
that is definitely a no (my screen is too small to have some noise
there, if for no other reason), it might have a warning in the
documentation though, if it's any useful. But honestly, I doubt such a
warning makes any sense. People who are capable of using jitviewer
already know better.
I
A couple of days ago I heard about the Parallella [1] project which is an
open hardware platform similar to the Raspberry Pi but with much higher
capabilities. It has a Zynq Z-7010 which has both a dual core ARM A9 (800
MHz) processor and a Artix-7 FPGA, a 16 core Epiphany multicore
accelerator,
19 matches
Mail list logo
