<Julian>
I had a few hours this morning to tinker, so at least things function on a basic level I believe now
<Julian>
there's one key issue left which is right now I'm only tagging the HEAD commit, when really it needs to loop over `git rev-list` (i.e. tag all commits on the branch that it sees, not just the tip)
<Guest3159>
Julian: why does it need to do the loop?
Guest3159 is now known as LarstiQ
LarstiQ is now known as Guest5577
<Julian>
Guest5577: because if you push 5 commits at once only commit #5 will get noted
<Julian>
so in theory it doesn't I suppose, you can calculate that later when you read the value, but it seems a bit easier to use if you can just assume every commit is tagged
<Julian>
(but I guess that's up to anyone who wants to use this on what their expectations are, I'm no named branch expert)
<Julian>
gone for lunch, but back later
Julian has quit [Quit: leaving]
Julian has joined #pypy
ronan__ is now known as ronan
<mattip>
arigato: I tried closing and pushing, it doesn't work
<marmoute>
mattip: what's the matter ?
Julian has quit [Ping timeout: 252 seconds]
<mattip>
marmoute: we changes someting in the server config to allow developers to push named branches
<mattip>
but it ended up making all commits not published, so we tried to revert the change
<mattip>
and now there are three commits that aparently used to be topic branches, but are now published heads of default
<mattip>
so if I do "hg push" it fails with "abort: push creates new remote head"
* mattip
off for a bit, sorry
<marmoute>
And you need these extra heads to no longer be in the way, right ?
<mattip>
yes please
<mattip>
but I have broken the repo so much now I am afraid to do anything
<mattip>
the commits are 6a46d28780d8 04a0975fc60f 40992405546
Julian has joined #pypy
<mattip>
hey Julian
<mattip>
thanks for the fixes, I will look at it later on
<mattip>
having all the commits marked would be nice
<marmoute>
mattip: what do you want to do with these extra 3 heads ? simply "close" them and forgot they are even there ?
Guest5577 is now known as LarstiQ
<mattip>
marmoute: I think so. They are abandoned topic branches
LarstiQ has joined #pypy
LarstiQ has quit [Changing host]
<mattip>
and can be redone if needed
<marmoute>
mattip: okay, I assume I can directly touch the repo, right ?
Julian has quit [Ping timeout: 258 seconds]
Julian has joined #pypy
<mattip>
marmoute: sure
Julian has quit [Ping timeout: 258 seconds]
Julian has joined #pypy
<Julian>
mattip: perfect
antocuni_ is now known as antocuni
Julian has quit [Ping timeout: 258 seconds]
<marmoute>
okay, I'll try to have a look this afternoon
Julian has joined #pypy
Julian has quit [Quit: leaving]
_whitelogger has joined #pypy
stkrdknmibalz has quit [Quit: WeeChat 3.0.1]
stkrdknmibalz has joined #pypy
catern- is now known as catern
fotis has joined #pypy
fotis has quit [Ping timeout: 252 seconds]
<marmoute>
mattip: remote: added 3 changesets with 0 changes to 0 files (-3 heads)
<ronan>
marmoute: remote: rejecting multiple heads on branch "py3.6"
<marmoute>
ronan: so you need the other branches fixed too, right ?
<ronan>
yes, I guess
<ronan>
I'm wondering how to figure out which heads need to be closed
<marmoute>
3 py3.6
<marmoute>
2 release-pypy2.7-v7.x
<marmoute>
2 py3.7-big-sur-dyld-cache
<marmoute>
2 py3.7
<marmoute>
You can check which one had a topic previously
fotis has joined #pypy
Julian has joined #pypy
<ronan>
marmoute: how?
<marmoute>
simplest is probably `hg log --debug` on these changeset
Julian has quit [Quit: leaving]
fotis has quit [Ping timeout: 245 seconds]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
fotis has joined #pypy
fotis has quit [Ping timeout: 258 seconds]
greedom has joined #pypy
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
fotis has joined #pypy
fotis has quit [Ping timeout: 256 seconds]
fotis has joined #pypy
greedom has quit [Remote host closed the connection]
fotis has quit [Ping timeout: 258 seconds]
<smarr>
Are there specific conditions around using `range()` for C-style `for` loops? I am seeing after some code changes that the range object didn't get compiled out, and it leads to residual `+304: i18 = getfield_gc_i(p2, descr=<FieldS range.next 8>)` in the trace.
fotis has joined #pypy
fotis has quit [Ping timeout: 240 seconds]
fotis has joined #pypy
fotis has quit [Ping timeout: 240 seconds]
fotis has joined #pypy
<smarr>
another issues I am currently running into is that some interpreter optimizations aren't great for jit-compiled performance. For instance, i got now a loop counter that is stored in a frame that outlives the trace, which it previously didn't. I can get rid of some of the drawbacks in the compiled code by using we_are_jitted(): and nil out the store. Though, there's still a cost in the interpreter.
<smarr>
not sure how else to communicate that the lifetime of the store is restricted to a scope
fotis has quit [Ping timeout: 272 seconds]
<smarr>
in case anyone has suggestions, I am reading the logs. thanks