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
<mattip>
cool, just as the macos buldbot began to fail, someone submitted a pr to fix it
marvin_ has quit [Remote host closed the connection]
marvin_ has joined #pypy
<antocuni>
mattip: I finally merged hpy into py3.6 :)
<antocuni>
(although it's not completely up to date with the latest git version, I'll explain more in an upcoming pypy-dev email)
<arigato>
I personally think it's too early to include _hpy_universal in an official pypy release, because tomorrow it won't be usable any more, but well
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<danchr>
mattip: I think I fixed it :)
<danchr>
perhaps the reason this has started failing is that Clang gives an error when implicitly declaring a library function — whereas that used to work just fine
<mattip>
danchr: thanks, and thanks for that PR, it came just in time
<danchr>
that wasn't even intentional ;)
<danchr>
just lucky
<danchr>
FWIW the changes to get Boehm working weren't _quite_ sufficient
YannickJadoul has joined #pypy
<danchr>
not sure why…
<mattip>
about the MACOSX_DEPLOYMENT_TARGET and sysconfig in general, it is not easy to figure out what is the right strategy
oberstet has quit [Remote host closed the connection]
<mattip>
since it impacts so many downstream projects: virtualenv, setuptools, and more
<danchr>
yeah, it's probably not a safe change
<danchr>
or rather; it should be dealt with as part of larger cleanup of the layout/distutils stuff
<danchr>
which I'd like to take a stab at, but I'm not entirely sure where to start
<mattip>
danchr: it depends on what the goal is.
<mattip>
PyPy as installed from the tarballs tries to mimic a virtualenv, and install everything inside a base directory
<danchr>
yeah, but if you're actually _installing_ pypy, that's a rather odd layout
<mattip>
unlike, say, debian packaging that spreads things out to /usr/local
<mattip>
so there is a basic conflict here. I wonder if templating could be used to solve it
<danchr>
from my perspective, there are two issues here: 1) PyPy needs to know where to find its bundled modules and 2) the bundled modules, pip, venv, distutils, etc., need to adapt to whatever layout used
<danchr>
once you know how to do #1, you can figure out what to do with #2
<danchr>
on macOS at least, part of getting packaging “right” is made easier by the fact that the executable actually refers to the dynamic library by a path, and that path is editable using install_name_tool
<mattip>
at the end of the day, PyPy should use the same methods CPython uses
<danchr>
well, that would essentially imply migrating PyPy to autotools
<mattip>
we have a Makefile, although the buildbots do not use it
<danchr>
one option is to extract a small library, written in C and using autotools, which would define the relevant symbols which pypy could then load and link against
<mgorny>
Where @EPREFIX@ is subst at build time
<mgorny>
But it still relies on pypy exec being in the usual place
<mgorny>
(And symlinked to /usr/bin)
<danchr>
mgorny: what I like to achieve is packaging PyPy in a way where it essentially corresponds to CPython and every other tool, rather than stashing it in ${prefix}/pypy with symlinks in ${prefix}/bin
<danchr>
mattip: what's your opinion of the small-exta-library idea? it might it much easier to mimic CPython in a limited fashion without applying a major overhaul to the RPython toolchain
<danchr>
+r
<mgorny>
That sounds like an ugly hack that's going to replace one problem with another
<mgorny>
(How do you install multiple pypy versions? )
<simpson>
(Same way as installing multiple versions of anything else: Use Nix, or something like Gentoo's switchable profiles)
<simpson>
(But also yeah, ugly hacks should not go unquestioned.)
<mattip>
danchr: pypy.exe is actually a very thin wrapper over libpypy-c.dylib
<mattip>
this is the entire C code:
<mattip>
int pypy_main_startup(int, char*[]); int main(int argc, char* argv[]) { return pypy_main_startup(argc, argv); }
<mattip>
mgorny: do you mean multiple pypy versions as in python2.7, python3.6, python3.7 or pypy versions as in pypy7.3.0, pypy7.3.1, pypy7.3.2?
<danchr>
ah, so a simpler solution might be to autotoolify pypy-c?
<mattip>
yup
<mattip>
and then percolate the variables into pypy_main_startup
<mattip>
or some other helper functions
<danchr>
so essentially, pypy-c would have some structure which defined the state of how to initialize PyPy, and pypy_main_startup() would take that state as an argument
<danchr>
perhaps we could rely on the linker by having a weakly imported symbol instead, and thus not changing the signature of pypy_main_startup()?
<danchr>
the RPython code would simply check whether that symbol is NULL
<mattip>
sure
<danchr>
the advantage to that is that it probably wouldn't break embedding or running unconfigured quite as much
<mattip>
I think the code that you are looking for is in pypy/interpreter/appmain.py, in setup_bootstrap_path
<mattip>
it is tricky, there are some comments there about what is permitted
<danchr>
I was looking in pypy/module/sys/initpath.py
<danchr>
no appmain.py in either default or py3.7?
<danchr>
ah, app_main.py :)
<mattip>
sorry
* mattip
off, can chat later
<YannickJadoul>
How would I go about debugging a function of the C API that segfaults?
<YannickJadoul>
PyUnicode_DecodeUTF16 seems to crash when used in pybind11, but getting a stacktrace with gdb isn't exactly helpful
<mgorny>
mattip: the former is sufficient for me
<mgorny>
danchr: tbh, you don't really need autoconf if it's just about substituting paths
<mgorny>
a trivial python script would do
<danchr>
yeah, autotools is probably overkill
ronan has quit [Remote host closed the connection]
<YannickJadoul>
mattip: I'm now noticing that even without adding a test, `pypy -m pytest pypy/module/cpyext/test/test_unicodeobject.py` already crashes