IRC log for #koha, 2006-02-27

← 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

koha1