cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | so many corner cases, so little time
<glyph> Were the pypy:3 ARM images removed from Docker Hub intentionally?
<glyph> Oh, wait, this is maintained by "the docker community" so maybe this is the wrong place to ask...
glyph has quit [Quit: End of line.]
glyph has joined #pypy
<glyph> (Yeah, sorry, wrong place. The issue for that, already filed, is here: <https://github.com/docker-library/pypy/issues/72>)
lehmrob has joined #pypy
lehmrob has quit [Remote host closed the connection]
lehmrob has joined #pypy
nimaje has quit [Ping timeout: 245 seconds]
nimaje has joined #pypy
<mattip> glyph: the manylinux2014 images are probably better maintained
<mattip> you can find them on https://quay.io/organization/pypa
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
vstinner has joined #pypy
<vstinner> hello. building PyPy 2.7 with GCC 12 fails with a SyntaxError on site.py: https://bugzilla-attachments.redhat.com/attachment.cgi?id=1856197
<vstinner> debug: OperationError:
<vstinner> debug: operror-type: SyntaxError
<vstinner> debug: operror-value: ("invalid syntax (expected ')')", ('/builddir/build/BUILD/pypy2.7-v7.3.6-src/lib-python/2.7/encodings/__init__.py', 38, 73, "_norm_encoding_map = (' . '\n", 0))
<vstinner> it only fails when PyPy 2.7 is built in 32-bit: https://bugzilla.redhat.com/show_bug.cgi?id=2046857
<vstinner> we are considering to drop 32-bit support for PyPy 2.7 on Fedora 36
<vstinner> what should I do for this issue? open an issue? can someone have a look? what do you need?
<cfbolz> vstinner: ouch, what
<vstinner> cfbolz: in short, building PyPy 2.7 fails with GCC 12
<mattip> maybe it is a gcc12 bug? NumPy is still finding gcc11 bugs
mgorny has quit [Quit: No Ping reply in 60 seconds.]
<mattip> when I look at https://www.gnu.org/software/gcc/gcc-12/changes.html, it says "gcc 12 has not been released yet"
<vstinner> mattip: maybe. but someone has to investigate, my team doesn't have the bandwidth to investigate the issue right now
<mattip> ok, thanks for reporting
<vstinner> mattip: GCC 12 is already in Fedora 36 which is also under devlopment, but the GCC 12 behavior is unlikely to change. if it's a compiler bug and nobody reports it, it will be in GCC 12 final :-)
mgorny has joined #pypy
<vstinner> mattip: i found a GCC 12 bug related to HUGE_VAL*0 used by CPython for its Py_NAN constant ;-)
<vstinner> my question stays: what should be done to make progress on this build error?
<cfbolz> vstinner: what's the easiest way for me to locally get an environment to reproduce this?
<vstinner> cfbolz: get a VM running Fedora 36 or Fedora Rawhide. i'm already running Fedora, so I use the mock command which creates a Fedora container, it's cheaper
<vstinner> "easiest" depends on your OS
<cfbolz> vstinner: I'm on ubuntu
<vstinner> cfbolz: hum. i don't know well how PyPy is built for 32-bit
epony has quit [Read error: Connection reset by peer]
<cfbolz> vstinner: I don't either, honestly :-(
<cfbolz> it needs a 32bit environment for that
<vstinner> cfbolz: on my side, i need to investigate a CPython issue with GCC 12 on ppc64le
<cfbolz> we can't cross-compile
<vstinner> cfbolz: sorry, my colleague who knows these stuff is busy, i may come back to you later this week
<cfbolz> ok, thanks
lritter has joined #pypy
<vstinner> Fedora still supports i686 arch?
<vstinner> i don't recall :-p
<vstinner> i asked on the fedora what is the easiest option to reproduce the issue
<vstinner> on x86-64, you can install 32-bit libc (binary, header file) and gcc -m32 works well to build for 32-bit. i use that time to time to debug 32-bit issue on CPython :-)
<cfbolz> vstinner: right, but you need a 32bit python to build pypy then too
<mattip> we build it in a 32-bit docker, running `linux32 <cmd>`
<vstinner> it's not easy to reproduce an isse which requires a specific arch and specific compiler version
<vstinner> on Fedora with mock, it's quite easy ;-)
<mattip> can we "yum install gcc12" inside centos7?
<vstinner> gcc12 is not release, but you can get a more recent compiler on CentOS/RHEL yes (with Software Collection, Developer Toolset, etc.)
<vstinner> right now, Fedora is the easiest option to get a GCC 12
<vstinner> cfbolz, mattip : i will ask my collagues to see how to easily reproduce the issue. once i will know, i will come back to you ;-)
<vstinner> ok, so the next step is: identify steps to reproduce the issue :-)
<mattip> perhaps running the own (untranslated) tests would expose the problem in a more contained test
<mattip> rather than testing the translated interpreter
<mattip> i.e. cpython2 testrunner/runner.py --config=pypy/testrunner_cfg.py --root=rpython
<mattip> for rpython
<mattip> or cpython2 testrunner/runner.py --config=pypy/testrunner_cfg.py --root=pypy
<mattip> for the pypy mixed modules (pypy's equivalent of c-extension modules)
<cfbolz> heh, just discovered that it's completely trivial to make a PyPy AppImage (=one file linux executable)
<cfbolz> adds 300ms to startup time thuogh
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<krono> print a fractal concurrently, and no-one wil notice
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
slav0nic has joined #pypy
Julian has joined #pypy
<mattip> cfbolz: is there any difference between cpython and pypy when creating an AppImage?
<cfbolz> mattip: I didn't try cpython
<cfbolz> PyPy is easy, because it already can do a self contained folder
<cfbolz> Without any compiled in path
otisolsen70 has joined #pypy
Julian has quit [Ping timeout: 272 seconds]
toulene has joined #pypy
Julian has joined #pypy
lritter has quit [Ping timeout: 256 seconds]
toulene has quit [Quit: ZNC - https://znc.in]
lehmrob has quit [Quit: Konversation terminated!]
Julian has quit [Quit: leaving]
<mattip> distributing an alternative interpreter is much harder than just tacking a JIT onto CPython
<mattip> beyond the compiled tarball, we need to provide installers, launchers, signed packages, and even pkg-config integration
<glyph> mattip: yeah I just switched to debian:sid once I realized pypy was up to date
<glyph> It seems to be working fine
<tumbleweed> glad to hear
<glyph> I confess I don’t really understand https://github.com/docker-library/pypy/pull/69 — is that something pypy itself should fix?
<tumbleweed> pypy's amd64 build is portable (shared libs are bundled), but the other archs aren't
<glyph> tumbleweed: does e.g. debian just have their own, separate pypy build process then? the issue here is that they're trying to use upstream binaries on unsupported ("not centos") distributions?
<tumbleweed> glyph: yes, we build from source. The pypy docker image is presumably using the pre-built tarballs from pypy.org's downloads
greedom has joined #pypy
tazle has quit [Ping timeout: 256 seconds]
nanonyme has quit [Ping timeout: 256 seconds]
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
tazle has joined #pypy
<mattip> glyph: thanks, I commented on the issue.
<glyph> mattip: Thanks. Illuminating!
<mattip> tumbleweed: does debian provide a pkg-config file pypy3.pc as part of the build?
<mattip> this came up as part of trying to get meson to support pypy
<mattip> glyph: sorry for the mess
<glyph> mattip: no worries, we're all trying our best
<tumbleweed> mattip: nope. We do have them for cpython, though
glyph has quit [Quit: End of line.]
glyph has joined #pypy
xcm has quit [Remote host closed the connection]
<mattip> tumbleweed: is there a reason to _not_ have them for pypy? Is there a problem with too many files or some other practical consideration?
otisolsen70 has quit [Quit: Leaving]
<tumbleweed> mattip: having it is good for libraries
<tumbleweed> IIRC pypy wasn't embeddable yet, when I packaged pypy
<mattip> it still isn't. I mentioned that in the issue on meson
<mattip> PyPy is missing Py_Initialize and some other c-api functions that would allow it to be embedded
greedom has quit [Remote host closed the connection]
epony has joined #pypy
<mattip> it seems we should release 7.3.9 by March 14 to match CPython, to get libexpat updated to 2.4.7 (currently the buildbots are using 2.4.6)
<tumbleweed> mattip: yeah, so the embedding use-case isn't there. They can also be used by external build systems building C extensions, there's value for having it there
<mattip> that seems reasonable, but I don't want to make you do more work
<tumbleweed> nah, .pc files are trivial
<mattip> cool, thanks
<mattip> you can skip 7.3.8, I will be releasing 7.3.9
<mattip> probably with no release candidates, since there are no big changes
<tumbleweed> +1
<tumbleweed> I wonder if there's an embargoed security issue in the wings, behind that joint release
<mattip> hmm, so maybe it would be prudent to wait till they release first?
Atque has quit [Quit: ...]
<tumbleweed> I don't know if there are usually announcements like that
slav0nic has quit [Ping timeout: 252 seconds]