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