| 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 |
