search for: recommonmark

Hi, Thanks for bringing this up. I am reluctant to update to recommonmark >= 0.4.0, because it is not available in any Ubuntu version, Debian Testing or even Debian Unstable. While we could do something custom on the buildbot, I think it would be a disservice for our users to use a library that is not packaged in modern operating systems yet. Dmitri

Hi, TL;DR - We should update the bot(s) responsible for building the LLVM documentation so that they use recommonmark 0.5.0, and apply https://reviews.llvm.org/D63211. Full context: I recently started trying to build the sphinx docs. However, a change by Jordan (r363100) resulted in me no longer being able to build them, even though the build bots were green and he could build them himself. After some digging, i...

On Tue, Feb 12, 2019 at 10:45 AM Jonas Devlieghere <jonas at devlieghere.com> wrote: > Hi Kostya, > > I remember seeing this in the past. IIRC it was sufficient to install > recommonmark with `pip install recommonmark`. > installing this on my machine won't help the bots that build the docs, right? > > Cheers, > Jonas > > On Tue, Feb 12, 2019 at 10:17 AM Kostya Serebryany via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >&gt...

...Files/docs-llvm-html cd /usr/local/google/home/kcc/llvm-build/docs && /usr/bin/sphinx-build -b html -d /usr/local/google/home/kcc/llvm-build/docs/_doctrees-llvm-html -q -W /usr/local/google/home/kcc/llvm/docs /usr/local/google/home/kcc/llvm-build/docs/html Extension error: Could not import recommonmark.parser (needed for source parser) (exception: No module named recommonmark.parser) ninja: build stopped: subcommand failed. Any thoughts? Thanks! --kcc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201902...

...------------------------------------------------------------------------------------------------------------ % make docs-llvm-html -j3 Generating html Sphinx documentation for llvm into "/home/lsandov1/repos/llvm-project/build/docs/html" /home/lsandov1/.local/lib/python2.7/site-packages/recommonmark/parser.py:75: UserWarning: Container node skipped: type=document   warn("Container node skipped: type={0}".format(mdnode.t)) Warning, treated as error: /home/lsandov1/repos/llvm-project/llvm/docs/AMDGPUUsage.rst:1317: ERROR: Malformed table. Column span alignment problem in table line...

...at google.com> wrote: > >> >> >> On Tue, Feb 12, 2019 at 10:45 AM Jonas Devlieghere <jonas at devlieghere.com> >> wrote: >> >>> Hi Kostya, >>> >>> I remember seeing this in the past. IIRC it was sufficient to install >>> recommonmark with `pip install recommonmark`. >>> >> >> installing this on my machine won't help the bots that build the docs, >> right? >> > > From your original e-mail I understood this only happened locally. The > sphinx bot (http://lab.llvm.org:8011/builders/llv...

...ch]( https://reviews.llvm.org/D44910) for that, but we should figure out a policy on how we want our documentation written first. The desire to use Markdown comes mostly from it being simpler, and having much wider adoption. It does lack some of the feature that reStructuredText has; however, the recommonmark plugin for Sphinx adds extensions for most of them and has an escape to RST when all else fails. My suggestion is that we don't touch the existing documentation, but encourage new documentation to be written in Markdown+Sphinx extensions. - Michael Spencer -------------- next part -----------...

Last night, I triggered a buildbot error after my most recent commit. That one was totally on me as the warning did pop up while generating the docs site locally using the sphinx-build command (confirmed this afternoon). I just checked in a commit to resolve the error but now it appears I've triggered a different buildbot error? This error did not come up when I built the site locally to test

...m.org/D44910) for that, but we should figure out a > policy on how we want our documentation written first. > > The desire to use Markdown comes mostly from it being simpler, and having > much wider adoption. It does lack some of the feature that reStructuredText > has; however, the recommonmark plugin for Sphinx adds extensions for most > of them and has an escape to RST when all else fails. > > My suggestion is that we don't touch the existing documentation, but > encourage new documentation to be written in Markdown+Sphinx extensions. > > - Michael Spencer > ___...

...r that, but we should > figure out a policy on how we want our documentation written first. > > The desire to use Markdown comes mostly from it being simpler, and > having much wider adoption.  It does lack some of the feature that > reStructuredText has; however, the recommonmark plugin for Sphinx > adds extensions for most of them and has an escape to RST when all > else fails. > > My suggestion is that we don't touch the existing documentation, > but encourage new documentation to be written in Markdown+Sphinx > extensions. > &...

...10) for that, but we should figure out a > policy on how we want our documentation written first. > > > > The desire to use Markdown comes mostly from it being simpler, and > having much wider adoption. It does lack some of the feature that > reStructuredText has; however, the recommonmark plugin for Sphinx adds > extensions for most of them and has an escape to RST when all else fails. > > > > My suggestion is that we don't touch the existing documentation, but > encourage new documentation to be written in Markdown+Sphinx extensions. > > Does the plugin...

On Tue, Aug 20, 2019 at 9:25 PM Michael Spencer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Aug 19, 2019 at 12:38 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi everyone. My name is DeForest Richards. I’m the technical writer who was selected to work on the LLVM project as part of the Google Season of Docs program. I’ll be helping to

...at, but we should figure out a >> policy on how we want our documentation written first. >> >> The desire to use Markdown comes mostly from it being simpler, and having >> much wider adoption. It does lack some of the feature that reStructuredText >> has; however, the recommonmark plugin for Sphinx adds extensions for most >> of them and has an escape to RST when all else fails. >> >> My suggestion is that we don't touch the existing documentation, but >> encourage new documentation to be written in Markdown+Sphinx extensions. >> >> -...

I am sure quite a number of packages not supported in the distribution are easy to build and install into /usr/local/bin and such. It is not that it is easy to defeat the standard distribution and update procedures as that doing so puts that software out of sync with the standard update procedure. From then on the distribution update for cmake has no effect. I suspect there are fairly rigid

...eviews.llvm.org/D44910>) for that, but we should figure out a policy on how we want our documentation written first. > > The desire to use Markdown comes mostly from it being simpler, and having much wider adoption. It does lack some of the feature that reStructuredText has; however, the recommonmark plugin for Sphinx adds extensions for most of them and has an escape to RST when all else fails. > > My suggestion is that we don't touch the existing documentation, but encourage new documentation to be written in Markdown+Sphinx extensions. > > - Michael Spencer > ___________...

...eviews.llvm.org/D44910>) for that, but we should figure out a policy on how we want our documentation written first. > > The desire to use Markdown comes mostly from it being simpler, and having much wider adoption. It does lack some of the feature that reStructuredText has; however, the recommonmark plugin for Sphinx adds extensions for most of them and has an escape to RST when all else fails. > > My suggestion is that we don't touch the existing documentation, but encourage new documentation to be written in Markdown+Sphinx extensions. > > - Michael Spencer > ___________...

Hi Neil, I'm really not sure what you're getting at. Are you objecting to the proposal to update? The LLVM community operates by having request-for-comment (RFC) discussion threads to coalesce around a plan, then just moving forward. There is no formal argument or proposal needed. We also don't really have an official policy regarding updating CMake. In your other emails on the