| Time |
S |
Nick |
Message |
| 12:09 |
|
gmcharlt |
slef: i'm with nengard - fine to inclue if blog covers Koha or relevant-to-Koha techie or library topics at least some of the time |
| 12:27 |
|
nengard |
Hi all, got an OPAC question - http://sites.google.com/a/libl[…]opac-details-page you'll see on this page what my OPAC looks like and what the opac.liblime.com looks liked (see the 440 part of this page to the liblime demo - my question is which is the way it will be? |
| 12:30 |
|
nengard |
the tabs across the top on the opac demo and on my install are different - which is right? |
| 12:30 |
|
nengard |
will there be 2 marc tabs across the top? |
| 12:30 |
|
nengard |
also on one it says 'subject(s)' and on the other it says 'related subject(s)' |
| 12:30 |
|
nengard |
which is the newest |
| 12:30 |
|
nengard |
and the one that people using 3.0 will see |
| 12:31 |
|
owen |
"subject(s)" is correct |
| 12:32 |
|
nengard |
okay - so my install is the newest ... which means my install doesn't have the 2 diff marc tabs ... shouldn't it? |
| 12:32 |
|
nengard |
i know this is confusing - sorry |
| 12:32 |
|
owen |
I don't know about the "expanded marc view" |
| 12:32 |
|
owen |
I've never seen that before |
| 12:32 |
|
nengard |
hehe |
| 12:33 |
|
owen |
It's not in the latest version of opac-detail.tmpl |
| 12:34 |
|
owen |
Probably something Liblime was working on? |
| 12:34 |
|
nengard |
maybe... |
| 12:35 |
|
owen |
Ah, so that's what opac-showmarc.tmpl is for |
| 12:36 |
|
owen |
Is that what Bug 2103 is about? The view you get from opac-showmarc.pl? |
| 13:03 |
|
nengard |
owen i think so if you follow the url in my bug and click the different views you'll see what i mean |
| 13:06 |
|
owen |
Yeah, at the moment that bug is invalid because standard git repos don't have that marc/extended marc option...Unless I'm missing something. |
| 13:08 |
|
owen |
Maybe kados can shed some light on it? |
| 13:12 |
|
acmoore |
does anyone know if bugs.koha.org accept mail to add comments to bugs? I can't seem to get it to work. |
| 13:13 |
|
acmoore |
I'd like to send patches to patches koha.org and to something like bugzillakoha.org so that they always show up in the right bug |
| 13:14 |
|
owen |
I like the idea, acmoore, but I haven't heard anything about that |
| 13:14 |
|
owen |
Hi atz |
| 13:22 |
|
atz |
greets owen |
| 13:24 |
|
paul |
owen, i've a small question for you. |
| 13:24 |
|
owen |
OK |
| 13:24 |
|
paul |
isn't koha supposed to auto-detect the browser preffered language and switch to it by default ? |
| 13:24 |
|
paul |
it's not the case atm, and it's annoying for non native english ppl |
| 13:25 |
|
paul |
en is always displayed at login, the users have to click on "Français", and they complain about that |
| 13:25 |
|
owen |
paul, I don't know about that. Is that something you've seen other web applications do? |
| 13:25 |
|
paul |
yep, of course. All browsers have a preffered language list. |
| 13:25 |
|
paul |
do you use firefox ? |
| 13:26 |
|
paul |
Edit > Preferences > Advanced > General > Language |
| 13:26 |
|
paul |
My list has french as 1st language, then en, then en-us |
| 13:27 |
|
owen |
Yes, but how does a web site detect the browser's preferred language? |
| 13:27 |
|
paul |
isn't it given by cookies ? |
| 13:27 |
|
acmoore |
I think it's the Accept-language header |
| 13:28 |
|
paul |
yep, you should be right |
| 13:28 |
|
atz |
owen: usually this is handled by Apache for static HTML sites |
| 13:29 |
|
acmoore |
and it's probably exposed in the CGI object somewhere.... it's presumably possible and I can't imagine it being prohibitively dificult. |
| 13:29 |
|
gmcharlt |
http://search.cpan.org/~cgilmo[…]AcceptLanguage.pm for one approach |
| 13:29 |
|
gmcharlt |
agree, shouldn't be hard to implement |
| 13:30 |
|
atz |
acmoore: should be ENV{HTTP-ACCEPT-LANGUAGE} or somethinge |
| 13:30 |
|
paul |
yep |
| 13:31 |
|
paul |
i'll investigate in this direction, thx |
| 13:31 |
|
acmoore |
There's an example in the CGI docs about $requested_language = http(?Accept-language?); and $requested_language = http(?HTTP_ACCEPT_LANGUAGE?); |
| 13:32 |
|
atz |
i assume those are regexps? |
| 13:32 |
|
atz |
like http(/Accept-language/) ? |
| 13:33 |
|
owen |
paul, where do your users see the language choice at login? |
| 13:33 |
|
acmoore |
I thought those were comma separated lists from the browser. Perhaps the CGI object makes them into perl lists, but I doubt it. |
| 13:33 |
|
paul |
owen : bottom left of the screen |
| 13:34 |
|
owen |
So it doesn't remember that they logged in previously with fr |
| 13:34 |
|
acmoore |
This thing shows the headers that your browser is sending http://www.ericgiguere.com/too[…]eader-viewer.html |
| 13:34 |
|
owen |
Also: http://livehttpheaders.mozdev.org/ |
| 13:35 |
|
owen |
paul, it sounds like there are two questions: 1) Can Koha automatically choose a language for the user; and 2) Why doesn't Koha remember that the user previously logged in with another language? |
| 13:35 |
|
paul |
maybe yes. |
| 13:36 |
|
paul |
2) being the most important |
| 13:36 |
|
atz |
owen: regarding (2), you mean the user themselves, or that particular browser (i.e., cookie) |
| 13:36 |
|
atz |
? |
| 13:36 |
|
paul |
users could be happy if they had to click only once in their life ! |
| 13:36 |
|
owen |
atz: we're talking about the user choosing a translation from the language-chooser menu in the staff client |
| 13:37 |
|
paul |
atz: when you close your browser, your session & preferred language is lost. and you're back to english |
| 13:37 |
|
atz |
right, so you need a new column in borrowers, or a keyed language-prefs table |
| 13:38 |
|
atz |
so that the info is paired w/ the user themselves, and not their browser session |
| 13:38 |
|
paul |
nope, I think it can be achieved through http header preferred language |
| 13:38 |
|
owen |
Shouldn't it be stored in a cookie the way the user's current branch is? |
| 13:38 |
|
owen |
(isn't it?) |
| 13:38 |
|
atz |
paul: how do you think that would affect, for example, a library in Quebec |
| 13:39 |
|
acmoore |
atz, if you associate it with the user information, they're still going to see the english login page because you don't know who they are before they log in. |
| 13:39 |
|
atz |
where they expect the users to switch back and forth |
| 13:39 |
|
paul |
acmoore++ ! |
| 13:39 |
|
owen |
atz: the language-chooser is always present |
| 13:39 |
|
atz |
acmoore: if you *don't* associate it w/ the users, they're going to have to choose more than once |
| 13:40 |
|
paul |
the http header should be used only if there is no koha pref set. |
| 13:40 |
|
atz |
i don't imagine the library lab will expect ppl to reconfigure the browser accept-language headers every time a user sits down to search the OPAC |
| 13:40 |
|
acmoore |
danged if you do, danged if you don't... |
| 13:41 |
|
paul |
nope, it should not. the default language is the one dictated by the header. |
| 13:41 |
|
paul |
if someone choose another one, then stick with it for the session ! |
| 13:42 |
|
acmoore |
so, it sounds like you show the login page in the language of the header, then after they login change to their preferred language if there is one? |
| 13:42 |
|
paul |
not after they login, but as soon as they have choosen one explicitly |
| 13:43 |
|
atz |
that sounds right |
| 13:51 |
|
owen |
hdl around? |
| 13:54 |
|
owen |
atz, can I ask you about book cover images? |
| 14:00 |
|
ryan |
anyone: what's the status of 'Suppress in OPAC' feature ? |
| 14:00 |
|
ryan |
doesn't seem to work. |
| 14:01 |
|
gmcharlt |
ryan: works for me (i.e., setting 942$n = 1), but depends on there being an OpacSuppression syspref |
| 14:01 |
|
gmcharlt |
syspref is not currently defined, but I'll add it |
| 14:01 |
|
atz |
owen: sure |
| 14:01 |
|
owen |
We've got three alternatives now for book cover images, but not all pages in the OPAC which display covers are set up to use all those options |
| 14:02 |
|
atz |
which are lacking? |
| 14:02 |
|
owen |
I'm wondering if we should be copying the relevant code to each script, or is there a more unified way of handling it? |
| 14:03 |
|
owen |
I'm thinking of opac-user, opac-shelves, opac-readingrecord, maybe even opac-basket |
| 14:04 |
|
ryan |
gmcharlt: grea, thx. |
| 14:04 |
|
atz |
the Amazon code and B&T code are roughly similar, the Google code is orthogonal |
| 14:04 |
|
ryan |
we need a way to handle it... I have some test info for syndetics jacket images |
| 14:04 |
|
ryan |
the templates are going to get messy |
| 14:05 |
|
atz |
the cleanest way would be google style AJAX |
| 14:05 |
|
owen |
Instead of linking to an image, we could have the <img> tag link to a script that returned image data |
| 14:05 |
|
atz |
it avoids you having to get into each "hit" element and conditionalize a host of image options in the template |
| 14:06 |
|
atz |
owen: in that case the server has to throughput all the image content |
| 14:06 |
|
owen |
The <img> could be wrapped in a link that pointed to a variable so that Baker and Taylor could point to their sales pages if necessary |
| 14:07 |
|
owen |
I'll defer to you on that one atz |
| 14:07 |
|
atz |
imho, it's probably not the way to go here, and may violate content providers' terms of service |
| 14:08 |
|
atz |
owen: have you looked at the mechanism google uses in js? |
| 14:09 |
|
atz |
i'm wondering if we can use the same identifier internally w/ our own js |
| 14:09 |
|
owen |
atz, my concern there is for non-js users |
| 14:09 |
|
atz |
yeah, they would still need potentially messy templates |
| 14:10 |
|
atz |
but at least you could enable some failover for script-capable browsers |
| 14:10 |
|
owen |
I don't see how that could work well... What would it failover to? |
| 14:11 |
|
atz |
other image sources! |
| 14:13 |
|
owen |
Right, but then we're back to having all the static markup in the template |
| 14:14 |
|
owen |
I'm assuming that if someone chooses Google Jackets that's because they want Google Jackets and not Amazon images. |
| 14:14 |
|
atz |
that's the eventual goal for jacket images... allow the library to select the image sources they want to use, and rank them in the preferred order. this req's js to process whether the first ajax request failed, the second, and so on. |
| 14:16 |
|
atz |
owen: right now I don't see any easy way to share code in the various opac pages |
| 14:16 |
|
hdl |
owen: am here now |
| 14:16 |
|
owen |
Okay atz, thanks. It was worth a try :) |
| 14:16 |
|
atz |
i'm pretty sure that a repeated INCLUDE (i.e., for each hit element) would be bad for performance |
| 14:17 |
|
atz |
since I believe that H:T:P would re-read and reparse the included file each time (unlike a loop) |
| 14:19 |
|
owen |
hdl, I just submitted a patch that adds the necessary YUI library files to the OPAC. These were missing following the changes to the YUI path pref. |
| 14:22 |
|
slef |
what's the scope of the "search koha.org" box on www.koha.org? anyone know? |
| 14:23 |
|
slef |
is it just www.koha.org or all koha.org sites? |
| 14:24 |
|
hdl |
owen : tx |
| 14:24 |
|
hdl |
owen++ |
| 14:29 |
|
hdl |
owen : just seen your bug report on local |
| 14:29 |
|
hdl |
yuipaht |
| 14:30 |
|
hdl |
I think this is owed to the fact that this page is not using C4::Output to output. |
| 14:33 |
|
slef |
lloyd's connection isn't in a happy place today, I guess |
| 14:34 |
|
ryan |
mysql case sensitivity-- |
| 14:38 |
|
owen |
Hi bb_marblehead |
| 14:40 |
|
Brooke |
whazzah? |
| 14:41 |
|
ryan |
does anyone see a problem with making the collation on marc_subfield_structure utf8_bin by default ? |
| 14:42 |
|
Brooke |
That would seem to be logical |
| 14:42 |
|
ryan |
currently, if you add an uppercase subfield code, it will overwrite your lowercase code. |
| 14:42 |
|
Brooke |
teh ohnoes! |
| 14:43 |
|
gmcharlt |
ryan++ # definitely ouchie not allowing uppercase subfield labels |
| 14:49 |
|
bb_marblehead |
hi owen |
| 14:50 |
|
bb_marblehead |
owen: do you have time for a quick call? |
| 14:51 |
|
hdl |
ryan : are subfield codes cas sensitive in MARC21 ? |
| 14:52 |
|
gmcharlt |
hdl: MARC21 doesn't generally use uppercase subfield codes, but they are case-senstive in ISO2709 and are sometimes used for local data |
| 14:55 |
|
hdl |
I like the idea of case sensitivity for subfield codes. But is MARC::Record case safe for subfield codes ? |
| 14:55 |
|
gmcharlt |
hdl: pretty sure it is |
| 14:56 |
|
hdl |
(just a question... I know I had to migrate data with subfield codes in UPPER and lower case) |
| 14:57 |
|
atz |
gmcharlt: did you get a chance to look at the C4::Scrubber patch? |
| 15:01 |
|
gmcharlt |
atz: looks OK. as you mentioned in comments, more POD is called for, but I'm figuring you ran out of time |
| 15:02 |
|
atz |
true |
| 15:02 |
|
owen |
bb_marblehead: I do now |
| 15:05 |
|
ryan |
hdl: so no problems for unimarc making the change for marc_subfield_structure ? |
| 15:05 |
|
hdl |
ryan: seems ok for me. |
| 15:09 |
|
owen |
Has anyone been testing in Internet Explorer 7? I can't seem to stay logged into Koha in IE7. Every link I click, I'm forced to log in again. |
| 15:10 |
|
Brooke |
I used to use IE for Koha, but it became frustrating |
| 15:11 |
|
Brooke |
whoever's headache it is making Koha work round Microsnot's bad code has my undying gratitude |
| 15:11 |
|
owen |
That's me, among others :( |
| 15:11 |
|
owen |
We were pretty lax about IE compatibility before, and we're trying to do better. |
| 15:12 |
|
bb_marblehead |
owen: can you please email me your # ... i have misplaced it |
| 15:14 |
|
Brooke |
that's a good thing, and worth the fuss, it's still what folks use most |
| 15:14 |
|
gmcharlt |
owen++ |
| 15:14 |
|
gmcharlt |
IE-- |
| 15:15 |
|
owen |
slef: We make every attempt to code to standards |
| 15:41 |
|
eric |
slef: I'm watching you about your Quebec French... :) |
| 15:46 |
|
paul |
tabernacle !!! |
| 15:48 |
|
owen |
What kind of information should I see in a biblio's modification log? If I modify a MARC record, should viewlog.pl show that? |
| 15:52 |
|
sawariwap |
any news for koha's RC or release? |
| 15:53 |
|
slef |
sawariwap: plenty, but no date AIUI :) |
| 15:53 |
|
slef |
sawariwap: send help, we're going to advance |
| 15:54 |
|
slef |
eric: given number of compliments I've had about the last day's emails, I think I should answer 6000 emails all at once more often ;-) |
| 15:57 |
|
bb_marblehead |
owen: you around? |
| 15:57 |
|
owen |
Yes |
| 15:57 |
|
bb_marblehead |
how is 3:30 for a call with eric? |
| 15:57 |
|
owen |
That'd be okay |
| 15:58 |
|
eric |
bb_marblehead, a call about what? |
| 15:59 |
|
bb_marblehead |
sorry wrong eric |
| 15:59 |
|
eric |
Ha, ok :) np |
| 17:07 |
|
acmoore |
gmcharlt, I improved the developer docs a bit to include some of the improvements that you and I have been adding to the test suite: http://wiki.koha.org/doku.php?[…]ment:unit_testing |
| 17:07 |
|
acmoore |
There's more to go, but this may help others contribute to the growing test suite. |
| 17:08 |
|
acmoore |
oh, and if anyone else has questions about how to use or extend the test suite, please don't hesitate to ask. It will help me improve the documentation because I can assure you that you're not the only one with questions. |
| 17:08 |
|
gmcharlt |
acmoore: looks good - thanks |
| 17:10 |
|
acmoore |
There's lots of stuff I think I can improve on the wiki, now that I'm getting more comfortable with the application and the processes around here. Now, I just have to get comfortable with yet another wiki syntax and quirks. ;) |
| 17:11 |
|
gmcharlt |
acmoore: at least this one has decent syntax highlighting |
| 17:12 |
|
acmoore |
yeah, I noticed that. |
| 17:14 |
|
acmoore |
gmcharlt, on a similar topic, do you think that the SQL stuff at http://wiki.koha.org/doku.php?[…]ingguidelines#sql should be updated to reflect the desire to use placeholders instead of cramming variables into SQL statements? |
| 17:14 |
|
gmcharlt |
acmoore: definitely |
| 17:15 |
|
gmcharlt |
feel free to add as much wording about how whole kindles of kittens will cry if placeholders are not used |
| 17:16 |
|
gmcharlt |
as you care to |
| 17:20 |
|
danny |
lol |
| 17:20 |
|
acmoore |
I thought there was a discussion about this in "Perl Best Practices", but I can't find it now. I was hoping to reference it. |
| 17:21 |
|
acmoore |
Maybe I'll just mention that if you fail to use placeholders, it makes me have to come in behind you, write tests, and refactor your code... |
| 17:33 |
|
acmoore |
I notice that there's discussion of a $VERSION variable on that page, too. Is that number supposed to be the same in all files? |
| 17:34 |
|
acmoore |
perhaps we would benefit from an automated test to check that. |
| 17:34 |
|
gmcharlt |
acmoore: in practice, no use is made of the $VERSION declared in the C4 modules |
| 17:34 |
|
gmcharlt |
acmoore: some sort of use could be made, obviously, but would have to be thought through carefully |
| 17:35 |
|
acmoore |
then, perhaps they're deprecated? |
| 17:38 |
|
gmcharlt |
acmoore: IMO, effectively yes - but could change if we get serious about turning C4 into an actual API meant for consumption outside of the core Koha scripts, which would imply API versioning, backwards compatibility, etc. |
| 17:40 |
|
acmoore |
sounds like YAGNI. Shall I remove that paragraph from the documentation? |
| 17:41 |
|
gmcharlt |
fine with me |
| 17:41 |
|
atz |
gmcharlt: i actually use the VERSION'd version of use |
| 17:41 |
|
acmoore |
ahh! cool. where do you use that? |
| 17:42 |
|
atz |
/home/atz/koha/production/koha/tags/review.pl |
| 17:42 |
|
atz |
for example |
| 17:42 |
|
atz |
use C4::Tags 0.02 qw(get_tags get_approval_rows whitelist blacklist is_approved); |
| 17:43 |
|
atz |
but I am clearly the exception |
| 17:43 |
|
gmcharlt |
atz: then please stop - I applaud the impulse, but this needs to be done throughout Koha or not at all |
| 17:44 |
|
acmoore |
is that because the current C4::Tags doesn't have the functionality you need yet? I notice mine is 0.01. |
| 17:44 |
|
atz |
well, we added VERSIONs to C4 |
| 17:44 |
|
atz |
acmoore: right, mine is newer |
| 17:45 |
|
atz |
gmcharlt: how is it harmful to have in only portions of the codebase? (besides possible developer confusion about the correct convention) |
| 17:45 |
|
atz |
? |
| 17:46 |
|
gmcharlt |
because of possible developer confusion about the correct convention |
| 17:46 |
|
atz |
do you see VERSION numbers regressing at some point? |
| 17:46 |
|
acmoore |
reasonable use, I guess. This prevents your tags/review.pl from getting used with an old C4::Tags. Shouldn't that get enforced by the fact that you presumably check them both in at once, though? |
| 17:46 |
|
gmcharlt |
IMO, we should not pretend that the API is properly versioned, stable, or backwords compatible |
| 17:46 |
|
gmcharlt |
until such time as C4 meets those conditions |
| 17:47 |
|
atz |
acmoore: yes, but in case my patches get applied only partially or at different times, this catches it immediately |
| 17:47 |
|
atz |
gmcharlt: so I can't pretend w/ Tags, even if it is? |
| 17:47 |
|
acmoore |
valid point. it's also clear why it's failing when it says "you need 0.02, and you only have 0.01" instead of saying "I can't find the get_tags method in C4::Tags", I guess. |
| 17:48 |
|
atz |
i agree that Koha as a whole certainly doesn't exhibit those features |
| 17:48 |
|
acmoore |
it seems like that versino number should be 3.0, though. |
| 17:49 |
|
gmcharlt |
yes, applying a 3.0 version to the whole C4 API is about as far as we can go, realistically |
| 17:50 |
|
atz |
acmoore: yeah, there's been some discussion on that. i'm not sure where I stand on it... 3.0 suggests things that this "experimental" feature doesn't have yet |
| 17:50 |
|
acmoore |
but, then, that doesn't really allow atz's use. |
| 17:50 |
|
gmcharlt |
atz: the issue is the moment somebody else touches C4::Tags, the proper versioning can get broken - we're not at the point, if we'll ever get there, where mistakes would get caught |
| 17:51 |
|
acmoore |
I didn't mean to open this large of a can of worms... |
| 17:51 |
|
gmcharlt |
acmoore: don't worry, this has been a long-running debate |
| 17:51 |
|
acmoore |
haha. great. |
| 17:51 |
|
gmcharlt |
as far as partial patch intake is concerned, that would be one thing for the test cases to catch |
| 17:51 |
|
atz |
gmcharlt: true enough... though not really any different than the versioning getting broken w/o the VERSION indicator |
| 17:53 |
|
acmoore |
the concern about other people touching C4::Tags and breaking versioning could be ameliorated if it were automatically increamented upon checkin, I think. Isn't that what CVS used to do? |
| 17:53 |
|
gmcharlt |
and something where acmoore's idea about patches being automatically attached to bugs could come into play - I'm not sure how I feel about automatically including the entire patch because of potential DB noise considers), but storing the git hahses of the patches could be useful |
| 17:53 |
|
atz |
acmoore: actually, that's not the problem... the problem is my new-feature dependent client-code would THINK it was getting the new version when somebody else checked in a minor unrelated update |
| 17:54 |
|
acmoore |
gmcharlt, I would prefer the whole bug be included, but not very strongly. Mainly, I just want an easy way to get to the changes that were made for a particular bug. |
| 17:54 |
|
acmoore |
atz, that's valid. |
| 17:55 |
|
acmoore |
I wonder how other people deal with this. We're not the first gang to start putting $VERSION in a few dozen files. |
| 17:55 |
|
atz |
so, that's a few laps around the VERSIONing debate track. |
| 17:55 |
|
acmoore |
atz, heh. Thanks for humoring me. |
| 17:55 |
|
gmcharlt |
acmoore: my preference is for something that auto-links between the bugs and the patches as displayed in gitweb - because a git RM and QA can sometimes modify patches, gitweb is more authoritative |
| 17:56 |
|
acmoore |
gmcharlt, super. How do we do that? |
| 17:56 |
|
slef |
acmoore: version control generating/updating the variable from tags, I think |
| 17:57 |
|
gmcharlt |
acmoore: perhaps some sort of git commit hook that requires that a commit description include a bug number in some parsable format, then a bit of customization of gitweb to allow a search on bug number - something like that |
| 17:58 |
|
slef |
acmoore: "changes that were made for a particular bug" - ideally, grep the git log --format=online output for the bug number, then cherry-pick the git commits |
| 17:58 |
|
gmcharlt |
acmoore: or if not requires, encourages |
| 17:58 |
|
slef |
but I've not tested that, sorry |
| 17:59 |
|
acmoore |
gmcharlt, I can see that working. Unfortunately, it requires hacking on gitweb a bit. If git send-email would send the patches to bugzilla to be included, we wouldn't have to do that. |
| 17:59 |
|
acmoore |
gmcharlt, Or, perhaps a git post-commit hook to send the hash or a gitweb link to bugzilla? |
| 18:00 |
|
gmcharlt |
acmoore; but then you're back to the issue that a patch stored in bugzilla is not necessarily the final version, or not necessarily accepted |
| 18:00 |
|
acmoore |
slef, that works pretty well, I guess. I'll see if I can whip up a shell script for that. |
| 18:01 |
|
gmcharlt |
storing the commit hash, though, would be enough I think to generate a link to that patch in gitweb, if/when the patch is accepted |
| 18:01 |
|
acmoore |
gmcharlt, that's fine. In fact, it may be useful for me to see the several versions of patches that I submitted relevant to a particular bug. Those patches are relveant to that bug, but right now there's no easy way to find them or know that they exist from bugzilla. |
| 18:02 |
|
acmoore |
gmcharlt, seeing unaccepted patches is useful, too. You can tell that I've submitted patches that fix your bug. You can see if they implement what you asked for, and you can tell that ther'e's progress being made on your request. Also, you can bug RM or QA to look at them. |
| 18:02 |
|
acmoore |
not a strong argument, but one nonetheless. |
| 18:03 |
|
acmoore |
gmcharlt, your point about patches being modified by RM or QA is very valid, though. I'd like links to accepted patches, too. |
| 18:03 |
|
acmoore |
whether it's gitweb, full text, hashes, or what. |
| 18:04 |
|
gmcharlt |
acmoore: valid point; but my preference for attaching patches in a bug database is to use them for communication - i.e., I'm not sure about how to fix something, I propose a patch, attach it to the bug, and ask for comments - I would want that use case to be distinguishable for linking accepted patches automatically |
| 18:05 |
|
gmcharlt |
distinguishable *from* |
| 18:06 |
|
acmoore |
yes, I follow and agree. They're different times that patch information is useful to bugzilla users. It should indicate where the patch came from or something to let users know what state the patch is in. |
| 18:07 |
|
acmoore |
for example: "This patch was submitted by GMC to patcheskoha.org yesterday..." or "Hi, folks, Here's my suggestion... -GMC" or "This patch went into HEAD at 10AM..." |
| 18:07 |
|
acmoore |
maybe we start from the places where we can agree that there is usefulness and build from there. |
| 18:08 |
|
acmoore |
it sounds like information about accepted patches is viewed as useful and not harmful. |
| 18:09 |
|
acmoore |
I'm not sure if that information is links, hashses, or what. Is there a technically easy way that we can do something like that? |
| 18:11 |
|
acmoore |
perhaps I'll look into WWW::Bugzilla to see if I can make a post-commit hook or something. |
| 18:12 |
|
gmcharlt |
acmoore: useful, but considerations apply: displaying them well, not overwhelming a bug history log with them |
| 18:13 |
|
gmcharlt |
the hash that identifies the commit (e.g., d2e27ff482863c9792c2bbe8e81f299caf62119d for my C4::Scrubber test case patch) is can be used to link directly to gitweb |
| 18:41 |
|
ryan |
gmcharlt: i have noticed that you seem to successfully submit patches with multiline commit messages. do you do something special ? |
| 18:43 |
|
gmcharlt |
ryan: a local copy of git 1.5.5 - i.e., may be due for an upgrade on our servers |
| 18:44 |
|
gmcharlt |
ryan: debian has 1.5.4.2-1 in etch-backports and 1.5.5 in lenny |
| 18:45 |
|
ryan |
ah. you are running lenny in a vm? |
| 18:45 |
|
gmcharlt |
no, just a local copy of git on arwen |
| 18:46 |
|
ryan |
ok, thx |
| 18:46 |
|
gmcharlt |
I'm 99% certain that the version packaged in etch-backports fixes the email bug, tho |
| 18:46 |
|
ryan |
ok. will have to update |
| 19:09 |
|
ryan |
owen: around ? |
| 19:09 |
|
owen |
Yes |
| 19:10 |
|
ryan |
Can you explain the paging paradigm on cgi-bin/koha/admin/marc_subfields_structure.pl |
| 19:11 |
|
ryan |
the link is generated in the script. |
| 19:11 |
|
ryan |
is this an old way to do it or a new way to do it ? |
| 19:11 |
|
ryan |
(i'm assuming old way) |
| 19:16 |
|
owen |
(Sorry phone) Yeah, it's an old way as far as I know |
| 19:24 |
|
ryan |
ok, thx |
| 20:33 |
|
chris |
morning |
| 20:35 |
|
paul |
hello chris |
| 20:35 |
|
chris |
hi paul |
| 20:59 |
|
paul_bed |
bye world. I'll be away from irc until next monday |
| 21:01 |
|
chris |
sleep well paul |
| 21:37 |
|
hdl |
ryan : which link wer you talking about ? |
| 21:37 |
|
hdl |
is this link between subfields ? |
| 21:38 |
|
hdl |
If it is this, then the new way to use this framework parameter is to put index code in it. |
| 21:57 |
|
kados |
hdl: just pushed up your patch from yesterday |
| 21:59 |
|
kados |
gmcharlt: oops, just noticed you had a version of that one in there |
| 21:59 |
|
kados |
gmcharlt: was there a change from hdl's? |
| 22:00 |
|
gmcharlt |
kados: no - just one I had picked off and tested so that I can build another DB rev on top of it w/o integrate problems |
| 22:23 |
|
kados |
hdl: can you sign off on galen's patch for unimarc_complet framework: put 801$a in tab 8 ? |
| 23:11 |
|
atz |
i think i finally fixed pagination_bar to be marginally intelligent |
| 23:11 |
|
atz |
so it will pull it's "page" variable out of the base_url that it is passed |
| 23:50 |
|
atz |
any reason my members page is only showing the first member of any given alphabet letter? |
| 00:06 |
|
gmcharlt |
atz: members/member.pl? not seeing this in my DB - rebased a couple minutes ago |
| 00:06 |
|
atz |
interesting... |
| 00:08 |
|
atz |
I get: Results 1 to 1 of 1 found for 'a' |
| 00:09 |
|
atz |
mysql> select surname,userid from borrowers where surname LIKE "a%" ORDER BY surname; |
| 00:09 |
|
atz |
+-----------+----------------+ |
| 00:09 |
|
atz |
| surname | userid | |
| 00:09 |
|
atz |
+-----------+----------------+ |
| 00:09 |
|
atz |
| Acevedo | 23529000035676 | |
| 00:09 |
|
atz |
| Acosta | 23529001000463 | |
| 00:09 |
|
atz |
| Admin | NULL | |
| 00:09 |
|
atz |
| Albertson | aaa | |
| 00:09 |
|
atz |
| Alford | 23529000050113 | |
| 00:09 |
|
atz |
+-----------+----------------+ |
| 00:09 |
|
atz |
5 rows in set (0.00 sec) |
| 00:09 |
|
atz |
the patron displayed is albertson, who happens to have the userid "aaa" |
| 00:10 |
|
atz |
i suspect the search is trying to be "smart" and taking a LIKE USERID "%$x" match as definitive |
| 00:10 |
|
atz |
gmcharlt: you might be able to short circuit your match by adjusting patron data similarly |
| 00:11 |
|
gmcharlt |
atz: look at that code recently - I think its actually exact match on cardnumber, not userid - does that patron have cardnumber = 'a' |
| 00:11 |
|
gmcharlt |
I looked at the code, I'm |
| 00:12 |
|
gmcharlt |
I mean |
| 00:12 |
|
atz |
mysql> select surname,userid,cardnumber from borrowers where surname LIKE "a%" ORDER BY surname; |
| 00:12 |
|
atz |
+-----------+----------------+----------------+ |
| 00:12 |
|
atz |
| surname | userid | cardnumber | |
| 00:12 |
|
atz |
+-----------+----------------+----------------+ |
| 00:12 |
|
atz |
| Acevedo | 23529000035676 | 23529000035676 | |
| 00:12 |
|
atz |
| Acosta | 23529001000463 | 23529001000463 | |
| 00:12 |
|
atz |
| Admin | NULL | 1 | |
| 00:12 |
|
atz |
| Albertson | aaa | 23529001223638 | |
| 00:12 |
|
atz |
| Alford | 23529000050113 | 23529000050113 | |
| 00:12 |
|
atz |
+-----------+----------------+----------------+ |
| 00:12 |
|
atz |
5 rows in set (0.00 sec) |
| 00:12 |
|
atz |
apparently normal cardnumber |
| 00:14 |
|
atz |
hmm... my theory doesn't hold up though. I change his userid to 'bbb' and he's still the only one on the page for "a" |
| 00:16 |
|
gmcharlt |
another possibility - is IndependentBranches on? |
| 00:16 |
|
atz |
good question |
| 00:16 |
|
gmcharlt |
if so, and if you're logged in with a branch assigned, only patrons of that branch will show up |
| 00:17 |
|
atz |
ah, indeed, independent branches is on. it must not normally care if you are the koha root (no default branch) |
| 00:19 |
|
atz |
but I'm logged in as my test dude "rch" :) |
| 00:19 |
|
gmcharlt |
then the answer is clear - we can blame everything on rch! ;-) |
| 00:20 |
|
atz |
thx for the sanity check |
| 00:20 |
|
gmcharlt |
atz: you'll like this one - NZanalyze, which is a recursive sub, can be made to loop infinitely in perl 5.10 where it terminates when running under 5.8 |
| 00:20 |
|
atz |
d'oh! |
| 00:21 |
|
atz |
who discovered that nicety? |
| 00:23 |
|
gmcharlt |
MatthewMetzger (bug 2020) - I just now am in the process of determing exactly *why* it does this - looks to be a subtle change in perlre and how capture variables work |
| 00:24 |
|
atz |
i was just reading a ton about look-ahead and look-behind REs |
| 00:24 |
|
atz |
i think the behavior of compound zero-width look-aheads did change |
| 00:25 |
|
gmcharlt |
looking at it more, appears to be a perlre bugfix - a failed match is not supposed to change $1, $2, etc., but I seem to be looking at a case that where it does |
| 00:26 |
|
gmcharlt |
(in 5.8, that is) |
| 00:26 |
|
atz |
we depend on backrefs from failed matches? |
| 00:26 |
|
atz |
seems lame |
| 00:30 |
|
atz |
# parse the string in in operator/operand/value again |
| 00:30 |
|
atz |
$string =~ /(.*)(>=|<=)(.*)/; |
| 00:30 |
|
atz |
my $left = $1; |
| 00:30 |
|
atz |
my $operator = $2; |
| 00:30 |
|
gmcharlt |
it's actually a valid technique (i.e., you're *supposed* to be able to use capture variables from the last successful match, even if you've made failing ones), but not used well (or intentionally, AFAIK) in NZanalyse |
| 00:30 |
|
atz |
my $right = $3; |
| 00:30 |
|
atz |
# warn "handling leaf... left:$left operator:$operator right:$right" if $DEBUG; |
| 00:30 |
|
atz |
unless ($operator) { |
| 00:30 |
|
atz |
$string =~ /(.*)(>|<|=)(.*)/; |
| 00:30 |
|
atz |
$left = $1; |
| 00:30 |
|
atz |
$operator = $2; |
| 00:30 |
|
atz |
$right = $3; |
| 00:30 |
|
atz |
warn "handling unless (operator)... left:$left operator:$operator right:$right" if $DEBUG; |
| 00:30 |
|
atz |
} |
| 00:31 |
|
atz |
so what happens if ($operator) and |
| 00:31 |
|
atz |
string fails the match inside conditional? |
| 00:35 |
|
atz |
seems some of those REs could benefit from using "non memory" clusters where appopriate |
| 00:44 |
|
atz |
$string =~ s/( and| or| not| AND| OR| NOT)\1/$1/g # <<also dicey |
| 00:44 |
|
atz |
gmcharlt: that line has the comment => "# delete repeated operator... Would then go in infinite loop" |
| 00:45 |
|
atz |
so I'd say that is a likely candidate! |
| 00:46 |
|
gmcharlt |
actually, it's the match at 1585 that seems to be the weak spot |
| 00:46 |
|
gmcharlt |
got a minimal test case ready - just a sec |
| 00:48 |
|
gmcharlt |
atz: http://pastebin.com/d4ab26ceb |
| 00:49 |
|
gmcharlt |
different results when run in 5.8 vs. 5.10 |
| 00:49 |
|
gmcharlt |
in both cases, the match fails the second go around, as it should |
| 00:49 |
|
gmcharlt |
but in 5.8, the failure changes $1 to 'ice' and clears $2 and $3 |
| 00:50 |
|
gmcharlt |
and in 5.10, it does the documented thing of leaving those vars alone (i.e., $1="mice", $2=" and ", $3="men") |
| 00:50 |
|
gmcharlt |
and the apparent regular expression bug in 5.8 accidentally prevents an infinite loop |
| 01:17 |
|
atz |
interesting... that test looks definitive |
| 01:20 |
|
atz |
gmcharlt: note that 5.8 will get to level 4 if I change the trailing * to a + |
| 01:20 |
|
atz |
updated pastebin w/ that revision if you want to see it |
| 01:21 |
|
gmcharlt |
atz: so only certain kinds of failed matches will reset the match variables |
| 01:21 |
|
gmcharlt |
I'm not positive, but this might be the relevant bug: http://rt.perl.org/rt3/Public/[…]lay.html?id=19049 |
| 01:23 |
|
gmcharlt |
and the corresponding fix: http://public.activestate.com/[…]erlbrowse/p/29279 |
| 01:25 |
|
atz |
so, if we were to talk out the regexp /(.*?)( and | or | not | AND | OR | NOT )(.*)/ |
| 01:25 |
|
atz |
it's looking for a minimal match on the front end? and a potentially empty match on the back? |
| 01:26 |
|
atz |
what is intended for (.*?) ? |
| 01:26 |
|
gmcharlt |
left hand of search string if a and/or/not operator is used |
| 01:28 |
|
gmcharlt |
I think solution is to test that the regexp at line 1585 actually matches - if it does, we can use $1, $2, $3 - if it doesn't, we're at a leaf and don't care if $1 had gotten clobbered |
| 01:29 |
|
atz |
i get that. I'm saying why is it .*? and not .+? |
| 01:29 |
|
atz |
are we OK w/ getting empty left and right elements? |
| 01:29 |
|
gmcharlt |
hmm - not sure - maybe to allow a unary not operator |
| 01:30 |
|
atz |
you're right though... it's a bug.... in NO case should left match "ice" |
| 01:31 |
|
gmcharlt |
looks like it shouldn't crash if NZanalyze is passed an empty string as its arg |
| 01:32 |
|
atz |
gmcharlt: aha! |
| 01:32 |
|
atz |
if you rework your regexp so that the spaces are outside the parens for $2 |
| 01:32 |
|
atz |
you also get 5.8 to level 4 |
| 01:33 |
|
atz |
keeping the spaces around the operator provides a whitespace operand later |
| 01:33 |
|
atz |
/(.*?) (and|or|not|AND|OR|NOT) (.*)/ |
| 01:34 |
|
atz |
still matches the same strings, but $2 is tighter |
| 01:34 |
|
atz |
that is a logical way to revise NZanalyse in any case |
| 09:18 |
|
frederic |
hi |
