neu.edu.tr← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 13:18 | thd-away | kados: are you around? |
| 13:19 | kados | thd: yes |
| 14:00 | owen: noticed your recent commit related to decimal place | |
| 14:00 | owen | Yes? |
| 14:00 | kados | owen: I'm wondering if we shouldn't have a syspref specifying number of decimal places |
| 14:00 | and use that instead of a hardcoded value | |
| 14:00 | any thoughts? | |
| 14:01 | owen | I've asked that before, but since no one has ever jumped on it I've been fixing them piecemeal. |
| 14:01 | kados | heh |
| 14:01 | owen | I think a syspref is a fine idea. |
| 14:02 | kados | paul will probably want us to wait until 3.0 for that change |
| 14:03 | owen | Should that be combined with a local currency preference? |
| 14:03 | kados | probably yes |
| 14:03 | I bet there's a free currency package out there | |
| 14:03 | we could integrate at some point | |
| 15:32 | chris | morning |
| 15:40 | kados | morning chris |
| 15:40 | chris: we had a nice bugsquash mtg | |
| 15:40 | chris | cool |
| 15:40 | kados | chris: pierrick's got a whole list of questions for you :-) |
| 15:40 | chris | righto |
| 19:56 | thd | kados: are you back later yet? |
| 01:16 | mason | . |
| 01:55 | pierrick | chris, are you around? |
| 01:58 | kados? | |
| 02:12 | paul | pierrick: peut être que joshua dort un peu quand même ;-) |
| 02:13 | pierrick: bonjour | |
| 02:13 | pierrick | paul, bonjour |
| 02:13 | paul, oui, mais ses horaires sont parfois surprenant | |
| 02:13 | hdl | bonjour le monde |
| 02:13 | paul | exact ! |
| 02:13 | pierrick | bonjour hdl |
| 02:13 | paul | hello hdl |
| 02:14 | vive la paperasse à la française !!! | |
| 02:14 | déclarations 2042+ 2035A+ 2035B+ Formation Professionnelle+ TVA+Taxe pro | |
| 02:15 | reste juste à faire un chèque de 8250€ pour le solde de TVA de 2005... | |
| 02:15 | c'était ma vie ;-) | |
| 02:17 | pierrick: qqn a modifié l'ancien wiki hier( www.koha.org/wiki) | |
| 02:18 | pierrick | paul, à ma connaissance, Joshua n'a pas officialisé le nouveau wiki |
| 02:18 | paul | ouaip, mais comme on l'utilise... |
| 02:19 | bon, je viens de modifier la page d'accueil de l'ancien. | |
| 02:19 | pierrick | OK |
| 02:19 | Je pense bientôt faire une proposition de nouvelle page d'accueil pour le nouveau wiki. La page actuelle est trop chargée | |
| 02:31 | russ | hi everyone |
| 02:32 | paul | hello russ |
| 02:32 | so... everybody coming to Marseille has it's own laptop. | |
| 02:32 | almost everybody has a laptop with wifi. | |
| 02:33 | we have a room with 15 chairs, should be OK even if we are 16 | |
| 02:33 | russ | cool |
| 02:34 | chris and i are working together on his presntation at the moment | |
| 02:50 | paul you there? | |
| 02:50 | paul | yep |
| 02:50 | russ | have you got a speaker sorted for the first day? |
| 02:50 | paul | (although on phone) |
| 02:50 | russ | for the first talk |
| 02:50 | no worries | |
| 02:52 | pierrick | hi russ |
| 02:52 | russ | hi pierrick |
| 02:52 | pierrick | russ, who manages bugs.koha.org, I mean software upgrades and so on |
| 02:52 | ? | |
| 02:52 | russ | chris |
| 02:52 | pierrick | (because I would really like an upgrade to Bugzilla 2.20.x) |
| 02:53 | russ | (he is sitting right next to me at the moment) |
| 02:53 | pierrick | bugzilla 2.14.2 is 4 years old, has bugs and is not supported anymore |
| 02:53 | russ | he'll have a look |
| 02:53 | pierrick | hi chris :-) |
| 02:53 | russ | :-) |
| 02:54 | pierrick | OK, if he wants, I can work on the upgrade, but I need a MySQL dump :-) |
| 02:54 | russ | he'll do it |
| 02:55 | the upgrade i mean | |
| 02:55 | pierrick | OK, thank you :-) |
| 02:55 | hdl | hi russ and chris. |
| 02:55 | russ | hi hdl |
| 03:13 | thd | paul hdl: I was confused by what was said yesterday about normal (budget based) acquisitions being used by your libraries for the past two years. |
| 03:14 | hdl | confused ? |
| 03:14 | hi osmoze. | |
| 03:15 | thd | hdl: I am the one confused by paul's statement yesterday :) |
| 03:16 | hdl | yes thd. I had read it. |
| 03:16 | you said confused. | |
| 03:16 | paul | (still on phone) |
| 03:16 | hdl | Is that because you think it doesnot work ? |
| 03:16 | thd | hdl: do you have libraries tracking funds and payments to place and receive orders within Koha during the past two years? |
| 03:17 | hdl | I am only one year old in Koha project. But yes I now some. |
| 03:18 | I know some limits to acquisition management. | |
| 03:18 | But some ppl found it useful. | |
| 03:18 | thd | hdl: yes, when I tested for 2.2.3 I found some aspects of budget based acquisitions not working in the default intranet English templates. |
| 03:18 | osmoze | hello |
| 03:19 | hdl | pls detail. |
| 03:19 | thd | hcl: chris had explained to me at the time that normal acquisitions had been broken since 2.X. |
| 03:20 | hdl | (hcl stands for chlorydric Acid. :) ) |
| 03:21 | thd: I know they had some template for their clients that wouldnot break things. | |
| 03:21 | thd | hdl: I found that some pages for placing an order had been disconnected from the templates. |
| 03:22 | hdl: Also, I found that I could not complete receiving an order. | |
| 03:24 | hdl: I found that an order once completed could not be found because the invoice number was never saved in the SQL tables or something like that. | |
| 03:25 | hdl: During receipt of the order the quantities were not deducted from the original order. | |
| 03:25 | hdl | thd: I admit there are some real needs and some hard work awaiting us on taht module. |
| 03:26 | It is normal not to be deducted from order. | |
| 03:27 | thd: what wouldnot be normal were if many receptions of One order was forgotten with keeping the latest reception. | |
| 03:28 | thd: item receptions must not be deducted but compared to order IMHO. | |
| 03:28 | thd | hdl: I do not remember all the problems with the acquisitions that I encountered as I had become satisfied with the answer chris gave about it having been broken for years and his clients were not yet using 2.X. |
| 03:29 | hdl: so it seems that you have some scheme for working around some difficulties | |
| 03:30 | hdl: Your libraries are not troubled when a distributor sends only a partial shipment as is the usual case in my experience where some titles still remain to be sent. | |
| 03:32 | hdl: how do your libraries track receipt of partial shipments without committing the partial receipt of the order? I should have said that rather than deducted from the original order. | |
| 03:34 | hdl | thd: you won. ;) (They cannot manage it properly with the actual system.) They know We know. As I said, Work work and work again on Acquisition module. |
| 03:36 | thd | hdl: yet enough of it does work for your libraries that they use it to provide some service instead of simply using acquisitions simple? |
| 03:37 | hdl | thd: yes. And normal acquisition is required for serials management. |
| 03:38 | thd | hdl: and you support and maintain it somewhat in its current partly working state? I guess that I assumed serials management was an exception that would also work for simple acquisitions without using a budget. |
| 03:40 | hdl: That clarifies my confusion for acquisitions from yesterday. I have one more question. | |
| 03:40 | hdl | thd: yes ? |
| 03:42 | thd | hdl: paul had made reference to work being done to correct the UNIMARC framework. Work that was 95% done. Can you clarify for me what work that is? |
| 03:44 | hdl | ask paul directly. :) (I think it is a work out of clients will and normalization will) |
| 03:46 | thd | hdl: ok I will ask paul directly, I do not understand your usage of will just now. |
| 03:47 | paul: I have a question for you about your recent work on the UNIMARC framework. | |
| 03:47 | paul: please let me know when you are off phone. | |
| 03:47 | hdl | thd : will stands for request or need compliance. |
| 03:49 | thd | hdl:'request' or 'need' would have been understandable for me in English for that context. |
| 03:50 | hdl | thd: sorry. English is only my second language. ;) |
| 03:51 | thd | hdl: I know and English and French are much too tricky. I can certainly see how anyone might think that will would apply and yet I was baffled by the usage :) |
| 03:51 | hdl | And I thought will would denote also kind of commitment conotation. |
| 03:53 | thd | hdl: your expectation was very reasonable about the usage of 'will' and yet if native users never imagine the word in that manner despite its possible application I could not think of what you had meant :) |
| 04:01 | hdl: language ought to be about conveying meaning where words are accepted for their meaning in whatever context the might possibly be applied. Yet in practise human capacity for language is too limited so we become confused by anything outside a customary pattern because determining possible meaning takes too long to process for our little brains :) | |
| 04:01 | s/the/they/ | |
| 04:03 | hdl | :D |
| 04:46 | tumer | Hi is paul around? |
| 04:46 | paul | yes. |
| 04:47 | hello tumer | |
| 04:47 | tumer | Hi paul I have questions regarding 2.4 and UTF8 |
| 04:47 | have time? | |
| 04:47 | paul | throw it, although i'm not sure i'll be the best person to answer. |
| 04:48 | tumer | By the way sorry I missed bug-squash I almost got squashed by a two legged bug |
| 04:48 | are you using char_decode still | |
| 04:49 | paul | (kados could confirm) |
| 04:49 | tumer | Well I think the char_decode has got some wrong coding in 2.2 thats why some german characters do not get converted. |
| 04:50 | I have corrected them but dont want to commit it unless someone else tries it as well | |
| 04:51 | I are the person (MARC21) | |
| 04:51 | Who else uses above ascii? | |
| 04:51 | paul | I suggest you wait until joshua is back from it's bed to decide wether you commit or not. |
| 04:52 | most libraries I think, although very rarely for english ppl | |
| 04:53 | tumer | This new M::F::XML does not convert some of the Turkish chars from MARC-8 to UTF-8 so its out for me. I still have to rely on char_decode untill there is a fix |
| 04:55 | Another problem we have to realise is that the new M:F:X is very sensitive , tries to be clever. | |
| 04:57 | In 2.2 when moving to 2.4 or 3.0 we have to make sure that all existing MARC records are UTF-8. Not only the chars but the leader as well otherwise everything breaks down | |
| 04:59 | paul | tumer: you're right = the updatedatabase tool will have to take care of this. |
| 05:01 | thd | tumer: why doe s the leader need to be UTF-8 when it contains only ASCII values by definition? |
| 05:02 | tumer: the leader would never have multibyte characters. | |
| 05:02 | tumer | The leader position 10 has to say "a" if the MARC record contains any UTF-8 otherwise breaks. This does not happen with old MFX cause it does not care just passes anything it has as it is |
| 05:03 | The new MFX tries to convert everything to MARC-8. HAve Phone. Out! | |
| 05:03 | thd | tumer: what I meant was that the 'a' and every other character in the leader is ASCII |
| 05:04 | paul | thd: I think tumer means that the leader MUST reflect the fact that the biblio is in utf-8 |
| 05:05 | thd | paul: yes tumer the leader character encoding setting must reflect the character change and some fixes that kados applied for that purpose have sometimes broken. |
| 05:07 | tumer: the real problem is that people have records in their system where the leader specified encoding does not match the actual record content in a different encoding. | |
| 05:10 | tumer: I have communicated to kados about systems which attempt to guess what starting encoding is actually used before conversion and then test as to whether the proposition about the possible encoding is true to overcome cases where the starting encoding is uncertain despite the setting of the record specifying a particular encoding. | |
| 05:12 | tumer: characters past the ASCII range are of importance even in fairly monolingual English records in the US because the standard forms of proper names may use characters past the ASCII range. | |
| 05:14 | tumer: I am in New York City where ASCII only would not be taken seriously by most any library. The English only mono culture that infects large parts of the US is pleasantly absent in New York. | |
| 05:17 | tumer: Also Spanish language material is becoming increasingly important throughout the US despite the false hostility towards immigrants expressed in the US Congress recently. | |
| 05:17 | paul | thd : tumer is disconnected |
| 05:17 | thd | :) |
| 05:18 | maybe he will see the logs later | |
| 05:22 | paul: so the question I had for you is what work were you referring to yesterday for recent UNIMARC framework corrections that you had mentioned were 95% done. | |
| 05:22 | ? | |
| 07:02 | paul | hello Sylvinh1 ! |
| 07:02 | l'espion marseillais. | |
| 07:03 | ToinS | salut sylvinho |
| 07:09 | thd | paul: If you are back again, I will ask again. What UNIMARC framework work have you done recently? You had refereed to something yesterday that was 95% done. |
| 07:10 | Sylvinh1 | bijour |
| 07:16 | paul | i'm back thd |
| 07:17 | thd | paul: Did you understand my question? |
| 07:17 | paul | I was a little bit too quick when saying it's 95% done. |
| 07:17 | thd | paul: so it is less than 95% done? |
| 07:18 | paul | in fact, I have many frameworks, some that are small & interesting for libraries that don't want too much MARC, some are complete, but a little bit too much for some libraries. |
| 07:18 | for example, the framework used by IPT is really complete. | |
| 07:18 | while the framework used by EMN is small & efficient, but incomplete. | |
| 07:19 | the one in CVS is a small & efficient one, although 100 & other coded fields are not here. | |
| 07:19 | I don't think i'll change anything to the CVS framework for instance. | |
| 07:19 | thd | paul: what is IPT? |
| 07:19 | paul | Institut Protestant de Théologie (one of my clients) |
| 07:21 | tumer | paul: As a framework expert can you suggest me 2 subfields to use internally for koha for LC indexing. like 090$c biblionumber? |
| 07:22 | thd | paul: have you seen the work that I prepared for kados where we had extended the hidden parameter to allow support for very comprehensive frameworks without bringing the record editor to a halt generating an excessively large form? |
| 07:22 | paul | tumer: no, I think you can use whatever you want (technically). If it's a marc21 question, then thd is a better source |
| 07:23 | thd: a little bit, although not completly | |
| 07:24 | thd | paul: I sent a copy to hdl. I had not wanted to commit it until I had finished a few last things and verified ever little element again. |
| 07:24 | tumer | paul: it has to be decided in general like the biblionumber so that if a library wants to use LC indexing 2 more fields that I'll add to biblioitems will have to reside |
| 07:24 | paul | tumer: ??? |
| 07:25 | thd | tumer: i will answer you in one moment. |
| 07:26 | paul: what recent work is it that is that is less than 95% complete. | |
| 07:26 | ? | |
| 07:26 | paul | the framework in cvs rel_2_2, default, for unimarc is incomplete. |
| 07:26 | while I have some that are complete, but too much for half of the libraries I bet. | |
| 07:29 | tumer | paul:For LC indexing I have to parse the classification into 2 parts. Alphabetic and numeric. (LC way of indexin) then use these 2 fields on LC sorts. If we leave this to each library we may have problems(or do we?) |
| 07:30 | thd | paul: The design I developed with kados to support complete frameworks allowed preservation of any data that started in the record while providing just a carefully chosen set of subfields to be used for editing if it was not already present in the record. |
| 07:30 | paul: I also went back to more minimising than what you had seen. | |
| 07:33 | paul: With a little extra work to support any adding subfields as needed at the time of record editing the default subfields present can be extremely small. | |
| 07:34 | paul: Will you be committing the IPT frameworks or an even more complete version? | |
| 07:34 | paul | thd: it's not planned |
| 07:35 | (+ I made nothing yet to use your improvements on framework structure) | |
| 07:37 | thd | paul: so you are planning to commit some frameworks with some more fields and subfields than the existing frameworks but less than what I PT has? |
| 07:37 | paul | no, I plan to do nothing. |
| 07:37 | thd | paul: :) |
| 07:38 | paul: ok, I will plan something for your benefit then if you have no plan :) | |
| 07:39 | paul | :) |
| 07:39 | thd | paul: I want to be certain that UNIMARC keeps up with recent improvements for MARC 21. |
| 07:42 | tumer: yu are trying to sort LC call numbers by dividing the leading letter class from the numeric and later parts of the classification both of which may start together in 050 $a? | |
| 07:42 | s/yu/you/ | |
| 07:42 | tumer | thd:yes I am doing that |
| 07:44 | thd | tumer: there are some subtler issues about LC classification sorting but let me address the question that you just asked. |
| 07:44 | tumer | thd: I have the script doing it on my system. Currently I am using 090$a and 090$b to hold these values. But to commit it I need some advice |
| 07:45 | thd | tumer: you are looking for a good place to store those values which may or may not be 090 $a $b. Is that your question? |
| 07:46 | tumer | thd:yes. anddo they have to be pre-programmed or left to the library to decide? |
| 07:50 | thd | tumer: 090 is a poor choice for Koha to use altogether because that is used by many libraries as the place to store LC call numbers in the world's largest library union catalogues. |
| 07:50 | tumer | thd: but we already have biblionumber in there |
| 07:52 | thd:Are we to change biblionumber to somewhere else at 3.0? | |
| 07:52 | paul | tumer: biblionumber can be anywhere. |
| 07:52 | it's in 090 by default. | |
| 07:52 | thd | tumer,: yes, blame NPL for not thinking ahead. It could easily be changed because it is not hard coded so do not hard code 090. However I have not selected a better place but merely recommended converting standard 090 usage to 09o with the letter 'o' as a temporary measure. |
| 07:53 | tumer | paul: it is hard coded I thought! |
| 07:54 | thd | tumer: it is only set by the setting of the bibliographic framework which I had just been discussing with paul |
| 07:54 | tumer | OK sorry not hard coded.:( |
| 07:55 | thd: all I am asking is we put it in at a place in the framework as default and let the user change it if they know what they are doing | |
| 07:55 | thd | tumer I have created a comprehensive bibliographic framework for MARC 21 which is not yet in CVS. I could email it to you before I am liable to commit it. |
| 07:55 | tumer: yes I am looking now. | |
| 07:56 | tumer | thd:thanks |
| 07:57 | thd | tumer my default bibliographic framework currently has the following default values for 090. |
| 07:57 | -- Original Record ID Field/Subfields | |
| 07:57 | -- INSERT INTO `marc_tag_structure` VALUES ('090', 'KOHA DATA', 'KOHA DATA', 1, 0, '', ''); | |
| 07:57 | -- INSERT INTO marc_subfield_structure VALUES ('090', 'a', 'Koha Itemtype (NR)', 'Koha Itemtype (NR)', 0, 0, NULL, -1, NULL, NULL, '', NULL, '', NULL, NULL); | |
| 07:58 | -- INSERT INTO marc_subfield_structure VALUES ('090', 'b', 'Koha Dewey Subclass (NR)', 'Koha Dewey Subclass (NR)', 0, 0, NULL, -1, NULL, NULL, '', NULL, '', NULL, NULL); | |
| 07:58 | -- INSERT INTO marc_subfield_structure VALUES ('090', 'c', 'Koha biblionumber (NR)', 'Koha biblionumber (NR)', 0, 0, 'biblio.biblionumber', -1, NULL, NULL, '', NULL, '', NULL, NULL); | |
| 07:58 | -- INSERT INTO marc_subfield_structure VALUES ('090', 'd', 'Koha biblioitemnumber (NR)', 'Koha biblioitemnumber (NR)', 0, 0, 'biblioitems.biblioitemnumber', -1, NULL, NULL, '', NULL, '', NULL, NULL); | |
| 07:58 | -- Current Record ID Field/Subfields | |
| 07:58 | INSERT INTO `marc_tag_structure` VALUES ('090', 'SYSTEM CONTROL NUMBERS (KOHA)', 'SYSTEM CONTROL NUMBERS (KOHA)', 1, 0, '', ''); | |
| 07:58 | INSERT INTO `marc_subfield_structure` VALUES ('090', 'a', 'Item type [OBSOLETE]', 'Item type [OBSOLETE]', 0, 0, NULL, -1, NULL, NULL, '', NULL, -5, '', '', ''); | |
| 07:58 | INSERT INTO `marc_subfield_structure` VALUES ('090', 'b', 'Koha Dewey Subclass [OBSOLETE]', 'Koha Dewey Subclass [OBSOLETE]', 0, 0, NULL, 0, NULL, NULL, '', NULL, -5, '', '', ''); | |
| 07:58 | INSERT INTO `marc_subfield_structure` VALUES ('090', 'c', 'Koha biblionumber', 'Koha biblionumber', 0, 0, 'biblio.biblionumber', -1, NULL, NULL, '', NULL, -5, '', '', ''); | |
| 07:58 | INSERT INTO `marc_subfield_structure` VALUES ('090', 'd', 'Koha biblioitemnumber', 'Koha biblioitemnumber', 0, 0, 'biblioitems.biblioitemnumber', -1, NULL, NULL, '', NULL, -5, '', '', ''); | |
| 07:59 | tumer sorry I guess that was a little too much for IRC it does not look bad in VIM with an non text wrapping view. | |
| 08:00 | tumer | thd: well it seems you have used a and b and left c & d intact |
| 08:01 | thd | tumer: well that seems to show that $a and $b are obsolete. I believe that they had once been defined for NPL and then that was changed. I think what you want though is what I put in 942. |
| 08:02 | tumer | thd:OK |
| 08:02 | thd | tumer yes this is good ... |
| 08:02 | tumer | I keep losing connection |
| 08:03 | thd | tumer why is that? |
| 08:03 | what is the cause of your connection loss? | |
| 08:03 | tumer | thd:new to IRC I think |
| 08:03 | thd | here comes some SQL with comments ... |
| 08:04 | kados | hi tumer |
| 08:04 | tumer | hi kados |
| 08:04 | kados | hi thd |
| 08:04 | thd | -- Current primary biblioitems Field/Subfields |
| 08:04 | INSERT INTO `marc_tag_structure` VALUES ('942', 'ADDED ENTRY ELEMENTS (KOHA)', 'ADDED ENTRY ELEMENTS (KOHA)', 0, 0, '', ''); | |
| 08:04 | INSERT INTO `marc_subfield_structure` VALUES ('942', 'a', 'Institution code [OBSOLETE]', 'Institution code [OBSOLETE]', 0, 0, '', 9, '', '', '', NULL, -5, '', '', ''); | |
| 08:04 | INSERT INTO `marc_subfield_structure` VALUES ('942', 'c', 'Item type', 'Item type', 0, 1, 'biblioitems.itemtype', 9, 'itemtypes', '', '', NULL, 0, '', '', ''); | |
| 08:04 | INSERT INTO `marc_subfield_structure` VALUES ('942', 'j', 'Location (call number prefix code)', 'Location (call number prefix code)', 0, 0, 'biblioitems.classification', 9, '', '', '', NULL, 0, '', '', ''); | |
| 08:04 | INSERT INTO `marc_subfield_structure` VALUES ('942', 'k', 'Classification base (DDC to decimal or LCC letter class padded after single letter classes with trailing 0', 'Classification base', 0, 0, 'biblioitems.dewey', 9, '', '', '', NULL, 0, '', '', ''); | |
| 08:04 | INSERT INTO `marc_subfield_structure` VALUES ('942', 'l', 'Classification subclass (DDC after decimal or LCC number after letters', 'Classification subclass', 0, 0, 'biblioitems.subclass', 9, '', '', '', NULL, 0, '', '', ''); | |
| 08:04 | pierrick | hi kados |
| 08:04 | thd | hello kados |
| 08:04 | kados | morning pierrick |
| 08:05 | pierrick | chris upgraded Bugzilla to 2.20.1 :-) |
| 08:05 | kados | w00t! |
| 08:06 | tumer | thd: yes thats what I wanted. Waiting for your e-mail tgaripneu.edu.tr |
| 08:06 | paul | (hello kados) |
| 08:06 | thd | tumer: I have suggested 942 $j and $k with suggestions about usage for your purpose. |
| 08:07 | kados | hi paul |
| 08:07 | tumer | thd: what other subtler issues with LC? |
| 08:11 | kados: do you know that this new M:F:X does not convert all the letters to UTF-8. at least 2 turkish chars. | |
| 08:11 | thd | tumer: one thing s that the classification number can have elements past the decimal point after the letter class which can cause problems with sorting. Even letters are sometimes present in the classification part before the cutter. |
| 08:11 | kados | tumer: are those MARC-8 encoded turkish chars? |
| 08:12 | tumer | kados:yes |
| 08:12 | thd | tumer: Also the classification hierarchy is not strictly numeric after the letter class. |
| 08:12 | kados | tumer: the mapping is provided by LOC |
| 08:12 | tumer: we must investigate whether they can update it | |
| 08:12 | tumer | thd:no problem if you pad with 0's and sort textually |
| 08:13 | kados | tumer: i also found some native alaskan chars it doesn't handle |
| 08:14 | tumer | kados:LOC web sýte has the chars defined. Like the one I just used |
| 08:14 | thd | tumer: yes much padding required for the best proximate sort. |
| 08:14 | kados | tumer: ok, so we need to tell the maintainers to update M::F::X |
| 08:14 | tumer: I will do this | |
| 08:14 | tumer | thd:If we do too much padding zebra slows down on updates |
| 08:15 | thd | tumer: the fine detail of what has precedence when it matters can only be seen by a detailed examination of each of the various classification schedules. |
| 08:16 | tumer | thd: I'll commit something and see what you think |
| 08:17 | kados | tumer: a comment about your recent commit to HEAD |
| 08:18 | tumer: unfortunately, MARC::Record does not change the actual encoding of the record when you specify ->encoding() | |
| 08:18 | tumer | which one. I had a big car accident and in a bit of shock:( |
| 08:18 | kados | oh no! |
| 08:18 | are you ok? | |
| 08:18 | thd | tumer: my recommendation for all such performance issues is that you create yet another subfield to store a numeric index number so that the calculation has already been done. |
| 08:18 | tumer | Some 2 legged bug tried to squash me. Turned over with the car. I'am OK |
| 08:19 | kados | yikes |
| 08:19 | tumer: the commits I'm speaking of: | |
| 08:19 | + $record->encoding('UTF-8'); | |
| 08:19 | and in Biblio.pm: | |
| 08:19 | + #Change MARC Leader to UTF-8 incase user did not set it.New M::F::XML is | |
| 08:19 | +sensitive to this | |
| 08:19 | + $record->encoding('UTF-8'); | |
| 08:20 | I agree 100% if you suggest that MARC::Record _should_ be converting the charset | |
| 08:20 | thd | tumer: The index number number or rather sort number need not be numeric but simply has incorporated all the padding calculations into it. |
| 08:20 | kados | tumer: but in fact, all that does is change leader position 9 |
| 08:20 | tumer | kados: this one makes sure that the leader of marc record is changed to saying that it is UTF-8. Necessary when moving from 2_2 to 3 |
| 08:21 | kados | tumer: however, a better way is to do this: |
| 08:21 | tumer | kados:The new M:F:X requýres this or it assumes MARC-8 even if the record we created is UTF-8 |
| 08:21 | thd | tumer: Do the CPU intensive work in a batch process whenever and store a value so that there is much less work to do at query time. |
| 08:21 | kados | tumer: my $xml = MARChtml2xml(\@tags,\@subfields,\@values,\@indicator,\@ind_tag); |
| 08:21 | tumer: my $record=MARC::Record->new_from_xml($xml,C4::Context->preference('TemplateEncoding'),C4::Context->preference('marcflavour')); | |
| 08:22 | tumer | thd: thats why I'll add 2 more fieds to bibioitems to hold these vaues |
| 08:22 | kados | tumer: this will change the leader position _AND_ encode the record correctly |
| 08:23 | tumer: sorry, my paste above is incorrect | |
| 08:23 | my $xml = $record->as_xml; | |
| 08:24 | my $newrecord = MARC::Record->new_from_xml($xml, C4::Context->preference('TemplateEncoding'),C4::Context->preference('marcflavour')); | |
| 08:24 | tumer | kados: I'seen that |
| 08:24 | thd | tumer: You need two subfield for the sort but maybe even forming a single value in advance from those two in yet another subfield to use for sorting at query time will be much faster for queries. |
| 08:24 | kados | in that case, $newrecord has proper leader AND encoding |
| 08:24 | in the other case (where just ->encoding() is used), the leader is lying about the encoding which can be very bad | |
| 08:25 | tumer | thd: I tried that but a 25 digit long letter or number slows zebra sorting veeeery much |
| 08:26 | thd | tumer: how do tow values to sort from at query time have an advantage on that? |
| 08:27 | tumer | kados: I'll look into this |
| 08:27 | kados | tumer: you will need to create a new systempreference |
| 08:27 | tumer: if you haven't done so already | |
| 08:27 | tumer: called 'TemplateEncoding' | |
| 08:27 | tumer | thd:I presort on 2 fields and call 2 fields sorted |
| 08:27 | kados | tumer: which can store 'UTF-8' |
| 08:27 | tumer: it is also used in the tempaltes | |
| 08:27 | tumer: (at least in rel_2_2 where I have been experimenting with this idea) | |
| 08:28 | tumer | kados: and only 'UTF-8' |
| 08:29 | kados | tumer: my idea is to make sure that Koha converts from 'MARC8' to UTF8 _before_ a record enters the collection |
| 08:29 | tumer: so internally, everything is utf-8 | |
| 08:29 | thd | tumer: i guess I miss something about what it means to presort two fields over presorting one field created from the two fields |
| 08:29 | kados | tumer: but if we are missing mappings in MARC::Charset, we will have to update it |
| 08:30 | tumer: (if you can figure out how MARC::Charset works perhaps you could add them? :-)) | |
| 08:30 | tumer: (I've not had a close look yet, but hope to later this week) | |
| 08:32 | tumer | kados:exactly right. But pre 3.0 data is iso8859. updating database we change everything to utf8. Call MARCgetbiblio you have a record with utf8 data and wrong leader. I was merely trying to correct that problem. Before we do anything else we have to run ->encoding('UTF-8') on all records and update and create zebra etc. |
| 08:33 | kados: I already looked MARC:charset it is a 350M big file and scary :) | |
| 08:34 | kados | tumer: (yes it is scary) |
| 08:34 | tumer: all you are doing with ->encoding('UTF-8') is updating the leader | |
| 08:34 | tumer: you are not converting the encoding | |
| 08:34 | tumer: a better way is to actually re-encode the records as I posted above | |
| 08:35 | tumer: the above code fixes both the leader and the encoding | |
| 08:35 | tumer: (though I agree that my expectation of ->encoding() would be to also change the records, but in fact, all it does is change the leader) | |
| 08:35 | tumer | kados: case dismissed:) |
| 08:36 | kados | tumer: we could fix MARC::Record so that ->encoding() also fixes encoding |
| 08:36 | tumer: that would be ideal :-) | |
| 08:37 | tumer | kados: we have bigger issues I believe:) |
| 08:37 | kados | tumer: which? |
| 08:38 | tumer: ahh, yes, we can get by without modifying the behaviour of ->encoding() by using as_xml() and new_from_xml(UTF-8) | |
| 08:38 | tumer | kados: I am playing a lot with zebra. Performance issues etc. |
| 08:38 | kados | tumer: really! |
| 08:38 | tumer: could you post your discovery to koha-zebra? | |
| 08:39 | tumer | kados: creating more than 4 sorts slowed down update times and created problems with me. |
| 08:39 | kados | wow |
| 08:39 | tumer: you're running on windows, right? | |
| 08:39 | i wonder if that's the problem | |
| 08:39 | tumer | kados:yes |
| 08:40 | kados: it could be! | |
| 08:40 | kados | so unstable a platform |
| 08:40 | tumer | but unfortunately so popular |
| 08:41 | kados | IMO you could very quickly learn some linux skills and convert to linux for your Koha servers |
| 08:41 | it would save money in licenses and would be more stable | |
| 08:41 | slef | even quicker if we ever get koha.deb |
| 08:41 | kados | slef++ |
| 08:41 | tumer | I have to keep on windows cause the university platfor is Windows |
| 08:42 | slef | I've got a new server which should help test that... just need to bring it online :-/ |
| 08:42 | kados | nice |
| 08:42 | slef | tumer: ah, the "you may only use a hammer, no matter what tool is needed" approach |
| 08:49 | owen | I saw my doctor using a Windows tablet PC running an IE-based web app. I wondered what it was and whether it was cross-browser compatible |
| 09:00 | thd | tumer: I sent you them message for the MARC 21 bibliographic framework |
| 09:01 | kados: I have had a syntax error from your eval usage in afognak2koha.pl | |
| 09:02 | paul | what is afognak2koha.pl ? |
| 09:03 | kados | paul: just a MARC::Record script that adds holdings data to a batch of MARC records |
| 09:03 | thd | paul: that is a migration script that I have been modifying for one of Liblime's customers |
| 09:06 | kados: I have not really looked properly at the issue for the eval usage. I can just borrow some code from you modification of bulkmarcimport.pl which does at least work although the structure is different because only MARC data is being added in that case. | |
| 09:17 | tumer | kados: are you here |
| 09:18 | kados | tumer: yes ... see the private message i sent you? |
| 09:18 | or am I sending it to the wrong person? :-) | |
| 09:21 | pierrick | can someone explain to me the database model on acquisitions? I don't understand the necessity of aqbasket :-/ |
| 09:22 | paul | pierrick: why ? |
| 09:22 | 1 aqbasket can contain X aqorders. and some infos in aqbasket are only here. | |
| 09:22 | so the table can't be dropped I think | |
| 09:23 | pierrick | an aqorder can contain only one biblio? |
| 09:24 | paul | 1 order is for 1 biblio, right. |
| 09:24 | it's the "order line" | |
| 09:24 | pierrick | so one basket has several order lines |
| 09:24 | paul | yep |
| 09:25 | pierrick | why on earth isn't aqorder called aqbasketline or aqbasket_item? ;-) |
| 09:25 | paul | ask katipans ;-) |
| 09:26 | I must add that in koha 1.x, aqbasket did not exist & all basket-related lines were duplicated in aqorder | |
| 09:26 | I've added aqbasket in 2.2, to add some DB consistency | |
| 09:27 | pierrick | OK, I understand, thank you paul |
| 11:34 | owen | Did Bugzilla get upgraded? |
| 11:34 | kados | yep, chris did it last night |
| 11:35 | owen | It's got no style :( |
| 11:35 | kados | heh |
| 11:52 | owen | kados: would you say this bug has been fixed by your recent changes? http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=1030 |
← Previous day | Today | Next day → | Search | Index
