![](https://secure.gravatar.com/avatar/27f6b03a726ccff3f7a5007b1df6bf8c.jpg?s=120&d=mm&r=g)
Logan Sorenson wrote:
You're welcome! I'll try to fill in as much as I can over the next few weeks (hopefully this weekend). I'll start with the existing web-pages and then try augmenting where I can.
That would be really great, thanks!
Fine, thanks! The docstrings of terms all use the custom syntax the 'genDocs.py' script needs, sphinx is not going to like that, too. There are tons of them, so maybe the 'genDocs.py' could be tweaked to hammer the docstring into the right shape, as it scans and parses them anyway.
Ok, I'll have a look into genDocs.py.
Skeleton alert on red level, beware :)
Basically, we just have to try to match the numpy style as much as possible, e.g. [5]. Now that's a literate programming! :)
Perhaps that particular example is overkill. :) I'm trying to document as much as possible on the mailing list what I did so others can recreate it if necessary. Sorry if I'm repeating stuff you already know. :)
Go on please, it's very good to have all the information together. :) The example [5] demonstrates all the possibilities, you are right that we need not them all. A more reasonable aim is to have some docstring in every function or method - still long way to go.
One issue that I noticed is I have to use numpydoc.autosummary to get the module documentation to autogenerate. For some reason, using sphinx.ext.autosummary is not enough, even though numpydoc.autosummary is deprecated and suggested to be replaced with sphinx.ext.autosummary. You can try asking the numpy crowd (numpy-di...@scipy.org), but I guess it's ok as long as it works ;)
I think it's ok for now, but I'll look around some more over on the numpy side to see where numpydoc is headed in the future. I don't want to get into maintaining a fork of numpydoc in sfepy's code base. :)
Sure, that is not an option, we have to use the standard tools, so that other kind people maintain them for us :)
Hmm, yes, this is strange. I don't notice any strange behavior from sphinx and I'm compiling the sfepy extension modules (sorry for the confusion there, I was kind of tired when I wrote the last mail :)) My only guess is that sphinx has to be able to import the module in order to autogenerate the documentation from the doc strings. Does python segfault when you load the extension modules? Everything seems ok here... Python is ok - the modules are loaded e.g. by running the tests, and all tests pass.
I get
Core was generated by `/usr/bin/python2.5 /usr/bin/sphinx-build -b html -d _build/doctrees . _build/ht'.
As you may notice, I still use python 2.5 - do you use 2.6?
I'm using 2.5.4 over here...basically, I just run "python setup.py build_ext --inplace" in the sfepy root and then cd into the doc directory and run "make html". I attached the output of these two commands in case it helps. Do you do something different to compile the extension modules?
I usually build simply by running "make". But anyway, I get the same segfault after "python setup.py build_ext --inplace". Have to check sanity of my installation some time. Thanks for the log, will check it too.
cheers, r.