From ianb at colorstudy.com Fri Feb 1 02:50:52 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 31 Jan 2008 19:50:52 -0600 Subject: [lxml-dev] Compile error with trunk Message-ID: <47A27AFC.7000500@colorstudy.com> I tried rebuilding the trunk, installing cython and deleting the .c files I had around. I got this: ~/src/lxml$ python setup.py develop Building with Cython 0.9.6.11. Building lxml version 2.0.beta2-51162. running develop running egg_info writing src/lxml.egg-info/PKG-INFO writing top-level names to src/lxml.egg-info/top_level.txt writing dependency_links to src/lxml.egg-info/dependency_links.txt reading manifest template 'MANIFEST.in' warning: no files found matching 'lxml.objectify.c' under directory 'src/lxml' warning: no files found matching 'lxml.pyclasslookup.c' under directory 'src/lxml' warning: no files found matching '*.html' under directory 'doc' warning: no previously-included files found matching 'src/lxml/etree.pxi' writing manifest file 'src/lxml.egg-info/SOURCES.txt' running build_ext building 'lxml.etree' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/libxml2 -I/usr/include/python2.5 -c src/lxml/lxml.etree.c -o build/temp.linux-i686-2.5/src/lxml/lxml.etree.o -w src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__BaseParser?: src/lxml/lxml.etree.c:91711: error: invalid lvalue in assignment src/lxml/lxml.etree.c:91714: error: invalid lvalue in assignment src/lxml/lxml.etree.c:91717: error: invalid lvalue in assignment src/lxml/lxml.etree.c:91720: error: invalid lvalue in assignment src/lxml/lxml.etree.c:91723: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__Document?: src/lxml/lxml.etree.c:91930: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_DocInfo?: src/lxml/lxml.etree.c:92086: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__Element?: src/lxml/lxml.etree.c:92310: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ElementTree?: src/lxml/lxml.etree.c:93275: error: invalid lvalue in assignment src/lxml/lxml.etree.c:93278: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__Attrib?: src/lxml/lxml.etree.c:93467: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__AttribIterator?: src/lxml/lxml.etree.c:93653: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ElementIterator?: src/lxml/lxml.etree.c:93973: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_ElementDepthFirstIterator?: src/lxml/lxml.etree.c:94539: error: invalid lvalue in assignment src/lxml/lxml.etree.c:94542: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_ElementTextIterator?: src/lxml/lxml.etree.c:94708: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__BaseErrorLog?: src/lxml/lxml.etree.c:95110: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_FallbackElementClassLookup?: src/lxml/lxml.etree.c:96712: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ResolverRegistry?: src/lxml/lxml.etree.c:98662: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ResolverContext?: src/lxml/lxml.etree.c:98832: error: invalid lvalue in assignment src/lxml/lxml.etree.c:98835: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ParserDictionaryContext?: src/lxml/lxml.etree.c:99002: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__FileReaderContext?: src/lxml/lxml.etree.c:99192: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ParserContext?: src/lxml/lxml.etree.c:99366: error: invalid lvalue in assignment src/lxml/lxml.etree.c:99369: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__SaxParserContext?: src/lxml/lxml.etree.c:99529: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ParserSchemaValidationContext?: src/lxml/lxml.etree.c:99856: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__Validator?: src/lxml/lxml.etree.c:100012: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_TreeBuilder?: src/lxml/lxml.etree.c:100641: error: invalid lvalue in assignment src/lxml/lxml.etree.c:100656: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__FilelikeWriter?: src/lxml/lxml.etree.c:101436: error: invalid lvalue in assignment src/lxml/lxml.etree.c:101439: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__IterparseContext?: src/lxml/lxml.etree.c:101634: error: invalid lvalue in assignment src/lxml/lxml.etree.c:101637: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__IDDict?: src/lxml/lxml.etree.c:102200: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_XInclude?: src/lxml/lxml.etree.c:102381: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__BaseContext?: src/lxml/lxml.etree.c:102750: error: invalid lvalue in assignment src/lxml/lxml.etree.c:102771: error: invalid lvalue in assignment src/lxml/lxml.etree.c:102774: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__ElementUnicodeResult?: src/lxml/lxml.etree.c:102965: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__XPathEvaluatorBase?: src/lxml/lxml.etree.c:103314: error: invalid lvalue in assignment src/lxml/lxml.etree.c:103317: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_XPathElementEvaluator?: src/lxml/lxml.etree.c:103487: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__XSLTResolverContext?: src/lxml/lxml.etree.c:104093: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree_XSLT?: src/lxml/lxml.etree.c:104554: error: invalid lvalue in assignment src/lxml/lxml.etree.c:104557: error: invalid lvalue in assignment src/lxml/lxml.etree.c:104560: error: invalid lvalue in assignment src/lxml/lxml.etree.c:104563: error: invalid lvalue in assignment src/lxml/lxml.etree.c: In function ?__pyx_tp_clear_4lxml_5etree__XSLTResultTree?: src/lxml/lxml.etree.c:104742: error: invalid lvalue in assignment src/lxml/lxml.etree.c:104745: error: invalid lvalue in assignment error: command 'gcc' failed with exit status 1 From stefan_ml at behnel.de Fri Feb 1 07:12:56 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 07:12:56 +0100 Subject: [lxml-dev] Compile error with trunk In-Reply-To: <47A27AFC.7000500@colorstudy.com> References: <47A27AFC.7000500@colorstudy.com> Message-ID: <47A2B868.6070202@behnel.de> Hi Ian, Ian Bicking wrote: > I tried rebuilding the trunk, installing cython and deleting the .c > files I had around. Note that this now requires a "make realclean", "make clean" will keep the .c files (mostly to keep people from breaking things by accident if they build without Cython). > I got this: > > ~/src/lxml$ python setup.py develop > Building with Cython 0.9.6.11. [...] > building 'lxml.etree' extension > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall > -Wstrict-prototypes -fPIC -I/usr/include/libxml2 > -I/usr/include/python2.5 -c src/lxml/lxml.etree.c -o > build/temp.linux-i686-2.5/src/lxml/lxml.etree.o -w > src/lxml/lxml.etree.c: In function > ?__pyx_tp_clear_4lxml_5etree__BaseParser?: > src/lxml/lxml.etree.c:91711: error: invalid lvalue in assignment > src/lxml/lxml.etree.c:91714: error: invalid lvalue in assignment > src/lxml/lxml.etree.c:91717: error: invalid lvalue in assignment > src/lxml/lxml.etree.c:91720: error: invalid lvalue in assignment [...] There is a bugfix release called Cython 0.9.6.11b. That should fix it. BTW, I wasn't able to fix all lxml.html test cases, including the 'HTML namespace' test which is now disabled. Please take a look at it once you've fixed your setup. I also removed the element from the "html.clean" tests as it seems to be problematic. Maybe there's a way to work around that? Thanks, Stefan From cz at gocept.com Fri Feb 1 09:58:23 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Fri, 1 Feb 2008 09:58:23 +0100 Subject: [lxml-dev] requesting lxml testimonials? References: <200801311551.48243.srichter@cosmos.phy.tufts.edu> Message-ID: On 2008-01-31 21:51:48 +0100, Stephan Richter said: > > lxml takes all the pain out of XML. I couldn't agree more. -- Christian Zagrodnick gocept gmbh & co. kg ? forsterstrasse 29 ? 06112 halle/saale www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891 From jholg at gmx.de Fri Feb 1 10:03:42 2008 From: jholg at gmx.de (jholg at gmx.de) Date: Fri, 01 Feb 2008 10:03:42 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <47A1F7E5.1000203@behnel.de> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> Message-ID: <20080201090342.15000@gmx.net> > thanks for the report. I'm actually pretty late... sorry for that. Maybe I should set up s.th. like a nightly or weekly checkout/build/test/bench someday. > Hmm, guess that's something to fix in Cython. The *LongLong() functions > are a > recent addition for safe type conversion. > > The line numbers above differ from mine, though. Could you send me the > source > code of the lines that failed here? 110149 110150 static INLINE int __Pyx_PyObject_IsTrue(PyObject* x) { 110151 if (x == Py_True) return 1; 110152 else if (x == Py_False) return 0; 110153 else return PyObject_IsTrue(x); 110154 } 110155 110156 static INLINE PY_LONG_LONG __pyx_PyInt_AsLongLong(PyObject* x) { 110157 if (PyInt_CheckExact(x)) { 110158 return PyInt_AS_LONG(x); 110159 } 110160 else if (PyLong_CheckExact(x)) { 110161 return PyLong_AsLongLong(x); 110162 } 110163 else { 110164 PyObject* tmp = PyNumber_Int(x); if (!tmp) return (PY_LONG_LONG)-1; 110165 PY_LONG_LONG val = __pyx_PyInt_AsLongLong(tmp); 110166 Py_DECREF(tmp); 110167 return val; 110168 } 110169 } 110170 110171 static INLINE unsigned PY_LONG_LONG __pyx_PyInt_AsUnsignedLongLong(PyObject* x) { 110172 if (PyInt_CheckExact(x)) { 110173 long val = PyInt_AS_LONG(x); 110174 if (unlikely(val < 0)) { 110175 PyErr_SetString(PyExc_TypeError, "Negative assignment to unsigned type."); 110176 return (unsigned PY_LONG_LONG)-1; 110177 } 110178 return val; 110179 } 110180 else if (PyLong_CheckExact(x)) { 110181 return PyLong_AsUnsignedLongLong(x); 110182 } 110183 else { 110184 PyObject* tmp = PyNumber_Int(x); if (!tmp) return (PY_LONG_LONG)-1; 110185 PY_LONG_LONG val = __pyx_PyInt_AsUnsignedLongLong(tmp); 110186 Py_DECREF(tmp); 110187 return val; 110188 } 110189 } 110190 110191 > > It seems to lack catalog support. I thought about adding that test or not. > Looks like it's better to leave it out. Is that my libmxl2 that's lacking catalog support? Or do these tests try to access s.th. from the web? > I wouldn't dare to compare the numbers here, given a difference of 30 > tests > (especially not knowing which ones are missing). If you get errors, it > naturally takes (a bit) longer. Also, it seems to run much less tests, so > I > guess you either do not have ElementTree installed for the compat tests > (though I actually think that's the case for both runs), or it just takes > longer to search the (non-existing) catalogs, or ... > > If you want real numbers, you should rather run the benchmarks. Your're right, of course, I'm gonna do that. Got a little carried away as I could actually see the test count going up ever so slowly compared to my last build. Btw I noticed that the file bench.py is missing, which the Makefile tries to invoke. Is there any existing tools to compare logs of different benchmark runs? Guess I'm gonna hack up s.th. rather than check differences manually... Thanks, Holger -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From l.oluyede at gmail.com Fri Feb 1 10:16:53 2008 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Fri, 1 Feb 2008 10:16:53 +0100 Subject: [lxml-dev] requesting lxml testimonials? In-Reply-To: References: Message-ID: <9eebf5740802010116u12656667l7384a79974b497c8@mail.gmail.com> I started using lxml heavily for an internal project involving resolving relaxng schemas and validating financial instruments and I'm really, really happy to have it in my toolbox. The great thing about it is you can do pretty much anything with an intuitive API. Heavy XPath queries, transformations, HTML parsing. It's definitely a wonder library. I really makes XML bearable as Stephan said :-) -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair From stefan_ml at behnel.de Fri Feb 1 10:38:23 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 10:38:23 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <20080201090342.15000@gmx.net> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> Message-ID: <47A2E88F.9090500@behnel.de> Hi, jholg at gmx.de wrote: >> thanks for the report. > > I'm actually pretty late... sorry for that. Maybe I should set up s.th. > like a nightly or weekly checkout/build/test/bench someday. good idea. :) > 110165 PY_LONG_LONG val = __pyx_PyInt_AsLongLong(tmp); Ok, so this line failed with src/lxml/lxml.etree.c:110165: parse error before `long' which lets me assume that PY_LONG_LONG is the usual "long long" on your machine, which apparently fails in gcc 2.95. Let me guess: your Python install was not compiled with gcc 2.95, was it? >> It seems to lack catalog support. I thought about adding that test or >> not. Looks like it's better to leave it out. > > Is that my libmxl2 that's lacking catalog support? Yes, or maybe just the catalog itself. I have the DocBook DTD locally in my catalog under /usr/share/xml/docbook/schema/dtd/ > Or do these tests try to access s.th. from the web? They shouldn't. Though, maybe, ... Guess it's just best to switch them off. :) > Btw I noticed that the file bench.py is missing, which the Makefile tries > to invoke. Ah, had forgotten about that target. Fixed. > Is there any existing tools to compare logs of different benchmark runs? > Guess I'm gonna hack up s.th. rather than check differences manually... That would be very helpful. The benchmarks just output a whole bunch of numbers, but I never got around to making anything more legible from them. Maybe we should have some kind of an "ETstone" or something, that would output a single number for ET performance. Or maybe one for parsing, one for serialising and one for the API or something in that line. Stefan From jholg at gmx.de Fri Feb 1 11:46:04 2008 From: jholg at gmx.de (jholg at gmx.de) Date: Fri, 01 Feb 2008 11:46:04 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <47A2E88F.9090500@behnel.de> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> <47A2E88F.9090500@behnel.de> Message-ID: <20080201104604.14990@gmx.net> Hi Stefan, > which lets me assume that PY_LONG_LONG is the usual "long long" on your > machine, which apparently fails in gcc 2.95. > > Let me guess: your Python install was not compiled with gcc 2.95, was it? > It was compiled with 2.95: 0 pytaf at adevp02 .../lxml-2.0beta2 $ gcc -dumpversion 2.95.2 0 pytaf at adevp02 .../lxml-2.0beta2 $ /apps/pydev/hjoukl/bin/python2.4 setup.py build Building with Cython 0.9.6.11b. Building lxml version 2.0.beta2-51091. running build running build_py writing byte-compilation script '/tmp/tmp61b-gM.py' /apps/pydev/hjoukl/bin/python2.4 -O /tmp/tmp61b-gM.py removing /tmp/tmp61b-gM.py running build_ext building 'lxml.etree' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/apps/prod//include -I/apps/prod//include/libxml2 -I/apps/prod/include/libxml2 -I/apps/prod/include -I/apps/pydev/hjoukl/include/python2.4 -c src/lxml/lxml.etree.c -o build/temp.solaris-2.8-sun4u-2.4/src/lxml/lxml.etree.o -w src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsLongLong': src/lxml/lxml.etree.c:110165: parse error before `long' src/lxml/lxml.etree.c:110167: `val' undeclared (first use in this function) src/lxml/lxml.etree.c:110167: (Each undeclared identifier is reported only once src/lxml/lxml.etree.c:110167: for each function it appears in.) src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsUnsignedLongLong': src/lxml/lxml.etree.c:110185: parse error before `long' src/lxml/lxml.etree.c:110187: `val' undeclared (first use in this function) error: command 'gcc' failed with exit status 1 1 pytaf at adevp02 .../lxml-2.0beta2 $ 0 pytaf at adevp02 .../lxml-2.0beta2 $ 0 pytaf at adevp02 .../lxml-2.0beta2 $ 0 pytaf at adevp02 .../lxml-2.0beta2 $ 0 pytaf at adevp02 .../lxml-2.0beta2 $ 0 pytaf at adevp02 .../lxml-2.0beta2 $ 0 pytaf at adevp02 .../lxml-2.0beta2 $/apps/pydev/hjoukl/bin/python2.4 Python 2.4.4 (#1, Mar 6 2007, 11:22:31) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> 0 pytaf at adevp02 .../lxml-2.0beta2 $ So I don't *think* it's s.th. to do with my setup, which is the same I used with the successful 2.0alpha builds (older cython version then, of course). Holger -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From stefan_ml at behnel.de Fri Feb 1 12:07:34 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 12:07:34 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <20080201104604.14990@gmx.net> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> <47A2E88F.9090500@behnel.de> <20080201104604.14990@gmx.net> Message-ID: <47A2FD76.1080707@behnel.de> Hi Holger, jholg at gmx.de wrote: > src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsLongLong': > src/lxml/lxml.etree.c:110165: parse error before `long' > src/lxml/lxml.etree.c:110167: `val' undeclared (first use in this function) > src/lxml/lxml.etree.c:110167: (Each undeclared identifier is reported only once > src/lxml/lxml.etree.c:110167: for each function it appears in.) > src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsUnsignedLongLong': > src/lxml/lxml.etree.c:110185: parse error before `long' > src/lxml/lxml.etree.c:110187: `val' undeclared (first use in this function) > error: command 'gcc' failed with exit status 1 I forwarded this to the Cython list, let's see what that gives. Stefan From gilles.lenfant at gmail.com Fri Feb 1 12:09:35 2008 From: gilles.lenfant at gmail.com (Gilles Lenfant) Date: Fri, 1 Feb 2008 12:09:35 +0100 Subject: [lxml-dev] requesting lxml testimonials? In-Reply-To: <200801311551.48243.srichter@cosmos.phy.tufts.edu> References: <200801311551.48243.srichter@cosmos.phy.tufts.edu> Message-ID: Le 31 janv. 08 ? 21:51, Stephan Richter a ?crit : > On Thursday 31 January 2008, Martijn Faassen wrote: >> else wants to give a testimonial, together with permission for its >> use? > [...] > lxml takes all the pain out of XML. That's the key point of lxml. THE tool for python and XML, as well as for newbies and experienced developers. > Regards -- Gilles Lenfant gilles.lenfant at gmail.com From stefan_ml at behnel.de Fri Feb 1 14:35:35 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 14:35:35 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <47A2FD76.1080707@behnel.de> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> <47A2E88F.9090500@behnel.de> <20080201104604.14990@gmx.net> <47A2FD76.1080707@behnel.de> Message-ID: <47A32027.1000806@behnel.de> Hi Holger, Stefan Behnel wrote: > jholg at gmx.de wrote: >> src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsLongLong': >> src/lxml/lxml.etree.c:110165: parse error before `long' >> src/lxml/lxml.etree.c:110167: `val' undeclared (first use in this function) >> src/lxml/lxml.etree.c:110167: (Each undeclared identifier is reported only once >> src/lxml/lxml.etree.c:110167: for each function it appears in.) >> src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsUnsignedLongLong': >> src/lxml/lxml.etree.c:110185: parse error before `long' >> src/lxml/lxml.etree.c:110187: `val' undeclared (first use in this function) >> error: command 'gcc' failed with exit status 1 > > I forwarded this to the Cython list, let's see what that gives. And it helped! :) http://comments.gmane.org/gmane.comp.python.cython.devel/588 Here's a fix for Cython. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc295-fix.patch Type: text/x-patch Size: 1182 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080201/9607939d/attachment.bin From jholg at gmx.de Fri Feb 1 16:06:29 2008 From: jholg at gmx.de (jholg at gmx.de) Date: Fri, 01 Feb 2008 16:06:29 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <47A32027.1000806@behnel.de> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> <47A2E88F.9090500@behnel.de> <20080201104604.14990@gmx.net> <47A2FD76.1080707@behnel.de> <47A32027.1000806@behnel.de> Message-ID: <20080201150629.15020@gmx.net> > > > > I forwarded this to the Cython list, let's see what that gives. > > And it helped! :) > > http://comments.gmane.org/gmane.comp.python.cython.devel/588 > > Here's a fix for Cython. > > Stefan Thanks very much, I'll try that out. You guys are lightspeed, as ever. That's one of another big point for lxml, btw: Mailing-list responsiveness by its maintainer, and experienced users. I tried to do a little bit of performance comp. This is the stuff that seems to be >20% slower for me since 2.0alpha: 0 lb54320 at adevp02 .../lxml-2.0beta2 $ /data/pydev/hjoukl/python/pysource/tools/lxml_benchcmp.py /data/tmp/pytaf/benchmarks/etree_2.0alpha.log /data/tmp/pytaf/benchmarks/etree_2.0beta2.log --tolerance 20 --loglevel MUCHSLOWER lxe: index_slice_neg (--TR T1 ): 0.02000000 <<< 0.14900000 msec/pass (+6.450000) !!! lxe: index_slice_neg (--TR T4 ): 0.00790000 <<< 0.10700000 msec/pass (+12.544304) !!! lxe: replace_children (--TC T2 ): 0.27700000 <<< 0.39790000 msec/pass (+0.436462) !!! lxe: replace_children (--TC T1 ): 0.03290000 <<< 0.04200000 msec/pass (+0.276596) !!! lxe: index_slice (--TR T3 ): 0.01100000 <<< 0.01410000 msec/pass (+0.281818) !!! lxe: replace_children (--TC T4 ): 0.03290000 <<< 0.04080000 msec/pass (+0.240122) !!! 0 lb54320 at adevp02 .../lxml-2.0beta2 $ I hacked up a little script to produce this (attached), not tested at all yet. I won't be able to check the patch until monday, unfortunately (unless I install a 2.95.2 on my linux box at home, that is ;-) Holger -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail -------------- next part -------------- A non-text attachment was scrubbed... Name: lxml_benchcmp.py Type: application/octet-stream Size: 6233 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080201/15346b80/attachment.obj From stefan_ml at behnel.de Fri Feb 1 16:22:49 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 16:22:49 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <20080131154553.289150@gmx.net> References: <20080131154553.289150@gmx.net> Message-ID: <47A33949.1010904@behnel.de> Hi Holger, jholg at gmx.de wrote: > Ran 855 tests in 37.860s > > Compared to 2.0alpha (I rebuilt that also with gcc 3.4.4): > > Ran 824 tests in 2.698s > > So basically performance drops by factor >10 for me Sorry, I had completely forgotten that I switched on garbage collection between test runs somewhere during the alpha cycle. The test run you are comparing to does not explicitly run GC after each test to catch refcounting bugs. That's what makes the difference here, not lxml itself. Stefan From stefan_ml at behnel.de Fri Feb 1 16:29:18 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 16:29:18 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <20080201150629.15020@gmx.net> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> <47A2E88F.9090500@behnel.de> <20080201104604.14990@gmx.net> <47A2FD76.1080707@behnel.de> <47A32027.1000806@behnel.de> <20080201150629.15020@gmx.net> Message-ID: <47A33ACE.7050109@behnel.de> Hi Holger, jholg at gmx.de wrote: > I tried to do a little bit of performance comp. This is the stuff that > seems to be >20% slower for me since 2.0alpha: > > 0 lb54320 at adevp02 .../lxml-2.0beta2 $ /data/pydev/hjoukl/python/pysource/tools/lxml_benchcmp.py /data/tmp/pytaf/benchmarks/etree_2.0alpha.log /data/tmp/pytaf/benchmarks/etree_2.0beta2.log --tolerance 20 --loglevel MUCHSLOWER > lxe: index_slice_neg (--TR T1 ): 0.02000000 <<< 0.14900000 msec/pass (+6.450000) !!! > lxe: index_slice_neg (--TR T4 ): 0.00790000 <<< 0.10700000 msec/pass (+12.544304) !!! > lxe: replace_children (--TC T2 ): 0.27700000 <<< 0.39790000 msec/pass (+0.436462) !!! > lxe: replace_children (--TC T1 ): 0.03290000 <<< 0.04200000 msec/pass (+0.276596) !!! > lxe: index_slice (--TR T3 ): 0.01100000 <<< 0.01410000 msec/pass (+0.281818) !!! > lxe: replace_children (--TC T4 ): 0.03290000 <<< 0.04080000 msec/pass (+0.240122) !!! > 0 lb54320 at adevp02 .../lxml-2.0beta2 $ Hmm, interesting. I'll look over that when I find the time. This is not release critical. Thanks, Stefan From stefan_ml at behnel.de Fri Feb 1 19:25:59 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 01 Feb 2008 19:25:59 +0100 Subject: [lxml-dev] lxml 2.0 is born! Message-ID: <47A36437.8080907@behnel.de> Hi everyone, I'm very happy to announce the official release of lxml 2.0! http://codespeak.net/lxml/ http://pypi.python.org/pypi/lxml/2.0 This release marks the end of a development effort of more than 6 months, starting with the release of the last stable series lxml 1.3. The major differences are explained on this page: http://codespeak.net/lxml/lxml2.html lxml 2.0 is not a revolution, it is a gradual move towards a cleaner API with more things working together as expected. But it nevertheless comes with a lot of new tools and features, that makes your XML life easier - and even more your HTML life. There are also a couple of minor things that were deprecated, which will be removed for lxml 2.1. See the above link for details. The new release has already adopted a lot of changes from the upcoming ElementTree 1.3 library, and implements a much broader set of compatible features, such as the TreeBuilder interface for parser targets. I appended the complete changelog, but lets start with the most important things: * * * * * * * * * * * * * * * ( ) (*) (*) * | | |~| |~| * | | | | | | ,,.......,, | | ,.a@@@@| |@@@@@@@@@@@@@@@@| |@@@@a. .,a@@@@@@@@@| |@@@@@@@@@@@@@@@@| |@@@@@@@@a,. ,a@@@@@@@@@@@@| |@@@@@@.@@@@@@@@@| |@@@@@@@@@@@@a, a@@@@@@@@@@@@@@@@@@@@@' . `@@@@@@@@@@@@@@@@@@@@@@@@a ;`@@@@@@@@@@@@@@@@@@' . `@@@@@@@@@@@@@@@@@@@@@'; ;@@@`@@@@@@@@@@@@@' . `@@@@@@@@@@@@@@@@'@@@; ;@@@;,.aaaaaaaaaa . aaaaa,,aaaaaaa,;@@@; ;;@;;;;@@@@@@@@;@ @.@ ;@@@;;;@@@@@@;;;;@@; ;;;;;;;@@@@;@@;;@ @@ . @@ ;;@;;;;@@;@@@;;;;;;; ;;;;;;;;@@;;;;;;; @@ . @@ ;;;;;;;;;;;@@;;;;@;; ;;;;;;;;;;;;;;;;;@@ . @@;;;;;;;;;;;;;;;;@@@; ,%%%;;;;;;;;@;;;;;;;; . ;;;;;;;;;;;;;;;;@@;;%%%, .%%%%%%;;;;;;;@@;;;;;;;; ,%%%, ;;;;;;;;;;;;;;;;;;;;%%%%%%, .%%%%%%%;;;;;;;@@;;;;;;;; ,%%%%%%%, ;;;;;;;;;;;;;;;;;;;;%%%%%%%, %%%%%%%%`;;;;;;;;;;;;;;;; %%%%%%%%%%% ;;;;;;;;;;;;;;;;;;;'%%%%%%%% %%%%%%%%%%%%`;;;;;;;;;;;;,%%%%%%%%%%%%%,;;;;;;;;;;;;;;;'%%%%%%%%%%%% `%%%%%%%%%%%%%%%%%,,,,,,,%%%%%%%%%%%%%%%,,,,,,,%%%%%%%%%%%%%%%%%%%%' `%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%' `%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%' """"""""""""""`,,,,,,,,,'""""""""""""""""" `%%%%%%%' `%%%%%' %%% generously donated by Susie Oviatt %%%%% .,%%%%%%%,. ,%%%%%%%%%%%%%%%%%%%, Happy birthday, lxml - and may the force be with you! :) Have fun, Stefan ** ChangeLog: 2.0 (2008-02-01) ================ Features added -------------- * Passing the ``unicode`` type as ``encoding`` to ``tostring()`` will serialise to unicode. The ``tounicode()`` function is now officially deprecated. * ``XMLSchema()`` and ``RelaxNG()`` can parse from StringIO. * ``makeparser()`` function in ``lxml.objectify`` to create a new parser with the usual objectify setup. Bugs fixed ---------- Other changes ------------- 2.0beta2 (2008-01-26) ===================== Features added -------------- * Plain ASCII XPath string results are no longer forced into unicode objects as in 2.0beta1, but are returned as plain strings as before. * All XPath string results are 'smart' objects that have a ``getparent()`` method to retrieve their parent Element. * ``with_tail`` option in serialiser functions. * More accurate exception messages in validator creation. Bugs fixed ---------- * Missing import in ``lxml.html.clean``. * Some Python 2.4-isms prevented lxml from building/running under Python 2.3. Other changes ------------- * Exceptions carry only the part of the error log that is related to the operation that caused the error. * ``XMLSchema()`` and ``RelaxNG()`` now enforce passing the source file/filename through the ``file`` keyword argument. * The test suite now skips most doctests under Python 2.3. * ``make clean`` no longer removes the .c files (use ``make realclean`` instead) 2.0beta1 (2008-01-11) ===================== Features added -------------- * Parse-time XML schema validation (``schema`` parser keyword). * XPath string results of the ``text()`` function and attribute selection make their Element container accessible through a ``getparent()`` method. As a side-effect, they are now always unicode objects (even ASCII strings). * ``XSLT`` objects are usable in any thread - at the cost of a deep copy if they were not created in that thread. * Invalid entity names and character references will be rejected by the ``Entity()`` factory. * ``entity.text`` returns the textual representation of the entity, e.g. ``&``. Bugs fixed ---------- * XPath on ElementTrees could crash when selecting the virtual root node of the ElementTree. * Compilation ``--without-threading`` was buggy in alpha5/6. Other changes ------------- * Minor performance tweaks for Element instantiation and subelement creation 2.0alpha6 (2007-12-19) ====================== Features added -------------- * New properties ``position`` and ``code`` on ParseError exception (as in ET 1.3) Bugs fixed ---------- * Memory leak in the ``parse()`` function. * Minor bugs in XSLT error message formatting. * Result document memory leak in target parser. Other changes ------------- * Various places in the XPath, XSLT and iteration APIs now require keyword-only arguments. * The argument order in ``element.itersiblings()`` was changed to match the order used in all other iteration methods. The second argument ('preceding') is now a keyword-only argument. * The ``getiterator()`` method on Elements and ElementTrees was reverted to return an iterator as it did in lxml 1.x. The ET API specification allows it to return either a sequence or an iterator, and it traditionally returned a sequence in ET and an iterator in lxml. However, it is now deprecated in favour of the ``iter()`` method, which should be used in new code wherever possible. * The 'pretty printed' serialisation of ElementTree objects now inserts newlines at the root level between processing instructions, comments and the root tag. * A 'pretty printed' serialisation is now terminated with a newline. * Second argument to ``lxml.etree.Extension()`` helper is no longer required, third argument is now a keyword-only argument ``ns``. * ``lxml.html.tostring`` takes an ``encoding`` argument. 2.0alpha5 (2007-11-24) ====================== Features added -------------- * Rich comparison of ``element.attrib`` proxies. * ElementTree compatible TreeBuilder class. * Use default prefixes for some common XML namespaces. * ``lxml.html.clean.Cleaner`` now allows for a ``host_whitelist``, and two overridable methods: ``allow_embedded_url(el, url)`` and the more general ``allow_element(el)``. * Extended slicing of Elements as in ``element[1:-1:2]``, both in etree and in objectify * Resolvers can now provide a ``base_url`` keyword argument when resolving a document as string data. * When using ``lxml.doctestcompare`` you can give the doctest option ``NOPARSE_MARKUP`` (like ``# doctest: +NOPARSE_MARKUP``) to suppress the special checking for one test. Bugs fixed ---------- * Target parser failed to report comments. * In the ``lxml.html`` ``iter_links`` method, links in ```` tags weren't recognized. (Note: plugin-specific link parameters still aren't recognized.) Also, the ```` tag, though not standard, is now included in ``lxml.html.defs.special_inline_tags``. * Using custom resolvers on XSLT stylesheets parsed from a string could request ill-formed URLs. * With ``lxml.doctestcompare`` if you do ```` in your output, it will then be namespace-neutral (before the ellipsis was treated as a real namespace). Other changes ------------- * The module source files were renamed to "lxml.*.pyx", such as "lxml.etree.pyx". This was changed for consistency with the way Pyrex commonly handles package imports. The main effect is that classes now know about their fully qualified class name, including the package name of their module. * Keyword-only arguments in some API functions, especially in the parsers and serialisers. 2.0alpha4 (2007-10-07) ====================== Features added -------------- Bugs fixed ---------- * AttributeError in feed parser on parse errors Other changes ------------- * Tag name validation in lxml.etree (and lxml.html) now distinguishes between HTML tags and XML tags based on the parser that was used to parse or create them. HTML tags no longer reject any non-ASCII characters in tag names but only spaces and the special characters ``<>&/"'``. 2.0alpha3 (2007-09-26) ====================== Features added -------------- * Separate ``feed_error_log`` property for the feed parser interface. The normal parser interface and ``iterparse`` continue to use ``error_log``. * The normal parsers and the feed parser interface are now separated and can be used concurrently on the same parser instance. * ``fromstringlist()`` and ``tostringlist()`` functions as in ElementTree 1.3 * ``iterparse()`` accepts an ``html`` boolean keyword argument for parsing with the HTML parser (note that this interface may be subject to change) * Parsers accept an ``encoding`` keyword argument that overrides the encoding of the parsed documents. * New C-API function ``hasChild()`` to test for children * ``annotate()`` function in objectify can annotate with Python types and XSI types in one step. Accompanied by ``xsiannotate()`` and ``pyannotate()``. Bugs fixed ---------- * XML feed parser setup problem * Type annotation for unicode strings in ``DataElement()`` Other changes ------------- * lxml.etree now emits a warning if you use XPath with libxml2 2.6.27 (which can crash on certain XPath errors) * Type annotation in objectify now preserves the already annotated type by default to prevent loosing type information that is already there. 2.0alpha2 (2007-09-15) ====================== Features added -------------- * ``ET.write()``, ``tostring()`` and ``tounicode()`` now accept a keyword argument ``method`` that can be one of 'xml' (or None), 'html' or 'text' to serialise as XML, HTML or plain text content. * ``iterfind()`` method on Elements returns an iterator equivalent to ``findall()`` * ``itertext()`` method on Elements * Setting a QName object as value of the .text property or as an attribute will resolve its prefix in the respective context * ElementTree-like parser target interface as described in http://effbot.org/elementtree/elementtree-xmlparser.htm * ElementTree-like feed parser interface on XMLParser and HTMLParser (``feed()`` and ``close()`` methods) Bugs fixed ---------- * lxml failed to serialise namespace declarations of elements other than the root node of a tree * Race condition in XSLT where the resolver context leaked between concurrent XSLT calls Other changes ------------- * ``element.getiterator()`` returns a list, use ``element.iter()`` to retrieve an iterator (ElementTree 1.3 compatible behaviour) 2.0alpha1 (2007-09-02) ====================== Features added -------------- * Reimplemented ``objectify.E`` for better performance and improved integration with objectify. Provides extended type support based on registered PyTypes. * XSLT objects now support deep copying * New ``makeSubElement()`` C-API function that allows creating a new subelement straight with text, tail and attributes. * XPath extension functions can now access the current context node (``context.context_node``) and use a context dictionary (``context.eval_context``) from the context provided in their first parameter * HTML tag soup parser based on BeautifulSoup in ``lxml.html.ElementSoup`` * New module ``lxml.doctestcompare`` by Ian Bicking for writing simplified doctests based on XML/HTML output. Use by importing ``lxml.usedoctest`` or ``lxml.html.usedoctest`` from within a doctest. * New module ``lxml.cssselect`` by Ian Bicking for selecting Elements with CSS selectors. * New package ``lxml.html`` written by Ian Bicking for advanced HTML treatment. * Namespace class setup is now local to the ``ElementNamespaceClassLookup`` instance and no longer global. * Schematron validation (incomplete in libxml2) * Additional ``stringify`` argument to ``objectify.PyType()`` takes a conversion function to strings to support setting text values from arbitrary types. * Entity support through an ``Entity`` factory and element classes. XML parsers now have a ``resolve_entities`` keyword argument that can be set to False to keep entities in the document. * ``column`` field on error log entries to accompany the ``line`` field * Error specific messages in XPath parsing and evaluation NOTE: for evaluation errors, you will now get an XPathEvalError instead of an XPathSyntaxError. To catch both, you can except on ``XPathError`` * The regular expression functions in XPath now support passing a node-set instead of a string * Extended type annotation in objectify: new ``xsiannotate()`` function * EXSLT RegExp support in standard XPath (not only XSLT) Bugs fixed ---------- * lxml.etree did not check tag/attribute names * The XML parser did not report undefined entities as error * The text in exceptions raised by XML parsers, validators and XPath evaluators now reports the first error that occurred instead of the last * Passing '' as XPath namespace prefix did not raise an error * Thread safety in XPath evaluators Other changes ------------- * objectify.PyType for None is now called "NoneType" * ``el.getiterator()`` renamed to ``el.iter()``, following ElementTree 1.3 - original name is still available as alias * In the public C-API, ``findOrBuildNodeNs()`` was replaced by the more generic ``findOrBuildNodeNsPrefix`` * Major refactoring in XPath/XSLT extension function code * Network access in parsers disabled by default From chairos at gmail.com Sat Feb 2 07:12:52 2008 From: chairos at gmail.com (Jon Rosebaugh) Date: Sat, 2 Feb 2008 00:12:52 -0600 Subject: [lxml-dev] Segfault and bus error when importing lxml.html.clean after importing webbrowser Message-ID: I was trying to use lxml.html.clean to sanitize comments in my blog. Unfortunately, although I can import and use it in a standalone console session, it fails within the webapp. Sometimes it segfaults, and sometimes it's a bus error instead. After going through all the imports to see what _they_ imported, I finally tracked down a minimal example that can cause the problem: import webbrowser import lxml.html.clean If I reverse the order of imports, everything works fine, so for the moment I've worked around it by making sure that lxml.html.clean is imported the very first thing. I have lxml compiled from the 2.0 tgz from the site, libxml2 2.6.31 and libxslt 1.1.22 installed via macports (both the latest versions macports has), Cython 0.9.6.11 installed, and I'm using Python 2.5.1 as downloaded from python.org for OS X. Here's the crash log Mac OS X provides: Process: Python [82702] Path: /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [188] Date/Time: 2008-02-02 00:05:49.472 -0600 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005 Crashed Thread: 0 Thread 0 Crashed: 0 libxml2.2.dylib 0x91cda419 xmlDictLookup + 360 1 libxml2.2.dylib 0x00d78728 xmlXPathCompExprAdd + 280 2 libxml2.2.dylib 0x00d84e0c xmlXPathCompStep + 1004 3 libxml2.2.dylib 0x00d85812 xmlXPathCompRelativeLocationPath + 98 4 libxml2.2.dylib 0x00d86235 xmlXPathCompPathExpr + 1973 5 libxml2.2.dylib 0x00d86c35 xmlXPathCompUnaryExpr + 213 6 libxml2.2.dylib 0x00d86e3f xmlXPathCompMultiplicativeExpr + 15 7 libxml2.2.dylib 0x00d8702f xmlXPathCompAdditiveExpr + 15 8 libxml2.2.dylib 0x00d8717f xmlXPathCompRelationalExpr + 15 9 libxml2.2.dylib 0x00d8732f xmlXPathCompEqualityExpr + 15 10 libxml2.2.dylib 0x00d8748f xmlXPathCompAndExpr + 15 11 libxml2.2.dylib 0x00d87602 xmlXPathCompileExpr + 18 12 libxml2.2.dylib 0x00d868ec xmlXPathCompPathExpr + 3692 13 libxml2.2.dylib 0x00d86c35 xmlXPathCompUnaryExpr + 213 14 libxml2.2.dylib 0x00d86e3f xmlXPathCompMultiplicativeExpr + 15 15 libxml2.2.dylib 0x00d8702f xmlXPathCompAdditiveExpr + 15 16 libxml2.2.dylib 0x00d8717f xmlXPathCompRelationalExpr + 15 17 libxml2.2.dylib 0x00d8732f xmlXPathCompEqualityExpr + 15 18 libxml2.2.dylib 0x00d8748f xmlXPathCompAndExpr + 15 19 libxml2.2.dylib 0x00d87602 xmlXPathCompileExpr + 18 20 libxml2.2.dylib 0x00d87872 xmlXPathCompPredicate + 194 21 libxml2.2.dylib 0x00d84d4e xmlXPathCompStep + 814 22 libxml2.2.dylib 0x00d85812 xmlXPathCompRelativeLocationPath + 98 23 libxml2.2.dylib 0x00d86235 xmlXPathCompPathExpr + 1973 24 libxml2.2.dylib 0x00d86c35 xmlXPathCompUnaryExpr + 213 25 libxml2.2.dylib 0x00d86e3f xmlXPathCompMultiplicativeExpr + 15 26 libxml2.2.dylib 0x00d8702f xmlXPathCompAdditiveExpr + 15 27 libxml2.2.dylib 0x00d8717f xmlXPathCompRelationalExpr + 15 28 libxml2.2.dylib 0x00d8732f xmlXPathCompEqualityExpr + 15 29 libxml2.2.dylib 0x00d8748f xmlXPathCompAndExpr + 15 30 libxml2.2.dylib 0x00d87602 xmlXPathCompileExpr + 18 31 libxml2.2.dylib 0x00d8c6ca xmlXPathCtxtCompile + 90 32 etree.so 0x00bdc1d7 __pyx_pf_4lxml_5etree_5XPath___init__ + 551 (lxml.etree.c:79217) 33 org.python.python 0x00448981 type_call + 166 (typeobject.c:436) 34 org.python.python 0x003f9278 PyObject_Call + 45 (abstract.c:1860) 35 org.python.python 0x00480851 PyEval_EvalFrameEx + 9242 (ceval.c:3775) 36 org.python.python 0x00484cdc PyEval_EvalCodeEx + 1819 (ceval.c:2831) 37 org.python.python 0x00484e90 PyEval_EvalCode + 87 (ceval.c:500) 38 org.python.python 0x0049bcbe PyImport_ExecCodeModuleEx + 193 (import.c:669) 39 org.python.python 0x0049c114 load_source_module + 726 (import.c:953) 40 org.python.python 0x0049cd9b import_submodule + 293 (import.c:2394) 41 org.python.python 0x0049cfe9 load_next + 195 (import.c:2214) 42 org.python.python 0x0049d4dd import_module_level + 213 (import.c:2002) 43 org.python.python 0x0049d98d PyImport_ImportModuleLevel + 45 (import.c:2066) 44 org.python.python 0x00478917 builtin___import__ + 156 (bltinmodule.c:49) 45 org.python.python 0x003f9278 PyObject_Call + 45 (abstract.c:1860) 46 org.python.python 0x0047d5b2 PyEval_CallObjectWithKeywords + 112 (ceval.c:3433) 47 org.python.python 0x00481464 PyEval_EvalFrameEx + 12333 (ceval.c:2063) 48 org.python.python 0x00484cdc PyEval_EvalCodeEx + 1819 (ceval.c:2831) 49 org.python.python 0x00484e90 PyEval_EvalCode + 87 (ceval.c:500) 50 org.python.python 0x004a7cf2 PyRun_InteractiveOneFlags + 460 (pythonrun.c:1271) 51 org.python.python 0x004a7f2e PyRun_InteractiveLoopFlags + 85 (pythonrun.c:723) 52 org.python.python 0x004a86da PyRun_AnyFileExFlags + 155 (pythonrun.c:690) 53 org.python.python 0x004b5bb6 Py_Main + 3077 (main.c:523) 54 org.python.python 0x00001f8e 0x1000 + 3982 55 org.python.python 0x00001eb5 0x1000 + 3765 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x009d0bd4 ebx: 0x91cda2c2 ecx: 0x00000004 edx: 0x0000e3d0 edi: 0x00000005 esi: 0x00000005 ebp: 0xbfffd428 esp: 0xbfffd3f0 ss: 0x0000001f efl: 0x00010202 eip: 0x91cda419 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000005 Binary Images: 0x1000 - 0x1fff +org.python.python 2.5a0 (2.5alpha0) /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 0xea000 - 0xebfff +cStringIO.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/cStringIO.so 0x3f0000 - 0x4e4fc3 +org.python.python 2.5a0 (2.5) /Library/Frameworks/Python.framework/Versions/2.5/Python 0x7f4000 - 0x7f5ffb +select.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/select.so 0x900000 - 0x926fdf +readline.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/readline.so 0x93e000 - 0x96ffe7 +libncurses.5.dylib ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/libncurses.5.dylib 0x98b000 - 0x98dfff +collections.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/collections.so 0x99a000 - 0x99bfff +fcntl.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/fcntl.so 0x9e3000 - 0x9e6ffb +_struct.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_struct.so 0x9f4000 - 0x9f5ff3 +time.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/time.so 0xb00000 - 0xb02fff +binascii.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/binascii.so 0xb0d000 - 0xb0e073 +icglue.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/icglue.so 0xb1c000 - 0xb1ffff +strop.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/strop.so 0xb2c000 - 0xb2ffff +_Res.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_Res.so 0xb3e000 - 0xb44fff +_File.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_File.so 0xb63000 - 0xb64ffd +MacOS.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/MacOS.so 0xbb5000 - 0xc67ff9 +etree.so ??? (???) <9f2b581810d292f482356b73a83969f9> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/lxml-2.0-py2.5-macosx-10.3-fat.egg/lxml/etree.so 0xcdd000 - 0xd09fff +libxslt.1.dylib ??? (???) /opt/local/lib/libxslt.1.dylib 0xd13000 - 0xd1ffff +libexslt.0.dylib ??? (???) /opt/local/lib/libexslt.0.dylib 0xd25000 - 0xe27fef +libxml2.2.dylib ??? (???) /opt/local/lib/libxml2.2.dylib 0xe59000 - 0xe69ffd +libz.1.dylib ??? (???) /opt/local/lib/libz.1.dylib 0xe6e000 - 0xf65ff0 +libiconv.2.dylib ??? (???) /opt/local/lib/libiconv.2.dylib 0xfd2000 - 0xfd4fff +operator.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/operator.so 0xfdf000 - 0xfe2fff +itertools.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/itertools.so 0x8fe00000 - 0x8fe2d883 dyld 95.3 (???) <81592e798780564b5d46b988f7ee1a6a> /usr/lib/dyld 0x9029d000 - 0x902f6fff libGLU.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x902f7000 - 0x906b5fea libLAPACK.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x906b6000 - 0x907fbff7 com.apple.ImageIO.framework 2.0.0 (2.0.0) <154d4d8cda2bd99518cbabc9f2d69833> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x907fc000 - 0x9080affd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib 0x908b7000 - 0x908b7fff com.apple.Carbon 136 (136) <98a5e3bc0c4fa44bbb09713bb88707fe> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x908c8000 - 0x908ccfff libGIF.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x908cd000 - 0x90b46fe7 com.apple.Foundation 6.5.1 (677.1) <85ac18c7cd454378db6122bea0c00965> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x90b47000 - 0x90e20fe7 com.apple.CoreServices.CarbonCore 783 (783) <8370e664eeb25edc98d5c1f5405b06ae> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90e21000 - 0x90e21ffd com.apple.Accelerate.vecLib 3.4 (vecLib 3.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x90fde000 - 0x9101dfef libTIFF.dylib ??? (???) <6d0f80e9d4d81f3f64c876aca005bd53> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x9101e000 - 0x910aaff7 com.apple.LaunchServices 286 (286) <72b15e7a01e42d510f0339e90113d5d6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x910ab000 - 0x910caffa libJPEG.dylib ??? (???) <0cfb80109d624beb9ceb3c43b6c5ec10> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x910cb000 - 0x910e1fe7 com.apple.CoreVideo 1.5.0 (1.5.0) <7e010557527a0e6d49147c297d16850a> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x910e2000 - 0x911c1fff libobjc.A.dylib ??? (???) <5eda47fec2d0e7853b3506aa1fd2dafa> /usr/lib/libobjc.A.dylib 0x911eb000 - 0x91345fe3 libSystem.B.dylib ??? (???) <8ecc83dc0399be3946f7a46e88cf4bbb> /usr/lib/libSystem.B.dylib 0x91346000 - 0x91350feb com.apple.audio.SoundManager 3.9.2 (3.9.2) <0f2ba6e891d3761212cf5a5e6134d683> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound 0x91c34000 - 0x91c3afff com.apple.print.framework.Print 218 (220) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x91c3b000 - 0x91c51fff com.apple.DictionaryServices 1.0.0 (1.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x91c52000 - 0x91c6dffb libPng.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x91c78000 - 0x91c78ffb com.apple.installserver.framework 1.0 (8) /System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/InstallServer 0x91cd8000 - 0x91db9ff7 libxml2.2.dylib ??? (???) <450ec38b57fb46013847cce851001a2f> /usr/lib/libxml2.2.dylib 0x91e5c000 - 0x91f0cfff edu.mit.Kerberos 6.0.11 (6.0.11) <33c25789baedcd70a7e24881775dd9ad> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x92527000 - 0x92533ff5 libGL.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x9253c000 - 0x925c6fff com.apple.framework.IOKit 1.5.1 (???) <5176a7383151a19c962334009fef2c6d> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x9260a000 - 0x926b1fff com.apple.QD 3.11.50 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x926b2000 - 0x92768fe3 com.apple.CoreServices.OSServices 210.2 (210.2) <4ed69f07fc0f211ab32d1ee96e281fc2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x92a21000 - 0x92a21ff8 com.apple.ApplicationServices 34 (34) <8f910fa65f01d401ad8d04cc933cf887> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x939aa000 - 0x93a75fff com.apple.ColorSync 4.5.0 (4.5.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x93a7c000 - 0x93abefef com.apple.NavigationServices 3.5.1 (161) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x93c16000 - 0x93cc5fff com.apple.DesktopServices 1.4.3 (1.4.3) <66d5ed56111c43d234e235d365d02469> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x93cc6000 - 0x93cf0fef libauto.dylib ??? (???) /usr/lib/libauto.dylib 0x93d61000 - 0x94067fff com.apple.HIToolbox 1.5.0 (???) <1b872a7151ee3f80c9c736a3e46d00d9> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x94080000 - 0x94147ff2 com.apple.vImage 3.0 (3.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x94196000 - 0x941a6ffc com.apple.LangAnalysis 1.6.4 (1.6.4) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x941a7000 - 0x94226ff5 com.apple.SearchKit 1.2.0 (1.2.0) <277b460da86bc222785159fe77e2e2ed> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x94227000 - 0x942d9ffb libcrypto.0.9.7.dylib ??? (???) <330b0e48e67faffc8c22dfc069ca7a47> /usr/lib/libcrypto.0.9.7.dylib 0x942da000 - 0x942daffa com.apple.CoreServices 32 (32) <2fcc8f3bd5bbfc000b476cad8e6a3dd2> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x942db000 - 0x94352fe3 com.apple.CFNetwork 220 (221) <972a41911805859205b057a6f5b91e8d> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x943f2000 - 0x943f7fff com.apple.CommonPanels 1.2.4 (85) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x943f8000 - 0x94427fe3 com.apple.AE 402 (402) <994ba8e884aefe7bf1fc5987df099e7b> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x94428000 - 0x944afff7 libsqlite3.0.dylib ??? (???) <273efcb717e89c21207c851d7d33fda4> /usr/lib/libsqlite3.0.dylib 0x944b0000 - 0x944ddfeb libvDSP.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x944de000 - 0x944dfffc libffi.dylib ??? (???) /usr/lib/libffi.dylib 0x9455e000 - 0x9456efff com.apple.speech.synthesis.framework 3.6.59 (3.6.59) <4ffef145fad3d4d787e0c33eab26b336> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x9456f000 - 0x9458dfff libresolv.9.dylib ??? (???) <54e6a08c2f108bdf5916fb483d51961b> /usr/lib/libresolv.9.dylib 0x945c8000 - 0x945dcff3 com.apple.ImageCapture 4.0 (5.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x945dd000 - 0x949edfef libBLAS.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x949ee000 - 0x94a4aff7 com.apple.htmlrendering 68 (1.1.3) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x94a51000 - 0x94f1dffe libGLProgrammability.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x94f1f000 - 0x94f79ff7 com.apple.CoreText 2.0.0 (???) <7fa39cd5bc847615ec02e7c7a37c0508> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x94f7a000 - 0x95143fef com.apple.security 5.0.1 (32736) <8c9eda0fcc1d8a571543025ac900715f> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x95156000 - 0x957edfef com.apple.CoreGraphics 1.351.0 (???) <7a6f399039eed6dbe845c169f7d21a70> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x957ee000 - 0x957fbfe7 com.apple.opengl 1.5.5 (1.5.5) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x95808000 - 0x95820fff com.apple.openscripting 1.2.6 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x95835000 - 0x958b1feb com.apple.audio.CoreAudio 3.1.0 (3.1) <70bb7c657061631491029a61babe0b26> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x958b2000 - 0x958b5fff com.apple.help 1.1 (36) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x95ab6000 - 0x95ab8ff5 libRadiance.dylib ??? (???) <20eadb285da83df96c795c2c5fa20590> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x95ab9000 - 0x95abbfff com.apple.securityhi 3.0 (30817) <2b2854123fed609d1820d2779e2e0963> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x95b66000 - 0x95babfef com.apple.Metadata 10.5.0 (398) <4fd74fba0062c2e08ec4b1c10b40ff63> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x95bac000 - 0x95c3eff3 com.apple.ApplicationServices.ATS 3.0 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x95c3f000 - 0x95c9cffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib 0x95f3d000 - 0x95f8dff7 com.apple.HIServices 1.6.0 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x96083000 - 0x96116fff com.apple.ink.framework 101.3 (86) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x9642d000 - 0x96463fff com.apple.SystemConfiguration 1.9.0 (1.9.0) <7919d9588c3b0d556646e555b7193f1f> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x96483000 - 0x965bbff7 libicucore.A.dylib ??? (???) /usr/lib/libicucore.A.dylib 0x96782000 - 0x967fcff8 com.apple.print.framework.PrintCore 5.5 (245) <9441d178f4b430cf92b67bf346646693> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x96835000 - 0x9685cfff libcups.2.dylib ??? (???) <5521498e8902ddd0b15cfaa7db384e29> /usr/lib/libcups.2.dylib 0x9685d000 - 0x96897ff7 com.apple.coreui 0.1 (60) /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x96898000 - 0x9689ffe9 libgcc_s.1.dylib ??? (???) /usr/lib/libgcc_s.1.dylib 0x968a4000 - 0x968abffe libbsm.dylib ??? (???) /usr/lib/libbsm.dylib 0x968ea000 - 0x96c80ff7 com.apple.QuartzCore 1.5.1 (1.5.1) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x96c81000 - 0x96ca5fff libxslt.1.dylib ??? (???) <4933ddc7f6618743197aadc85b33b5ab> /usr/lib/libxslt.1.dylib 0x96ca6000 - 0x96caefff com.apple.DiskArbitration 2.2 (2.2) <1551b2af557fdf6f368f93e093933852> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x96caf000 - 0x96cafffd com.apple.Accelerate 1.4 (Accelerate 1.4) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x96cb0000 - 0x96d24fef libvMisc.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x96d68000 - 0x96da5ff7 libGLImage.dylib ??? (???) <202d73e6a4688fc06ff11b71910c2ce7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x96dd6000 - 0x96dd7fef libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x96dd8000 - 0x96f0afe7 com.apple.CoreFoundation 6.5 (476) <8bfebc0dbad6fc33bea0fa00a1b9ec37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x96f0b000 - 0x96f14fff com.apple.speech.recognition.framework 3.7.24 (3.7.24) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0xfffe8000 - 0xfffebfff libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib From stefan_ml at behnel.de Sat Feb 2 07:34:57 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 02 Feb 2008 07:34:57 +0100 Subject: [lxml-dev] Segfault and bus error when importing lxml.html.clean after importing webbrowser In-Reply-To: References: Message-ID: <47A40F11.8070401@behnel.de> Hi, Jon Rosebaugh wrote: > I was trying to use lxml.html.clean to sanitize comments in my blog. > Unfortunately, although I can import and use it in a standalone > console session, it fails within the webapp. Sometimes it segfaults, > and sometimes it's a bus error instead. > After going through all the imports to see what _they_ imported, I > finally tracked down a minimal example that can cause the problem: > > import webbrowser > import lxml.html.clean > > If I reverse the order of imports, everything works fine, so for the > moment I've worked around it by making sure that lxml.html.clean is > imported the very first thing. > > I have lxml compiled from the 2.0 tgz from the site, libxml2 2.6.31 > and libxslt 1.1.22 installed via macports (both the latest versions > macports has), Cython 0.9.6.11 installed, and I'm using Python 2.5.1 > as downloaded from python.org for OS X. Could you please try two things: - uninstall Cython (you do not need it to build from release sources) or make sure it is at least 0.9.6.11b (with a 'b'), not only 0.9.6.11, which has bugs - set DYLD_LIBRARY_PATH as explained here: http://codespeak.net/lxml/build.html#providing-newer-library-versions-on-mac-os-x If that doesn't work, try building statically to make sure MacOS-X gets your libs right (which you definitely want for a production environment). Stefan From chairos at gmail.com Sat Feb 2 08:11:29 2008 From: chairos at gmail.com (Jon Rosebaugh) Date: Sat, 2 Feb 2008 01:11:29 -0600 Subject: [lxml-dev] Segfault and bus error when importing lxml.html.clean after importing webbrowser In-Reply-To: <47A40F11.8070401@behnel.de> References: <47A40F11.8070401@behnel.de> Message-ID: On Feb 2, 2008 12:34 AM, Stefan Behnel wrote: > Could you please try two things: > > - uninstall Cython (you do not need it to build from release sources) or make > sure it is at least 0.9.6.11b (with a 'b'), not only 0.9.6.11, which has bugs > > - set DYLD_LIBRARY_PATH as explained here: > > http://codespeak.net/lxml/build.html#providing-newer-library-versions-on-mac-os-x These did not work. > If that doesn't work, try building statically to make sure MacOS-X gets your > libs right (which you definitely want for a production environment). My production deployment will actually be on Debian Linux; this is just my development machine. That said, I tried looking at the static build directions, but they're for Windows. I did download all the source archives for the various libraries, but I believe I have to configure them in a certain way for the static build? At any rate, the directories aren't the same as in the Windows example, and I'm not sure which directories are the right ones. From stefan_ml at behnel.de Sat Feb 2 10:50:16 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 02 Feb 2008 10:50:16 +0100 Subject: [lxml-dev] Segfault and bus error when importing lxml.html.clean after importing webbrowser In-Reply-To: References: <47A40F11.8070401@behnel.de> Message-ID: <47A43CD8.1020308@behnel.de> Hi, Jon Rosebaugh wrote: > My production deployment will actually be on Debian Linux; this is > just my development machine. That said, I tried looking at the static > build directions, but they're for Windows. I did download all the > source archives for the various libraries, but I believe I have to > configure them in a certain way for the static build? No, normally they build everything you need for both static and dynamic linking. I have no idea how MacOS-X works here, but you should already have the libraries installed on your system, maybe you just need the development packages with header files and static build libs. But if you have the source directories, something like this might work: # cd /path/to/libxml2-src # ./configure CFLAGS="whatever you use" --without-python # make # cd /path/to/libxslt-src # ./configure CFLAGS="whatever you use" --without-python \ --with-libxml-src=/path/to/libxml2-src # make and then open lxml's setup.py and set the static include dirs to /path/to/libxml2-src/include /path/to/libxslt-src/libxslt /path/to/libxslt-src/libexslt + the normal system include dirs for zlib, iconv, etc. and the static lib dirs to /path/to/libxml2-src/.libs /path/to/libxslt-src/libxslt/.libs /path/to/libxslt-src/libexslt/.libs You may have to add something like "-liconv" and "-lz" to the static cflags to compile against the other libs, or maybe you need to link those statically also. Just try it out. The compiler calls from the standard build of lxml will give you hints what else you need. Hope that helps, Stefan From chairos at gmail.com Sat Feb 2 12:31:45 2008 From: chairos at gmail.com (Jon Rosebaugh) Date: Sat, 2 Feb 2008 05:31:45 -0600 Subject: [lxml-dev] Segfault and bus error when importing lxml.html.clean after importing webbrowser In-Reply-To: <47A43CD8.1020308@behnel.de> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> Message-ID: No luck. Apparently I need a universal build of libxml2 and libxslt in order for lxml to build, and I can't figure out how to compile those manually. I tried telling lxml to statically link against the universal builds provided by macports, but I got segfaulting again. On Sat, Feb 2, 2008 at 3:50 AM, Stefan Behnel wrote: > Hi, > > > Jon Rosebaugh wrote: > > My production deployment will actually be on Debian Linux; this is > > just my development machine. That said, I tried looking at the static > > build directions, but they're for Windows. I did download all the > > source archives for the various libraries, but I believe I have to > > configure them in a certain way for the static build? > > No, normally they build everything you need for both static and dynamic linking. > > I have no idea how MacOS-X works here, but you should already have the > libraries installed on your system, maybe you just need the development > packages with header files and static build libs. > > But if you have the source directories, something like this might work: > > # cd /path/to/libxml2-src > # ./configure CFLAGS="whatever you use" --without-python > # make > # cd /path/to/libxslt-src > # ./configure CFLAGS="whatever you use" --without-python \ > --with-libxml-src=/path/to/libxml2-src > # make > > and then open lxml's setup.py and set the static include dirs to > > /path/to/libxml2-src/include > /path/to/libxslt-src/libxslt > /path/to/libxslt-src/libexslt > + the normal system include dirs for zlib, iconv, etc. > > and the static lib dirs to > > /path/to/libxml2-src/.libs > /path/to/libxslt-src/libxslt/.libs > /path/to/libxslt-src/libexslt/.libs > > You may have to add something like "-liconv" and "-lz" to the static cflags to > compile against the other libs, or maybe you need to link those statically > also. Just try it out. The compiler calls from the standard build of lxml will > give you hints what else you need. > > Hope that helps, > Stefan > > From stefan_ml at behnel.de Sat Feb 2 12:40:50 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 02 Feb 2008 12:40:50 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> Message-ID: <47A456C2.8020108@behnel.de> Hi, Jon Rosebaugh wrote: > No luck. Apparently I need a universal build of libxml2 and libxslt in > order for lxml to build, and I can't figure out how to compile those > manually. I tried telling lxml to statically link against the > universal builds provided by macports, but I got segfaulting again. Hmm, too bad. Ok, calling for help here. Are there any other Mac users on the list who could give hints? Stefan From ebgssth at gmail.com Sat Feb 2 14:26:51 2008 From: ebgssth at gmail.com (js) Date: Sat, 2 Feb 2008 22:26:51 +0900 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: <47A456C2.8020108@behnel.de> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: Hi Stefan and Jon, I've just intalled lxml-2.0 on OS X Tiger by using MacPorts and it worked without any problem. lxml-2.0 port is not yet available so I have to patch the portfile. I already sent the patch to MacPorts team so I hope that will be available soon. You can fetch the patch from below. http://trac.macosforge.org/projects/macports/ticket/14137 Thanks. On Feb 2, 2008 8:40 PM, Stefan Behnel wrote: > Hi, > > Jon Rosebaugh wrote: > > No luck. Apparently I need a universal build of libxml2 and libxslt in > > order for lxml to build, and I can't figure out how to compile those > > manually. I tried telling lxml to statically link against the > > universal builds provided by macports, but I got segfaulting again. > > Hmm, too bad. > > Ok, calling for help here. Are there any other Mac users on the list who could > give hints? > > Stefan > > _______________________________________________ > lxml-dev mailing list > lxml-dev at codespeak.net > http://codespeak.net/mailman/listinfo/lxml-dev > From piet at cs.uu.nl Sat Feb 2 14:03:01 2008 From: piet at cs.uu.nl (Piet van Oostrum) Date: Sat, 2 Feb 2008 14:03:01 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: <47A456C2.8020108@behnel.de> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: <18340.27141.491714.859261@cp453394-a.venlo1.lb.home.nl> >>>>> Stefan Behnel (SB) wrote: >SB> Hi, >SB> Jon Rosebaugh wrote: >>> No luck. Apparently I need a universal build of libxml2 and libxslt in >>> order for lxml to build, and I can't figure out how to compile those >>> manually. I tried telling lxml to statically link against the >>> universal builds provided by macports, but I got segfaulting again. >SB> Hmm, too bad. >SB> Ok, calling for help here. Are there any other Mac users on the >SB> list who could give hints? I have the latest versions of libxml2 and libxslt installed with macports. Macports has a possibility to specify that it should install universal versions of the libraries but I haven't done that. When I compiled lxml 2.0 it did complain about something with ppc and intel architectures (I have an Intel machine), but the resulting library did work (it did run the tests). -- Piet van Oostrum URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From chairos at gmail.com Sat Feb 2 14:41:59 2008 From: chairos at gmail.com (Jon Rosebaugh) Date: Sat, 2 Feb 2008 07:41:59 -0600 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: On Feb 2, 2008 7:26 AM, js wrote: > Hi Stefan and Jon, > > I've just intalled lxml-2.0 on OS X Tiger by using MacPorts and it > worked without any problem. > lxml-2.0 port is not yet available so I have to patch the portfile. > I already sent the patch to MacPorts team so I hope > that will be available soon. > You can fetch the patch from below. > http://trac.macosforge.org/projects/macports/ticket/14137 > > Thanks. > I use the framework Python from python.org rather than the python available from macports, so it's my understanding that I can't use any macports python packages. Am I wrong? From ebgssth at gmail.com Sat Feb 2 14:50:38 2008 From: ebgssth at gmail.com (js) Date: Sat, 2 Feb 2008 22:50:38 +0900 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: Beats me. I've never used the framework Python. Not 100% sure but I *think* MacPorts python will work even if you installed the framework python, so If you don't have to stick to, give it a try. On Feb 2, 2008 10:41 PM, Jon Rosebaugh wrote: > On Feb 2, 2008 7:26 AM, js wrote: > > Hi Stefan and Jon, > > > > I've just intalled lxml-2.0 on OS X Tiger by using MacPorts and it > > worked without any problem. > > lxml-2.0 port is not yet available so I have to patch the portfile. > > I already sent the patch to MacPorts team so I hope > > that will be available soon. > > You can fetch the patch from below. > > http://trac.macosforge.org/projects/macports/ticket/14137 > > > > Thanks. > > > > I use the framework Python from python.org rather than the python > available from macports, so it's my understanding that I can't use any > macports python packages. Am I wrong? > From etiffany at alum.mit.edu Sat Feb 2 15:19:14 2008 From: etiffany at alum.mit.edu (Eric Tiffany) Date: Sat, 02 Feb 2008 09:19:14 -0500 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: Message-ID: Sorry for the late reply. I've been using lxml 1.3.x for a while on MacOS, using the Python 2.4 installed by MacPorts (along with the libxml2 and libxslt). This configuration works well for me, but heed the DYLD_LIBRARY_PATH suggestion. You need to make sure this is set to the correct value for both building and (especially) runtime. If you build lxml using the DYLD set but don't have it set at runtime, lxml will report that it is using the correct versions of libraries, when it is actually not. I think I reported that on this list a while ago. I use lxml within a Zope/Plone installation, and also from within Eclipse. However, I have not used lxml 2.0 in this config, so YMMV. But, I would suggest getting everything from MacPorts (python, libxml, etc.). Also, note that it seems like the recent MacPorts builds only create python2.4 and python2.5 binaries -- it's up to you to either link "python" to one of these, or make sure your config settings explicitly call /usr/local/bin/python2.4 Good luck ET On 2/2/08 8:50 AM, "js" wrote: > Beats me. > I've never used the framework Python. > Not 100% sure but I *think* MacPorts python will work > even if you installed the framework python, > so If you don't have to stick to, give it a try. > > On Feb 2, 2008 10:41 PM, Jon Rosebaugh wrote: >> On Feb 2, 2008 7:26 AM, js wrote: >>> Hi Stefan and Jon, >>> >>> I've just intalled lxml-2.0 on OS X Tiger by using MacPorts and it >>> worked without any problem. >>> lxml-2.0 port is not yet available so I have to patch the portfile. >>> I already sent the patch to MacPorts team so I hope >>> that will be available soon. >>> You can fetch the patch from below. >>> http://trac.macosforge.org/projects/macports/ticket/14137 >>> >>> Thanks. >>> >> >> I use the framework Python from python.org rather than the python >> available from macports, so it's my understanding that I can't use any >> macports python packages. Am I wrong? >> > _______________________________________________ > lxml-dev mailing list > lxml-dev at codespeak.net > http://codespeak.net/mailman/listinfo/lxml-dev From chairos at gmail.com Sat Feb 2 20:19:23 2008 From: chairos at gmail.com (Jon Rosebaugh) Date: Sat, 2 Feb 2008 13:19:23 -0600 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: <47A456C2.8020108@behnel.de> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: I'm beginning to think that it's not actually compiling statically. I set up a fresh install of OS X, installed Python, installed XCode, installed macports, libiconv, libxml2, zlib, libxslt, and tried building statically with the following options in the setup file and the following command: STATIC_INCLUDE_DIRS = ["/opt/local/include", "/opt/local/include/libxml2"] STATIC_LIBRARY_DIRS = ["/opt/local/lib"] STATIC_CFLAGS = ["-liconv", "-lz"] euterpe:~/lxml-2.0 jon$ export DYLD_LIBRARY_PATH=/opt/local/lib euterpe:~/lxml-2.0 jon$ python setup.py bdist_egg --static However, I noticed (a) that the gcc line still says -dynamic and (b) the file size of etree.so does not differ whether or not I build with the --static option. And I still get the same segfaults. Building lxml version 2.0. NOTE: Trying to build without Cython, pre-generated 'src/lxml/etree.c' needs to be available. running bdist_egg running egg_info writing src/lxml.egg-info/PKG-INFO writing top-level names to src/lxml.egg-info/top_level.txt writing dependency_links to src/lxml.egg-info/dependency_links.txt reading manifest file 'src/lxml.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no previously-included files found matching 'doc/pyrex.txt' writing manifest file 'src/lxml.egg-info/SOURCES.txt' installing library code to build/bdist.macosx-10.3-fat/egg running install_lib running build_py creating build creating build/lib.macosx-10.3-fat-2.5 creating build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/__init__.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/_elementpath.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/builder.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/cssselect.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/doctestcompare.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/ElementInclude.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/htmlbuilder.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/sax.py -> build/lib.macosx-10.3-fat-2.5/lxml copying src/lxml/usedoctest.py -> build/lib.macosx-10.3-fat-2.5/lxml creating build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/__init__.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/_dictmixin.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/_diffcommand.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/builder.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/clean.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/defs.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/diff.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/ElementSoup.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/formfill.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/setmixin.py -> build/lib.macosx-10.3-fat-2.5/lxml/html copying src/lxml/html/usedoctest.py -> build/lib.macosx-10.3-fat-2.5/lxml/html running build_ext building 'lxml.etree' extension creating build/temp.macosx-10.3-fat-2.5 creating build/temp.macosx-10.3-fat-2.5/src creating build/temp.macosx-10.3-fat-2.5/src/lxml gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/opt/local/include -I/opt/local/include/libxml2 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c src/lxml/lxml.etree.c -o build/temp.macosx-10.3-fat-2.5/src/lxml/lxml.etree.o -w -liconv -lz i686-apple-darwin8-gcc-4.0.1: -liconv: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -lz: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -liconv: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -lz: linker input file unused because linking not done gcc -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.5/src/lxml/lxml.etree.o -L/opt/local/lib -lxslt -lexslt -lxml2 -lz -lm -o build/lib.macosx-10.3-fat-2.5/lxml/etree.so building 'lxml.objectify' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/opt/local/include -I/opt/local/include/libxml2 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c src/lxml/lxml.objectify.c -o build/temp.macosx-10.3-fat-2.5/src/lxml/lxml.objectify.o -w -liconv -lz i686-apple-darwin8-gcc-4.0.1: -liconv: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -lz: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -liconv: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -lz: linker input file unused because linking not done gcc -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.5/src/lxml/lxml.objectify.o -L/opt/local/lib -lxslt -lexslt -lxml2 -lz -lm -o build/lib.macosx-10.3-fat-2.5/lxml/objectify.so building 'lxml.pyclasslookup' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/opt/local/include -I/opt/local/include/libxml2 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -c src/lxml/lxml.pyclasslookup.c -o build/temp.macosx-10.3-fat-2.5/src/lxml/lxml.pyclasslookup.o -w -liconv -lz i686-apple-darwin8-gcc-4.0.1: -liconv: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -lz: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -liconv: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -lz: linker input file unused because linking not done gcc -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.5/src/lxml/lxml.pyclasslookup.o -L/opt/local/lib -lxslt -lexslt -lxml2 -lz -lm -o build/lib.macosx-10.3-fat-2.5/lxml/pyclasslookup.so creating build/bdist.macosx-10.3-fat creating build/bdist.macosx-10.3-fat/egg creating build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/__init__.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/_elementpath.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/builder.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/cssselect.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/doctestcompare.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/ElementInclude.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/etree.so -> build/bdist.macosx-10.3-fat/egg/lxml creating build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/__init__.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/_dictmixin.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/_diffcommand.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/builder.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/clean.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/defs.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/diff.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/ElementSoup.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/formfill.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/setmixin.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/html/usedoctest.py -> build/bdist.macosx-10.3-fat/egg/lxml/html copying build/lib.macosx-10.3-fat-2.5/lxml/htmlbuilder.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/objectify.so -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/pyclasslookup.so -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/sax.py -> build/bdist.macosx-10.3-fat/egg/lxml copying build/lib.macosx-10.3-fat-2.5/lxml/usedoctest.py -> build/bdist.macosx-10.3-fat/egg/lxml byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/__init__.py to __init__.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/_elementpath.py to _elementpath.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/builder.py to builder.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/cssselect.py to cssselect.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/doctestcompare.py to doctestcompare.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/ElementInclude.py to ElementInclude.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/__init__.py to __init__.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/_dictmixin.py to _dictmixin.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/_diffcommand.py to _diffcommand.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/builder.py to builder.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/clean.py to clean.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/defs.py to defs.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/diff.py to diff.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/ElementSoup.py to ElementSoup.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/formfill.py to formfill.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/setmixin.py to setmixin.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/html/usedoctest.py to usedoctest.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/htmlbuilder.py to htmlbuilder.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/sax.py to sax.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/usedoctest.py to usedoctest.pyc creating stub loader for lxml/etree.so creating stub loader for lxml/objectify.so creating stub loader for lxml/pyclasslookup.so byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/etree.py to etree.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/objectify.py to objectify.pyc byte-compiling build/bdist.macosx-10.3-fat/egg/lxml/pyclasslookup.py to pyclasslookup.pyc creating build/bdist.macosx-10.3-fat/egg/EGG-INFO writing src/lxml.egg-info/native_libs.txt copying src/lxml.egg-info/PKG-INFO -> build/bdist.macosx-10.3-fat/egg/EGG-INFO copying src/lxml.egg-info/SOURCES.txt -> build/bdist.macosx-10.3-fat/egg/EGG-INFO copying src/lxml.egg-info/dependency_links.txt -> build/bdist.macosx-10.3-fat/egg/EGG-INFO copying src/lxml.egg-info/native_libs.txt -> build/bdist.macosx-10.3-fat/egg/EGG-INFO copying src/lxml.egg-info/not-zip-safe -> build/bdist.macosx-10.3-fat/egg/EGG-INFO copying src/lxml.egg-info/top_level.txt -> build/bdist.macosx-10.3-fat/egg/EGG-INFO creating dist creating 'dist/lxml-2.0-py2.5-macosx-10.3-fat.egg' and adding 'build/bdist.macosx-10.3-fat/egg' to it removing 'build/bdist.macosx-10.3-fat/egg' (and everything under it) euterpe:~/lxml-2.0 jon$ ls -lh dist/ total 3616 -rw-r--r-- 1 jon jon 1M Feb 2 13:03 lxml-2.0-py2.5-macosx-10.3-fat.egg From stefan_ml at behnel.de Sun Feb 3 18:17:30 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 03 Feb 2008 18:17:30 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: <47A5F72A.4000201@behnel.de> Hi, Jon Rosebaugh wrote: > I'm beginning to think that it's not actually compiling statically. I > set up a fresh install of OS X, installed Python, installed XCode, > installed macports, libiconv, libxml2, zlib, libxslt, and tried > building statically with the following options in the setup file and > the following command: > > STATIC_INCLUDE_DIRS = ["/opt/local/include", "/opt/local/include/libxml2"] > STATIC_LIBRARY_DIRS = ["/opt/local/lib"] > STATIC_CFLAGS = ["-liconv", "-lz"] > > euterpe:~/lxml-2.0 jon$ export DYLD_LIBRARY_PATH=/opt/local/lib > euterpe:~/lxml-2.0 jon$ python setup.py bdist_egg --static > > However, I noticed (a) that the gcc line still says -dynamic and (b) > the file size of etree.so does not differ whether or not I build with > the --static option. And I still get the same segfaults. Sorry for that, I just checked. "--static" will explicitly not work for other platforms than win32 (see the file setupinfo.py). I didn't write that code, so I wasn't aware how platform specific it is. Is there any chance you could figure out what you need to do for a static compile on MacOS? I.e., what binaries of the libs you need to include in the build, etc. If we can get them into setupinfo.py, I bet you wouldn't be the only happy Mac user. Otherwise, you'd have to stick with the normal build - but there's not much I can do myself to find out what's going wrong - I don't have a Mac (and when I see how difficult it seems to be to update a system library, I guess it won't become my favourite platform either...) Stefan From stefan_ml at behnel.de Sun Feb 3 21:56:37 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 03 Feb 2008 21:56:37 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: <47A62A85.9090802@behnel.de> Hi, js wrote: > seg fault occured to me, too. > Repeating etree.parse causes that. > > Here's the crash.log > Command: python2.5 > Path: /opt/local/bin/python2.5 > Parent: zsh [12091] > > Version: ??? (???) > > PID: 12274 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6f632e6f > > Thread 0 Crashed: > 0 libxml2.2.dylib 0x01371fc0 xmlDictFree + 45 > 1 libxml2.2.dylib 0x0137200e xmlDictFree + 123 > 2 etree.so 0x010634ad > __pyx_f_4lxml_5etree_24_ParserDictionaryContext_initThreadDictRef + 63 > (lxml.etree.c:45919) > .... Have you set DYLD... to the directory where the new lib versions are installed when running this? (compile time is *not* enough) If you did, could you try passing the "--without-threading" option to setup.py and rebuild with that to see if the problem persists? Stefan From mike at it-loops.com Sun Feb 3 22:14:24 2008 From: mike at it-loops.com (Michael Guntsche) Date: Sun, 3 Feb 2008 22:14:24 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: <47A456C2.8020108@behnel.de> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> Message-ID: <7638A5A1-E559-4035-A84A-142AECEAE27E@it-loops.com> On Feb 2, 2008, at 12:40, Stefan Behnel wrote: > Hmm, too bad. > > Ok, calling for help here. Are there any other Mac users on the > list who could > give hints? > > Stefan Here's a quick howto how I build dynamically linked lxml eggs under Macosx 10.4. Python is version 2.5 universal binary form python.org Via macports I installed libxml2 as an universal variant (+universal) and also the other needed libraries. I made sure that xml2-config from macports is found BEFORE the stock xml2-config in /usr/bin. Then I just called python setup.py bdist_egg to compile it. make test shows that 2.6.31 is used from macports but shows a bus error at the "test_inplace" test though. Apart from that I haven't noticed any problems. Kind regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080203/c2f903ea/attachment.bin From stefan_ml at behnel.de Mon Feb 4 08:09:06 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 04 Feb 2008 08:09:06 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: <7638A5A1-E559-4035-A84A-142AECEAE27E@it-loops.com> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> <7638A5A1-E559-4035-A84A-142AECEAE27E@it-loops.com> Message-ID: <47A6BA12.5030706@behnel.de> Hi, Michael Guntsche wrote: > Here's a quick howto how I build dynamically linked lxml eggs under > Macosx 10.4. > > Python is version 2.5 universal binary form python.org > Via macports I installed libxml2 as an universal variant (+universal) > and also the other needed libraries. > I made sure that xml2-config from macports is found BEFORE the stock > xml2-config in /usr/bin. > Then I just called python setup.py bdist_egg to compile it. > make test shows that 2.6.31 is used from macports but shows a bus error > at the "test_inplace" test though. Hmm, "test_inplace" doesn't tell me much, as it's just the make target for running all tests, not an individual test. However, it seems to be common for Mac users to have lxml crash, so we should definitely do something about it... Stefan From jholg at gmx.de Mon Feb 4 09:36:05 2008 From: jholg at gmx.de (jholg at gmx.de) Date: Mon, 04 Feb 2008 09:36:05 +0100 Subject: [lxml-dev] build & performance issues with 2.0beta2 In-Reply-To: <47A32027.1000806@behnel.de> References: <20080131154553.289150@gmx.net> <47A1F7E5.1000203@behnel.de> <20080201090342.15000@gmx.net> <47A2E88F.9090500@behnel.de> <20080201104604.14990@gmx.net> <47A2FD76.1080707@behnel.de> <47A32027.1000806@behnel.de> Message-ID: <20080204083605.62950@gmx.net> Hi Stefan, > >> src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsLongLong': > >> src/lxml/lxml.etree.c:110165: parse error before `long' > >> src/lxml/lxml.etree.c:110167: `val' undeclared (first use in this > function) > >> src/lxml/lxml.etree.c:110167: (Each undeclared identifier is reported > only once > >> src/lxml/lxml.etree.c:110167: for each function it appears in.) > >> src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsUnsignedLongLong': > >> src/lxml/lxml.etree.c:110185: parse error before `long' > >> src/lxml/lxml.etree.c:110187: `val' undeclared (first use in this > function) > >> error: command 'gcc' failed with exit status 1 > > > > I forwarded this to the Cython list, let's see what that gives. > > And it helped! :) > > http://comments.gmane.org/gmane.comp.python.cython.devel/588 > > Here's a fix for Cython. > > Stefan As expected, fix works smoothly! Thank you, Holger -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From stefan_ml at behnel.de Mon Feb 4 09:45:37 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 04 Feb 2008 09:45:37 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X Message-ID: <47A6D0B1.5020600@behnel.de> Hi, it looks like many Mac users have problems with lxml on their platform. This usually involves installing up-to-date dependencies (libxml2/libxslt) in addition to the system libraries. I would like to get these problems resolved. To get a start on this, we must collect some information. We had a few reports, but I need to know in more detail what people did, what they tried, and to what avail. So here is a list of questions for Mac users. Please help us by answering them. Some instructions follow at the end. When building lxml, please move any installed Cython versions out of the way and run the build on the unpacked lxml-2.0.tar.gz release sources. It must say "trying to build without Cython" at the beginning. Please provide the following information: - what package management system (fink/macports) do you use? - are you using the stock Python or one that is installed separately? - what library versions are you using of libxml2, libxslt, zlib, libiconv? - which library versions are preinstalled on your platform? (I do not know how to find that out, can anyone provide instructions here?) - what library versions does lxml.etree find? (see below) Just in case there are people who actually have a working installation, - has anyone successfully built lxml statically against libxml2/libxslt? * does it work reliably? (see "Testing" below) * did you build with the --without-threads option? * does it work with *and* without that option? - has anyone managed to get lxml working reliably (see "Testing" below) with a dynamic build? * did you set DYLD_LIBRARY_PATH? * is DYLD_LIBRARY_PATH required for you or does it work without? * is there anything special you did to make it work? * if there are crashes, is the install unusable or are there things you can still do reliably? If lxml crashes for you, - does it work if you set DYLD_LIBRARY_PATH at runtime? (dynamic builds only) - does it work when building with the --without-threads option? - does it crash when running the normal tests? - if the tests pass fine, does it crash with the "ot-test" script below? Every reply is appreciated. You can reply in private e-mail, if you prefer, although it might be helpful to others to see your answer. Thanks in advance, Stefan Here are some instructions: * Checking library versions Please report the library versions that lxml.etree thinks it is using: http://codespeak.net/lxml/FAQ.html#i-think-i-have-found-a-bug-in-lxml-what-should-i-do * Setting DYLD_LIBRARY_PATH When you run tests or an application with lxml, you can pass the environment variable DYLD_LIBRARY_PATH to your program. It needs to be set to the directory (or directories) where lxml's library dependencies are installed, i.e. libxml2 and libxslt. http://codespeak.net/lxml/build.html#providing-newer-library-versions-on-mac-os-x * Testing When I say "works reliably", I mean, without crashes. The first thing to verify that is to run "make test". If it already crashes here, there is no need to try the script below. Please report anything you can find out about the crash in this case. A debugger run and/or a stack trace might give us some useful hints here. If the normal tests pass, please try another test. Here is an XML document and a script that fires off a bunch of threads to parse the document and run multiple XSLTs over it. The archive is about 1MB. http://codespeak.net/lxml/ot-test.zip It's kind of a worst-case scenario that I use to find problems, so if you have a working installation of lxml 2.0, please run it to see if it crashes for you. Parsing may fail (usually for threads 7-9), that's fine, but it must not crash with your otherwise working setup. It normally starts up 16 threads, which should require a couple of hundred MB of memory. If you find that it runs out of memory, you can try running less threads instead by passing the number to the script at the command line. From chairos at gmail.com Mon Feb 4 09:52:46 2008 From: chairos at gmail.com (Jon Rosebaugh) Date: Mon, 4 Feb 2008 02:52:46 -0600 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X In-Reply-To: <47A6D0B1.5020600@behnel.de> References: <47A6D0B1.5020600@behnel.de> Message-ID: On Feb 4, 2008 2:45 AM, Stefan Behnel wrote: > Hi, > > it looks like many Mac users have problems with lxml on their platform. This > usually involves installing up-to-date dependencies (libxml2/libxslt) in > addition to the system libraries. I would like to get these problems resolved. For whatever it's worth, I could usually get lxml to work by itself, when it was the only thing imported in the python interpreter. The problem came when it was imported in a webapp with a bunch of other modules. I believe threading may also have been involved. I'll try to fill out a full report in the next few days, but I've actually obviated my need for lxml by porting lxml.html.clean to BeautifulSoup. It runs nicely and all the tests pass after adjusting for whitespace differences. From mike at it-loops.com Mon Feb 4 16:38:02 2008 From: mike at it-loops.com (Michael Guntsche) Date: Mon, 4 Feb 2008 16:38:02 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: <47A6BA12.5030706@behnel.de> References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> <7638A5A1-E559-4035-A84A-142AECEAE27E@it-loops.com> <47A6BA12.5030706@behnel.de> Message-ID: On Feb 4, 2008, at 8:09, Stefan Behnel wrote: > Hmm, "test_inplace" doesn't tell me much, as it's just the make > target for > running all tests, not an individual test. > > However, it seems to be common for Mac users to have lxml crash, so > we should > definitely do something about it... > I upgraded Cython to 0.9.6.11 and recompiled lxml. Now make test, no longer segfaults but I get several errors in test_elementtree.py Examples: ERROR: test_feed_parser (lxml.tests.test_elementtree.ElementTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/unittest.py", line 260, in run testMethod() File "/Users/maru/source/cvs+svn/lxml/src/lxml/tests/ test_elementtree.py", line 3011, in test_feed_parser parser = self.etree.XMLParser() AttributeError: 'module' object has no attribute 'XMLParser' ERROR: test_tostring_method_text (lxml.tests.test_elementtree.ElementTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/unittest.py", line 260, in run testMethod() File "/Users/maru/source/cvs+svn/lxml/src/lxml/tests/ test_elementtree.py", line 2420, in test_tostring_method_text tostring(a, method="text")) TypeError: tostring() got an unexpected keyword argument 'method' Other than that everything seems to work normally, at least the features I use (validation and xpath most often). /mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080204/c9cef774/attachment.bin From mike at it-loops.com Mon Feb 4 16:55:28 2008 From: mike at it-loops.com (Michael Guntsche) Date: Mon, 4 Feb 2008 16:55:28 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X In-Reply-To: <47A6D0B1.5020600@behnel.de> References: <47A6D0B1.5020600@behnel.de> Message-ID: <2C6DA784-C579-45F7-919B-159909D6325B@it-loops.com> On Feb 4, 2008, at 9:45, Stefan Behnel wrote: > When building lxml, please move any installed Cython versions out > of the way > and run the build on the unpacked lxml-2.0.tar.gz release sources. > It must say > "trying to build without Cython" at the beginning. > Slight difference here Cython 0.9.6.11 and lxml from current trunk. > Please provide the following information: > > - what package management system (fink/macports) do you use? > > - are you using the stock Python or one that is installed separately? > > - what library versions are you using of libxml2, libxslt, zlib, > libiconv? > > - which library versions are preinstalled on your platform? > (I do not know how to find that out, can anyone provide > instructions here?) > With tiger the preinstalled libraries are lxml2: 2.6.16 lxslt: 1.1.11 To get this information just run /usr/bin/xml2-config --version /usr/bin/xslt-config --version Leopard should have newer libraries but I have no machine right now to check that. > - what library versions does lxml.etree find? (see below) > The OS is Macosx Tiger 10.4.11 Python is version 2.5.1 universal binary from www.python.org package management for (libxml2, libxslt) is macports TESTED VERSION: 2.0.0-51232 Python: (2, 5, 1, 'final', 0) lxml.etree: (2, 0, 0, 51232) libxml used: (2, 6, 31) libxml compiled: (2, 6, 31) libxslt used: (1, 1, 22) libxslt compiled: (1, 1, 22) All libraries are universal built libraries from macports and linked dynamically. I have not tried static, since macports by default ONLY compiles dynamic libraries and everyhing seems to be working fine for me. > > Just in case there are people who actually have a working > installation, > > - has anyone successfully built lxml statically against libxml2/ > libxslt? > As said before dynamically linked only. > * does it work reliably? (see "Testing" below) ot-test runs through without any crashes. Threads 7-9 throw exceptions though, as you said. > * did you build with the --without-threads option? > * does it work with *and* without that option? > Dynamically linked only > - has anyone managed to get lxml working reliably (see "Testing" > below) with > a dynamic build? > > * did you set DYLD_LIBRARY_PATH? > * is DYLD_LIBRARY_PATH required for you or does it work without? > * is there anything special you did to make it work? > DYLD_LIBRARY_PATH is not set at all. All I had to do for lxml to find the correct libraries was to make sure that xml2-config and xslt-config from my macports installation is found BEFORE the stock versions in /usr/bin. This way etree links against the correct libraries. > * if there are crashes, is the install unusable or are there things > you can > still do reliably? No crashes at all. If you need any more information just tell me. Kind regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080204/91952256/attachment.bin From stefan_ml at behnel.de Mon Feb 4 19:43:08 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 04 Feb 2008 19:43:08 +0100 Subject: [lxml-dev] Build problems under MacOS-X In-Reply-To: References: <47A40F11.8070401@behnel.de> <47A43CD8.1020308@behnel.de> <47A456C2.8020108@behnel.de> <7638A5A1-E559-4035-A84A-142AECEAE27E@it-loops.com> <47A6BA12.5030706@behnel.de> Message-ID: <47A75CBC.201@behnel.de> Hi, Michael Guntsche wrote: > I upgraded Cython to 0.9.6.11 and recompiled lxml. Now make test, no > longer segfaults [...] > everything seems to work normally, at least the features > I use (validation and xpath most often). Ah, that's good. You actually need Cython 0.9.6.11b(!) for a reliable install, but to keep these minor versions from biting people, I just updated the build page to make clear you'd better not install Cython for a normal release build, but to use the provided (and tested) C sources instead. http://codespeak.net/lxml/build.html#cython > but I get several errors in test_elementtree.py > > Examples: > > ERROR: test_feed_parser (lxml.tests.test_elementtree.ElementTreeTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/unittest.py", > line 260, in run > testMethod() > File > "/Users/maru/source/cvs+svn/lxml/src/lxml/tests/test_elementtree.py", > line 3011, in test_feed_parser > parser = self.etree.XMLParser() > AttributeError: 'module' object has no attribute 'XMLParser' That's just fine. The compatibility tests require ET 1.3 (currently only in SVN) to run. I'll just have to check why these tests aren't disabled for older (c)ET versions yet. Stefan From stefan_ml at behnel.de Mon Feb 4 19:55:32 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 04 Feb 2008 19:55:32 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X In-Reply-To: <2C6DA784-C579-45F7-919B-159909D6325B@it-loops.com> References: <47A6D0B1.5020600@behnel.de> <2C6DA784-C579-45F7-919B-159909D6325B@it-loops.com> Message-ID: <47A75FA4.6000406@behnel.de> Hi, Michael Guntsche wrote: > On Feb 4, 2008, at 9:45, Stefan Behnel wrote: > >> When building lxml, please move any installed Cython versions out of >> the way >> and run the build on the unpacked lxml-2.0.tar.gz release sources. It >> must say >> "trying to build without Cython" at the beginning. > > Slight difference here Cython 0.9.6.11 and lxml from current trunk. :) ... if even that works, I really don't know what ... > With tiger the preinstalled libraries are > > lxml2: 2.6.16 > lxslt: 1.1.11 > > To get this information just run > > /usr/bin/xml2-config --version > /usr/bin/xslt-config --version Ah, sure, thanks. Those libraries are definitely too old and too buggy. > ot-test runs through without any crashes. Threads 7-9 throw exceptions > though, as you said. Then that really looks like a safe setup. > DYLD_LIBRARY_PATH is not set at all. All I had to do for lxml to find > the correct libraries was to make sure > that xml2-config and xslt-config from my macports installation is found > BEFORE the stock versions in /usr/bin. > This way etree links against the correct libraries. Hmmm, could others comment on this? Does this make a difference? Especially for those, who must currently set the DYLD var? Stefan From mike at it-loops.com Mon Feb 4 20:09:35 2008 From: mike at it-loops.com (Michael Guntsche) Date: Mon, 4 Feb 2008 20:09:35 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X In-Reply-To: <47A75FA4.6000406@behnel.de> References: <47A6D0B1.5020600@behnel.de> <2C6DA784-C579-45F7-919B-159909D6325B@it-loops.com> <47A75FA4.6000406@behnel.de> Message-ID: <038D47D3-0F6B-419F-9F9A-B9E1EB9E31F3@it-loops.com> On Feb 4, 2008, at 19:55, Stefan Behnel wrote: >> DYLD_LIBRARY_PATH is not set at all. All I had to do for lxml to find >> the correct libraries was to make sure >> that xml2-config and xslt-config from my macports installation is >> found >> BEFORE the stock versions in /usr/bin. >> This way etree links against the correct libraries. > > Hmmm, could others comment on this? Does this make a difference? > Especially > for those, who must currently set the DYLD var? > Just had a look at setupinfo.py and CHANGES.txt, only "xslt-config" is used to find the corrent CFLAGS and libs, but since xml2-config and xslt-config should always be in the same directory this should not be much of a problem. So just make sure the new xslt-config is found first and you should be safe. /Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080204/aa112498/attachment.bin From cz at gocept.com Tue Feb 5 14:01:32 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Tue, 5 Feb 2008 14:01:32 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X References: <47A6D0B1.5020600@behnel.de> Message-ID: Hey, On 2008-02-04 09:45:37 +0100, Stefan Behnel said: > Hi, > > it looks like many Mac users have problems with lxml on their platform. This > usually involves installing up-to-date dependencies (libxml2/libxslt) in > addition to the system libraries. I would like to get these problems resolved. > > To get a start on this, we must collect some information. We had a few > reports, but I need to know in more detail what people did, what they tried, > and to what avail. So here is a list of questions for Mac users. Please help > us by answering them. Some instructions follow at the end. > > When building lxml, please move any installed Cython versions out of the way > and run the build on the unpacked lxml-2.0.tar.gz release sources. It must say > "trying to build without Cython" at the beginning. > > Please provide the following information: > > - what package management system (fink/macports) do you use? We use buidout for the development/deployment. Via buildout we build basically everything to be sure we get consistent results: [libxml2] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxml2/2.6/libxml2-2.6.26.tar.gz extra_options = --without-python [libxslt] recipe = zc.recipe.cmmi url = http://ftp.gnome.org/pub/GNOME/sources/libxslt/1.1/libxslt-1.1.16.tar.bz2 extra_options = --with-libxml-prefix=${buildout:directory}/parts/libxml2/ --without-python [lxml] recipe = zc.recipe.egg:custom egg = lxml include-dirs = ${buildout:directory}/parts/libxml2/include/libxml2 ${buildout:directory}/parts/libxslt/include library-dirs = ${buildout:directory}/parts/libxml2/lib ${buildout:directory}/parts/libxslt/lib rpath = ${buildout:directory}/parts/libxml2/lib ${buildout:directory}/parts/libxslt/lib > > - are you using the stock Python or one that is installed separately? Custom built python wich *nothing* else installed. [....] I'll look after the other things when i've got more time. But basically since using buildout we're fine :) -- Christian Zagrodnick gocept gmbh & co. kg ? forsterstrasse 29 ? 06112 halle/saale www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891 From sidnei at enfoldsystems.com Tue Feb 5 18:00:59 2008 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Tue, 5 Feb 2008 15:00:59 -0200 Subject: [lxml-dev] requesting lxml testimonials? In-Reply-To: <47A1D22F.8050702@behnel.de> References: <47A1D22F.8050702@behnel.de> Message-ID: On Jan 31, 2008 11:50 AM, Stefan Behnel wrote: > I started a FAQ entry "Who uses lxml?": > > http://codespeak.net/svn/lxml/trunk/doc/FAQ.txt > > It will go online with the release of lxml 2.0 tomorrow (although maybe I > should wait a little longer, this has been a suspiciously calm week on the > list). Anyway, I hope that people will start bugging me why their own link is > missing. ;) > > But I agree, there should be some quotes on the web site also, and maybe even > the FAQ entry should be placed (or referenced) more prominently... The upcoming Enfold Proxy 4 release will support applying XSLT transformations to proxied pages: http://www.enfoldsystems.com/Products/Proxy/4 -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From stefan_ml at behnel.de Tue Feb 5 21:22:32 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 05 Feb 2008 21:22:32 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X In-Reply-To: References: <47A6D0B1.5020600@behnel.de> Message-ID: <47A8C588.9060701@behnel.de> Hi, Christian Zagrodnick wrote: > We use buildout for the development/deployment. Via buildout we build > basically everything to be sure we get consistent results Martijn also made a buildout script for lxml a while ago: http://faassen.n--tree.net/blog/view/weblog/2006/10/03/0 I guess this is really helpful. Definitely for production environments, but it might also come in handy for Mac users. Can someone enlighten me how finding libxml2/libxslt works here at runtime? Martijn, you suggested adding this to lxml back then. I think we should have this in SVN so that people can use it straight away. Stefan From cz at gocept.com Thu Feb 7 08:52:40 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Thu, 7 Feb 2008 08:52:40 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X In-Reply-To: <47A8C588.9060701@behnel.de> References: <47A6D0B1.5020600@behnel.de> <47A8C588.9060701@behnel.de> Message-ID: On 05.02.2008, at 21:22, Stefan Behnel wrote: > Hi, > > Christian Zagrodnick wrote: >> We use buildout for the development/deployment. Via buildout we build >> basically everything to be sure we get consistent results > > Martijn also made a buildout script for lxml a while ago: > > http://faassen.n--tree.net/blog/view/weblog/2006/10/03/0 > > I guess this is really helpful. Definitely for production > environments, but it > might also come in handy for Mac users. > > Can someone enlighten me how finding libxml2/libxslt works here at > runtime? Well, the generated scripts use the compiled lxml: % grep lxml bin/test '/Users/zagy/.../develop-eggs/lxml-2.0-py2.4-macosx-10.5-i386.egg', And actually I thought the `rpath` option was there to do that: rpath: A new-line separated list of directories to search for dynamic libraries at run time. But that doesn't exactly seem to work as it really seems lxml would use the system libraries at runtime. Gotta ask jim. -- Christian Zagrodnick gocept gmbh & co. kg ? forsterstrasse 29 ? 06112 halle/saale www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891 From cz at gocept.com Thu Feb 7 16:36:02 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Thu, 7 Feb 2008 16:36:02 +0100 Subject: [lxml-dev] Help getting lxml to work reliably on MacOS-X References: <47A6D0B1.5020600@behnel.de> <47A8C588.9060701@behnel.de> Message-ID: On 2008-02-07 08:52:40 +0100, Christian Zagrodnick said: > > On 05.02.2008, at 21:22, Stefan Behnel wrote: > >> Hi, >> >> Christian Zagrodnick wrote: >>> We use buildout for the development/deployment. Via buildout we build >>> basically everything to be sure we get consistent results >> >> Martijn also made a buildout script for lxml a while ago: >> >> http://faassen.n--tree.net/blog/view/weblog/2006/10/03/0 >> >> I guess this is really helpful. Definitely for production > >> environments, but it >> might also come in handy for Mac users. >> >> Can someone enlighten me how finding libxml2/libxslt works here at > >> runtime? > > Well, the generated scripts use the compiled lxml: > > % grep lxml bin/test > '/Users/zagy/.../develop-eggs/lxml-2.0-py2.4-macosx-10.5-i386.egg', > > And actually I thought the `rpath` option was there to do that: > > rpath: A new-line separated list of directories to search for dynamic > > libraries at run time. > > But that doesn't exactly seem to work as it really seems lxml would > > use the system libraries at runtime. Gotta ask jim. Right, so actually buildout does the right thing. The main problem is, that lxml runs the wrong xslt-config. So I was bascially buildint libxml2 and libxslt just for the fun of it. The question is if lxml really always needs to call xslt-config. Or how one would set the path in the buildout so that the right xslt-config is called. If I manually set the path it works like charm: % PATH=`pwd`/parts/libxslt/bin:$PATH bin/buildout -- Christian Zagrodnick gocept gmbh & co. kg ? forsterstrasse 29 ? 06112 halle/saale www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891 From cz at gocept.com Thu Feb 7 17:16:54 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Thu, 7 Feb 2008 17:16:54 +0100 Subject: [lxml-dev] Bug: type annotation namespace-prefix goes missing Message-ID: Hi there, given the following little script: import lxml.etree import lxml.objectify xml = lxml.objectify.XML( '' 'titfoobar') foo = xml['b'][0] bar = xml['b'][1] foo['text'] = 'FOO!' print lxml.etree.tostring(xml, pretty_print=True) foo = xml.xpath('b[@name="b1"]')[0] bar = xml.xpath('b[@name="b2"]')[0] xml['b'] = [bar, foo] print lxml.etree.tostring(xml, pretty_print=True) The first print statement prints, where everything is fine: