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)"
<LarstiQ>
Hotpot33: pypy has well over a decade of development, for years has been much more mature than pyston/unladen swallow ever were, and is having good progress recently on the scientific stack and python3.5 compatibility
<LarstiQ>
I'd be quite confident running pypy in production (after testing it makes sense for your particular workload)
<LarstiQ>
Hotpot33: on the other hand, more help is always welcome
<Hotpot33>
oh I see
<LarstiQ>
Hotpot33: oh, and rpython is used by quite a number of other languages as well
<bremner>
is there a writeup somewhere of the various scientific stack projects in progress?
<tumbleweed>
I can request increases (and have) but that's always going to be slow and involve discussion. Getting pypy better at showing progress, even when thrashing like mad, would help
oberstet has joined #pypy
<runciter>
hm
<runciter>
i now have a computer that's capable of building pypy
tbodt has joined #pypy
tbodt has quit [Ping timeout: 248 seconds]
jacob22__ has quit [Ping timeout: 240 seconds]
<kenaan>
fijal unicode-utf8 55238fb1d18a /pypy/objspace/std/: use iterator for islower
traverseda has joined #pypy
<arigato>
tumbleweed: well, the situation you describe only occurs on Mips
<arigato>
I am rather unsure that anyone needs pypy on mips, but well, I would be satisfied with "they get the last version that compiled, even if it's a bit older"
<arigato>
imho
<arigato>
imho too, the most reasonable pypy installation on mips or alpha or hppa or sparc is: "ln -s python pypy"
Nizumzen has quit [Ping timeout: 258 seconds]
tbodt has joined #pypy
<tumbleweed>
arigato: it has been an issue on other archs too
<tumbleweed>
but really, things are much easier for us in debian when we have pypy everywhere
<tumbleweed>
(whether or not it's particularly useful)
mattip has joined #pypy
<arigato>
tumbleweed: yes, I understand, that's why I suggested "ln -s python pypy" as a way to have ``pypy'' everywhere
<tumbleweed>
that won't work
<tumbleweed>
it would have to be configured to put things in the same places as pypy
<tumbleweed>
pypy works just fine on mips - the issue here is buildds with not enough ram
<arigato>
no, I mean, add a dependency on the regular cpython on these arches
<tumbleweed>
oh, we do that
<arigato>
and put only a couple of symlinks inside the "pypy" package
<tumbleweed>
I think that's going to be quite complex, actually
<tumbleweed>
getting pypy built on mips isn't proving impossible, just slow
tav has joined #pypy
<arigato>
*shrug*
<arigato>
a quick hack would be thread.start_new_thread(f) where f prints a dot every 10 seconds
<tumbleweed>
yeah
<tumbleweed>
I'm going to try to do something better than that
<arigato>
better only in mot sense of the word; it's worse in that it prevents pypy 5.9 from showing up on platforms where 99% of people are
<arigato>
s/mot/most
<arigato>
there was a very rare issue recently, where a loop over a dictionary was potentially infinite depending on dict ordering
<arigato>
it was a top-level loop in the annotation phase
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<arigato>
so what I mean is that if you add "print dot" in the top-level loop of the annotation phase, then you risk not doing anything better than "print a dot every 10 seconds anyway"
zmt00 has joined #pypy
<arigato>
much saner to disable the output check (or work around it with printing a dot every 10 seconds), but having an absolute time bound
Nizumzen has joined #pypy
<arigato>
which can be done simply by printing every minute "keepalive, %d minutes left" downwards until 0, and then not printing anything anymore
Nizumzen has quit [Client Quit]
Nizumzen has joined #pypy
jamesaxl has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
<tumbleweed>
arigato: that makes sense
<dddddd>
Excuse me, tumbleweed, Lacking a RPython package (I think there's an open bug about it), which is the recommended way to get it on Debian? I came up with [0]. What do you think? [0] See "Dependencies" at https://notabug.org/deesix/z80jit
jamesaxl has quit [Read error: Connection reset by peer]
<fijal>
dddddd: you can pip install rpython, these days
jamesaxl has joined #pypy
<tumbleweed>
dddddd: we should have an rpython package, yes
<dddddd>
fijal, I'll keep that in mind too, thanks.
drolando has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dddddd>
Anyway, I don't like to use extra package managers that much.
drolando has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nunatak has joined #pypy
asmeurer_ has quit [Ping timeout: 240 seconds]
drolando has joined #pypy
<dddddd>
How rpython version numbering works? I'm a bit surprised seeing 0.2.1 in pip? (I'm trying to compare it, let's say, with the one in the debian pypy source-package)
<dddddd>
*in pip (no question mark there, sorry)
<fijal>
it has no relation to pypy versioning at all
<dddddd>
rpython --version doesn't seems to exists, and --help does not give any version number.
<fijal>
indeed, that seems like a bug
<fijal>
dddddd: file a bug report?
<fijal>
please :)
<dddddd>
It seems to be some support to extract the version from hg or git indeed.
<dddddd>
(I don't know if pypy or rpython version)
<dddddd>
Tried rpython/tool/version.py from inside the Mercurial repo and it's not going to return x.y.z anyway, but something like ('default', '9dad012e168e')
<fijal>
dddddd: that's the repo version
<fijal>
dddddd: anyway, why do you need that?
<fijal>
(commit ID that is)
<dddddd>
Sure it is. I like to know the rpython version.
<fijal>
dddddd: create a bug report and we'll add an API :)
<dddddd>
I don't have a bitbucket account, nor need an API, just to map some tree of code with it's version. I guess you're not really versioning rpython in the tree (which it's fine given the close pypy-rpython relation, I guess)
<dddddd>
*its version
<fijal>
right then ('default', '9dad012e168e') is a thing you want I guess?
<arigato>
you either want an API, or you are happy with whatever internal functions like this one returns, right?
<dddddd>
Thw question is... how can I compare that pip (0.2.1) with some other rpython (say pypy 2.6.0)
<fijal>
you cannot
<fijal>
the pypy versions don't have a branded rpython
<dddddd>
Where comes from the 0.2.1 then?
<fijal>
pypy version is irrelevant
<fijal>
it's a bit like asking which GCC version is python 3.5 compiled with
<fijal>
you can (sometimes) use more than one
<fijal>
('default', '9dad012e168e')
<fijal>
is as good as it gets
<fijal>
0.2.1 is something we added to pip because pip asks it
jcea has quit [Remote host closed the connection]
<arigato>
we could still try to give it a number like "5.9" that matches the pypy version
jcea has joined #pypy
<arigato>
just because there is no reason *not* to do that
<dddddd>
Using that analogy, I want to know the gcc version (indepently of pypy, python or some another program).
<arigato>
there is no official way, that's why fijal suggested to open an issue and we'll add one
<mattip>
njs: ping
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
slacky has joined #pypy
traverseda has quit [Remote host closed the connection]
<mattip>
discussion on numpy about deprecation / non-deprecation of PyPy incompatible UPDATEIFCOPY semantics
<mattip>
does anyone remember where in CPython docs they say "don't do too much in a deallocator"?
slacky has quit [Ping timeout: 268 seconds]
Demon111 has joined #pypy
jamesaxl has quit [Quit: WeeChat 1.9.1]
lesshaste has quit [Quit: Leaving]
<Demon111>
mattip: I figured out the debug issue we talked about yesterday
<mattip>
Demon111: nice, care to share?
<Demon111>
mattip: the "debug" kwarg never makes it into build_ext(), the only way it works is by using "-g" as a command line argument to setup.py. this also makes the distutils try to link python27_d ... which is an unwanted side effect requiring me to fake that file
<mattip>
none of the CFLAGS or extra_compile_args suggestions helped?
<arigato>
mattip: maybe you have in mind the Cython docs, that do say that
<Demon111>
I'm not sure I tried all of them, but looking at the code in distutils, it pulls the debug args from the command line before linking
<mattip>
arigato: thanks
tbodt has joined #pypy
<mattip>
link?
<arigato>
<Demon111> I'm not sure I tried all of them, but looking at the code in distutils, it pulls the debug args from the command line before linking
<arigato>
Demon111: sorry about that, it was a copy-paste mistake
<mattip>
Demon111: it seems like the side effects are not so nice, is this for general consumption or just for you?
<Demon111>
well, it's for an internal tool
altendky has quit [*.net *.split]
dustinm has quit [*.net *.split]
dpn` has quit [*.net *.split]
agronholm has quit [*.net *.split]
bremner has quit [*.net *.split]
ColdHeat has quit [*.net *.split]
dw has quit [*.net *.split]
drolando has quit [*.net *.split]
nunatak has quit [*.net *.split]
commandoline has quit [*.net *.split]
pulkitg has quit [*.net *.split]
bendlas has quit [*.net *.split]
_habnabit has quit [*.net *.split]
tmarkovich has quit [*.net *.split]
cfbolz has quit [*.net *.split]
<Demon111>
can you double check this? in build_ext.py the call to link_shared_object() passed debug from self.debug, and that comes from get_option_dict() and so forth...
huonw has quit [Ping timeout: 252 seconds]
<Demon111>
I initially built this with VS and passed the extra debug args through extra_args... and distutils doesn't make the linker strip the symbols because that's not how it works in VS
<Demon111>
anyway, if this is the only way I'll just have setup.py fake the python dll