[Koha-bugs] [Bug 7170] Remove use of XML::Simple
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7170 mathieu saby mathieu.s...@univ-rennes2.fr changed: What|Removed |Added CC||mathieu.saby@univ-rennes2.f ||r --- Comment #11 from mathieu saby mathieu.s...@univ-rennes2.fr --- Hello Does someone still work on this bug? XML::Simple is still used by a lot of files. Any change that could improve performances would be a good thing! (And yes, I know Plack and Memcached ;-) ) Using Yaml instead of XML in some cases (particulary for Koha-conf) would also be a GREAT thing ( some libraries don't want to use Memcached). M. Saby Rennes 2 University -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7170] Remove use of XML::Simple
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7170 --- Comment #12 from Jared Camins-Esakov jcam...@cpbibliography.com --- (In reply to comment #11) Hello Does someone still work on this bug? XML::Simple is still used by a lot of files. I was actually thinking about working on this on my flight home tomorrow, actually. It depends how tired I am. In order to stay awake on flights I work on projects like this, that do not require any outside input. Any change that could improve performances would be a good thing! (And yes, I know Plack and Memcached ;-) ) Plack is not ready for production in my opinion, so I wasn't going to suggest it. Memcached is good, but not a silver bullet. For this, an mmap'd cache might be useful. I will experiment if I work on the problem. Using Yaml instead of XML in some cases (particulary for Koha-conf) would also be a GREAT thing ( some libraries don't want to use Memcached). If we can get drastically better performance using a different XML parser I think I might prefer that to switching to YAML, even if the other parser requires some massaging of the output data structure. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7170] Remove use of XML::Simple
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7170 --- Comment #13 from Jared Camins-Esakov jcam...@cpbibliography.com --- Also note that if you are not using XML::SAX::ExpatXS as your parser, you should be. You can do that by setting the environment variable XML_SIMPLE_PREFERRED_PARSER to 'XML::SAX::ExpatXS'. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9401] Javascript used for tags handling wants access to CGISESSID cookie
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9401 --- Comment #5 from M. de Rooy m.de.r...@rijksmuseum.nl --- (In reply to comment #4) This patch has been pushed to Master. Tagging worked for me both before and after applying this patch on top of the patch for bug 9102. I am not entirely sure why. However, since it worked after, I am pushing the patch anyway since it removes unnecessary cruft. Hi Jared Tagging worked since the session id from javascript was only plan-B in the script. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9536] New: Make it still easier to add to the the list of possible encodings for Z39.50 servers.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9536 Bug ID: 9536 Summary: Make it still easier to add to the the list of possible encodings for Z39.50 servers. Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcha...@gmail.com Reporter: egpetri...@yahoo.com CC: m.de.r...@rijksmuseum.nl This is a follow-up to Bug 9497 - Make it easier to add to the the list of possible encodings for Z39.50 servers and add ISO 8859-1 and a previous message of mine to the general list (Sep 23, 2012). The purpose of the suggestion is to make koha more flexible as it regards Z39.50 targets' encoding. From what I can see in http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/ZOOM.pod, the calling application (koha in our case ?) has to set the encoding conversion, and ZOOM forwards it in turn to the called YAZ module (as per http://www.indexdata.com/yaz/doc/zoom.records.html). YAZ in turn is supposed to be a wrapper for the library system call iconv. But YAZ' iconv utility also implements conversions on its own (as per http://www.indexdata.com/yaz/doc/yaz.pdf and http://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1. 13/iconv.1.html). In other words, besides marc8, marc8s, marc8lossy, marc8lossless, utf8, iso8859-1, iso5426, iso5428:1984, advancegreek and danmarc, encodings that it natively supports, YAZ is supposed to be able to handle all the encodings supported by iconv. In debian at least, the list of encodings that YAZ supports (fully or partially) is enormous: iconv -l The following list contain all the coded character sets known. This does not necessarily mean that all combinations of these names can be used for the FROM and TO command line parameters. One coded character set can be listed with several different names (aliases). 437, 500, 500V1, 850, 851, 852, 855, 856, 857, 860, 861, 862, 863, 864, 865, 866, 866NAV, 869, 874, 904, 1026, 1046, 1047, 8859_1, 8859_2, 8859_3, 8859_4, 8859_5, 8859_6, 8859_7, 8859_8, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ANSI_X3.4-1968, ANSI_X3.4-1986, ANSI_X3.4, ANSI_X3.110-1983, ANSI_X3.110, ARABIC, ARABIC7, ARMSCII-8, ASCII, ASMO-708, ASMO_449, BALTIC, BIG-5, BIG-FIVE, BIG5-HKSCS, BIG5, BIG5HKSCS, BIGFIVE, BRF, BS_4730, CA, CN-BIG5, CN-GB, CN, CP-AR, CP-GR, CP-HU, CP037, CP038, CP273, CP274, CP275, CP278, CP280, CP281, CP282, CP284, CP285, CP290, CP297, CP367, CP420, CP423, CP424, CP437, CP500, CP737, CP775, CP803, CP813, CP819, CP850, CP851, CP852, CP855, CP856, CP857, CP860, CP861, CP862, CP863, CP864, CP865, CP866, CP866NAV, CP868, CP869, CP870, CP871, CP874, CP875, CP880, CP891, CP901, CP902, CP903, CP904, CP905, CP912, CP915, CP916, CP918, CP920, CP921, CP922, CP930, CP932, CP933, CP935, CP936, CP937, CP939, CP949, CP950, CP1004, CP1008, CP1025, CP1026, CP1046, CP1047, CP1070, CP1079, CP1081, CP1084, CP1089, CP1097, CP1112, CP1122, CP1123, CP1124, CP1125, CP1129, CP1130, CP1132, CP1133, CP1137, CP1140, CP1141, CP1142, CP1143, CP1144, CP1145, CP1146, CP1147, CP1148, CP1149, CP1153, CP1154, CP1155, CP1156, CP1157, CP1158, CP1160, CP1161, CP1162, CP1163, CP1164, CP1166, CP1167, CP1250, CP1251, CP1252, CP1253, CP1254, CP1255, CP1256, CP1257, CP1258, CP1282, CP1361, CP1364, CP1371, CP1388, CP1390, CP1399, CP4517, CP4899, CP4909, CP4971, CP5347, CP9030, CP9066, CP9448, CP10007, CP12712, CP16804, CPIBM861, CSA7-1, CSA7-2, CSASCII, CSA_T500-1983, CSA_T500, CSA_Z243.4-1985-1, CSA_Z243.4-1985-2, CSA_Z243.419851, CSA_Z243.419852, CSDECMCS, CSEBCDICATDE, CSEBCDICATDEA, CSEBCDICCAFR, CSEBCDICDKNO, CSEBCDICDKNOA, CSEBCDICES, CSEBCDICESA, CSEBCDICESS, CSEBCDICFISE, CSEBCDICFISEA, CSEBCDICFR, CSEBCDICIT, CSEBCDICPT, CSEBCDICUK, CSEBCDICUS, CSEUCKR, CSEUCPKDFMTJAPANESE, CSGB2312, CSHPROMAN8, CSIBM037, CSIBM038, CSIBM273, CSIBM274, CSIBM275, CSIBM277, CSIBM278, CSIBM280, CSIBM281, CSIBM284, CSIBM285, CSIBM290, CSIBM297, CSIBM420, CSIBM423, CSIBM424, CSIBM500, CSIBM803, CSIBM851, CSIBM855, CSIBM856, CSIBM857, CSIBM860, CSIBM863, CSIBM864, CSIBM865, CSIBM866, CSIBM868, CSIBM869, CSIBM870, CSIBM871, CSIBM880, CSIBM891, CSIBM901, CSIBM902, CSIBM903, CSIBM904, CSIBM905, CSIBM918, CSIBM921, CSIBM922, CSIBM930, CSIBM932, CSIBM933, CSIBM935, CSIBM937, CSIBM939, CSIBM943, CSIBM1008, CSIBM1025, CSIBM1026, CSIBM1097, CSIBM1112, CSIBM1122, CSIBM1123, CSIBM1124, CSIBM1129, CSIBM1130, CSIBM1132, CSIBM1133, CSIBM1137, CSIBM1140, CSIBM1141, CSIBM1142, CSIBM1143, CSIBM1144, CSIBM1145, CSIBM1146, CSIBM1147, CSIBM1148, CSIBM1149, CSIBM1153, CSIBM1154, CSIBM1155, CSIBM1156, CSIBM1157, CSIBM1158, CSIBM1160, CSIBM1161, CSIBM1163, CSIBM1164, CSIBM1166, CSIBM1167, CSIBM1364, CSIBM1371,
[Koha-bugs] [Bug 9343] SIP doesn't handle debarred date/status correctly
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9343 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Status|Pushed to Master|Pushed to Stable --- Comment #7 from Chris Cormack ch...@bigballofwax.co.nz --- Pushed to 3.10.x will be in 3.10.3 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9537] New: Add a list of the patches that have been applied to a koha installation
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9537 Bug ID: 9537 Summary: Add a list of the patches that have been applied to a koha installation Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs@lists.koha-community.org Reporter: egpetri...@yahoo.com CC: gmcha...@gmail.com I wonder if it would be useful to add a tab in the home, about koha section, displaying a list patches that have been applied to the specific koha installation, similar to the list of pearl modules. This could prove handy when trying to ascertain why a bug that doesn't exist in the main distribution manifests itself in some git derivative or other. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9537] Add a list of the patches that have been applied to a koha installation
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9537 Liz Rea (CatalystIT) l...@catalyst.net.nz changed: What|Removed |Added Status|NEW |ASSIGNED CC||l...@catalyst.net.nz Assignee|koha-b...@lists.koha-commun |egpetri...@yahoo.com |ity.org | --- Comment #1 from Liz Rea (CatalystIT) l...@catalyst.net.nz --- This development would be welcomed, however it seems unlikely that it will be fixed without a code submission by someone who is really interested in seeing this feature in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 9516] Item Availability/Data missing from OPAC tag search
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 --- Comment #6 from David Cook dc...@prosentient.com.au --- (In reply to comment #4) Neither I nor Owen have been able to reproduce this bug. Hmmm, intriguing! The more I look at the getRecords and searchResults subs, the more confused I get by the marc/marcxml/items synchronization. If it's working for you guys, it must mean that my sync is off, because using getRecords seems to return raw marc with embedded item data, while just querying the marc blob in the database returns raw marc without item data. :S I thought that the marcxml and marc weren't supposed to store item-level data anymore, but I don't see in these subs where it is being added. In fact, in searchResults (around line 1729: Pull out the items fields), it seems that the incoming marcRecord param passed into searchResults should have that embedded item data :S. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
