On 28/02/12 19:19, Lex Trotman wrote:
[...]
And if it did it wouldn't use the alternative implementation.
How does Jython get around that?
I don't think it does, the User Guide compiles with Jython on my machine
only because I have python installed.
Ah, ok, I guess if that suits the Jython folks then its fine.
I patched the asciidoc.conf to run the executable asciidoc instead,
the performance is 10-30% faster than CPython depending on the input
file. Not striking, but useful, especially as unlike Cython the
unmodified asciidoc.py compiled.
Looks like an interesting project, especially since according to the author no
great effort has yet been put into optimization.
And perhaps this needs to be fixed, there was also a recent comment in
the ML about Arch linux using python3 as the default "python" command
and again these the commands in asciidoc.conf didn't work until they
were patched to python2.
I'm not sure of the "correct" solution but I think it could be an
increasing problem.
I agree, maybe a {python} intrinsic attribute set to sys.executable
That should work, on my system sys.executable doesn't really give the
executable path, but it seems to give the command that initiated the
interpretor, if python is started by "python" sys.executable is
/usr/bin/python which is a link to python2.6 but if started as
"python2.6" it gives /user/bin/python2.6 directly and of course
python3 gives /usr/bin/python3.
Since the command that initiated the interpretor was good enough to
run asciidoc the first time it should be ok for the recursive case.
I've committed a (rather large patch) that resolves the 'mixed interpreters'
problem, it also fixes some sloppy coding that was making a2x and a couple of
the built-in filters incompatible with Jython.
There were also some Jython related asciidocapi StringIO incompatibilities that
have are (almost) ironed out by using the Jython cStringIO instead of StringIO.
There is still an outstanding Jython related asciidocapi bug that
occurs when using a cStringIO output file: Jython throws an error when
non-ascii characters are found in included CSS or JavaScript files
(e.g. slidy.css), this only happens if you are executing asciidoc via the
asciidocapi and you are using a StringIO output file (as opposed to a real file).
See:
https://code.google.com/p/asciidoc/source/detail?r=722d81a94dc0f1327aee7ab34afee07879d8d40d
Cheers, Stuart
Cheers
Lex
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
