gmane.text.docutils.devel

Re: rst2odp released into wild...

David Goodger — 2008-12-03T16:09:23

I couldn't use reST for Impress before, so I never tried it. Now that I can use reST, I will try it. I don't know what the advantages & disadvantages are. S5 only requires a browser, no extra software to install. We can put presentations on the web directly. If the ODP writer is compatible with the S5 writer (i.e. uses the same reST source), we can still put presentations on the web. Is it? Incremental mode is a biggie. Of course a tool like OO.o Impress will be more powerful and tweakable than S5 in many ways. The whole point of using reST is that we don't want to waste time tweaking in a GUI.

Re: rst2odp released into wild...

m h — 2008-12-03T15:55:35

;) My question to you is how is S5 better (for you) than impress? What are the advantages of S5? Unless they went a route similar to creating odplib (ie create a module for creating odt from python which has nothing to do with rst), I don't think there are reasons to merge back to the ODT writer. Keeping track of the state in the translator is too much for my brain. It was sort of an epiphany for me to pull out the odplib. I would actually recommend it to anyone creating a semi complex translator. It's much easier to test, there's now a library for people to use, and I actually think it makes it easier to work on the translator. (Again, those are my feelings, after 3 attempts at creating a translator). Ok, I see it as a logical migration path from S5, so I think that answers my questions. Ok, I'll put that on my list. You haven't happened to play with animations in Impress? I haven't really so if someone has and nows how to do 'incremental' type stuff, please let me know. Ok, my documentation c

Re: rst2odp released into wild...

David Goodger — 2008-12-03T14:18:12

... Congrats! Progress on S5 certainly is dormant, maybe pining for the fjords, but I wouldn't call it dead. S5 is still useful and used. Would improvements to the ODT writer solve that? You can add it to Docutils, an established, well-known project. Or you can create a new project for it, which will take time to become known. If you want rst2odp to be used widely, Docutils is the logical place to put it. Otherwise it may just languish in obscurity. I do, heavily. Lack of incremental support would be a blocker for me. As long as it has a well-thought-out and well-documented mapping from source document (Docutils doctree, from reST) to target document, anything goes. IOW, avoid surprising behavior.

rst2odp released into wild...

m h — 2008-12-03T06:17:38

Folks- I've released an alpha of rst2odp on my blog[0]. I think it is (or should be) a viable replacement for anyone using rst2s5, since s5 appears to be dead (and has some drawbacks due to it's browser based architecture). You might be wondering why I haven't been pushing changes to the OdtWriter in svn. Here's a semi quick version. My first rst2odp was homegrown and checked into svn. I was then asked why I didn't build upon the existing odtwriter. It seemed like a good idea at the time since they appeared to have solved many of the issues I hit with my initial version, and hey code re-use is great and all that. It went good for a while but I started hitting corner cases. OOo impress is picky about xml and apparently OOo writer isn't. I was crashing impress pretty easily. But the biggest problem was keeping track of the state during translation. How to get around that? Well, be able to test. But testing was kind of one step removed. What I really wanted was an odp library that I could use to

Re: [Docutils-checkins] r5739 - in trunk/docutils: HISTORY.txt test/test_functional.py tools/buildhtml.py

2008-12-01T07:24:26

Sorry fixed. On Sun, 30 Nov 2008, David Goodger wrote:

Re: Python 3.0 porting types diff

Aahz — 2008-12-01T04:51:51

Works for me: 2.2 was released 12/2001 and 2.3 was released 7/2003.

Re: Python 3.0 porting types diff

David Goodger — 2008-11-30T17:44:55

We could drop Python 2.2 compatibility for Docutils 0.6+. Any objections? Patches that are sent to mailing lists are sometimes lost. We should use the same rules as python-dev. And SF isn't *that* bad. ;-)

Re: [Docutils-checkins] r5739 - intrunk/docutils: HISTORY.txt test/test_functional.pytools/buildhtml.py

David Goodger — 2008-11-30T17:40:34

This patch doesn't do anything; it doesn't introduce os.walk. Please fix or revert.

Re: Python 3.0 porting types diff

2008-11-30T16:16:15

run the tests now and then against 2.2 to 2.6. i will do it more often if need arises or someone requests no idea. the longer the better i think. it is not mandatory in this project, if you dont wantg to, patches might get lost easier in email. all the best

Re: Python 3.0 porting types diff

Peter Funk — 2008-11-30T12:15:52

Hello all, Georg Brandl asked Sunday, 30.11.2008 at 11:52: ... Disclaimer: I can't speak for the docutils development, because I didn't contribute anything here during the last years. I'm working as a software developer since 1986. With my personal experience I would say that keeping backward compatibility has been proven to be a very worthwhile good which shouldn't be dropped lightheaded. My company has still customers out there running rather old systems where Python 1.5.2 was the default /usr/bin/python included with the OS distribution. ;-) Fortunately we are using doc-utils only inhouse and the oldest server in use with has already Python 2.4.3. As general rules of thumb for packages trying to gain good platform portability I would suggest the following: * Don't rely on any new programming language features, unless they were available eight years ago. * Don't rely on operating system features, unless they were available ten years ago. Of course there is always the option to work aro

Re: Python 3.0 porting types diff

Georg Brandl — 2008-11-30T10:52:58

grubert< at >users.sourceforge.net schrieb: OK, I didn't test that here. Maybe I really should build a Python 2.2 :-) Related question: For how long will the 2.2 compatibility requirement be upheld? I will if you insist, but I thought I'd spare everyone the trouble that is using SourceForge ;-) Georg

Re: Python 3.0 porting

2008-11-30T10:02:55

committed all three (as far as possible) cheers

Re: Python 3.0 porting

2008-11-30T09:53:08

2.2 does not have os.walk, i did put some try/except into fro 2.2. cheers

Re: Python 3.0 porting

2008-11-30T09:00:19

add SliceType to this. the rest is committed. thanks

Re: Python 3.0 porting types diff

2008-11-30T08:51:39

in python2.2 slice is a built-in function i guess that is why it says 'TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types' you could post the patches to sourceforge maybe , then we have a clearer subject line (and we might get bigger numbers on the change counters). but this is up to you cheers

Re: Python 3.0 porting

Georg Brandl — 2008-11-27T20:15:35

Georg Brandl schrieb: Third, even more trivial patch: return a boolean from __nonzero__. Georg Index: docutils/nodes.py =================================================================== --- docutils/nodes.py(Revision 5728) +++ docutils/nodes.py(Arbeitskopie) < at >< at > -58,7 +58,7 < at >< at > Use `len()` to check node length. Use `None` to represent a boolean false value. """ - return 1 + return True def __str__(self): return unicode(self).encode('raw_unicode_escape') < at >< at > -292,7 +292,7 < at >< at > def __new__(cls, data, rawsource=None): """Prevent the rawsource argument from propagating to str.""" return reprunicode.__new__(cls, data) - + def __init__(self, data, rawsource=''): self.rawsource = rawsource ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes

Re: Python 3.0 porting

Georg Brandl — 2008-11-27T20:14:17

Georg Brandl schrieb: Second (shorter) patch: get rid of os.path.walk. Georg Index: test/test_functional.py =================================================================== --- test/test_functional.py(Revision 5728) +++ test/test_functional.py(Arbeitskopie) < at >< at > -39,7 +39,16 < at >< at > os.chdir(DocutilsTestSupport.testroot) self.clear_output_directory() self.added = 0 - os.path.walk(join_path(datadir, 'tests'), self.walker, None) + for root, dirs, files in os.walk(join_path(datadir, 'tests')): + # Process all config files among `names` in `dirname`. A config + # file is a Python file (*.py) which sets several variables. + for name in files: + if name.endswith('.py') and not name.startswith('_'): + config_file_full_path = join_path(root, name) + self.addTestCase(FunctionalTestCase, 'test', None, None, + id=config_file_full_path, +

Re: Python 3.0 porting

Georg Brandl — 2008-11-27T19:55:18

Georg Brandl schrieb: OK, after the encouraging post from Alan I'll try to find a way to let 2to3 do all the work. It may also be possible to write custom fixers for 2to3 that fix things the stock tool can't generally do. I'll send patches for some changes that can be made without breaking any compatibility. The first removes all unnecessary use of the "types" module whose trivial attributes like StringType are gone in 3k. Usage of ClassType remains however and must (ATM) be fixed manually. Georg Index: test/package_unittest.py =================================================================== --- test/package_unittest.py(Revision 5728) +++ test/package_unittest.py(Arbeitskopie) < at >< at > -116,8 +116,7 < at >< at > continue if type(suite) == types.FunctionType: testSuite.addTest(suite()) - elif type(suite) == types.InstanceType \ - and isinstance(suite, unittest.TestSuite): + elif isinstance(suite, unittest.TestSuite):

Re: website updates: SF shell is back

Guenter Milde — 2008-11-27T08:33:14

David Goodger python.org> schrieb: With the remote server, I had to do the cleaning 3 times (locally|SVN, berlios/aux and SF). With local updates, files I remove from SF remain on the local contributors machines and will be restored with the next rsync (if no special care is taken). Günter ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Docutils-develop mailing list Docutils-develop< at >lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/docutils-develop Please use "Reply All" to reply to the list.

Re: website updates: SF shell is back

David Goodger — 2008-11-26T14:51:21

Maybe, I haven't checked. I'm inclined to abandon that approach though. I don't see how that would be any worse on a local build than on a remote server. It's not that big of a problem IMO. Can you explain further?

[ docutils-Bugs-2350865 ] Empty block commentscause wrong syntax coloring in Emacs

SourceForge.net — 2008-11-26T13:34:56

Bugs item #2350865, was opened at 2008-11-26 14:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=2350865&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: Jérôme M. Berger (voiz) Assigned to: Nobody/Anonymous (nobody) Summary: Empty block comments cause wrong syntax coloring in Emacs Initial Comment: The following example will be colored entirely as if it were a block comment, including the normal text line at the end: ====================8<-------------------- .. First comment paragraph .. .. Second comment paragraph Normal text -------------------->8==================== This is with the ``rst.el`` from version 0.5. -------------------------------------------