http://blog.gmane.org/gmane.comp.python.lxml.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.lxml.devel/3990 I am trying to build lxml for python 2.3 on windows, using mingw32. I've successfully downloaded and installed libxslt and libxml2, put the include header files and the lib files where they need to be, but when I build lxml the following error appears: Am I missing any .lib files? libxslt, libxml2, libexslt, iconv and zlib are all in the python 2.3 libs folder. D:\LXML\lxml-2.1.1>python setup.py build -cmingw32 Building lxml version 2.1.1. NOTE: Trying to build without Cython, pre-generated 'src/lxml/lxml.etree.c' needs to be available. ERROR: 'xslt-config' is not recognized as an internal or external command, operable program or batch file. ** make sure the development packages of libxml2 and libxslt are installed ** Using build configuration of libxslt running build running build_py running build_ext building 'lxml.etree' extension writing build\temp.win32-2.3\Release\src\lxml\etree.def C:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.3\Release\src\lxm l\lxml.etree.o build\temp.win32-2.3\ Nguyễn Khánh Duy 2008-08-21T15:43:34 http://comments.gmane.org/gmane.comp.python.lxml.devel/3987 FYI -------- Original-Message -------- Subject: [xml] Security fix for libxml2 Date: Wed, 20 Aug 2008 19:00:51 +0200 From: Daniel Veillard <veillard< at >redhat.com> To: xml< at >gnome.org Bad news, when checking against recursive entities expansion problem back when it was made official (c.f. the billion laught attack circa 2004) I had checked for the normal recursion, but when happening in an attribute value the resource consumption is way faster and the recursion detection in place is not sufficient to catch the problem. Basically when this happen within an attribute just checking for a recursion depth is not sufficient, and the only good method I could find was to count the number of entities replacement taking place while parsing a given document, and drop parsing after half a million substitution. I think it's a fair default process and what the patches below implements for various libxml2 versions, but i can understand that in some case that may be problematic. So i intend in the next release (2.7.0 hope Stefan Behnel 2008-08-20T18:50:26 http://comments.gmane.org/gmane.comp.python.lxml.devel/3985 _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev Holger Joukl 2008-08-20T15:09:09 http://comments.gmane.org/gmane.comp.python.lxml.devel/3970 I'm looking for a freely available tool that can generate xml instance documents from an xml schema. I'm aware of Sun's xmlgen, but I cannot find a valid web link to it. Does anyone have a current link to Sun's xmlgen or know of a similar tool? When writing such a tool, wouldn't you need to load the schema as an xml document, walk the tree, and output appropriate instance xml (probably not trivial, given xml schema's complexity)? Thank you, Peter Peter 2008-08-15T10:26:26 http://comments.gmane.org/gmane.comp.python.lxml.devel/3965 I have a stylesheet that uses document('') to reference itself. The stylesheet works with xsltproc and xmlstarlet on ubuntu 7.10 However when I use it in a threaded wsgi app with lxml 2.11 or 2.0, it does not work. I then wrote a simple test case (thinking.. aha, I'll report this error), but of course the test case functions correctly. I've spent 4 hours working on this tonight, I'm pooped, and going nuts. basically given an xml document whose root element is "<root />" and a stylesheet that has: <xsl:value-of select="name(document('')/*)" /> From within the threaded wsgi app, the output I get from this is "root", but from the test case and from xsltproc, I get "xsl:stylesheet" My code is more or less like this: ss_parser = etree.XMLParser(load_dtd=True) ss_parser.resolvers.add(Resolver()) stylesheet_doc = etree.fromstring(stylesheet_src, ss_parser, base_url='http://mystylesheet.xsl') stylesheet = etree.XSLT(stylesheet_doc) doc_parser = etree.XMLParser(load_dtd=Tru Brad Clements 2008-08-13T05:29:36 http://comments.gmane.org/gmane.comp.python.lxml.devel/3961 _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev Santoro, Peter 2008-08-08T16:39:40 http://comments.gmane.org/gmane.comp.python.lxml.devel/3959 I have some XML data already parsed into an lxml ElementTree. Is there any easy way to reparse that using lxml.html, or is the only way to do it to serialize the XML to a string and reparse using one of the lxml.html parsers? John Krukoff 2008-08-08T15:55:10 http://comments.gmane.org/gmane.comp.python.lxml.devel/3954 Hi all! I've attached small piece of code. lxml target parsing has some problems from my point of view. 1) I use lxml.html.HTMLParser which should handle unknown HTML tags since it uses lxml.html.HtmlElementClassLookup which contain this code in its lookup function: "if node_type == 'element': return self._element_classes.get(name.lower(), HtmlElement)". If I understand it right, then even unknown tags should be handled properly. But I still get error at the end of the code: lxml.etree.XMLSyntaxError: Tag noindex invalid, line 266, column 17 I don't understand why, hope someone give me a good advice :) 2) Even if the whole process fails, etree.fromstring continue to call target methods (start,end,comment etc...) even after invelid tag <noindex> is appeared. It's ok, it's some sort of fault tolerance. But why it do not call target.close() at the end? Instead of that it raises exception. If document processing continues even after error, then call target.close() too! Maybe i'ts better to pass all accured e Max Ivanov 2008-08-08T04:54:57 http://comments.gmane.org/gmane.comp.python.lxml.devel/3952 Hi, I have an xml.sax based parser that works like this: .-----. ,-------------------. file.xml -> | gpp | -> preprocessed.xml -> |saxexts.make_parser| --. `-----' `-------------------' | ,-------------------. | custom class heirarchy <- |sax DocumentHandler| <-' `-------------------' I'm in the process of converting all of this from xml.sax to lxml.etree. The DocumentHandler function is very complex, but well debugged, so I'd really like to convert it to work with an lxml.XMLParser target keyword, which is straight forward enough (changing startElement to start, characters to data etc) to avoid churning the handler function and the custom class heirarchy it builds. So for so good... Also, performance is important, so I'm passing the the output of gpp (general pre-processor) to the parser with a feed function as gpp Gary V. Vaughan 2008-08-07T08:26:44 http://comments.gmane.org/gmane.comp.python.lxml.devel/3946 _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev Cesar Ortiz 2008-08-06T14:51:24 http://comments.gmane.org/gmane.comp.python.lxml.devel/3943 Hi there, I've got a reproducible failing test when using custom resolvers and relative xsl:import. Basically, if I use resolve_string() or let the default resolver do it's work, everything works fine. If I use resolve_file though, the *next* uri to be resolved will have a relative (to the previous uri resolved) filename, and then there's not enough information available to compute the full URI. This happens with lxml 2.1.1. I am pretty sure it didn't happen with lxml 1.3.x series (which is what I was using before). I'm attaching the problematic test and related files. For reference, this is the problematic code: ... def resolve(self, uri, id, ctx): print uri # return None # works # return self.resolve_string(open(uri, 'r').read(), ctx) # works return self.resolve_file(open(uri, 'r'), ctx) # fails ... Sidnei da Silva 2008-08-06T02:24:41 http://comments.gmane.org/gmane.comp.python.lxml.devel/3942 Hi there, I've got a reproducible failing test when using custom resolvers and relative xsl:import. Basically, if I use resolve_string() or let the default resolver do it's work, everything works fine. If I use resolve_file though, the *next* uri to be resolved will have a relative (to the previous uri resolved) filename, and then there's not enough information available to compute the full URI. This happens with lxml 2.1.1. I am pretty sure it didn't happen with lxml 1.3.x series (which is what I was using before). I'm attaching the problematic test and related files. For reference, this is the problematic code: ... def resolve(self, uri, id, ctx): print uri # return None # works # return self.resolve_string(open(uri, 'r').read(), ctx) # works return self.resolve_file(open(uri, 'r'), ctx) # fails ... Sidnei da Silva 2008-08-06T02:17:15 http://comments.gmane.org/gmane.comp.python.lxml.devel/3941 Hi there, I've just got an exception while upgrading to lxml 2.1.1. Still trying to find out if it's some backwards-incompatible change. But what triggered my attention is that the exception seems to have tried to display the line number from etree.c but failed: File "enfold\lxml\transform.pyo", line 429, in transform File "xslt.pxi", line 399, in lxml.etree.XSLT.__init__ (src/lxml/lxml.etree.c:%u) XSLTParseError: Cannot parse stylesheet This is on Windows FWIW. Sidnei da Silva 2008-08-05T23:52:32 http://comments.gmane.org/gmane.comp.python.lxml.devel/3935 Hi Apologies in advance if this is the wrong list -- I'm suggesting a change to lxml, so I guess this is the right place... I'm working on some existing code that makes use of both unicode objects and UTF-8 encoded bytestring objects (both of which sometimes contain non-ASCII characters). I'm making changes to the code to ensure that it supports the unicode character set. Unfortunately, it's not practical to change all of the code to use unicode objects (partly because there's a lot of code, and partly because fixing that would probably entail fixing PyGTK to return unicode objects instead of UTF-8 encoded bytestrings). So, the plan is to live with both unicode and UTF-8 encoded bytestrings, and to ensure Python's default encoding is always set to UTF-8. I'm sure the wisdom that approach could be debated (!), but I hope that somebody will be kind enough to answer the following question anyway :-) Looking at the code, it seems that changing function _utf8 in apihelpers.pxi to accept UTF-8 en John J Lee 2008-08-04T12:10:16 http://comments.gmane.org/gmane.comp.python.lxml.devel/3925 Hello At first, congratulations, I'm using lxml for more that one year and enjoy the huge progress (and work) you have done. I'm using lxml to validate XML documents instances with etree.XMLSchema(schema_doc).validate(xml_doc). I've used to work with DTD's where it's possible to include standard sets of HTML entities declarations like for example for (&nbsp; &eacute; etc ...). Now, working with XML schemas, sometimes I have some of those common HTML entities that appears (from an editor like FCK) in the content. And at the validation time, of course, I have an error like this : File "lxml.etree.pyx", line 2520, in lxml.etree.parse File "parser.pxi", line 1309, in lxml.etree._parseDocument File "parser.pxi", line 1338, in lxml.etree._parseDocumentFromURL File "parser.pxi", line 1248, in lxml.etree._parseDocFromFile File "parser.pxi", line 828, in lxml.etree._BaseParser._parseDocFromFile File "parser.pxi", line 452, in lxml.etree._ParserContext._handleParseResultDoc File "parser.pxi", line 53 Eric Garin 2008-07-31T08:04:10 http://comments.gmane.org/gmane.comp.python.lxml.devel/3920 So, I've got a tricky to repeat segfault that occurs on an edge case, and I'm wondering if it's even an lxml bug, or a libxslt bug? What appears to be happening, is that if I run this stylesheet which has an undefined variable reference in an xpath expression, sometimes I can get a segfault. Not always, and it seems to be based on what other xml has been processed beforehand. If I start with a clean slate, it works fine and raises an exception as expected. If I run a bunch of other stuff first (yeah, I know how vague this is, and will work on a real test case), it reliably segfaults for me. A coworker noticed this problem, his symptoms were different, instead of segfaulting, the XSLT parser would unexpectedly exit (with no exception!) at the point where the invalid xpath was run, returning whatever result document had been generated up to that point. <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:gizmo="http://www.lt-systems.com/gizmo.xsd"> <xsl:output method="xml" ind John Krukoff 2008-07-29T23:45:54 http://comments.gmane.org/gmane.comp.python.lxml.devel/3916 _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev Spencer Crissman 2008-07-28T20:24:06 http://comments.gmane.org/gmane.comp.python.lxml.devel/3911 _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev Niels Bjerre 2008-07-27T23:20:10 http://comments.gmane.org/gmane.comp.python.lxml.devel/3900 _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev mmdumi 2008-07-25T09:23:13 http://comments.gmane.org/gmane.comp.python.lxml.devel/3898 Hi, I've been trying to install lxml 2.1 for days and it seems nothing I've tried works. gcc keeps giving me a enormous amount of errors and I've installed libxml2, libxml2-dev, libxslt1.1, and libxslt1-dev (all form the Ubuntu repository) and it seems nothing works. http://ubuntuforums.org/showthread.php?p=5452334 has more info about all I've done. Any help would be greatly appreciated, I'm working on a project which heavily relies on lxml. _______________________________________________ lxml-dev mailing list lxml-dev< at >codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev Richard Alex Hofer 2008-07-24T23:32:05 http://comments.gmane.org/gmane.comp.python.lxml.devel/3897 Hi all, I just released new bug-fix versions of the 2.1 and 2.0 series to PyPI. They mainly fix a crash bug in the XSLT code. Changelog follows as usual. Have fun, Stefan 2.1.1 (2008-07-24) Bugs fixed * Crash when parsing XSLT stylesheets in a thread and using them in another. * Encoding problem when including text with ElementInclude under Python 3. 2.0.8 (2008-07-24) Features added * lxml.html.rewrite_links() strips links to work around documents with whitespace in URL attributes. (backport from 2.1) Bugs fixed * Crash when parsing XSLT stylesheets in a thread and using them in another. * CSS selector parser dropped remaining expression after a function with parameters. Stefan Behnel 2008-07-24T07:40:30 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.lxml.devel