From teammember0x01 at gmail.com  Sun Jan  9 14:50:38 2022
From: teammember0x01 at gmail.com (M A)
Date: Sun, 9 Jan 2022 14:50:38 -0500
Subject: [pypy-dev] Running PyPy on top of CPython
Message-ID: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>

Hello, I read here (https://rpython.readthedocs.io/en/latest/rpython.html) that PyPy is runnable on top of CPython. How do I start PyPy so it runs in CPython?

From drsalists at gmail.com  Sun Jan  9 16:59:12 2022
From: drsalists at gmail.com (Dan Stromberg)
Date: Sun, 9 Jan 2022 13:59:12 -0800
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
Message-ID: <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>

IINM, Running Pypy overtop of CPython is mostly useful for bootstrapping
Pypy - but it's generally easier to download a Pypy binary from the
official website.

If you just want CPython+speed, maybe try
https://stromberg.dnsalias.org/~strombrg/speeding-python/ ?


On Sun, Jan 9, 2022 at 11:51 AM M A <teammember0x01 at gmail.com> wrote:

> Hello, I read here (https://rpython.readthedocs.io/en/latest/rpython.html)
> that PyPy is runnable on top of CPython. How do I start PyPy so it runs in
> CPython?
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pypy-dev/attachments/20220109/fce7f163/attachment.html>

From matti.picus at gmail.com  Sun Jan  9 17:23:34 2022
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 10 Jan 2022 00:23:34 +0200
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
Message-ID: <7b683b2e-f32f-6ad8-5250-6c8bc83a2403@gmail.com>


On 9/1/22 9:50 pm, M A wrote:
> Hello, I read here (https://rpython.readthedocs.io/en/latest/rpython.html) that PyPy is runnable on top of CPython. How do I start PyPy so it runs in CPython?


python2 pypy/bin/pyinteractive.py


You can get help with

python2 pypy/bin/pyinteractive.py --help


It takes ~20 secs to startup. To drop into rpython, hit ctrl-c, to 
return to interpreted PyPy on top of CPython hit ctrl-d


In rpython you have access to "space".



Matti



From teammember0x01 at gmail.com  Sun Jan  9 21:31:04 2022
From: teammember0x01 at gmail.com (M A)
Date: Sun, 9 Jan 2022 21:31:04 -0500
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
Message-ID: <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>

Well I am developing for PyPy and was hoping to try my code out without having to build PyPy first.

> On Jan 9, 2022, at 4:59 PM, Dan Stromberg <drsalists at gmail.com> wrote:
> 
> 
> IINM, Running Pypy overtop of CPython is mostly useful for bootstrapping Pypy - but it's generally easier to download a Pypy binary from the official website.
> 
> If you just want CPython+speed, maybe try https://stromberg.dnsalias.org/~strombrg/speeding-python/ ?
> 
> 
> On Sun, Jan 9, 2022 at 11:51 AM M A <teammember0x01 at gmail.com> wrote:
> Hello, I read here (https://rpython.readthedocs.io/en/latest/rpython.html) that PyPy is runnable on top of CPython. How do I start PyPy so it runs in CPython?
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev


From matti.picus at gmail.com  Mon Jan 10 03:41:27 2022
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 10 Jan 2022 10:41:27 +0200
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
 <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
Message-ID: <cea20e3b-a073-b2c8-780f-10ca44b14de0@gmail.com>


On 10/1/22 4:31 am, M A wrote:
> Well I am developing for PyPy and was hoping to try my code out without having to build PyPy first.


You asked this question on the issue tracker as well. Running PyPy on 
top of CPython is not a replacement for getting stress tests in the 
issue? comment [0] to pass.


[0] https://foss.heptapod.net/pypy/pypy/-/issues/3566#note_167193


From armin.rigo at gmail.com  Mon Jan 10 09:44:57 2022
From: armin.rigo at gmail.com (Armin Rigo)
Date: Mon, 10 Jan 2022 15:44:57 +0100
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
 <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
Message-ID: <CAMSv6X1-GW-Pqu30yG0HpYVhpwQcLfKPv+phOmuN8ZyH4HUGeQ@mail.gmail.com>

Hi,

On Mon, 10 Jan 2022, 3:31 AM M A <teammember0x01 at gmail.com> wrote:

> Well I am developing for PyPy and was hoping to try my code out without
> having to build PyPy first.
>

I tried twice to tell you how we develop PyPy in the issue: by running
tests. You seem to be ignoring that. Sorry but I will ignore further
requests from you until you acknowledge you have at least tried what I
recommend first.

Armin

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pypy-dev/attachments/20220110/262d2da6/attachment-0001.html>

From teammember0x01 at gmail.com  Mon Jan 10 09:56:47 2022
From: teammember0x01 at gmail.com (M A)
Date: Mon, 10 Jan 2022 09:56:47 -0500
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <CAMSv6X1-GW-Pqu30yG0HpYVhpwQcLfKPv+phOmuN8ZyH4HUGeQ@mail.gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
 <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
 <CAMSv6X1-GW-Pqu30yG0HpYVhpwQcLfKPv+phOmuN8ZyH4HUGeQ@mail.gmail.com>
Message-ID: <02DDB3DC-FD90-4662-B872-ADEF3F7BDEE3@gmail.com>



> On Jan 10, 2022, at 9:44 AM, Armin Rigo <armin.rigo at gmail.com> wrote:
> 
> Hi,
> 
> On Mon, 10 Jan 2022, 3:31 AM M A <teammember0x01 at gmail.com> wrote:
> Well I am developing for PyPy and was hoping to try my code out without having to build PyPy first.
> 
> I tried twice to tell you how we develop PyPy in the issue: by running tests. You seem to be ignoring that.

I think you are confused. I just read in PyPy's documentation that PyPy could be run from CPython. This sounds like something that could help save me time by seeing if my changes work. I'm am not sure why you think I am ignoring the tests. Yes I have tried them. I am seeing if there is a more efficient way of trying out my code without having to wait a long time of PyPy to recompile. 



From armin.rigo at gmail.com  Mon Jan 10 11:02:34 2022
From: armin.rigo at gmail.com (Armin Rigo)
Date: Mon, 10 Jan 2022 17:02:34 +0100
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <02DDB3DC-FD90-4662-B872-ADEF3F7BDEE3@gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
 <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
 <CAMSv6X1-GW-Pqu30yG0HpYVhpwQcLfKPv+phOmuN8ZyH4HUGeQ@mail.gmail.com>
 <02DDB3DC-FD90-4662-B872-ADEF3F7BDEE3@gmail.com>
Message-ID: <CAMSv6X00qsJBxmyKda75M+3zvS0TRo8ZV9jWbT+WTNouBrSbRA@mail.gmail.com>

Hi,

On Mon, 10 Jan 2022 at 15:56, M A <teammember0x01 at gmail.com> wrote:
> I think you are confused. I just read in PyPy's documentation that PyPy could be run from CPython. This sounds like something that could help save me time by seeing if my changes work. I'm am not sure why you think I am ignoring the tests. Yes I have tried them. I am seeing if there is a more efficient way of trying out my code without having to wait a long time of PyPy to recompile.

Sorry for not explaining myself clearly.  I've been trying all along
to tell you that you don't need to recompile PyPy, ever. As long as
not all the tests I listed are passing, then there is basically no
point.  (except that it feels good to see PyPy half-working instead of
not working at all, of course, but don't try to debug that)

The documentation says "PyPy can be run on top of CPython": that's
almost what all the tests are doing.  They run not the whole PyPy, but
instead some small example RPython code (sometimes written as RPython
in the test, sometimes at a lower level).  The point is that they test
the JIT backend by running it as normal Python code, on top of
CPython.  When working on the JIT backend, you don't want to run the
whole PyPy on top of CPython running with the JIT; while possible in
theory, it is far too slow to be practical.  Instead, run the tests,
which test the same thing but with a small bit of RPython code instead
of the many-thousand-of-lines-of-code of PyPy.

Let me try to explain myself in a different way.
What we're trying to do here is fix a JIT compiler emitting machine
code, at the level of RPython instead of Python.  That means that any
error is likely to cause not just a problem for some specific Python
function which you can find by running Python code; instead, bugs
cause random hard-to-debug crashes that show up at half-random
points, with no obvious one-to-one correspondence to what Python code
is running.  This could be caused for example by the wrong registers
being used or accidentally overwritten in some cases, leading to a
nonsense value propagating further, until the point of crash.  Most
tests listed above check all basic cases and problems we encountered
so far.  The last test is producing and running random exemples, in an
attempt to find the random rare-case issues.  It has been the case
that this last test found a remaining bug after running for hours, but
I think that after half a day we can conclude that there is no bug
left to be found.  In the past, there were very rare bugs that went
uncaught by random testing too; these were a real pain to debug---I
once spent more than two weeks straight on a pair of them, running
"gdb" inside a translated PyPy, hacking at the generated C code to
dump more information to try to figure it out.  But these bugs were
more than just in the JIT backend (e.g. some interaction between the
JIT and the GC), and they are fixed now.  I'm telling this story to
explain why I do not recommend going down that path for the simpler
bugs that are already caught by the tests!

So, once more, I recommend working on this by running the tests, and
fixing them, until all tests pass.  Once all tests pass (and not
before) you can try to translate the whole PyPy, and at this point it
will likely work on the first try.

Sorry for not managing to get this message across to you in the past.
I hope I have done so now.


A bient?t,

Armin.

From teammember0x01 at gmail.com  Mon Jan 10 16:28:23 2022
From: teammember0x01 at gmail.com (M A)
Date: Mon, 10 Jan 2022 16:28:23 -0500
Subject: [pypy-dev] Calling a C function from PyPy
Message-ID: <CC0C8997-290C-4355-AC7E-D548BE2B94C9@gmail.com>

Hi, I'm trying to call my own C function from a small RPython program. When I try to build the program I see this error:

[translation:ERROR] Exception: stand-alone program entry point must return an int (and not, e.g., None or always raise an exception).

This is the entire RPython program:

from rpython.rtyper.lltypesystem import rffi, lltype
from rpython.translator.tool.cbuild import ExternalCompilationInfo

info = ExternalCompilationInfo(includes=["./myheader.h"], libraries=["./my_functions.so"])
print_thread_mode = rffi.llexternal("print_thread_mode", [lltype.Void], lltype.Void, compilation_info=info)

def entry_point(argv):
    print_thread_mode()
    return 0

def target(*args):
    return entry_point


The entry_point function is returning an int (0 here). If I remove the call to print_thread_mode() the program compiles. The C function is declared in a .c file. I compiled that file to .so and was able to use it using ctypes in CPython. This is its prototype: void print_thread_mode(void). It simply prints some text.

Is there something I am missing?

From teammember0x01 at gmail.com  Mon Jan 10 16:30:02 2022
From: teammember0x01 at gmail.com (M A)
Date: Mon, 10 Jan 2022 16:30:02 -0500
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <mailman.2316.1641825912.3078.pypy-dev@python.org>
References: <mailman.2316.1641825912.3078.pypy-dev@python.org>
Message-ID: <0B60BAAD-34F3-48CE-802F-734C41D2F6F9@gmail.com>


> On 9/1/22 9:50 pm, M A wrote:
>> Hello, I read here (https://rpython.readthedocs.io/en/latest/rpython.html) that PyPy is runnable on top of CPython. How do I start PyPy so it runs in CPython?
> 
> 
> python2 pypy/bin/pyinteractive.py
> 
> 
> You can get help with
> 
> python2 pypy/bin/pyinteractive.py --help
> 
> 
> It takes ~20 secs to startup. To drop into rpython, hit ctrl-c, to 
> return to interpreted PyPy on top of CPython hit ctrl-d
> 
> 
> In rpython you have access to "space".
> 
> 
> 
> Matti

Thank you very much for this information. It really helped me.

From omer.drow at gmail.com  Tue Jan 11 09:17:16 2022
From: omer.drow at gmail.com (Omer Katz)
Date: Tue, 11 Jan 2022 16:17:16 +0200
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <CAMSv6X00qsJBxmyKda75M+3zvS0TRo8ZV9jWbT+WTNouBrSbRA@mail.gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
 <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
 <CAMSv6X1-GW-Pqu30yG0HpYVhpwQcLfKPv+phOmuN8ZyH4HUGeQ@mail.gmail.com>
 <02DDB3DC-FD90-4662-B872-ADEF3F7BDEE3@gmail.com>
 <CAMSv6X00qsJBxmyKda75M+3zvS0TRo8ZV9jWbT+WTNouBrSbRA@mail.gmail.com>
Message-ID: <CAOZCFcCpuusLZAvR8q1e78DKsvDaHY+OksaaeBtJDjcCpxiZHQ@mail.gmail.com>

Hi Armin,

Would you mind adding the above to the documentation?
I think it'll be useful for newcomers.

Best Regards,
Omer Katz

??????? ??? ??, 10 ????? 2022 ?-18:03 ??? ?Armin Rigo?? <?
armin.rigo at gmail.com??>:?

> Hi,
>
> On Mon, 10 Jan 2022 at 15:56, M A <teammember0x01 at gmail.com> wrote:
> > I think you are confused. I just read in PyPy's documentation that PyPy
> could be run from CPython. This sounds like something that could help save
> me time by seeing if my changes work. I'm am not sure why you think I am
> ignoring the tests. Yes I have tried them. I am seeing if there is a more
> efficient way of trying out my code without having to wait a long time of
> PyPy to recompile.
>
> Sorry for not explaining myself clearly.  I've been trying all along
> to tell you that you don't need to recompile PyPy, ever. As long as
> not all the tests I listed are passing, then there is basically no
> point.  (except that it feels good to see PyPy half-working instead of
> not working at all, of course, but don't try to debug that)
>
> The documentation says "PyPy can be run on top of CPython": that's
> almost what all the tests are doing.  They run not the whole PyPy, but
> instead some small example RPython code (sometimes written as RPython
> in the test, sometimes at a lower level).  The point is that they test
> the JIT backend by running it as normal Python code, on top of
> CPython.  When working on the JIT backend, you don't want to run the
> whole PyPy on top of CPython running with the JIT; while possible in
> theory, it is far too slow to be practical.  Instead, run the tests,
> which test the same thing but with a small bit of RPython code instead
> of the many-thousand-of-lines-of-code of PyPy.
>
> Let me try to explain myself in a different way.
> What we're trying to do here is fix a JIT compiler emitting machine
> code, at the level of RPython instead of Python.  That means that any
> error is likely to cause not just a problem for some specific Python
> function which you can find by running Python code; instead, bugs
> cause random hard-to-debug crashes that show up at half-random
> points, with no obvious one-to-one correspondence to what Python code
> is running.  This could be caused for example by the wrong registers
> being used or accidentally overwritten in some cases, leading to a
> nonsense value propagating further, until the point of crash.  Most
> tests listed above check all basic cases and problems we encountered
> so far.  The last test is producing and running random exemples, in an
> attempt to find the random rare-case issues.  It has been the case
> that this last test found a remaining bug after running for hours, but
> I think that after half a day we can conclude that there is no bug
> left to be found.  In the past, there were very rare bugs that went
> uncaught by random testing too; these were a real pain to debug---I
> once spent more than two weeks straight on a pair of them, running
> "gdb" inside a translated PyPy, hacking at the generated C code to
> dump more information to try to figure it out.  But these bugs were
> more than just in the JIT backend (e.g. some interaction between the
> JIT and the GC), and they are fixed now.  I'm telling this story to
> explain why I do not recommend going down that path for the simpler
> bugs that are already caught by the tests!
>
> So, once more, I recommend working on this by running the tests, and
> fixing them, until all tests pass.  Once all tests pass (and not
> before) you can try to translate the whole PyPy, and at this point it
> will likely work on the first try.
>
> Sorry for not managing to get this message across to you in the past.
> I hope I have done so now.
>
>
> A bient?t,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pypy-dev/attachments/20220111/e508b197/attachment.html>

From matti.picus at gmail.com  Tue Jan 11 10:57:41 2022
From: matti.picus at gmail.com (Matti Picus)
Date: Tue, 11 Jan 2022 17:57:41 +0200
Subject: [pypy-dev] Running PyPy on top of CPython
In-Reply-To: <CAOZCFcCpuusLZAvR8q1e78DKsvDaHY+OksaaeBtJDjcCpxiZHQ@mail.gmail.com>
References: <0E5EA5C5-0FF1-472E-9EE4-EF49960747F0@gmail.com>
 <CAGGBd_rAzQhCHeyDrD5fdZRryM=OwSNx5wEPo=WM+KEGKjGdfA@mail.gmail.com>
 <8A99C626-7A00-4D24-8CFA-EEC023D35C27@gmail.com>
 <CAMSv6X1-GW-Pqu30yG0HpYVhpwQcLfKPv+phOmuN8ZyH4HUGeQ@mail.gmail.com>
 <02DDB3DC-FD90-4662-B872-ADEF3F7BDEE3@gmail.com>
 <CAMSv6X00qsJBxmyKda75M+3zvS0TRo8ZV9jWbT+WTNouBrSbRA@mail.gmail.com>
 <CAOZCFcCpuusLZAvR8q1e78DKsvDaHY+OksaaeBtJDjcCpxiZHQ@mail.gmail.com>
Message-ID: <cce6357d-4c40-0696-9bbf-c014ad9bc690@gmail.com>

Hi Omer. I think much of what Armin wrote is already in the 
documentation like 
https://doc.pypy.org/en/latest/contributing.html#architecture and 
https://doc.pypy.org/en/latest/contributing.html#test-driven-development. 
Could you see where things can be improved?

Matti


On 11/1/22 4:17 pm, Omer Katz wrote:
> Hi Armin,
>
> Would you mind adding the above to the documentation?
> I think it'll be useful for newcomers.
>
> Best Regards,
> Omer Katz
>
> ??????? ??? ??, 10 ????? 2022 ?-18:03 ??? ?Armin Rigo?? 
> <?armin.rigo at gmail.com <mailto:armin.rigo at gmail.com>??>:?
>
>     Hi,
>
>     On Mon, 10 Jan 2022 at 15:56, M A <teammember0x01 at gmail.com
>     <mailto:teammember0x01 at gmail.com>> wrote:
>     > I think you are confused. I just read in PyPy's documentation
>     that PyPy could be run from CPython. This sounds like something
>     that could help save me time by seeing if my changes work. I'm am
>     not sure why you think I am ignoring the tests. Yes I have tried
>     them. I am seeing if there is a more efficient way of trying out
>     my code without having to wait a long time of PyPy to recompile.
>
>     Sorry for not explaining myself clearly.? I've been trying all along
>     to tell you that you don't need to recompile PyPy, ever. As long as
>     not all the tests I listed are passing, then there is basically no
>     point.? (except that it feels good to see PyPy half-working instead of
>     not working at all, of course, but don't try to debug that)
>
>     The documentation says "PyPy can be run on top of CPython": that's
>     almost what all the tests are doing.? They run not the whole PyPy, but
>     instead some small example RPython code (sometimes written as RPython
>     in the test, sometimes at a lower level).? The point is that they test
>     the JIT backend by running it as normal Python code, on top of
>     CPython.? When working on the JIT backend, you don't want to run the
>     whole PyPy on top of CPython running with the JIT; while possible in
>     theory, it is far too slow to be practical.? Instead, run the tests,
>     which test the same thing but with a small bit of RPython code instead
>     of the many-thousand-of-lines-of-code of PyPy.
>
>     Let me try to explain myself in a different way.
>     What we're trying to do here is fix a JIT compiler emitting machine
>     code, at the level of RPython instead of Python.? That means that any
>     error is likely to cause not just a problem for some specific Python
>     function which you can find by running Python code; instead, bugs
>     cause random hard-to-debug crashes that show up at half-random
>     points, with no obvious one-to-one correspondence to what Python code
>     is running.? This could be caused for example by the wrong registers
>     being used or accidentally overwritten in some cases, leading to a
>     nonsense value propagating further, until the point of crash. Most
>     tests listed above check all basic cases and problems we encountered
>     so far.? The last test is producing and running random exemples, in an
>     attempt to find the random rare-case issues.? It has been the case
>     that this last test found a remaining bug after running for hours, but
>     I think that after half a day we can conclude that there is no bug
>     left to be found.? In the past, there were very rare bugs that went
>     uncaught by random testing too; these were a real pain to debug---I
>     once spent more than two weeks straight on a pair of them, running
>     "gdb" inside a translated PyPy, hacking at the generated C code to
>     dump more information to try to figure it out.? But these bugs were
>     more than just in the JIT backend (e.g. some interaction between the
>     JIT and the GC), and they are fixed now.? I'm telling this story to
>     explain why I do not recommend going down that path for the simpler
>     bugs that are already caught by the tests!
>
>     So, once more, I recommend working on this by running the tests, and
>     fixing them, until all tests pass.? Once all tests pass (and not
>     before) you can try to translate the whole PyPy, and at this point it
>     will likely work on the first try.
>
>     Sorry for not managing to get this message across to you in the past.
>     I hope I have done so now.
>
>
>     A bient?t,
>
>     Armin.
>     _______________________________________________
>     pypy-dev mailing list
>     pypy-dev at python.org <mailto:pypy-dev at python.org>
>     https://mail.python.org/mailman/listinfo/pypy-dev
>     <https://mail.python.org/mailman/listinfo/pypy-dev>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev

From rodrigo.bruno at tecnico.ulisboa.pt  Tue Jan 18 02:28:03 2022
From: rodrigo.bruno at tecnico.ulisboa.pt (Rodrigo Bruno)
Date: Tue, 18 Jan 2022 07:28:03 +0000
Subject: [pypy-dev] MoreVMs 2022 : Workshop on Modern Language Runtimes,
 Ecosystems, and VMs
Message-ID: <CADy33kDcvbUSbBvcw30+4HPNftC=9VAq3Tuuhfs_5mYqEpvUyw@mail.gmail.com>

======================================================================

              Call for Extended Abstracts and Talks: MoreVMs?22

                              6th Workshop on

               Modern Language Runtimes, Ecosystems, and VMs

                      Co-located with ?Programming??22

                  March 22nd, 2022, Porto, Portugal


https://2022.programming-conference.org/home/MoreVMs-2022#Call-for-Talks-and-Papers

======================================================================

Following six previous successful editions, the MoreVMs?22 workshop aims to
bring together industrial and academic programmers to discuss the design,
implementation, and usage of modern languages and runtimes. This includes
aspects such as reuse of language runtimes, modular implementation,
language design, and compilation strategies. By bringing together both
researchers and practitioners, the workshop aims to enable a diverse
discussion on how languages and runtimes are currently being utilized, and
where they need to improve further.

In addition to conventional workshop-style submissions, MoreVMs also
accepts (and encourages) submissions that present early-stage work and
emerging ideas.

Relevant topics include, but are definitely not limited to, the following:

 - Extensible VM design (compiler- or interpreter-based VMs)

 - Reusable components (e.g. interpreters, garbage collectors, ...)

 - Static and dynamic compilation techniques

 - Techniques for targeting high-level languages such as JavaScript

 - Interoperability between languages

 - Tooling support (e.g. debugging, profiling, etc.)

 - Programming language development environments

 - Case studies of existing language implementation approaches

 - Language implementation challenges and trade-offs

 - Surveys and usage reports to understand usage in the wild

 - Ideas for more predictable performance

 - Ideas for how VMs could take advantage of new hardware features

 - Ideas for how we should build languages in the future

Workshop Format and Submissions

-------------------------------

We welcome presentation proposals in the form of extended abstracts (2 to 4

pages long), talk proposals (title and 400 words abstract), and blog posts,
discussing new

techniques, insights, experiences, works-in-progress, as well as future

visions, from either an academic or industrial perspective.

The extended abstracts and talk proposals, and if the speakers wish, their
slides, will be published on the workshop's website. Alternatively,
extended abstracts can be published as part of the companion of
?Programming??22 in the ACM DL. Publication in the ACM DL is conditional on
the acceptance by the program committee.

Please note that MoreVMs?22 is organized as an academic workshop, and as
such, speakers will be required to register for the workshop. We regret
that we are unable to cover registration, travel, or accommodation costs
for authors.

Important Dates

---------------

Extended abstract and talk submissions:  2022-01-27

Author notification:                     2022-02-15

Camera Ready:                           2022-03-01

Workshop:                                2022-03-22

All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour.

Organizers

----------

Rodrigo Bruno, INESC-ID / T?cnico, ULisboa, Portugal

Michael Engel, NTNU, Norway

-- 
rodrigo-bruno.github.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/pypy-dev/attachments/20220118/a43f0094/attachment.html>

From matti.picus at gmail.com  Wed Jan 26 18:03:28 2022
From: matti.picus at gmail.com (Matti Picus)
Date: Thu, 27 Jan 2022 01:03:28 +0200
Subject: [pypy-dev] PyPy v7.3.8 rc1 now available
Message-ID: <c6153128-c3ad-6269-6d3c-d19bb6c8e481@gmail.com>

This is a release of 4 versions of python: 2.7, 3.7, 3.8 (no longer 
beta) and 3.9 (beta quality).


Release note: https://doc.pypy.org/en/latest/release-v7.3.8.html


Downloads: https://


checksums: https://www.pypy.org/checksums.html


As soon as the CDN network updates the 
https://downloads.python.org/pypy/versions.json file, you can use them 
in github actions CI.


Please try these out and report any problems. Note that we are having 
issues with the ARM8-64bit buildbot, so we are not releasing binary 
packages for that platform. Hopefully we will have an alternative for 
the final release.

Matti


From matti.picus at gmail.com  Wed Jan 26 18:04:25 2022
From: matti.picus at gmail.com (Matti Picus)
Date: Thu, 27 Jan 2022 01:04:25 +0200
Subject: [pypy-dev] PyPy v7.3.8 rc1 now available
In-Reply-To: <c6153128-c3ad-6269-6d3c-d19bb6c8e481@gmail.com>
References: <c6153128-c3ad-6269-6d3c-d19bb6c8e481@gmail.com>
Message-ID: <6a5dd9b6-0516-e1fb-0cd5-8d0c84a4713b@gmail.com>

Downloads: https://downloads.python.org/pypy


On 27/1/22 01:03, Matti Picus wrote:
> This is a release of 4 versions of python: 2.7, 3.7, 3.8 (no longer 
> beta) and 3.9 (beta quality).
>
>
> Release note: https://doc.pypy.org/en/latest/release-v7.3.8.html
>
>
> Downloads: https://
>
>
> checksums: https://www.pypy.org/checksums.html
>
>
> As soon as the CDN network updates the 
> https://downloads.python.org/pypy/versions.json file, you can use them 
> in github actions CI.
>
>
> Please try these out and report any problems. Note that we are having 
> issues with the ARM8-64bit buildbot, so we are not releasing binary 
> packages for that platform. Hopefully we will have an alternative for 
> the final release.
>
> Matti

From mhroncok at redhat.com  Wed Jan 26 18:19:06 2022
From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=)
Date: Thu, 27 Jan 2022 00:19:06 +0100
Subject: [pypy-dev] PyPy v7.3.8 rc1 now available
In-Reply-To: <c6153128-c3ad-6269-6d3c-d19bb6c8e481@gmail.com>
References: <c6153128-c3ad-6269-6d3c-d19bb6c8e481@gmail.com>
Message-ID: <45148083-1adc-be00-82ec-6671a901ce79@redhat.com>

On 27. 01. 22 0:03, Matti Picus wrote:
> This is a release of 4 versions of python: 2.7, 3.7, 3.8 (no longer beta) and 
> 3.9 (beta quality).
> 
> 
> Release note: https://doc.pypy.org/en/latest/release-v7.3.8.html
> 
> 
> Downloads: https://downloads.python.org/pypy
> 
> 
> checksums: https://www.pypy.org/checksums.html
> 
> 
> As soon as the CDN network updates the 
> https://downloads.python.org/pypy/versions.json file, you can use them in 
> github actions CI.
> 
> 
> Please try these out and report any problems. Note that we are having issues 
> with the ARM8-64bit buildbot, so we are not releasing binary packages for that 
> platform. Hopefully we will have an alternative for the final release.

I'll try to package PyPy3.9 for Fedora and report back any layout related-issues.

Thanks!

-- 
Miro Hron?ok
-- 
Phone: +420777974800
IRC: mhroncok


From mhroncok at redhat.com  Thu Jan 27 07:59:04 2022
From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=)
Date: Thu, 27 Jan 2022 13:59:04 +0100
Subject: [pypy-dev] Installation layout of the PyPy 3.8 Fedora package
In-Reply-To: <816e9a88-9945-7c0d-0f26-f7b94f37c063@redhat.com>
References: <bb52d1bb-3dd2-86a0-9f93-3409a343e058@redhat.com>
 <0af2df4f-08d2-82e1-f6a1-c12f4ca477ef@gmail.com>
 <816e9a88-9945-7c0d-0f26-f7b94f37c063@redhat.com>
Message-ID: <1beadb35-35e2-a781-6e4e-ec14c6b0c617@redhat.com>

On 06. 12. 21 12:30, Miro Hron?ok wrote:
> 2) Help make PyPy 3.9 more like CPython 3.9 in this regard.

So, this is now:

/usr
??? bin
??? ??? libpypy3.9-c.so
??? ??? pypy -> pypy3.9
??? ??? pypy3 -> pypy3.9
??? ??? pypy3.9
??? ??? python -> pypy3.9
??? ??? python3 -> pypy3.9
??? ??? python3.9 -> pypy3.9
??? include
??? ??? pypy3.9
???     ??? *.h
??? lib64
  ?? ??? pypy3.9
  ??     ??? *.py
  ??     ??? */
  ??     ??? *.pypy39-pp73-x86_64-linux-gnu.so
  ??     ??? __pycache__
  ??     ??? ??? *.pypy39.opt-1.pyc
  ??     ??? ??? *.pypy39.pyc
  ??     ??? site-packages/

That looks reasonable good -- everything is namespaced or a symbolic link.

The only remaining thing is libpypy3.9-c.so in /usr/bin.
I'd like to move it to /usr/lib64 where it will be found.

Technically, Fedora forbids an unversioned so file there.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning

CPython has libpython3.9.so.1.0.

$ objdump -p /usr/lib64/libpython3.9.so.1.0 | grep 'SONAME'
   SONAME               libpython3.9.so.1.0

Do you think PyPy can do this as well? Or is there a reason not to?

Thanks!
-- 
Miro Hron?ok
-- 
Phone: +420777974800
IRC: mhroncok


From matti.picus at gmail.com  Thu Jan 27 09:54:47 2022
From: matti.picus at gmail.com (Matti Picus)
Date: Thu, 27 Jan 2022 16:54:47 +0200
Subject: [pypy-dev] Installation layout of the PyPy 3.8 Fedora package
In-Reply-To: <1beadb35-35e2-a781-6e4e-ec14c6b0c617@redhat.com>
References: <bb52d1bb-3dd2-86a0-9f93-3409a343e058@redhat.com>
 <0af2df4f-08d2-82e1-f6a1-c12f4ca477ef@gmail.com>
 <816e9a88-9945-7c0d-0f26-f7b94f37c063@redhat.com>
 <1beadb35-35e2-a781-6e4e-ec14c6b0c617@redhat.com>
Message-ID: <bd98fca8-c6e0-0155-2428-b5a7292da89e@gmail.com>


On 27/1/22 14:59, Miro Hron?ok wrote:
> ...
> The only remaining thing is libpypy3.9-c.so in /usr/bin.
> I'd like to move it to /usr/lib64 where it will be found.
>
> Technically, Fedora forbids an unversioned so file there.
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning 
>
>
> CPython has libpython3.9.so.1.0.
>
> $ objdump -p /usr/lib64/libpython3.9.so.1.0 | grep 'SONAME'
> ? SONAME?????????????? libpython3.9.so.1.0
>
> Do you think PyPy can do this as well? Or is there a reason not to?
>
> Thanks!


(Previously replied privately, sorry about that).


I tried moving the so to /usr/lib64/libpypy3-c.so.1.0 and adding a 
symlink to /usr/lib64/libpypy3-c.so.

After running ldconfig to pick up the new file, I could run pypy3-c, and 
it seems venv and virtualenv do not complain about missing the shared 
object.


So it seems it JustWorks.


Matti


From mhroncok at redhat.com  Thu Jan 27 10:03:08 2022
From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=)
Date: Thu, 27 Jan 2022 16:03:08 +0100
Subject: [pypy-dev] Installation layout of the PyPy 3.8 Fedora package
In-Reply-To: <bd98fca8-c6e0-0155-2428-b5a7292da89e@gmail.com>
References: <bb52d1bb-3dd2-86a0-9f93-3409a343e058@redhat.com>
 <0af2df4f-08d2-82e1-f6a1-c12f4ca477ef@gmail.com>
 <816e9a88-9945-7c0d-0f26-f7b94f37c063@redhat.com>
 <1beadb35-35e2-a781-6e4e-ec14c6b0c617@redhat.com>
 <bd98fca8-c6e0-0155-2428-b5a7292da89e@gmail.com>
Message-ID: <6dc80ca0-d55f-ed63-1c4b-5fdbe87f69d0@redhat.com>

On 27. 01. 22 15:54, Matti Picus wrote:
> 
> On 27/1/22 14:59, Miro Hron?ok wrote:
>> ...
>> The only remaining thing is libpypy3.9-c.so in /usr/bin.
>> I'd like to move it to /usr/lib64 where it will be found.
>>
>> Technically, Fedora forbids an unversioned so file there.
>>
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning 
>>
>>
>> CPython has libpython3.9.so.1.0.
>>
>> $ objdump -p /usr/lib64/libpython3.9.so.1.0 | grep 'SONAME'
>> ? SONAME?????????????? libpython3.9.so.1.0
>>
>> Do you think PyPy can do this as well? Or is there a reason not to?
>>
>> Thanks!
> 
> 
> (Previously replied privately, sorry about that).
> 
> 
> I tried moving the so to /usr/lib64/libpypy3-c.so.1.0 and adding a symlink to 
> /usr/lib64/libpypy3-c.so.
> 
> After running ldconfig to pick up the new file, I could run pypy3-c, and it 
> seems venv and virtualenv do not complain about missing the shared object.
> 
> 
> So it seems it JustWorks.

In order to be fully SONAME versioned, the file also needs to set SONAME in it. 
It seems it JustWorks as well:


# mv /usr/bin/libpypy3.9-c.so /usr/lib64/libpypy3.9-c.so.1.0
# ln -s libpypy3.9-c.so.1.0 /usr/lib64/libpypy3.9-c.so

# patchelf --set-soname libpypy3.9-c.so.1.0 /usr/lib64/libpypy3.9-c.so.1.0
# objdump -p /usr/lib64/libpypy3.9-c.so.1.0 | grep 'SONAME'
   SONAME               libpypy3.9-c.so.1.0

# pypy3
Python 3.9.10 (5bee8a8dce85, Jan 27 2022, 11:29:45)...


Awesome!
-- 
Miro Hron?ok
-- 
Phone: +420777974800
IRC: mhroncok


From teammember0x01 at gmail.com  Sun Jan 30 10:39:25 2022
From: teammember0x01 at gmail.com (M A)
Date: Sun, 30 Jan 2022 10:39:25 -0500
Subject: [pypy-dev] How to declare a variable as a void** type
Message-ID: <880931B8-EA29-43F6-A9A4-B39B3A56881A@gmail.com>

Hi, I'm working on an libffi function called ffi_closure_alloc() that takes for its second argument a variable of type void**. Is there a way to declare a Rpython variable as a point to a pointer to a void?