Evergreen ILS Website

IRC log for #evergreen, 2013-06-04

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:23 wjr joined #evergreen
00:24 jeff_ joined #evergreen
00:26 Guest1958 joined #evergreen
00:46 jeff_ joined #evergreen
00:48 wjr joined #evergreen
00:57 Guest28303 joined #evergreen
01:07 zerick joined #evergreen
03:38 Mark__T joined #evergreen
06:44 elene joined #evergreen
07:32 bkuhn joined #evergreen
07:49 rangi joined #evergreen
07:49 rangi joined #evergreen
07:51 timf joined #evergreen
08:14 kmlussier joined #evergreen
08:20 akilsdonk_ joined #evergreen
08:24 paxed blah.
08:53 Dyrcona joined #evergreen
08:54 Meliss joined #evergreen
08:56 paxed *grmbl* how do i use util.money.* in non-xul context, specifically in PO views?
08:57 paxed (that's re bug 1156545)
08:57 pinesol_green Launchpad bug 1156545 in Evergreen "Currency symbol and format should not be in po-file translatable texts" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1156545
09:08 Hagerstown_Staff joined #evergreen
09:08 mllewellyn joined #evergreen
09:14 kmlussier I'm trying to fresh my memory on how holdings information is sorted in the record details. My recollection is it's first sorted by library (with preferred library at the top) and then by call number. Are parts ever a factor in how the holdings are sorted?
09:15 * dbs will take a quick look
09:16 mrpeters joined #evergreen
09:16 kmlussier That was refresh my memory, not fresh my memory. :-/
09:17 dbs sounds like a gum commercial
09:18 kmlussier :D
09:18 dbs basic_opac_copy_query orders by aou.name then acn.label
09:18 dbs now to check if mk_copy_query adds anything to that part of the mix
09:20 dbs nothing to do with parts there; adds in aou by rank first, and adds copy status as a tie breaker, but nothing more
09:20 * dbs guesses that we'll never converge on a single unapi call to rule & consistentize them all
09:20 kmlussier dbs: Thanks for checking! I tried looking at the code myself, but got lost.
09:21 dbs I guess that means that prefixes and suffixes don't come into play either
09:21 mrpeters where would one find the actual error message for an A/T event that has a state of "error"?
09:22 kmlussier dbs: Yeah, I think we knew affixes didn't come into play, but I've heard that we would like them to.
09:22 Callender joined #evergreen
09:23 kmlussier I had a request to sort by library name, then call number, then part, which makes sense. However, they want the parts to sort numerically so that 9 comes before 10. But I also know that we don't always use numbers in our parts, so I don't know how feasible that would be.
09:23 dbs kmlussier: this is where someone says "See? _That's_ why we have libraries that don't want to use the per-call-number affixes and just jam them into the labels." :)
09:24 Dyrcona dbs: We didn't use prefixes because they were brand new when we migrated, and our previous ILS put everything in one field.
09:24 kmlussier I wouldn't object to making affixes part of the sort. I think I've advocated for that in the past, though, now that I think about it, I don't think I ever filed anything in Launchpad.
09:25 kmlussier Even when the previous ILS used prefixes, they are messy to migrate.
09:25 Dyrcona kmlussier: It is easy to sort numbers numerically from 1 to infinity without leading zeroes, not so easy when sorting numbers and letters that way.
09:26 * kmlussier nods.
09:26 dbs Teaching part sorting to understand that 10 should come after 1 and 9 would require normalizing like labels. Whee :)
09:26 * Dyrcona jacks on the redundancy port of redundancy.
09:27 dbs We need an ILS. And by ILS, I mean "integrated label system"
09:28 Dyrcona Heh.
09:28 Dyrcona We need a 787 and they gave us this old space shuttle, and I think it is the Soviet model, too. ;)
09:41 jdouma joined #evergreen
09:48 dboyle joined #evergreen
09:58 fparks_ joined #evergreen
10:03 mtcarlson joined #evergreen
10:03 dbwells joined #evergreen
10:04 dboyle_ joined #evergreen
10:17 jdouma_ joined #evergreen
10:24 mrpeters is there a specific log file that should tell me why an A/T event is erroring out after going through the whole pending > found > collected > validating process?   I'm not finding any related messages in the logs except the state changes in the pg logs...
10:25 tsbere Main opensrf logging might tell you something.
10:25 tsbere Is there an error output on the event?
10:26 mrpeters the state just says error
10:27 tsbere no error_output value?
10:27 mrpeters will have to get back to you on that
10:27 mrpeters starting fresh 1 more time
10:27 eby jeff: pm
10:28 mrpeters but actually, no, error_output is null
10:39 bshum Yeah, I'd probably look at the main opensrf logs too.  And try to trace down the ID for the specific A/T event that failed.  And then follow the processes surrounding it for some ideas.
10:40 bshum If it was an actual A/T definition error like a bad environment or such I'd expect that to show more prominently in the logs as an actual error.
10:40 bshum At least, mine have in the past
10:44 mrpeters thanks
10:48 bshum Sigh... I hate apostrophes
10:49 bshum So, apparently, people are now coming to the realization that performing a search without the apostrophe no longer retrieves the result.
10:49 bshum So "men's health" works, but "mens health" does not.
10:50 bshum An odd 2.4 issue with new QP maybe?
10:51 dbs "men's health" becomes "men","s","health" in the tsv column I assume
10:51 bshum Probably.
10:51 bshum Cause if I search for "men s health" as the search I get the same hits.
10:51 bshum But I can check the DB.
10:52 _zerick_ joined #evergreen
10:53 _zerick_ joined #evergreen
10:53 36DAAQ1DZ joined #evergreen
10:55 dbs SELECT search_normalize('men''s health'); returns "men s health"
10:55 bshum That'd do it.
10:56 dbs I'm sort of surprised that the stemmer doesn't remove the "s" from "mens" though. It seems to for me
10:57 bshum Hmm :(
10:57 dbs SELECT ts_debug('english_nostop', 'mens health'); -- shows that the "mens" gets stemmed to "men"
10:58 dbs So it should match, methinks.
10:59 _zerick_ joined #evergreen
11:00 tspindler joined #evergreen
11:04 Dyrcona dbs: mens health doesn't match men's health on my catalog, either.
11:04 bshum Well, I just tested that search on MVLC and SCLEND's catalogs and neither returned expected results
11:05 bshum Oh, heh
11:05 dbs Looks like your thinking that new QP might be playing a role might be a reasonable theory. I'm seeing the same difference on our 2.4 test server vs our 2.3 production server
11:06 dbs Is SCLENDs on 2.4?
11:06 dbs I assume MVLC is.
11:06 gmcharlt dbs: yes
11:08 * bshum goes off to file a bug
11:08 paxed is it enough to insert into config.record_attr_definition and reingest, or do i have to do something else to get a new filter working?
11:09 zerick joined #evergreen
11:10 dbs "mens" does get stemmed in the tsv column to "men" in weighting 'A' and 'C', but is only present as "mens" in weighting 'A'
11:12 dbs methinks the problem may lie in the new use of weighting in the vector index :/
11:12 Dyrcona dbs: could be.
11:14 jeff_ paxed: depending on what you mean by filter -- when adding a new facet i know that at least an apache restart (and possibly an opensrf services restart) is required.
11:15 jeff_ paxed: sorry to say "i know" so definitively then fall back to a vague "one, possibly both" :-)
11:15 paxed jeff_: heh.
11:15 * jeff_ looks to see how well the OpenSRF and OpenILS perl modules take to being installed under a perlbrew environment
11:16 paxed jeff_: for example, a hypothetical one: insert into config.record_attr_definition (name, filter, sorter, tag, start_pos, string_len) values ('foo', TRUE, FALSE, '007', 1, 1);
11:25 jeff_ paxed: the filters are pulled from the db as part of the QueryParser initialization sub. it looks like it might be done every search, but I'm not certain of that without looking further. Try it, and if it doesn't work, restart OpenSRF services (which means you should restart apache also)
11:27 dboyle joined #evergreen
11:29 jdouma joined #evergreen
11:31 fparks joined #evergreen
11:33 paxed huh. okay, that works. it just didn't work like i expected it to.
11:34 paxed adding that filter, it seems to consider the whole 007 field, not the 007/1
11:46 Ruth joined #evergreen
11:57 jeff_ drat. the perils of comparing json as strings?
11:57 jeff_ #   Failed test at t/09-Utils-JSON.t line 105.
11:57 jeff_ #          got: '{"__p":{"foo":"bar"},"__c":"osrfException"}'
11:57 jeff_ #     expected: '{"__c":"osrfException","__p":{"foo":"bar"}}'
11:57 jeff_ (of course, run the test again and all's well)
11:59 Ruth I had the same problem with roofing nails this morning.
12:02 mcooper joined #evergreen
12:05 pinesol_green [evergreen|Simon Hieu Mai] LP#1053074: Editimg MARC Fixed Fields jumps cursor to marc record - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=717a126>
12:07 mtcarlson joined #evergreen
12:07 Ruth I would love to be able to run a report that showed a month's worth of daily circulations for designated shelving locations
12:07 * Ruth knows this is possible.
12:07 * Ruth has not the time to build said report.
12:08 eeevil paxed: looks like I gave you some bad info, based on the schema comments: http://pastebin.com/4f1akLKc ... we could either expand the use of start_pos/string_len or you could use config.marc21_ff_pos_map and define 007/01 (note: start_pos is always 0-based ... think: C strings)
12:10 eeevil (my bad info was /not/ based on the comments ... the comments are correct according to the code)
12:10 jihpringle joined #evergreen
12:13 paxed eeevil: so, insert into config.marc21_ff_pos_map (fixed_field, tag, rec_type, start_pos, length) values ('mrbond', '007', 'COM', 1, 1); and reingest?
12:17 eeevil paxed: you'll need to adjust your "foo" record_attr_definition row too
12:17 eeevil to point at the new mrbond fixed field def
12:17 eeevil but, yes
12:18 tspindler left #evergreen
12:18 paxed oh, mrbond would go into fixed_field.
12:20 eeevil right, and null tag, start_pos and string_len
12:21 paxed ok
12:25 eeevil paxed: you may want to add one for all rec_type values, so you can filter on any 007/01
12:25 ldwhalen joined #evergreen
12:35 paxed yeah, figured
12:39 mjingle joined #evergreen
12:55 jeff_ tests+-
13:09 mcarlson joined #evergreen
13:11 mtcarlson joined #evergreen
13:13 dbs jeff_: maybe set $json->canonical(true) to ensure the keys are ordered
13:14 dbs assuming that json::xs is in play
13:15 * dbs hasn't been able to get that test to fail
13:15 jeff_ yeah. it might be a perl 5.18 thing. i'm seeing similar with some XML tests for RPC::XML
13:16 jeff_ or, might be that i've fallen back to the pure perl json backend. i should check.
13:16 dbs mmm, yeah, perl 5.16 here
13:16 jeff_ and dbs++ for $json->canonical(true) -- i thought there was an option for that but had not gone looking.
13:17 StephenGWills joined #evergreen
13:23 StephenGWills Is there already a way, or is someone working on being able to move multiple items from a search result set into a book bag in one click?
13:25 StephenGWills probably not the best worded spec ever.  I'm envisioning a checkbox next to results and a button to move the selected items.
13:34 mtcarlson joined #evergreen
13:35 * jeff_ leaves his desk to avoid watching perl brew
13:48 ldwhalen joined #evergreen
13:53 tsbere_ joined #evergreen
13:56 bshum_ joined #evergreen
13:57 senator_ joined #evergreen
13:58 gmcharlt_ joined #evergreen
14:03 ldwhalen_mobile joined #evergreen
14:05 egbuilder_ joined #evergreen
14:08 timf joined #evergreen
14:09 tsbere__ joined #evergreen
14:12 _bott_ joined #evergreen
14:14 mjingle joined #evergreen
14:16 timhome joined #evergreen
14:17 ktomita joined #evergreen
14:17 sseng_ joined #evergreen
14:17 ktomita_ joined #evergreen
14:18 tfaile_ joined #evergreen
14:23 upesh joined #evergreen
14:27 mcarlson joined #evergreen
14:30 goooood joined #evergreen
14:31 gdunbar joined #evergreen
14:33 rbecker joined #evergreen
14:34 ktomita__ joined #evergreen
14:34 ktomita___ joined #evergreen
14:35 artunit_ joined #evergreen
14:37 hopkinsju joined #evergreen
14:37 eby_ joined #evergreen
14:37 _bott_1 joined #evergreen
14:38 Meliss1 joined #evergreen
14:38 gmcharlt joined #evergreen
14:38 tfaile joined #evergreen
14:38 shadowspar joined #evergreen
14:39 Ruth joined #evergreen
14:41 artunit_ joined #evergreen
14:42 senator joined #evergreen
14:43 rfrasur joined #evergreen
14:58 tsbere_ joined #evergreen
14:59 Ruth joined #evergreen
15:01 jcamins_ joined #evergreen
15:01 pastebot0 joined #evergreen
15:05 tsbere joined #evergreen
15:06 tsbere joined #evergreen
15:06 Ruth joined #evergreen
15:07 tsbere joined #evergreen
15:12 tsbere_ joined #evergreen
15:19 tsbere joined #evergreen
15:19 tsbere joined #evergreen
15:25 paxed joined #evergreen
15:42 kyleonalaptop joined #evergreen
15:43 bshum I haven't migrated bibs before, but that email to the list sounds painful.
15:47 dbs Those docs are based on the migration path we used > 4 years ago. I haven't followed that path for about 3.5 years.
15:47 bshum Heh
15:47 bshum That's what I thought too.
15:53 Ruth Sounds like an entertaining email for when I check it today.  Summer Reading - meh.
15:53 dbs Doing that whole 550K import inside one function is clearly stressing the system out. If he could chop it into separate calls for chunks of 10K records, that might help...
15:53 bshum I wondered if it had anything to do with the number of bibs
15:53 bshum And yeah splitting it down into ranges
15:55 bshum I haven't used those scripts ever, but I just had a feeling that it might be something like that.
15:57 gmcharlt FWIW, I don't generally load bibs in transactions larger than a thousand each
15:57 dbs It's worth something ;)
15:57 dbs I hear you have some experience with this whole importing thing!
15:59 dbs 10K chunks was what I used for the last midsized (90K) migration I did; that was an easy one, as the holdings were well-expressed in the MARC records
16:00 Dyrcona joined #evergreen
16:14 tfaile_ joined #evergreen
16:15 mrpeters left #evergreen
16:20 tsbere_ joined #evergreen
16:24 shadowspar joined #evergreen
16:31 mtcarlson joined #evergreen
16:39 remingtron joined #evergreen
16:40 kyleonalaptop_ joined #evergreen
16:51 dbwells dbs++ # writing code for the mailing list
17:00 ldwhalen joined #evergreen
17:01 FRANK_ joined #evergreen
17:02 FRANK_ Hello everybody, does someone have the steps I have to follow to could use the KPAC?
17:05 mjingle joined #evergreen
20:20 serflog joined #evergreen
20:20 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org
20:21 bshum awitter++ mrpeters++
20:36 b_bonner joined #evergreen
20:43 mtcarlson joined #evergreen
20:46 mcarlson joined #evergreen
20:49 ldwhalen joined #evergreen
22:03 ktomita-mac joined #evergreen
22:16 ldwhalen joined #evergreen
22:17 kmlussier joined #evergreen
22:20 * bshum sighs loudly at acquisitions and EDI testing :(
23:00 pinesol_green [evergreen|Pranjal Prabhash] Standalone Mode Staff Client Shortcuts - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b55da92>
23:00 pinesol_green [evergreen|Ben Shum] Added release note for standalone mode shortcuts - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2060027>
23:04 bshum Calling 0794
23:13 ldwhalen joined #evergreen
23:36 timf joined #evergreen
23:38 jcamins joined #evergreen
23:49 bshum Hmm, for some reason my git is counting me changing the file from XXXX to a stamp number as a delete old file/add new file instead of a move.
23:49 bshum And we lose the quick diff between files that normally gets seen.
23:49 bshum Humbug... :(
23:54 bshum Or maybe it's some weird gitweb problem, sigh.
23:56 bshum Ah okay, so it is something wacky with the gitweb.
23:56 bshum Nevermind me....
23:59 paxed morning

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat