cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
xcm has quit [Read error: Connection reset by peer]
pjenvey has quit [Read error: Connection reset by peer]
zmt00 has joined #pypy
zmt01 has quit [Ping timeout: 260 seconds]
Dejan has joined #pypy
Dejan has quit [Changing host]
Dejan has joined #pypy
<Dejan>
Wow just 11F own tests in the 3.7 branch
BPL has joined #pypy
xcm has quit [Killed (orwell.freenode.net (Nickname regained by services))]
xcm has joined #pypy
YannickJadoul has quit [Ping timeout: 240 seconds]
otisolsen70 has quit [Quit: Leaving]
<arigo>
:-)
Rhy0lite has joined #pypy
dddddd has joined #pypy
YannickJadoul has joined #pypy
YannickJadoul has quit [Remote host closed the connection]
rfgpfeiffer has joined #pypy
<rfgpfeiffer>
Which is the first version of PyPy that implemented PEP 3118?
<arigo>
any version of PyPy3 should do, if you exclude the oldest non-official builds
<arigo>
unless you want to ask specifically about one detail of one function, which might have been fixed more recently
<rfgpfeiffer>
I want to figure out which one is the oldest version of PyPy that can still compile PyGame
<rfgpfeiffer>
to upgrade the build script
<rfgpfeiffer>
Well, you game me the answer I wanted to hear to be honest
<rfgpfeiffer>
Don't build on PyPy when sys.version_info < (3,0)
<arigo>
I fear there is no best answer than "try and see", I'm sure there are many missing details (unrelated to PEP 3118 but related to other parts the C extension support) that have been fixed over time
<arigo>
I'm not sure about what exactly you ask though
<arigo>
PEP 3118 is only implemented in CPython 3.0 anyway
<arigo>
if you rely on it, you don't support Python 2.7 any more
<arigo>
or am I missing something?
<rfgpfeiffer>
Well, it runs on 2.7
<arigo>
ah, then sorry, I've read too fast
<arigo>
it is supposed by PyPy2 too, if it works on CPython 2.7
<arigo>
it is supported by PyPy2 too, if it works on CPython 2.7
<rfgpfeiffer>
ok, then I'll update the build script to refelct that
<rfgpfeiffer>
I can't wait to drop 2.7 support
<arigo>
if you want to know the oldest release of PyPy2 that supports this pep specifically, well, the answer is "it was long ago"
<rfgpfeiffer>
After this release
<rfgpfeiffer>
In this case, sys.version_info >= (2, 7) is good enough, I guess
<arigo>
my point is that I suspect there are other missing things that make pygame not work on old versions of pypy, unrelated to pep 3118
<arigo>
but it's kind of pointess to dig into history
<rfgpfeiffer>
Don't tell me
<arigo>
pypy users generally use a recent version of pypy (which can be either implementing python 2.7 or python 3.6), and if both of these work for pygame, then we're happy
<rfgpfeiffer>
I guess I'll check for a new version of PyPy then, since you've recently fixed some PEP 3118 stuff
<arigo>
if we did, then sorry, I missed that and possibly all I said is bogus
<rfgpfeiffer>
Thanks for the help anyway. I have a recent-ish pypy that came with my Ubuntu 18.04
<rfgpfeiffer>
that's my one data point. It runs, and it's slow
<rfgpfeiffer>
No surprise there, the CPython/C API is not fast with PyPy
jcea has joined #pypy
oberstet has quit [Quit: Leaving]
jvesely has quit [Quit: jvesely]
jvesely has joined #pypy
DanielHolth has joined #pypy
<DanielHolth>
hi
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
<Alex_Gaynor>
Does anyone know how much work it'll be to make the JIT work on aarch64 for macOS? I assume it's just a matter of teaching the aarch64 the macOS calling convention?
<mjacob>
Alex_Gaynor: do you plan to get a new laptop this year? ;)
<mjacob>
Alex_Gaynor: the backend code does not contain explicitly OS-specific code
<Alex_Gaynor>
mjacob: I could have sworn we needed one or two macOS ifs in the x86-64 backend because of stack alignment or something like that.
<Alex_Gaynor>
(I don't use a mac laptop at all for development these days, but lots of people do :-))
<mjacob>
Alex_Gaynor: yes, i guess it's something like adding that. i'm not even sure the macOS calling convention is different
<Dejan>
I have PineBook Pro ($199 hexacore ARM64 I think) and PyPy works there awesomely
<Dejan>
I see they now install Manjaro on them, my one had Debian
Piraty has joined #pypy
<Piraty>
does pypy support crosscompilation? can anyone hint me a buildscript / recipe of some kind that helps with this?
<Piraty>
i'm baffled to see that pypy3.6-7.3.1 requires python2 to build (using prebuild pypy for the build is a nono for me)
<DanielHolth>
PyPy is written in
<DanielHolth>
Python 2. This is unlikely to change.
<Dejan>
How do you bootstrap, say, gcc?
<Dejan>
you *need* gcc or something to bootstrap it
<Dejan>
so why is it a nono?
<Dejan>
you can use CPython2 too
<DanielHolth>
however there are faster ways to view mandelbrot
<Dejan>
DanielHolth, :)
<Dejan>
I remember the first time i ran it...
<Dejan>
when i saw mandelbrot, i was like what the heck...
DanielHolth has quit [Quit: This computer has gone to sleep]
DanielHolth has joined #pypy
<Piraty>
Dejan: i know how to bootstrap gcc and the pain it induces. yet i don't consider language interpreters need themselves (and given py2 is eol, *only* itself) to bootstrap
<Piraty>
a necessary thing
<Piraty>
just ilke rust and go left the path
<Piraty>
which was inevidable
<simpson>
I'm sure that patches are welcome, if you want to help change the situation, but as it is, the C code which RPython produces is dependent on the machine that is doing the translation, so whichever Python interpreter is translating is effectively a bootstrapping interpreter.
lritter has quit [Ping timeout: 258 seconds]
Piraty has left #pypy ["--"]
Dejan has quit [Read error: Connection reset by peer]