IRC log for #koha, 2008-08-01

← Previous day | Today | Search | Index

All times shown according to UTC.

Time Nick Message
12:12 slef Has anyone else had problems with Safari+Keychain and koha logins?
12:12 (I've got a fault report that I can't debug.)
12:14 hi gaano
12:18 gaano hi
13:02 danny hello #koha
13:02 slef hello danny
13:03 hdl hi
13:05 kados : Is there any plan to have an API to use XSLT on marcxml wherever biblios are displayed (lists, basket, acquisitions,....) ?
13:06 Or is XSLT processing only limited to some display ?
13:19 gmcharlt greetings #koha
13:19 hdl: extending XSLT so that it's an option for all MARC displays is a good idea
13:20 hdl: we don't have any specific plans, yet, but we should definitely explore it for 3.2
13:20 hdl I thought we could even have a web API for that
13:21 gmcharlt yep
13:21 hdl xslt/xsltname/biblio/biblionum​ber1/biblionumber2/bibnumber3.
13:21 for instance.
13:21 (This would help maybe for interactions.)
13:22 I asked that because I was working on recentacquisitions and I wanted to use an XSLT. But seems that none could be used.
13:23 gmcharlt: Is there someone that could explain some of the utils functions in XSLT ?
13:30 gmcharlt hdl: hmm, yeah, the POD there is a little lacking
13:30 hdl: I'll open a bug
13:31 hdl: actually, wait - to clarify, are you asking about C4::XSLT or the utility functions called in the XSLT stylesheet itself
13:31 slef Has anyone else had problems with Safari+Keychain and koha logins?
13:31 hdl the XSLT stylesheet itself.
13:32 slef Oh sorry, I already aksed that.
13:32 asked
13:32 gmcharlt slef: not that I've noticed, but I use FF3 much more than Safari when working with Koha on my Mac
13:33 nicomo slef : I use safari+Keychain; never encountered any problem so far
13:34 hdl ryan:  ?
13:35 gmcharlt hdl: the utility functions are from http://www.loc.gov/standards/m[…]RC21slimUtils.xsl - didn't find any doc per se after a minute of Google
13:35 Googling
13:36 hdl The fact is that we donot have anything help like that in France.
13:37 And Such functions imho are quite MARC21oriented.
13:37 So I tried to understand (months ago) the importance of such functions.
13:38 gmcharlt the ones in that stylesheet seem pretty generic, except for chopPunctuation, which I assume is mostly redundant in UNIMARC
13:45 hdl gmcharlt: seems that order of subfields is important and UNIMARC subfield order is not the same.
13:46 gmcharlt hdl: wrt to what?  subfieldSelect preserves the order; you just tell it which ones you're interested in
13:51 hdl yes : was wrt specialSubfieldSelect
13:55 gmcharlt hdl: ah, I see, that's in the /MARC21slim2OPACDetail.xsl, not the more generic utility functions
13:55 owen Speaking of XSLT, does anyone know why my XSLT version of opac-detail isn't displaying any data?
13:56 I've got the pref turned on. Is there something else I need to do?
13:56 hdl you should point to the good xslt files in some sys prefs.
13:57 gmcharlt: yes, was quite an old memories fo mine.
13:57 owen hdl, the only XSLT prefs I have are for DetailsDisplay and ResultsDisplay
13:57 gmcharlt owen: anything in log?
13:58 owen Doesn't look like it
14:54 paul gmcharlt: 2 weeks ago (iirc), kados told us you were away, so he won't create a new branch for 3.2. Now you're back. I think it could be usefull to create 3.2 now
14:54 your opinion ?
14:54 gmcharlt paul: as a temporary branch, maybe OK
14:54 paul what do you mean by "temporary branch" ?
14:55 gmcharlt paul: ideally, once we fully transition to 3.2
14:55 I'd want 3.2 patches to go to HEAD
14:55 paul then, it's time to branch 3.0 maybe ;-)
14:55 gmcharlt and stuff for 3.0.1 to go on a 3.0-post-final maint branch
14:56 paul: I take it you have a bunch of 3.2 patches lined up?
14:57 paul monday, a new BibLibrer will start working on new acquisition module with Olivier. So I would be pleased to have a branch to commit into. to share the work with you
14:57 otherwise, we will continue with a local branch (as we started)
14:57 that's possible, but not optimized I think
14:57 gmcharlt for the new acq module, are you changing C4::Acquistions, or starting an entirely new set of DB tables and modules?
14:57 paul + some patches should not be added to head now, and it's a shame to have them pending for weeks/months.
14:58 for instance, starting a new set (aq2 tables) & C4/Acquisitions2.pm
14:58 but i'm not sure it's the best solution, we may want to switch
14:58 slef huh? new acq module?
14:59 paul example of a patch that should not be in 3.0, but in 3.2 = Joe, jul
14:59 example of a patch that should not be in 3.0, but in 3.2 = Joe, jul 30, "Tag cloud implementation in jquery"
14:59 slef paul: can we coordinate so the EDIFACT stuff still works with it, please?
14:59 paul "still works " ?
14:59 slef #include <rants/javascript.die.die.die>
15:00 paul: davi is working on EDIFACT for us
15:00 paul: I hope it will work this autumn, if our suppliers start to cooperate and give us test accounts.
15:00 davi slef, yes
15:00 paul mmm... is your code available somewhere ?
15:00 slef davi: I'll chase again today
15:01 davi great!
15:01 slef paul: nafaik... later
15:01 paul did you announce it on koha-devel ?
15:01 slef paul: actually, I'm not sure.  It should be in bugs.k.o at least.
15:02 I've definitely discussed it on IRC before and I thought you were here.
15:02 but maybe not.
15:04 paul: it was >9 months ago
15:07 paul ok, thanks. I've cced olivier that works on our part. I hope i'll be able to open our git in early sept.
15:08 slef biab
15:10 atz paul: actually that was part of the tags specs I was working from, so 3.0 or 3.2, i had to do it now
15:11 paul atz: OK, but if it's not added to HEAD now, it will stay pending nowhere until 3.2 is branched.
15:30 slef Real men do not play games, they win!
15:30 spam is funny
15:30 acmoore gmcharlt: If I look at getting 2084 knocked out for the 3.0 release, do you think I should disallow sorting on those large results, or allow it after a warning, or what?
15:31 atz i think the absurdist poets would be stunned at the quality of spam's nonsense
15:32 gmcharlt slef: I've also noticed that spam subject lines have actually gotten pretty funny in the last month or two
15:32 slef acmoore: you're going to knock 2084 out?  Careful!  Knocking one out too often makes you go blind...
15:33 gmcharlt we have yet to install the haptics interface to bugzilla, so hopefully acmoore will survive :)
15:34 slef gmcharlt: I still think dehydration would be a danger.
15:37 gmcharlt acmoore: basically, I think that if a report can reasonably have more than 200 rows or so for a large library, the JS table-sorter should be removed for now
15:37 acmoore: not best in the long run, but useful for now
15:38 slef ok, who turned on the sky-taps?
15:39 acmoore so, we would still return all of the data, but withouth the JS sorter, right?
15:41 gmcharlt acmoore: right
15:43 acmoore Do you think it's worth testing the database to see if it has a large amount of data, or just remove the JS sorter for those places where users *could* have a lot of data?
15:43 gmcharlt for now, simple is best IMO
15:43 i.e., just remove JS sorter for unpaginated results
15:43 acmoore OK. I agree.
15:44 OK, I'll look into it a bit and see how I do.
15:46 atz acmoore: should be able to handle the number of results in the template and optionally load or skip the sorter
15:46 pianohacker Couldn't we hook the current table sorter interface up to ajax for 3.2?
15:46 acmoore atz: good point. count the @results in the template and pass a flag to enable or disable the sorter?
15:47 pianohacker I.e., re-load and cache the results when you sort differently
15:47 atz acmoore: right
15:47 pianohacker: yeah, ideally just pushing JSON to AJAX... very application-y
15:51 gmcharlt atz, pianohacker: good idea for 3.2
15:51 pianohacker gmcharlt: You probably have a keyboard shortcut to say that at this point
16:19 paul newlogbot: seen hdl ?
16:19 pianohacker paul: I don't think newlogbot is quite that smart
16:20 paul I thought ;-)
16:20 logbot used to speak a lot (too much)
16:20 it make us laught often !
16:26 slef !seen hdl
16:26 newlogbot: salut
16:26 no, it's not as chatty as logbot
16:27 hdl !liste
16:27 !list
16:27 paul slef: & that's good !
16:28 slef ?? koha
16:43 pianohacker newlogbot: circulation is a synonym for despair
16:44 ?? circulation
16:44 Dang
16:44 slef pianohacker: /msg newlogbot !define <word> <definition>
16:44 pianohacker Ah
17:02 acmoore pianohacker: was it you talking about possibly doing something to facilitate picking database version numbers?
17:02 pianohacker Yes
17:02 acmoore I'm wondering if you have a plan that I should participate in.
17:02 pianohacker I was thinking just creating a namespace on the wiki and posting a message to koha-devel
17:03 i.e., development:dbrevs:v106
17:03 acmoore that might work. So, if I'm writing a feature now that I don't expect to be done for a few days, how would I determine which database number to pick?
17:03 I think I'd want to keep them in order, so if I picked the next available number, someone else might get a commit in sooner than me, using a larger number.
17:04 gmcharlt picking DB rev number would be one's last act before submitting
17:04 gaps in sequence would be OK, if untidy
17:04 acmoore ah.
17:04 gmcharlt but out-of-order changes would break things
17:06 acmoore yeah, it sure would.
17:07 gmcharlt maybe a sort of DB change registry might be better
17:07 i.e., don't rely on a perfect linear sequence
17:07 but give each DB change an ID
17:07 and change registry (stored in Koha DB) of which DB changes need to be applied
17:07 check registry, that is
17:08 some DB changes will require others as prereqs
17:08 but may be easier for us to deal with that
17:08 dunno
17:08 slef directed graphs yay!
17:09 rhcl When will kados et al be back from Kansas? I assume that's where he's at, anyway.
17:09 gmcharlt rch1: he'll be fully back by Monday (US)
17:09 rhcl OK, tnx.
17:36 pianohacker Could everybody take a look at http://wiki.koha.org/doku.php?[…]ment:dbrevs:start and give me an opinion?
17:58 acmoore pianohacker: I'm not sure that the 2 day wait in this new process is going to make it worth the benefit of possibly having to send a patch again.
17:59 pianohacker english.py: RuntimeError: too much recursion
18:00 gmcharlt pianohacker: translation - it would slow things down too much
18:00 pianohacker Ah
18:00 gmcharlt: thanks ;)
18:00 That was mainly thrown in there so that changes would get bundled together; I can remove it if it would be a problem
18:01 gmcharlt pianohacker: also, could you put a big fat "this is only a proposal" on the wiki page
18:01 acmoore oh yeah, I guess I said that backwards. sorry.
18:05 pianohacker Okay, edited
18:15 owen Are the help files in intranet-tmpl/prog/en/modules/help getting generated by something?
18:18 acmoore pianohacker: I edited it. Is that how you pictured it?
18:20 pianohacker Very much so!
18:21 owen: nengard is editing them, that might be it
18:22 acmoore I can see this being useful, but it's still quite a bit of work to do. In fact, I'm not really sure that the subpage is necessary once I've put my name, a date, a version number, and a bug number there.
18:23 pianohacker That's a good point
18:23 Maybe not bother with the subpage, and instead make the description on the main page slightly more detailed?
18:24 gmcharlt pianohacker, owen: as far as I know, nengard has not in fact submitted any patches to the help files yet - it must be something else
18:24 pianohacker http://git.koha.org/cgi-bin/gi[…]a69c3869825600dea ?
18:25 gmcharlt pianohacker: which is exactly one file
18:25 pianohacker or http://git.koha.org/cgi-bin/gi[…]r&s=Nicole+Engard
18:26 gmcharlt pianohacker: I stand corrected
18:29 acmoore pianohacker: I added a table. Maybe that will suffice? I guess if more discussion is warranted, the version number can be a link a subpage if it exists?
18:30 pianohacker Sounds good
18:31 acmoore I hope I haven't railroaded your suggestion.
18:33 pianohacker No, this is good
18:34 Edited again, hopefully my long sentences fetish won't annoy anybody
18:36 acmoore OK, I made my version number into a link, for demonstration purposes, I guess.
18:38 This might actually be handy if we start to use it. I'm interseted in seeing what kind of reaction you get from the koha-devel list.
18:40 pianohacker <shiver>
22:21 cnighs interesting
22:21 Your mail to 'Koha' with the subject
22:21   Re: [Koha] koha error
22:21 Is being held until the list moderator can review it for approval.
22:21 The reason it is being held:
22:21   Too many recipients to the message
22:30 atz a reasonable spam-guard, i guess

← Previous day | Today | Search | Index

koha1