← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 15:19 | kados | thd-away: you around? |
| 15:20 | thd-away: yay | |
| 15:20 | thd: I'm gonna forward you a couple emails that will make you smile | |
| 15:20 | thd | kados: I am here |
| 15:21 | kados | thd: you haven't seen my response to the Tag 880 thread yet right? |
| 15:21 | thd: the one where I provide a complete solution? | |
| 15:22 | thd | kados: I have not even seen breakfast yet |
| 15:22 | kados | (I think was was held up by the mailing list because it had too many recipients, and I sent it after chris had left so he couldn't approve it) |
| 15:22 | hehe | |
| 15:22 | I just sent it to you | |
| 15:22 | you'll be pleased I think ... let me know | |
| 15:25 | however, I have found a bug in the MARC editor | |
| 15:26 | and my fix for it created yet another bug | |
| 15:53 | thd | kados: I am pleased |
| 15:54 | kados: I guess I should subscribe to the koha-win32 list. That seems to be where all the interesting discussion is. | |
| 15:55 | kados | thd: well ... it's on the koha list too ... just hasn't arrived yet |
| 15:55 | thd: (hasn't arrived on the win32 list either ...! | |
| 15:55 | thd: (our mailing lists are dog slow) | |
| 15:56 | thd | kados: Pinyin is the only romanisation form currently approved by LC. |
| 15:56 | kados | thd: who cares |
| 15:56 | thd: it's definitely not the only one used | |
| 15:56 | thd: :-) | |
| 15:57 | thd: and our approach blows LOC out of the water :-) | |
| 15:57 | thd | kados: interoperability and record exchange care |
| 15:58 | kados: Those of us with no knowledge of Chinese hope to find records with some common shared Roman access points so we can at least look at the pictures in the books. | |
| 15:59 | kados: the pictures are always in English | |
| 15:59 | :) | |
| 16:00 | kados | thd: my record had pinyin it it :-) |
| 16:01 | thd | kados: Steven seems to have missed out on the Wade-Giles to Pinyin coversions done by OCLC, RLG, and whomever else. |
| 16:01 | kados | thd: I also recommended that she continue with the 880 technique |
| 16:01 | thd: as Koha could easily support interpreting $6 at some point in the future | |
| 16:03 | thd | kados: Of course, it was nice to know from David Bigwood about de-transliteration programs but I want my Roman access points so I can find the pictures :) |
| 16:04 | kados | yep, and those are in there |
| 16:07 | thd | kados: you could have multiple transliterations even if disparaged by LC using the repeatable alternate form of fields with $6 as you suggested or almost suggested. |
| 16:12 | kados: Have you tried my suggestion about groups of virtual libraries for different circulation rules in your current migration? | |
| 16:13 | kados | no |
| 16:13 | thd: that's not quite what I suggested | |
| 16:13 | thd: did you look at the second record I listed in that email? | |
| 16:15 | thd | kados: I only looked at the record from last night and noticed everything was fixed except that the 245 subfield order had been stuck at an incorrect order but there is no easy means of fixing that just yet. |
| 16:16 | kados | thd: read the email carefully and look at both examples I provided |
| 16:16 | thd: you'll see with the second example the power of my idea | |
| 16:16 | thd | kados: meaning $6 was not the first subfield in 245 for the record from last night. |
| 16:36 | kados | thd: right, subfield order is a problem |
| 16:45 | thd | kados: I had understood your usage of 9XX without looking at the record, although, seeing it in practise it is a potential way to exhaust 9XX in reserving usage for transliteration where most standard fields could have $6. Yet, anything to see comments like this one must be good. "This is hot! Support for Koha is totally better than commercial products." |
| 16:46 | kados: Granted, that quote is from one of the already converted. Even Steven is a member of the already converted or he would not even be giving any attention to Koha. | |
| 17:04 | kados: let me know if you and some candidate library are ever brave enough to attempt to implement my suggestion about preserving circulation rule independence from media type. The workaround seems only a little more awkward to me than the problem of needing to manage circulation rules in the first place. (I prefer non-circulating libraries with no theft problem.) My suggested workaround merely puts the circulation rules in direct view when | |
| 17:06 | creating items rather than disguising them as a media type that the never were. | |
| 17:19 | kados: I do not understand why the order of subfields changes for some fields and not others except that paul added some new dirty code in Biblo.pm to treat some fields like title differently for overcoming bugs he was sometimes seeing and he had failed to trace and squash at their origin. | |
| 17:19 | kados | thd: there's lots of dirty code in Biblio.pm |
| 17:19 | thd: I'm actually doing some cleaning right now | |
| 17:19 | thd: and fixing that problem is definitely on my list before 2.2.6 | |
| 17:20 | thd: i want a bug-free MARC editor that doesn't save blank fields and allows for subfield repeatability | |
| 17:20 | thd | kados: However, that really makes it seem that this problem is related to the original problem that paul had failed to trace. |
| 17:35 | kados: sometime during the period after the 2.2.4 release to the 2.2.5 release some code was changed in Biblio.pm that may be the common source of multiple problems. | |
| 17:58 | kados: nevermind, I may have made a general assertion that is liable to be true in any case; but one partial fix I had committed to HEAD during 2.2.4 but not committed to rel_2_2 until after 2.2.5 never worked any better under 2.2.4 because it was always only a partial fix. | |
| 20:44 | kados | chris: looks like I may have broken addbiblio.pl in HEAD too :/ |
| 20:44 | chris: for some reason, I can find a biblio in cataloging but when I go to edit it, it comes up blank | |
| 20:48 | also, this is going to sound crazy, but I think zebra is actually slower than mysql at importing :-) | |
| 20:49 | chris | doesnt sound crazy at all |
| 20:49 | im well prepared to believe that | |
| 20:49 | kados | right |
| 20:50 | well I like my commits today, but either hdl or I broke modifying items | |
| 20:50 | chris | right, cos it was working the other day |
| 20:50 | kados | (I see he moved somethings around, so I'm not so sure it was me after all) :-) |
| 20:51 | I added the $Zconn to addbiblio when it calls MODaddbiblioitem | |
| 20:51 | or whatever it's called :-) | |
| 20:51 | chris | so the script is making the connection? rather than i the module? |
| 20:52 | kados | NEWmodbiblio actually |
| 20:52 | is that wrong? | |
| 20:52 | chris | kinda |
| 20:52 | well to my thinking anyway | |
| 20:53 | kados | k ... where should the $Zconn get set then? |
| 20:53 | chris | the scripts should need to know |
| 20:53 | or care where/how the data is stored | |
| 20:53 | should=shouldnt | |
| 20:53 | kados | not inside z3950_extended_services |
| 20:53 | cause presumably you want 1 conn to many commits | |
| 20:54 | and z3950_extended_services only handles one thing at a time | |
| 20:54 | (that makes sense) | |
| 20:54 | chris | i dont like/want to see any $dbh or $Zconn in the scripts |
| 20:54 | kados | ok ... so how do they get set then? |
| 20:54 | chris | in modules |
| 20:55 | kados | at the top of the module? |
| 20:55 | will that cover any use of it in the module? | |
| 20:55 | chris | could do, or just in whatever function needs them |
| 20:55 | if you do it right, it wont make a new connection unless it needs to | |
| 20:55 | kados | hmmm |
| 20:56 | chris | littering connections around in scripts = horrible horrible mess under mod_perl |
| 20:56 | kados | what do you mean by 'right'? |
| 20:56 | I think the only Zconn in a script is in addbiblio.pl | |
| 20:56 | chris | yep, but i dont see why it needs to be |
| 20:57 | kados | ok |
| 20:57 | I'll try without it | |
| 20:57 | well, first I'll try bulkmarcimport without it | |
| 20:57 | (notice that addbiblio has a dbh :-)) | |
| 20:57 | chris | yes i dont like that either |
| 20:58 | scripts should handle input and output | |
| 20:58 | all the logic should be in modules | |
| 20:58 | kados | hmmm ... this foils my z3950_extended_services function |
| 20:58 | so where does Zconn get set in Biblio.pm? | |
| 20:58 | at the top? | |
| 20:58 | chris | just open it in the function you need it in |
| 20:59 | if its using C4::Context its not going to open a new one | |
| 20:59 | just give you an already open one | |
| 20:59 | kados | ok, I"ll try that |
| 21:00 | chris | if we have logic in the scripts .. it gets much trickier if we want to build a gtk version .. or an ajax version etc |
| 21:00 | if all the logic is in modules, then it makes changing interfaces a lot easier | |
| 21:01 | i dont like all these subs in addbiblio.pl either | |
| 21:02 | in Biblio.pm | |
| 21:03 | you could have | |
| 21:03 | our $Zconn=C4::Context->Zconn; | |
| 21:03 | and then use that throughout the module | |
| 21:03 | not having to pass it round | |
| 21:03 | that might be the nicest way to do it | |
| 21:04 | kados | yea, just adding it to the z3950_extended_services gives me: |
| 21:04 | ZOOM error 109 "Database unavailable" (addinfo: "kohatest") from diag-set 'Bib-1' | |
| 21:05 | except within z3950_extended_services | |
| 21:06 | hmmm | |
| 21:06 | so if I use the 'our', I'm probably gonna want all those $Zconn's back in there, eh? | |
| 21:06 | chris | probably yep :) |
| 21:06 | kados | damn :-) |
| 21:06 | chris | i actually think its better not to |
| 21:07 | i think its much better to request a connection when we need it | |
| 21:07 | kados | ok |
| 21:07 | chris | rather than passing one around |
| 21:07 | passing one around means we have to check it each time before we use it anyway | |
| 21:07 | kados | ok, so I'll commit this, though it's not working |
| 21:07 | so you can have a look | |
| 21:07 | chris | cool |
| 21:08 | im gonna head out for a bit, but sunday evening tv sucks so ill have a look then | |
| 21:08 | kados | hehe |
| 21:08 | k ... thx | |
| 21:13 | chris | oh before i go, well done on the framework stuff yesterday |
| 21:13 | ill do a blog entry on it tonight | |
| 21:25 | kados | thanks :-) |
| 22:26 | thd: whenever you're around ... you should know that as of version .8 of MARC::File::XML, conversion from MARC-8 to UTF-8 is automatic | |
| 22:27 | thd: we have Mike Rylander from PINES to thank for that | |
| 22:27 | chris: when you start watching sun evening tv, let me know, I need a table def for that missing table in Fines.pm if possible | |
| 22:52 | that would cause a stir :-) | |
| 22:56 | thd | kados: well thank you Mike Rylander |
| 22:57 | kados: I assume Mike has not addressed the same issue for UNIMARC encodings which are not MARC-8 | |
| 22:59 | kados: what was meant in your humorous comment relating to Ebay? I missed the context. | |
| 23:00 | kados: OK very funny, I understand now. :) |
← Previous day | Today | Next day → | Search | Index