| Time |
S |
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-p[…]lugin-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/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 |
|
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/devel[…]-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/gi[…]a297184;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=colla[…]1f48451deca6c87d8 |
| 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 |
