cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
Atque has joined #pypy
derpydoo has joined #pypy
lehmrob has joined #pypy
<arigato> mattip: or just write float.__hash__ to check if it's called on a subclass
jcea has quit [Ping timeout: 260 seconds]
lehmrob has quit [Ping timeout: 268 seconds]
otisolsen70 has joined #pypy
winter6 has joined #pypy
Atque has quit [Ping timeout: 255 seconds]
Atque_ has joined #pypy
winter has quit [Ping timeout: 264 seconds]
winter6 is now known as winter
tazle has joined #pypy
derpydoo has quit [*.net *.split]
ltfish has quit [*.net *.split]
tazle_ has quit [*.net *.split]
Lightsword has quit [*.net *.split]
rb has quit [*.net *.split]
mattip has quit [*.net *.split]
derpydoo has joined #pypy
ltfish has joined #pypy
Lightsword has joined #pypy
rb has joined #pypy
mattip has joined #pypy
derpydoo has quit [Ping timeout: 248 seconds]
<fijal> is pip install sympy supposed to work on pypy? explodes with not being able to find 'Python.h'
<mattip> what version of pypy, how did you install it?
<mattip> if you want to install binary packages and not build form source, conda has packages
<fijal> "pip install betse" - it explodes in weird ways
<fijal> I'm happy to build from source, but I don't understand what's going on
<fijal> so it's weird, because pip install matplotlib expldoes while building numpy wheel
<fijal> ... while numpy is installed just fine, what is going on?
<fijal> like so
<fijal> is it officially supposed to install?
<fijal> this is Mac btw
lehmrob has joined #pypy
Atque_ is now known as Atque
<fijal> ok, I think I got it - matplotlib requires very specific version of numpy, but newer one works
<fijal> eh
<fijal> mattip: I must say I'm very lost why matplotlib insists on 1.21 numpy, where do I nuke caches of that?
<mattip> _building_ matplotlib requires "oldest supported numpy"
<fijal> ok, it's the error in "oldest_supported_numpy" package, it seems
<mattip> but I don't see where 1.21 comes from in oldest-supported-numpy
<mattip> again: I would suggest using conda. All these problems have been worked out there, and binary packages are available
<mattip> we (me and the conda-forge people) put a lot of work into making it work, rather than trying to convince all the PyPI packages in the world to make wheels for PyPy
<fijal> well, yes, sure, but also I would like to be able to build stuff from source
<mattip> ok, but then be prepared for pain
<mattip> also: conda does not yet support arm64 macos, so maybe you would want to build from source
<fijal> well, the packages are outright broken for pypy
<fijal> heh
<fijal> I'm glad I have a ready to use excuse that I don't need to manufacture
<fijal> I'm not sure "use conda" is a good excuse for having a build chain that's outright broken
<fijal> for pypy at least
<mattip> it's not an excuse, it is a choice
atomizer has quit [Ping timeout: 255 seconds]
<fijal> to not fix matplotlib or scipy?
<mattip> with limited resources, it is easier to get conda-forge cooperation than to try to get all the packages to build wheels
<mattip> or run pypy in their CI when it runs 4x slower
<mattip> and breaks too often
<fijal> we are talking about completely different topics
<fijal> like, is building from source on pypy outright unsupported?
<mattip> no. it is just slightly broken
<mattip> but that "slightly" is different for each repo
<fijal> ok, so how is it built on conda?
atomizer has joined #pypy
<fijal> like someone goes and manually edits the source?
<fijal> presumably there are patches that make it work no?
<mattip> for one thing,conda does not try to pin numpy to 1.21
<mattip> but again, it is a choice where to focus resources. I cannot sit and debug every build on every platform
<mattip> so I try to get CI to do the work for me
<fijal> sure, but I'm failing to understand
<mattip> on conda that method works, elsewhere less so
<fijal> matplotlib (and scipy), the building from source does not work
<fijal> how do you build from source for conda? do you patch the source? can I have those patches?
<mattip> remove the pin for oldest-numpy
<mattip> the patches are all in the conda-forge feedstocks and config files
<fijal> that worked for matplotlib, kinda failing for scipy so far
<fijal> I don't think you are selling me the platform that a) does not work on my machine b) is run by a corporation that I don't have a good opinion of
<arigato> fijal: I think you're behaving like an end user that wants things to work on his platform and doesn't care that it would take a lot of resources to make that
<fijal> I'm very perplexed why building from source is an abandoned idea, I think
<fijal> my platform being "pypy" or "mac m1"?
<arigato> I agree that it's a sad state that building from source is relegated into the background now that everybody expects wheels
<fijal> well, the wheels don't work
<fijal> clearly
<fijal> so, one option is of course "pip does not work on pypy + numpy ecosystem", maybe that's an answer
<fijal> I don't know, I would be sympathetic to "matplotlib maintainers don't respond to my emails" I guess?
<arigato> I have no solution, just saying that I agree that the situation is sad
<arigato> (not blaming mattip here, in case that could be interpreted that way)
<fijal> I don't think I have answers either, it just seems that abandoning "building from source" without even trying to disable it somehow is a bit weird to me
<fijal> pressing the up arrow in pdb freezez my terminal
<fijal> I'm probably going to give up on trying to use pypy here, looks hopeless
<arigato> note that mattip may have more insentive to help you if you would explain why you can't just use the conda packages
<fijal> arigato: he gave me one reason, which is that it does not work on my mac
<fijal> (I suspect I can get it going in x86 simulator, but that sounds like yet-another-dependency-hell)
Atque has quit [Ping timeout: 255 seconds]
<arigato> ah ok, right, sorry
<mattip> conda-forge is not anaconda, they use ananconda infrastructure but you do not need any license even for $$ work
<mattip> and I would be happy to support m1 builds, but cross-compiling does not yet work
<mattip> with pypy, it is too slow
Atque has joined #pypy
<mattip> so maybe you should be upset with Apple for making a proprietary platform with no available CI support?
<fijal> that I'm certainly upset about :-)
<fijal> it has been an issue for a very long time
<fijal> mattip: so not sure if there is any info for you there, but I'm giving up. There seems to be way too many bugs on the way to even assess if pypy will be faster (probably not because of heavy use of numpy)
<fijal> 1. the up-arrow in pdb crashes the terminal
<fijal> 2. something in contextvars loops infinitely
<fijal> I can show you the traceback for the second one, if you care
<mattip> sure, open an issue on heptapod
<mattip> btw, this sounds like some other peoples' experiences, for instance
<fijal> I'm not opening an issue - I don't think I have a thing I can reproduce short of "try to run betse"
<mattip> you have a traceback?
<mattip> that would justify an issue
<fijal> mattip: I don't know if it's not progressing or progressing-so-slowly-I-cant-tell
<LarstiQ> mattip: there is but I don't fancy building my own CI on top of that
<LarstiQ> but yeah, a colleague recently turned in their M1 mac because not having native wheels made everything too cumbersome
<mattip> there is this issue about pypy + m1 support on conda-forge
<mattip> m1 is on the roadmap for github, slated for q3 2023 currently, pushed back from 2022
<mattip> for github CI
<Atque> fijal: Is docker an option. I've tried this and it has worked okay on an ARM mac:
<fijal> Atque: yet-another-monster?
<fijal> anyway, I *think* there is no chance to get this project running on pypy in some sensible timeframe
<fijal> nor I believe it would actually be beneficial
<Atque> Yeah, I didn't read much of the backscroll so not 100% sure whatcha trying to do
<mattip> so fwiw, betse's feedstock has a dependency on pyside2, which will never be available for pypy,
<mattip> in other words, the chances of a binary package of betse being made available are quite low
<LarstiQ> didn't ctismer get pyside almost working?
<mattip> that work does not seem to have percolated out to conda-forge. sip still is not building
<mattip> which if I understand correctly is a pre-requisite
<fijal> mattip: I managed to run it, I don't think the dependency is hard?
<fijal> like, not everything works, but that's ok
<fijal> well, that said, as I pointed in the issue, some stuff is not working and I have no clue why
<fijal> and it's a bit hard to debug. I'm sure it's doable, but at this stage, what are the chnaces of it being significantly faster on pypy?
xcm has joined #pypy
Atque has quit [Ping timeout: 255 seconds]
Atque_ has joined #pypy
Atque_ is now known as Atque
otisolsen70 has quit [Ping timeout: 268 seconds]
lehmrob has quit [Quit: Konversation terminated!]
jcea has joined #pypy
derpydoo has joined #pypy
derpydoo has quit [Ping timeout: 252 seconds]
joshszep has joined #pypy
joshszep_ has joined #pypy
joshszep has quit [Ping timeout: 264 seconds]
joshszep_ has quit [Read error: Connection reset by peer]
joshszep has joined #pypy
<joshszep> hello PyPy community! I ask hoping to contribute back to this great project. I'm particular I am interested in helping PyPy reach 3.10 compatibility. Anyways, just wanted to say hi and introduce myself. Cheers!
joshszep_work has joined #pypy
joshszep_work has quit [Quit: Client closed]
joshszep_ has joined #pypy
joshszep has quit [Ping timeout: 248 seconds]
joshszep_ has quit [Read error: Connection reset by peer]
joshszep has joined #pypy
derpydoo has joined #pypy