[mpl][fold.html] apply<op, _1, deref<_2> > correction needed.
The vault file: http://preview.tinyurl.com/cbr9k3 demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html? TIA. -Larry
AMDG Larry Evans wrote:
The vault file:
http://preview.tinyurl.com/cbr9k3
demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html?
I'm very confused. First of all, in the assertions, you probably want boost::mpl::equal_to instead of boost::mpl::equal. Second, I don't see fold or iter_fold at all. Finally, when you use a lambda expression inside another lambda expression, you need to wrap it in protect. mpl::apply<mpl::apply<op_meta_fun_elem<_1, _2>, _1, mpl::deref<_2> >, state0, iter0>::type is guaranteed to behave strangely, because all the placeholders will be substituted by the outermost apply. In Christ, Steven Watanabe
On 03/11/09 11:38, Steven Watanabe wrote:
AMDG
Larry Evans wrote:
The vault file:
http://preview.tinyurl.com/cbr9k3
demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html?
I'm very confused. First of all, in the assertions, you probably want boost::mpl::equal_to instead of boost::mpl::equal.
Thanks. Will change.
Second, I don't see fold or iter_fold at all.
I'm not saying there's a bug in either. I'm claiming there's a documentation bug.
Finally, when you use a lambda expression inside another lambda expression, you need to wrap it in protect.
mpl::apply<mpl::apply<op_meta_fun_elem<_1, _2>, _1, mpl::deref<_2> >, state0, iter0>::type
is guaranteed to behave strangely, because all the placeholders will be substituted by the outermost apply.
So the documentation in fold.html should have used protect somewhere in apply<op,_1, deref<_2> >? Thanks Steven. -Larry
On 03/11/09 12:07, Larry Evans wrote:
On 03/11/09 11:38, Steven Watanabe wrote:
AMDG
Larry Evans wrote:
The vault file:
http://preview.tinyurl.com/cbr9k3
demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html? [snip] Finally, when you use a lambda expression inside another lambda expression, you need to wrap it in protect.
mpl::apply<mpl::apply<op_meta_fun_elem<_1, _2>, _1, mpl::deref<_2> >, state0, iter0>::type
is guaranteed to behave strangely, because all the placeholders will be substituted by the outermost apply.
So the documentation in fold.html should have used protect somewhere in apply<op,_1, deref<_2> >?
I think a combination of lambda<op>::type::apply<_1,deref<_2> > works, at least according to the new version of the vault file just uploaded. So, the fold.html docs are wrong and could be corrected by changing: apply<op,_1, deref<_2> > to: lambda<op>::type::apply<_1,deref<_2> > , or am I missing something else. TIA. -Larry
On 03/11/09 16:20, Larry Evans wrote:
On 03/11/09 12:07, Larry Evans wrote:
On 03/11/09 11:38, Steven Watanabe wrote: [snip]
Finally, when you use a lambda expression inside another lambda expression, you need to wrap it in protect.
Steven, I tried that, but got an error, which lead me finally to the lambda<Op>::type::apply<,> solution shown below. [snip]
So, the fold.html docs are wrong and could be corrected by changing:
apply<op,_1, deref<_2> >
to:
lambda<op>::type::apply<_1,deref<_2> >
, or am I missing something else.
Apparently I was missing something because the page: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/apply.html Says for any _Lambda Expression_ f and arbitrary type a1,...,an: typedef apply<f,a1,...,an>::type t is equivalent to: typedef apply_wrap< lambda<f>::type,a1,...,an>::type t; and the page: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/apply-wrap.html says for any _Metafunction Class_ f and arbitrary types a1,...,an: typedef apply_wrap<f,a1,...an>::type t; is equivalent to: f::apply<a1,... an>::type t; so, the fold.html expression: apply<op,_1, deref<_2> > is equivalent to: apply_wrap<lambda<op>::type, _1, deref<_2> > is equivalent to: lambda<op>::type::apply<_1, deref<_2> >::type which is the exact expression I got to work; yet, just coding: apply<op, _1, deref<_2> > doesn't work. Maybe there's a bug in the compiler I'm using? It's gcc-4.4 or gcc-4.1. Anybody else having this problem with another compiler? TIA. -Larry
On 03/12/09 16:39, Larry Evans wrote:
On 03/11/09 16:20, Larry Evans wrote:
On 03/11/09 12:07, Larry Evans wrote: [snip] So, the fold.html docs are wrong and could be corrected by changing:
apply<op,_1, deref<_2> >
to:
lambda<op>::type::apply<_1,deref<_2> >
, or am I missing something else.
Apparently I was missing something because the page:
http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/apply.html
Says for any _Lambda Expression_ f and arbitrary type a1,...,an: [snip] A new upload to vault in
Home/Template Metaprogramming/fold_html_or_app_bug.cpp Has a test showing apply<op,_1,deref<_2> > fails and, in addition to the lambda<op>::type::apply<_1,deref<_2> > solution, shows another solution which involves changing the apply template to *not* inherit from apply_wrap. Any ideas about which solution is better? -regards, Larry
On 03/13/09 22:02, Larry Evans wrote: [snip]
Has a test showing apply<op,_1,deref<_2> > fails and, in addition to the lambda<op>::type::apply<_1,deref<_2> > solution, shows another solution which involves changing the apply template to *not* inherit from apply_wrap. Any ideas about which solution is better?
OOPS. The 2nd solution of redefining apply to contain nested typedef apply_wrap<,,> type; instead of inheriting apply_wrap would obviously break existing code. However, to get something similar to the apply<op,_1,deref<_2> > in: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html to work, maybe using eval_apply (defined as the app2ok in the vault) would work? Then instead of: apply<op,_1,deref<_2> > use: eval_apply<op,_1,deref<_2> >::type as shown in the vault code. The name eval_apply is modeled after eval_if. Am I missing something or should I file a trac ticket on this? Note, the ticket woul only say there's a bug in fold.html. It would say nothing about bugs in fold.hpp.
On 03/14/09 06:24, Larry Evans wrote: [snip]
to work, maybe using eval_apply (defined as the app2ok in the vault) would work? Then instead of:
apply<op,_1,deref<_2> >
use:
eval_apply<op,_1,deref<_2> >::type
as shown in the vault code.
The name eval_apply is modeled after eval_if.
Am I missing something or should I file a trac ticket on this?
OOPS. eval_apply<,,>::type is simply apply_wrap<,,>. But apply is derived from apply_wrap;hence, apply<op,_1,deref<_2> should work. The newly uploaded vault file: http://preview.tinyurl.com/de8qkp shows this. I tried using cpp to produce output to try on comeau's online compiler: http://www.comeaucomputing.com/tryitout/ however, it failed because some gcc specific names were used (e.g. __visibility__ ) and the online compile failed. Could someone try this on some other compiler to verify that gcc is buggy here? TIA. -Larry
Hi Larry,
I'm not saying there's a bug in either. I'm claiming there's a documentation bug.
You are right, please see below.
Finally, when you use a lambda expression inside another lambda expression, you need to wrap it in protect. mpl::apply<mpl::apply<op_meta_fun_elem<_1, _2>, _1, mpl::deref<_2> >, state0, iter0>::type is guaranteed to behave strangely, because all the placeholders will be substituted by the outermost apply.
So the documentation in fold.html should have used protect somewhere in apply<op,_1, deref<_2> >?
Nope, it should have been typedef iter_fold<s,state,apply2<lambda<op>::type,_1,deref<_2> > >::type t; ^ ^^^^^^^^^^^^^^^^ That is: - 'apply2' instead of 'apply' to workaround "apply + lambda + BOOST_MPL_LIMIT_METAFUNCTION_ARITY+1" issue (http://article.gmane.org/gmane.comp.lib.boost.user/9917) and - 'lambda<op>::type' instead of 'op' to prevent 'op' from being treated as an integral part of the 'apply2< ...,_1,deref<_2> >' lambda expression. Fixed in the doc sources in the trunk (https://svn.boost.org/trac/boost/changeset/51791). Thanks for the report! -- Aleksey Gurtovoy MetaCommunications Engineering
On 03/16/09 01:34, Aleksey Gurtovoy wrote: Hi Aleksey, [snip]
Nope, it should have been
typedef iter_fold<s,state,apply2<lambda<op>::type,_1,deref<_2> >
::type t; ^ ^^^^^^^^^^^^^^^^
since apply2<op,a1,a2> is derived from apply_wrap2<lambda<op>::type,a1,a2>, it would be less confusion, at least to me, to just use apply_wrap2<lambda<op>::type,_1,deref<_2> >. Otherwise, you'dd have apply_wrap2<lambda<lambda<op>::type>::type,_1,deref<_2> >. As shown in my last upload to the vault. this seems to work. Now why apply2<op,,> doesn't is a mystery to me since it's superclass, apply_wrap2<lambda<op>::type,,> seems to work.
That is:
- 'apply2' instead of 'apply' to workaround "apply + lambda + BOOST_MPL_LIMIT_METAFUNCTION_ARITY+1" issue (http://article.gmane.org/gmane.comp.lib.boost.user/9917) and
That post seems to suggest a workaround:
When I first realized this, I was thinking about bumping up BOOST_MPL_LIMIT_METAFUNCTION_ARITY internally, so that, in fact, the maximum supported arity of placeholder expressions (but not everything else) would be BOOST_MPL_LIMIT_METAFUNCTION_ARITY + 1, but unfortunately never got to it. I'll consider fixing this for 1.33.
Would this workaround actually work? If so, are there plan's to install it? [snip]
Fixed in the doc sources in the trunk (https://svn.boost.org/trac/boost/changeset/51791).
Thank you.
Thanks for the report!
Glad I could help. -Larry
On Mon, 16 Mar 2009 09:19:25 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
On 03/16/09 01:34, Aleksey Gurtovoy wrote:
Nope, it should have been typedef iter_fold<s,state,apply2<lambda<op>::type,_1,deref<_2> >
::type t; ^ ^^^^^^^^^^^^^^^^
since apply2<op,a1,a2> is derived from apply_wrap2<lambda<op>::type,a1,a2>, it would be less confusion, at least to me, to just use apply_wrap2<lambda<op>::type,_1,deref<_2> >.
Good point. It's also more consistent with the rest of the docs (e.g. http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/unique.html). Corrected in https://svn.boost.org/trac/boost/changeset/52205.
That is: - 'apply2' instead of 'apply' to workaround "apply + lambda + BOOST_MPL_LIMIT_METAFUNCTION_ARITY+1" issue (http://article.gmane.org/gmane.comp.lib.boost.user/9917) and
That post seems to suggest a workaround:
When I first realized this, I was thinking about bumping up BOOST_MPL_LIMIT_METAFUNCTION_ARITY internally, so that, in fact, the maximum supported arity of placeholder expressions (but not everything else) would be BOOST_MPL_LIMIT_METAFUNCTION_ARITY + 1, but unfortunately never got to it. I'll consider fixing this for 1.33.
Would this workaround actually work?
In one or another form, sure.
If so, are there plan's to install it?
It's on the TODO list (http://svn.boost.org/trac/boost/wiki/BoostMplRoadmap), but there is no specific plan aside "this should be fixed at some point". Patches are welcome :). Sorry for the late reply, got totally swamped. -- Aleksey Gurtovoy MetaCommunications Engineering
On Sun, Apr 5, 2009 at 11:59 PM, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
On Mon, 16 Mar 2009 09:19:25 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
[snip]
It's on the TODO list (http://svn.boost.org/trac/boost/wiki/BoostMplRoadmap),
None of the gmane links in this page works for me :( [snip]
-- Aleksey Gurtovoy MetaCommunications Engineering
Regards, -- Felipe Magno de Almeida
On Sun, 05 Apr 2009 22:37:52 -0500, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Sun, Apr 5, 2009 at 11:59 PM, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
On Mon, 16 Mar 2009 09:19:25 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
[snip]
It's on the TODO list (http://svn.boost.org/trac/boost/wiki/BoostMplRoadmap),
None of the gmane links in this page works for me :(
Hmm, quite a few don't work for me either. Looks like somehow gmane lost track of some of the threads, even though the individual messages are still there. Okay, I fixed what I could. HTH, -- Aleksey Gurtovoy MetaCommunications Engineering
On 03/16/09 01:34, Aleksey Gurtovoy wrote: [snip]
Nope, it should have been
typedef iter_fold<s,state,apply2<lambda<op>::type,_1,deref<_2> >
::type t; ^ ^^^^^^^^^^^^^^^^ [snip] Fixed in the doc sources in the trunk (https://svn.boost.org/trac/boost/changeset/51791). [snip]
After doing `svn update`, got the changes. Then read the: /libs/mpl/doc/src/README.txt and followed instructions, which worked (after becoming root) until: 4. Do ``python build.py``. It's going to take a couple of minutes to finish. which resulted in: ~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ ls README.txt build.py docutils refmanual ~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ python build.py Traceback (most recent call last): File "/usr/bin/rst2htmlrefdoc.py", line 16, in <module> from docutils.core import publish_cmdline, default_description ImportError: No module named docutils.core There is a file: libs/mpl/doc/src/docutils/tools/rst2htmlrefdoc.py So, I assume the setup.py in step 3 (where I had to become root) of the README.txt 3. Go to ``$BOOST_ROOT/libs/mpl/doc/src/docutils`` directory and do ``python setup.py install`` to install MPL-specific HTML/refdoc Docutils writer. should have installed the usr/bin/rst2htmlrefdoc.py file? Is there anyway to modify this to avoid the need to become root in order to write to /usr/bin or /usr/lib/python2.5/site-packages/docutils? -regards, Larry
On 03/16/09 11:45, Larry Evans wrote:
On 03/16/09 01:34, Aleksey Gurtovoy wrote: [snip] 4. Do ``python build.py``. It's going to take a couple of minutes to finish.
which resulted in:
~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ ls README.txt build.py docutils refmanual ~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ python build.py Traceback (most recent call last): File "/usr/bin/rst2htmlrefdoc.py", line 16, in <module> from docutils.core import publish_cmdline, default_description ImportError: No module named docutils.core
There is a file:
libs/mpl/doc/src/docutils/tools/rst2htmlrefdoc.py
So, I assume the setup.py in step 3 (where I had to become root) of the README.txt
3. Go to ``$BOOST_ROOT/libs/mpl/doc/src/docutils`` directory and do ``python setup.py install`` to install MPL-specific HTML/refdoc Docutils writer.
should have installed the usr/bin/rst2htmlrefdoc.py file?
[snip] OOPS. Should have read the error closer, in particular the part about docutils.core. Should setup.py be installing that? There is: from distutils.core import setup in setup.py. Here's the output from my run of setup.py: root@evansl-desktop:/usr/lib/python2.5# mkdir docutils root@evansl-desktop:/usr/lib/python2.5# cd /home/evansl/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src/docutils root@evansl-desktop:/home/evansl/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src/docutils# python setup.py install running install running build running build_py running build_scripts running install_lib creating /usr/lib/python2.5/site-packages/docutils creating /usr/lib/python2.5/site-packages/docutils/writers creating /usr/lib/python2.5/site-packages/docutils/writers/html4_refdoc copying build/lib/docutils/writers/html4_refdoc/__init__.py -> /usr/lib/python2.5/site-packages/docutils/writers/html4_refdoc copying build/lib/docutils/writers/html4_refdoc/frames.css -> /usr/lib/python2.5/site-packages/docutils/writers/html4_refdoc byte-compiling /usr/lib/python2.5/site-packages/docutils/writers/html4_refdoc/__init__.py to __init__.pyc running install_scripts copying build/scripts-2.5/rst2htmlrefdoc.py -> /usr/bin changing mode of /usr/bin/rst2htmlrefdoc.py to 755 running install_egg_info Writing /usr/lib/python2.5/site-packages/html_refdoc-.1.egg-info root@evansl-desktop:/home/evansl/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src/docutils# cd .. root@evansl-desktop:/home/evansl/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src# ls README.txt build.py docutils refmanual
On Mon, 16 Mar 2009 16:05:38 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
Should have read the error closer, in particular the part about docutils.core. Should setup.py be installing that?
Yes and no. Not 'setup.py' from step 3, but 'setup.py' for the docutils snapshot that (I assume) you've downloaded. I guess step 1, 1. Install prerequisites. could have been clearer. Does this version work better for you: https://svn.boost.org/trac/boost/changeset/52206 ? -- Aleksey Gurtovoy MetaCommunications Engineering
On 04/05/09 23:35, Aleksey Gurtovoy wrote:
On Mon, 16 Mar 2009 16:05:38 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
Should have read the error closer, in particular the part about docutils.core. Should setup.py be installing that?
Yes and no. Not 'setup.py' from step 3, but 'setup.py' for the docutils snapshot that (I assume) you've downloaded. I guess step 1,
1. Install prerequisites.
could have been clearer. Does this version work better for you:
https://svn.boost.org/trac/boost/changeset/52206
?
Thanks, Aleksey, but that says: 25 - To install HTML/frames writer, go to Sandbox's ``agurtovoy/html_frames`` 26 directory and run ``python setup.py install`` However: https://svn.boost.org/trac/boost/browser/sandbox has no agurtovoy directory. Is there another sandbox I should be looking at? -regards, Larry
On Mon, 06 Apr 2009 09:56:01 -0500, Larry Evans <cppljevans@suddenlink.net> wrote: > On 04/05/09 23:35, Aleksey Gurtovoy wrote: >> On Mon, 16 Mar 2009 16:05:38 -0500, Larry Evans >> <cppljevans@suddenlink.net> wrote: >>> Should have read the error closer, in particular the part >>> about docutils.core. Should setup.py be installing that? >> Yes and no. Not 'setup.py' from step 3, but 'setup.py' for the docutils >> snapshot that (I assume) you've downloaded. I guess step 1, >> 1. Install prerequisites. >> could have been clearer. Does this version work better for you: >> https://svn.boost.org/trac/boost/changeset/52206 >> ? >> > > Thanks, Aleksey, but that says: > > 25 - To install HTML/frames writer, go to Sandbox's > ``agurtovoy/html_frames`` > 26 directory and run ``python setup.py install`` > > However: > > https://svn.boost.org/trac/boost/browser/sandbox > > has no agurtovoy directory. Is there another sandbox > I should be looking at? Yes, the one from the Prerequisites: * Docutils `HTML/frames writer`_ from Docutils Sandbox. Download it as a part of daily `Sandbox snapshot`_ at or get it from the `Docutils' Subversion repository`_. .. _HTML/frames writer: http://docutils.sourceforge.net/sandbox/agurtovoy/html_frames/ .. _Sandbox snapshot: http://docutils.sourceforge.net/docutils-sandbox-snapshot.tgz .. _Docutils' Subversion repository: http://docutils.sourceforge.net/docs/dev/repository.html Sorry for the confusion. -- Aleksey Gurtovoy MetaCommunications Engineering
On 04/06/09 10:49, Aleksey Gurtovoy wrote:
> On Mon, 06 Apr 2009 09:56:01 -0500, Larry Evans
> <cppljevans@suddenlink.net> wrote:
>
>> On 04/05/09 23:35, Aleksey Gurtovoy wrote:
>>> On Mon, 16 Mar 2009 16:05:38 -0500, Larry Evans
>>> <cppljevans@suddenlink.net> wrote:
>>>> Should have read the error closer, in particular the part
>>>> about docutils.core. Should setup.py be installing that?
>>> Yes and no. Not 'setup.py' from step 3, but 'setup.py' for the docutils
>>> snapshot that (I assume) you've downloaded. I guess step 1,
>>> 1. Install prerequisites.
>>> could have been clearer. Does this version work better for you:
>>> https://svn.boost.org/trac/boost/changeset/52206
>>> ?
>>>
>>
>> Thanks, Aleksey, but that says:
>>
>> 25 - To install HTML/frames writer, go to Sandbox's
>> ``agurtovoy/html_frames``
>> 26 directory and run ``python setup.py install``
>>
>> However:
>>
>> https://svn.boost.org/trac/boost/browser/sandbox
>>
>> has no agurtovoy directory. Is there another sandbox
>> I should be looking at?
>
> Yes, the one from the Prerequisites:
>
> * Docutils `HTML/frames writer`_ from Docutils Sandbox. Download it as
> a part of daily `Sandbox snapshot`_ at or get it from the `Docutils'
> Subversion repository`_.
>
> .. _HTML/frames writer:
> http://docutils.sourceforge.net/sandbox/agurtovoy/html_frames/
> .. _Sandbox snapshot:
> http://docutils.sourceforge.net/docutils-sandbox-snapshot.tgz
> .. _Docutils' Subversion repository:
> http://docutils.sourceforge.net/docs/dev/repository.html
>
> Sorry for the confusion.
>
No problem.
I did get the agurtovoy/html_frames and then followed all 4 steps in:
https://svn.boost.org/trac/boost/browser/trunk/libs/mpl/doc/src/README.txt?rev=52206#L12
However, the last step gave error messages:
-{--build.py errors--
~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ python build.py
at.rst:3207: (ERROR/3) Undefined substitution referenced: "overloaded name".
clear.rst:3950: (ERROR/3) Undefined substitution referenced:
"concept-identical".
insert.rst:4189: (ERROR/3) Undefined substitution referenced:
"overloaded name".
refmanual.gen:4248: (ERROR/3) Undefined substitution referenced:
"concept-identical".
refmanual.gen:4282: (ERROR/3) Undefined substitution referenced:
"concept-identical".
refmanual.gen:4438: (ERROR/3) Undefined substitution referenced:
"concept-identical".
refmanual.gen:5289: (ERROR/3) Undefined substitution referenced:
"concept-identical".
refmanual.gen:5728: (ERROR/3) Undefined substitution referenced:
"concept-identical".
transform.rst:9874: (ERROR/3) Undefined substitution referenced:
"overloaded name".
reverse_transform.rst:11435: (ERROR/3) Undefined substitution
referenced: "overloaded name".
refmanual.gen:14647: (ERROR/3) Undefined substitution referenced: "bind
expression".
protect.rst:15007: (ERROR/3) Undefined substitution referenced: "bind
expression".
refmanual.gen:15043: (ERROR/3) Undefined substitution referenced: "bind
expression".
Traceback (most recent call last):
File "/usr/bin/rst2htmlrefdoc.py", line 22, in <module>
publish_cmdline(writer_name='html4_refdoc', description=description)
File "/usr/lib/python2.5/site-packages/docutils/core.py", line 336,
in publish_cmdline
config_section=config_section, enable_exit_status=enable_exit_status)
File "/usr/lib/python2.5/site-packages/docutils/core.py", line 205,
in publish
output = self.writer.write(self.document, self.destination)
File
"/usr/lib/python2.5/site-packages/docutils/writers/html4_frames/__init__.py",
line 108, in write
(index_text, pages) = self.translate(document, index_file,
page_files_dir, extension)
File
"/usr/lib/python2.5/site-packages/docutils/writers/html4_frames/__init__.py",
line 72, in translate
document.walkabout(visitor)
File "/usr/lib/python2.5/site-packages/docutils/nodes.py", line 173,
in walkabout
if child.walkabout(visitor):
File "/usr/lib/python2.5/site-packages/docutils/nodes.py", line 165,
in walkabout
visitor.dispatch_visit(self)
File "/usr/lib/python2.5/site-packages/docutils/nodes.py", line 1597,
in dispatch_visit
return method(node)
File
"/usr/lib/python2.5/site-packages/docutils/writers/html4_frames/__init__.py",
line 210, in visit_section
section_id = _node_id(node)
File
"/usr/lib/python2.5/site-packages/docutils/writers/html4_frames/__init__.py",
line 617, in _node_id
return node['ids'][0]
IndexError: list index out of range
-}--build.py errors--
What might I be doing wrong?
Thanks,
Larry
On Mon, 06 Apr 2009 16:02:56 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
I did get the agurtovoy/html_frames and then followed all 4 steps in:
https://svn.boost.org/trac/boost/browser/trunk/libs/mpl/doc/src/README.txt?r...
However, the last step gave error messages: -{--build.py errors--
~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ python build.py at.rst:3207: (ERROR/3) Undefined substitution referenced: "overloaded name". clear.rst:3950: (ERROR/3) Undefined substitution referenced: "concept-identical". insert.rst:4189: (ERROR/3) Undefined substitution referenced: "overloaded name".
[skip more errors] Hmm, these should have come from "terminology.rst". Please check if you are completely in sync with the trunk. If that doesn't help, could you send me your refmanual.gen (produced by build.py in libs/mpl/doc/src/refmanual/)? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering
on Sun Apr 12 2009, "Aleksey Gurtovoy" <agurtovoy-AT-meta-comm.com> wrote:
On Mon, 06 Apr 2009 16:02:56 -0500, Larry Evans <cppljevans@suddenlink.net> wrote:
I did get the agurtovoy/html_frames and then followed all 4 steps in:
https://svn.boost.org/trac/boost/browser/trunk/libs/mpl/doc/src/README.txt?r...
However, the last step gave error messages: -{--build.py errors--
~/prog_dev/boost-svn/ro/boost-trunk/libs/mpl/doc/src $ python build.py at.rst:3207: (ERROR/3) Undefined substitution referenced: "overloaded name". clear.rst:3950: (ERROR/3) Undefined substitution referenced: "concept-identical". insert.rst:4189: (ERROR/3) Undefined substitution referenced: "overloaded name".
[skip more errors]
Hmm, these should have come from "terminology.rst". Please check if you are completely in sync with the trunk. If that doesn't help, could you send me your refmanual.gen (produced by build.py in libs/mpl/doc/src/refmanual/)?
The problem was that until very recently, docutils.jam didn't work at all with a standard docutils installation. It was necessary to download a docutils source distribution and then, in user-config.jam: using docutils : path/to/docutils/source/distro ; In the trunk you can now install docutils and then: using docutils : # empty : directory/of/installed/rst2html.py ; HTH, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
Aleksey Gurtovoy -
David Abrahams -
Felipe Magno de Almeida -
Larry Evans -
Steven Watanabe