antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
mattip has left #pypy ["bye"]
marky1991 has quit [Read error: Connection reset by peer]
<ronan>
the failure condition is something like hash(value) % 16 == 3
<arigato>
it's hard to avoid
<arigato>
well in this precise example, I don't understand why it would be called more than once
<arigato>
in general, the dict changing strategy could cause random things to occur
<ronan>
custom __eq__ can only be called from object strategy though, so it's not that random
<arigato>
ok, yes
marr has joined #pypy
antocuni has quit [Ping timeout: 260 seconds]
<arigato>
indeed, it seems to call __eq__ twice iff the hash ends in "3" in hexadecimal
<arigato>
I know why
<arigato>
it's even unclear why CPython doesn't show a similar behaviour
<arigato>
it's because after checking the item at index 3 in the hash table, and finding the answer False, it goes on the next item
<arigato>
but for 3 the formula gives 19, which is again 3
<arigato>
...right, your file actually fails in a similar way on CPython :-)
slackyy has joined #pypy
<arigato>
so no, CPython has the same corner case behavior
<ronan>
yay, bug-for-bug compatibility!
<arigato>
:-)
<arigato>
CPython starts with hash tables of size 8, but we start with hash tables of size 16 (because that costs much less on pypy); so it means CPython shows the bug twice as often as pypy...
jamesaxl has quit [Quit: WeeChat 1.9.1]
<mattip>
speaking of bug-for-bug compatability, it seems macos high sierra has the same issues on cpython as on our buildbot
<arigato>
oooh, yes, that sounds like a terrible idea from the developers of APFS
<fijal>
mattip: I have sierra
<mattip>
I guess we could codify that somehow, how does one detect APFS or high sierra on the test runs?
<arigato>
it looks fine now, but in a few years, we'll have new codepoints showing up in filenames and they won't be storable on their machines
<fijal>
arigato: I think I'm ok with that :-)
<fijal>
arigato: like, new emojis that are not supported for filenames? fine ;-)
<arigato>
until the day someone sends you a file with a new emoji in it and the application crashes
<fijal>
mattip: we can change the test not to create invalid filenames too
<fijal>
arigato: new emoji in filename btw
<fijal>
not in file
<arigato>
yes
<fijal>
how many emojis do you have in your filenames?
<fijal>
I mean I see your point, but still
<fijal>
(also the application already has to handle stuff like out of disk space etc, so it's a valid question to ask for a different filename)
<fijal>
arigato: note that this solves some other problem, which is, how do you present unrenderable filenames?
<fijal>
as '?'
<fijal>
but then how do you know which '?' is which?
<arigato>
well, sure, but I guess I wouldn't be fine if I was a Chinese person with a character in my name that is not yet in Unicode 9.0 but will be in the next one
<fijal>
I don't think that's possible
<fijal>
we're adding to unicode mostly stuff that's emojis or long dead languages
* fijal
looks
<arigato>
I think (but I don't know for sure) that we're adding new characters for existing languages because we discover that two character variants should actually be different
<fijal>
not in 9.0
<fijal>
at least
<Rotonen>
there are also new written languages for spoken-only living languages so those land something new from time to time as well (once a decade?)
<fijal>
yes, something like that
<arigato>
Unicode 10.0 lists "CJK Extension F (7,473 Han characters)"
<arigato>
heh, and the Bitcoin sign
<arigato>
you're sure nobody will feel like using the Bitcoin sign in their documents?
<arigato>
...documents' names?
<fijal>
hahaha
<fijal>
arigato: only if they start putting it on keyboards
<fijal>
also, I would give it.... like 8 more months?
<Rotonen>
touchscreen mobile device -> through the web
<Rotonen>
i suppose that is how the majority gets used, or via apps where :emoticon: autocompletions exist, like chat apps (but increasingly all apps)
<kenaan>
mattip buildbot 0b37e98f8694 /bot2/pypybuildbot/builds.py: use os tools to clean out old virtualenv (untested)
<kenaan>
mattip buildbot be8418f6ed85 /bot2/pypybuildbot/builds.py: use upgraded virtualenv for pypy -A tests, clean out old virtualenv's
* arigato
gets reminded from time to time about the large amount of CPython bugs he opened or discussed:
<arigato>
from time to time they update the Python version it applies to, or somebody new registers for follow-ups
<mattip>
arigato, ronan: those commits 1) clean out old virtualenvs with "rm -rf",
<arigato>
interestingly today I got reminded about a bug on which the last post is me complaining that the issue was already lingering for 7 years
<mattip>
and for pypy -A tests use "pypy -mpip install --upgrade virtualenv" before creating the virtualenv
<mattip>
I tested them on a local buildbot, does it sound reasonable to use them?
<arigato>
mattip: 'rm -rf pypy-env' should it be 'rm -fr pypy-venv' ?
<mattip>
so during the rvmprof import, while running rvmprof.__init__, there is a try, except
<mattip>
and AFAICT an exception is raised, but the ExternalCompilationInfo has already been created
<mattip>
so at the end of the translation rvmprof.c gets added to the Makefile
<arigato>
I don't see which try:except: you're referring to
<arigato>
there is only one inside rlib/rvmprof/*.py and it doesn't seem to be relevant
<mattip>
right, my bad. It is in pypy/modules/_vmprof/__init__.py
<arigato>
ah, but that's not imported by the jit
<mattip>
correct, sorry
<mattip>
so the problem is the JIT should be getting dummy function stubs if withoutmod-_vmprof
slackyy has quit [Ping timeout: 240 seconds]
nunatak has quit [Quit: Leaving]
<arigato>
I don't understand why it's seen
<mattip>
the function __vmprof_eval_vmprof or the c file rvmprof.c ?
<arigato>
even cintf.py
<mattip>
jitlog uses it
zmt00 has quit [Quit: Leaving]
<arigato>
ok, what do you mean by "jitlog"?
<mattip>
grepping
<arigato>
pypy/module/_jitlog, using rpython/rlib/rjitlog? doesn't seem to
adamholm_ has joined #pypy
slackyy has joined #pypy
<mattip>
I remember something in rpython/rlib/jit.py, but lost the thread now
<arigato>
I'll try to translate on Windows with a set_trace inside cintf.py
adamholmberg has quit [Ping timeout: 268 seconds]
<mattip>
yes, I put an xxx and it crashed pretty fast
<mattip>
but now I am back on linux
* mattip
off,
<mattip>
sorry, zzz
mattip has left #pypy ["bye"]
<arigato>
in fact we need to put pdb.set_trace() inside the setup() function; before that function actually runs, the "global_eci" doesn't go anywhere
<arigato>
ok, found it
<arigato>
it's 3e4e9ff62be1, dated november 15
adamholm_ has quit [Read error: Connection reset by peer]
<arigato>
mattip (for the logs): I'd ping anto about it, it seems like it will be a messy fix
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
<kenaan>
arigo default 386b50664e3e /rpython/rlib/rstacklet.py: Untested and hard-to-test, but for symmetry reasons if we don't call start_sampling() here then it means sampling w...
adamholmberg has quit [Read error: No route to host]
<ronan>
arigato: so what should I do about test_vicious_descriptor_nonsense?
<arigato>
ronan: didn't look so far, a sec
<ronan>
well, it's really about the dict issue
<ronan>
should we fix it or not?
oberstet has quit [Ping timeout: 248 seconds]
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
<arigato>
ronan: no, it's not an issue because CPython has the same one, and did have it forever
<arigato>
it's "part of the design"
<ronan>
OK
<ronan>
I'm surprised that the test doesn't fail on CPython
<ronan>
maybe they run the tests with hash randomisation off
<arigato>
uh
<fijal>
ronan: we know it can do what it does and the point of the test is not to segfault
<fijal>
so just accept the fact that it can raise AttributeError I guess?
<ronan>
yeah
<kenaan>
arigo default 1cc101a9ee5a /rpython/rlib/: * Be more careful and let stop_sampling()/start_sampling() be called in code that is not compiled with rvmprof. Th...
<kenaan>
rlamy py3.5 9a354884fd09 /lib-python/3/test/test_descr.py: Prevent test from crashing for an unrelated reason
<arigato>
mattip, antocuni: fixed? or maybe running the slightly poor tests is not enough and I did a typo, in which case I'm sorry
<ronan>
fijal: I'm running out of tests to fix, BTW
<fijal>
ronan: "good"?
<fijal>
ronan: feel like helping me fix the neverending utf8 nightmares?
<ronan>
yes
<fijal>
ronan: cool, I pushed last changes right now