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
<Hodgestar>
antocuni, mattip: I merged the py3.7 into hpy (as a step towards merging the hpy branch back into py3.7). Hopefully this was the right thing to do.
<antocuni>
is it?
<antocuni>
now, you can no longer merge hpy into py3.6
<Hodgestar>
Oh. :/
<Hodgestar>
Meh. I can try fix.
<antocuni>
I mean, it *might* be what we want
<antocuni>
if 3.7 is stable enough, I am fine to say that pypy's hpy targets 3.7 only
<Hodgestar>
py3.7 also seemed to have some HPy fixes that weren't in the hpy branch, which was a bit odd.
<antocuni>
like what?
<Hodgestar>
Replacing charp2str with constcharp2str in interp_cpy_compat.
<Hodgestar>
Good news is that I didn't actually push the merge yet, so I can still not push it if we like.
<antocuni>
anh was it done in py3.7 instead of the hpy branch?
<antocuni>
I think that hpy should target the "main pypy3 branch", whatever it is
<antocuni>
so the question really is: what is the main pypy3 branch nowadays? 3.6 or 3.7?
<Hodgestar>
The answer seemed to be "both" for a bit?
<antocuni>
I think we periodically merge 3.6 into 3.7, don't we? In that case, hpy will be automatically merged into 3.7 every now and then
<Hodgestar>
I have got too many branches all depending on each other across pypy and hpy. :/
<antocuni>
Hodgestar: I perfectly know the feelings :(
<antocuni>
Hodgestar: !780 looks fine to me
<Hodgestar>
Woot.
<antocuni>
one less branch to go ;)
<Hodgestar>
Once it's merged, do I merge default into py3.6? And then into the hpy branch?
<antocuni>
in theory yes
<antocuni>
in practice, for small changes like this, I often just cherry-pick (transplant in hg terms) the commit into 3.6 or directly in hpy
<Hodgestar>
I have clicked the merge button in hetapod.
jacob22 has joined #pypy
<antocuni>
👍
<Hodgestar>
hg is telling me to use "graft" instead of "transplant". Is that good advice? :)
<antocuni>
I don't know, I always used transplant. No idea what is graft
<mattip>
I had proposed making py3.7 the default python3 branch on the pypy-dev mailing list. There were 3 ersponses ys and one response no
<mattip>
there were 3 responses yes and one response no
<Hodgestar>
antocuni: graft looks more friendly, so I used it (the documentation claims hg will realise that a grafted change has been applied when merging).
<Hodgestar>
mattip: Hmm. I don't want to vote on this one because I am not involved enough in the py3.6 or py3.7 branches.
<antocuni>
me neither
<antocuni>
I am fine with both solutions
<ronan>
mattip: huh? I'm the only one who responded
<ronan>
I don't know if you counted me as a yes or a no. I'm against dropping py3.6, but fine with having py3.7 as the main py3 branch
<Hodgestar>
ronan: I think we already merged hpy into 3.7 once so it's probably not too hard to start merging it into 3.7 more regularly? Unless there is some mercurial thing that gets in the way? (not saying we have to -- just that it seems like the initial merge was already done).
<antocuni>
I am fine to say that hpy targets only the py3.7 branch. As I said, I'm happy to leave the decision to those who work on those branches more actively than me
<ronan>
Hodgestar: the question is whether we merge py3.7 into hpy
<ronan>
which means py3.6 won't get hpy updates any more
* Hodgestar
nods.
<ronan>
I don't mind too much, but we still need to resync everything together if we do that
<Hodgestar>
Maybe we should decouple the two discussions? So decide how (default, py3.6 and py3.7) get merged into each other and then after that we can separately decide what to do with the hpy branch?
<antocuni>
Hodgestar: the MR looks good, I approved it! Thanks
<ronan>
Hodgestar: I don't think we can decouple the discussions
<ronan>
if we don't merge py3.6 to py3.7 any more, then hpy has to be developed on top of py3.7
<Hodgestar>
ronan: Sure, there are some consequences for the hpy branching depending on how the first decision goes. But I think I can live with some extra hpy merging effort that is what is required. My point of view is that hpy is currently an experimental feature and that people who want to try it right now can probably use whichever nightly build we suggest, whether that is py3.6 or py3.7.
<ronan>
the annoying bit is that py3.6 and py3.7 will end up targetting different versions of hpy
<Hodgestar>
ronan: But there are two many possible subsets of merging graphs for me to consider if I have to include the hpy branch but also not vote on the (default, py3.6, py3.7) part of the graph. :)
<Hodgestar>
pypy/hpy is now up to date with hpy/master. Woot!
<Hodgestar>
s/two/too/
<ronan>
nice!
<Hodgestar>
I am off for a bit. The next step is to make my life harder by starting again with the changes needed to get pypy/hpy to work with the new universal packaging.
<antocuni>
Hodgestar: feel free to ask if you need help for that
<Hodgestar>
antocuni: Thanks. I will see how it goes.
<ronan>
I merged default > py3.6 > py3.7
Rhy0lite has joined #pypy
<ronan>
... and py3.6 > hpy > py3.6 > py3.7
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<arigato>
cool (not): cffi doesn't provide wheels for macosx on arm64 because of a *mess*. Now these machines download the wheels for macosx on x86_64!
<arigato>
if this is a blocker, I'll release the next cffi version without *any* wheels at all
<arigato>
and call for help
<arigato>
basically since August I've been fighting wheels for cffi, made two next releases with basically no change in the source
<arigato>
so I'm about to give it up completely myself
<tumbleweed>
does cpython do macos arm64 properly yet?
<arigato>
wrong person to ask
<tumbleweed>
IIRC I think the goal here was to have fat (bi-arch) binaries for cpython
<arigato>
so yes, maybe indeed that's the goal, and the problem here would be that Azure Pipelines builds non-fat wheels
<tumbleweed>
yeah, it seems pip is going down the fat road with the "universal2" machine type for arm64+amd64
<arigato>
if the goal is to name such wheels "universal2", I have no idea why pip on arm64 picks up a wheel called "x86_64"
<tumbleweed>
it is *very* new:
<tumbleweed>
Add a new custom “machine” type “universal2” for “x86_64 and arm64”. This extends the existing support for fat binaries in macOS and the name matches Apple’s name for the new combination.