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)"
raynold has quit [Quit: Connection closed for inactivity]
marvin has joined #pypy
marvin is now known as Guest79535
fulvio has joined #pypy
fulvio has quit [Client Quit]
lritter_ has quit [Ping timeout: 248 seconds]
fulvio has joined #pypy
<fulvio>
hello everyone
<fulvio>
I get to use python 3.5 on a daily basis at work and has got recently interested in the pypy project
<fulvio>
My man dev env is based on Win64 so I was looking for a Win64 version of the interpreter but couldn't find it, so I looked around to see if I could build one
<fulvio>
and found a bit of instruction for what it takes. My understanding is that a CPython 2.x is needed because PyIntObject is mentioned (which is not there anymore in CPython 3.5 at least, didn't check previous version in the 3 series)
<fulvio>
Is that right? Or can I build Pypy-c with a more modern version of cpython?
<fulvio>
I'd have a bit of a hard time finding old VS to build an old python while I already have VS2017 installed on my laptop
<fulvio>
camara, yep, I've got that, I was thinking on hacking a bit on pypy and try to get a Win64 build
<LarstiQ>
fulvio: the pypy codebase is written in python2, so yeah, cpython3.x won't help
<LarstiQ>
fulvio: there used to be a VS distributed by MS especially for python
<LarstiQ>
fulvio: possibly VS2017 also works these days
<bremner>
not sure I get the full context, but vs-code has a reasonable python 2/3 debugger
<fulvio>
I'll see if I can get Python 2.7 to compile with a recent VS and see how it comes along
<fulvio>
bremner, vs-code is just an incredibly capable editor, but visual studio includes C/C++ compilers and other stuff needed to build CPython/Pypy
<LarstiQ>
bremner: there is no Win64 pypy, one approach to getting there (iirc) modifies CPython to bootstrap, hence the above line of questioning
<kenaan>
rlamy py3.5 142c785bb994 /pypy/: Backed out changeset f80cb4368b95
__Yiota has joined #pypy
<ronan>
mjacob: save_module_content_for_future_reload() doesn't really work and shouldn't be necessary, since builtin modules are only loaded once in 3.5, but clearly we depend on it somehow
<kenaan>
rlamy py3.5 21d9bc2c1120 /pypy/module/imp/test/test_import.py: Fix untranslated test_reimport_builtin(): time.tzname is initialised in a non-standard way that seems to break in unt...
alex_ has quit [Ping timeout: 240 seconds]
traverseda has joined #pypy
<kenaan>
rlamy py3.5 7746dde0b2d4 /pypy/module/imp/test/test_import.py: Don't mess too much with the sys module
zmt00 has joined #pypy
<kenaan>
rlamy py3.5 c41fe009ac33 /pypy/tool/pytest/objspace.py: Allow __pypy__ module apptests to run translated
raynold has joined #pypy
marvin_ has quit [Ping timeout: 255 seconds]
marvin has joined #pypy
marvin is now known as Guest39285
tbodt has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Cheery>
when I allowed broader typing in my vectors, they about doubled the memory use and a benchmark shows it takes 3 times longer with new-style vectors.
<Cheery>
I wonder what I should do there.. I'd like the better vectors. :)
<Cheery>
but cutting capacity from all vector related code by that measure is bit steep.
<Cheery>
(basically switched from .x,.y,.z fields into one .scalars -field
<Cheery>
(and changed the code likewise)
oberstet has quit [Ping timeout: 248 seconds]
<Cheery>
(plus removed the float restriction.
marr has joined #pypy
_whitelogger has joined #pypy
nunatak has quit [Quit: Leaving]
raynold has quit [Quit: Connection closed for inactivity]
pdox has quit [Ping timeout: 252 seconds]
pdox has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kenaan>
antocuni cpyext-refactor-methodobject 8823f6116665 /pypy/module/cpyext/methodobject.py: XXX: this is just a test to see how much performance we loose if we go through the slow __a...
<kenaan>
antocuni cpyext-refactor-methodobject 26eed5075896 /pypy/module/cpyext/: WIP: try a different approach for descr_call: instead of creating a different class/typedef...
<kenaan>
antocuni cpyext-refactor-methodobject 094b65ff1d96 /pypy/: add a test for METH_KEYWORDS; the test passes with -A, but is currently broken in pypy
<kenaan>
antocuni cpyext-refactor-methodobject 1c00ece5b913 /pypy/module/cpyext/methodobject.py: implement call_KEYWORDS and fix the test
<kenaan>
antocuni cpyext-refactor-methodobject 071be7b3d869 /pypy/module/cpyext/methodobject.py: fix W_PyCMethodObject.descr_call, so that it uses the same logic as W_PyCFunctionObject
<kenaan>
antocuni cpyext-refactor-methodobject 6a0f6b5d4571 /pypy/module/cpyext/: kill the now-obsolete W_PyCFunctionObject_{NOARGS,O,VARARGS}
<kenaan>
antocuni cpyext-refactor-methodobject 7501b268c626 /pypy/module/cpyext/typeobject.py: add this fix, because now pass w_kwds=None directly; we should investigate better whether t...