I don't expect it to actually "work", per se, today, so this is probably more like "Finish building..."

some well-defined set of "extends" or "inherits" relationships

The vision is for it to be full-featured (e.g., support a variety of languages and input and output formats -- but also support integrations, policies, cheap setup via Harbormaster, easy document preview via arc, etc), but there isn't much demand so progress is likely to be slow. I doubt we'll ever have a superset of Sphinx's features (e.g., I don't know what "ePub" format is and would be slightly surprised to peer into the future and learn that we support it), but the architecture is (mostly) generic.

I'd have to defer to the Phacility guys on that, but I would like to see Diviner become a full-fledged tool which can be used separately to Phabricator itself. I don't know enough about sphinx to compare the two products.

Is the vision for Diviner that it will become as full featured as something like sphinx (the place to write Serious Docs for all my software projects) or just moderately useful for things that are not Phabricator?

Oh, sure, that makes sense. So maybe not "valuable indefinitely", just "valuable until Diviner can extract symbols from a bunch of languages".

Actually I fnd the "pipe CTAGS" use case odd. I think it would be more useful if you could just run diviner generate inside a directory and we automatically generate symbols and documentation (unless you disable one or the other perhaps). In particular, this could maybe let us generate documentation stubs for languages we don't know about.

I suspect it may not make sense to totally merge them -- particularly, I think the "pipe CTAGS into some script" sort of use case is valuable indefinitely.

Hi, I'm new to this but mostly we've been enjoying phabricator's features a lot. It seems like there's limited support for integrating with doxygen, as others have mentioned. This would really be nice, as I'd like to have documentation generated and available with access permissions correctly set through phabricator's account management. It would be great to have!

Looks like the feed_storynotification queries are the slowest ones; there's no objectPHID key on that table.

Yeah, that seems reasonable to me.

@epriestley, could we simply invert the logic of DivinerAtomQuery so that it returns undocumentable atoms by default (and add withExcludeUndocumentable(true) to all existing callsites?

https://secure.phabricator.com/differential/diff/31781/ seems to fix this, although I doubt this is the correct solution.

Adding PhutilArgumentParser and --trace gives me the following output:

Probably a prerequisite for implementing anything like arc diviner, or whatever, too. That said, it's probably also quite a lot of work.

Diviner updates over Conduit would be awesome!

Implementing transactions. I think that this would be messy given that (currently) no user would really ever interact with Diviner, it is always the omnipotent user.

In T8352#117479, @epriestley wrote:

(There's also a uri.source in Books which should probably get an implicit value if the repository is set but uri.source is not.)

I think that's reasonable.

Some things that are maybe worthwhile (in addition to the blocked tasks):

Would it be valuable to record the repositoryPHID for DivinerLiveSymbol / DivinerLiveAtom as well? Furthermore, are you able to explain the distinction between these two classes.

Adding the PHID: I think this is quite reasonable, since the vast majority of books have a meaningful value for the field, but it should be nullable (i.e., you should be able to generate a book from a random collection of text files on your local disk if you want) and that it's likely not the best primary organization mechanism for finding/listing books.

I did the same with Fetchmail and with a catch-all for email sent to that domain. It's ultra-simple and works pretty efficiently.

I'm not sure this is an actual bug either, but I won't let that stop me!