2002: 2003: 2004: 2005: 2006: 2007: 2008: 2009: 2010: 2011: 2012: 2013: Jan Feb Mar Apr (5) May (27) Jun (22) Jul (72) Aug (82) Sep (86) Oct (138) Nov (100) Dec (62) Jan (122) Feb (147) Mar (92) Apr (82) May (101) Jun (153) Jul (37) Aug (34) Sep (46) Oct (46) Nov (6) Dec (38) Jan (64) Feb (81) Mar (36) Apr (194) May (329) Jun (272) Jul (68) Aug (74) Sep (150) Oct (57) Nov (62) Dec (63) Jan (78) Feb (30) Mar (137) Apr (78) May (54) Jun (122) Jul (72) Aug (110) Sep (80) Oct (75) Nov (125) Dec (79) Jan (100) Feb (15) Mar (41) Apr (67) May (30) Jun (11) Jul (14) Aug (22) Sep (20) Oct (14) Nov (11) Dec (15) Jan (17) Feb (16) Mar (35) Apr (21) May (33) Jun (50) Jul (12) Aug (7) Sep (2) Oct (6) Nov (5) Dec (2) Jan (14) Feb (20) Mar (35) Apr (9) May (57) Jun (21) Jul (42) Aug (4) Sep (13) Oct (76) Nov (40) Dec (55) Jan (26) Feb (15) Mar (3) Apr (67) May (32) Jun (39) Jul (59) Aug (31) Sep (59) Oct (64) Nov (21) Dec (10) Jan (21) Feb (3) Mar (116) Apr (33) May (6) Jun (28) Jul (21) Aug (23) Sep (146) Oct (70) Nov (31) Dec (57) Jan (33) Feb (22) Mar (11) Apr (21) May (51) Jun (47) Jul (35) Aug (26) Sep (25) Oct (34) Nov (61) Dec (51) Jan (75) Feb (31) Mar (26) Apr (16) May (24) Jun (24) Jul (31) Aug (46) Sep (36) Oct (28) Nov (37) Dec (21) Jan (16) Feb (56) Mar (31) Apr (44) May (45) Jun (29) Jul (38) Aug (18) Sep (12) Oct (16) Nov (21) Dec (2)
S M T W T F S
1 2 3 4 5
(2) (2)
6 7 8 9 10 11 12
(2)
13 14 15 16 17 18 19
(2)   (3) (5) (3)
20 21 22 23 24 25 26
(2)
27 28 29 30 31
(3)
 docutils-checkins docutils-users docutils-develop Nested Flat Threaded Ultimate Show 25 Show 50 Show 75 Show 100
 [Docutils-develop] C reStructuredText parser From: Marvin Humphrey - 2012-05-16 14:35 Hello, There's a C project I'm involved with where it might make sense to use the reStructuredText format, but the portability and dependency policies mandate only C dependencies, so we can't use docutils. I looked around for a reStructuredText parser implemented in C, but came up empty. Anybody know of one? If not, would it be realistic to attempt a parser based on the Lemon parser generator, which is an LALR(1) parser generator similar to yacc? I'm not a parsing guru, but I've had some success writing parsers with Lemon in the past. http://www.hwaci.com/sw/lemon/ Cheers, Marvin Humphrey 

 Re: [Docutils-develop] C reStructuredText parser From: Paul Tremblay - 2012-05-17 00:08 A c parser strikes me as useful. However, one problem with restructured text is the lack of a solid standard (no?). I believe the syntax is still being developed. Paul On 5/16/12 9:40 AM, Marvin Humphrey wrote: > Hello, > > There's a C project I'm involved with where it might make sense to use the > reStructuredText format, but the portability and dependency policies mandate > only C dependencies, so we can't use docutils. > > I looked around for a reStructuredText parser implemented in C, but came up > empty. Anybody know of one? > > If not, would it be realistic to attempt a parser based on the Lemon > parser generator, which is an LALR(1) parser generator similar to yacc? I'm > not a parsing guru, but I've had some success writing parsers with Lemon > in the past. > > http://www.hwaci.com/sw/lemon/ > > Cheers, > > Marvin Humphrey > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Docutils-develop mailing list > Docutils-develop@... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > > Please use "Reply All" to reply to the list. 

 Re: [Docutils-develop] C reStructuredText parser From: David Goodger - 2012-05-17 00:46 On Wed, May 16, 2012 at 8:08 PM, Paul Tremblay wrote: > A c parser strikes me as useful. However, one problem with restructured > text is the lack of a solid standard (no?). I believe the syntax is > still being developed. This is just FUD. The standard is as solid as anything in software, short of an ISO/IEEE standard. The basic syntax has been established and has been used for over 10 years. I don't foresee any significant incompatible changes to the syntax. There will undoubtedly be additions, as there is in any evolving project. Please avoid spreading FUD. -- David Goodger > On 5/16/12 9:40 AM, Marvin Humphrey wrote: >> Hello, >> >> There's a C project I'm involved with where it might make sense to use the >> reStructuredText format, but the portability and dependency policies mandate >> only C dependencies, so we can't use docutils. >> >> I looked around for a reStructuredText parser implemented in C, but came up >> empty.  Anybody know of one? >> >> If not, would it be realistic to attempt a parser based on the Lemon >> parser generator, which is an LALR(1) parser generator similar to yacc?  I'm >> not a parsing guru, but I've had some success writing parsers with Lemon >> in the past. >> >>      http://www.hwaci.com/sw/lemon/ >> >> Cheers, >> >> Marvin Humphrey 

 Re: [Docutils-develop] C reStructuredText parser From: David Goodger - 2012-05-17 00:58 On Wed, May 16, 2012 at 9:40 AM, Marvin Humphrey wrote: > There's a C project I'm involved with where it might make sense to use the > reStructuredText format, but the portability and dependency policies mandate > only C dependencies, so we can't use docutils. Seems short-sighted. Perhaps it would be easier to push for an exception. > I looked around for a reStructuredText parser implemented in C, but came up > empty.  Anybody know of one? I don't know of anything. The most up-to-date resource I know of for tools using and implementing reST is http://stackoverflow.com/questions/2746692/restructuredtext-tool-support > If not, would it be realistic to attempt a parser based on the Lemon > parser generator, which is an LALR(1) parser generator similar to yacc?  I'm > not a parsing guru, but I've had some success writing parsers with Lemon > in the past. > >    http://www.hwaci.com/sw/lemon/ No idea. The reST parser is completely home-grown, and doesn't use any kind of parser generator. Be warned: reST is a two-dimensional markup language. Indentation is significant, as well as specific amounts of relative indentation (e.g., things that line up belong at the same level). Like the Python language, but sometimes more exacting. The most extreme example is tables. The table parser is implemented like a graphic edge-detecting algorithm. IOW, it would be a significant task to reimplement the reST parser. You may want to look for tools that already exist in the C world, even if you have to settle for what you may think is an inferior markup language. -- David Goodger 

 Re: [Docutils-develop] C reStructuredText parser From: Stefan Merten - 2012-05-17 13:23 Attachments: Message as HTML Hi Marvin! Yesterday Marvin Humphrey wrote: > If not, would it be realistic to attempt a parser based on the Lemon > parser generator, which is an LALR(1) parser generator similar to yacc? The main question is whether you can squeeze reStructuredText syntax into a LALR(1) (or any other recursive) grammar. Frankly I doubt this. One of the beauties of reStructuredText is that it is very readable / writable for humans - which more or less implies that it is difficult to parse. However, it could be worth a try to at least cover a significant subset of reStructuredText by a formal grammar. This would open the door for reStructuredText parsers in other programming languages, too. IMHO this would be a worthwhile goal. In the past I worked with formal grammars a couple of times. May be I can help a bit here. However, don't hold your breath for a reaction from me ;-) . Grüße Stefan 

 Re: [Docutils-develop] C reStructuredText parser From: Stefan Merten - 2012-05-17 14:03 Attachments: Message as HTML Hi Marvin! 38 minutes ago Stefan Merten wrote: > Yesterday Marvin Humphrey wrote: >> If not, would it be realistic to attempt a parser based on the Lemon >> parser generator, which is an LALR(1) parser generator similar to yacc? > > The main question is whether you can squeeze reStructuredText syntax > into a LALR(1) (or any other recursive) grammar. Normally you start with the tokens for a grammar. I wrote a good part of rst.el and there is rst-re-alist-def which defines a lot of regular expressions for matching reStructuredText stuff. May be this could be used for a start. You find rst.el at http://docutils.svn.sourceforge.net/svnroot/docutils/trunk/docutils/tools/editors/emacs/rst.el Grüße Stefan 

 Re: [Docutils-develop] C reStructuredText parser From: Marvin Humphrey - 2012-05-18 22:07 On Wed, May 16, 2012 at 5:57 PM, David Goodger wrote: > On Wed, May 16, 2012 at 9:40 AM, Marvin Humphrey wrote: >> There's a C project I'm involved with where it might make sense to use the >> reStructuredText format, but the portability and dependency policies mandate >> only C dependencies, so we can't use docutils. > > Seems short-sighted. Perhaps it would be easier to push for an exception. :) The project is Apache Lucy. Our portability and dependency goals are to build on all common operating systems and to require only a C compiler environment (C99/C++ compiler, Make, linker, etc.) in addition to the dynamic language "host" which the Lucy C core gets bound to. These requirements are very unlikely to be relaxed -- if it came down to choosing between a different lightweight markup language and adding Python as a mandatory dependency, we would go with a different lightweight markup language. > IOW, it would be a significant task to reimplement the reST parser. > You may want to look for tools that already exist in the C world, even > if you have to settle for what you may think is an inferior markup > language. It's not essential that this task consume an absolute minimum of engineering hours. So long as it looks like the parser I write will ultimately be used by Lucy, I'm happy to at least spend a few days getting something up and running -- I'd do it partly for work, partly for fun, partly to learn more about parsing, and partly for the public good. Besides, the hard work you've put in building consensus and writing a canonical spec may benefit us: http://markmail.org/message/s5bs5ik5gusga3ws In my opinion, our number one priority should be to commit to an external spec that is carved in stone. Debating lightweight markup syntax might be even less fun than debating query parser syntax. :P By implementing an authoritative spec, we limit the scope of debate and shut down a lot of bikeshedding before it starts. Our use case is embedding lightweight markup in C-style comments: /** Do some stuff with foo and bar. * * :param foo: a Foo. * :param bar: a Bar. * :return: true on success, false on failure. */ The content will be transformed into the native document format of the host language: POD for Perl, RDoc for Ruby, etc. We originally considered a hybrid of Markdown and Javadoc/Doxygen-style @tags, but are now evaluating reStructuredText. Marvin Humphrey 

 Re: [Docutils-develop] C reStructuredText parser From: Marvin Humphrey - 2012-05-18 23:00 On Thu, May 17, 2012 at 6:22 AM, Stefan Merten wrote: > Yesterday Marvin Humphrey wrote: >> If not, would it be realistic to attempt a parser based on the Lemon >> parser generator, which is an LALR(1) parser generator similar to yacc? > > The main question is whether you can squeeze reStructuredText syntax > into a LALR(1) (or any other recursive) grammar. Frankly I doubt this. FWIW, I'm not wedded to Lemon, only to C. Lemon is convenient because it's easy to add as a bundled dependency: tiny (2 C files), compiles everywhere, and public domain so no licensing restrictions. But one of the questions I'd have here is whether it makes more sense to approach parsing RST from the top down (LL, recursive descent) or from the bottom up (LR, LALR). If the reference parser for RST uses something like an extremely complex regular expression, maybe it makes sense to hand-code a recursive descent parser? http://en.wikipedia.org/wiki/Recursive_descent_parser#C_implementation It might be worthwhile to collect some opinions on stackoverflow.com. And maybe it's time I bought the Dragon book and read the chapter on parsing. :) > However, it could be worth a try to at least cover a significant > subset of reStructuredText by a formal grammar. Agreed. Marvin Humphrey 

 Re: [Docutils-develop] C reStructuredText parser From: David Goodger - 2012-05-29 18:54 On Fri, May 18, 2012 at 6:30 PM, Marvin Humphrey wrote: > But one of the questions I'd have here is whether it makes more sense to > approach parsing RST from the top down (LL, recursive descent) or from the > bottom up (LR, LALR).  If the reference parser for RST uses something like an > extremely complex regular expression, maybe it makes sense to hand-code a > recursive descent parser? > >    http://en.wikipedia.org/wiki/Recursive_descent_parser#C_implementation I've forgotten most of what I ever knew about formal parsing, and I didn't approach writing the reST parser in a formal way. The reST parser grew from a finite state machine that I wrote to filter log files in a complex way (e.g. "give me lines that begin with X within 10 lines of lines that contain Y but not after lines that contain Z"). The module docstring of docutils.parsers.rst.states contains a "Parser Overview" (http://docutils.sourceforge.net/docutils/parsers/rst/states.py). It begins, "The reStructuredText parser is implemented as a recursive state machine, examining its input one line at a time." > It might be worthwhile to collect some opinions on stackoverflow.com.  And > maybe it's time I bought the Dragon book and read the chapter on parsing. :) You can't go wrong reading the Dragon book. And if you do post on stackoverflow, please provide a link here. -- David Goodger 

 Re: [Docutils-develop] C reStructuredText parser From: Marvin Humphrey - 2012-05-29 20:49 On Tue, May 29, 2012 at 11:53 AM, David Goodger wrote: > The module docstring of docutils.parsers.rst.states contains a "Parser Overview" > (http://docutils.sourceforge.net/docutils/parsers/rst/states.py). It > begins, "The reStructuredText parser is implemented as a recursive > state machine, examining its input one line at a time." I've been gathering information, and I think that whatever choice we make, we will want to avoid backtracking if we can. That may help to make the parser more suitable for web environments, as it will be more resistant to algorithmic complexity attacks. I think that points towards a bottom-up approach, but I'm not quite that far along yet. >> It might be worthwhile to collect some opinions on stackoverflow.com.  And >> maybe it's time I bought the Dragon book and read the chapter on parsing. :) > > You can't go wrong reading the Dragon book. I wound up deciding on two other books instead. :) Going slowly and thoroughly, I'm about 50 pages in on this one: Parsing Techniques: A Practical Guide Dick Grune and Ceriel Jacobs http://www.amazon.com/Parsing-Techniques-Practical-Monographs-Computer/dp/1441919015/ I'm reading the second edition from 2008, but for those who might be interested, the 1990 first edition is available as a free download. http://www.dickgrune.com/Books/PTAPG_1st_Edition/ And then there's this book, which a handful of people from the Apache Lucy community plan to study together: Programming Language Pragmatics Michael L. Scott http://www.amazon.com/Programming-Language-Pragmatics-Third-Edition/dp/0123745144/ > And if you do post on stackoverflow, please provide a link here. Will do. I'm reasonably confident that after absorbing a few chapters from Grune's book I will be able to put together a coherent proposition and hold an intelligent conversation about the tradeoffs. Marvin Humphrey 

 [Docutils-develop] [ docutils-Bugs-3530517 ] rst2man does not escape '.' at the start of the line From: SourceForge.net - 2012-05-29 13:40 Bugs item #3530517, was opened at 2012-05-29 06:40 Message generated for change (Tracker Item Submitted) made by t-tujikawa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3530517&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: tujikawa (t-tujikawa) Assigned to: Nobody/Anonymous (nobody) Summary: rst2man does not escape '.' at the start of the line Initial Comment: rst2man does not escape '.' at the start of the line. As a result, if the world ".hello" is located at the start of the line, rst2man just copies the word unescaped and man(1) treats it as a macro and finally the word disappears. Example: $cat bug.rst TITLE ===== .hello world$ rst2man < bug.rst > bug.1 $cat bug.1 .TH TITLE "" "" "" .SH NAME TITLE \- .\" Man page generated from reStructeredText. . .sp .hello world .\" Generated by docutils manpage writer. .\" .$ # See .hello is copied verbatim. $man -l bug.1 TITLE() TITLE() NAME TITLE - world$ # See .hello disappeared. Version: docutils 0.8.1-6 Debian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3530517&group_id=38414 

 [Docutils-develop] [ docutils-Patches-3527397 ] Add indentation to literal blocks in manpage writer From: SourceForge.net - 2012-05-16 20:42 Patches item #3527397, was opened at 2012-05-16 13:42 Message generated for change (Tracker Item Submitted) made by joshuagraff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527397&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Graff (joshuagraff) Assigned to: Nobody/Anonymous (nobody) Summary: Add indentation to literal blocks in manpage writer Initial Comment: The current manpage writer does not add or maintain any type of indentation on literal blocks. Example: $cat example.rst ===== Title ===== :Version: 1.1 :Author: joe.user@... Example ======= Example::$ man ls $rst2man.py example.rst > example.man$ man ./example.man NAME Title - EXAMPLE Example: $man ls AUTHOR joe.user@... In the above example '$ man ls' starts at the same indentation level as 'Example:', which seems difficult to read. A solution that has worked well for me is to treat literal blocks like block quotes in the manpage writer. Example: $rst2man.py example.rst > example.man$ man ./example.man NAME Title - EXAMPLE Example: $man ls AUTHOR joe.user@... Attached is patch to indent literal blocks like block quotes which I hope others may find useful. -Josh ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527397&group_id=38414   [Docutils-develop] [ docutils-Patches-3527397 ] Add indentation to literal blocks in manpage writer From: SourceForge.net - 2012-05-25 04:23 Patches item #3527397, was opened at 2012-05-16 13:42 Message generated for change (Settings changed) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527397&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Graff (joshuagraff) >Assigned to: engelbert gruber (grubert) Summary: Add indentation to literal blocks in manpage writer Initial Comment: The current manpage writer does not add or maintain any type of indentation on literal blocks. Example:$ cat example.rst ===== Title ===== :Version: 1.1 :Author: joe.user@... Example ======= Example:: $man ls$ rst2man.py example.rst > example.man $man ./example.man NAME Title - EXAMPLE Example:$ man ls AUTHOR joe.user@... In the above example '$man ls' starts at the same indentation level as 'Example:', which seems difficult to read. A solution that has worked well for me is to treat literal blocks like block quotes in the manpage writer. Example:$ rst2man.py example.rst > example.man $man ./example.man NAME Title - EXAMPLE Example:$ man ls AUTHOR joe.user@... Attached is patch to indent literal blocks like block quotes which I hope others may find useful. -Josh ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527397&group_id=38414 

 [Docutils-develop] [ docutils-Patches-3527401 ] manpage writer addmonition's don't preserve indentation From: SourceForge.net - 2012-05-16 21:12 Patches item #3527401, was opened at 2012-05-16 14:12 Message generated for change (Tracker Item Submitted) made by joshuagraff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527401&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Graff (joshuagraff) Assigned to: Nobody/Anonymous (nobody) Summary: manpage writer addmonition's don't preserve indentation Initial Comment: In the manpage writer admonitions use troff's .IP/.RE for paragraph indentation. This unfortunately does not appear to preserve indentation for bullets and other block types (literal) that might be contained within an admonition. Example: $cat example.rst ===== Title ===== :Version: 1.1 :Author: joe.user@... Example ======= This is an example. .. NOTE:: This is an important note. * Bullet Example::$ man ls $rst2man.py example.rst > example.man$ ./example.man NAME Title - EXAMPLE This is an example. Note This is an important note. o Bullet Example: $man ls AUTHOR joe.user@... In the above example both the bullet and literal block start at the same indentation level as 'Note'. A solution that has worked well for me is to treat admonitions as block quotes with a strong heading. Example:$ rst2man.py example.rst > example.man $man ./example.man NAME Title - EXAMPLE This is an example. NOTE: This is an important note. o Bullet Example:$ man ls AUTHOR joe.user@... Please note the missing indentation of the literal block 'Example:' is described in patch item #3527397. Attached is a patch with the changes described above which I hope other may find useful. -Josh ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527401&group_id=38414 

 [Docutils-develop] [ docutils-Patches-3527401 ] manpage writer addmonition's don't preserve indentation From: SourceForge.net - 2012-05-25 04:22 Patches item #3527401, was opened at 2012-05-16 14:12 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527401&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Graff (joshuagraff) >Assigned to: engelbert gruber (grubert) Summary: manpage writer addmonition's don't preserve indentation Initial Comment: In the manpage writer admonitions use troff's .IP/.RE for paragraph indentation. This unfortunately does not appear to preserve indentation for bullets and other block types (literal) that might be contained within an admonition. Example: $cat example.rst ===== Title ===== :Version: 1.1 :Author: joe.user@... Example ======= This is an example. .. NOTE:: This is an important note. * Bullet Example::$ man ls $rst2man.py example.rst > example.man$ ./example.man NAME Title - EXAMPLE This is an example. Note This is an important note. o Bullet Example: $man ls AUTHOR joe.user@... In the above example both the bullet and literal block start at the same indentation level as 'Note'. A solution that has worked well for me is to treat admonitions as block quotes with a strong heading. Example:$ rst2man.py example.rst > example.man $man ./example.man NAME Title - EXAMPLE This is an example. NOTE: This is an important note. o Bullet Example:$ man ls AUTHOR joe.user@... Please note the missing indentation of the literal block 'Example:' is described in patch item #3527397. Attached is a patch with the changes described above which I hope other may find useful. -Josh ---------------------------------------------------------------------- >Comment By: engelbert gruber (grubert) Date: 2012-05-24 21:22 Message: * needs to pass sandbox/manpage-writer (obviously test will need change) * check against mercurial * maybe mplayer also uses manpage-writer in progress ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3527401&group_id=38414 

 [Docutils-develop] [ docutils-Bugs-3527842 ] Extra directories for python 3 From: SourceForge.net - 2012-05-18 11:40 Bugs item #3527842, was opened at 2012-05-18 04:40 Message generated for change (Tracker Item Submitted) made by toddrme2178 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3527842&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Todd Rme (toddrme2178) Assigned to: Nobody/Anonymous (nobody) Summary: Extra directories for python 3 Initial Comment: When compiling docutils 9 for python 3 I get the same directories I get with python 2: {root}/{prefix}/bin/ {root}/{prefix}/{site-packages}/docutils/ However, I also extra directories that are not present in the python 2 version. These are: {root}/{prefix}/{site-packages}/test/ {root}/{prefix}/{site-packages}/tools/ I was told that these directories are not supposed to be there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3527842&group_id=38414 

 [Docutils-develop] [Latex support in docutils] Problem with the restructuredtext reference. From: David Kremer - 2012-05-14 13:25 Hello, I tried to compile the restructured text reference manual with rst2latex, and I had several warnings in doing so : #!/bin/bash mkdir tmp && cd tmp wget http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.txt rst2latex2 restructuredtext.txt rst.tex pdflatex rst.tex We have problems with references, and some chars are not translated properly. However it works rather well. But do you think it would be a good idea to propose a fix for perfectionnists ? Cheers, David 

 Re: [Docutils-develop] [Latex support in docutils] Problem with the restructuredtext reference. From: Guenter Milde - 2012-05-14 14:14 On 2012-05-14, David Kremer wrote: > Hello, > I tried to compile the restructured text reference manual with > rst2latex, and I had several warnings in doing so : > #!/bin/bash > mkdir tmp && cd tmp > wget http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.txt > rst2latex2 restructuredtext.txt rst.tex > pdflatex rst.tex > We have problems with references, and some chars are not translated > properly. However it works rather well. But do you think it would be a > good idea to propose a fix for perfectionnists ? There can be several reasons for the problems. A detailled description of the used programs (and versions) and the warnings/errors is welcome, as are suggestions for improvement. (Patches will need revision/discussion before application, so instead of preparing the perfect patch start in pieces.) Thanks, Günter 

 [Docutils-develop] [ docutils-Bugs-3525847 ] test_directives/test_include.py: UnicodeEncodeError From: SourceForge.net - 2012-05-11 14:18 Bugs item #3525847, was opened at 2012-05-11 07:18 Message generated for change (Tracker Item Submitted) made by jakub-wilk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3525847&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakub Wilk (jakub-wilk) Assigned to: Nobody/Anonymous (nobody) Summary: test_directives/test_include.py: UnicodeEncodeError Initial Comment: If LC_ALL=C is set to C, test_directives/test_include.py fails with UnicodeEncodeError: $LC_ALL=C python test/test_parsers/test_rst/test_directives/test_include.py ................E............. ====================================================================== ERROR: test/test_parsers/test_rst/test_directives/test_include.py: totest['include'][14]; test_parser (DocutilsTestSupport.ParserTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/docutils-0.9/test/DocutilsTestSupport.py", line 456, in test_parser self.parser.parse(self.input, document) File "/tmp/docutils-0.9/docutils/parsers/rst/__init__.py", line 162, in parse self.statemachine.run(inputlines, document, inliner=self.inliner) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 174, in run input_source=document['source']) File "/tmp/docutils-0.9/docutils/statemachine.py", line 239, in run context, state, transitions) File "/tmp/docutils-0.9/docutils/statemachine.py", line 460, in check_line return method(match, context, next_state) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2279, in explicit_markup nodelist, blank_finish = self.explicit_construct(match) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2291, in explicit_construct return method(self, expmatch) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2034, in directive directive_class, match, type_name, option_presets) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2083, in run_directive result = directive_instance.run() File "/tmp/docutils-0.9/docutils/parsers/rst/directives/misc.py", line 75, in run handle_io_errors=None) File "/tmp/docutils-0.9/docutils/io.py", line 222, in __init__ self.source = open(source_path, mode, **kwargs) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) ---------------------------------------------------------------------- Ran 30 tests in 0.396s FAILED (errors=1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3525847&group_id=38414   [Docutils-develop] [ docutils-Bugs-3525847 ] test_directives/test_include.py: UnicodeEncodeError From: SourceForge.net - 2012-05-11 20:59 Bugs item #3525847, was opened at 2012-05-11 07:18 Message generated for change (Comment added) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3525847&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jakub Wilk (jakub-wilk) Assigned to: Nobody/Anonymous (nobody) Summary: test_directives/test_include.py: UnicodeEncodeError Initial Comment: If LC_ALL=C is set to C, test_directives/test_include.py fails with UnicodeEncodeError:$ LC_ALL=C python test/test_parsers/test_rst/test_directives/test_include.py ................E............. ====================================================================== ERROR: test/test_parsers/test_rst/test_directives/test_include.py: totest['include'][14]; test_parser (DocutilsTestSupport.ParserTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/docutils-0.9/test/DocutilsTestSupport.py", line 456, in test_parser self.parser.parse(self.input, document) File "/tmp/docutils-0.9/docutils/parsers/rst/__init__.py", line 162, in parse self.statemachine.run(inputlines, document, inliner=self.inliner) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 174, in run input_source=document['source']) File "/tmp/docutils-0.9/docutils/statemachine.py", line 239, in run context, state, transitions) File "/tmp/docutils-0.9/docutils/statemachine.py", line 460, in check_line return method(match, context, next_state) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2279, in explicit_markup nodelist, blank_finish = self.explicit_construct(match) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2291, in explicit_construct return method(self, expmatch) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2034, in directive directive_class, match, type_name, option_presets) File "/tmp/docutils-0.9/docutils/parsers/rst/states.py", line 2083, in run_directive result = directive_instance.run() File "/tmp/docutils-0.9/docutils/parsers/rst/directives/misc.py", line 75, in run handle_io_errors=None) File "/tmp/docutils-0.9/docutils/io.py", line 222, in __init__ self.source = open(source_path, mode, **kwargs) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) ---------------------------------------------------------------------- Ran 30 tests in 0.396s FAILED (errors=1) ---------------------------------------------------------------------- Comment By: Günter Milde (milde) Date: 2012-05-11 13:59 Message: Fixed; thanks for the bug report. You can download a current snapshot from: http://docutils.svn.sourceforge.net/viewvc/docutils/trunk/docutils/?view=tar ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3525847&group_id=38414 

 [Docutils-develop] [ docutils-Bugs-3495454 ] http://diveintopython.org/ is gone From: SourceForge.net - 2012-05-03 13:14 Bugs item #3495454, was opened at 2012-02-28 15:39 Message generated for change (Settings changed) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3495454&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Jakub Wilk (jakub-wilk) Assigned to: Nobody/Anonymous (nobody) Summary: http://diveintopython.org/ is gone Initial Comment: roman.py contains the following text: This program is part of "Dive Into Python", a free Python tutorial for experienced programmers. Visit http://diveintopython.org/ for the latest version. However, http://diveintopython.org/ currently reads: The requested resource / is no longer available on this server and there is no forwarding address. Please remove all references to this resource. You might want to remove the URL, or maybe point the mirror that apparently someone provides: http://www.diveintopython.net/ ---------------------------------------------------------------------- Comment By: Günter Milde (milde) Date: 2012-03-30 05:10 Message: We ship an unaltered "backup copy" of roman.py to ensure working without external requirements. The same version (1.4 from 8 August 2001) is e.g. installed by the Debian package python-roman. IMV it is better not to patch this external module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3495454&group_id=38414 

 [Docutils-develop] [ docutils-Bugs-2993756 ] PIL import error From: SourceForge.net - 2012-05-03 09:51 Bugs item #2993756, was opened at 2010-04-28 11:44 Message generated for change (Settings changed) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=2993756&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jared () Assigned to: Nobody/Anonymous (nobody) Summary: PIL import error Initial Comment: Docutils uses "import Image" to use the Python Imaging Library, which conflicts with django's "from PIL import Image" (essentially the module is imported twice and chokes. See this post http://jaredforsyth.com/blog/2010/apr/28/accessinit-hash-collision-3-both-1-and-1/ for more info). I've attached a patch which fixes this problem. ---------------------------------------------------------------------- >Comment By: Günter Milde (milde) Date: 2012-05-03 02:51 Message: The momentom seems to go towards PIL.Image: The PIL documentation has both variants: http://www.pythonware.com/library/pil/handbook/image.htm uses from PIL import Image. Fredrik Lundh pronounced at http://mail.python.org/pipermail/image-sig/2011-January/006650.html that as of PIL 1.2 pre-alpha "PIL now lives in the PIL namespace only". So it would be more future-proof to change all "import Image" statements to "from PIL import Image". Pygments (now also imported by Docutils for code highlight uses "from PIL import ..." in recent versions. Docutils 0.9(svn) uses try: # check for the Python Imaging Library import PIL except ImportError: try: # sometimes PIL modules are put in PYTHONPATH's root import Image class PIL(object): pass # dummy wrapper PIL.Image = Image except ImportError: PIL = None since Dec 2011. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2010-04-28 13:08 Message: The PIL docs (http://www.pythonware.com/library/pil/handbook/introduction.htm) say to use "import Image". If we change Docutils, it may just break somebody else's code. Closing as "invalid": this is a PIL problem. Try this workaround in your own code (import PIL.Image once in advance, and make multiple references in Python's modules table): >>> import sys >>> import PIL.Image >>> sys.modules['Image'] = PIL.Image >>> import Image >>> from PIL import Image as Image2 >>> id(Image) 9901296 >>> id(PIL.Image) 9901296 >>> id(Image2) 9901296 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2010-04-28 12:34 Message: PIL has long had this split personality, where it tries to support both ways of using it. (This is an insane behavior on PIL's part.) Apps I'm involved in use "from PIL import Image". I've no hope that PIL will ever be changed to require one or the other uses, and I'm not sure I would advocate doing so, because either is likely to break some non-trivial number of apps. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2010-04-28 12:25 Message: Can you provide some evidence please? A URL to an authoritative doc would be best. Your blog post refers to three projects, two of which use the "non-standard" form... which pre-date the project using the "standard" form. I'm leaning toward "won't fix". ---------------------------------------------------------------------- Comment By: Jared () Date: 2010-04-28 12:15 Message: From looking around, I have determined that "from PIL import Image" is the more accepted, standard usage. I would also hope to change PIL such that "import Image" would be impossible, but indeed that seems unlikely to happen. Although whichever way docutils implements there will still be a way to break it, would suggest working toward standardization. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2010-04-28 12:07 Message: Perhaps it's Django that's the real problem? Or PIL/Image itself? (Or maybe an import problem in Python?) If we fix this here, won't projects that use Docutils and also do "import Image" see the same problem? I'd like to see some justification as to why this is problem for Docutils to fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=2993756&group_id=38414 

 [Docutils-develop] release 0.9 From: engelbert gruber - 2012-05-02 19:37 Release 0.9 (2012-05-02) bigger changes are General: - reStructuredText "code" role and directive with syntax highlighting by Pygments. "code" option of the "include" directive. - Fix [ 3402314 ] allow non-ASCII whitespace, punctuation characters and "international" quotes around inline markup. - Fix handling of missing stylesheets. setup.py - Fix [ 2971827 ] and [ 3442827 ] extras/roman.py moved to docutils/utils/roman.py docutils/utils.py -> docutils/utils/__init__.py - docutils.utils is now a package (providing a place for sub-modules) docutils/writers/html4css1/__init__.py - change default for math-output setting to MathJax docutils/writers/latex2e/__init__.py - Support the abbreviation and acronym standard roles. - Record only files required to generate the LaTeX source as dependencies. - Use \setcounter{secnumdepth}{0} instead of *-versions when suppressing LaTeX section numbering. please report any problems all the best engelbert -- http://darefoot.blogspot.com 

 [Docutils-develop] [ docutils-Bugs-3519169 ] rst2pdf crashes in spanFixDim() From: SourceForge.net - 2012-05-02 08:33 Bugs item #3519169, was opened at 2012-04-18 08:26 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3519169&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Hunt (jamesodhunt) Assigned to: Nobody/Anonymous (nobody) Summary: rst2pdf crashes in spanFixDim() Initial Comment: I have a large rst document [1] which passes through 'rst2html --strict' correctly but which fails with rst2pdf: rst2pdf -o /tmp/upstart_cookbook.pdf /tmp/upstart_cookbook.rst Traceback (most recent call last): File "/usr/bin/rst2pdf", line 9, in load_entry_point('rst2pdf==0.16', 'console_scripts', 'rst2pdf')() File "/usr/lib/pymodules/python2.7/rst2pdf/createpdf.py", line 1456, in main compressed=options.compressed) File "/usr/lib/pymodules/python2.7/rst2pdf/createpdf.py", line 666, in createPdf pdfdoc.multiBuild(elements) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/doctemplate.py", line 960, in multiBuild self.build(tempStory, **buildKwds) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/doctemplate.py", line 880, in build self.handle_flowable(flowables) File "/usr/lib/pymodules/python2.7/rst2pdf/createpdf.py", line 774, in handle_flowable if frame.add(f, canv, trySplit=self.allowSplitting): File "/usr/lib/pymodules/python2.7/rst2pdf/flowables.py", line 555, in add return Frame.add(self, flowable, canv, trySplit) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/frames.py", line 159, in _add w, h = flowable.wrap(aW, h) File "/usr/lib/pymodules/python2.7/rst2pdf/flowables.py", line 233, in wrap return self.t.wrap(w, h) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/tables.py", line 1113, in wrap self._calc(availWidth, availHeight) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/tables.py", line 587, in _calc self._calc_height(availHeight,availWidth,W=W) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/tables.py", line 553, in _calc_height spanFixDim(H0,H,spanCons,lim=hmax) File "/usr/lib/python2.7/dist-packages/reportlab/platypus/tables.py", line 205, in spanFixDim t = sum([V[x]+M.get(x,0) for x in xrange(x0,x1)]) TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' $dpkg -l |grep docutils|awk '{print$2, $3}' docutils-common 0.8.1-4ubuntu1 docutils-doc 0.8.1-4ubuntu1 python-docutils 0.8.1-4ubuntu1$ [1] - http://bazaar.launchpad.net/~upstart-documenters/upstart-cookbook/trunk/view/head:/upstart_cookbook.rst ---------------------------------------------------------------------- >Comment By: engelbert gruber (grubert) Date: 2012-05-02 01:33 Message: rst2pdf is a separate project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3519169&group_id=38414