headers
Paul Everitt | 1 Dec 18:12
Favicon

BUG: Trunk fails on Leopard (OS X 10.5) for missing schematron.h


Hi all.  I just tried compiling lxml trunk on Leopard and got:

building 'lxml.etree' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp 
-mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
-I/usr/include/libxml2 -I/Users/paul/opt/include/python2.4 -c 
src/lxml/lxml.etree.c -o 
build/temp.macosx-10.3-i386-2.4/src/lxml/lxml.etree.o -w
src/lxml/lxml.etree.c:69:31: error: libxml/schematron.h: No such file or 
directory

This also happens with the current cheeseshop egg (2.0alpha5).

Here's the libxml2 version that ships with Leopard:

$ xmllint --version
xmllint: using libxml version 20616
    compiled with: DTDValid FTP HTTP HTML C14N Catalog XPath XPointer 
XInclude Unicode Regexps Automata Schemas

--Paul
Permalink | Reply | 2 comments |
headers
Stefan Behnel | 1 Dec 19:35
Picon
Favicon
Gravatar

Re: BUG: Trunk fails on Leopard (OS X 10.5) for missing schematron.h


Paul Everitt wrote:
> build/temp.macosx-10.3-i386-2.4/src/lxml/lxml.etree.o -w
> src/lxml/lxml.etree.c:69:31: error: libxml/schematron.h: No such file or 
> directory
> 
> This also happens with the current cheeseshop egg (2.0alpha5).
> 
> Here's the libxml2 version that ships with Leopard:
> 
> $ xmllint --version
> xmllint: using libxml version 20616
>     compiled with: DTDValid FTP HTTP HTML C14N Catalog XPath XPointer 
> XInclude Unicode Regexps Automata Schemas

You are trying to build lxml 2.0 with libxml2 2.6.16. As the FAQ states, lxml
2.0 requires libxml2 2.6.20 or later.

http://codespeak.net/lxml/dev/FAQ.html#which-version-of-libxml2-and-libxslt-should-i-use-or-require

You can either try lxml 1.3.x or install a newer libxml2 version.

Stefan
Permalink | Reply | 1 comment |
headers
Brad Clements | 3 Dec 01:13
Gravatar

broken document('') in xslt ..

I am having trouble with a transform on 2.0alpha5 (and 2.0alpha3). It 
works on a system with a newer libxml2/libxslt,
but fails on a slightly older libxml2/libxslt. However when using 
xsltproc on the "older" system, the transform works.

So I think maybe there is an issue with custom resolvers.

basically the .xsl looks like this:

<xsl_:for-each select="document('')//const:css/const:file">
<xsl_:variable name="file" select="."/>
    <link rel="stylesheet" type="text/css">
    <xsl_:attribute name="href">
<xsl_:value-of select="concat('/css/', $file)"/>
</xsl_:attribute>
</link>
</xsl_:for-each>

And elsewhere in the xsl file is:

<const:css id="number_pad_css">
<const:file>manage_pending.css</const:file>
</const:css>

I am using a custom resolver.

I don't see any requests to resolve '' (and I wouldn't expect any either).

At first I thought this was a 2.0alpha5 issue, but I downgraded to 
2.0alpha3 and I still have the problem on one system, but it works on
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Behnel | 3 Dec 13:02
Picon
Favicon
Gravatar

Re: broken document('') in xslt ..

Hi,

Brad Clements wrote:
> I am having trouble with a transform on 2.0alpha5 (and 2.0alpha3). It 
> works on a system with a newer libxml2/libxslt,
> but fails on a slightly older libxml2/libxslt. However when using 
> xsltproc on the "older" system, the transform works.

We actually do have test cases for "document('')" in XSLT and my last test
didn't show any problems here. Maybe it's only an issue when custom resolvers
come into play.

I'll look into this.

> Can anyone suggest something? (upgrading libxslt on this system will be 
> difficult)

It looks like you have a sane build environment available. You can try to
build a recent libxml2 and libxslt by hand (without installing them) and link
them statically into lxml to work around this. It will add some 4-5 megs to
the size of the lxml install, though.

This should get you going:

http://codespeak.net/lxml/dev/build.html#static-linking-on-windows

Stefan
Permalink | Reply | 0 comments |
headers
Dmitri Fedoruk | 3 Dec 14:17
Picon

Re: Error with thread

Hello,

Looks like I've got the same problem.
Sometimes I get the same error message: 'stylesheet is not usable in
this thread'. As far as I could understand, that's because of an
attempt to use in one thread the xslt obejct initiated in another
thread. Sounds reasonable.

> Correct. As I said, a work-around would be to either create them on the fly or
> cache the XSLT objects in thread-local storage and reuse them from there.

Nice. My application works under the same scheme. I'm using mod_python
and several apache processes started in prefork mode. In every apache
process I'm using a global general object that contains xslt objects
inside. When a request comes to the next apache process, my general
object is initialized (if it has not been done yet) and then is used
inside this thread and this process. I cannot see the reason why one
instance of mod_python should conflict with another.

Nevertheless, I happen to get this error messages without any idea
why. I can not see any dependency or rule yet. The only solution is to
restart apache.

My software is the following:
Apache/2.0.61
Python 2.5.1
mod_python-3.3.1
lxml-1.3.4
libxslt-1.1.20
freebsd 6.2-20070330-SNAP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hans-Jürgen Hay | 3 Dec 21:37
Picon
Favicon

Re: Error with thread

Hi,

I had the same problem with mod_python, a while ago, it seems mod_python
does some trickery with threads in its internals. The only solution I
found is setting

PythonInterpreter "myoneandonlyinterpreter"

in the apache config of each virtual host while running prefork servers.
I coudn't find any other solution beside hoping that the threading
problem in lxml will go away, sometime.

Hans

Am Montag, den 03.12.2007, 16:17 +0300 schrieb Dmitri Fedoruk:
> Hello,
> 
> Looks like I've got the same problem.
> Sometimes I get the same error message: 'stylesheet is not usable in
> this thread'. As far as I could understand, that's because of an
> attempt to use in one thread the xslt obejct initiated in another
> thread. Sounds reasonable.
> 
> > Correct. As I said, a work-around would be to either create them on the fly or
> > cache the XSLT objects in thread-local storage and reuse them from there.
> 
> Nice. My application works under the same scheme. I'm using mod_python
> and several apache processes started in prefork mode. In every apache
> process I'm using a global general object that contains xslt objects
> inside. When a request comes to the next apache process, my general
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Everitt | 4 Dec 17:16
Favicon

Re: BUG: Trunk fails on Leopard (OS X 10.5) for missing schematron.h


Total brainfart on my part.  I had read somewhere else that libxml2 was 
updated, then looked at the version number *directly*, and *still* 
misread it.

Sorry sorry sorry.

--Paul

Stefan Behnel wrote:
> Paul Everitt wrote:
>> build/temp.macosx-10.3-i386-2.4/src/lxml/lxml.etree.o -w
>> src/lxml/lxml.etree.c:69:31: error: libxml/schematron.h: No such file or 
>> directory
>>
>> This also happens with the current cheeseshop egg (2.0alpha5).
>>
>> Here's the libxml2 version that ships with Leopard:
>>
>> $ xmllint --version
>> xmllint: using libxml version 20616
>>     compiled with: DTDValid FTP HTTP HTML C14N Catalog XPath XPointer 
>> XInclude Unicode Regexps Automata Schemas
> 
> You are trying to build lxml 2.0 with libxml2 2.6.16. As the FAQ states, lxml
> 2.0 requires libxml2 2.6.20 or later.
> 
> http://codespeak.net/lxml/dev/FAQ.html#which-version-of-libxml2-and-libxslt-should-i-use-or-require
> 
> You can either try lxml 1.3.x or install a newer libxml2 version.
(Continue reading)

Permalink | Reply | 0 comments |
headers
js | 5 Dec 14:41
Picon

Now lxml is available through MacPorts

I just want to announce that lxml is accepted by MacPorts community
so now you can install lxml just by doing "port install py25-lxml".
IMHO, MacPorts is more flexible and easier to use than easy_install.

Please give it a try.

Thanks.
Permalink | Reply | 1 comment |
headers
Christian Zagrodnick | 6 Dec 08:59
Favicon
Gravatar

Processing instruction roundtrip (again)

Hi,

i've got a problem with Processing Instructions (2.0alpha5, Python2.4):

>>> obj = lxml.objectify.XML('<a/><?foo:bar blurb ?>')
>>> lxml.etree.tostring(obj)
'<a/>'
>>> obj = lxml.objectify.XML('<a><?foo:bar blurb ?></a>')
>>> lxml.etree.tostring(obj)
'<a><?foo:bar blurb ?></a>'
>>>

So a PI not contained in the root node gets lost. Any way to fix this?

--

-- 
Christian Zagrodnick

gocept gmbh & co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
Permalink | Reply | 501 comments |
headers
Artur Siekielski | 7 Dec 01:56
Picon

Huge memory leak in latest 2.0

Hi.

I'm using latest 2.0 version from trunk, rev. 49494 (because it supports 
'encoding' keyword in HTMLParser). I'm parsing many HTML documents in 
loop, 100-200kB each. I have noticed that memory used by my program 
increases about 1MB after each document processed, so after a few 
hundreds of passes system is about to hang. Running the same code with 
lxml 1.3.6 doesn't cause such memory usage increase.

I'm using the following library calls:
tree = etree.parse( <opened file>, HTMLParser(encoding=...))
etree.tostring(tree)
el.xpath(...)
getting children and attributes of elements

I'm using libxml2 version 2.6.28.

If anyone knows about solution/workaround, please write.

Regards,
Artur
Permalink | Reply | 3 comments |

Gmane