Hi Ryan,
On 5 November 2014 19:07, Ryan Gonzalez wrote:
> That's the weird issue: it's already fixed! A version compiled from tip
> works, but the prebuilt 2.4 binaries are the ones that crash.
I ran it up to the crash, which occurs somewhere in the compiler. My
guess is that 27aa8184f00f fixed
Thanks! I'll have to wait for the next release so Travis can use a correct PyPy
(right now, I had to hack stuff to download a custom PyPy nightly for running
the tests).
Armin Rigo wrote:
>Hi Ryan,
>
>On 5 November 2014 19:07, Ryan Gonzalez wrote:
>> That's the weird issue: it's already fixed!
Is there any easy way to profile code under Pypy? When I try to run using
the usual pypy -m cProfile foo.py, I get nonsensical results, like negative
time or billions of seconds.
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailma
In some cases, Pypy performs worse than CPython when running Krakatau, and
it has gotten a lot worse from 2.3 to 2.5
My benchmark is https://github.com/Storyyeller/Krakatau/tree/pypy_benchmark
(for future reference, commit d889c7f44723e6d66a3630681f0385f173317dc9)
You can run it with pypy Krakata
So I'm trying to integrate libuv into Pixie, and all was going well, but
I'm hitting a bit of a snag when it comes to opening files. I've tried
several things, but my latest iteration is this:
https://github.com/pixie-lang/pixie/blob/async-io-file/pixie/vm/libs/uv_file.py#L104
When running this i
Hi Robert.
I've been looking at krakatau performance for a while, it's almost
exclusively warmup time. We are going to address it, I hope rather
sooner than later :-)
On Mon, Nov 10, 2014 at 12:41 AM, Robert Grosse wrote:
> In some cases, Pypy performs worse than CPython when running Krakatau, a
you should really use "with" sentence with scoped buffers, otherwise
you're leaking memory. Same goes for lltype.malloc(flavor='raw'), you
need to lltype.free it.
I don't think that causes crashes though, I would need to take a
deeper look into the incantation too. How do I get a crash? Is there a
Hi Timothy,
From the docs, the signature of uv_fs_read() is this
(http://docs.libuv.org/en/latest/fs.html#c.uv_fs_read):
int uv_fs_read(uv_loop_t* loop, uv_fs_t* req, uv_file file, const
uv_buf_t bufs[], unsigned int nbufs, int64_t offset, uv_fs_cb cb)
This seems to differ from what you're repor
