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
<cfbolz>
the new "metaclass found to be 'list', but calling <type 'list'> with args (name, bases, dict) raised 'list() takes at most 1 argument (3 given)'" type error improvement leads to problems, sometimes
<cfbolz>
specifically if the metaclass is really "type", and we are getting a typeerror because eg "duplicate base class 'BaseB'"
<cfbolz>
should I disable the new error if the metaclass is type?
<arigato>
probably
<cfbolz>
or still worth it, because you get the arguments told
<cfbolz>
(I really like the new error for non-type cases)
<arigato>
I think you get literally "(name, bases, dict)", not the actual arguments passed
<arigato>
if the metaclass is 'type' then it's usually not what you are interested in
<cfbolz>
no no, you get the name and the bases (not the dict):
<kenaan>
cfbolz py3.7 17f00b954798 /pypy/objspace/std/: no reason to not follow cpython exactly
<mattip>
on the benchmark machine, if I set ulimit -v 13000000 (that is ~13GB) it fails, if I set it to 16000000 it passes
lritter has joined #pypy
<cfbolz>
mattip: how much memory does cpython use?
<mattip>
too little to register
<mattip>
less than 1gb
<mattip>
my machine is just under the requirement to run the benchmark
<mattip>
so I will adjust it a bit. Anyway, each of the 50 runs is ~1 sec on cpython, 5 secs with jit off
oberstet has quit [Remote host closed the connection]
<kenaan>
mattip benchmarks[chameleon] 24f7763db60b /unladen_swallow/: update spitfire to master which no longer has psyco nor o4
<kenaan>
mattip benchmarks[chameleon] 09d5bf1ff68d /unladen_swallow/performance/bm_spitfire.py: limit table size to run with <16GB since pypy chews up gb of memory
<cfbolz>
mattip: we should definitely investigate, that sounds like a real problem
<mattip>
well, one fish at a time
<mattip>
it might be something to do with the metaclass templating of spitfire
<cfbolz>
mattip: let's file an issue?
<mattip>
ok
<fijal>
may I complain that python is unusable for anything else than actively using python ever day?
<fijal>
3 year old software generally requires tweaks to run it
<Dejan>
fijal, arguably you are not using it the right way
<fijal>
arguably!
<fijal>
like, using libraries, installing them using pip
<Dejan>
I am not a Python expert (5y of Python coding, 20+ years of coding in general) - if Python application is released in such way that dependencies are frozen, you can using it after 20 years, in theory
<fijal>
writing software based on documentation
<fijal>
right, that is probably the case
<Dejan>
the key is in deps being frozen during the release
<fijal>
but that also means that changing it is a bit hard
<fijal>
because you have to dig 3y old documentation
<Dejan>
true
<Dejan>
but you change legacy code VERY CAREFULY
<fijal>
and you don't get any security updates or bug fixes
<Dejan>
:)
<fijal>
heh
<fijal>
well, I'm sad 3 y old is "legacy"
<fijal>
that is "mostly unsupported"
<Dejan>
that is also true, but that is a problem with ANY language
<Dejan>
in modern world 3 y is really old, yep
<Dejan>
we live in agile age
<Dejan>
speaking about technology
<fijal>
it's much less issue with C
<Dejan>
I downloaded few weeks ago an old version of JavE
<fijal>
arguably because C is much harder to use
<Dejan>
(ASCII editor)
<Dejan>
it was compiled with Java from 20 years ago
<Dejan>
1.4
<Dejan>
and believe it or not, it worked on my Fedora with Java 13
<Dejan>
a GUI application :D
<Dejan>
.jar that was compiled with Java 1.4 20 years ago!
<mattip>
java c, c++ and the win32api work very hard to make that happen
<mattip>
python, javascript, ruby less so
<Dejan>
there is a huge cost to that!
<Dejan>
:)
<Dejan>
that is why changing something in Java takes years