[lxml-dev] merge annotate() and xsiannotate() into single function
Hi Holger, in the current trunk, objectify has those two big functions "annotate()" and "xsiannotate()" that do very similar things in similar ways. When I was changing the annotation behaviour for empty elements, I noticed that it would be hard to keep the two in sync, so I decided to merge them. Here is a patch that matches the current test cases on the trunk (note that I did not yet merge your tests for 1.3 back). Holger, could you look through it to check if this is what you would expect? I know that it does not guarantee exactly the same behaviour as before, so there will likely be cases where some annotations come out different than now. Actually, xsiannotate() was not yet in a release, but I even think that objectify shouldn't guarantee any particular annotations anyway. I rather prefer something like: "it always yields types that make sense for the current data". Another point here: the current XSI type order prefers "integer" over "long" and "float" over "double". Shouldn't those be swapped to always annotate with the widest possible type? Stefan
Hi,
Holger, could you look through it to check if this is what you would expect? I know that it does not guarantee exactly the same behaviour as before, so there will likely be cases where some annotations come out different than now.
I'll look into it. As a side note, current trunk dumps core with a segfault for me in "make test". I attach the output/trace at the end of this post.
Another point here: the current XSI type order prefers "integer" over "long" and "float" over "double". Shouldn't those be swapped to always annotate with the widest possible type?
You're right, double and float should be swapped; but not integer: In XML Schema datatypes terms, xsd:long is derived from xsd:integer and restricts its value space, so I think xsd:integer is what comes closest to python long. Holger Trunk segfault: 0 lb54320@adevp02 .../lxml $ make test PYTHON=python2.4 python2.4 setup.py build_ext -i Building lxml version 2.0.dev-44407 running build_ext python2.4 test.py -p -v TESTED VERSION: Python: (2, 4, 4, 'final', 0) lxml.etree: (2, 0, -3, 44407) libxml used: (2, 6, 27) libxml compiled: (2, 6, 27) libxslt used: (1, 1, 20) libxslt compiled: (1, 1, 20) 488/583 ( 83.7%): test_xmlschema_invalid_schema2 (....test_xmlschema.ETreeXMLSchemaTestCase)make: *** [test_inplace] Segmentation Fault (core dumped) 2 lb54320@adevp02 .../lxml $ Reading symbols from /data/pydev/hjoukl/LXML/lxml/src/lxml/pyclasslookup.so...done. Reading symbols from /apps/prod/lib/python2.4/lib-dynload/_locale.so...done. Reading symbols from /usr/lib/libintl.so.1... warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 0x74 done. Reading symbols from /apps/prod/lib/python2.4/lib-dynload/readline.so...done. Reading symbols from /apps/prod/lib/libreadline.so...done. #0 0xff0b3218 in strlen () from /usr/lib/libc.so.1 (gdb) where #0 0xff0b3218 in strlen () from /usr/lib/libc.so.1 #1 0xff106530 in _doprnt () from /usr/lib/libc.so.1 #2 0xff108730 in vsnprintf () from /usr/lib/libc.so.1 #3 0xfe237874 in __xmlRaiseError () from /apps/prod/lib/libxml2.so.2 #4 0xfe33bdd8 in xmlSchemaErr4Line () from /apps/prod/lib/libxml2.so.2 #5 0xfe33beec in xmlSchemaErr4 () from /apps/prod/lib/libxml2.so.2 #6 0xfe33c7b8 in xmlSchemaCustomErr4 () from /apps/prod/lib/libxml2.so.2 #7 0xfe33c83c in xmlSchemaCustomErr () from /apps/prod/lib/libxml2.so.2 #8 0xfe353608 in xmlSchemaAddSchemaDoc () from /apps/prod/lib/libxml2.so.2 #9 0xfe36a77c in xmlSchemaParse () from /apps/prod/lib/libxml2.so.2 #10 0xfe57fed8 in __pyx_f_5etree_9XMLSchema___init__ (__pyx_v_self=0x6f3110, __pyx_args=0x714900, __pyx_kwds=0x551260) at src/lxml/etree.c:38303 #11 0x584cc in type_call (type=0xfe5ce75c, args=0x6f3a90, kwds=0x6f9c90) at Objects/typeobject.c:435 #12 0x2608c in PyObject_Call (func=0x6f3110, arg=0x6f3a90, kw=0x6f9c90) at Objects/abstract.c:1795 #13 0x88f14 in ext_do_call (func=0xfe5ce75c, pp_stack=0xffbed71c, flags=3, na=-1, nk=0) at Python/ceval.c:3845 #14 0x85ac0 in PyEval_EvalFrame (f=0x73e728) at Python/ceval.c:2207 #15 0x86e80 in PyEval_EvalCodeEx (co=0x1be4a0, globals=0x0, locals=0x73e728, args=0x73f6bc, argcount=4, kws=0x73f6cc, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #16 0x88850 in fast_function (func=0x1c8c30, pp_stack=0xffbed970, n=4, na=4, nk=0) at Python/ceval.c:3661 #17 0x88678 in call_function (pp_stack=0xffbed970, oparg=4) at Python/ceval.c:3589 #18 0x859c8 in PyEval_EvalFrame (f=0x73f568) at Python/ceval.c:2167 #19 0x887c4 in fast_function (func=0x5ca030, pp_stack=0x714690, n=1, na=1, nk=1240904) at Python/ceval.c:3651 #20 0x88678 in call_function (pp_stack=0xffbedb38, oparg=1) at Python/ceval.c:3589 #21 0x859c8 in PyEval_EvalFrame (f=0x714530) at Python/ceval.c:2167 #22 0x86e80 in PyEval_EvalCodeEx (co=0x1be2a0, globals=0x0, locals=0x714530, args=0x6a5104, argcount=2, kws=0x4647e0, kwcount=0, defs=0x1c067c, defcount=1, closure=0x0) at Python/ceval.c:2741 #23 0xdad9c in function_call (func=0x1c8a70, arg=0x6a50f8, kw=0x6f9030) at Objects/funcobject.c:548 #24 0x2608c in PyObject_Call (func=0x1c8a70, arg=0x6a50f8, kw=0x6f9030) at Objects/abstract.c:1795 #25 0x88f14 in ext_do_call (func=0x1c8a70, pp_stack=0xffbeddd4, flags=3, na=-1, nk=0) at Python/ceval.c:3845 #26 0x85ac0 in PyEval_EvalFrame (f=0x673360) at Python/ceval.c:2207 #27 0x86e80 in PyEval_EvalCodeEx (co=0x1be2e0, globals=0x0, locals=0x673360, args=0x6a50b4, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #28 0xdad9c in function_call (func=0x1c8ab0, arg=0x6a50a8, kw=0x0) at Objects/funcobject.c:548 #29 0x2608c in PyObject_Call (func=0x1c8ab0, arg=0x6a50a8, kw=0x0) at Objects/abstract.c:1795 #30 0x2e2d4 in instancemethod_call (func=0x1c8ab0, arg=0x6a50a8, kw=0x0) at Objects/classobject.c:2532 #31 0x2608c in PyObject_Call (func=0x1c8ab0, arg=0x6a50a8, kw=0x0) at Objects/abstract.c:1795 #32 0x63880 in slot_tp_call (self=0x5beff0, args=0x5f2cf0, kwds=0x0) at Objects/typeobject.c:4546 ---Type <return> to continue, or q <return> to quit--- #33 0x2608c in PyObject_Call (func=0x5beff0, arg=0x5f2cf0, kw=0x0) at Objects/abstract.c:1795 #34 0x8a8a8 in do_call (func=0x5beff0, pp_stack=0xffbee4d8, na=-1, nk=6237424) at Python/ceval.c:3776 #35 0x88690 in call_function (pp_stack=0xffbee4d8, oparg=1) at Python/ceval.c:3591 #36 0x859c8 in PyEval_EvalFrame (f=0x607670) at Python/ceval.c:2167 #37 0x86e80 in PyEval_EvalCodeEx (co=0x1be7e0, globals=0x0, locals=0x607670, args=0x5d74ec, argcount=2, kws=0x4647f0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #38 0xdad9c in function_call (func=0x1c8ef0, arg=0x5d74e0, kw=0x5d9d20) at Objects/funcobject.c:548 #39 0x2608c in PyObject_Call (func=0x1c8ef0, arg=0x5d74e0, kw=0x5d9d20) at Objects/abstract.c:1795 #40 0x88f14 in ext_do_call (func=0x1c8ef0, pp_stack=0xffbee774, flags=3, na=-1, nk=0) at Python/ceval.c:3845 #41 0x85ac0 in PyEval_EvalFrame (f=0x299828) at Python/ceval.c:2207 #42 0x86e80 in PyEval_EvalCodeEx (co=0x1be820, globals=0x0, locals=0x299828, args=0x5c8dac, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #43 0xdad9c in function_call (func=0x1c8f30, arg=0x5c8da0, kw=0x0) at Objects/funcobject.c:548 #44 0x2608c in PyObject_Call (func=0x1c8f30, arg=0x5c8da0, kw=0x0) at Objects/abstract.c:1795 #45 0x2e2d4 in instancemethod_call (func=0x1c8f30, arg=0x5c8da0, kw=0x0) at Objects/classobject.c:2532 #46 0x2608c in PyObject_Call (func=0x1c8f30, arg=0x5c8da0, kw=0x0) at Objects/abstract.c:1795 #47 0x63880 in slot_tp_call (self=0x5becd0, args=0x5bef50, kwds=0x0) at Objects/typeobject.c:4546 #48 0x2608c in PyObject_Call (func=0x5becd0, arg=0x5bef50, kw=0x0) at Objects/abstract.c:1795 #49 0x8a8a8 in do_call (func=0x5becd0, pp_stack=0xffbeee78, na=-1, nk=6025040) at Python/ceval.c:3776 #50 0x88690 in call_function (pp_stack=0xffbeee78, oparg=1) at Python/ceval.c:3591 #51 0x859c8 in PyEval_EvalFrame (f=0x1e2820) at Python/ceval.c:2167 #52 0x887c4 in fast_function (func=0x1d3c30, pp_stack=0x294a70, n=2, na=1, nk=1240904) at Python/ceval.c:3651 #53 0x88678 in call_function (pp_stack=0xffbef040, oparg=2) at Python/ceval.c:3589 #54 0x859c8 in PyEval_EvalFrame (f=0x2948b8) at Python/ceval.c:2167 #55 0x887c4 in fast_function (func=0x1cba70, pp_stack=0x1e531c, n=1, na=1, nk=1240904) at Python/ceval.c:3651 #56 0x88678 in call_function (pp_stack=0xffbef208, oparg=1) at Python/ceval.c:3589 #57 0x859c8 in PyEval_EvalFrame (f=0x1e51c8) at Python/ceval.c:2167 #58 0x86e80 in PyEval_EvalCodeEx (co=0x2566e0, globals=0x0, locals=0x1e51c8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #59 0x8a7a0 in PyEval_EvalCode (co=0x2566e0, globals=0x148a50, locals=0x148a50) at Python/ceval.c:484 #60 0xb01cc in run_node (n=0x138218, filename=0x2566e0 "", globals=0x148a50, locals=0x148a50, flags=0xffbef5d0) at Python/pythonrun.c:1285 #61 0xb0178 in run_err_node (n=0x138218, filename=0x2566e0 "", globals=0x148a50, locals=0x148a50, flags=0xffbef5d0) at Python/pythonrun.c:1272 #62 0xafdd8 in PyRun_FileExFlags (fp=0x12a938, filename=0xffbef8ae "test.py", start=1346128, globals=0x148a50, locals=0x148a50, closeit=1, flags=0xffbef5d0) at Python/pythonrun.c:1263 #63 0xae5e0 in PyRun_SimpleFileExFlags (fp=0x12a938, filename=0xffbef8ae "test.py", closeit=1, flags=0xffbef5d0) at Python/pythonrun.c:869 ---Type <return> to continue, or q <return> to quit--- #64 0xaf8cc in PyRun_AnyFileExFlags (fp=0x12a938, filename=0xffbef8ae "test.py", closeit=1, flags=0xffbef5d0) at Python/pythonrun.c:673 #65 0x1e9ec in Py_Main (argc=4, argv=0xffbef754) at Modules/main.c:493 #66 0x1dfe4 in main (argc=4, argv=0xffbef754) at ./Modules/python.c:23 (gdb) -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Hi,
Holger, could you look through it to check if this is what you would expect? I know that it does not guarantee exactly the same behaviour as before, so there will likely be cases where some annotations come out different than now.
I'll look into it.
I haven't had time to test thoroughly but that eems pretty much to do everything I'd expect. I like the empty_pytype switch. Two things: -I think the order of the 2 first checks if the old xsi:type or py:pytype hints should be reused should be changed to first look at old py:pytype; this is more like annotate() worked until now -I'd like to keep TREE attribute info for *leaf* tree elements if ignore_old is False, so that a full annotate->serialize->re-parse cycle has a chance of keeping these elements ObjectifiedElements. And I think you could also let _annotate have a public interface, to let the bold-at-heart xsi-and-pytype-annotate in one step. I'd volunteer to add/adapt all tests for annotate/xsiannotate and maybe introduce the afore mentioned small changes, but that won't be until next week. And why should xsiannotate() not go into 1.3, btw? It doesn't look like it needs to change behaviour for 2.0, any more :) Holger -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Hi Holger, jholg@gmx.de wrote:
Holger, could you look through it to check if this is what you would expect? I know that it does not guarantee exactly the same behaviour as before, so there will likely be cases where some annotations come out different than now. I'll look into it.
I haven't had time to test thoroughly but that eems pretty much to do everything I'd expect. I like the empty_pytype switch.
Two things: -I think the order of the 2 first checks if the old xsi:type or py:pytype hints should be reused should be changed to first look at old py:pytype; this is more like annotate() worked until now
I considered that, but the thing is that xsi:type is a more accurate description of the type, so I think it should be preferred. Note that there is still a type check involved, so if the old one doesn't work, the possibly broader pytype is considered next.
-I'd like to keep TREE attribute info for *leaf* tree elements if ignore_old is False, so that a full annotate->serialize->re-parse cycle has a chance of keeping these elements ObjectifiedElements.
Then how would you get rid of those if you wanted to?
And I think you could also let _annotate have a public interface, to let the bold-at-heart xsi-and-pytype-annotate in one step.
That's why I noted that xsiannotate was never part of an official release. Maybe we should just remove it and extend annotate() instead.
I'd volunteer to add/adapt all tests for annotate/xsiannotate and maybe introduce the afore mentioned small changes, but that won't be until next week.
That's ok, I'll have to look into the crashes anyway before 1.3 goes for world domination.
And why should xsiannotate() not go into 1.3, btw? It doesn't look like it needs to change behaviour for 2.0, any more :)
As I said, I'd prefer having a single function here, just as with deannotate(). Stefan
Hi,
Two things: -I think the order of the 2 first checks if the old xsi:type or py:pytype hints should be reused should be changed to first look at old py:pytype; this is more like annotate() worked until now
I considered that, but the thing is that xsi:type is a more accurate description of the type, so I think it should be preferred. Note that there is still a type check involved, so if the old one doesn't work, the possibly broader pytype is considered next.
I see.
-I'd like to keep TREE attribute info for *leaf* tree elements if ignore_old is False, so that a full annotate->serialize->re-parse cycle has a chance of keeping these elements ObjectifiedElements.
Then how would you get rid of those if you wanted to?
By using ignore_old=True. I admit this is kind of an abuse of ignore_old, so it would be cleaner to add yet another switch to handle this.
And I think you could also let _annotate have a public interface, to let the bold-at-heart xsi-and-pytype-annotate in one step.
That's why I noted that xsiannotate was never part of an official release. Maybe we should just remove it and extend annotate() instead.
Looking at the _annotate interface I'd say it is quite complex to grasp what will happen for different parameter combinations, as they can have certain side effects on each other. I think it's a good thing to have the simpler annotate() and xsiannotate() entry points. 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
jholg@gmx.de wrote:
-I'd like to keep TREE attribute info for *leaf* tree elements if ignore_old is False, so that a full annotate->serialize->re-parse cycle has a chance of keeping these elements ObjectifiedElements. Then how would you get rid of those if you wanted to?
By using ignore_old=True. I admit this is kind of an abuse of ignore_old, so it would be cleaner to add yet another switch to handle this.
Really sounds like an abuse to me.
Looking at the _annotate interface I'd say it is quite complex to grasp what will happen for different parameter combinations, as they can have certain side effects on each other. I think it's a good thing to have the simpler annotate() and xsiannotate() entry points.
That would make it pyannotate(), xsiannotate() and annotate() then ? Although, we already have annotate() for pyannotate(), but the above three names would be The Right Ones... Stefan
Hi,
jholg@gmx.de wrote:
-I'd like to keep TREE attribute info for *leaf* tree elements if ignore_old is False, so that a full annotate->serialize->re-parse cycle has a chance of keeping these elements ObjectifiedElements. Then how would you get rid of those if you wanted to?
By using ignore_old=True. I admit this is kind of an abuse of ignore_old, so it would be cleaner to add yet another switch to handle this.
Really sounds like an abuse to me.
Sorry, I meant ignore_old=False, of course.
Looking at the _annotate interface I'd say it is quite complex to grasp what will happen for different parameter combinations, as they can have certain side effects on each other. I think it's a good thing to have the simpler annotate() and xsiannotate() entry points.
That would make it pyannotate(), xsiannotate() and annotate() then ?
Although, we already have annotate() for pyannotate(), but the above three names would be The Right Ones...
+1 for these names; it should even be possible keep the new annotate() compatible for default parameters by rearranging the parameter list. Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
jholg@gmx.de wrote:
As a side note, current trunk dumps core with a segfault for me in "make test". I attach the output/trace at the end of this post.
Trunk segfault:
0 lb54320@adevp02 .../lxml $ make test PYTHON=python2.4 python2.4 setup.py build_ext -i Building lxml version 2.0.dev-44407 running build_ext python2.4 test.py -p -v
TESTED VERSION: Python: (2, 4, 4, 'final', 0) lxml.etree: (2, 0, -3, 44407) libxml used: (2, 6, 27) libxml compiled: (2, 6, 27) libxslt used: (1, 1, 20) libxslt compiled: (1, 1, 20)
488/583 ( 83.7%): test_xmlschema_invalid_schema2 (....test_xmlschema.ETreeXMLSchemaTestCase)make: *** [test_inplace] Segmentation Fault (core dumped) 2 lb54320@adevp02 .../lxml $
Hmm, there was a bug in libxml2 versions before 2.6.24 that made this test crash, but lxml now works around it. So I have no idea where this might come from. It works for me with exactly the same versions (and even any version I tested). This is on Solaris, right? Any chance you might be running into a similar problem as we saw on Mac-OS, where multiple installed libraries were interfering? It's impossible for me to investigate this. You can switch off that test for your work by prepending the method name with an underscore, for example. We can look into this later on. 1.3 is more important now. Stefan
-------- Original-Nachricht -------- Datum: Fri, 22 Jun 2007 20:03:41 +0200 Von: Stefan Behnel <stefan_ml@behnel.de> An: jholg@gmx.de CC: lxml-dev@codespeak.net Betreff: Re: merge annotate() and xsiannotate() into single function
jholg@gmx.de wrote:
As a side note, current trunk dumps core with a segfault for me in "make test". I attach the output/trace at the end of this post.
Trunk segfault:
0 lb54320@adevp02 .../lxml $ make test PYTHON=python2.4 python2.4 setup.py build_ext -i Building lxml version 2.0.dev-44407 running build_ext python2.4 test.py -p -v
TESTED VERSION: Python: (2, 4, 4, 'final', 0) lxml.etree: (2, 0, -3, 44407) libxml used: (2, 6, 27) libxml compiled: (2, 6, 27) libxslt used: (1, 1, 20) libxslt compiled: (1, 1, 20)
488/583 ( 83.7%): test_xmlschema_invalid_schema2 (....test_xmlschema.ETreeXMLSchemaTestCase)make: *** [test_inplace] Segmentation Fault (core dumped) 2 lb54320@adevp02 .../lxml $
Hmm, there was a bug in libxml2 versions before 2.6.24 that made this test crash, but lxml now works around it. So I have no idea where this might come from. It works for me with exactly the same versions (and even any version I tested). This is on Solaris, right? Any chance you might be running into a similar problem as we saw on Mac-OS, where multiple installed libraries were interfering?
It's impossible for me to investigate this. You can switch off that test for your work by prepending the method name with an underscore, for example. We can look into this later on. 1.3 is more important now.
Stefan
-- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Hi,
488/583 ( 83.7%): test_xmlschema_invalid_schema2
(....test_xmlschema.ETreeXMLSchemaTestCase)make: *** [test_inplace] Segmentation Fault (core dumped)
2 lb54320@adevp02 .../lxml $
Hmm, there was a bug in libxml2 versions before 2.6.24 that made this test crash, but lxml now works around it. So I have no idea where this might come from. It works for me with exactly the same versions (and even any version I tested). This is on Solaris, right? Any chance you might be running into a similar problem as we saw on Mac-OS, where multiple installed libraries were interfering?
It's on Solaris, yes. And no, the reason is not multiple installed libraries. Hm, for this test case lxml 1.3 runs exactly into the workaround, which has been disabled for libxml2 >= 2.6.24 in the trunk. I verified that libxml2 (2.6.27) has _not_ been fixed with regard to this, at least on Solaris: 0 lb54320@adevp02 .../rumprobieren $ cat xml2schemaparse_broken3.c #include <stdio.h> #include "libxml/parser.h" #include "libxml/xmlschemas.h" int main(void) { xmlParserCtxt* pctxt; xmlDocPtr doc; xmlSchemaParserCtxtPtr spctxt; xmlSchemaPtr schema; pctxt = xmlNewParserCtxt(); if (pctxt == NULL) { printf("could not acquire parser context\n"); return 1; } doc = xmlCtxtReadMemory(pctxt, "<test/>", 7, NULL, NULL, 0); if (doc == NULL) { printf("could not parse memory string\n"); return 2; } spctxt = xmlSchemaNewDocParserCtxt(doc); schema = xmlSchemaParse(spctxt); if (schema == NULL) { printf("invalid schema\n"); return 3; } } 0 lb54320@adevp02 .../rumprobieren $ gcc -I /apps/prod/include/libxml2/ -R /apps/prod/lib -L /apps/prod/lib -lxml2 -g xml2schemaparse_broken3.c 0 lb54320@adevp02 .../rumprobieren $ ./a.out Segmentation Fault (core dumped) Gonna file a bug report for libxml2. Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
Hi Holger, thanks for looking into this. jholg@gmx.de wrote:
488/583 ( 83.7%): test_xmlschema_invalid_schema2 (....test_xmlschema.ETreeXMLSchemaTestCase)make: *** [test_inplace] Segmentation Fault (core dumped) 2 lb54320@adevp02 .../lxml $ Hmm, there was a bug in libxml2 versions before 2.6.24 that made this test crash, but lxml now works around it. So I have no idea where this might come from. It works for me with exactly the same versions (and even any version I tested). This is on Solaris, right? Any chance you might be running into a similar problem as we saw on Mac-OS, where multiple installed libraries were interfering?
It's on Solaris, yes. And no, the reason is not multiple installed libraries.
Hm, for this test case lxml 1.3 runs exactly into the workaround, which has been disabled for libxml2 >= 2.6.24 in the trunk.
I verified that libxml2 (2.6.27) has _not_ been fixed with regard to this, at least on Solaris [...] Gonna file a bug report for libxml2.
Thanks. My original bug report is here: http://bugzilla.gnome.org/show_bug.cgi?id=338303 As I said, it seems to be fixed on my machine (Linux/Intel), but you're the only one I know who uses libxml2 on Solaris. Stefan
jholg@gmx.de wrote:
Hm, for this test case lxml 1.3 runs exactly into the workaround, which has been disabled for libxml2 >= 2.6.24 in the trunk.
I reenabled the work-around on the trunk, BTW. Let's see what response we get from the libxml2 people. Stefan
jholg@gmx.de wrote:
Hm, for this test case lxml 1.3 runs exactly into the workaround, which has been disabled for libxml2 >= 2.6.24 in the trunk.
I reenabled the work-around on the trunk, BTW. Let's see what response we get
from the libxml2 people.
Stefan
This is now libxml2 bug http://bugzilla.gnome.org/show_bug.cgi?id=450936 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
Hi,
jholg@gmx.de wrote:
Hm, for this test case lxml 1.3 runs exactly into the workaround, which has been disabled for libxml2 >= 2.6.24 in the trunk.
I reenabled the work-around on the trunk, BTW. Let's see what response we get
from the libxml2 people.
Stefan
This is now libxml2 bug http://bugzilla.gnome.org/show_bug.cgi?id=450936
Those libxml2 guys are fast: This has been fixed for libxml2 trunk. The reason was that solaris printf("%s", NULL) crashes with a segfault. 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
jholg@gmx.de wrote:
jholg@gmx.de wrote:
Hm, for this test case lxml 1.3 runs exactly into the workaround, which has been disabled for libxml2 >= 2.6.24 in the trunk.
I reenabled the work-around on the trunk, BTW. Let's see what response we get
from the libxml2 people.
Stefan This is now libxml2 bug http://bugzilla.gnome.org/show_bug.cgi?id=450936
Those libxml2 guys are fast: This has been fixed for libxml2 trunk. The reason was that solaris printf("%s", NULL) crashes with a segfault.
Ok, so we'll leave the fix in for libxml2 up to 2.6.29 :) Stefan
participants (2)
-
jholg＠gmx.de -
Stefan Behnel