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
dmalcolm has quit [Read error: Connection reset by peer]
dmalcolm_ has joined #pypy
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
<mattip>
gracinet: a user started a MR from the py3.6 branch, but it should have been off default instead
<arigo>
gracinet: the problem is 0f8f2a20a7bd (in pypy/pypy), which accidentally caused a merge of py3.6 into default
<mattip>
they retargeted the two-line change to be off default, and I merged it via the web ui, so I didn;t notice
<mattip>
that it merged 3.6 into default
<mattip>
so I merged that changeset into default in dc01a8045170 while accepting only the old files
<mattip>
now when ronan merged default back to py3.6 it didn't work correctly
<arigo>
because py3.6 is still somehow in the ancestors of default, which it shouldn't be
<arigo>
is the correct solution to "prune" the bogus merge with evolve, and leave all more recent commits to be rebase-evolved?
BPL has joined #pypy
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
<gracinet>
I see
<gracinet>
arigo, mattip: you can't prune 0f8f2a20a7bd because it's public
<gracinet>
what I try in order to make the merge back into py3.6 succeed would be something like merging the `default` parent of 0f8f2a20a7bd (the bogus merge commit), and then grafting subsequent commits from the default branch. Maybe you want also to revert some of the changes done by the merge in default, and of course not graft that back into py3.6.
<gracinet>
From there, py3.6 would not be an ancestor of default any more, and subsequent merges default -> py3.6 should be ok but will have to be checked carefully
<gracinet>
saying all this probably too quickly, really needs verification
<gracinet>
for the record, there's an Heptapod ticket about this kind of things, let me look it up…
<gracinet>
about the recovery actions arigo, mattip: you'll have to be very careful that a subsequent merge in the py3.6 branch does not bring back any revert of py3.6 stuff done in the default branch
<gracinet>
I don't know a very satisfying way to do that.
lritter has joined #pypy
CrazyPython has joined #pypy
<ronan>
gracinet: yes, that's the main issue. Ideally we would just remove the bad merge from the history.
<mattip>
gracinet: I originally tried to close the HEAD of default and made a blank commit on HEAD~1 in order to restart the branch
<mattip>
but hg didn't like it when I tried to push that to heptapod: it claimed there were two heads on default
<mattip>
s/on HEAD~1/ on a commit before the bad merge/
<catern>
ah. I forgot a py3.7 feature i turned out to actually use, from __future__ import annotations. is that not supported on the py3.7 branch yet?
dddddd has joined #pypy
<cfbolz>
catern: it should be. running into problems?
<catern>
the import evaluates fine, but I'm getting NameErrors for things I use in annotations before their definition
<catern>
(that is to say, the annotations import seems to be having no effect)
<catern>
uh, hm, let me investigate a little more
<catern>
it works when I reduce it down to a reproducer...
<catern>
aha, got it, it fails when an *async* function defines a return type
<catern>
i.e. this fails:
<catern>
async def foo(x) -> Foobar: pass
<catern>
(with Foobar not already defined in the file, and with "from __future__ import annotations" at start of file, of course)
jacob22 has joined #pypy
<gracinet>
mattip: that's an interesting approach. Did you try to force-push ?
<gracinet>
There's a server-side hard protection against multiple heads, but sometimes, the earlier checks involving the client are the only one complaining, and the hard server-side protection would actually accept
<cfbolz>
catern: that sounds like a bug
<cfbolz>
catern: would you file an issue? I'll try to take a look soonish
<mattip>
gracinet: after doing so much damage I was afraid to do more.
KindTwo has joined #pypy
<gracinet>
mattip: unless I'd lift the server side protection (always turned out to be right in my experience), it's not really risky
<cfbolz>
catern: great, thanks for tracking it down!
<ronan>
locally, pruning the bad commits works fine (after hg phase -fd 0f8f2a20a7bd), but I guess heptapod won't accept it
CrazyPython has quit [Ping timeout: 258 seconds]
<gracinet>
ronan: no it won't. That's the point of the phase thing, you have to assume it's been distributed already
<gracinet>
A notable exception has been the PR import from Bitbucket, there was no other choice, but that was acceptable only because it's forcing phase onto changesets from forks, instead of from the main repo
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
thrnciar has quit [Ping timeout: 256 seconds]
<ronan>
public changesets are a PITA, I wonder if we could keep everything draft, except for releases
<ronan>
I wish we could strip commits, like on bitbucket
<ronan>
but I guess the only way is to dummy-merge back to py3.6 and hope that fixes the merge logic
omry has quit [Remote host closed the connection]
omry has joined #pypy
omry has quit [Remote host closed the connection]
omry has joined #pypy
Dejan has joined #pypy
Dejan has joined #pypy
Dejan has quit [Changing host]
thrnciar has joined #pypy
<mattip>
ronan: thanks
<ronan>
merges seem to be fixed. Fingers crossed!
CrazyPython has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
thrnciar has quit [Remote host closed the connection]
thrnciar has joined #pypy
NinaAgdal has joined #pypy
NinaAgdal has quit [Client Quit]
<ronan>
hg bisect is a bit broken though
<arigo>
I must say it doesn't look like a good situation as long as 'ancestors(default)' contains py3.6
<arigo>
I'm going to try a 'hg push' now
<arigo>
yes, it worked
<arigo>
wait a second now, I have to restore the commits done since then
<ronan>
arigo: how did you manage that? I tried it but couldn't push
<arigo>
it works if you close one head
<ronan>
I did that...
<arigo>
and then I did "hg push -f", but I'm not 100% the "-f" was needed
<ronan>
ah, it's probably the -f
<arigo>
I tried with "-f" without closing one head first, and indeed got a (different) message saying the server was unhappy
<arigo>
OK, I've pushed again the 4 changesets on "default" on top of that new head
<arigo>
you merged default into py3.6, which is probably fine
<arigo>
meh, no, now "hg merge default" have many conflicts
<arigo>
I'll try to fix that...
<ronan>
yeah, I guess hg will be confused if we don't rebase everything on top of cf48663ad7f8
<arigo>
guess so
<arigo>
fixed py3.6, py3.7 still broken
<arigo>
OK, "hg heads -r 0f8f2a20a7bd" is now empty (this lists only open heads)
<ronan>
great, thank you!
<arigo>
merging default -> py3.6 still shows a few conflicts, I fear you'll have to redo the most recent merge
<arigo>
namely 154b571e530e
<arigo>
which I didn't try to "hg graft" because, argh, grafting a merge?
<arigo>
same with 2e2b52fefdee for py3.6 -> py3.7
<arigo>
in any case, anyone who pulled and updated very recently needs to be careful when he pulls again, not to get himself stuck in the closed heads
CrazyPython has joined #pypy
<ronan>
merges done
<ronan>
arigo: I thought hg update moved to the most recent head?
<arigo>
it doesn't jump to a different topological branch, but at least it gives a warning in this case
<arigo>
however, IMPORTANT: if you make a change on default/py3.6/py3.7, then "hg pull", then "hg merge": careful! This will happily merge your local head with the new official head, and you'll reintroduce the bad commit 0f8f2a20a7bd in the history
<arigo>
(assuming of course you made a change on top of the bad commit, then committed it, and then "hg pull" "hg merge"
<arigo>
)
jacob22 has quit [Read error: Connection reset by peer]
inhahe has quit [Read error: Connection reset by peer]
inhahe has joined #pypy
jacob22 has joined #pypy
<arigo>
test_whatsnew.py doesn't check that the bad merge occurs now in a place from which only closed heads are reachable, but I guess I won't try to "improve" the already-quite-complicated "-r" argument here
Dejan has quit [Quit: Leaving]
thrnciar has quit [Ping timeout: 272 seconds]
KindTwo is now known as KindOne
jvesely has quit [Remote host closed the connection]
jvesely has joined #pypy
oberstet has quit [Remote host closed the connection]
ionelmc has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
thrnciar has joined #pypy
tsaka_ has joined #pypy
tsaka__ has quit [Ping timeout: 240 seconds]
Anastasia has joined #pypy
Anastasia has quit [Client Quit]
BPL has quit [Quit: Leaving]
<YannickJadoul>
Does someone know more about Windows/MSVC and setuptools/distutils?