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
jvesely has quit [Read error: Connection reset by peer]
jvesely_ is now known as jvesely
jvesely has quit [Read error: Connection reset by peer]
thrnciar has quit [Ping timeout: 264 seconds]
<ronan>
Merging from default to py3.6 is completely messed up now
<ronan>
I wonder if we can remove the bad merge?
<arigo>
ronan: I didn't try in this case, but maybe you should be able to fix it like this: merge everything from default before the bad merge, then do a null merge for just the two default revision that are the messing up and reversal
<tos9>
I am trying to figure out if this is "required" behavior or not (the docs or test suite neither mention it if so), but sys.prefix on CPython seems to be realpath'ed, and on PyPy it is not
<arigo>
(by a "null merge" I mean something like "hg merge --tool internal:local")
<arigo>
ronan: yes, but on default, right? now I'm saying we should do it in py3.6
<antocuni>
can't we use mercurial phases to "strip" the problematic changeset?
<arigo>
everything is "public", so no
<arigo>
we could maybe hack the repo on heptapod to kill changesets, but as usual the risk is that someone will push it there again
<arigo>
(at least I think the answer is no?)
<arigo>
(maybe we can "evolve" the bad merge into nothingness?)
<mattip>
tos9: on pypy2.7 or pypy3.6?
<tos9>
mattip: both
<arigo>
well we could certainly close the branch containing the bad merge, and start again from just before (maybe rebasing if there is some work added already)
<ronan>
arigo: +1
<arigo>
i.e. make two heads in the "default" branch, and close one of them
<mattip>
arigo: I tried that but mercurial yelled at me that I was trying to push a new head to default so I got scared and tried the other tactic
<arigo>
right
<ronan>
hmm, maybe it's heptapod that doesn't allow it?
<mattip>
it might have allowed it, but at that point I was hesitant to do more damage
<arigo>
I guess we'd need marmoute's opinion
<arigo>
I have no idea if we could "evolve" the merge commit into a different commit that is no longer a merge, and if nothing will be confused by that
<tos9>
mattip: yeah, notably, they don't say that guarantee, yeah?
<mattip>
could you print sys.base_prefix as well?
<tos9>
mattip: for PyPy{,3} it's /usr/local/Cellar/pypy{,3}/7.3.1_1/libexec
<tos9>
For CPython it's a funny path, /usr/local/opt/python/bin/../Frameworks/Python.framework/Versions/3.7
<tos9>
(which is what I mentioned to Bernat, that even on CPython it doesn't look like it's normalized, at least)
<cfbolz>
antocuni: is it? you mean with push -f? then you also have the risk that somebody else pulled in the meantime and pushes the bad changeset again, no?
<antocuni>
cfbolz: true enough, although you can just reassign "master" to the new fixed commit. If people tries to push the "old" master, they get an error and if they try to merge, then get tons of conflicts
<antocuni>
but indeed, it's more or less equivalent to pushing a new head on default and close the wrong one
BPL has quit [Quit: Leaving]
jvesely has joined #pypy
inhahe has quit [Remote host closed the connection]
inhahe has joined #pypy
thrnciar has joined #pypy
thrnciar has quit [Ping timeout: 240 seconds]
gracinet has joined #pypy
jvesely_ has joined #pypy
jvesely has quit [Ping timeout: 256 seconds]
jvesely_ is now known as jvesely
BPL has joined #pypy
BPL has quit [Remote host closed the connection]
BPL has joined #pypy
oberstet has quit [Remote host closed the connection]
jvesely has quit [Read error: Connection reset by peer]