From cfbolz at gmx.de  Wed Jun  5 04:57:23 2019
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 5 Jun 2019 10:57:23 +0200
Subject: [pypy-dev] better line number information in PyPy3
Message-ID: <CADLBHoQNan1b0n5v9AE2VTUsK4iVPr6fkR2UbPd0LPSV+gTPqw@mail.gmail.com>

Hi all,

This is a discussion mail about improving the traceback line number
quality in PyPy3. Some context:

CPython has started supporting negative line number offset from one
bytecode to the next in its lnotab encoding, see here:

https://bugs.python.org/issue26107
https://github.com/python/cpython/commit/f3914eb16d2#diff-cb296cc5109f5640ff3f6d7198a6abee

(Please don't ask me why not a single test was added for this new feature.)

However, the support is so far only theoretically possible, the Python
3.7/3.8 bytecode compiler does not seem to make use of the feature.
Negative line number jumps occur quite regularly with continuation
lines, eg like this:

def foobar(a, b):
    return "" + (1,
            a,
            b,
            2
            )

If you call this function, the traceback will contain this line:

  File "x.py", line 5, in foobar
    2
TypeError: can only concatenate str (not "tuple") to str

Which is obviously misleading.


A slightly more realistic example are function decorators. There, the
execution order is regularly "backwards": first the function
definition is executed, then the individual decorators are run. There
is currently a hack to sometimes leave the line number on the line of
the first decorator, leading to confusing tracebacks. Example:

def works(f):
    return f

def broken(f):
    assert 0

@works
@broken
@works
def g():
    pass


Running this, you'll get the following traceback:

Traceback (most recent call last):
  File "y.py", line 9, in <module>
    @works
  File "y.py", line 5, in broken
    assert 0
AssertionError

Pointing you again to the wrong line.


We could fix this problem rather easily by removing the code that
prevents the bytecode compiler from emitting negative line number
offsets. Should I implement this?

Advantages:
- A lot less confusing tracebacks in real-world cases

Disadvantages:
- Different behavior from CPython (but arguably more correct)
- Tracing tools could potentially be confused
- Potentially larger lnotab strings due to more jumping around

Cheers,

Carl Friedrich

From dynamicgl at gmail.com  Fri Jun 21 02:12:47 2019
From: dynamicgl at gmail.com (Gelin Yan)
Date: Fri, 21 Jun 2019 14:12:47 +0800
Subject: [pypy-dev] Is pypy 3.5 7.0 available on raspberry pi?
Message-ID: <CABkOF6TSAAhMZbjBmtZJz3LxE3tD1kP5-94-7um4tkyTZ3SxxA@mail.gmail.com>

Hi All

   I  just noticed there are no links for downloading pypy 7.0 for Arm
version. Does it imply I have to use the old version or the arm development
has been suspended?

Regards

gelin yan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20190621/df9a9bfc/attachment.html>

From matti.picus at gmail.com  Fri Jun 21 02:41:01 2019
From: matti.picus at gmail.com (Matti Picus)
Date: Fri, 21 Jun 2019 09:41:01 +0300
Subject: [pypy-dev] Is pypy 3.5 7.0 available on raspberry pi?
In-Reply-To: <CABkOF6TSAAhMZbjBmtZJz3LxE3tD1kP5-94-7um4tkyTZ3SxxA@mail.gmail.com>
References: <CABkOF6TSAAhMZbjBmtZJz3LxE3tD1kP5-94-7um4tkyTZ3SxxA@mail.gmail.com>
Message-ID: <ddd30a6d-b2d2-f19d-4a3e-c4fd7fce6f54@gmail.com>


On 21/6/19 9:12 am, Gelin Yan wrote:
> Hi All
>
> ? ?I? just noticed there are no links for downloading pypy 7.0 for Arm 
> version. Does it imply I have to use the old version or the arm 
> development has been suspended?
>
> Regards
>
> gelin yan
>

While we still nominally support ARM32, we do not supply binaries. It 
takes around 10 hours to translate on a qemu virtual machine with a x86 
host. The solution to cross-compile (scratchbox) is no longer supported. 
We are exploring options for someone to host a aarch64 build machine 
that can run a 32-bit chroot, which seems to be the best alternative. 
Help sponsoring such work would be welcome.


Matti


From jamtlu at gmail.com  Mon Jun 24 08:44:25 2019
From: jamtlu at gmail.com (James Lu)
Date: Mon, 24 Jun 2019 08:44:25 -0400
Subject: [pypy-dev] =?utf-8?q?How_does_PyPy=E2=80=99s_performance_compare?=
 =?utf-8?q?_with_GraalPython=E2=80=99s_performance=3F?=
Message-ID: <AA11C7C3-BA0F-4ADF-8DE2-443F0DEF8B17@gmail.com>

PyPy is to RPython as GraalPython is to Graal.

GraalPython is an implementation of Python on the Graal JIT. It employs what they call a ?self-rewriting AST.? Graal is an AST interpreter. GraalPython uses the Truffle language framework and runs on the Truffle VM. 

What benchmarks should be run to compare GraalPython?s performance versus e.g. PyPy or CPython?

From my observations, the Truffle VM seems to have zero overhead language interoperability? it can even inline across language boundaries! 

From matt at vazor.com  Tue Jun 25 19:25:20 2019
From: matt at vazor.com (Matt Billenstein)
Date: Tue, 25 Jun 2019 23:25:20 +0000
Subject: [pypy-dev] Is pypy 3.5 7.0 available on raspberry pi?
Message-ID: <0101016b90f54020-257b2ce2-0191-48b8-9cc4-28b54c089cc5-000000@us-west-2.amazonses.com>

Hi all,

You can rent aarch64 hardware on ec2 now - I built pypy3 7.1.1 on an a1.large
(2 vCPUs, 4GB RAM, ~$37/mo on-demand) using an armhf chroot.  It took about 140
minutes wall clock time - I did need to create a swap file as my first attempt
failed with a memory error:

real    139m41.253s
user    118m12.756s
sys     1m4.388s

(armhf)ubuntu at ip-172-31-xx-xxx:~$ pypy3-build/opt/pypy3/bin/pypy3
Python 3.6.1 (784b254d669919c872a505b807db8462b6140973, Jun 25 2019, 16:45:29)
[PyPy 7.1.1-beta0 with GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``snow, snow, snow, snow''
>>>> 1 + 2
3

The same script on an i7 laptop with Ubuntu 18.04 took around 64 minutes:

real    63m58.293s
user    53m31.992s
sys     0m17.487s

I had also tried a build on a Raspberry Pi3b with an usb ssd as a swap disk
(this machine only has 1GB of RAM) - this got pretty far, but failed after
around 4 hours with a memory error.  A Pi 4b with 4GB of RAM would compile it I
imagine, so this might make a very cheap buildbot host for that purpose.

m


> On 2019-06-21 02:41, Matti Picus wrote:
> > On 21/6/19 9:12 am, Gelin Yan wrote:
> > Hi All
> >
> >    I  just noticed there are no links for downloading pypy 7.0 for Arm 
> > version. Does it imply I have to use the old version or the arm 
> > development has been suspended?
> >
> > Regards
> >
> > gelin yan
> >
> 
> While we still nominally support ARM32, we do not supply binaries. It 
> takes around 10 hours to translate on a qemu virtual machine with a x86 
> host. The solution to cross-compile (scratchbox) is no longer supported. 
> We are exploring options for someone to host a aarch64 build machine 
> that can run a 32-bit chroot, which seems to be the best alternative. 
> Help sponsoring such work would be welcome.
> 
> 
> Matti

-- 
Matt Billenstein
matt at vazor.com
http://www.vazor.com/

From matt at vazor.com  Tue Jun 25 19:33:39 2019
From: matt at vazor.com (Matt Billenstein)
Date: Tue, 25 Jun 2019 23:33:39 +0000
Subject: [pypy-dev] Is pypy 3.5 7.0 available on raspberry pi?
In-Reply-To: <0101016b90f54020-257b2ce2-0191-48b8-9cc4-28b54c089cc5-000000@us-west-2.amazonses.com>
References: <0101016b90f54020-257b2ce2-0191-48b8-9cc4-28b54c089cc5-000000@us-west-2.amazonses.com>
Message-ID: <0101016b90fcdf30-0a575001-b91c-4106-b03a-86050ca9ed97-000000@us-west-2.amazonses.com>

Fwiw, here's the build script I used:

https://gist.github.com/mattbillenstein/21811731d24403eb5e805f7342d35378

m

On Tue, Jun 25, 2019 at 11:25:20PM +0000, Matt Billenstein wrote:
> Hi all,
> 
> You can rent aarch64 hardware on ec2 now - I built pypy3 7.1.1 on an a1.large
> (2 vCPUs, 4GB RAM, ~$37/mo on-demand) using an armhf chroot.  It took about 140
> minutes wall clock time - I did need to create a swap file as my first attempt
> failed with a memory error:
> 
> real    139m41.253s
> user    118m12.756s
> sys     1m4.388s
> 
> (armhf)ubuntu at ip-172-31-xx-xxx:~$ pypy3-build/opt/pypy3/bin/pypy3
> Python 3.6.1 (784b254d669919c872a505b807db8462b6140973, Jun 25 2019, 16:45:29)
> [PyPy 7.1.1-beta0 with GCC 7.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> And now for something completely different: ``snow, snow, snow, snow''
> >>>> 1 + 2
> 3
> 
> The same script on an i7 laptop with Ubuntu 18.04 took around 64 minutes:
> 
> real    63m58.293s
> user    53m31.992s
> sys     0m17.487s
> 
> I had also tried a build on a Raspberry Pi3b with an usb ssd as a swap disk
> (this machine only has 1GB of RAM) - this got pretty far, but failed after
> around 4 hours with a memory error.  A Pi 4b with 4GB of RAM would compile it I
> imagine, so this might make a very cheap buildbot host for that purpose.
> 
> m
> 
> 
> > On 2019-06-21 02:41, Matti Picus wrote:
> > > On 21/6/19 9:12 am, Gelin Yan wrote:
> > > Hi All
> > >
> > >    I  just noticed there are no links for downloading pypy 7.0 for Arm 
> > > version. Does it imply I have to use the old version or the arm 
> > > development has been suspended?
> > >
> > > Regards
> > >
> > > gelin yan
> > >
> > 
> > While we still nominally support ARM32, we do not supply binaries. It 
> > takes around 10 hours to translate on a qemu virtual machine with a x86 
> > host. The solution to cross-compile (scratchbox) is no longer supported. 
> > We are exploring options for someone to host a aarch64 build machine 
> > that can run a 32-bit chroot, which seems to be the best alternative. 
> > Help sponsoring such work would be welcome.
> > 
> > 
> > Matti
> 
> -- 
> Matt Billenstein
> matt at vazor.com
> http://www.vazor.com/
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

-- 
Matt Billenstein
matt at vazor.com
http://www.vazor.com/