IRC log for #koha, 2006-06-17

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
13:10 thd owen: My test showed that there is no JavaScript functionality in the add repeatable field link for Firefox 1.07
13:11 owen Wow...so it just fails silently?
13:12 thd owen: I have only a non-JavaScript link to the same page itself with a blank anchor at the end.
13:13 owen Are there any errors in the Javascript Console?
13:14 thd owen: I did not check very extensively.  Let me look now.
13:14 owen It would be very helpful to know any relevant Javascript errors.
13:15 thd owen: This may take a few minutes because most resources are being consumed by a giant system update on my low bandwidth.
13:16 owen No problem.
13:22 thd owen: no error messages and the add field has only a link to the same addbiblio.pl page for the record with a blank page anchor.
13:23 owen You're talking about the little plus sign link after the tag description, right? e.g. 'INTERNATIONAL STANDARD SERIAL NUMBER'
13:24 thd owen: I have this as an example for the link intended to create another ISBN, field 020: http://localhost:8082/cgi-bin/[…]ldbiblionumber=30# .
13:24 owen The link is just a dummy--it's a trigger for a javascript function. So the link itself doesn't matter.
13:25 thd owen: I do no where it always had been actuated previously :) but that is good to check
13:25 s/no/know/
13:25 kados thd: i will have a couple hours later today to troubleshoot these issues
13:25 thd: i also discovered some major bugs in the new editor
13:27 thd kados: in another three or four days or so I will have updated Firefox to version 1.5 along with just about everything else on my system
13:29 kados: This morning paul suggested to me that he was supposing the DOM had changed in some significant way between Firefox 1.0X and 1.5 so that the means for accessing the same part of the document in one version would not work in the other version.
13:31 kados: I suppose that could be possible but that did not seem to be a reasonably likely account of the difference without actually knowing how the code changed and how it worked.
13:32 owen Anyway, the problems kados is seeing are much more than just a javascript issue
13:33 thd owen: yes, I am also skeptical about that as I would have seen only changes in the DOM that provide enhanced methods of access to the document historically.
13:33 dewey okay, thd.
13:34 thd owen: what sort of problems is kados seeing, which are unrelated to JavaScript?
13:36 owen kados noticed and I confirmed that information was getting lost when saving records after editing.
13:37 kados also saw a problem with the "duplicate record" function from the catalog
13:39 kados it's possible paul changed something in the scripts that broke MARC21
13:39 I'm planning to spend a few hours on this later today
13:42 owen kados: Did you mean that when you clicked the 'duplicate record' button the record that opened was incomplete and/or empty?
13:42 kados no ...
13:42 it's when I go to save it
13:42 and it asks me if it's a duplicate
13:42 of the original record
13:42 (which it is of course)
13:42 that screen has a mangled record on it
13:43 since all of this was working in rel_2_2 right before paul made his changes
13:43 I can only assume something he did is responsible ;-)
13:43 thd I have now tested with standards compliant Opera 8.52 and observed the same conditions as with Firefox 1.07 exactly.
13:46 owen thd: the clone tag function? It works fine for me in Opera 8.54 (Windows)
13:47 thd owen: maybe I need 8.54 instead of 8.52 (GNU/Linux)
13:48 owen Again, it seems unlikely that it's a browser version issue
13:48 Are you sure javascript is turned on?
13:48 thd owen: actually Linux versions are usually a little behind.
13:48 owen: yes
13:50 owen: yes now I am certain
13:50 kyle hey all
13:50 owen Bummer, that would have been an easy fix ;)
13:51 thd hello kyle
13:51 kyle hello thd : )
13:51 fyi, I created a project on sourceforge called koha-tools.
13:51 It has my firefox extension, reports generators and other stuff in it.
13:52 thd owen: there should however, be a standard warning message that is visible if JavaScript is not turned on for pages that need JavaScript to function.
13:52 kyle The perl module for user simulation, and a marc tool for fixing 245 fields.
13:53 thd owen: Very few pages should actually need JavaScript
13:53 all pages needing JavaScript should be in the intranet only.
13:54 owen few pages should /require/ javascript, but addbiblio is the exception, because of the complexity it demands
13:54 thd kyle: are your 245 fields broken?
13:54 kyle extremely
13:55 many that should have an indicator > 0 don't, and some that *should* have 0 have some other number.
13:55 thd owen: Perl is much better scripting tool for managing complexity.
13:55 kyle our current ILS only stores marc data, but doesn't use it.
13:56 it has it's own scheme for ordering search results.
13:56 thd However, that would be server side.
13:56 owen thd: true, but for an advanced editor to be efficient, it needs to be fast. addbiblio is too large a page to continually refresh as you're editing a record.
13:57 thd owen: yes, I understand the reason and agreed reluctantly that it must be JavaScript
14:00 owen: there is yet another model possible with small pages of one tab at a time being sent where most everything stays on the server.
14:01 owen: such a model could have the same resource consumption as the current JavaScript model.
14:02 owen: especially as every plugin is a server side call.
14:05 kyle: Does your ILS stores record data in SQL or some other database model but only reads MARC at the time of record creation?
14:05 s/record creation/original record creation/
14:05 kyle thd: it uses a database called Btrieve.
14:06 thd: basically, yes, it only grabs data from the MARC record on import, then stores and ignores it.
14:07 thd kyle: Can it export MARC from its own format if the MARC records were gone or would it be just a small subset of MARC.
14:07 ?
14:09 kyle: actually, as I remember, your database does not export its own data like most similar databases without a fee being paid.
14:10 kyle thd: we can get MARC data out, but it stores a marc record for each item in the database, 5 copies of a book = 5 identical marc records.
14:11 thd: I spent an incredible amount of time writing a program to fix it so that koha sees one biblio with multiple items.
14:14 thd kyle: was your incredible amount of time spent to fix Koha so that it would use the records in the same manner or fixing your MARC records so that Koha could use them.
14:14 ?
14:15 kyle: I mean did you change Koha to accommodate your records as they were or did you attach all your holdings to a single record before import into Koha?
14:16 kyle thd: we could have used the records as they were, but koha would have showed five separate instances of said book, instead of one book with five items attached.
14:16 thd: the latter
14:17 thd: actually, what we did was import them into koha as is, then I wrote a program to manipulate the koha database directly to remove the duplicates and readd them as additional items to a single biblio.
14:17 thd: so it will only work on the 2.2 branch of koha.
14:17 thd kyle: I was wondering if you had added some record deduplication function to Koha itself, about which I had no knowledge.
14:18 kyle: no wonder that took an incredible amount of time :)
14:18 kyle thd: no, I was going to go that route but the processing time would have been astronomical, to the tune of factorial($numberOfMarcRecords)
14:19 thd kyle: yes, that would not be practical for CPU usage in real time
14:20 kyle: I assume that you can now export your records from Koha as individual MARC records with holdings attached?
14:21 kyle thd: that's why I took the route I did. Processing a couple hundred thousand records only takes a few hours with my current program.
14:21 thd: yes, that is correct.
14:23 thd kyle: well you have certainly solved it what would seem to be the difficult way to me but I guess every way requires creating a database of which records are which before merging holdings content.
14:24 kyle: and Koha 2.2 provided that.
14:24 kyle thd: yeah.
14:27 thd kyle: your script may be tied to Koha 2.2 but if you would need to do something similar in future, a similar thing could be done more easily with Zebra and MARC::Record than doing it mostly in SQL as I imagine that you had done.
14:30 kyle thd: yes, I imagine so. The problem being that I have no idea how to manipulate data in Zebra.
14:30 thd kyle: you export it first and manipulate it in MARC record.
14:31 s/MARC record/MARC::Record/
14:31 kyle thd: what I would like to write is a marc "scrubbing" program that would look at a marc file's isbn or other identifier, download the corrosponding marc file from LOC, and fill in any missing fields.
14:32 thd kyle: I have some code to do just that.
14:32 kyle thd: that's great, is it available somewhere?
14:34 thd kyle: I would be happy to share it but it needs a little more work to avoid false matches.  Maybe you could hire LibLime to hire me to improve the code.
14:36 kyle thd: I wish I had the clout to do that, but John's still waiting for Zebra to be fully integrated into koha, I don't think I'll be talking him into funding another project anytime soon ; )
14:37 thd kyle: It currently consists of an LWP Perl script that drives special hidden features in a PHP/Yaz client that I had started before Perl::Zoom was ready.
14:38 kyle thd: that's sounds nifty.
14:40 thd kyle: It need not cost much because I am very cheap but have John talk to kados.  I do want to share the code but it has no comments and I have changed the PHP/Yaz client just recently so that the Perl would need updating at least to communicate the correct variables.
14:41 kyle thd: I'll ask him about it next time I see him. Can't hurt to ask.
14:41 thd kyle: the basic problem is that being confident that you have the same record is much more tricky than you would imagine at first.
14:41 kyle thd: yeah, I can imagine so.
14:42 thd kyle: I am actually desperate for work but I have spent months researching how to do this well so that I can do it well.
14:43 kyle: I am actually disparate for any kind of work so that I am having to do things which keep me from working on Koha.
14:45 kyle: I have tried this for one LibLime customer already so that I do have real experience with matching some very poor quality records and I know all the published research on MARC record matching techniques.
14:46 kyle: Unfortunately, the LibLime customer was anxious to have records quickly so I did manual post processing of a few hundred records to give them results without correcting my script to do it right automatically.
14:48 kyle: the LibLime customer did not even have MARC data so, obviously that made the matching more difficult when sometimes the only field was a title field with a couple of words.
14:50 kyle thd: wow, that must've been fun.
14:50 thd kyle: the greatest difficulty with even real records is that no two cataloguers will catalogue perfect ideal matching records for the same material and so you have to match on multiple fields with varying weights and give the records a score to know that you have a good automated match.
14:51 kyle thd: that makes alot of sense
14:52 thd kyle: yes lots of fun especially as bugs in the Koha MARC editor have delayed the manually making the resulting records perfect.
14:55 kyle: also ISBNs, LCCNs or other standard identifiers alone have a 15 to 20 percent error rate for having a valid match if they were entered manually.
14:57 kyle: and then even valid numbers will match records which are related but not identical material.
14:59 kyle: a collection of weighted key fields can yield very accurate matches for almost all records with a large enough set of targets.
15:00 kyle thd: that's interesting. However, I've got to do. Talk to you later.
15:01 thd kyle: furthermore my Z39.50 client identifies the most complete record with multiple matching records and will give you the record with the complete table of contents and most subject headings etc.
15:03 kyle thd: talk to you later.
15:03 bye all
15:03 thd goodbye kyle
16:20 hdl kados around ?
16:20 thd ?
16:20 dewey thd is probably just dying to tell you but I fear that if I reveal all I will lose the ability to obtain funding for a business myself. or skeptical about that as I would have seen only changes in the DOM that provide enhanced methods of access to the document historically.
16:21 thd dewey: what silly things you have collected together.
16:21 dewey thd: i don't know
16:21 thd dewey: at least the rest of us can appreciate the humour
16:21 dewey thd: excuse me?
16:22 thd hdl: I am here
16:22 kados: is somewhere, maybe working on the record editor bugs.
16:23 hdl: above
16:23 hdl thd :
16:24 do you know where I could get access to a working current dev on zebra ?
16:24 thd hdl: you mean head is not working so you want a working checkout?
16:25 hdl No.
16:25 I mean I have a demo tomorrow and client would certainly be impressed to see what kados has already up :)))
16:26 thd hdl: you do not mean his zoomopac search forms?
16:26 hdl yes.
16:27 thd hdl: http://zoomopac.liblime.com
16:28 hdl :D
16:28 thx anyway.
16:28 hope you are fine.
16:28 thd you are quite welcome hdl
16:30 hdl: I am ok.  I will be better in a couple of days after a full system update will give me Firefox 1.5 along with other things to use the record editor with fewer bugs.
18:25 dewey: what happened to hewey and louie?
18:25 dewey thd: i haven't a clue
18:26 thd s/hewey/huey/
18:27 dewey: huey and louie are broken.
18:27 dewey OK, thd.
18:27 thd dewey: it is up to you to take good care of the forest.
18:27 dewey ...but it is <reply>...
18:40 thd dewey: take good care of the forest.
18:40 dewey thd: what?
18:41 thd dewey: dewey is to take good care of the forest.
18:41 dewey ...but dewey is an infobot...
18:42 thd dewey: dewey the inforbot is to take good care of the forest.
18:42 dewey OK, thd.
18:43 thd dewey: do you fix spelling errors?
18:43 dewey wish i knew, thd
18:44 russ dewey: spell nessacery
18:44 dewey I can't find alternate spellings for 'nessacery'
18:44 thd dewey: dewey, the infobot, is to take good care of the forest.
18:44 dewey OK, thd.
18:44 thd dewey spell inforbot
18:44 dewey I can't find alternate spellings for 'inforbot'
18:45 thd dewey: what is an infobot?
18:45 dewey an infobot is at http://www.cs.cmu.edu/~infobot
18:46 thd dewey: remember all infobots named dewey must take good care of the forest.
18:46 dewey thd: i'm not following you...
18:47 thd dewey: you do not need to follow me as long as you take good care of the forest.
18:47 dewey thd: i'm not following you...
18:47 thd dewey: exactly, carry on.
18:47 dewey thd: i'm not following you...
18:48 thd dewey: CMU should give you a better parser.
18:48 dewey thd: what?
18:49 thd exactly
02:10 btoumi hi all
02:39 one qustion for all champion
02:39 the deletedborrowers table is a same  that  the borrowers table?
02:41 osmoze hello #koha
02:43 btoumi hi osmoze
02:43 osmoze no champion here :p
02:44 chris yes it should be the same bruno, and when you delete a borrower it should get stored there
02:44 btoumi i think they work too much
02:44 chris because people often go .. oh i didnt mean to delete that, can I get it back
02:45 btoumi i ask u because actually the deletedborrowers table not the same i do the change in updatabase
02:45 and commit
02:45 chris cool that would be good
02:46 btoumi hi chris and ty
03:02 paul hdl around ?
03:37 btoumi :chris around?
03:52 another question for campion
03:53 paul campion is away I think :-D
03:53 btoumi champion
03:53 lol
03:55 actually deletedborrowertable is not correct we have badfield name and useless field but if i modify updatedatabase
03:57 i must do like if i have a koha 2.2.5 database
03:57 isn't it?
03:57 paul pas sûr de bien comprendre la question...
03:57 btoumi je vais la faire en francais parce que la c chaud en anglais
03:58 en fait dans la version actuelle de la base de donnee de koha3.0 la table deletedborrower contient les champs de la table actuelle borrowers plus les anciens champ
03:59 paul ouaip
03:59 btoumi je suis entrain de modifier l'updatedatabase pour que l'on puisse modifier la base d'une version anterieur
04:00 et pas les modidications que l'on doit faire sur la base actuelle de la 3.0
04:00 est ce comprehensible?
04:14 par contre va falloir modifier la base de donnees de la head
04:16 donc je sais pas si c toi :paul ou :chris
04:16 qui allez le faire
04:52 change be doen for updatedatabase
04:52 dewey btoumi: that doesn't look right
04:54 btoumi :nick btoumi_lunch
04:54 nick btoumi_lunch
09:03 bye for all good week end
09:08 paul hello pierrick
09:09 une dernière petite visite ?
09:09 (depuis pfw.ineoms.com)

← Previous day | Today | Next day → | Search | Index

koha1