Menu
▾
▴
docutils-users
|
From: Tim D. <tu...@tu...> - 2013-03-17 03:27:57
|
I have a standard makefile I use to create a variety of output media from a given rst file. This recently stopped working on the Cygwin system I use for this task. Upon further review, I found that that when the rst2* programs run, they produce proper output, but when they complete, Python aborts. This is causing the makefile to terminate prematurely. I am also see this error when I attempt to produce html: <stdin>:: (ERROR/3) Cannot embed stylesheet '/home/luser/Docs/myproject/html4css1.css': No such file or directory Any ideas what's going on here? Cygwin is up-to-date and seems to otherwise be OK. The same rst file works fine on native Linux and FreeBSD systems. TIA, -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: Martin G. <mar...@gm...> - 2013-03-17 03:55:02
|
> <stdin>:: (ERROR/3) Cannot embed stylesheet '/home/luser/Docs/myproject/html4css1.css': No such file or directory > > > Any ideas what's going on here? Look at the mailing list archive in Gmane: http://news.gmane.org/gmane.text.docutils.user This particular issue was fixed yesterday and may very well be the cause of your premature Makefile termination. -Martin |
|
From: Tim D. <tu...@tu...> - 2013-03-17 03:58:26
|
On 03/16/2013 10:54 PM, Martin Gignac wrote: >> <stdin>:: (ERROR/3) Cannot embed stylesheet '/home/luser/Docs/myproject/html4css1.css': No such file or directory >> >> >> Any ideas what's going on here? > > Look at the mailing list archive in Gmane: > http://news.gmane.org/gmane.text.docutils.user > > This particular issue was fixed yesterday and may very well be the > cause of your premature Makefile termination. > > -Martin Many thanks, I'll look for a new nightly build. However, the python dumping problem also occurs with rst2latex.py rst2man.py ... Any theories on what is causing this? Thanks very much for your time ... |
|
From: Tim D. <tu...@tu...> - 2013-03-17 04:06:05
|
On 03/16/2013 10:58 PM, Tim Daneliuk wrote: > On 03/16/2013 10:54 PM, Martin Gignac wrote: >>> <stdin>:: (ERROR/3) Cannot embed stylesheet '/home/luser/Docs/myproject/html4css1.css': No such file or directory >>> >>> >>> Any ideas what's going on here? >> >> Look at the mailing list archive in Gmane: >> http://news.gmane.org/gmane.text.docutils.user >> >> This particular issue was fixed yesterday and may very well be the >> cause of your premature Makefile termination. >> >> -Martin > Many thanks, I'll look for a new nightly build. > > However, the python dumping problem also occurs with rst2latex.py > rst2man.py ... Any theories on what is causing this? > > Thanks very much for your time ... A quick followup: The latest build does, indeed, fix the css file problem and the makefile now works as expected (thanks!). BUT ... if I attempt to run an rst conversion from the command line like this, I get the dreaded python dump, although the output does appear to be created: rst2html.py <foo.py >foo.html Very strange... |
|
From: Tim D. <tu...@tu...> - 2013-03-17 04:09:07
|
On 03/16/2013 11:05 PM, Tim Daneliuk wrote: > On 03/16/2013 10:58 PM, Tim Daneliuk wrote: >> On 03/16/2013 10:54 PM, Martin Gignac wrote: >>>> <stdin>:: (ERROR/3) Cannot embed stylesheet '/home/luser/Docs/myproject/html4css1.css': No such file or directory >>>> >>>> >>>> Any ideas what's going on here? >>> >>> Look at the mailing list archive in Gmane: >>> http://news.gmane.org/gmane.text.docutils.user >>> >>> This particular issue was fixed yesterday and may very well be the >>> cause of your premature Makefile termination. >>> >>> -Martin >> Many thanks, I'll look for a new nightly build. >> >> However, the python dumping problem also occurs with rst2latex.py >> rst2man.py ... Any theories on what is causing this? >> >> Thanks very much for your time ... > > A quick followup: > > The latest build does, indeed, fix the css file problem and the makefile now works as > expected (thanks!). BUT ... if I attempt to run an rst conversion from the > command line like this, I get the dreaded python dump, although the output does > appear to be created: > > rst2html.py <foo.py >foo.html > > Very strange... Ooops, nevermind. That is not the case. I had some intermediate files around that made the makefile work. In a clean environment, the makefile still fails because of python bailing out ..... sigh. -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: Martin G. <mar...@gm...> - 2013-03-17 13:08:24
|
> In a clean environment, the makefile > still fails because of python bailing out ..... sigh. I don't run Python on Cygwin so probably won't be able to help, but out of curiosity: 1. What is the output of the "dump" in question? 2. If you make sure to temporarily move/delete _all_ Docutils configuration files (http://docutils.sourceforge.net/docs/user/config.html#configuration-files), do you still get the dump? -Martin |
|
From: Tim D. <tu...@tu...> - 2013-03-17 14:54:50
|
On 03/17/2013 08:07 AM, Martin Gignac wrote: >> In a clean environment, the makefile >> still fails because of python bailing out ..... sigh. > > I don't run Python on Cygwin so probably won't be able to help, but > out of curiosity: > > 1. What is the output of the "dump" in question? It prints some column headers but that's it. There's no actual content. > > 2. If you make sure to temporarily move/delete _all_ Docutils > configuration files > (http://docutils.sourceforge.net/docs/user/config.html#configuration-files), > do you still get the dump? None of these exist on the Cygwin system I am using. > > -Martin > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Docutils-users mailing list > Doc...@li... > https://lists.sourceforge.net/lists/listinfo/docutils-users > > Please use "Reply All" to reply to the list. > -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: Martin G. <mar...@gm...> - 2013-03-18 02:19:11
|
> It prints some column headers but that's it. There's no > actual content. Can you post the column headers in a mail, on the off chance it rings a bell? |
|
From: Tim D. <tu...@tu...> - 2013-03-18 02:35:02
|
On 03/17/2013 09:18 PM, Martin Gignac wrote: >> It prints some column headers but that's it. There's no >> actual content. > > Can you post the column headers in a mail, on the off chance it rings a bell? > Stack trace: Frame Function Args That's it. Once in a while, there is one line underneath this but it's not repeatable. I have done a complete and clean install of cygwin and docutils just to make sure I'm not a victim of a misconfigured cygwin setup but the problem persists. Thanks, -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: David G. <go...@py...> - 2013-03-18 02:44:54
|
Tim, I'm sorry you're having problems with Docutils. Unfortunately, you haven't provided us with enough information to diagnose the problem or to fix anything. We need to be able to replicate the behavior, and in order to do that we need *details*. Please see "How To Report A Bug" for tips: http://docutils.sourceforge.net/BUGS.html#how-to-report-a-bug Thanks! -- David Goodger <http://python.net/~goodger> |
|
From: Tim D. <tu...@tu...> - 2013-03-18 02:53:10
|
On 03/17/2013 09:44 PM, David Goodger wrote: > Tim, I'm sorry you're having problems with Docutils. Unfortunately, > you haven't provided us with enough information to diagnose the > problem or to fix anything. We need to be able to replicate the > behavior, and in order to do that we need *details*. > > Please see "How To Report A Bug" for tips: > http://docutils.sourceforge.net/BUGS.html#how-to-report-a-bug > > Thanks! > I'm aware of this David, but I am at a loss of how to provide you with more info. The problem is specific to docutils on cygwin. I can take the same source document and makefiles and it works swimmingly on FreeBSD and Linux. So .. there is something about the Cygwin/docutils combo that is suddenly broken. When I have a moment, I can provide the versions of cygwin, the OS, and Python that are in use. Beyond that. I'm not clear on what else you might find useful. If there's anything you'd find useful, do let me know and I'll be happy to dig it out for you. Unfortunately, I have no convenient access to another cygwin install to try this on to see if a different Windows OS variant makes the problem different. It seems that Python is blowing up but the most informative message I get is "Aborted" ... not real helpful. I will also try to run this with Python in verbose mode to see if that yields anything useful. -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: Tim D. <tu...@tu...> - 2013-03-18 03:13:48
Attachments:
docutils-run.txt
|
On 03/17/2013 09:52 PM, Tim Daneliuk wrote: > On 03/17/2013 09:44 PM, David Goodger wrote: >> Tim, I'm sorry you're having problems with Docutils. Unfortunately, >> you haven't provided us with enough information to diagnose the >> problem or to fix anything. We need to be able to replicate the >> behavior, and in order to do that we need *details*. >> >> Please see "How To Report A Bug" for tips: >> http://docutils.sourceforge.net/BUGS.html#how-to-report-a-bug >> >> Thanks! >> > > I'm aware of this David, but I am at a loss of how to provide you > with more info. The problem is specific to docutils on cygwin. > I can take the same source document and makefiles and it works > swimmingly on FreeBSD and Linux. So .. there is something about > the Cygwin/docutils combo that is suddenly broken. > > When I have a moment, I can provide the versions of cygwin, the OS, > and Python that are in use. Beyond that. I'm not clear on what else > you might find useful. > > If there's anything you'd find useful, do let me know and I'll be happy > to dig it out for you. > > Unfortunately, I have no convenient access to another cygwin install to try > this on to see if a different Windows OS variant makes the problem different. > It seems that Python is blowing up but the most informative message I > get is "Aborted" ... not real helpful. I will also try to run this > with Python in verbose mode to see if that yields anything useful. > > > Attached is a verbose run of the python output when running things from the command line. The latex file is produced, but I suspect the "Aborted" at the end is what is blowing out the makefile ... -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: Martin G. <mar...@gm...> - 2013-03-18 03:00:30
|
> Stack trace: > > Frame Function Args > > > That's it. Once in a while, there is one line underneath this but it's > not repeatable. Hmm, no clue then. Google does turn up some hits for Cygwin and stack traces. One of them suggests "rebasing" the Cygwin install (http://www.garethhunt.com/2008/02/11/cygwin-died-waiting-for-dll-loading/) but you said you re-installed from scratch already so... There's also a list of software known to sometimes wreak havoc on Cygwin: http://cygwin.com/faq/faq.using.html#faq.using.bloda Maybe you could use Python for Windows instead of the Cygwin version and use Microsoft's nmake if you're only using Cygwin because of Makefiles... -Martin |
|
From: Tim D. <tu...@tu...> - 2013-03-18 03:11:00
|
On 03/17/2013 10:00 PM, Martin Gignac wrote: >> Stack trace: >> >> Frame Function Args >> >> >> That's it. Once in a while, there is one line underneath this but it's >> not repeatable. > > Hmm, no clue then. Google does turn up some hits for Cygwin and stack > traces. One of them suggests "rebasing" the Cygwin install > (http://www.garethhunt.com/2008/02/11/cygwin-died-waiting-for-dll-loading/) > but you said you re-installed from scratch already so... > > There's also a list of software known to sometimes wreak havoc on > Cygwin: http://cygwin.com/faq/faq.using.html#faq.using.bloda > > Maybe you could use Python for Windows instead of the Cygwin version > and use Microsoft's nmake if you're only using Cygwin because of > Makefiles... > > -Martin > Well, I can always just do it on real *nix, but I thought the docutils should at least be aware of the issue. Thanks for taking the time to help in any case ... -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: engelbert g. <eng...@gm...> - 2013-03-18 08:53:30
|
On 18 March 2013 04:10, Tim Daneliuk <tu...@tu...> wrote: > Well, I can always just do it on real *nix, but I thought the docutils > should at least be aware of the issue. that stands correct , you did not file a bug ? cheers engelbert -- http://blog.jazsoup.net |
|
From: Guenter M. <mi...@us...> - 2013-03-18 09:30:52
|
Dear Tim,
On 2013-03-17, Tim Daneliuk wrote:
> I have a standard makefile I use to create a variety of output media from
> a given rst file. This recently stopped working on the Cygwin system
> I use for this task.
> Upon further review, I found that that when the rst2* programs
> run, they produce proper output, but when they complete,
> Python aborts. This is causing the makefile to terminate
> prematurely.
> I am also see this error when I attempt to produce html:
><stdin>:: (ERROR/3) Cannot embed stylesheet '/home/luser/Docs/myproject/html4css1.css': No such file or directory
> Any ideas what's going on here? Cygwin is up-to-date and seems to otherwise
> be OK. The same rst file works fine on native Linux and FreeBSD systems.
Thanks for the report. As already said, it is difficult to find the reason
without further info. I have some guesses, though:
* A common problem (and a nightmare for parallel Py2x and Py3x development)
are the encoding issues. It may well be that Cygwin adds to them in a way
that cannot be tested otherwhere.
The biggest problem was encoding errors preventing sensible error messages
--- errors when reporting an error. I thought to have them solved but
maybe some resurfaces in your case.
If you run one of the aborting commands from the command line and add the
--traceback command line option, do you get a traceback?
If yes, this would be an immense help, if no, the actuall error message
would still be valuable info.
* It may be that Cygwin uses a newer Python version than your alternatives.
There are several bugreports regarding Python beta versions that are not
handled yet because
+ we cannot reproduce them with the stable Python release (here on
Debian/testing).
+ some seem to be rather Python bugs than Docutils bugs and we prefer to
concentrate our scare recourses on the problems with stable releases.
(patches that anticipate problems with upcoming changes are welcome,
of course).
Could your try whether using an older Python version solves the problem?
Could you try with Python 3?
Thanks,
Günter
|
|
From: Tim D. <tu...@tu...> - 2013-03-18 14:59:56
|
On 03/18/2013 04:30 AM, Guenter Milde wrote:
<SNIP>
> Thanks for the report. As already said, it is difficult to find the reason
> without further info. I have some guesses, though:
>
> * A common problem (and a nightmare for parallel Py2x and Py3x development)
> are the encoding issues. It may well be that Cygwin adds to them in a way
> that cannot be tested otherwhere.
This seems likely. See below.
>
> The biggest problem was encoding errors preventing sensible error messages
> --- errors when reporting an error. I thought to have them solved but
> maybe some resurfaces in your case.
>
> If you run one of the aborting commands from the command line and add the
> --traceback command line option, do you get a traceback?
There is no traceback output. All I see is the aforementioned "Aborted"
message at the end of the run even though rst2* has done its job.
This is starting to look more and more like a Python-on-Cygwin problem
not a docutils problem. I think docutils may just have exposed the issue.
>
> If yes, this would be an immense help, if no, the actuall error message
> would still be valuable info.
>
> * It may be that Cygwin uses a newer Python version than your alternatives.
> There are several bugreports regarding Python beta versions that are not
> handled yet because
>
> + we cannot reproduce them with the stable Python release (here on
> Debian/testing).
> + some seem to be rather Python bugs than Docutils bugs and we prefer to
> concentrate our scare recourses on the problems with stable releases.
> (patches that anticipate problems with upcoming changes are welcome,
> of course).
I have tested this on Python 2.7.3 on both Cygwin (failed) and FreeBSD 9-STABLE
(successful).
I cannot test on Python 3.2.3 because when I attempt to install docutils under
Cygwin's Python 3 implementation, I see this:
byte-compiling /usr/lib/python3.2/site-packages/docutils/writers/xetex/__init__.py to __init__.cpython-32.pyc
File "/usr/lib/python3.2/site-packages/docutils/writers/xetex/__init__.py", line 117
self.literal_double_quote = u'"' # TODO: use \textquotedbl
^
SyntaxError: invalid syntax
byte-compiling /usr/lib/python3.2/site-packages/docutils/writers/__init__.py to __init__.cpython-32.pyc
byte-compiling /usr/lib/python3.2/site-packages/docutils/_compat.py to _compat.cpython-32.pyc
byte-compiling /usr/lib/python3.2/site-packages/docutils/__init__.py to __init__.cpython-32.pyc
File "/usr/lib/python3.2/site-packages/docutils/__init__.py", line 75
return u', '.join(self.args)
^
SyntaxError: invalid syntax
>
> Could your try whether using an older Python version solves the problem?
> Could you try with Python 3?
>
> Thanks,
>
> Günter
>
>
-----------------------------------------------------------------------
Tim Daneliuk
|
|
From: Guenter M. <mi...@us...> - 2013-03-21 08:00:44
|
Dear Tim, On 2013-03-18, Tim Daneliuk wrote: > On 03/18/2013 04:30 AM, Guenter Milde wrote: ... >> If you run one of the aborting commands from the command line and add the >> --traceback command line option, do you get a traceback? > There is no traceback output. All I see is the aforementioned "Aborted" > message at the end of the run even though rst2* has done its job. > This is starting to look more and more like a Python-on-Cygwin problem > not a docutils problem. I think docutils may just have exposed the issue. This is well possible. It may help to find a minimal example that exposes the problem: * Does it occur with every document (even an empty one)? * Does it occur with every front-end? If not, which ones? * Do config-settings/command line arguments influence the outcome? How? It may, of course also be a problem specific to your Cygwin installation/setup. Is there someone else using Docutils under Cygwin? > I have tested this on Python 2.7.3 on both Cygwin (failed) and FreeBSD > 9-STABLE (successful). OK, so this can be ruled out. > I cannot test on Python 3.2.3 because when I attempt to install > docutils under Cygwin's Python 3 implementation, I see this: > byte-compiling /usr/lib/python3.2/site-packages/docutils/writers/xetex/__init__.py to __init__.cpython-32.pyc > File "/usr/lib/python3.2/site-packages/docutils/writers/xetex/__init__.py", line 117 > self.literal_double_quote = u'"' # TODO: use \textquotedbl > ^ > SyntaxError: invalid syntax > byte-compiling /usr/lib/python3.2/site-packages/docutils/writers/__init__.py to __init__.cpython-32.pyc > byte-compiling /usr/lib/python3.2/site-packages/docutils/_compat.py to _compat.cpython-32.pyc > byte-compiling /usr/lib/python3.2/site-packages/docutils/__init__.py to __init__.cpython-32.pyc > File "/usr/lib/python3.2/site-packages/docutils/__init__.py", line 75 > return u', '.join(self.args) > ^ > SyntaxError: invalid syntax The curious thing about these errors is, the ``u'...'`` that should have been converted to ``'...'`` during the setup by the 2to3 converter. Did you follow the installation__ procedure and run python3 setup.py install from the Docutils root directory? If yes, this could be a problem with the 2to3 script. You may try removing the ``u`` from the offending literal strings "by hand". Alternatively, you could do the conversion on a different machine with python3 setup.py build and install the created directories under build/ and test3/ "by hand". Günter __ http://docutils.sourceforge.net/README.html#installation |
|
From: Tim D. <tu...@tu...> - 2013-03-21 20:49:44
|
On 03/21/2013 03:00 AM, Guenter Milde wrote: > The curious thing about these errors is, the ``u'...'`` that should have > been converted to ``'...'`` during the setup by the 2to3 converter. > > Did you follow the installation__ procedure and run > > python3 setup.py install > > from the Docutils root directory? Initially, I did a python2 install. Then when I IDed the problem we are talking about, I went back and did the above and got the results I've already described. -- ---------------------------------------------------------------------------- Tim Daneliuk tu...@tu... PGP Key: http://www.tundraware.com/PGP/ |
|
From: Guenter M. <mi...@us...> - 2013-03-22 08:54:50
|
On 2013-03-21, Tim Daneliuk wrote:
> On 03/21/2013 03:00 AM, Guenter Milde wrote:
>> The curious thing about these errors is, the ``u'...'`` that should have
>> been converted to ``'...'`` during the setup by the 2to3 converter.
>> Did you follow the installation__ procedure and run
>> python3 setup.py install
>> from the Docutils root directory?
> Initially, I did a python2 install.
> Then when I IDed the problem we are talking about, I went back
> and did the above and got the results I've already described.
If you have the time and will to test the Python-3 problem further, it
might help to know the following:
Do you remember whether the 2to3 conversion did run at all?
Do you still have the files in build/lib? Are they Py3k code?
If not, maybe you should run
python3 setup.py build
(and if this does not re-start the 2to3 conversion, first delete the
build/ dir and try again).
If most of the files in the Python-3-lib are Python-3 code, does manually
removing the ``u`` help?
Besides this, more fine-grained failure/success reports with Py 2.7.3
would be nice, too.
Günter
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X