cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<arigato>
cfbolz: I assume you checked that the JIT produces the same optimized traces?
<cfbolz>
arigato: yes
<arigato>
cool
<cfbolz>
arigato: which reminded me how strange those traces sometimes get ;-)
<arigato>
:-
<arigato>
)
<arigato>
def frontend_tag_overflow() is no longer needed in opencoder.py
<arigato>
self.history.trace_tag_overflow() should be checked more systematically: at least before any self.history.trace.done()
<arigato>
(otherwise, you get a trace with a broken v = 0 in them but you're still using that trace)
<cfbolz>
arigato: right
<cfbolz>
arigato: indeed, it's a bit of a dangerous interface
<cfbolz>
(not that raising exceptions randomly in the middle of any code is that much better)
<cfbolz>
arigato: maybe done should itself assert that the tags didn't overflow?
<arigato>
yes, well, that's an assertion waiting to fail
<arigato>
the safest would be to raise the SwitchToBlackhole from done()
<cfbolz>
pfff, are we sure enough this is safe?
<arigato>
no, but at least that's only 3 places to check
<cfbolz>
arigato: honestly, I'd rather have an assert failure than what we had now, randomly misbehaving by jumping to the blackhole from an inconsistent state
<arigato>
right
<arigato>
ok
<arigato>
note that blackhole_if_trace_too_long also calls history.trace.done(), for some reason
<cfbolz>
yes, I am running into that
<cfbolz>
and I can't add an argument done(abandoned_trace=True) either, because done is shared with TraceIterator :-(
<arigato>
:-(
<arigato>
why that it so, I have no clue
<cfbolz>
I'll try to fix that, it sounds silly
<cfbolz>
arigato: if I fix that, you think the branch looks ok?
<cfbolz>
also, do you have an opinion whether I should rip out green fields completely, or leave them disabled?
<arigato>
cfbolz: I don't know about greenfields, better leave them in but with an assert that fails if you use them, then people with 3rd-party jitdrivers can either remove the assert or adapt their code
<cfbolz>
arigato: yes, works for me
<cfbolz>
(that's what I did, actually)
<arigato>
of course, the day we need to maintain some code (e.g. virtualizables) and run into some greenfield-specific hack, better kill it
<cfbolz>
+1
<fijal>
cfbolz: please merge
<fijal>
I'm a bit sick
<cfbolz>
ok
<cfbolz>
fijal: get better soon!
pf_moore has joined #pypy
<mattip>
there is a new failure with the numpy test suite, a subclass of ndarray (maskedarray) is somehow losing an attribute it should have
<cfbolz>
mattip: related to anto's branch?
<mattip>
adding a gc.collect() "fixes" the test, so I suspect a refcount issue introduced lately?
<mattip>
maybe, I will try to bisect now
<antocuni>
mattip: that test if flaky
<antocuni>
if you run it enough times, you can see it failing even on default before I merged my branch
<mattip>
antocuni: are we talking about the same one - test_shuffle_masked ?
<antocuni>
if you look at the test, it looks weird: it does the same operation 50 times: if you increase the 50, it becomes more likely to fail
<antocuni>
mattip: I think so
energizer has joined #pypy
<mattip>
that test has a loop of 50 indeed
<antocuni>
I also saw it when running tests on my branch; but then I saw it was occasionally failing also on default, so I declared that it was not a fault of the branch and merded :). Didn't investigate further, though
<cfbolz>
arigato: ah, note that in theory we can call tracing_done several times on the same trace, when compile_loop doesn't compile a tarket_token, then we just keep tracing
<arigato>
right
<arigato>
is it a good idea to free these caches then?
<cfbolz>
"who knows"
<cfbolz>
continuing tracing should be a rare situation, of course
<cfbolz>
things keep working fine if the caches are killed, we just use more tag bits
<simpson>
I did have code at one point to support Linux perf JIT maps, using the hooks to write out the map, but I think that that code must have rotted.
<kenaan>
cfbolz default ac140c11bea3 /: merge fix-sre-problems: - stop switching to the blackhole interpreter in random places, which leads to arbitrar...
illume has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
inad923 has joined #pypy
marky1991 has quit [Ping timeout: 246 seconds]
marky1991 has joined #pypy
inad923 has quit [Ping timeout: 240 seconds]
<mattip>
cfbolz: thanks for the quick work
<mattip>
we are close to a new release IMO
mcyprian has joined #pypy
illume has joined #pypy
<cfbolz>
mattip: cheers
<cfbolz>
mattip: actually I have two more small branches I'd like to merge but I'd like to wait till tomorrow to see whether there is any fallout
<mattip>
ok. I am searching for a cpyext issue,
<mattip>
errors after a random number of times through a loop make me suspect refcount is off somewhere, it happens even with JIT off
ielectric has joined #pypy
<cfbolz>
mattip: no fun :-(
abecker has joined #pypy
inad923 has joined #pypy
<mattip>
it seems I can pinpoint the line in cythonized code where the error occurs (printing is still my favorite debug method)
abecker has quit [Client Quit]
igitoor has quit [Ping timeout: 246 seconds]
<antocuni>
mattip: if this is an issue which started to show up only recently, it might be worth trying with different versions of cython
<mattip>
antocuni: good point
mcyprian has left #pypy [#pypy]
inad923 has quit [Ping timeout: 240 seconds]
inad923 has joined #pypy
planrich has quit [Ping timeout: 256 seconds]
inad923 has quit [Ping timeout: 240 seconds]
igitoor has joined #pypy
jredondo__ has quit [Read error: Connection reset by peer]
<tumbleweed>
mattip: ensurepip is disabled for good reason. nobody should need it
igitoor has quit [Changing host]
igitoor has joined #pypy
<arigato>
tumbleweed: what should we recommend people to use, then, if "pypy -m ensurepip" doesn't work because of their distribution-mangled version of pypy?
<tumbleweed>
use a virtualenv
<tumbleweed>
ensurepip would be modifying your debian package-installed pypy, that's kind of a no-go
<tumbleweed>
if you create a virtulaenv, it'll have pip
stduolc has quit [Quit: Connection closed for inactivity]
ielectric is now known as domenkozar
<arigato>
ah, ok
mattip_ has joined #pypy
<mattip_>
tumbleweed: hi. doesn’t calling the pypy a debian-installed package imply people can “apt install pypy-numpy”, etc?
marky1991 has quit [Ping timeout: 264 seconds]
<bremner>
I don't understand the question.
<bremner>
are you saying debian shouldn't package things unless they package every possible piece of software that works with it?
<bremner>
fsvo works.
mattip_ has quit [Remote host closed the connection]
<cfbolz>
tumbleweed: nice, more than I would have thought
<tumbleweed>
switch to sid and there's more
<dstufft>
tumbleweed: I still feel like maybe Debian shouldn't put `python` on $PATH :P
<tumbleweed>
we should probably add support for pip, and that would solve the issue that got us into this conversation
<dstufft>
ALL YOU GET IS VIRTUALENV
<cfbolz>
tumbleweed: that would be awesome
<tumbleweed>
dstufft: yeah, the "system-python" is a very different way of thinking about things. I do see the merit of it
<tumbleweed>
there are also people who rely on our packaged modules for their local apps
cjwelborn has quit [Ping timeout: 240 seconds]
marky1991 has joined #pypy
mattip_ has joined #pypy
<mattip_>
ahh, nice. So I guess the day will come for pypy-numpy
mattip_ has quit [Remote host closed the connection]
marky1991 has quit [Ping timeout: 260 seconds]
asmeurer__ has joined #pypy
planrich has joined #pypy
asmeurer__ has quit [Quit: asmeurer__]
marky1991 has joined #pypy
squeaky_pl has joined #pypy
<squeaky_pl>
for the pypy + pip discussion, portable builds bundle virtualenv so you can just unpack it and run `pypy-x.y.z/bin/virtualenv-pypy whatever`
inad923 has joined #pypy
cjwelborn has joined #pypy
tbodt has joined #pypy
cjwelborn has quit [Ping timeout: 240 seconds]
nunatak has joined #pypy
antocuni has quit [Ping timeout: 245 seconds]
illume has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
raynold has joined #pypy
illume has joined #pypy
agates has joined #pypy
cjwelborn has joined #pypy
Rhy0lite has quit [Quit: Leaving]
jredondo__ has joined #pypy
jredondo__ has quit [Ping timeout: 256 seconds]
asmeurer_ has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]