IRC log for #koha, 2006-05-25

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

All times shown according to UTC.

Time Nick Message
12:50 owen What does it mean in the 3.0 Roadmap when the notes column in the table says "note" ?
12:52 Tumer has completed a search history feature for the opac?
13:12 kyle hey all, I'm trying to write a script that simulates daily usage (issues and returns only for now), and I can't seem to get C4::Circulation::Circ2::issuebook to work.
13:13 I set the %env var (branchcode, printer, queue) by hand, but I get this error:
13:13 Can't use string ("/dev/lp0") as a HASH ref while "strict refs" in use at /usr/local/koha/intranet/mod​ules/C4/Circulation/Circ2.pm line 839.
13:13 any idea what's going on?
13:15 it makes no sense. Line 829 is:         if ($currentborrower eq $borrower->{'borrowernumber'}) {
13:15 it's not even referencing %env
13:23 kados owen: it means that's the space for a note, but none has been written yet ;-)
13:23 owen: yes, search history feature is complete
13:24 owen In HEAD? I'll have to see if I can get it working on 101
13:24 kados owen: not a chance :-)
13:24 owen: I'm working on getting it up on 100
13:24 owen HEAD's pretty broken right now I take it?
13:24 kados owen: been working on it all day in fact :-)
13:24 owen: yea, but it's improving
13:40 basically we just need to finish merging dev-week code into HEAD
13:41 then we need to merge in all the bug fixes and patches to rel_2_2 into HEAD
13:41 at that point the only difference between rel_2_2 and HEAD will be Zebra + all the newly developed stuff ... but at least the core will be stable
01:58 hdl hi
02:00 pierrick hi hdl
02:17 hdl, where do I find a good documentation of serials in Koha ?
02:19 btoumi hi everybody
02:21 osmoze hello too :)
02:21 btoumi :=)
02:22 russ hi there
02:22 hdl pierrick: what kind of information do you need ?
02:22 pierrick hi russ, btoumi & osmoze
02:22 russ pierrick - not sure if this helps but here are some docs for the serials changes we have just made (they are in final testing with a client, once they pass there they will be committed)
02:23 pierrick hdl & russ: I would like to understand how serials are managed, a functionnal documentation for first
02:23 hdl pierrick: Does online help not help you ?
02:23 pierrick hdl, which one.
02:23 russ http://wiki.liblime.com/doku.p[…]d=kohaserialsspec
02:23 pierrick ?
02:24 hdl online help on a new subscription for instance or on edit page.
02:24 pierrick hdl, there is the kohadocs.org manual, but it says the serials chapter is "to be completed"
02:24 oh sorry, I take a look
02:25 russ pierrick: we also have some documentation prepared, completed with online help
02:25 but i dont have my hands on it at the moment
02:25 i can chase it all up tomorrow when the rest of the crew is back at work
02:25 hdl But if it is with how it is managed with koha tables, you are right, it is not explained.
02:25 pierrick ok russ, thanks
02:52 chris evening
02:53 pierrick evening chris
02:54 russ or chris, do you know when the serials management improvement is planned to be implemented?
02:54 (the one described in Liblime wiki)
02:55 chris its been written and is in testing by one of our clients at the moment
02:55 pierrick great, so it will be an extension for 2.4 ?
02:55 and included in 3.0 ?
02:55 chris yep
02:56 we'll commit it to head
02:58 should be in the next week or so, i havent worked on it, one of the other developers at katipo did it, and it should be some of his first big commits
03:00 as soon as the it passes its testing, we'll get it committed
03:17 ToinS hi all
03:22 chris hi toins
03:22 ToinS chris: how are you ?
03:26 pierrick hi ToinS
03:26 ToinS hello pierrick
03:27 chris good thanks, how are you?
03:28 the importance of using strict
03:28 http://www.perlmonks.org/index.pl?node_id=494927
03:29 ToinS lol
03:32 btoumi hi toins
03:32 ToinS hi btoumi
03:32 btoumi lol
04:52 pierrick:desole je renvoi ca sur la liste
07:10 pierrick is there a dedicated screen for serials in the OPAC?
07:10 (I can't find it so I think no, but let's ask the experts :-)
07:36 hdl pierrick: there is a dedicated link taht leads to collection status.
07:39 pierrick hdl, can you tell me where it is ?
07:42 is it possible to have more than one item for the same serial?
07:42 I mean for example, 2 items of "Le Monde, N°12345"
07:43 "Le Monde" is the collection
07:44 hdl pierrick: opac-serial-issue.pl
07:44 normally, yes, two different barcodes.
07:45 But then you should receive twice (at the moment).
07:48 pierrick URL /cgi-bin/koha/opac-serial-issue.pl was not found on this server.
07:49 hdl cgi-bin/koha/opac-serial-issues.pl?biblionumber=30
07:49 pierrick are the 2 items linked in some way ? Or are they just supposed to have the same serial.serialseq ?
07:49 same problem, I have an error 404, not a 500
07:50 kados hi all
07:50 pierrick hi kados
07:50 kyle hey kados
07:50 kados I've just sent an important email to koha-devel dealing with how to merge changes to Biblio.pm from dev_week and HEAD
07:50 if paul's around, I'd love some feedback on that
07:51 hdl pierrick: same serial.serialseq
07:53 opac-serial-issues.pl is in HEAD directory opac.
07:53 pierrick OK, as long as HEAD is all broken on my computer (due to the new koha.xml I suppose) I can't test
07:54 hdl In rel_2_2 also
07:56 pierrick hdl: you're right, I had made a typo in the URL :-)
07:58 hdl :)
07:59 pierrick is it possible to duplicate a subscription?
08:00 (because I want more than one item per serial issue)
08:01 ... simply be using the same biblionumber, it's quite easy in fact
08:02 hdl :)
08:06 pierrick after testing, with opac-serial-issues.pl I can't see how many items per issue I have. The screen is broken in subscriptions
08:07 (I hope the customer won't have more than 3 subscribtions, I will become hard to read :-/)
08:09 kados pierrick: getting the koha.xml to work is pretty simple
08:09 pierrick: I did mine yesterday
08:13 pierrick kados, I wanted to make it work this morning, but SAX keeps saying there is an encoding issue on a file (I suppose on koha.xml)... I have not much time today, so I'll do it next week
08:30 paul pierrickn hdl, kados & btoumi_away, i'm back on this channel
08:48 kados hey paul ...
08:49 paul hey
08:49 kados if you have a spare moment, please take a look at my mail to koha-devel asking questions about Biblio.pm
08:49 I am hoping to get dev_week merged this week
08:49 but it's a lot of work !
08:52 paul: we don't need to export routines that aren't used outside of Biblio.pm, right?
08:52 paul (on phone)
08:57 pierrick kados, right
08:57 kados, even better, a Perl convention to keep routines "privates" to a module is to precede their name with "_"
08:57 kados we seem to have lost &updateBiblio &updateBiblioItem and &updateItem in HEAD
08:58 pierrick: right, we should start doing that then
08:58 pierrick: I'm ready to completely overhaul Biblio.pm
08:58 pierrick kados, OK, I add this to my coding guidelines draft
08:58 kados pierrick: I'm going to go through every subroutine in there, check where it's used, clean it up, etc.
08:58 pierrick: if you post what you have to the wiki I'll add stuff as I find it
08:58 pierrick great ! That's a huge work.
09:00 kados pierrick: the most difficult part is trying to figure out why things changed the way they did ...
09:00 pierrick kados, I'll do it at the end of the day if I have time to finish my proposal :-/
09:00 kados pierrick: sweet, thanks
09:01 pierrick kados, I've worked a lot on the reservation screen and I've realized that in modules, there are many routines written twice or more (I mean two routines doing the vey same thing)
09:01 kados pierrick: yea, its crazy
09:01 pierrick: I'm not releasing 3.0 until all that junk is cleaned up
09:01 pierrick: :-)
09:04 what I'm doing
09:04 I've got a 'cvsrepos' dir
09:04 with three dirs inside:
09:04 22, 30, dev-week
09:04 each has a koha dir inside with the cvs repo
09:05 so I can go grep -r updateBiblio cvsrepos
09:05 and find all the places in all three trees where a given sub is used
09:05 pierrick of course :-)
09:06 (I prefer using "find . -name "*.p[ml]" | xargs grep -wl updateBiblio", but it's a matter of choice...)
09:06 kados heh :-)
09:06 pierrick using emacs macros is also a good solution to be efficient
09:07 kados I'm confused about why updateBiblio, updateBiblioitem and updateitem are not present in HEAD
09:07 and I don't see any notes in the changelog
09:07 pierrick and you can't study the "cvs annotate"...
09:08 kados paul: do you know?
09:08 what's cvs annotate?
09:08 pierrick ah ah :-)
09:08 let's give it a try on your C4/Biblio.pm :-)
09:08 kados pierrick: remember I'm not a programmer by trade ;-)
09:10 ahh, that's  anice trick :-)
09:11 cvs annotate C4/Biblio.pm |grep updateBiblio
09:11 doesn't help much :(
09:12 pierrick of course, annotate is great for additions, not for deletions
09:12 kados well, if someone removes updateBiblio, they should say they did and why!
09:12 pierrick (and now)
09:14 kados I guess I'm gonna assume those three routines are from koha 1.x and aren't relevant anymore
09:14 they're not used anywhere ...
09:16 pierrick if not used, where is the problem of removing? We should remove any useless routine I guess
09:19 kados yep, doing that
09:19 paul: got another question for you ...
09:19 paul (still on phone, but throw your question)
09:19 kados paul: what do you think of keeping marc-* tables in Koha and allowing a library to choose whether to use zebra or not
09:19 paul: is it too late to consider this option? :-)
09:27 paul kados : i'm back
09:27 kados cool
09:27 paul (in fact, I was here, but skyping with a tunisian contact ;-) )
09:27 kados sweet
09:28 paul to answer your last question : no, it's not too late. even if i'm not sure it's a good solution.
09:28 because keeping marc_*_table is still possible for biblio.pm, it will be quite complex to keep SearchMarc.pm working with all those new features that rocks
09:28 (like CQL...)
09:29 kados ahh ... true
09:29 unless ...
09:29 we have two separate search screens for each ... like we do already
09:29 there's a simple search screen written by chris for CQL
09:29 and the advanced search written by tumer for zebra boolean
09:29 paul maybe that could be somewhere possible.
09:29 kados and the old opac-main.pl and opac-search.pl
09:35 paul about updateBiblio : is there a recent commit from me removing them ? maybe I checked & saw they were useless & removed them in a recent commit, as I made a lot of cleaning.
09:35 let me check...
09:36 mmm... no, I can't see any specific commit about "cleaning code"
09:37 kados I think what we need ... is to define an API for Biblio.pm and Search.pm
09:37 that's step #1
09:37 so what are the operations that we need to support in the API
09:38 for Biblio.pm for instance
09:39 paul I think that the API I had defined for Biblio.pm was quite good. So we could continue with it mostly.
09:40 and that would be very good for compatibility with everything if adding a biblio could just be NEWnewbiblio($dbh,$record,$framework)
09:44 kados paul: the API for 3.0? or 2.2?
09:44 paul it didn't change from me, so it's the same.
09:44 but tumer did some changes i could not investigate yet
09:46 kados paul: why not just call then newbiblio instead of NEWnewbiblio?
09:46 paul because newbiblio was the name for 1.x API, without MARC
09:47 kados so can't we just delete the old one ?
09:47 in 3.0 i don't think we need to have 1.x code still in Biblio.pm
09:47 paul once MARC=OFF will be dead, we will be able to
09:47 kados all MARC=OFF does it hide MARC, it doesn't change what happens behind the scenes ... right?
09:48 paul nope. look at POD of Biblio.pm
09:48 it explain all of this
09:48 ToinS is trying to commit on gna.org with svn since this morning.
09:48 svn co is done, svn add fails.
09:49 kados cool
09:49 ok ... here's from the POD
09:49 * MARC=ON : when MARC=ON, Koha uses a MARC::Record object (in sub parameters). Saving information in the DB means :
09:49        - transform the MARC record into a hash
09:49        - add the raw MARC record into the hash
09:49 * MARC=OFF : when MARC=OFF, Koha uses a hash object (in sub parameters). Saving information in the DB means :
09:49        - store them & update Zebra
09:49        - transform the hash into a MARC record
09:49        - add the raw marc record into the hash
09:49        - store them & update zebra
09:50 I'm a bit confused by this
09:50 steps 2 and three are the same
09:50 but step one in MARC=ON leaves you with a hash, but with MARC=OFF it leaves you with a raw MARC
09:51 paul the call parameter is different : MARC for NEW, hash for old
09:52 then, the other object is builded & both are stored (MARC & non-MARC)
09:52 at the end, both have a MARC & non-MARC storage.
09:53 kados what is sub parameters?
09:54 paul ?
09:54 kados I don't see it anywhere
09:55 pierrick: do you understand the above POD?
09:55 I'm still not understanding what the difference between MARC=ON and MARC=OFF is
09:56 paul adding a biblio with MARC=OFF don't give you the addbiblio.pl screen, but a highly different one.
09:56 very simple & hardcoded
09:57 kados couldn't we just get rid of that and use a simplified framework?
09:57 and turn off display of the MARC codes?
09:58 paul that's what I suggested to chris recently & he promised to give it a try
09:58 he seems quite happy with this solution
09:58 kados ok, I say we do this then ...
09:58 so we can unify the API
09:58 paul ;-)
09:59 kados so here are the changes I'm proposing for Biblio.pm
09:59 1. delete old 1.x routines
09:59 2. change NEWXXX to XXX
09:59 change the name of all internal routines to _XXX
09:59 dewey kados: that doesn't look right
09:59 kados dewey: right, I forgot the 3. :-)
09:59 dewey kados: huh?
10:01 kados paul: we should be able to eliminate REALXXX too
10:01 I see no reason to separate out the NEW and REAL routines ... we can just have one routine for each API call ... unless you disagree
10:01 pierrick: any opinions on this?
10:02 paul kados: for sure, we don't need REAL...
10:02 if we get rid of MARC=OFF, Biblio.pm will be highly simplified !
10:02 kados it makes troubleshooting very difficult
10:02 yea, we're getting rid of it :-)
10:03 if we need to fix some stuff for katipo's clients then so be it
10:03 but we need to clean up this API
10:03 it's a mess
10:03 I'm re-writing Biblio.pm from scratch :-)
10:04 paul imho, we don't need to rewrite biblio.pm from scratch.
10:04 we should be able to get something clean by :
10:04 - keeping useful API (NEWnewbiblio for example)
10:04 merging OLD & MARC subs in NEW
10:05 - removing REAL, that is really useless
10:05 - removing old-style API
10:05 the last question being : is it interesting to keep using NEWxxxx ?
10:05 why not having just xxxx ?
10:05 good question ;-)
10:06 kados that's basically what I'm doing
10:06 but I'm starting with a new file
10:06 and copy/paste in the stuff we're saving
10:06 and i need to merge in Tumer's Zebra management functions
10:06 paul should be the best solution probably then.
10:07 kados I tried cvs update -d -j Biblio.pm
10:07 but that was never going to work :-) a real mess :-)
10:08 I'm also turning on warnings
10:08 it'll be turned off before the 3.0 release
10:08 but it's going to be necessary to troubleshoot in the meantime
10:08 esp with mod_perl
10:11 paul: do we need newbiblio as well as newbiblioitem?
10:11 paul yep, I have warnings=ON too
10:11 pierrick I'm back... kados I read the log of the last hour
10:11 paul this question is interesting... it depends on wether we decide to remove 1biblio = X biblioitems possibility that was with MARC=OFF
10:12 in this case, no need to have biblio & biblioitems tables.
10:12 kados right
10:12 paul thus no need to have newbiblio & newbiblioitem ;-)
10:12 kados I know that katipo needs to be able to group items of different itemtypes
10:12 but if we move itemtype to the item level
10:12 I think that would solve that problem for them
10:13 (it would also remove another barrier to standard MARC compliance)
10:14 paul be careful, as for UNIMARC itemtype is at the right place !
10:15 (biblio level)
10:15 because for UNIMARC, a different itemtype means a different "object", so a different biblio. even if the diff is only the publicationyear & not the itemtype !
10:17 kados so maybe we need
10:17 bibliotype and itemtype
10:17 paul: would that work for UNIMARC?
10:18 pierrick: what do you think of the log?
10:18 paul yep, maybe. but upgrade 2.x => 3.0 will be really nice !!!
10:19 pierrick OK, I've read the last hour log...
10:19 many things were said.
10:19 kados paul: in fact, not too bad ... it will be necessary to export all MARC records anyway
10:19 paul: to index in zebra
10:20 pierrick My opinion is the following: kados, please create a real discussion on koha-devel with all your propositions. Even if IRC is great for reactivity, it's bad for deep discussion as the one I've just read
10:20 paul pierrick: ++ I almost wrote this here a few minuts ago
10:20 kados paul: there are some highly specialized routines in Biblio.pm ... such as &modsubtitle &modsubject &modaddauthor
10:21 paul that should be removed as well
10:21 kados pierrick: of course, I will ... but we could talk for weeks about how to do this
10:21 pierrick: the first step is to define what my propositions are
10:21 pierrick yep
10:21 kados pierrick: and to do so i need to chat with the original authors of the modules
10:22 btoumi_away bye everybody
10:22 kados pierrick: I'm putting together a wiki page with my new proposed api for biblio.pm
10:22 pierrick great :-)
10:22 kados paul: so all of those specialized routines can be handed by modbiblio now, right?
10:22 and &checkitems ...
10:22 paul yep. they were here because in Koha 1.x, subtitle & addauthors & subjects where in a different screen
10:23 (iirc)
10:23 (& when MARC=OFF)
10:23 kados gotcha
10:25 pierrick another question about Biblio.pm: shouldn't we separate biblio management and items management ?
10:25 items are used for circulation while biblio are used for search
10:26 paul maybe yes, but not sure. as items are also used for searching sometimes.
10:26 kados yea, all are in the MARC record
10:26 at least currently
10:26 paul I think a package for MARC management & one for MARC search is better
10:26 kados at devweek we discussed creating a separate holdings database
10:26 in zebra
10:26 and i think it's a good idea
10:26 but I'm not sure how hard it would be to do at this point
10:26 paul (but we decided to put this idea on feature for Koha 4 ;-) )
10:26 kados yea :-)
10:27 pierrick: in your view would we then have a Biblio.pm and a Holdings.pm ?
10:27 pierrick yes we have items in MARC record, but what we always use in code is the MySQL links
10:27 kados pierrick: or would we keep everything in the Biblio.pm still?
10:27 pierrick kados, yes, Biblios and Holdings are not the same
10:27 kados interesting ...
10:27 in 2.x we use MySQL links for searching
10:28 bu in 3.0 we use CQL or RPN
10:28 pierrick really ?
10:28 kados yea, at least in tumer's stuff
10:28 don't know about chris's
10:29 pierrick when I have a barcode issued, I look in zebra to find the associated biblio?
10:29 kados tumer's code allows this I think
10:29 I'm not sure if he's committed that bit yet
10:30 pierrick: in fact, why not have a Holdings.pm
10:31 pierrick: so in Biblio.pm, we'd have:
10:31 newBiblio
10:31 modBiblio
10:31 delBiblio
10:31 and in Holdings.pm we'd have:
10:31 newItem
10:31 modItem
10:31 delItem
10:32 and in Search.pm:
10:32 getBiblio
10:32 getItem
10:32 right?
10:32 paul: do we need more of an API that that?
10:32 paul & getBiblios to search in the catalogue
10:32 kados ahh ... right
10:32 paul that that ? no, that that enough I think
10:33 kados in fact, it's quite simple then
10:33 pierrick instead of newXXX I would prefer addXXX (consistency)
10:33 kados good point pierrick
10:33 paul ah ! good question : do we prefer new or add !
10:33 I personnaly prefer new.
10:33 kados heh
10:33 paul but I agree we just need to decide
10:34 pierrick "new" is a adjective, while we want a verb
10:34 paul other question : "mod" or "upd" ?
10:34 pierrick "mod" or "upd" is the same for me
10:34 paul pierrick: ++
10:34 (for new/add)
10:35 kados ok, so addXXX
10:36 i prefer modXXX to udpXXX
10:36 pierrick we are also saying we prefer "addXxx" to "add_xxx" and "addxxx".
10:37 I don't mind, but it's important for consistency.
10:37 paul addXxx for me
10:37 kados I prefer that
10:37 addXxx for me too
10:37 pierrick OK, "addXxx"
10:37 paul meaning addXxxxYyyyZzzz if needed
10:37 kados and it will be consistant in Biblio.pm, Holdings.pm and Search.pm
10:37 yep
10:46 http://wiki.koha.org/doku.php?id=api
10:47 paul: we've got a bunch of other exported methods in Biblio.pm ...
10:48 things like MARChtml2xml
10:48 pierrick and paul, should those be exported?
10:48 I know that one is currently used in addbiblio for instance
10:50 paul MARChtml2xml will be necessary i think
10:51 kados should that really be in Biblio.pm?
10:52 paul probably, as it's really related to biblio editing
11:01 veki hello, I was on one conference about open access to information and I proposed to people from African countries to use free software for their libraries at the universities.  DO you have any list of universities that use Koha for their libraries?
11:03 kados pierrick: do you agree that connection management for zebra should be handled in Context.pm?
11:03 paul hi veki.
11:03 in which country ?
11:03 veki hi
11:04 pierrick kados, yes of course
11:04 paul because we have some users in south america (Argentina for example)
11:04 as well as in cyprus
11:04 veki I am right now in serbia and my http://www.gnucentar.org.yu
11:04 but I have conections with universities in Ghana, Nigeria, South Africa, Uganda, Zimbabwe
11:04 paul no university that I know are here. but you'd better ask on koha mialing list I think
11:05 kados pierrick_leavin: should there even be dbh or zconn in Biblio.pm?
11:05 paul we have some libraries in Nigeria
11:05 veki ok, no problem, I just want to knwo that soneone is already using koha, because people rather use something that is already used by someone
11:05 paul kados: no, I don't think so, as they are general management.
11:05 kados paul: no to which? ... there should not be dbh or zconn in biblio.pm?
11:06 paul they should stay in Context.pm I think
11:06 kados paul: right now in Biblio.pm we have:
11:06 all subs require/use $dbh as 1st parameter and a hash as 2nd parameter.
11:06 pierrick_leavin kados, what do you mean exactly? you don't want to see "dbh" anywhere in Biblio ?
11:06 kados pierrick_leavin: yes, that's what I mean I think
11:07 pierrick_leavin kados, where do you move SQL queries ?
11:07 paul the 1st parameter is useless I think
11:08 as Context.pm handles db handlers very well
11:08 pierrick_leavin paul++
11:08 kados pierrick_leavin: well, I suppose we _should_ abstract them out to a SQL.pm or something ... but I see that as a  separate issue
11:08 pierrick_leavin kados, did you see what I made with get_infos_of in C4::Koha ?
11:09 kados pierrick_leavin: no ... is it in head?
11:09 pierrick_leavin kados, yes
11:09 paul pierrick_leavin: yes, I saw it, and i'm still unsure i'm happy with it.
11:09 pierrick_leavin paul, why?
11:09 paul (I'm afraid this could make too many small subs too much specialized)
11:10 kados pierrick_leavin: i don't quite understand what it does
11:10 paul but I may be wrong. my opinion is not definetly made
11:10 pierrick_leavin paul, instead of what you say, you will have more generic sub
11:10 paul mmm... that's what I wanted to write in fact.
11:10 pierrick_leavin the purpose is to avoid too many SQL joins
11:11 kados, find where it is used
11:11 paul, we'll talk of it on monday if you want
11:11 paul ok
11:12 pierrick_leavin I would like to go now, I take the car tonight, many things to do before leaving Paris...
11:13 kados pierrick_leavin: ciao
11:13 pierrick_leavin bye bye
11:17 veki guys, i will wive your address to some librarians so yo can help them if needed. I hope that this is OK for you.
11:18 I will download koha and try it in one library here and I will give your address to some librarians
11:28 paul_away bye & see you on friday
11:29 (on monday pierrick won't be here & me neither, as we have a meeting with a university interested by Koha. not sure to be back at 20 for the meeting)

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

koha1