On Sun, Aug 30, 2020 at 02:46:02PM +0200, figdev--- via pypy-dev wrote:
Hello,
> This is more about OpenBSD than FreeBSD (I've talked to maintainers for
> each) but I'm curious about the requirements for building PyPy (especially
> 2.7 compatible) from source.
>
> For GNU/Linux I just download
[Summary: the recursion_and_inlining branch stops us tracing arbitrarily deep
in recursive functions. Comments welcome. If we think this is a good idea, we
have to decide if/how many levels deep we unroll before stopping tracing. My
current thinking is that 7 levels looks about right, though this
On Fri, Jul 11, 2014 at 10:57:24AM +0200, Armin Rigo wrote:
Hello Armin,
A comment about this, if I can make it here: for languages like Python,
there are two slightly different issues. The first is to use a constant
amount of memory to do unbounded calls. This is difficult because of the
On Wed, Jul 09, 2014 at 02:21:10PM -0500, Ryan Gonzalez wrote:
Well, if the stack still shows the function call, it isn't a bad idea.
Tail call optimisation has trade-offs: one can always construct cases where
it loses debugging information. If you'll permit the immodesty, one of my old
blog
I feel I might be going mad but I think there are a few web-page issues with
the 2.3.1 release. First the links to pypy-2.3.1-src.tar.bz2 and
pypy-2.3.1-src.zip point to release-2.3.1.tar.bz2 and release-2.3.1.zip
respectively in the get directory [1]. This confused the life out of me for a
while.
On Sun, Jun 22, 2014 at 01:27:02PM +0300, Matti Picus wrote:
Sorry, it's my fault, I didn't download/repackage/upload the source files
as in previous builds, it seemed redundant.
I see it was not, so I will try to fix.
Thanks Matti!
Laurie
___
On Thu, Nov 14, 2013 at 09:30:21AM +0100, Armin Rigo wrote:
Hi Armin,
Yes, but the question is whether we want both FloatIntegerListStrategy and
FloatListStrategy. The same arguments apply about the JIT not needing to
check the value of a float grabbed out of the list in the
On Tue, Nov 12, 2013 at 09:48:23AM +0100, Armin Rigo wrote:
Hi Armin,
Ok, but then it seems that the first problem we hit down this road, before
arriving at the __contains__ performance, is actually mixing ints and
floats in the same list. We need to do something to store such lists
On Fri, Nov 08, 2013 at 10:19:30AM +0100, Armin Rigo wrote:
I fear a bit that *all* cases are on the clearly nonsense side of things.
I don't particularly think there is code out there that would see any
speed-ups using these cases. As Amaury pointed out this introduces
delicate correctness
I've been fiddling with extending some of the strategies in PyPy. My first
port of call has been to provide fast paths in IntegerListStrategy.find,
which is the basis of x in l and l.index(x). Previously this was very
fast if you looked up an integer, but rather slow if you tried up looking
On Thu, Nov 07, 2013 at 11:42:47PM +0100, Amaury Forgeot d'Arc wrote:
Hum, [1,2,3].__contains__(1.9)?
Good point. This is something I clearly got wrong.
Is there a practical way to tell if a float could ever compare True to an
integer? I suppose I could convert it to an int, and do a
On Mon, Jun 24, 2013 at 06:05:39PM +0200, Armin Rigo wrote:
Shooting in the dark, but one possible reading of the man page shows
that when readdir() returns a non-null pointer, the value of errno
might be randomly modified.
Yes, this is true and bit me in a different context just over a year
On Tue, Jun 25, 2013 at 01:51:48PM +0200, Armin Rigo wrote:
According to these mails, the issue you've hit is different: what occurs to
errno if readdir() returns NULL. This is indeed strange but documented.
But what occurs to errno if readdir() does *not* return NULL? I thought
that errno
On Tue, Jun 25, 2013 at 11:34:03PM +0200, Armin Rigo wrote:
Sorry, I don't follow you. As far as I know the Linux man page is not
clear about what occurs to errno if readdir() doesn't return NULL...
Exactly :) My reading of it is that readdir returns: NULL and sets errno if
an error occurred;
On Sun, Jan 01, 2012 at 06:47:08PM +0200, Maciej Fijalkowski wrote:
I haven't noticed this particular output type before... but I'm not really
sure what most of the numbers actually mean! Does anyone have any
pointers?
Can you paste them somewhere? I'll explain
Thanks! Here's an example
On Sun, Jan 01, 2012 at 07:02:14PM +0200, Maciej Fijalkowski wrote:
Here's an example (hopefully a decent one!):
http://pastebin.com/51QpPD7C
so for example here, tracing has taken 0.8s out of 2.5 total (a lot) + 0.2s
for the backend. If you can post some example I can probably look at
Hi all,
As many of you know, over the past few months I've been creating an RPython
VM for the Converge language http://convergepl.org. This is now mostly
complete at a basic level - enough to run pretty much all of my Converge
programs at least on Linux and OpenBSD. [Major remaining issues are:
On Sat, Dec 31, 2011 at 12:29:40PM +0200, Maciej Fijalkowski wrote:
Hi Maciej,
Overall great work, but I have to point out one thing - if you want us to
look into benchmarks, you have to provide a precise benchmark and a precise
way to run it (few examples would be awesome), otherwise for
On Sat, Dec 31, 2011 at 05:45:35PM +0100, Armin Rigo wrote:
Hi Armin,
func main():
i := 0
while i 10:
i += 1
A quick update: on this program, with 100 times the number of iterations,
converge-opt3 runs in 2.6 seconds on my laptop, and converge-jit runs
in less than 0.7
Hello all,
I'm looking to port PyPy to OpenBSD (specifically amd64/x86_64, as I no
longer have any i386 machines; that might be the cause of some of my woes).
Getting much of PyPy to run on OpenBSD/amd64 is simple - partly basing things
on the FreeBSD parts - and compilation on my laptop merrily
20 matches
Mail list logo
