From apaku at gmx.de Wed Feb 1 20:55:25 2006 From: apaku at gmx.de (Andreas Pakulat) Date: Wed Feb 1 20:55:30 2006 Subject: [lxml-dev] Request for help on testing new libxml2 feature Message-ID: <20060201195525.GA6040@morpheus.apaku.dnsalias.org> Hi, regarding the remove-redundant-namespaces issue there are news: kbuchcik implemented the xmlDOMWrapReconcileNamespaces in tree.c of libxml2 so it should remove redundant NS decl. However neither do I have any experience with libxml2 nor do I have the time to dig into it so that I can build a test program for this. Thus I ask you guys here, who surely are libxml2 experts, if you could help me out here. Either some "hack" for lxml that allows me to test this or a small programm that takes an xml file and applies this function to it's DOM tree (and outputs the result) would be really great. Thanks, Andreas -- You now have Asian Flu. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20060201/112d83c9/attachment.pgp From K.Buchcik at 4commerce.de Thu Feb 2 13:23:45 2006 From: K.Buchcik at 4commerce.de (Kasimier Buchcik) Date: Thu Feb 2 13:23:51 2006 Subject: [lxml-dev] Request for help on testing new libxml2 feature In-Reply-To: <20060201195525.GA6040@morpheus.apaku.dnsalias.org> References: <20060201195525.GA6040@morpheus.apaku.dnsalias.org> Message-ID: <1138883025.1272.7.camel@librax> Hi, On Wed, 2006-02-01 at 20:55 +0100, Andreas Pakulat wrote: > Hi, > > regarding the remove-redundant-namespaces issue there are news: > > kbuchcik implemented the xmlDOMWrapReconcileNamespaces in tree.c of > libxml2 so it should remove redundant NS decl. However neither do I have > any experience with libxml2 nor do I have the time to dig into it so > that I can build a test program for this. > > Thus I ask you guys here, who surely are libxml2 experts, if you could > help me out here. Either some "hack" for lxml that allows me to test > this or a small programm that takes an xml file and applies this > function to it's DOM tree (and outputs the result) would be really > great. Note that removal of redundant ns-decls in xmlDOMWrapReconcileNamespaces() was committed to CVS just yesterday and I fixed some bugs today; I peformed only rudimental tests, so more testing would be appreciated. Andreas' bug-entry: http://bugzilla.gnome.org/show_bug.cgi?id=329347 Regards, Kasimier From petri.savolainen at iki.fi Thu Feb 2 14:15:58 2006 From: petri.savolainen at iki.fi (Petri Savolainen) Date: Thu Feb 2 14:32:15 2006 Subject: [lxml-dev] Version for windows? In-Reply-To: <956277792.20051214154959@carcass.dhs.org> References: <43A043E1.80502@free.fr> <956277792.20051214154959@carcass.dhs.org> Message-ID: <43E2060E.70200@iki.fi> Hello, I saw some talk about a windows version on this list/group, but did not see one on the website yet...? Any pointers? The one below was not available when I tried... Thanks! Petri Steve Howe wrote: > Hello Werner, > > Wednesday, December 14, 2005, 1:10:09 PM, you wrote: > >> I am running into problems trying to: > >> \python24\python setup.py install > > [...] > >> Any chance that there is a binary build for Windows XP is available? > You can get it from me: > > http://redguy.dhs.org:81/lxml-0.8.win32-py2.4.exe > > This is the 0.8 version. > > Best Regards, > Howe From behnel_ml at gkec.informatik.tu-darmstadt.de Thu Feb 2 16:09:21 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Thu Feb 2 16:09:30 2006 Subject: [lxml-dev] XMLParser + XMLFormatter ? Message-ID: <43E220A1.5090804@gkec.informatik.tu-darmstadt.de> Hi, Andreas requested a new feature that mainly relates to output formatting. The obvious API for it might be a new keyword argument. However, since we seem to be getting more and more keyword arguments in the I/O functions, maybe we should rethink the way we set options on output methods. Fredrik mentioned the possibility to have an XMLParser that only wrapps options like this: class XMLParser: def __init__(self, **options): self.options = options doc = ET.parse(source, parser=XMLParser(configuration)) What about doing the same with output options? Imagine this: class XMLFormatter: def __init__(self, xhtml=False, pretty_print=False, indent=4, ...): self.options = {} ... xml_text = ET.write_str(XMLFormatter(pretty_print=True)) That would give us a nice, symmetric API for input and output options. If you prefer, you could easily use sublasses to provide different default arguments: class XMLPrettyPrinter(XMLFormatter): def __init__(..., pretty_print=True, ...): Comments? Stefan From behnel_ml at gkec.informatik.tu-darmstadt.de Thu Feb 2 16:30:54 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Thu Feb 2 16:31:05 2006 Subject: [lxml-dev] Request for help on testing new libxml2 feature In-Reply-To: <1138883025.1272.7.camel@librax> References: <20060201195525.GA6040@morpheus.apaku.dnsalias.org> <1138883025.1272.7.camel@librax> Message-ID: <43E225AE.6080108@gkec.informatik.tu-darmstadt.de> Kasimier Buchcik wrote: > On Wed, 2006-02-01 at 20:55 +0100, Andreas Pakulat wrote: >> regarding the remove-redundant-namespaces issue there are news: >> >> kbuchcik implemented the xmlDOMWrapReconcileNamespaces in tree.c of >> libxml2 so it should remove redundant NS decl. However neither do I have >> any experience with libxml2 nor do I have the time to dig into it so >> that I can build a test program for this. >> >> Thus I ask you guys here, who surely are libxml2 experts, if you could >> help me out here. Either some "hack" for lxml that allows me to test >> this or a small programm that takes an xml file and applies this >> function to it's DOM tree (and outputs the result) would be really >> great. > > Note that removal of redundant ns-decls in > xmlDOMWrapReconcileNamespaces() was committed to CVS just > yesterday and I fixed some bugs today; I peformed only rudimental > tests, so more testing would be appreciated. > > Andreas' bug-entry: > http://bugzilla.gnome.org/show_bug.cgi?id=329347 Ok, I think we cannot easily depend on CVS versions of libxml2 in lxml, so this rather experimental feature will not be supported in lxml for a while. As a work around this kind of problems with libxml2 versions, we *could* support something like conditional *compilation* in lxml, depending on the libxml2 version. It's not beautiful, but I could imagine something like this, related to the new I/O API and Geert's/Patrick's patches: class XMLFormatter: def __init__(..., xhtml=False, ...): if xhtml: if LIBXML_VERSION < 20623: raise VersionError, \ "Libxml version >= 2.6.23 needed for XHTML formatting" else: ... This would allow us to keep a consistent API, while supporting different versions of libxml2 and their diverging features. This obviously only works for libxml2 versions that provide all API functions used by the lxml code, since they must be available at compile time. I actually haven't tested this, but it may even work. Anyway, for now, this is only an idea. So far, we do not even have code that needs this. But is may make the change to Geert's output features simpler and may also allow us to support experimental features of libxml2. Stefan From bashautomation at gmail.com Sat Feb 4 17:09:07 2006 From: bashautomation at gmail.com (Scott Haeger) Date: Sat Feb 4 17:09:18 2006 Subject: [lxml-dev] memory leak in el.get() ? Message-ID: <3d8ae71c0602040809x5dc13647r13e4909e60a42e97@mail.gmail.com> I am getting a memory leak using the get attribute method. The following will illustrate the problem: el = etree.Element("element") el.set('a', 'first') while True: x = el.get('a') Memory usage as displayed in top continues will continue to grow. I am using the following: lxml 0.8 libxml2 2.6.23 Fedora Core 3 Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/lxml-dev/attachments/20060204/f5b3e139/attachment.htm From behnel_ml at gkec.informatik.tu-darmstadt.de Sun Feb 5 10:26:48 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Sun Feb 5 10:26:57 2006 Subject: [lxml-dev] memory leak in el.get() ? In-Reply-To: <3d8ae71c0602040809x5dc13647r13e4909e60a42e97@mail.gmail.com> References: <3d8ae71c0602040809x5dc13647r13e4909e60a42e97@mail.gmail.com> Message-ID: <43E5C4D8.3070506@gkec.informatik.tu-darmstadt.de> Scott Haeger wrote: > I am getting a memory leak using the get attribute method. The > following will illustrate the problem: > > el = etree.Element("element") > el.set('a', 'first') > > while True: > x = el.get('a') > > Memory usage as displayed in top continues will continue to grow. > > I am using the following: > lxml 0.8 > libxml2 2.6.23 > Fedora Core 3 > > Scott Hi Scott, thanks for reporting this. I think you're right, there is a problem with freeing the string buffer of attribute values after converting them to Python strings. I'll see if I can fix that and commit a patch to SVN. Thanks, Stefan From behnel_ml at gkec.informatik.tu-darmstadt.de Sun Feb 5 11:27:02 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Sun Feb 5 11:27:12 2006 Subject: [lxml-dev] memory leak in el.get() ? In-Reply-To: <3d8ae71c0602040809x5dc13647r13e4909e60a42e97@mail.gmail.com> References: <3d8ae71c0602040809x5dc13647r13e4909e60a42e97@mail.gmail.com> Message-ID: <43E5D2F6.9010906@gkec.informatik.tu-darmstadt.de> Scott Haeger wrote: > I am getting a memory leak using the get attribute method. The > following will illustrate the problem: > > el = etree.Element("element") > el.set('a', 'first') > > while True: > x = el.get('a') > > Memory usage as displayed in top continues will continue to grow. > > I am using the following: > lxml 0.8 > libxml2 2.6.23 > Fedora Core 3 > > Scott Fixed. You can either use the current SVN version (trunk or scoder2 branch) or apply the attached patch by hand. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: leak.patch Type: text/x-patch Size: 1216 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20060205/af02557d/leak-0001.bin From werner.bruhin at free.fr Tue Feb 7 15:45:13 2006 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Tue Feb 7 16:36:43 2006 Subject: [lxml-dev] OT - Schema conversion Message-ID: <43E8B279.7080106@free.fr> I am trying to convert XSD schema to Relax NG to get the best of both worlds - maybe. Looked at Trang but it does not convert from XSD to Relax, just the other way round but I found the Sun Relax NG converter which should be able to do it. But I can't get it to work and my Java knowledge is probably less then none. Has anyone used this conversion tool successfully? I am getting the following exception: Sun Relax NG Converter version 20030225 C:\Dev\TheWineCellarBook\xml\sunconverter>java -jar rngconv.jar wineXML.xsd > wineXML.rng Exception in thread "main" java.lang.ClassCastException at com.sun.msv.datatype.xsd.TypeIncubator.derive(TypeIncubator.java:216) at com.sun.msv.reader.datatype.xsd.XSDatatypeExp$1.derive(XSDatatypeExp.java:92) at com.sun.msv.reader.datatype.xsd.RestrictionState.annealType(RestrictionState.java:41) at com.sun.msv.reader.datatype.xsd.TypeWithOneChildState.makeType(TypeWithOneChildState.java :42) at com.sun.msv.reader.datatype.xsd.TypeState._makeType(TypeState.java:76) at com.sun.msv.reader.datatype.xsd.TypeState.endSelf(TypeState.java:52) at com.sun.msv.reader.SimpleState.endElement(SimpleState.java:100) at org.xml.sax.helpers.XMLFilterImpl.endElement(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch( Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.msv.reader.util.GrammarLoader._loadSchema(GrammarLoader.java:511) at com.sun.msv.reader.util.GrammarLoader.parse(GrammarLoader.java:331) at com.sun.msv.reader.util.GrammarLoader.loadSchema(GrammarLoader.java:178) at com.sun.msv.writer.relaxng.Driver.main(Unknown Source) I am on Windows XP Pro and I am not familar with Java (version installed is j2re1.4.2_01) Tried to find info on the Sun site and posted on their list but no answer till now. Maybe someone can point me in the right direction to get this working. See you Werner From desai at mcs.anl.gov Fri Feb 10 16:52:26 2006 From: desai at mcs.anl.gov (Narayan Desai) Date: Sun Feb 12 01:50:47 2006 Subject: [lxml-dev] fix for another memory leak Message-ID: In addition to the memory leak in the Element.get method, I have recently been seeing memory leaks in Element.Attrib.has_key. This results in the following trace from valgrind: ==12133== 8 bytes in 4 blocks are definitely lost in loss record 2 of 48 ==12133== at 0x401B422: malloc (vg_replace_malloc.c:149) ==12133== by 0x453D8B5: xmlStrndup (in /usr/lib/libxml2.so.2.6.23) ==12133== by 0x453D943: xmlStrdup (in /usr/lib/libxml2.so.2.6.23) ==12133== by 0x453E0D1: xmlStrcat (in /usr/lib/libxml2.so.2.6.23) ==12133== by 0x44E98A1: xmlNodeListGetString (in /usr/lib/libxml2.so.2.6.23) ==12133== by 0x44EF6D2: xmlGetNoNsProp (in /usr/lib/libxml2.so.2.6.23) ==12133== by 0x4462ED0: __pyx_f_5etree_7_Attrib_has_key (etree.c:5389) ==12133== by 0x80B6BE3: (within /usr/bin/python2.3) ==12133== by 0x80B8356: PyEval_EvalCodeEx (in /usr/bin/python2.3) ==12133== by 0x80B85D4: PyEval_EvalCode (in /usr/bin/python2.3) ==12133== by 0x80D8EFF: PyRun_InteractiveOneFlags (in /usr/bin/python2.3) ==12133== by 0x80D9018: PyRun_InteractiveLoopFlags (in /usr/bin/python2.3) The following patch appears to fix things for me. It is basically copied from the Element.get fix. -nld Index: src/lxml/etree.pyx =================================================================== --- src/lxml/etree.pyx (revision 23162) +++ src/lxml/etree.pyx (working copy) @@ -855,6 +855,7 @@ result = tree.xmlGetNoNsProp(self._c_node, tag) else: result = tree.xmlGetNsProp(self._c_node, tag, ns) + tree.xmlFree(result) return result is not NULL def __contains__(self, key): From apaku at gmx.de Tue Feb 14 11:20:49 2006 From: apaku at gmx.de (Andreas Pakulat) Date: Tue Feb 14 11:20:50 2006 Subject: [lxml-dev] Use lxml under windows Message-ID: <20060214102049.GA5341@morpheus> Hi, I'd like to use lxml under windows, but I can't compile the C extension: C:\lxml-scoder2>python setup.py build -c mingw32 running build running build_py running build_ext building 'lxml.etree' extension creating build\temp.win32-2.4 creating build\temp.win32-2.4\Release creating build\temp.win32-2.4\Release\src creating build\temp.win32-2.4\Release\src\lxml c:\Programme\CodeBlocks\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\libxml\inclu de -IC:\Python24\include -IC:\Python24\PC -c src/lxml/etree.c -o build\temp.win3 2-2.4\Release\src\lxml\etree.o -w writing build\temp.win32-2.4\Release\src\lxml\etree.def c:\Programme\CodeBlocks\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.4\ Release\src\lxml\etree.o build\temp.win32-2.4\Release\src\lxml\etree.def -LC:\li bxml\lib -LC:\Python24\libs -LC:\Python24\PCBuild -llibexslt -lzdll -llibxml2 -l libxslt -liconv -lzlib -lpython24 -lmsvcr71 -o build\lib.win32-2.4\lxml\etree.py d build\temp.win32-2.4\Release\src\lxml\etree.o:etree.c:(.text+0x38b3): undefined reference to `_imp__xmlFree' build\temp.win32-2.4\Release\src\lxml\etree.o:etree.c:(.text+0x193b0): undefined reference to `_imp__xmlFree' build\temp.win32-2.4\Release\src\lxml\etree.o:etree.c:(.text+0x202d6): undefined reference to `_imp__xmlFree' build\temp.win32-2.4\Release\src\lxml\etree.o:etree.c:(.text+0x2044a): undefined reference to `_imp__xmlFree' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 I already altered the setup.py to include include_dir=['c:\libxml\include'] library_dirs=['c:\libxml\lib'] libaries=['libxml','libxslt','iconv','zlib'] libxml2 is from the prebuilt-windows-binaries. Now the question is: Are those prebuilt-binaries incorrectly built and thus don't include the necessary symbols or is lxml at fault here? Would maybe building libxml2 myself solve this? Andreas -- Today is what happened to yesterday. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://codespeak.net/pipermail/lxml-dev/attachments/20060214/92e72069/attachment.pgp From behnel_ml at gkec.informatik.tu-darmstadt.de Tue Feb 14 13:16:38 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Tue Feb 14 13:16:22 2006 Subject: [lxml-dev] fix for another memory leak In-Reply-To: References: Message-ID: <43F1CA26.1030003@gkec.informatik.tu-darmstadt.de> Narayan Desai wrote: > In addition to the memory leak in the Element.get method, I have > recently been seeing memory leaks in Element.Attrib.has_key. This > results in the following trace from valgrind: > ==12133== 8 bytes in 4 blocks are definitely lost in loss record 2 of 48 > ==12133== at 0x401B422: malloc (vg_replace_malloc.c:149) > ==12133== by 0x453D8B5: xmlStrndup (in /usr/lib/libxml2.so.2.6.23) > ==12133== by 0x453D943: xmlStrdup (in /usr/lib/libxml2.so.2.6.23) > ==12133== by 0x453E0D1: xmlStrcat (in /usr/lib/libxml2.so.2.6.23) > ==12133== by 0x44E98A1: xmlNodeListGetString (in /usr/lib/libxml2.so.2.6.23) > ==12133== by 0x44EF6D2: xmlGetNoNsProp (in /usr/lib/libxml2.so.2.6.23) > ==12133== by 0x4462ED0: __pyx_f_5etree_7_Attrib_has_key (etree.c:5389) > ==12133== by 0x80B6BE3: (within /usr/bin/python2.3) > ==12133== by 0x80B8356: PyEval_EvalCodeEx (in /usr/bin/python2.3) > ==12133== by 0x80B85D4: PyEval_EvalCode (in /usr/bin/python2.3) > ==12133== by 0x80D8EFF: PyRun_InteractiveOneFlags (in /usr/bin/python2.3) > ==12133== by 0x80D9018: PyRun_InteractiveLoopFlags (in /usr/bin/python2.3) > > The following patch appears to fix things for me. It is basically > copied from the Element.get fix. Hi, sorry for the late reply. Thank you for supplying the patch. I applied a slightly different patch to the SVN trunk, also for the __contains__ method, to keep them from using pointers after calling free. Could you please check if the bug is gone? It would be really nice if you could also test the __contains__ method with Valgrind. Thanks again, Stefan Index: src/lxml/etree.pyx =================================================================== --- src/lxml/etree.pyx (Revision 23034) +++ src/lxml/etree.pyx (Arbeitskopie) @@ -855,7 +855,11 @@ result = tree.xmlGetNoNsProp(self._c_node, tag) else: result = tree.xmlGetNsProp(self._c_node, tag, ns) - return result is not NULL + if result is not NULL: + tree.xmlFree(result) + return True + else: + return False def __contains__(self, key): cdef xmlNs* c_ns @@ -865,7 +869,11 @@ result = tree.xmlGetNoNsProp(self._c_node, tag) else: result = tree.xmlGetNsProp(self._c_node, tag, ns) - return result is not NULL + if result is not NULL: + tree.xmlFree(result) + return True + else: + return False cdef _Attrib _attribFactory(_Document doc, xmlNode* c_node): cdef _Attrib result From desai at mcs.anl.gov Tue Feb 14 16:37:42 2006 From: desai at mcs.anl.gov (Narayan Desai) Date: Tue Feb 14 16:55:09 2006 Subject: [lxml-dev] Re: fix for another memory leak References: <43F1CA26.1030003@gkec.informatik.tu-darmstadt.de> Message-ID: Your patch fixes those two problems. I found one more in __getitem__. With the following patch, my code runs clean. (insofar as python can valgrind clean.) -nld Index: src/lxml/etree.pyx =================================================================== --- src/lxml/etree.pyx (revision 23162) +++ src/lxml/etree.pyx (working copy) @@ -775,16 +775,18 @@ def __getitem__(self, key): cdef xmlNs* c_ns - cdef char* result + cdef char* cresult ns, tag = _getNsTag(key) if ns is None: - result = tree.xmlGetNoNsProp(self._c_node, tag) + cresult = tree.xmlGetNoNsProp(self._c_node, tag) else: - result = tree.xmlGetNsProp(self._c_node, tag, ns) - if result is NULL: + cresult = tree.xmlGetNsProp(self._c_node, tag, ns) + if cresult is NULL: # XXX free namespace that is not in use..? raise KeyError, key - return funicode(result) + result = funicode(cresult) + tree.xmlFree(cresult) + return result def __len__(self): cdef int c @@ -855,7 +857,11 @@ result = tree.xmlGetNoNsProp(self._c_node, tag) else: result = tree.xmlGetNsProp(self._c_node, tag, ns) - return result is not NULL + if result is not NULL: + tree.xmlFree(result) + return True + else: + return False def __contains__(self, key): cdef xmlNs* c_ns @@ -865,7 +871,11 @@ result = tree.xmlGetNoNsProp(self._c_node, tag) else: result = tree.xmlGetNsProp(self._c_node, tag, ns) - return result is not NULL + if result is not NULL: + tree.xmlFree(result) + return True + else: + return False cdef _Attrib _attribFactory(_Document doc, xmlNode* c_node): cdef _Attrib result From behnel_ml at gkec.informatik.tu-darmstadt.de Tue Feb 14 18:25:38 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Tue Feb 14 18:24:12 2006 Subject: [lxml-dev] Re: fix for another memory leak In-Reply-To: References: <43F1CA26.1030003@gkec.informatik.tu-darmstadt.de> Message-ID: <43F21292.3090906@gkec.informatik.tu-darmstadt.de> Narayan Desai wrote: > Your patch fixes those two problems. I found one more in __getitem__. > With the following patch, my code runs clean. (insofar as python ran > valgrind clean.) > -nld The patch you sent was a combination of the patches I previously applied to SVN (I think). So, it is now in both the trunk and the scoder2 branch. Thanks for testing. Stefan From behnel_ml at gkec.informatik.tu-darmstadt.de Thu Feb 16 13:03:21 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Thu Feb 16 13:03:01 2006 Subject: [lxml-dev] fix for another memory leak In-Reply-To: <87oe18jm2s.fsf@topaz.mcs.anl.gov> References: <43F1CA26.1030003@gkec.informatik.tu-darmstadt.de> <87oe18jm2s.fsf@topaz.mcs.anl.gov> Message-ID: <43F46A09.40801@gkec.informatik.tu-darmstadt.de> Narayan Desai schrieb: > I updated to the current svn, and it looks like this chunk didn't get > committed. Is this intentional? Oh, thanks for checking! :) It was by accident. It looked so much like the patch I had committed before the last one that I just thought you had copied it. I'll check it in as soon as I get to it. Thank you for taking care, Stefan > Index: src/lxml/etree.pyx > =================================================================== > --- src/lxml/etree.pyx (revision 23382) > +++ src/lxml/etree.pyx (working copy) > @@ -775,16 +775,18 @@ > > def __getitem__(self, key): > cdef xmlNs* c_ns > - cdef char* result > + cdef char* cresult > ns, tag = _getNsTag(key) > if ns is None: > - result = tree.xmlGetNoNsProp(self._c_node, tag) > + cresult = tree.xmlGetNoNsProp(self._c_node, tag) > else: > - result = tree.xmlGetNsProp(self._c_node, tag, ns) > - if result is NULL: > + cresult = tree.xmlGetNsProp(self._c_node, tag, ns) > + if cresult is NULL: > # XXX free namespace that is not in use..? > raise KeyError, key > - return funicode(result) > + result = funicode(cresult) > + tree.xmlFree(cresult) > + return result > > def __len__(self): > cdef int c From crankycoder at gmail.com Thu Feb 16 18:51:26 2006 From: crankycoder at gmail.com (Victor Ng) Date: Thu Feb 16 18:51:43 2006 Subject: [lxml-dev] is valgrind still used? Message-ID: Hi all, It's been a long time since I've been on this list, but I'm hoping to start hacking again. Whoo! New job. More open source hacking time. On to the questions! Is valgrind still being used anymore? I just ran : > valgrind --tool=memcheck --suppressions=valgrind-python.supp python test.py and got: ==13242== ==13242== ERROR SUMMARY: 138 errors from 16 contexts (suppressed: 10026 from 6) ==13242== malloc/free: in use at exit: 2848232 bytes in 2981 blocks. ==13242== malloc/free: 53700 allocs, 50719 frees, 21000875 bytes allocated. ==13242== For counts of detected errors, rerun with: -v ==13242== searching for pointers to 2981 not-freed blocks. ==13242== checked 3490012 bytes. ==13242== ==13242== LEAK SUMMARY: ==13242== definitely lost: 4759 bytes in 168 blocks. ==13242== possibly lost: 0 bytes in 0 blocks. ==13242== still reachable: 2843473 bytes in 2813 blocks. ==13242== suppressed: 0 bytes in 0 blocks. ==13242== Use --leak-check=full to see details of leaked memory. victorng@mbdev1:~/dev/lxml$ Is this expected? Is there a Trac instance or some other bug tracker that I can look at to see what the open bugs are? Thanks! Hope to be less than useless soon. :) vic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/lxml-dev/attachments/20060216/df262345/attachment-0001.htm From behnel_ml at gkec.informatik.tu-darmstadt.de Fri Feb 17 12:21:45 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Fri Feb 17 12:21:17 2006 Subject: [lxml-dev] is valgrind still used? In-Reply-To: References: Message-ID: <43F5B1C9.3070800@gkec.informatik.tu-darmstadt.de> Victor Ng wrote: > Is valgrind still being used anymore? I just ran : > >> valgrind --tool=memcheck --suppressions=valgrind-python.supp python > test.py > > and got: > > ==13242== > ==13242== ERROR SUMMARY: 138 errors from 16 contexts (suppressed: 10026 > from 6) > ==13242== malloc/free: in use at exit: 2848232 bytes in 2981 blocks. > ==13242== malloc/free: 53700 allocs, 50719 frees, 21000875 bytes allocated. > ==13242== For counts of detected errors, rerun with: -v > ==13242== searching for pointers to 2981 not-freed blocks. > ==13242== checked 3490012 bytes. > ==13242== > ==13242== LEAK SUMMARY: > ==13242== definitely lost: 4759 bytes in 168 blocks. > ==13242== possibly lost: 0 bytes in 0 blocks. > ==13242== still reachable: 2843473 bytes in 2813 blocks. > ==13242== suppressed: 0 bytes in 0 blocks. > ==13242== Use --leak-check=full to see details of leaked memory. > victorng@mbdev1:~/dev/lxml$ Thanks for testing. However, there have been a number of fixes for memory leaks applied to the latest SVN (I applied the last one today), which dramatically reduce the number of lost blocks. It's not zero, though, but it looks like the remaining problems are more related to Python itself. You didn't say which version you are running (0.8, I assume), but since there were many, many changes to SVN since the last version, you should really use the current SVN version when testing. I currently get this result for the trunk version: ==24747== LEAK SUMMARY: ==24747== definitely lost: 7,760 bytes in 121 blocks. ==24747== possibly lost: 16,320 bytes in 60 blocks. ==24747== still reachable: 4,521,357 bytes in 3,331 blocks. ==24747== suppressed: 0 bytes in 0 blocks. > Is this expected? Is there a Trac instance or some other bug tracker > that I can look at to see what the open bugs are? No, there is no trac support currently. Bugs are commonly reported to the mailing list, just as you did. Anyway, thanks for testing. Narayan Desai has just reported (and fixed) a few leaks this week, so, if you find anything else that should be done, I'd be glad to hear about it. Stefan From bashautomation at gmail.com Tue Feb 21 18:53:16 2006 From: bashautomation at gmail.com (Scott Haeger) Date: Tue Feb 21 18:53:52 2006 Subject: [lxml-dev] xml:space and xml:lang problem Message-ID: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> It is my understanding that xml has two special attributes under the xml namespace, namely xml:space and xml:lang. My problem is that I am getting garbage for the xml namespace such as xmlns:="(XXX)://www.w3.org/XML/1998/namespace", where (XXX) is complete garbage. The problem occurs both when the namespace is declared and when it is not declared. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/lxml-dev/attachments/20060221/30f518c4/attachment.html From behnel_ml at gkec.informatik.tu-darmstadt.de Tue Feb 21 19:39:10 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Tue Feb 21 19:37:59 2006 Subject: [lxml-dev] xml:space and xml:lang problem In-Reply-To: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> References: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> Message-ID: <43FB5E4E.709@gkec.informatik.tu-darmstadt.de> Scott Haeger wrote: > It is my understanding that xml has two special attributes under the xml > namespace, namely xml:space and xml:lang. My problem is that I am > getting garbage for the xml namespace such as > xmlns:="(XXX)://www.w3.org/XML/1998/namespace", where (XXX) is complete > garbage. The problem occurs both when the namespace is declared and > when it is not declared. Could you please give some more detail? What does "getting garbage" mean? That lxml is not serializing an internal XML representation correctly? Does it read such XML in correctly? Could you come up with a short code fragment that demonstrates the problem? Stefan From behnel_ml at gkec.informatik.tu-darmstadt.de Wed Feb 22 08:39:42 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Wed Feb 22 08:39:16 2006 Subject: [lxml-dev] xml:space and xml:lang problem In-Reply-To: <3d8ae71c0602211251y5c68d61dw696c13ac18b4ba3a@mail.gmail.com> References: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> <43FB5E4E.709@gkec.informatik.tu-darmstadt.de> <3d8ae71c0602211251y5c68d61dw696c13ac18b4ba3a@mail.gmail.com> Message-ID: <43FC153E.9060606@gkec.informatik.tu-darmstadt.de> Scott Haeger wrote: > It seems that lxml is not serializing properly. The following code will > demonstrate: > > from lxml import etree > import sys > > # parse xml from file > intree = etree.parse("test.xml") > > # create root for new tree > outroot = etree.Element("root") > > # go through original and append to new tree > doc = intree.getiterator() > for el in doc: > newel = el > outroot.append(newel) > > # create new tree and output to screen > outtree = etree.ElementTree(outroot) > outtree.write(sys.stdout) > > > Test.xml is the following: > > > xmlns:xml=" http://www.w3.org/1998/XML"> > > > > Although the demo does not show the random characters (garbage) as seen > in my full application, it does demostrate a failure to serialize > properly. Copying elements between trees will most likely not change the result. I cut that down to the following: ---------- .>>> from lxml import etree .>>> intree = etree.XML(""" ... ... ... ... """) .>>> etree.tostring(intree) '\n\n' ---------- So this definitely misses the XML namespace declaration. BUT, according to the spec, that is not a problem. """ The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. """ Source: http://www.w3.org/TR/REC-xml-names/ Is that what you meant when you said it demonstrates a failure? > The problem occurs with and without the namespace declaration. Because, according to the spec, both are the same. > Also, removing the xml:space attribute corrects the problem. Probably, since it only references explicitly declared namespaces in that case. Still, could you try to come up with an example that shows your unreadable characters on serialization? Thanks, Stefan From K.Buchcik at 4commerce.de Wed Feb 22 16:45:24 2006 From: K.Buchcik at 4commerce.de (Kasimier Buchcik) Date: Wed Feb 22 16:45:42 2006 Subject: [lxml-dev] xml:space and xml:lang problem In-Reply-To: <43FC153E.9060606@gkec.informatik.tu-darmstadt.de> References: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> <43FB5E4E.709@gkec.informatik.tu-darmstadt.de> <3d8ae71c0602211251y5c68d61dw696c13ac18b4ba3a@mail.gmail.com> <43FC153E.9060606@gkec.informatik.tu-darmstadt.de> Message-ID: <1140623124.1272.47.camel@librax> Hi, On Wed, 2006-02-22 at 08:39 +0100, Stefan Behnel wrote: > Scott Haeger wrote: [...] > > Test.xml is the following: > > > > > > > xmlns:xml=" http://www.w3.org/1998/XML"> > > > > [...] I don't know if this is just a typo in the example, but the namespace-URI begins with a space-character: $ xmllint --debug xmlns.xml xmlns.xml:2: namespace error : xml namespace prefix mapped to wrong URI ^ DOCUMENT version=1.0 URL=xmlns.xml standalone=true namespace xml href=http://www.w3.org/XML/1998/namespace ELEMENT svg TEXT interned content= ELEMENT a ATTRIBUTE id TEXT content=first ATTRIBUTE space TEXT content=default TEXT interned content= [...] > """ > The prefix xml is by definition bound to the namespace name > http://www.w3.org/XML/1998/namespace. > """ > > Source: http://www.w3.org/TR/REC-xml-names/ [...] Just an info: Libxml2 strips all explicit declarations of the XML namespace, since it stores the XML ns-declaration in a special field on the doc itself, namely in xmlDoc->oldNs. The XML namespace declaration is "built-in" by every XML processor, so you don't have to declare it. Regards, Kasimier From bashautomation at gmail.com Wed Feb 22 17:39:38 2006 From: bashautomation at gmail.com (Scott Haeger) Date: Wed Feb 22 17:39:56 2006 Subject: [lxml-dev] xml:space and xml:lang problem In-Reply-To: <1140623124.1272.47.camel@librax> References: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> <43FB5E4E.709@gkec.informatik.tu-darmstadt.de> <3d8ae71c0602211251y5c68d61dw696c13ac18b4ba3a@mail.gmail.com> <43FC153E.9060606@gkec.informatik.tu-darmstadt.de> <1140623124.1272.47.camel@librax> Message-ID: <3d8ae71c0602220839s5c61ac5cldb3f7f62f31548e8@mail.gmail.com> Kasimier My fault on the xml namespace. It should be xmlns:xml=" http://www.w3.org/XML/1998/namespace". That solves the xmllint problem. The problem I am seeing occurs with or without the additional space before the URI. I have two test scripts to illustrate my problem. The two scripts and the test xml file follow. Another test file would be an Inkscape document with a text element. Problem does not occur in this script: from lxml import etree import sys intree = etree.parse("test.xml") intree.write(sys.stdout) Problem occurs: Note the xml namespace in the output. from lxml import etree import sys intree = etree.parse("test.xml") outroot = etree.Element("root") doc = intree.getiterator() for el in doc: newel = el outroot.append(newel) outtree = etree.ElementTree(outroot) outtree.write(sys.stdout) Test file: Interesting notes: The space before the URI does not affect result. Switching for xml:space to svg:space fixes the problem Problem occurs with or without xml namespace declaration __copy__ and/or append are suspect? Parsing not handling the xml namespace properly? I wish I knew more about the library. Scott On 2/22/06, Kasimier Buchcik wrote: > > Hi, > > On Wed, 2006-02-22 at 08:39 +0100, Stefan Behnel wrote: > > Scott Haeger wrote: > > [...] > > > > Test.xml is the following: > > > > > > > > > > > xmlns:xml=" http://www.w3.org/1998/XML"> > > > > > > > > [...] > > I don't know if this is just a typo in the example, but the > namespace-URI begins with a space-character: > > > $ xmllint --debug xmlns.xml > xmlns.xml:2: namespace error : xml namespace prefix mapped to wrong URI > > ^ > DOCUMENT > version=1.0 > URL=xmlns.xml > standalone=true > namespace xml href=http://www.w3.org/XML/1998/namespace > ELEMENT svg > TEXT interned > content= > ELEMENT a > ATTRIBUTE id > TEXT > content=first > ATTRIBUTE space > TEXT > content=default > TEXT interned > content= > > [...] > > > """ > > The prefix xml is by definition bound to the namespace name > > http://www.w3.org/XML/1998/namespace. > > """ > > > > Source: http://www.w3.org/TR/REC-xml-names/ > > > [...] > > Just an info: Libxml2 strips all explicit declarations of the XML > namespace, since it stores the XML ns-declaration in a special field on > the doc itself, namely in xmlDoc->oldNs. The XML namespace declaration > is "built-in" by every XML processor, so you don't have to declare it. > > Regards, > > Kasimier > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/lxml-dev/attachments/20060222/473a87f7/attachment.htm From behnel_ml at gkec.informatik.tu-darmstadt.de Wed Feb 22 17:59:15 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Wed Feb 22 17:59:33 2006 Subject: [lxml-dev] xml:space and xml:lang problem In-Reply-To: <3d8ae71c0602220839s5c61ac5cldb3f7f62f31548e8@mail.gmail.com> References: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> <43FB5E4E.709@gkec.informatik.tu-darmstadt.de> <3d8ae71c0602211251y5c68d61dw696c13ac18b4ba3a@mail.gmail.com> <43FC153E.9060606@gkec.informatik.tu-darmstadt.de> <1140623124.1272.47.camel@librax> <3d8ae71c0602220839s5c61ac5cldb3f7f62f31548e8@mail.gmail.com> Message-ID: <43FC9863.1080905@gkec.informatik.tu-darmstadt.de> Scott Haeger wrote: > Problem occurs: Note the xml namespace in the output. > > from lxml import etree > import sys > intree = etree.parse("test.xml") > outroot = etree.Element("root") > doc = intree.getiterator() > for el in doc: > newel = el > outroot.append (newel) > outtree = etree.ElementTree(outroot) > outtree.write(sys.stdout) > > Test file: > > > xmlns:svg="http://www.w3.org/2000/svg " > xmlns:xml=" http://www.w3.org/XML/1998/namespace"> > > My system: Python - 2.4.2 lxml - from scoder2 branch and current SVN libxml2 - 2.6.23 My output for the above script: I do not see a problem here. Maybe you are using an outdated version of libxml2? Stefan From bashautomation at gmail.com Wed Feb 22 19:32:00 2006 From: bashautomation at gmail.com (Scott Haeger) Date: Wed Feb 22 19:32:17 2006 Subject: [lxml-dev] xml:space and xml:lang problem In-Reply-To: <43FC9863.1080905@gkec.informatik.tu-darmstadt.de> References: <3d8ae71c0602210953r3df25dct96105534616033dc@mail.gmail.com> <43FB5E4E.709@gkec.informatik.tu-darmstadt.de> <3d8ae71c0602211251y5c68d61dw696c13ac18b4ba3a@mail.gmail.com> <43FC153E.9060606@gkec.informatik.tu-darmstadt.de> <1140623124.1272.47.camel@librax> <3d8ae71c0602220839s5c61ac5cldb3f7f62f31548e8@mail.gmail.com> <43FC9863.1080905@gkec.informatik.tu-darmstadt.de> Message-ID: <3d8ae71c0602221032w521a5187od1e7eca7dabb92f6@mail.gmail.com> I upgraded to the latest SVN version. I believe it has fixed the problem. Strange, my version of lxml was only about a week old. Thanks for the help. Scott On 2/22/06, Stefan Behnel wrote: > > > Scott Haeger wrote: > > Problem occurs: Note the xml namespace in the output. > > > > from lxml import etree > > import sys > > intree = etree.parse("test.xml") > > outroot = etree.Element("root") > > doc = intree.getiterator() > > for el in doc: > > newel = el > > outroot.append (newel) > > outtree = etree.ElementTree(outroot) > > outtree.write(sys.stdout) > > > > Test file: > > > > > > > xmlns:svg="http://www.w3.org/2000/svg " > > xmlns:xml=" http://www.w3.org/XML/1998/namespace"> > > > > > > My system: > Python - 2.4.2 > lxml - from scoder2 branch and current SVN > libxml2 - 2.6.23 > > My output for the above script: > > > > > I do not see a problem here. Maybe you are using an outdated version of > libxml2? > > Stefan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/lxml-dev/attachments/20060222/40ad4dd8/attachment.htm From behnel_ml at gkec.informatik.tu-darmstadt.de Sat Feb 25 09:22:18 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Sat Feb 25 17:47:53 2006 Subject: [lxml-dev] Use of XPathEvaluator object in extension functions? Message-ID: <440013BA.5040106@gkec.informatik.tu-darmstadt.de> Hi, I just looked through the documentation a bit and started rewriting xpath.txt for the new Namespace API. I never actually thought much about it, but the docs made me stumble over the fact that extension functions take the XPathEvaluator object as first parameter. I don't really know what that is good for. Has anyone used this feature so far? What purpose does it serve? When I rewrote the implementation, I introduced a 'ContextBuilder', which is now passed instead. I'm wondering if that can fulfil the original intention... Can anyone enlighten me? Stefan From allan at curtisnz.com Mon Feb 27 08:32:46 2006 From: allan at curtisnz.com (Allan Curtis) Date: Mon Feb 27 08:29:36 2006 Subject: [lxml-dev] lxml build problem Message-ID: <200602272032.46750.allan@curtisnz.com> Hi, I am trying to build lxml from the latest svn build on a Suse10.0 based computer with GCC4.02 and I seem to be getting gcc related errors when compiling etree. python setup.py build_ext -i running build_ext building 'lxml.etree' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fmessage-length=0 -Wall -D_FORTI FY_SOURCE=2 -g -fPIC -I/usr/include/python2.4 -c src/lxml/etree.c -o build/temp. linux-x86_64-2.4/src/lxml/etree.o -w -I/usr/include/libxml2 src/lxml/etree.c: In function ?__pyx_f_5etree_12_ElementTree_parse?: src/lxml/etree.c:921: error: invalid lvalue in assignment src/lxml/etree.c:932: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree__newElementTree?: src/lxml/etree.c:1858: error: invalid lvalue in assignment src/lxml/etree.c:1884: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree__elementFactory?: src/lxml/etree.c:4135: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree__commentFactory?: src/lxml/etree.c:4522: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree__attribFactory?: src/lxml/etree.c:5591: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree__xsltResultTreeFactory?: src/lxml/etree.c:8377: error: invalid lvalue in assignment src/lxml/etree.c: In function '__pyx_f_5etree_22XPathDocumentEvaluator___init__? : src/lxml/etree.c:8473: error: invalid lvalue in assignment src/lxml/etree.c:8478: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree_21XPathElementEvaluator___init__?: src/lxml/etree.c:9256: error: invalid lvalue in assignment src/lxml/etree.c: In function ?__pyx_f_5etree_changeDocumentBelowHelper?: src/lxml/etree.c:13105: error: invalid lvalue in assignment error: command 'gcc' failed with exit status 1 make: *** [inplace] Error 1 Is anyone able to assist with resolving this? Cheers, -- Allan From ogrisel at nuxeo.com Mon Feb 27 10:14:03 2006 From: ogrisel at nuxeo.com (Olivier Grisel) Date: Mon Feb 27 10:15:15 2006 Subject: [lxml-dev] Re: lxml build problem In-Reply-To: <200602272032.46750.allan@curtisnz.com> References: <200602272032.46750.allan@curtisnz.com> Message-ID: Allan Curtis a ?crit : > I am trying to build lxml from the latest svn build on a Suse10.0 based > computer with GCC4.02 and I seem to be getting gcc related errors when > compiling etree. > > python setup.py build_ext -i [snip] > src/lxml/etree.c:13105: error: invalid lvalue in assignment > error: command 'gcc' failed with exit status 1 > make: *** [inplace] Error 1 This is a konwn problem: your version of Pyrex does not support gcc4 as explained on the installation page of lxml: http://codespeak.net/lxml/installation.html Pyrex 0.9.3.1 does not fix the problem entirely. You can download a patch above or you can directly 'svn co' a prepatched version of pyrex here for instance: http://svn.nuxeo.org/pub/vendor/Pyrex/tags/0.9.3-gcc4-patched/ Best, -- Olivier From allan at curtisnz.com Mon Feb 27 10:44:43 2006 From: allan at curtisnz.com (Allan Curtis) Date: Mon Feb 27 10:41:18 2006 Subject: [lxml-dev] Re: lxml build problem In-Reply-To: References: <200602272032.46750.allan@curtisnz.com> Message-ID: <200602272244.43795.allan@curtisnz.com> On Monday 27 February 2006 22:14, Olivier Grisel wrote: Olivier, Thanks for your very quick response. > This is a konwn problem: your version of Pyrex does not support gcc4 as > explained on the installation page of lxml: > > http://codespeak.net/lxml/installation.html > > Pyrex 0.9.3.1 does not fix the problem entirely. > > You can download a patch above or you can directly 'svn co' a prepatched > version of pyrex here for instance: > > http://svn.nuxeo.org/pub/vendor/Pyrex/tags/0.9.3-gcc4-patched/ I thought that v0.9.3.1 of Pyrex was patched. Anyway, I have progress but get further errors: running build_ext building 'lxml.etree' extension Traceback (most recent call last): File "setup.py", line 29, in ? cmdclass = {'build_ext': build_pyx} File "/usr/lib64/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib64/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib64/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib64/python2.4/distutils/command/install.py", line 511, in run self.run_command('build') File "/usr/lib64/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib64/python2.4/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/usr/lib64/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib64/python2.4/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "/usr/lib64/python2.4/distutils/command/build_ext.py", line 405, in build _extensions self.build_extension(ext) File "/usr/lib64/python2.4/distutils/command/build_ext.py", line 442, in build _extension sources = self.swig_sources(sources, ext) TypeError: swig_sources() takes exactly 2 arguments (3 given) I am new to Python, but this error appears to be a Python rather than assembler issue. Any guidance would be much appreciated. Kind Regards -- Allan Curtis From ogrisel at nuxeo.com Mon Feb 27 10:56:01 2006 From: ogrisel at nuxeo.com (Olivier Grisel) Date: Mon Feb 27 10:59:11 2006 Subject: [lxml-dev] Re: lxml build problem In-Reply-To: <200602272244.43795.allan@curtisnz.com> References: <200602272032.46750.allan@curtisnz.com> <200602272244.43795.allan@curtisnz.com> Message-ID: Allan Curtis a ?crit : > > I thought that v0.9.3.1 of Pyrex was patched. Anyway, I have progress but get > further errors: > [snip] > File "/usr/lib64/python2.4/distutils/command/build_ext.py", line 442, in > build _extension > sources = self.swig_sources(sources, ext) > TypeError: swig_sources() takes exactly 2 arguments (3 given) > > I am new to Python, but this error appears to be a Python rather than > assembler issue. Any guidance would be much appreciated. After googling a bit it looks like the 0.9.3 + gcc4 patch does not work with python 2.4 (except on my machine, why?). This has been fixed in 0.9.3.1. Thus you need use the 0.9.3.1 version and apply the missing part of the patch manually. Or you can fix offending line by hand: site-packages/Pyrex/Distutils/build_ext.py 35c35 < def swig_sources (self, sources): --- > def swig_sources (self, sources, extension=None): http://lists.copyleft.no/pipermail/pyrex/2005-July/001256.html -- Olivier From allan at curtisnz.com Mon Feb 27 20:21:10 2006 From: allan at curtisnz.com (Allan Curtis) Date: Mon Feb 27 20:17:44 2006 Subject: [lxml-dev] Re: lxml build problem In-Reply-To: References: <200602272032.46750.allan@curtisnz.com> <200602272244.43795.allan@curtisnz.com> Message-ID: <200602280821.10488.allan@curtisnz.com> On Monday 27 February 2006 22:56, Olivier Grisel wrote: Olivier, > After googling a bit it looks like the 0.9.3 + gcc4 patch does not work > with python 2.4 (except on my machine, why?). This has been fixed in > 0.9.3.1. Thus you need use the 0.9.3.1 version and apply the missing part > of the patch manually. Or you can fix offending line by hand: > > site-packages/Pyrex/Distutils/build_ext.py > > 35c35 > < def swig_sources (self, sources): > --- > > > def swig_sources (self, sources, extension=None): > > http://lists.copyleft.no/pipermail/pyrex/2005-July/001256.html Oh, dear. Patched that line and now get back the same gcc compile errors as before. If you have the 0.9.3 patch working, what distro are you using and is it for a 64 bit CPU? Maybe I should talk to the Pyrex developer, Greg Ewing (he is at my old university and is in the same time zone). Kind Regards, -- Allan Curtis From behnel_ml at gkec.informatik.tu-darmstadt.de Mon Feb 27 20:36:16 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Mon Feb 27 20:36:16 2006 Subject: [lxml-dev] Re: lxml build problem In-Reply-To: <200602280821.10488.allan@curtisnz.com> References: <200602272032.46750.allan@curtisnz.com> <200602272244.43795.allan@curtisnz.com> <200602280821.10488.allan@curtisnz.com> Message-ID: <440354B0.4040505@gkec.informatik.tu-darmstadt.de> Allan Curtis wrote: > If you have the 0.9.3 patch working, what distro are you using and > is it for a 64 bit CPU? I have patched versions of the SRPM/RPM for SuSE 10. I'll send them to you (but not to the list). You can also find the patches in the SVN version of lxml. There will soon be a new release that will contain the generated etree.c so that people will no longer need to install Pyrex to compile lxml. Stefan From behnel_ml at gkec.informatik.tu-darmstadt.de Tue Feb 28 13:15:12 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Tue Feb 28 13:14:32 2006 Subject: [lxml-dev] Call for Contribution: lxml 0.9 Message-ID: <44043ED0.4020505@gkec.informatik.tu-darmstadt.de> Hello, everyone! Martijn and I realised that there has not been a release of lxml for quite a while - despite a lot of important changes to the code base. We therefore agreed to prepare the release of lxml 0.9 for *Monday, March 20*. The remaining time will be used to get the trunk ready for a release. It will include the current feature set of the trunk plus the support for extension functions that is currently implemented in the scoder2 branch. The latter still needs a bit of discussion and merging. Any comments on this are appreciated. For you, this announcement means the following. - If you want any features included, make sure you send requests and patches to the list within the next days or try to fix a date when a patch will be available. Remember that we may have to discuss patches before applying them. - If you feel that you especially like or dislike anything about the new features and the way they are made available through APIs, feel free to tell us over the list. - If you feel that anything from past discussions has been left out that should be worth remembering for a new release, speak up now. - We know that there are still a few places where documentation would help users to understand new features. A good way to contribute would therefore be to look through the documentation in the "doc" directory and see if it is understandable or if there is anything you might want to add. - In the same line, usage examples in the form of doctests would be nice to have for more API functions. They also belong into the files in the "doc" directory, which are (or must be) called from the related test cases in src/lxml/tests. Happy coding, Stefan