Re: [Koha-devel] State of the debian packaging
I forgot the CC -------- Original Message -------- Subject: Re: [Koha-devel] [Koha] Wrong SAX Parser - does it matter? -> impact on Debian packaging Date: Sun, 07 Dec 2008 09:31:03 +0100 From: Vincent Danjean <vdanjean.ml@free.fr> To: Chris Cormack <chris@bigballofwax.co.nz> References: <003401c94446$b2fb8f80$18f2ae80$@edu> <23FC99CE-5792-4BD2-BBBC-09EFD0FE6790@biblio.org> <DD1D2ACF-3F3D-49EA-A9DB-988574B11329@gmail.com> <491DDBD2.3090202@free.fr> <606aab810812062322p2738f2eat8eda17dc0640c99c@mail.gmail.com> Chris Cormack wrote:
Hi Vincent
Is the below issue still a problem?
This issue is still problematic (ie I do not know the answer and a good packaging cannot modify a (not owned) global configuration file) Other problem I got are config files in general. The same config file is used by several packages so I must design config and postconf script to deal with this. You can see my current state here : http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip (not in a usable state as I just started to rewrite the management of conffig file....) If you have some remarks about the packaging splitting, I would be glad to get some feedback. http://git.debian.org/?p=collab-maint/koha.git;a=blob;f=debian/control;hb=wi...
I was wondering what I could do to help you finish the packaging. I work with a couple of Debian Developers and Francois was telling me on friday that if we get the packaging finished soon, that although we have missed lenny, if its done before january we might get it into the next ubuntu release.
If you havent had an answer on the below question let me know and I'll go find the answer for you
Ok, if you can test if koha works with current expat parser, it will help. I you kwow koha, telling me which config file is needed by which program would also be a good thing. The idea is to be able to answer to the question: Which config file (and which values will be read in it) do I need on each machine A, B and C if I want to setup: - koha opac and intranet on machine A - zebra server on machine B - pazpar2 server on machine C And which crontab/script do I need to run on each of these machines. I CC koha-devel in case someone else can answer these questions. Best regards and thanks for for help Vincent
CHris
On Sat, Nov 15, 2008 at 9:13 AM, Vincent Danjean <vdanjean.ml@free.fr> wrote:
[moving from koha to koha-devel due to my questions]
Mason James wrote:
On 2008/11/12, at 11:56 AM, Brendan Gallagher wrote:
Did you try editing ParserDetails.ini What I do not understand is why koha is requiring to modify such a global configuration file.
Is this setup really still required ? Were not the bugs from the expat filter fixed ? I do not know at all why this parser is/was needed, but Expact seems to work for the test case in koha scripts : vdanjean koha/misc$ ./sax_parser_print.pl XML::SAX::Expat=HASH(0x115c4f0) vdanjean koha/misc$ ./sax_parser_test.pl é vdanjean koha/misc )
By the way, this kind of requirement is really a bad thing (with my hat of trying to make a official Debian package) => it will be NOT possible at all that the koha package modifies the global configuration file. However, I really do not understand why, if the SAX parser is really needed, it is not required in the koha code itself.
For example, I tried to add as the first line in sax_parser_print.pl and sax_parser_test.pl the line: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; (tip found in the doc of XML::SAX::ParserFactory) Without changing my global configuration file, sax_parser_print.pl now report XML::LibXML::SAX.
I failed to see where koha really instantiate a sax parser. 'rgrep "use XML::SAX" koha/' does not return anything (but sax_parser_print.pl and sax_parser_test.pl).
Perhaps, koha gurus can know where SAX parser are used and add the line requesting the particular parser if it is still needed ?
Regards, Vincent
-- Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin
Hi all, I can say with certainty that Expact is not UNICODE safe, neither is PurlPerl ... only LibXML is safe. Cheers, Josh On Sun, Dec 7, 2008 at 3:33 AM, Vincent Danjean <vdanjean.ml@free.fr> wrote:
I forgot the CC
-------- Original Message -------- Subject: Re: [Koha-devel] [Koha] Wrong SAX Parser - does it matter? -> impact on Debian packaging Date: Sun, 07 Dec 2008 09:31:03 +0100 From: Vincent Danjean <vdanjean.ml@free.fr> To: Chris Cormack <chris@bigballofwax.co.nz> References: <003401c94446$b2fb8f80$18f2ae80$@edu> <23FC99CE-5792-4BD2-BBBC-09EFD0FE6790@biblio.org> <DD1D2ACF-3F3D-49EA-A9DB-988574B11329@gmail.com> <491DDBD2.3090202@free.fr> <606aab810812062322p2738f2eat8eda17dc0640c99c@mail.gmail.com>
Chris Cormack wrote:
Hi Vincent
Is the below issue still a problem?
This issue is still problematic (ie I do not know the answer and a good packaging cannot modify a (not owned) global configuration file)
Other problem I got are config files in general. The same config file is used by several packages so I must design config and postconf script to deal with this.
You can see my current state here : http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip (not in a usable state as I just started to rewrite the management of conffig file....)
If you have some remarks about the packaging splitting, I would be glad to get some feedback. http://git.debian.org/?p=collab-maint/koha.git;a=blob;f=debian/control;hb=wi...
I was wondering what I could do to help you finish the packaging. I work with a couple of Debian Developers and Francois was telling me on friday that if we get the packaging finished soon, that although we have missed lenny, if its done before january we might get it into the next ubuntu release.
If you havent had an answer on the below question let me know and I'll go find the answer for you
Ok, if you can test if koha works with current expat parser, it will help. I you kwow koha, telling me which config file is needed by which program would also be a good thing. The idea is to be able to answer to the question:
Which config file (and which values will be read in it) do I need on each machine A, B and C if I want to setup: - koha opac and intranet on machine A - zebra server on machine B - pazpar2 server on machine C And which crontab/script do I need to run on each of these machines.
I CC koha-devel in case someone else can answer these questions.
Best regards and thanks for for help Vincent
CHris
On Sat, Nov 15, 2008 at 9:13 AM, Vincent Danjean <vdanjean.ml@free.fr> wrote:
[moving from koha to koha-devel due to my questions]
Mason James wrote:
On 2008/11/12, at 11:56 AM, Brendan Gallagher wrote:
Did you try editing ParserDetails.ini What I do not understand is why koha is requiring to modify such a global configuration file.
Is this setup really still required ? Were not the bugs from the expat filter fixed ? I do not know at all why this parser is/was needed, but Expact seems to work for the test case in koha scripts : vdanjean koha/misc$ ./sax_parser_print.pl XML::SAX::Expat=HASH(0x115c4f0) vdanjean koha/misc$ ./sax_parser_test.pl é vdanjean koha/misc )
By the way, this kind of requirement is really a bad thing (with my hat of trying to make a official Debian package) => it will be NOT possible at all that the koha package modifies the global configuration file. However, I really do not understand why, if the SAX parser is really needed, it is not required in the koha code itself.
For example, I tried to add as the first line in sax_parser_print.pl and sax_parser_test.pl the line: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; (tip found in the doc of XML::SAX::ParserFactory) Without changing my global configuration file, sax_parser_print.pl now report XML::LibXML::SAX.
I failed to see where koha really instantiate a sax parser. 'rgrep "use XML::SAX" koha/' does not return anything (but sax_parser_print.pl and sax_parser_test.pl).
Perhaps, koha gurus can know where SAX parser are used and add the line requesting the particular parser if it is still needed ?
Regards, Vincent
-- Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro wrote:
I can say with certainty that Expact is not UNICODE safe, neither is PurlPerl ... only LibXML is safe.
In this case, do you know which part of Koha really call the XML parser ? As said before:
I failed to see where koha really instantiate a sax parser. 'rgrep "use XML::SAX" koha/' does not return anything (but sax_parser_print.pl and sax_parser_test.pl).
And if we know where the XML parser is called (directly or indirectly), we can set in the koha file(s) the global variable
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; in order to force the good XML parser without requiring to modify a global configuration file
Best regards, Vincent
On Sat, Nov 15, 2008 at 9:13 AM, Vincent Danjean <vdanjean.ml@free.fr> wrote:
[moving from koha to koha-devel due to my questions]
Mason James wrote:
On 2008/11/12, at 11:56 AM, Brendan Gallagher wrote:
Did you try editing ParserDetails.ini What I do not understand is why koha is requiring to modify such a global configuration file.
Is this setup really still required ? Were not the bugs from the expat filter fixed ? I do not know at all why this parser is/was needed, but Expact seems to work for the test case in koha scripts : vdanjean koha/misc$ ./sax_parser_print.pl XML::SAX::Expat=HASH(0x115c4f0) vdanjean koha/misc$ ./sax_parser_test.pl é vdanjean koha/misc )
By the way, this kind of requirement is really a bad thing (with my hat of trying to make a official Debian package) => it will be NOT possible at all that the koha package modifies the global configuration file. However, I really do not understand why, if the SAX parser is really needed, it is not required in the koha code itself.
For example, I tried to add as the first line in sax_parser_print.pl and sax_parser_test.pl the line: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; (tip found in the doc of XML::SAX::ParserFactory) Without changing my global configuration file, sax_parser_print.pl now report XML::LibXML::SAX.
I failed to see where koha really instantiate a sax parser. 'rgrep "use XML::SAX" koha/' does not return anything (but sax_parser_print.pl and sax_parser_test.pl).
Perhaps, koha gurus can know where SAX parser are used and add the line requesting the particular parser if it is still needed ?
Regards, Vincent
-- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin
On Sun, Dec 7, 2008 at 11:53 AM, Vincent Danjean <vdanjean.ml@free.fr> wrote:
Joshua Ferraro wrote:
I can say with certainty that Expact is not UNICODE safe, neither is PurlPerl ... only LibXML is safe.
In this case, do you know which part of Koha really call the XML parser ? As said before:
I failed to see where koha really instantiate a sax parser. 'rgrep "use XML::SAX" koha/' does not return anything (but sax_parser_print.pl and sax_parser_test.pl).
And if we know where the XML parser is called (directly or indirectly), we can set in the koha file(s) the global variable
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; in order to force the good XML parser without requiring to modify a global configuration file Primarily, Koha uses a SAX parser in MARC::File::XML, but also XML::Simple.
Cheers, Josh
Best regards, Vincent
On Sat, Nov 15, 2008 at 9:13 AM, Vincent Danjean <vdanjean.ml@free.fr> wrote:
[moving from koha to koha-devel due to my questions]
Mason James wrote:
On 2008/11/12, at 11:56 AM, Brendan Gallagher wrote: > Did you try editing ParserDetails.ini What I do not understand is why koha is requiring to modify such a global configuration file.
Is this setup really still required ? Were not the bugs from the expat filter fixed ? I do not know at all why this parser is/was needed, but Expact seems to work for the test case in koha scripts : vdanjean koha/misc$ ./sax_parser_print.pl XML::SAX::Expat=HASH(0x115c4f0) vdanjean koha/misc$ ./sax_parser_test.pl é vdanjean koha/misc )
By the way, this kind of requirement is really a bad thing (with my hat of trying to make a official Debian package) => it will be NOT possible at all that the koha package modifies the global configuration file. However, I really do not understand why, if the SAX parser is really needed, it is not required in the koha code itself.
For example, I tried to add as the first line in sax_parser_print.pl and sax_parser_test.pl the line: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; (tip found in the doc of XML::SAX::ParserFactory) Without changing my global configuration file, sax_parser_print.pl now report XML::LibXML::SAX.
I failed to see where koha really instantiate a sax parser. 'rgrep "use XML::SAX" koha/' does not return anything (but sax_parser_print.pl and sax_parser_test.pl).
Perhaps, koha gurus can know where SAX parser are used and add the line requesting the particular parser if it is still needed ?
Regards, Vincent
-- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
And if we know where the XML parser is called (directly or indirectly), we can set in the koha file(s) the global variable
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; in order to force the good XML parser without requiring to modify a global configuration file Primarily, Koha uses a SAX parser in MARC::File::XML, but also XML::Simple.
XML::LibXML::SAX is specifically required by MARC::File::XML. With another SAX parser, XML MARC records are not correctly decoded-encoded and accented characters, for example, are mixed. In this file: MARC/File/XML.pm line 21: my $factory = XML::SAX::ParserFactory->new(); a SAX parser is instantiated. So since MARC::File::XML need XML::LibXML::SAX, it should ask explicitly this parser and insert before line 21, as said by Vincent: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; Can't someone contact MARC::File:XML package maintainer and ask him to update his code? -- Frédéric
Frederic Demians wrote:
And if we know where the XML parser is called (directly or indirectly), we can set in the koha file(s) the global variable
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; in order to force the good XML parser without requiring to modify a global configuration file Primarily, Koha uses a SAX parser in MARC::File::XML, but also XML::Simple.
XML::LibXML::SAX is specifically required by MARC::File::XML. With another SAX parser, XML MARC records are not correctly decoded-encoded and accented characters, for example, are mixed.
In this file:
MARC/File/XML.pm
line 21:
my $factory = XML::SAX::ParserFactory->new();
a SAX parser is instantiated.
So since MARC::File::XML need XML::LibXML::SAX, it should ask explicitly this parser and insert before line 21, as said by Vincent:
$XML::SAX::ParserPackage = "XML::LibXML::SAX";
Can't someone contact MARC::File:XML package maintainer and ask him to update his code?
Someone can ask but I'm not sure that the MARC::File:XML package maintainer will agree with this modification. Perhaps, he will add the line. But he can also answer: - MARC::File::XML can work with other XML parser if there is no accentuated letter (no non-ASCII letter) so I do not want to force a specific dependency or - MARC::File::XML requires a correct XML parser. If one XML parser is buggy then bug must be filled against this XML parser and not against packages that use XML parser. or - MARC::File::XML will implement in a future release a mechanism to be able to choose the XML parser (such as XML::Simple) or - ... So, asking him is a good thing (perhaps he does not know the issue). But koha can also force the use of the parser it needs (ie add $XML::SAX::ParserPackage = "XML::LibXML::SAX"; when it uses MARC::File::XML) It would be good also that misc/sax_parser_test.pl really tests the parser (I get the same binary output with XML::LibXML::SAX or with the Expat XML parser) Note that, according to the XML::Simple documentation, XML::Simple can also force the XML parser it will use by setting: $XML::Simple::PREFERRED_PARSER="XML::LibXML::SAX"; I prepared two commits for koha to force the use of the LibXML parser. Can you test them and apply them if they are ok ? (I only greped for any occurrences of XML::Simple and MARC::File::XML and add the correct line). Both commits are available at the top of my wip-for-upstream branch: http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip-f... They are: - "Force MARC::File::XML to use the XML::LibXML::SAX parser" and - "Force XML::Simple to use to XML::LibXML::SAX parser" Regards, Vincent
Vincent Danjean a écrit :
Frederic Demians wrote:
And if we know where the XML parser is called (directly or indirectly), we can set in the koha file(s) the global variable
$XML::SAX::ParserPackage = "XML::LibXML::SAX";
in order to force the good XML parser without requiring to modify a global configuration file
Primarily, Koha uses a SAX parser in MARC::File::XML, but also XML::Simple.
XML::LibXML::SAX is specifically required by MARC::File::XML. With another SAX parser, XML MARC records are not correctly decoded-encoded and accented characters, for example, are mixed.
In this file:
MARC/File/XML.pm
line 21:
my $factory = XML::SAX::ParserFactory->new();
a SAX parser is instantiated.
So since MARC::File::XML need XML::LibXML::SAX, it should ask explicitly this parser and insert before line 21, as said by Vincent:
$XML::SAX::ParserPackage = "XML::LibXML::SAX";
Can't someone contact MARC::File:XML package maintainer and ask him to update his code?
Someone can ask but I'm not sure that the MARC::File:XML package maintainer will agree with this modification. Josh is the package maintainer, he may agree with that modification ;) Perhaps, he will add the line. But he can also answer: - MARC::File::XML can work with other XML parser if there is no accentuated letter (no non-ASCII letter) so I do not want to force a specific dependency or - MARC::File::XML requires a correct XML parser. If one XML parser is buggy then bug must be filled against this XML parser and not against packages that use XML parser. or - MARC::File::XML will implement in a future release a mechanism to be able to choose the XML parser (such as XML::Simple) or - ...
So, asking him is a good thing (perhaps he does not know the issue). But koha can also force the use of the parser it needs (ie add $XML::SAX::ParserPackage = "XML::LibXML::SAX"; when it uses MARC::File::XML)
It would be good also that misc/sax_parser_test.pl really tests the parser (I get the same binary output with XML::LibXML::SAX or with the Expat XML parser)
Note that, according to the XML::Simple documentation, XML::Simple can also force the XML parser it will use by setting: $XML::Simple::PREFERRED_PARSER="XML::LibXML::SAX";
I prepared two commits for koha to force the use of the LibXML parser. Can you test them and apply them if they are ok ? (I only greped for any occurrences of XML::Simple and MARC::File::XML and add the correct line). Both commits are available at the top of my wip-for-upstream branch: http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip-f... They are: - "Force MARC::File::XML to use the XML::LibXML::SAX parser" and - "Force XML::Simple to use to XML::LibXML::SAX parser"
I'll try your patches.
Vincent Danjean a écrit :
Frederic Demians wrote:
And if we know where the XML parser is called (directly or indirectly), we can set in the koha file(s) the global variable
> $XML::SAX::ParserPackage = "XML::LibXML::SAX"; > in order to force the good XML parser without requiring to modify a global configuration file
Primarily, Koha uses a SAX parser in MARC::File::XML, but also XML::Simple.
XML::LibXML::SAX is specifically required by MARC::File::XML. With another SAX parser, XML MARC records are not correctly decoded-encoded and accented characters, for example, are mixed.
In this file:
MARC/File/XML.pm
line 21:
my $factory = XML::SAX::ParserFactory->new();
a SAX parser is instantiated.
So since MARC::File::XML need XML::LibXML::SAX, it should ask explicitly this parser and insert before line 21, as said by Vincent:
$XML::SAX::ParserPackage = "XML::LibXML::SAX";
Can't someone contact MARC::File:XML package maintainer and ask him to update his code?
Someone can ask but I'm not sure that the MARC::File:XML package maintainer will agree with this modification. Josh is the package maintainer, he may agree with that modification ;) Actually, I'm just the CPAN Package maintainer, I haven't worked on M::F::X much in a while. I believe it's now Mike Rylander now. This code's version control lives at SourceForge the MARCPM project, and
On Sun, Dec 7, 2008 at 6:04 PM, Henri-Damien LAURENT <laurenthdl@alinto.com> wrote: the best forum for discussing this type of issue is probably the Perl4Lib listserv. Cheers, Josh
Perhaps, he will add the line. But he can also answer: - MARC::File::XML can work with other XML parser if there is no accentuated letter (no non-ASCII letter) so I do not want to force a specific dependency or - MARC::File::XML requires a correct XML parser. If one XML parser is buggy then bug must be filled against this XML parser and not against packages that use XML parser. or - MARC::File::XML will implement in a future release a mechanism to be able to choose the XML parser (such as XML::Simple) or - ...
So, asking him is a good thing (perhaps he does not know the issue). But koha can also force the use of the parser it needs (ie add $XML::SAX::ParserPackage = "XML::LibXML::SAX"; when it uses MARC::File::XML)
It would be good also that misc/sax_parser_test.pl really tests the parser (I get the same binary output with XML::LibXML::SAX or with the Expat XML parser)
Note that, according to the XML::Simple documentation, XML::Simple can also force the XML parser it will use by setting: $XML::Simple::PREFERRED_PARSER="XML::LibXML::SAX";
I prepared two commits for koha to force the use of the LibXML parser. Can you test them and apply them if they are ok ? (I only greped for any occurrences of XML::Simple and MARC::File::XML and add the correct line). Both commits are available at the top of my wip-for-upstream branch: http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip-f... They are: - "Force MARC::File::XML to use the XML::LibXML::SAX parser" and - "Force XML::Simple to use to XML::LibXML::SAX parser"
I'll try your patches.
_______________________________________________ Koha-patches mailing list Koha-patches@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-patches
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
I prepared two commits for koha to force the use of the LibXML parser. Can you test them and apply them if they are ok ? (I only greped for any occurrences of XML::Simple and MARC::File::XML and add the correct line). Both commits are available at the top of my wip-for-upstream branch: http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip-f... They are: - "Force MARC::File::XML to use the XML::LibXML::SAX parser"
You have: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; use MARC::File::XML; It doesn't work. I've tested it on a Debian box where I can see immediately if extended characters are properly displayed or not which is not the case with your patch. This modification works: $XML::SAX::ParserPackage = "XML::LibXML::SAX"; require MARC::File::XML;
and - "Force XML::Simple to use to XML::LibXML::SAX parser"
I can't say if it works and even if it's necessary. We know for sure that MARC::File::XML requires LibXML, but I haven't seen yet that it's also the case for XML::Simple. Another solution for MARC::File::XML would be to embed this package with Koha by copying 'MARC' directory and it's subdirectory into Koha installation root directory at the same level than 'C4' and then modifying XML.pm file to force LibXML use. Thank you very much Vincent for the good job! -- Frédéric
2008/12/8 Frederic Demians <frederic@tamil.fr>:
I prepared two commits for koha to force the use of the LibXML parser. Can you test them and apply them if they are ok ? (I only greped for any occurrences of XML::Simple and MARC::File::XML and add the correct line). Both commits are available at the top of my wip-for-upstream branch: http://git.debian.org/?p=collab-maint/koha.git;a=shortlog;h=refs/heads/wip-f... They are: - "Force MARC::File::XML to use the XML::LibXML::SAX parser"
You have:
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; use MARC::File::XML;
It doesn't work. I've tested it on a Debian box where I can see immediately if extended characters are properly displayed or not which is not the case with your patch. This modification works:
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; require MARC::File::XML;
This is because "use" is inside an implicit "BEGIN" block, so it would be executed before $XML::SAX::ParserPackage is set. I haven't tested it but this should work too: BEGIN { $XML::SAX::ParserPackage = "XML::LibXML::SAX"; } use MARC::File::XML; Depending on whether anything is actually imported (a "use" is a "require" followed by an "import"), this would mean a slightly different thing. -- cheers, -ambrose The 'net used to be run by smart people; now many sites are run by idiots. So SAD... (Sites that do spam filtering on mails sent to the abuse contact need to be cut off the net...)
Frederic Demians wrote:
You have:
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; use MARC::File::XML;
It doesn't work. I've tested it on a Debian box where I can see immediately if extended characters are properly displayed or not which is not the case with your patch. This modification works:
$XML::SAX::ParserPackage = "XML::LibXML::SAX"; require MARC::File::XML;
Why is it so? The "use" statement is executed once at compile time. The only parameterisation is passed via the use statement itself. In the above example, the "use' statement is actually executed before the assignment to ParserPackage. This seems strange until you realise that "use" is implicitly executed in the BEGIN { } block for the module or script. The "require" statement is executed at run time.The ParserPackage variable is seen during the load of the module MARC::File::XML. Behavior modified as expected. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Finster's Law: A closed mouth gathers no feet.
participants (6)
-
Ambrose Li -
Frederic Demians -
Henri-Damien LAURENT -
Joshua Ferraro -
Rick Welykochy -
Vincent Danjean