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
<kingsley>
simpson: Thank you for sharing your thoughts. Sorry for not replying sooner.
<kingsley>
I'll humbly offer a few tentative and non-definitive comments on your reasonable questions!
<kingsley>
"Does it have to be a fork of PyPy?" Maybe at first, at least in a development branch.
<kingsley>
"Why would we need to fork it?" Damage control during development. Later on, refactoring is different enough from pypy's claim to fame, the need for speed, that a new name related to refactoring might avoid confusion.
<kingsley>
"do you have a specific plan for how that (machine learning) would work?" At first glance, it seems to me that since machines learn by example, the examples presented to a machine learning algorithm might include inputs of
<kingsley>
spaghetti code,
<kingsley>
pypy's analysis of it,
<kingsley>
coccinelle's analysis of it, and
<kingsley>
the original spaghetti code after a cool python programmer refactored it, maybe so it complies with a PEP or two.
<kingsley>
These would be training examples for a machine learning algorithm.
<kingsley>
If it learned well, I can imagine it becoming a plugin for common editors, like gvim, and IDEs, like pycharm, that enhance built in pretty printing reformatting to include refactoring.
<kingsley>
simpson: I share your concern it may be unrealistically ambitions.
<kingsley>
But as energizer astutely pointed out, some of the code may already be written.
<energizer>
i dont see how this relates to the pypy runtime though
<kingsley>
energizer: Sorry of I wasn't clear. Maybe pypy's analysis of spaghetti-like python code could be an additional, as they say, "engineered" feature that improves the performance of pre-existing machine learning code, like for suggesting code changes.
ronan__ has quit [Read error: Connection reset by peer]
ronan__ has joined #pypy
ronan has quit [Ping timeout: 265 seconds]
mwhudson has quit [Ping timeout: 245 seconds]
ronan__ has quit [Ping timeout: 276 seconds]
<kenaan>
antocuni hpy c385bc205649 /pypy/module/hpy_universal/: move the _vendored directory one level up and reorganize things until tests pass again
<kenaan>
antocuni hpy 5b07516b0134 /pypy/module/hpy_universal/update_vendored.sh: update the script with the new location
<kenaan>
antocuni hpy 114766a84394 /pypy/module/hpy_universal/update_vendored.sh: make the script nicer
<kenaan>
antocuni hpy e24f375edf83 /pypy/module/hpy_universal/_vendored/test/support.py: update support.py to the git hpy revision 48d7fda
<kenaan>
antocuni hpy 2f6fc739e150 /pypy/module/hpy_universal/test/support.py: we no longer need the FakeSpec, we can call hpy_universal.load directly now
<kenaan>
antocuni hpy be9be5d98bb9 /pypy/module/hpy_universal/test/support.py: reduce code duplication and reuse most of the logic which is already in support.py
<kenaan>
antocuni hpy 0fee85415527 /pypy/module/hpy_universal/test/: remove the test duplication: we can now reuse directly the tests which we vendored from hpy
<mattip_>
maybe the occasional aarch64 translation failures on default (in malloc removal) and py3.6 (in inlining a _siphash24) are related
<mattip_>
something like a failure to correctly remove mallocs when inlining a 4-value return tuple
mikroskeem has quit [Quit: overflow in /dev/null]
ronan__ has joined #pypy
Rhy0lite has joined #pypy
ronan__ has quit [Remote host closed the connection]
marky1991_2 has joined #pypy
lritter has quit [Ping timeout: 245 seconds]
lritter has joined #pypy
YannickJadoul has joined #pypy
<YannickJadoul>
Sorry, yet another annoying macOS wheel-building thing
<YannickJadoul>
It seems that PyPy 2 is building spam-0.1.0-pp272-pypy_41-macosx_10_14_x86_64.whl
<YannickJadoul>
Then cibuildwheel tries to install it, but errors: "ERROR: spam-0.1.0-pp272-pypy_41-macosx_10_14_x86_64.whl is not a supported wheel on this platform."
<YannickJadoul>
(And indeed, the platform is 10.13, if I look up the CI's configuration)
<mattip_>
I wonder where the platform tag is getting "14" in macosx_10_14_x86_64 from
<YannickJadoul>
Reason is because: distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET'] returns '10.14'
<mattip_>
ahh. What happens if you change that to 13?
<mattip_>
or override it with an environment variable
<YannickJadoul>
I think one solution would indeed be to set 'MACOSX_DEPLOYMENT_TARGET' to '10.13' when building the wheel
<YannickJadoul>
I still don't 100% get this, but I think that distutils default to the MACOSX_DEPLOYMENT_TARGET that was used to build the Python interpreter, if it's not explictly set?
<mattip_>
cpython caches the Makefile and uses values from that
<mattip_>
we don't
<YannickJadoul>
Aha, yes. But any idea where the 10.14 in sysconfig comes from, then?
<YannickJadoul>
(I'm making a new build with "MACOSX_DEPLOYMENT_TARGET" set to 10.13, if not set, btw. That should work
<YannickJadoul>
)
<YannickJadoul>
But it feels weird that a PyPy interpreter builds wheels it can't install
<mattip_>
on HEAD we changed that to '10.7'
<YannickJadoul>
Oh, nice! :) So all I need to do is put this workaround for now, and wait for the newest PyPy release?
<YannickJadoul>
OK, and I just figured out: for 3.6, there's no problem, because 'MACOSX_DEPLOYMENT_TARGET' not in distutils.sysconfig.get_config_vars(), and in that case, distutils defaults to using the current system's version
<mattip_>
should we do that on 2.7 as well?
<mattip_>
it seems weird that they do not do the same thing
<YannickJadoul>
Having the same behavior would be nice
<YannickJadoul>
But I would think having sysconfig's "MACOSX_DEPLOYMENT_TARGET" set to the lowest value on which the PyPy will run would be best
<YannickJadoul>
error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.13" but "10.14" during configure
<mattip_>
try a nightly instead where the MACOS_DEPLOYMENT_TARGET is '10.7'
tsaka_ has quit [Quit: Konversation terminated!]
<mattip_>
or add a patch step to set it in your CI
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
Dejan has quit [Quit: Leaving]
marky1991_2 has quit [Ping timeout: 240 seconds]
jvesely has joined #pypy
<YannickJadoul>
mattip_: Thanks for the suggestion. Indeed, distutils compares an externally-set MACOS_DEPLOYMENT_TARGET against the one inside of Python
<YannickJadoul>
So I've made a workaround patch, and am trying again
marky1991 has joined #pypy
<kenaan>
antocuni hpy 3a384fd65d2e /rpython/translator/test/test_exceptiontransform.py: (antocuni, arigo): add a passing test which we needed to convince ourselves that you can raise exceptions from withi...
marky1991 has quit [Ping timeout: 265 seconds]
ronan has joined #pypy
<kenaan>
antocuni hpy 84c205b54510 /pypy/module/hpy_universal/_vendored/: update to pyhandle/hpy c8ddac3
<kenaan>
antocuni hpy 120fbccc3422 /pypy/module/hpy_universal/: (antocuni, arigo) WIP implementing test_exception this mostly works already. However, if you raise an exception whi...
<kenaan>
arigo hpy 1b05295469eb /rpython/rtyper/lltypesystem/: (antocuni, arigo) Allow llhelper functions to propagate exceptions from RPython to RPython via C. This already works a...
<YannickJadoul>
cibuildwheel tests are succeeding to build PyPy wheels on all three Windows, macOS, and (many)Linux!
<YannickJadoul>
mattip_, antocuni, anyone else who's interested: Do you mind if I tag you in the PR, so you can have a look at a few details, such as PyPy versions etc?
YannickJadoul has quit [Quit: Leaving]
jvesely has joined #pypy
<mattip_>
YannickJadoul (fo the logs): the time to tag me might have been when it was *not* working, but sure, I am mattip on github
<mjacob>
energizer: ok, that with dependent types, please ;)
<ammar2>
I thought you said "lisp semantics"
<ammar2>
which lisp implementation do you know that has dependent types?
<mjacob>
ammar2: i'm not aware of any
jvesely has quit [Quit: jvesely]
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
jvesely has joined #pypy
<mattip_>
tos9: great that github actions will support newer pypy, thanx
jvesely has quit [Client Quit]
<tos9>
yup yup
jvesely has joined #pypy
oberstet_ has quit [Remote host closed the connection]
<mattip_>
now if I could figure out when to use github actions and not azure/travis/circleci/appveyor
<kenaan>
antocuni hpy 87553600e78a /: introduce a new decorator @llhelper_can_raise and use it to fix test_exception
<kenaan>
antocuni hpy 5c9a3fd99fc7 /pypy/module/hpy_universal/interp_hpy.py: remove the error argument from @apifunc. It was unused and we decided to use a different approach for exceptions anyway
xcm has quit [Remote host closed the connection]
Niko31 has joined #pypy
xcm has joined #pypy
<Niko31>
Hi, 1) There is any comparison between pypy2 and pypy3 (speed comparison)? 2) Moreover isaw that pypy 7.2 include a big change within the json module, that included on pypy3, 3) pypy3 (3.6) includes all the features of cpython3.6? Thank you very much!
<mattip_>
1) not really 2) yes, it is in both 3) there are a few missing corner cases, but not ones that normal people should notice