IRC log for #koha, 2008-05-14

All times shown according to UTC.

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 bugzilla@koha.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 patches@koha.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

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary