<toad_poloer>
The contributing guidelines suggest popping in here might be a good idea.
<mattip>
hi and welcome. Tests will help to work out what needs to be done, something like extending test_constructors
<mattip>
in test_datetime
<toad_poloer>
Ah yes I was about to ask that.
<mattip>
you run them with `python2 pytest.py pypy/module/cpyext/test/test_datetime.py -k test_constructors`
<toad_poloer>
python2? Not pypy?
<mattip>
which will translate enough of PyPy to run the test, compile a c-extension module, import it and run the test
<mattip>
correct
<toad_poloer>
Is it still python2 for PyPy 3.6? One of those bugs is 3.6-only.
<mattip>
that is called an untranslated test
<mattip>
yes, since rpython is python2
<mattip>
to run the test with pypy3 or cpython3, try
darkman66 has joined #pypy
<mattip>
python2 pytest.py -A --python=python3 pypy/module/cpyext/test/test_datetime.py -k test_constructors
<mattip>
python2 pytest.py -A --python=path/to/pypy3 pypy/module/cpyext/test/test_datetime.py -k test_constructors
<toad_poloer>
By the way, are you familiar with the cpyext datetime stuff? Because I have a question about the capsule import that I haven't drilled down into enough to actually determine if it's a bug worth reporting yet.
<toad_poloer>
The non-PyPy version calls PyCapsule_Import, but apparently that has caused some problems with PyPy, which is expecting you to call PyDateTime_Import()
<toad_poloer>
It's understandable why this is, this is a consequence of the fact that CPython's "API" is a bunch of C macros, so anyone writing bindings or wrappers has to actually re-implement the functions.
<fijal>
toad_poloer: thanks for doing this btw
<toad_poloer>
PyPy actually exposes real C symbols that we can just bind to, but I kinda think the other way should work, too (and it would simplify things on the PyO3 end)
<toad_poloer>
No problem fijal, happy to help!
<mattip>
PyCapsule_Import is a C function in PyPy, I imagine we took it from CPython. Maybe it needs adjustment for python3
<toad_poloer>
If you don't know offhand the differences, I'll probably figure it out pretty quickly while I'm digging around in the datetime cpyext code.
<mattip>
hard to say without seeing the error they talk about
<mattip>
don't know much about PyO3, but c-extensions are painful on PyPY. Would be nice to find a better interop mechanism
<toad_poloer>
If you're writing Rust extensions specifically targeting pypy, my understanding is milksnake/cffi is a better approach.
<toad_poloer>
At least in terms of speed.
<toad_poloer>
My goal here is to make it as easy as possible for people targeting cpython to *also* compile a version for PyPy.
<mattip>
right, thanks for doing that
<mattip>
ahh, in cpython PyDateTime_IMPORT is defined as (PyDateTime_CAPI *)PyCapsule_Import(PyDateTime_CAPSULE_NAME, 0)
<toad_poloer>
Yeah, that's why it's implemented that way in Rust.
<mattip>
so "will behave unexpectedly in pypy" should be "does the wrong thing in PyPy"
<toad_poloer>
It's a pretty minor issue, really, but my understanding from when I've touched that PyDateTime_CAPI stuff in CPython was that the capsule was the way to go, moving forward.
<toad_poloer>
I don't know that it's worth seriously complicating things on the PyPy side to save a few conditional compilation lines in PyO3, but if it's easier to keep the implementations somewhat in sync to maximize compatibility, I can look into tweaking the import logic.
<mattip>
I may be wrong but simply importing datetime will not call PyDatetime_Import on pypy, since it is pure python.
<mattip>
we do call PyDatetime_Import whenever instaniating a cpyext datetime/date object via the call to attach
<toad_poloer>
I think from PyO3's side that doesn't matter too much at the moment, since there's no way to call into PyPy from PyO3.
marky1991 has quit [Ping timeout: 252 seconds]
<toad_poloer>
And the CAPI object is a "lazy static" object, it calls the rust wrapper for PyDatetime_IMPORT the first time it's dereferenced.
<toad_poloer>
It's really just that in CPython, importing the capsule and calling PyDatetime_IMPORT do the same thing.
<toad_poloer>
And in PyPy they don't.
<mattip>
ok. Back to missing new py3.6 api calls, I usually would try to get the tests right by testing with -A --python=python3
<mattip>
which has another advantage, it is alot faster
<mattip>
then move to figuring out what is missing in cpyext
<toad_poloer>
Oh you mean before I start adding tests?
<toad_poloer>
Yeah that's probably a good call.
<mattip>
no, I mean add the test first, it really helps to focus on what is important
<mattip>
of course, that is how we end up with really slow code, because maybe by designing it all top-down things would be better
<toad_poloer>
Running that command cold (with or without -A), I'm getting "no module named pycparser"
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
antocuni2 has quit [Quit: Leaving]
<mattip>
indeed, your host python2 should have some packages installed. cpyext uses pycparser
<toad_poloer>
Ah, ok, I assume they're all in `requirements.txt`
<mattip>
maybe, installing cffi will bring in pycparser
darkman66 has quit [Remote host closed the connection]
<toad_poloer>
It's also complaining a bit about the -A
<mattip>
you should be running this in the top-level pypy directory so it picks up pypy's pytest
Rhy0lite has quit [Quit: Leaving]
<toad_poloer>
Yeah, in the repo root.
darkman66 has joined #pypy
<toad_poloer>
The tests are working without the -A and --python, though I'm not sure what version it's using.
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
marky1991 has quit [Read error: Connection reset by peer]
marky1991 has joined #pypy
adamholmberg has quit [Remote host closed the connection]
<cfbolz>
toad_poloer: which branch are you on?
<cfbolz>
It's possible that --python only exists on py3.6
marky1991 has quit [Ping timeout: 250 seconds]
adamholmberg has joined #pypy
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
adamholmberg has quit [Read error: Connection reset by peer]
darkman66 has quit [Remote host closed the connection]
adamholmberg has joined #pypy
darkman66 has joined #pypy
<toad_poloer>
cfbolz: Whatever the default is.
<toad_poloer>
I don't usually use mercurial, so I haven't done anything fancier than fork + clone.
<mattip>
you need to do "hg update py3.6" which is "git checkout py3.6"
<mattip>
we have two branches "default" which is python2 and py3.6 which is python3.6
<toad_poloer>
Are there going to be more 3.5 releases?
<mattip>
based on popular demand
<mattip>
so probably not
<toad_poloer>
OK.
<mattip>
no-one has showed up to ask for it in any case
<toad_poloer>
I'll keep the part that can be backported a separate PR anyway.
<toad_poloer>
But not actively try to backport it.
<mattip>
bitbucket's PR workflow is horrible
<mattip>
we prefer to give people a commit bit, and tell them to work on a feature branch
<mattip>
so you would do "hg branch my-awesome-branch"
<mattip>
"hg add my-new-file"
<mattip>
hg commit -m"here is some new stuff"
<mattip>
by default hg commits all changes, there is no staging
<toad_poloer>
Yeah, I'm going to read this "mercurial for git users" thing, because I am a pretty heavy user of partial commits and interactive rebasing.
<mattip>
there is a stash-like thing called shelve
<toad_poloer>
So before I actually commit anything it's best to get a sense of how to use mercurial. I've been meaning to learn that anyway.
<mattip>
thg (tortoise-hg) is a really nice gui that actually is helpful for that kind of stuff
<toad_poloer>
Anyway, I've gotten my first segfault for screwing up the implementation of DateTime_FromTimestamp, so it looks like we're off to the races ;)
<mattip>
refcounting is fun
<toad_poloer>
This was actually signature mismatch - it's also, I think, why these two functions are outliers in not being included in the CAPI.
<toad_poloer>
The signature of the macro doesn't match the signature of the C API, so it's a bit more work to get them to do the same thing.
<toad_poloer>
Shouldn't be a problem, though, just a matter of adding a wrapper function.
<mattip>
we can use macros too in a header file
<toad_poloer>
Might be useful, but I think this is mostly concerned with the public link-able stuff.
<toad_poloer>
I think it'll be pretty easy to fix, honestly.
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
danieljabailey has quit [Read error: Connection reset by peer]
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
darkman66 has quit [Remote host closed the connection]
Ai9zO5AP has quit [Quit: WeeChat 2.4]
darkman66 has joined #pypy
darkman66 has quit [Remote host closed the connection]
darkman66 has joined #pypy
darkman66 has quit [Ping timeout: 240 seconds]
themsay has joined #pypy
darkman66 has joined #pypy
Smigwell has joined #pypy
adamholmberg has quit [Remote host closed the connection]
user24 has joined #pypy
<user24>
I just saw the startup message: "Every time someone argues with "Smalltalk has always done X", it is always a good hint that something needs to be changed fast. - Marcus Denker"
<user24>
can someone explain?
<user24>
is this meant ironically or not? i'm confuzzled
<user24>
to a human user, the pypy interpreter is 10000% slower than cpython, because you have to figure out the source of the snarky irc comments first :P
darkman66 has quit [Remote host closed the connection]