Time  Nick         Message
00:49 pianohacker  atz_: Are you still around? Just saw your note on longoverdues.pl
23:49 gmcharlt     atz_: agreed that a little review is in order
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:33 atz_         or if it should just be purged and forgotten
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:30 atz_         this will take a DB rev. to fix correctly
23:29 atz_         the hardcoded default of 1 item is silly
23:28 atz_         those categories are not transparent to the user.
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:27 atz_         the syspref type should be Integer, not free
23:27 atz_         the feature as a whole is an only superficially implemented idea
23:26 atz_         gmcharlt: I think some review of maxItemsInSearchResults is in order
21:29 liz          in the results list
21:28 liz          interestingly also it only hyperlinks the title up to the colon
21:28 liz          stops printing the slip after the first colon
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          example: this title -
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.
20:10 chris        which would be pretty cool
20:10 chris        but we will make the cutoff for ubuntu jaunty
20:10 chris        we wont get it in lenny (already missed that)
20:10 chris        if we can get it done before early/mid january
20:09 chris        http://git.debian.org/?p=collab-maint/koha.git;a=blob_plain;f=debian/TODO-packaging;hb=e8e6ba875f121ef9843747e1f48451deca6c87d8
20:08 chris        which im trying to help with
20:08 chris        vincent has a little todo list
20:08 chris        they will rock when they are finished, especially the localisation packages
20:07 chris        but then you want to do the final bit with the Makefile.PL
20:07 chris        in one fell swoop
20:07 chris        well they are good for getting all the dependencies installed
20:07 atz          weird, must have a debian fixation
20:06 chris        atz: i told that guy not to use the packages, or if he did, dont expect them to work
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
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)
19:19 nengard      oops
19:19 nengard      owen is you myacpl.org down?
18:41 areinmeyer   I won't say that it's the best way to handle it, but that's at least the apparent logic
18:38 pianohacker  I sympathize with you though, if you've been wading through that morass
18:38 pianohacker  Well, I guess that kinda makes sense
18:36 areinmeyer   It does seem an odd way to mark it though
18:36 areinmeyer   but then needs to account for the item being charged in circulation
18:36 pianohacker  Hmm
18:36 areinmeyer   I saw that as the library charges for the lost item, considers it gone
18:35 areinmeyer   pianohacker:  I've been looking at fines/Accounts recently
18:34 pianohacker  Does anyone know why this would be a desired behavior?
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:30 pianohacker  Hello; is anyone here familiar with longoverdues.pl/C4::Accounts ?
17:05 paul_p       TmplTokenizer.pm is our friend I think
17:03 atz          paul_p: right... it uses a parser... but at the end what does it build?
17:03 paul_p       atz: it's much more complex than that. it uses a parser if I'm not mistaken
16:50 atz          i can write a regexp (as a separate pass) that can identify all the TMPL_VAR DEFAULT strings
16:49 atz          yes, surely... i mean all it is doing is pulling out the strings (and their positions?)
16:49 gmcharlt     plus fixing the translation script will get us one more person who groks it
16:49 paul_p       gmcharlt: ++
16:49 gmcharlt     than reliably change all <!-- TMPL to <TMPL
16:48 gmcharlt     I'm thinking that it will be easier to fix tmpl_process3.pl / xgettext.pl
16:46 atz          thx
16:46 paul_p       atz: just answered your question about "No Title" on koha-dev
16:45 paul_p       but once it's done, they're happy !
16:45 paul_p       the main concern most of our libraries have is to define the label size/position...
16:45 liz          heh yea, it would work perfectly
16:44 atz          i should say, in that case, it works great
16:44 paul_p       right
16:44 liz          smart lol
16:44 atz          very utilitarian
16:44 atz          ah, i see.... they aren't interested in having the author/title and other stuff on there
16:44 liz          ah i see!
16:44 paul_p       nope, because they print barcode (a few of them), of callnumber (which has no accents)
16:43 liz          I should say
16:43 liz          or, doesn't work well
16:43 liz          because it doesn't work, right?
16:43 paul_p       (afaik)
16:43 paul_p       in fact, none of our libraries uses the label generator with accents !
16:43 liz          hehe no the spine label
16:43 paul_p       (label = leader in french)
16:42 paul_p       ah, ok, I thought you were speaking of the MARC label ;-)
16:42 liz          (in lithuania)
16:42 atz          since the PDF generator seems not to work for non-ASCII
16:42 liz          yea, they can't probably use the internal label printing
16:42 atz          paul_p: what do you use for label and barcode printing?
16:42 atz          or (my favorite example), the lithuanian library we support (w/ 53 diacritical chars!)
16:41 atz          it makes me feel like I'm neglecting, say, our saudi arabian clients
16:41 atz          liz: i agree with you... i hate features that work for some of our libraries and break for others.
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:20 the_new_user hi
16:17 the_new_user can anyone help me install koha on cpane
16:16 the_new_user hi
16:12 atz          i've been meaning to test w/ glabel (GNU printing software), but haven't got around to it yet
16:11 atz          np.  it's not as cute as the auto-PDF, but it works far more reliably
16:10 liz          <smacks forehead for her own dumbitude)
16:10 liz          ... and this is why I asked you, thanks
16:10 atz          liz: use CSV export and a workstation printing application
16:09 liz          would it be best to just tell our librarians to do labels with special characters by hand?
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).
15:56 nahuel       so it's better to do it, based on my patched koha
15:56 gmcharlt     hence no conflict
15:56 nahuel       ok
15:55 nahuel       (if it's done for the HEAD version
15:55 gmcharlt     generally I should apply the first patch before the second
15:55 nahuel       thinking, my 2nd patch should fail applying it
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:54 gmcharlt     go ahead
15:54 nahuel       gmcharlt, I have a question on how make patches
15:52 nahuel       :)
15:52 gmcharlt     right, just wanted to make sure you saw it
15:52 nahuel       since I format as (bug #XXX)
15:52 nahuel       The patch that have [bug #XXX] subject are older than this blog post
15:51 nahuel       gmcharlt, already read :)
15:51 gmcharlt     upshot is that "[bug 1234] this and that" is not ideal for commit messages
15:51 gmcharlt     nahuel: please see http://blogs.liblime.com/developers/2008/12/02/git-tip-prefix-in-commit-messages/
15:50 gmcharlt     thanks
15:50 nahuel       gmcharlt, sent
15:48 nahuel       hmm well, i'll redo it, let me some minutes :)
15:48 gmcharlt     please resend the patch
15:48 gmcharlt     nahuel: context for first hunk no longer applies
15:47 nahuel       (by mail)
15:47 nahuel       I just answer you
15:47 nahuel       it apply in my install
15:47 nahuel       gmcharlt, how the 2831 patch doesn't apply ?
15:46 gmcharlt     nahuel: hi. yes, I'm here
15:46 nahuel       gmcharlt, are you here ?
15:45 owen         Hi liz, how was Kansas Koha Interest Group Day?
14:59 paul_p       ok, gotcha. it's on freenode
14:58 paul_p       acmoore:  what is #kohanews ?
14:57 acmoore      ... and then Business::ISBN or some kind of C4::ISBN.
14:57 acmoore      I'd love to see us use either DateTime or C4::Dates for that, though.
14:57 acmoore      no. I played around with inflating them into DateTime objects, but not too much.
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:50 acmoore      none to speak of.
14:50 ryan         acmoore: have you done any error handling yet with dbic?
14:34 acmoore      yeah, weird. #kohanews is showing things done 2 days ago as recent.
14:33 gmcharlt     acmoore: something in the chain not storing or comparing timestamps of updates correct, presumably
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:23 ryan         'talk to the rtfm-bot'
14:22 ryan         heh, nothing like getting lambasted for n00b questions.
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: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:20 ryan         acmoore: $schema->storage->debug(1);  causes all generated sql to be output to STDERR
14:17 acmoore      ryan: out of curiousity, how did you come across this? I've never looked at the SQL generated by DBIC.
14:16 acmoore      ryan: yeah, I recall that, too, which is why I'm somewhat surprised by this.
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:14 acmoore      want to go over to #dbix-class on irc.perl.org with me and ask?
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: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: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: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 nengard      hi paul_p
14:10 acmoore      whoah. It does?
14:10 ryan         ?
14:10 ryan         $rs->search_literal( 'column = ?', $data );
14:10 ryan         (2) my $rs = $schema->resultset('table');
14:10 ryan         (1)  my $rs = $schema->resultset('table')->search_literal( 'column = ?', $data );
14:10 ryan         (hi paul_p )
14:10 paul_p       (& nengard)
14:10 ryan         do you understand why the following two dbic uses result in different sql ? ...
14:10 paul_p       hi ryan & owen & gmcharlt & anyone just waking up :D
14:09 ryan         hi acmoore .  got a question re: dbic & chaining for ya.
14:08 acmoore      morning
14:07 ryan         acmoore: around ?
13:57 ryan         gmcharlt: , owen ok, i'll submit a patch.
13:54 owen         That's fine with me. And I'd be willing to undertake wider implementation if everyone agrees.
13:53 gmcharlt     yes
13:53 owen         gmcharlt: RFC to find out if we should implement it throughout?
13:52 gmcharlt     ryan: why not try it out on a Koha form first, then RFC if experiment works
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:50 owen         I've used it in other projects
13:49 owen         I don't think it is
13:49 ryan         ?
13:49 ryan         owen: is this in koha now ?  or i would have to add it to lib
13:46 ryan         owen: looks nice.  i'll use 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:42 ryan         owen: do we have a preferred form validator now ?  or any particularly good paradigm for it ?
13:42 owen         Hi ryan and everyone
13:42 ryan         hi owen
13:30 hdl          hi nengard
13:27 nengard      :)
13:27 nengard      or morning
13:27 nengard      moening
13:25 hdl          hi
13:24 paul_p       good morning danny
13:17 danny        good morning #koha