← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
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 | or morning | |
13:27 | :) | |
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-p[…]lugin-validation/ |
13:46 | ryan | owen: looks nice. i'll use it. |
13:49 | owen: is this in koha now ? or i would have to add it to lib | |
13:49 | ? | |
13:49 | owen | I don't think it is |
13:50 | 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 | 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 | (1) my $rs = $schema->resultset('table')->search_literal( 'column = ?', $data ); | |
14:10 | (2) my $rs = $schema->resultset('table'); | |
14:10 | $rs->search_literal( 'column = ?', $data ); | |
14:10 | ? | |
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 | 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 | 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 | 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 | 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 | 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 | '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/gi[…]?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 | I'd love to see us use either DateTime or C4::Dates for that, though. | |
14:57 | ... and then Business::ISBN or some kind of C4::ISBN. | |
14:58 | paul_p | acmoore: what is #kohanews ? |
14:59 | 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 | it apply in my install | |
15:47 | I just answer you | |
15:47 | (by mail) | |
15:48 | gmcharlt | nahuel: context for first hunk no longer applies |
15:48 | please resend the patch | |
15:48 | nahuel | hmm well, i'll redo it, let me some minutes :) |
15:50 | gmcharlt, sent | |
15:50 | gmcharlt | thanks |
15:51 | nahuel: please see http://blogs.liblime.com/devel[…]-commit-messages/ | |
15:51 | upshot is that "[bug 1234] this and that" is not ideal for commit messages | |
15:51 | nahuel | gmcharlt, already read :) |
15:52 | The patch that have [bug #XXX] subject are older than this blog post | |
15:52 | since I format as (bug #XXX) | |
15:52 | gmcharlt | right, just wanted to make sure you saw it |
15:52 | nahuel | :) |
15:54 | 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 | 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 | 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 | 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 | <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 | 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 | can anyone help me install koha on cpane | |
16:20 | 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 | it makes me feel like I'm neglecting, say, our saudi arabian clients | |
16:42 | or (my favorite example), the lithuanian library we support (w/ 53 diacritical chars!) | |
16:42 | 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 | (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 | (afaik) | |
16:43 | liz | because it doesn't work, right? |
16:43 | or, doesn't work well | |
16:43 | 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 | 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 | but once it's done, they're happy ! | |
16:46 | 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 | 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 | 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 | I think I'm looking at a quite odd bug where it marks lost items as returned: http://git.koha.org/cgi-bin/gi[…]a297184;hb=master line 315 | |
18:34 | Does anyone know why this would be a desired behavior? | |
18:35 | areinmeyer | pianohacker: I've been looking at fines/Accounts recently |
18:36 | 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 | It does seem an odd way to mark it though | |
18:38 | pianohacker | Well, I guess that kinda makes sense |
18:38 | 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 | 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 | 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 | in one fell swoop | |
20:07 | but then you want to do the final bit with the Makefile.PL | |
20:08 | they will rock when they are finished, especially the localisation packages | |
20:08 | vincent has a little todo list | |
20:08 | which im trying to help with | |
20:09 | http://git.debian.org/?p=colla[…]1f48451deca6c87d8 | |
20:10 | if we can get it done before early/mid january | |
20:10 | we wont get it in lenny (already missed that) | |
20:10 | but we will make the cutoff for ubuntu jaunty | |
20:10 | 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 | example: this title - | |
21:28 | Libraries for the future : planning buildings that work : proceedings of the library buildings preconference, June 27 and 28, 1991, Atlanta, Georgia | |
21:28 | stops printing the slip after the first colon | |
21:28 | interestingly also it only hyperlinks the title up to the colon | |
21:29 | in the results list | |
23:26 | atz_ | gmcharlt: I think some review of maxItemsInSearchResults is in order |
23:27 | the feature as a whole is an only superficially implemented idea | |
23:27 | the syspref type should be Integer, not free | |
23:28 | and it actually limits the number of items that appears in each of three categories, not the total number of items | |
23:28 | those categories are not transparent to the user. | |
23:29 | the hardcoded default of 1 item is silly | |
23:30 | this will take a DB rev. to fix correctly | |
23:32 | 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 | or if it should just be purged and forgotten | |
23:34 | 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 |
← Previous day | Today | Next day → | Search | Index