Time Nick Message
13:17 danny good morning #koha
13:24 paul_p good morning danny
13:25 hdl hi
13:27 nengard moening
13:27 nengard or morning
13:27 nengard :)
13:30 hdl hi nengard
13:42 ryan hi owen
13:42 owen Hi ryan and everyone
13:42 ryan owen: do we have a preferred form validator now ? or any particularly good paradigm for it ?
13:43 owen We don't, but I've had good experiences with a jquery one: http://bassistance.de/jquery-plugins/jquery-plugin-validation/
13:46 ryan owen: looks nice. i'll use it.
13:49 ryan owen: is this in koha now ? or i would have to add it to lib
13:49 ryan ?
13:49 owen I don't think it is
13:50 owen I've used it in other projects
13:51 ryan owen: would adding this to koha warrant an rfc? If you'll adopt it elsewhere, good, but i don't want to tie ourselves to anything prematurely
13:52 gmcharlt ryan: why not try it out on a Koha form first, then RFC if experiment works
13:53 owen gmcharlt: RFC to find out if we should implement it throughout?
13:53 gmcharlt yes
13:54 owen That's fine with me. And I'd be willing to undertake wider implementation if everyone agrees.
13:57 ryan gmcharlt: , owen ok, i'll submit a patch.
14:07 ryan acmoore: around ?
14:08 acmoore morning
14:09 ryan hi acmoore . got a question re: dbic & chaining for ya.
14:10 paul_p hi ryan & owen & gmcharlt & anyone just waking up :D
14:10 ryan do you understand why the following two dbic uses result in different sql ? ...
14:10 paul_p (& nengard)
14:10 ryan (hi paul_p )
14:10 ryan (1) my $rs = $schema->resultset('table')->search_literal( 'column = ?', $data );
14:10 ryan (2) my $rs = $schema->resultset('table');
14:10 ryan $rs->search_literal( 'column = ?', $data );
14:10 ryan ?
14:10 acmoore whoah. It does?
14:11 nengard hi paul_p
14:11 ryan acmoore: there's no where clause if i call search_literal on the $rs obj, but there is a where clause if i use it chained.
14:11 acmoore or, rather, they make different SQL? No, I don't understand that. I can play with that and see what comes of it.
14:12 acmoore well, when you instantiate a resultset, it does the search. so, in the second case, I guess you're using perl to narrow down the results instead of using SQL.
14:13 acmoore in other words, "search_literal" isn't the thing that means "get me some data", "resultset" means that. That's just my guess based on rather limited exposure to it.
14:14 acmoore want to go over to #dbix-class on irc.perl.org with me and ask?
14:15 ryan acmoore: sure. i guess that makes some sense, though i recall reading the caveat that dbic tries to actually get data at the latest time possible.
14:16 acmoore ryan: yeah, I recall that, too, which is why I'm somewhat surprised by this.
14:17 acmoore ryan: out of curiousity, how did you come across this? I've never looked at the SQL generated by DBIC.
14:20 ryan acmoore: $schema->storage->debug(1); causes all generated sql to be output to STDERR
14:21 acmoore oh yeah, I recollect that now. Hmm. I'll give it a try. I'd better wait for tomorrow to play with it, but if you have some other examples, send them my way.
14:21 acmoore I'll probably ask about it a bit in #dbix-class if I can't make sense out of it. You have to have kind of thik skin in there, though, sometimes.
14:22 ryan heh, nothing like getting lambasted for n00b questions.
14:23 ryan 'talk to the rtfm-bot'
14:32 acmoore gmcharlt: I wonder why #kohanews shows about 8 new things in git, but http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=summary only shows 4.
14:33 gmcharlt acmoore: something in the chain not storing or comparing timestamps of updates correct, presumably
14:34 acmoore yeah, weird. #kohanews is showing things done 2 days ago as recent.
14:50 ryan acmoore: have you done any error handling yet with dbic?
14:50 acmoore none to speak of.
14:56 ryan acmoore: feel free to defer my questions until tomorrow if you're busy... i'm just playing a bit with it now, but can wait for much of it. Now I'm looking at inflating date columns to C4::Dates objects. Have you done this already?
14:57 acmoore no. I played around with inflating them into DateTime objects, but not too much.
14:57 acmoore I'd love to see us use either DateTime or C4::Dates for that, though.
14:57 acmoore ... and then Business::ISBN or some kind of C4::ISBN.
14:58 paul_p acmoore: what is #kohanews ?
14:59 paul_p ok, gotcha. it's on freenode
15:45 owen Hi liz, how was Kansas Koha Interest Group Day?
15:46 nahuel gmcharlt, are you here ?
15:46 gmcharlt nahuel: hi. yes, I'm here
15:47 nahuel gmcharlt, how the 2831 patch doesn't apply ?
15:47 nahuel it apply in my install
15:47 nahuel I just answer you
15:47 nahuel (by mail)
15:48 gmcharlt nahuel: context for first hunk no longer applies
15:48 gmcharlt please resend the patch
15:48 nahuel hmm well, i'll redo it, let me some minutes :)
15:50 nahuel gmcharlt, sent
15:50 gmcharlt thanks
15:51 gmcharlt nahuel: please see http://blogs.liblime.com/developers/2008/12/02/git-tip-prefix-in-commit-messages/
15:51 gmcharlt upshot is that "[bug 1234] this and that" is not ideal for commit messages
15:51 nahuel gmcharlt, already read :)
15:52 nahuel The patch that have [bug #XXX] subject are older than this blog post
15:52 nahuel since I format as (bug #XXX)
15:52 gmcharlt right, just wanted to make sure you saw it
15:52 nahuel :)
15:54 nahuel gmcharlt, I have a question on how make patches
15:54 gmcharlt go ahead
15:55 nahuel If I do a patch to a file, and then another patch to the same file, should I do the patch for the "actual HEAD", or my patched HEAD
15:55 nahuel thinking, my 2nd patch should fail applying it
15:55 gmcharlt generally I should apply the first patch before the second
15:55 nahuel (if it's done for the HEAD version
15:56 nahuel ok
15:56 gmcharlt hence no conflict
15:56 nahuel so it's better to do it, based on my patched koha
16:09 liz atz: I'm looking at bug 2246, we seem to be affected by this fairly severely at NEKLS (special chars/unicode/PDF::Reuse), I'm wondering how best to go about avoiding it (short of removing all special characters in title/author fields).
16:09 liz would it be best to just tell our librarians to do labels with special characters by hand?
16:10 atz liz: use CSV export and a workstation printing application
16:10 liz ... and this is why I asked you, thanks
16:10 liz <smacks forehead for her own dumbitude)
16:11 atz np. it's not as cute as the auto-PDF, but it works far more reliably
16:12 atz i've been meaning to test w/ glabel (GNU printing software), but haven't got around to it yet
16:16 the_new_user hi
16:17 the_new_user can anyone help me install koha on cpane
16:20 the_new_user hi
16:40 liz atz: Some of the staff here think it's "no big deal" that the label printing doesn't work 100% of the time, and that iti's ok to anglicize the titles/authors. I personally think it's "kind of a big deal," i.e. if I were French, i wouldn't want Americans bastardizing the titles of my French books just because their software couldn't handle the accents (I'm not French, any French folk are welcome to chime in). I like accuracy, though. Maybe I'm the one that's wrong.
16:41 atz liz: i agree with you... i hate features that work for some of our libraries and break for others.
16:41 atz it makes me feel like I'm neglecting, say, our saudi arabian clients
16:42 atz or (my favorite example), the lithuanian library we support (w/ 53 diacritical chars!)
16:42 atz paul_p: what do you use for label and barcode printing?
16:42 liz yea, they can't probably use the internal label printing
16:42 atz since the PDF generator seems not to work for non-ASCII
16:42 liz (in lithuania)
16:42 paul_p ah, ok, I thought you were speaking of the MARC label ;-)
16:43 paul_p (label = leader in french)
16:43 liz hehe no the spine label
16:43 paul_p in fact, none of our libraries uses the label generator with accents !
16:43 paul_p (afaik)
16:43 liz because it doesn't work, right?
16:43 liz or, doesn't work well
16:43 liz I should say
16:44 paul_p nope, because they print barcode (a few of them), of callnumber (which has no accents)
16:44 liz ah i see!
16:44 atz ah, i see.... they aren't interested in having the author/title and other stuff on there
16:44 atz very utilitarian
16:44 liz smart lol
16:44 paul_p right
16:44 atz i should say, in that case, it works great
16:45 liz heh yea, it would work perfectly
16:45 paul_p the main concern most of our libraries have is to define the label size/position...
16:45 paul_p but once it's done, they're happy !
16:46 paul_p atz: just answered your question about "No Title" on koha-dev
16:46 atz thx
16:48 gmcharlt I'm thinking that it will be easier to fix tmpl_process3.pl / xgettext.pl
16:49 gmcharlt than reliably change all <!-- TMPL to <TMPL
16:49 paul_p gmcharlt: ++
16:49 gmcharlt plus fixing the translation script will get us one more person who groks it
16:49 atz yes, surely... i mean all it is doing is pulling out the strings (and their positions?)
16:50 atz i can write a regexp (as a separate pass) that can identify all the TMPL_VAR DEFAULT strings
17:03 paul_p atz: it's much more complex than that. it uses a parser if I'm not mistaken
17:03 atz paul_p: right... it uses a parser... but at the end what does it build?
17:05 paul_p TmplTokenizer.pm is our friend I think
18:30 pianohacker Hello; is anyone here familiar with longoverdues.pl/C4::Accounts ?
18:32 pianohacker I think I'm looking at a quite odd bug where it marks lost items as returned: http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/Accounts.pm;h=c43741bf49c9d3f5a4253670762f38ecaa297184;hb=master line 315
18:34 pianohacker Does anyone know why this would be a desired behavior?
18:35 areinmeyer pianohacker: I've been looking at fines/Accounts recently
18:36 areinmeyer I saw that as the library charges for the lost item, considers it gone
18:36 pianohacker Hmm
18:36 areinmeyer but then needs to account for the item being charged in circulation
18:36 areinmeyer It does seem an odd way to mark it though
18:38 pianohacker Well, I guess that kinda makes sense
18:38 pianohacker I sympathize with you though, if you've been wading through that morass
18:41 areinmeyer I won't say that it's the best way to handle it, but that's at least the apparent logic
19:19 nengard owen is you myacpl.org down?
19:19 nengard oops
19:58 atz pianohacker: yeah, the whole point of longoverdues is to get the items off the patron account (in exchange for the associated fine)
20:00 atz in many cases the items will then be deleted... which couldn't have been accomplished w/o getting rid of the pending checkout
20:06 chris atz: i told that guy not to use the packages, or if he did, dont expect them to work
20:07 atz weird, must have a debian fixation
20:07 chris well they are good for getting all the dependencies installed
20:07 chris in one fell swoop
20:07 chris but then you want to do the final bit with the Makefile.PL
20:08 chris they will rock when they are finished, especially the localisation packages
20:08 chris vincent has a little todo list
20:08 chris which im trying to help with
20:09 chris http://git.debian.org/?p=collab-maint/koha.git;a=blob_plain;f=debian/TODO-packaging;hb=e8e6ba875f121ef9843747e1f48451deca6c87d8
20:10 chris if we can get it done before early/mid january
20:10 chris we wont get it in lenny (already missed that)
20:10 chris but we will make the cutoff for ubuntu jaunty
20:10 chris which would be pretty cool
21:26 liz anybody seen the issue where items with sub-titles or colons in the title mess up the hold transfer slip? By mess up I mean, it doesn't display/print the rest of the slip after the colon, which should display the author and item barcode.
21:28 liz example: this title -
21:28 liz Libraries for the future : planning buildings that work : proceedings of the library buildings preconference, June 27 and 28, 1991, Atlanta, Georgia
21:28 liz stops printing the slip after the first colon
21:28 liz interestingly also it only hyperlinks the title up to the colon
21:29 liz in the results list
23:26 atz_ gmcharlt: I think some review of maxItemsInSearchResults is in order
23:27 atz_ the feature as a whole is an only superficially implemented idea
23:27 atz_ the syspref type should be Integer, not free
23:28 atz_ and it actually limits the number of items that appears in each of three categories, not the total number of items
23:28 atz_ those categories are not transparent to the user.
23:29 atz_ the hardcoded default of 1 item is silly
23:30 atz_ this will take a DB rev. to fix correctly
23:32 atz_ and we should decide if we want it to work in a logical way (max of any items displayed) or the current way (max of 3 separate categories)
23:33 atz_ or if it should just be purged and forgotten
23:34 atz_ i guess that wold be a little excessive, since it isn't too hard to do right... but it would be easier if it wasn't wrong at so many levels already
23:49 gmcharlt atz_: agreed that a little review is in order
00:49 pianohacker atz_: Are you still around? Just saw your note on longoverdues.pl