<steve_s>
It seems that there are no plugins like doctest for C extensions. What would people think about rolling out some simple scheme ourselves? I assume that readthedocs is going to be a long term documentation solution for HPy, so the investment would be worth it.
<fangerer>
Sounds good to me and shouldn't be too hard. FYI: We also discussed (some time ago) kind of the other direction that we could generate examples out of the tests. That reminds me that I should create an issue for that.
<mattip>
The problem with compiling small code snippets into c-extensions and then running them is that it is time consuming
<mattip>
especially on windows
<steve_s>
Do you mean time consuming in the sense of how long the tests would run or developer's time?
<mattip>
if the runner could aggregate all the snippets into one larger C file and compile once that would be preferable
<mattip>
write out the files to disk and compilation
<mattip>
I mean time counsuming in terms of writing out the files to disk, and compilation
<steve_s>
I was thinking about doing it the other way around: you'd have a full C extension, and in it you'd make some snippets with a comment, then in the documentation, you'd refer to those snippets by some ID from the comment. Probably not all code of the C extension would be actually used in the docs.
<steve_s>
make => mark
<steve_s>
But being full extension it will contain all the boiler place to make it successfully compile. Docs would cherry-pick just some parts from it that are of interest.
<Hodgestar>
steve_s: A way to display small snippets in the documentation sounds pretty useful. I'd be a bit surprised if it didn't exist already.
<Hodgestar>
steve_s: https://github.com/hpyproject/hpy/pull/246 might benefit from such a tool -- the idea is to have a porting example that is tested (already in the PR) and then to write docs which reference / include the relevant code.
<antocuni>
steve_s: having fully working (and tested) extensions that we can reference in the docs looks like a good idea to me
<antocuni>
ah, I didn't know about start-after and end-before, they look like exactly what we need. I have used literalinclude in the past but it was incredibly fragile using line numbers, of course
<Hodgestar>
\o/ for not having to write custom sphinx extensions, and go Sphinx for already having what we need. :)
<Hodgestar>
This will also save me having to find a plan for #246.
<ronan>
I'm starting to work on the numpy port again. But I should probably update numpy first, I'm wondering whether to merge or rebase, any opinion?