<sthalik>
fijal, i saw your hack about matplotlib. what if -- one was to serialize the data on input, only to deserialize it in embedded cpython at entry points? no leaks, easier impl
<sthalik>
fijal, i haven't gone into embedding cpython yet, but i need it for a c++ project myself. so it's gonna take some time to potentially work on it. so treat it as just an idea
<fijal>
sthalik: matplotlib mostly runs in pypy these dats
<fijal>
days
<fijal>
I had to do like 2 modifications
<fijal>
at least for the inline plots in jupyter notebook
<sthalik>
fijal, thanks. this is great news
<fijal>
mattip will know for sure
<fijal>
but cpyext has gone a long way
<sthalik>
fijal, your module, or community-wise?
<fijal>
the module
antocuni has joined #pypy
<fijal>
the purpose of the module is so the community can do nothing :)
<LarstiQ>
can, or needs to? ;)
<fijal>
LarstiQ: what's the real difference :)
<fijal>
should we make #pypy-philosophy?
<LarstiQ>
fijal: can could be read as "they're not able to do anything because the module disallows it"
<LarstiQ>
hmm, what happened to the pypy wiki?
* LarstiQ
tried to find mattip's cpyext adventures
<LarstiQ>
sthalik: ssh://hg@bitbucket.org/pypy/pypy/wiki for the hg repo backing that
<fijal>
sthalik: not the qt one
<fijal>
sthalik: but the web one already works, I used it
<fijal>
(with plots)
<antocuni>
yeah, I confirm it works. It's as easy as doing 'pypy -m pip install jupyter matplotlib numpy scipy"... it just works :)
<fijal>
the getting-plots-inside-jupyter is a bit of a hassle
<fijal>
but that's also true on cpython on OS X :-)
<antocuni>
fijal: I tried to copy&paste the examples from the website and they worked out of the box
<antocuni>
(on linux)
<fijal>
yes, I think linux is the only first-grade supported platform for numpy
<antocuni>
ah ok
<fijal>
on OS X you're supposed to use anaconda, if you don't
<sthalik>
fijal, inline plots <3
<fijal>
shit explodes
<sthalik>
fijal, i'm more into running a pypy kernel inside a cpython qtconsole
<fijal>
antocuni: its not a pypy probem :)
<fijal>
sthalik: that might work
<sthalik>
i need freetype :|
<sthalik>
and libpgn
<antocuni>
fijal: "good" :)
arigato has joined #pypy
<kenaan>
arigo default 6bfa05038883 /pypy/doc/cpython_differences.rst: The issue is even more specific than documented
marr has joined #pypy
<idnar>
in vmprof: megabytes = os.path.getsize(filename) / 1000
<idnar>
but I think getsize returns bytes, so that's actually kilobytes, not megabytes
<idnar>
(I was confused why I was getting the warning on a ~40MB profile)
<sthalik>
noob question, why do you "warm up" with mandelbrot?
<fijal>
sthalik: just a progres bar
<fijal>
beats the standard .
<sthalik>
noob question, why can't cross-compile?
<fijal>
pfff
<fijal>
for bad reasons :)
<fijal>
sthalik: we capture too much of the platform used to compile
<sthalik>
well at least it's not as hard as making Qt5 switch from qmake to cmake for its own build
<cfbolz>
arigato: ah, I see. it used to be the case in cpython and pypy that (lambda **d: d)(**d) just returns (a copy of?) d
<cfbolz>
but seems that in 2.7 that doesn't work any more either
jacob22_ has joined #pypy
marr has quit [Ping timeout: 260 seconds]
<arigato>
cfbolz: are you sure about cpython? I don't have a pre-2.6 to test with :-)
<cfbolz>
arigato: not 100% ;-)
<cfbolz>
But I think the current text is fine anyway
<cfbolz>
Just a historical detail
<kenaan>
antocuni faster-rstruct-2 8a582e197e5b /rpython/: experimental checkin, reviews are welcome :). Refactor rgc._ResizableListSupportingRawPtr to use a prop...
<kenaan>
antocuni faster-rstruct-2 ed23f8739819 /rpython/rlib/: implement rgc.ll_for_resizable_list, which is the equivalent of llstr(), but for lists
<antocuni>
arigato: I am leaving for lunch soon, but if you feel like reviewing it, I'd like to get an opinion on the branch I'm working on
<antocuni>
the end goal is to be able to optimize BytearrayBuffer the same way we do for StringBuffer
<antocuni>
i.e., that when we do struct.{unpack,unpack_from} on a bytearray, we generate a gc_load_indexed inside the 'items' field
<arigato>
cfbolz: just because, I tested 2.3 and 2.5 and no, it doesn't work there either :-)
<cfbolz>
arigato: OK. So it's just pypy that did this
<arigato>
antocuni: ok, makes sense
<antocuni>
thanks. I have launched a translation in the meantime to make sure that I didn't break things so far :), I'll check the result after lunch
* antocuni
off
<cfbolz>
arigato: then we just close as won't fix, imo. Because for the dictionary case, just leaving off the ** does the same thing
<arigato>
yes, we should mention it explicitly in the docs, even
<arigato>
also, d1.update(**d2) is also the same as d1.update(d2)
<cfbolz>
Yes
<arigato>
you may abuse d1.update(d2, **d3) as a one-liner way to do d1.update(d2); d1.update(d3)
<arigato>
but meh
<arigato>
like, it's a way to write "the union of d1 and d2" in an expression: dict(d1, **d2)
<arigato>
but I just thought about it right now
antocuni has quit [Ping timeout: 258 seconds]
<kenaan>
arigo default 73b4ce214eb8 /pypy/doc/cpython_differences.rst: Add another note
jcea has joined #pypy
<idnar>
arigato: sometimes you have three dicts :D
<arigato>
idnar: in Python 3.6 you can write dict(**d1, **d2, **d3) :-) but only for unicode-only keys
<idnar>
oh boy
<arigato>
already in 3.5 or even before, actually
<idnar>
is the order guaranteed to be correct with overlapping keys?
vkirilichev has quit [Remote host closed the connection]
kipras`away is now known as kipras
<kenaan>
antocuni faster-rstruct-2 5155ad0ff2ca /: 1) avoid to take an unneeded string slice to skip the chars after typed_read; 2) as it was written befo...
<njs>
fijal: "linux is the only first-grade supported platform for numpy" <-- this is news to me...
<njs>
"in Python 3.6 you can write dict(**d1, **d2, **d3) :-) but only for unicode-only keys" <-- you can also do {**d1, **d2, **d3} and it works for any keys :-)
juqrum has joined #pypy
juqrum is now known as bjs
Rhy0lite has quit [Quit: Leaving]
jamesaxl has quit [Quit: WeeChat 1.7.1]
vkirilichev has quit [Remote host closed the connection]