| Time |
Nick |
Message |
| 00:22 |
dbs |
with bug 1193204 , bug 1193196 , and bug 1192710 in place, I think our logs are starting to get back under control |
| 00:22 |
pinesol_green |
Launchpad bug 1193204 in Evergreen "Do not exit eval BLOCK by "next"; use "return" instead" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1193204 |
| 00:22 |
pinesol_green |
Launchpad bug 1193196 in Evergreen "Silence uninitialized var warnings in add_query_normalizer()" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1193196 |
| 00:22 |
pinesol_green |
Launchpad bug 1192710 in Evergreen "QP uses numeric cmp operator for comparing strings, fills logs with warnings" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1192710 |
| 00:33 |
dbs |
Next one to tackle is open-ils.storage.biblio.multiclass.staged.search_fts: NOTICE: text-search query doesn't contain lexemes: "" |
| 00:56 |
|
Mark__T joined #evergreen |
| 03:56 |
|
jeff joined #evergreen |
| 03:56 |
|
jeff joined #evergreen |
| 05:17 |
paxed |
ouch |
| 06:51 |
|
rfrasur joined #evergreen |
| 07:34 |
|
jboyer-isl joined #evergreen |
| 08:08 |
|
bkuhn joined #evergreen |
| 08:25 |
|
akilsdonk_ joined #evergreen |
| 08:28 |
|
kbeswick joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:44 |
|
mmorgan1 joined #evergreen |
| 08:44 |
|
ericar joined #evergreen |
| 09:03 |
pastebot |
"dbs" at 204.193.129.146 pasted "After applying various warning-reducing patches, 9 hours of warnings are down to:" (10 lines) at http://paste.evergreen-ils.org/20 |
| 09:04 |
|
akilsdonk_ joined #evergreen |
| 09:09 |
dbs |
that's 1,365 warnings in total over the first 9 hours of the day, vs. 15,375 warnings in total over the first 9 hours of yesterday. WIN. |
| 09:09 |
pinesol_green |
[evergreen|Dan Scott] return, not next, from eval BLOCK - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=174c7db> |
| 09:11 |
dbs |
berick++ |
| 09:11 |
* dbs |
heads into work |
| 09:19 |
berick |
dbs++ |
| 09:19 |
berick |
nice solution! |
| 09:29 |
|
yboston joined #evergreen |
| 09:33 |
|
tspindler joined #evergreen |
| 09:37 |
tspindler |
I was wondering if anyone runs any crons to clean up after dead precats |
| 09:38 |
tspindler |
we have situations where libraries create precats because of miscans and never remove the precat |
| 09:39 |
tspindler |
some of these precats may end up with a barcode like "13" which than gets picked up by another library and checked out because of another miscan |
| 09:39 |
tspindler |
I don't have any idea how frequent the problem is overall but and least anecdotal reports indicate it happens often enough |
| 09:40 |
tsbere |
We get a lot of those types of precats |
| 09:40 |
tsbere |
But "cleaning up" after them means finding a way to identify them |
| 09:41 |
tspindler |
one thought for me is to look for precats above a certain age that are currently not checked out, I would identify them with the -1 for call number |
| 09:42 |
pinesol_green |
[evergreen|Dan Scott] Silence uninit var warnings from query normalizer - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=84d6910> |
| 09:42 |
berick |
web-man moodaepo, you up for some website release updates? 2.3.8 and 2.2.10 (ready, senator?) |
| 09:42 |
* berick |
also could use an LP milestone update, whoever does those |
| 09:42 |
berick |
... these days |
| 09:46 |
|
remingtron joined #evergreen |
| 09:50 |
|
rfrasur joined #evergreen |
| 09:58 |
dbs |
methinks that's primarily bshum these days |
| 10:01 |
rfrasur |
(there should be a rule against such titles as "seduction & snacks") |
| 10:08 |
senator |
berick: ooh yeah (in kool-aid man voice) |
| 10:10 |
rfrasur |
tspindler: we do see that prob relatively often here. we have a pretty strict local policy but it's not consortium wide as far as I know...so...lots of chaff. |
| 10:19 |
tspindler |
rfrasur: my guess is there are others, it is an issue that is not unique to evergreen, I know we had a similar issue on III also with the "on the fly" records |
| 10:20 |
tspindler |
ideally, staff would pay more attention and make sure these things get cleaned up but I know thats not always going to happen even with the best staff |
| 10:20 |
rfrasur |
tspindler: I'm sure. IMO, generally, I don't think it's big deal other than obviously taking away from a nice buttoned up catalog EXCEPT in the scenario(s) you mentioned. |
| 10:20 |
rfrasur |
staff_paying_more_attention++ |
| 10:22 |
Dyrcona |
rfrasur makes me laugh.... ;) |
| 10:22 |
* rfrasur |
bows |
| 10:22 |
rfrasur |
contact my agent...or parole officer |
| 10:23 |
mmorgan1 |
tspindler: We have some of this going on as well. The most annoying part is the one or two digit barcodes that get saved as precats. |
| 10:23 |
Dyrcona |
We blame it on misscans for the most part. |
| 10:23 |
rfrasur |
Dyrcona: very generous |
| 10:23 |
Dyrcona |
heh... |
| 10:24 |
Dyrcona |
We get in trouble if we blame the staff for not paying attention. |
| 10:24 |
rfrasur |
In trouble by who? |
| 10:24 |
mmorgan1 |
Not sure exactly how the one or two digit barcode thing happens, since we encourage use of "strict barcode" |
| 10:24 |
Dyrcona |
Suggesting that they, y'know, do their job.... |
| 10:25 |
tspindler |
mmorgan1: probably the biggest problem that occurs is that a miscan occurs, precat gets checkout even though there is a record for it, item gets returned, scans correctly and shows not checked out, patron gets a bill for precat item |
| 10:25 |
Dyrcona |
tspindler mmorgan1 Has this become an issue since migrating to Horizon, or did you see this a lot on your previous system? |
| 10:26 |
Dyrcona |
rfrasur: It's more of a metaphorical trouble. |
| 10:26 |
mmorgan1 |
dyrcona: you mean evergreen? ;-) |
| 10:26 |
tspindler |
Dyrcona: we saw this some before |
| 10:26 |
Dyrcona |
Hah! yeah... |
| 10:26 |
Dyrcona |
I was just finishing up a document that had a lot of mention of the unmentionable. |
| 10:27 |
Dyrcona |
We use to see it on Horizon, but I think we see it more now. |
| 10:27 |
tspindler |
mmorgan1: we have some issues with using strict barcode because we have valid barcodes that would not scan with this setting (Joan Kranich could give you the details) |
| 10:27 |
Dyrcona |
tspindler: You probably have barcodes that don't use checksums. |
| 10:28 |
tspindler |
Dyrcona: yes i think thats correct |
| 10:28 |
mmorgan1 |
we saw this in millennium some, too, but millennium was VERY strict about what you could scan into the barcode box. so we see more in evergreen |
| 10:28 |
* rfrasur |
might be in such a constant state of trouble that it's no longer she no longer senses it. |
| 10:29 |
Dyrcona |
What I'd like to figure out is if it is worse because of a technical difference between our previous ILS and Evergreen or if it is just a lack of familiarity on the part of circulation staff. |
| 10:29 |
tspindler |
Dyrcona: I think that is the 64 dollar question in a lot of areas |
| 10:30 |
rfrasur |
Dyrcona: In our case, we had staff that weren't watching the screen and then not reading alert messages. |
| 10:30 |
Dyrcona |
rfrasur: Everyone has that problem. |
| 10:30 |
tspindler |
rfrasur: we have some of that definitely |
| 10:31 |
rfrasur |
Or, they'd try to precat (which we do allow), but they weren't recognizing the important distinction between a UPC and a lib barcode |
| 10:31 |
mmorgan1 |
we do too |
| 10:31 |
jcamins |
Dyrcona: I'm working with a (Koha) library that bought new barcode scanners during the switch from Millennium to Koha, and they're seeing a lot of misscans because they didn't realize that they had to turn on checksum mode. |
| 10:31 |
tspindler |
I know many of our circ supervisors in our member libraries get frustrated with their staff who do not read the screens carefully |
| 10:31 |
rfrasur |
or a partial scan that they weren't double checking. |
| 10:32 |
Dyrcona |
jcamins: For the most part our libraries are using the same barcode scanners. |
| 10:32 |
mmorgan1 |
but it seems like there may be a technical difference with Evergreen |
| 10:32 |
jcamins |
Dyrcona: so much for that theory, in your case. |
| 10:32 |
rfrasur |
mmorgan1: why do you think it might be partially a software prob? (not discounting...just really asking why) |
| 10:32 |
tspindler |
our problem, because of our size we have lots of variatioin in hardware and even the barcodes used over the years |
| 10:33 |
mmorgan1 |
in evergreen, sometimes a digit in the middle of a barcode that will be dropped. Don't think I saw much of that in our old system |
| 10:33 |
tspindler |
mmorgan1: I think some of our libraries have reported this also |
| 10:33 |
mmorgan1 |
seems like it's possible for a barcode scanner to feed in digits faster than they can register in evergreen |
| 10:34 |
rfrasur |
hmm, I haven't seen that but I'm not with the scanners much anymore either. |
| 10:36 |
mmorgan1 |
rfrasur: btw, regarding the upc, you may be able to program your barcode scanners not to recognize these, as long as your book barcodes aren't the same kind |
| 10:37 |
csharp |
mmorgan1: a simple test might be to scan the same barcodes into a text editor and see if the errors persist |
| 10:38 |
csharp |
in our experience, those kinds of mis-scans are the fault of the scanner itself FWIW |
| 10:38 |
csharp |
(or *ahem*, staff) |
| 10:38 |
rfrasur |
mmorgan1: you're right, we probably could. but, I'm the IT department (it's sorely lacking) and the everything else, and decided it was easier to move the barcodes away from the UPC (they're never on the back anymore) and explicitly teach the full staff re: barcodes in general. The obnoxious of the tutorial and the prospect of getting it again was a deterrent. |
| 10:40 |
csharp |
and "strict barcode" doesn't stop the creation of invalid barcodes - it just checks for them when scanning |
| 10:40 |
|
dboyle joined #evergreen |
| 10:41 |
moodaepo |
berick: just saw your message..updating site |
| 10:41 |
csharp |
moodaepo++ |
| 10:41 |
mmorgan1 |
csharp: I think we did try that at some point. the scanners do mess up, but it seems like we see more dropped digits than we should in evergreen |
| 10:41 |
* rfrasur |
grumbles something about people using 10 digit ISBN in 2013 bib records |
| 10:42 |
dbs |
rfrasur: on the happy side of things, a search for the 13 digit ISBN should turn up that record |
| 10:42 |
tspindler |
that reminds, we do have people sometimes scanning upcs and not barcodes ;) |
| 10:42 |
jcamins |
rfrasur: unless they've been taught to know how to convert ISBNs, your catalogers can't really be expected to know not to transcribe the ISBN in the book. |
| 10:42 |
dbs |
thanks to Indexing Magic(TM) |
| 10:42 |
rfrasur |
dbs: It didn't because whoever did the initial BIB didn't add the 13-dig |
| 10:43 |
rfrasur |
and they included a : HRD after it. |
| 10:43 |
rfrasur |
@hates |
| 10:43 |
pinesol_green |
rfrasur hates MARC; mouthy teens; State of Indiana Department of Workforce Development online interface; and stupid state bureaucracy |
| 10:43 |
berick |
moodaepo++ thanks |
| 10:43 |
rfrasur |
the first one is applicable |
| 10:43 |
dbs |
rfrasur: hmm. you shouldn't have to include the 13-digit ISBN, I'm pretty sure we have (for years) automatically generated an equivalent 13-digit for the indexes, but perhaps the : HRD throws it off |
| 10:44 |
rfrasur |
the whole record is a joke. it must have been something that someone loaded and didn't clean up. |
| 10:44 |
dbs |
works here, at least: http://laurentian.concat.ca/eg/opac/results?contains=contains&_special=1&qtype=identifier%7Cisbn&query=978-0-389-20742-9&locg=105 |
| 10:46 |
|
zerick joined #evergreen |
| 10:46 |
rfrasur |
dbs: It didn't work in this case...but let me try something before I fix the record. maybe it is just that : HRD |
| 10:47 |
dbs |
actually, it looks like we should even do it in the case of : HRD |
| 10:48 |
|
zerick joined #evergreen |
| 10:48 |
dbs |
public.translate_isbn1013() function does the magic for identifier:isbn entries |
| 10:48 |
pinesol_green |
[evergreen_website|Anoop Atre] Downloads - Evergreen 2.3.8 and 2.2.10 releases - <http://git.evergreen-ils.org/?p=Evergreen_Website.git;a=commit;h=e2cef8e> |
| 10:50 |
rfrasur |
there's something wrong w/ this item. |
| 10:52 |
rfrasur |
it's showing up now in the staff client and searching correctly (I just added the 13 digit ISBN because it should be there anyway)...but not in the OPAC |
| 10:52 |
rfrasur |
oh good grief...this has to be user error |
| 10:53 |
* rfrasur |
is doing something incredibly easy incredibly wrong |
| 10:54 |
rfrasur |
(or trying to do it too fast...it's all copasetic now) |
| 10:55 |
Dyrcona |
berick: You want new milestones created in Launchpad? |
| 10:55 |
rfrasur |
Hmm, as far as the ISBN magic goes, we're running 2.2, but I'm not sure which in that family |
| 10:56 |
rfrasur |
2.2.2 |
| 10:56 |
berick |
Dyrcona: yes, please, and whatever else you normally do (for 2.2 and 2.3) |
| 10:56 |
berick |
Dyrcona++ |
| 10:57 |
Dyrcona |
Ok, so 2.2.11 and 2.3.9 to be created. |
| 10:57 |
berick |
most excellent |
| 10:57 |
Dyrcona |
OK. I'll take care of marking the others released as of yesterday and move the bugs. |
| 11:01 |
dbs |
rfrasur: ISBN magic went in 3 years ago, that should predate 2.2... the default indexing config should include that normalizer for identifier:isbn, but it's always possible it was changed locally I guess |
| 11:02 |
rfrasur |
dbs: very possible |
| 11:02 |
rfrasur |
rjackson-isl: do you know anything about that? |
| 11:05 |
|
wolf29_ joined #evergreen |
| 11:06 |
dbs |
SELECT cmf.field_class, cmf.name, cin.name FROM config.metabib_field_index_norm_map cmfinm INNER JOIN config.metabib_field cmf ON cmf.id = cmfinm.field INNER JOIN config.index_normalizer cin ON cin.id = cmfinm.norm WHERE cin.func ~ 'isbn'; |
| 11:06 |
dbs |
gives me identifier | isbn | ISBN 10/13 conversion |
| 11:09 |
dbs |
rfrasur: to be clear; we don't actually change the MARC record itself to include the generated ISBN, it's just that an ISBN search should return the record for either the 10 or 13 digit ISBN |
| 11:09 |
rfrasur |
dbs: that's all above me and my permission level. I believe you that it should work. |
| 11:10 |
dbs |
:) |
| 11:10 |
rfrasur |
yeah, I understood that part of it. seems like it adds the 978 and stems the end of the 10-digit |
| 11:10 |
|
Callender joined #evergreen |
| 11:11 |
dbs |
Using the correct checksum, etc - Business::ISBN does the heavy lifting |
| 11:12 |
rfrasur |
which is why people touching the MARC should be diligent about adding as many ISBN access points are appropriate to the record. :p |
| 11:17 |
mmorgan1 |
Can someone confirm which printer context is used by the Simplified Pull List? |
| 11:19 |
mmorgan1 |
I have one printer set under default, a receipt printer set under receipt, and the simplified pull list wants to go to a third printer |
| 11:21 |
|
acoomes joined #evergreen |
| 11:22 |
senator |
mmorgan1: i don't know anything about printer contexts, but i do know that the simplified pull list ultimately just calls window.print(). possibly someone else who knows about printer contexts and is familiar with that part of the code could put my datum with your question and come up with an answer |
| 11:22 |
senator |
phasefx: ^-- maybe you? |
| 11:23 |
mmorgan1 |
I thought it might be the Windows default, but I've changed that and the simplified pull list stubbornly wants to go to that same printer which I don't have set anywhere |
| 11:23 |
tsbere |
it might be "whichever context was last used to print" >_> |
| 11:23 |
phasefx |
mmorgan1: senator: I was just checking. It looks like none of the printer roles are getting used there |
| 11:23 |
phasefx |
so I think it defaults to whatever the default windows printer is |
| 11:23 |
rfrasur |
phasefx++ |
| 11:24 |
phasefx |
so anywhere in the client where we're essentially doing window.print |
| 11:24 |
phasefx |
and not using util.print |
| 11:24 |
tsbere |
phasefx: I thought xulrunner-based apps tended to default to the last printer used. Or does the util.print stuff undo the printer settings changes after it is done printing? |
| 11:25 |
phasefx |
tsbere: it doesn't appear to work like that empirically |
| 11:26 |
phasefx |
hrmm, but it's not doing the default windows printer for me either.. or at least it looked like it was at first, but when I switched it, it didn't switch in the client, even after a restart |
| 11:27 |
mmorgan1 |
phasefx: Seeing the same thing - I just changed my windows default, cleared cache, closed client, logged back in, and it still wants to print to that printer. |
| 11:27 |
phasefx |
so my default windows printer is Microsoft XPS Document Writer, and all my staff client printer roles are set to CutePDF, but the simplified pull list is going to Generic/Text Only, which used to be my windows default |
| 11:28 |
tsbere |
phasefx/mmorgan1: Perhaps take a look at the about:config page to see what it is storing in the printer settings variables? |
| 11:29 |
phasefx |
if I clear out print_printer in about:config, it goes to my windows default |
| 11:29 |
phasefx |
print_printer as opposed to print.print_printer (gosh that all seems tangled) |
| 11:30 |
phasefx |
mmorgan1: so About -> For Developers -> about:config, enter print_printer in the Search box |
| 11:30 |
phasefx |
then right click on the print_printer entry, and choose Reset |
| 11:30 |
csharp |
sometimes that can be fixed by unchecking the "silent print when using Mozilla print" (or whatever it's called) in the printer admin interface, then clicking print from the interface you're trying to print from, selecting the desired printer, then re-checking the silent print box when done |
| 11:31 |
csharp |
(which confirms tsbere on "last printer used") |
| 11:31 |
|
mcooper joined #evergreen |
| 11:31 |
mmorgan1 |
just changed the printer dialog box for simplified pull list to yet another printer "Toshiba..." and "Toshiba..." is what now appears in about:config next to print_printer |
| 11:31 |
phasefx |
I wasn't using silent printing at all |
| 11:31 |
csharp |
maybe I'm thinking of the wrong setting... |
| 11:32 |
csharp |
in any case, not trying to muddy the water further ;-) |
| 11:32 |
phasefx |
is it just sticky then? if you change the printer used with the simple list? |
| 11:32 |
mmorgan1 |
so it looks like it uses windows default for starters, and remembers that printer until you change it in the dialog box? |
| 11:32 |
phasefx |
sounds likely |
| 11:32 |
csharp |
mmorgan1: that's my understanding, yes |
| 11:33 |
mmorgan1 |
OK, thanks, that clarifies things. Not quite how I expected it to behave, though! |
| 11:33 |
phasefx |
we could probably force the Default role to get used there with some dev effort |
| 11:33 |
phasefx |
munging the prefs |
| 11:37 |
rfrasur |
phasefx: what is munging? |
| 11:37 |
phasefx |
manipulating is what I mean |
| 11:37 |
rfrasur |
lol, okay. |
| 11:37 |
phasefx |
and prefs being an internal feature of xulrunner |
| 11:37 |
* rfrasur |
can usually parse it out...not always |
| 11:37 |
phasefx |
the stuff you see in about:config |
| 11:42 |
mmorgan1 |
opened bug 1193405 on Launchpad just to get this out there |
| 11:42 |
pinesol_green |
Launchpad bug 1193405 in Evergreen "Simplified pull list does not use printer context" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1193405 |
| 11:44 |
phasefx |
mmorgan1++ |
| 11:50 |
|
jdouma joined #evergreen |
| 11:56 |
|
krvmga joined #evergreen |
| 11:56 |
|
mllewellyn joined #evergreen |
| 11:57 |
krvmga |
some catalogers in our consortium perceive the speed of cataloging periodicals in the JSPAC to be faster than the TPAC. has anyone else heard this? |
| 11:59 |
berick |
I wouldn't be surprised if some things in the JSPAC were faster, particularly actions that do not require a page reload |
| 12:00 |
krvmga |
i wonder if this is something i can do anything about. |
| 12:01 |
berick |
a gatrillion lines of JS is a pain to load, but once you have it, it's pretty fast |
| 12:10 |
dbs |
Also, the old is always better than the new. |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:42 |
wolf29_ |
dbs++ New is scary |
| 12:46 |
|
frank joined #evergreen |
| 12:49 |
|
zerick joined #evergreen |
| 13:00 |
|
mtcarlson joined #evergreen |
| 13:00 |
mcooper |
I've been trying to convince people that new is exciting and full of potential for the better part of a year =) |
| 13:05 |
b_bonner |
Hi all. Our staff is starting to test the OCLC number scheme change that is starting next month, and noticed something quite odd. If an 001 OCLC number is the new style with "on" followed by 10 digits (on3987654321), it is NOT searchable in the opac (keyword or identifier). However, it IS searchable if it is |
| 13:05 |
b_bonner |
on" followed by 11 or 12 digits (on39876543211). Can someone help reproduce this and see if it's not just us? |
| 13:05 |
b_bonner |
I've been able to change the oclc number on the same record back and forth between and can confirm this scenario on our system |
| 13:07 |
b_bonner |
TCNs 1283817 (10 digit) and 1283816 (11 digit) on catalog.kcls.org if you want our examples |
| 13:15 |
dbs |
b_bonner: looks like it should be indexed and retrievable via identifier|scn ... |
| 13:18 |
dbs |
b_bonner: but right now catalog.kcls.org only seems to be returning 500 server errors :/ |
| 13:19 |
dbs |
in theory, if it was running, http://catalog.kcls.org/eg/opac/results?query=identifier|scn:3987654321 would give you what you're looking for |
| 13:19 |
b_bonner |
dbs: as far as I can see, metabib.identifier_field_entry seems to be breaking it up as expected. |
| 13:19 |
b_bonner |
dbs: hmm, our catalog seems to do that when a pipe is entered. that's new/ |
| 13:19 |
dbs |
:( |
| 13:20 |
b_bonner |
well, not every pipe. but your identifier|scn does make that happen. |
| 13:21 |
b_bonner |
dbs: what is the scn? never used that before myself |
| 13:23 |
dbs |
"System Control Number" - it's in the MARC specification, essentially it populates 035 $a with "(OrgId)bib-id-for-that-Org", rather than relying on the 001 which is only supposed to be a unique numeric identifier within a single library system |
| 13:23 |
dbs |
So as a record gets imported via Z39.50 from system to system, each one adds their 035$a |
| 13:24 |
* dbs |
thought that commit 7ea1d71af1711 might be involved but maybe not |
| 13:24 |
pinesol_green |
[evergreen|Galen Charlton] LP#1155329: better enforce cat.bib.use_id_for_tcn - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ea1d71> |
| 13:28 |
b_bonner |
dbs: sorry for the ignorance, but haven't spent much time in this part (and I'm not a cataloger).. FYI we currently have cat.maintain_control_numbers global flag = false, and I don't see an scn entry in metabib.field |
| 13:29 |
dbs |
Ohhh. If cat.maintain_control_numbers is false, then you get no such goodness |
| 13:29 |
|
kmlussier joined #evergreen |
| 13:30 |
b_bonner |
it is strange that identifier search on 001 works on other length entries, just not on+10 |
| 13:30 |
dbs |
b_bonner: it seems likely that you have something set up locally to do special things that don't match the Evergreen out-of-the-box experience. Hard to help with that :/ |
| 13:32 |
b_bonner |
dbs: hmm, thanks. will keep digging. Can you do me a favor and try changing an 001 on your test system to "on54987654321" and see if it can find it via keyword or identifier search? |
| 13:35 |
b_bonner |
dbs: and if not, does 11 digit? (on39876543211) |
| 13:40 |
csharp |
b_bonner: you might also poke around in the metabib tables to see if entries for each of those records are present |
| 13:40 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier|scn:on54987654321 works |
| 13:41 |
dbs |
... but it's not getting (OCoLC)54987654321 as a 035$a like I would have expected. |
| 13:41 |
dbs |
possibly because we have an institutional ID set? hrm. |
| 13:42 |
b_bonner |
csharp: first thing I did. every thing looks identical between them in metabib.identifier_field_entry between them when 10 or 11 digits, just search failing on 10 |
| 13:42 |
csharp |
hmm |
| 13:44 |
b_bonner |
dbs csharp: query captured: http://pastebin.com/VpAteZRd |
| 13:44 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier|scn:on39876543211 also works |
| 13:45 |
dbs |
but really, the "on" should be stripped off |
| 13:45 |
b_bonner |
dbs: any results without the scn? |
| 13:45 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier:on39876543211 works fine too |
| 13:45 |
b_bonner |
we have an identifer set up (accession) on the 001 tag |
| 13:46 |
dbs |
Yeah, that's an out of the box thing |
| 13:46 |
b_bonner |
and without scn on the 10 digit? |
| 13:46 |
dbs |
http://laurentian-test.concat.ca/eg/opac/results?query=identifier:on54987654321 works too |
| 13:47 |
dbs |
Note that our system is set up to replace the 001 with the bib ID each time, so the results will show 001 739015 |
| 13:47 |
dbs |
But you can see the 035 $a that were added. |
| 13:48 |
b_bonner |
dbs: yeah, that changes the scenario quite a bit |
| 13:48 |
* dbs |
tries an ocn prefix, that works too. |
| 13:48 |
dbs |
b_bonner: why? |
| 13:49 |
b_bonner |
well, we are searching on just the 001, don't think we have the 035 searchable, but will double-check |
| 13:55 |
* dbs |
suspects something is broken in maintain_control_numbers, as he was expecting OCLC 001s to generate a 035 (OCoLC)###### without the oc?[nm] prefix, but is getting (existing 003)oc?[nm]###### instead |
| 13:55 |
* dbs |
blames dbwells for wanting to support OCLC special cases :) |
| 13:56 |
gmcharlt |
heh, indeed |
| 13:58 |
* dbwells |
isn't sure "want" is the right word. |
| 13:58 |
dbs |
dbwells++ |
| 13:58 |
jcamins |
dbs: doesn't the alphabetic prefix usually go into the 035 for reasons I can't begin to understand? |
| 13:59 |
dbs |
jcamins: we're doing $cn =~ s/^o(c[nm]|n)0*(\d+)/$2/; so we're trying to avoid it, unless I'm reading that wrong |
| 14:00 |
dbs |
(of course, only if you have maintain_control_numbers enabled) |
| 14:00 |
|
acoomes_ joined #evergreen |
| 14:00 |
gmcharlt |
jcamins: well, there's nothing saying that 001 values need to be numeric, so 001 + 003 => 035 $a(003)001 has always seemed the most reasonable way to do it for me |
| 14:00 |
jcamins |
Ah. I think most other systems keep the ocm/ocn/oc. |
| 14:00 |
gmcharlt |
right -- but OCLC evidently disagrees |
| 14:00 |
dbs |
and http://oclc.org/developer/documentation/xoclcnum/request-types shows all of their example 035 without the prefix |
| 14:01 |
* dbs |
recalls reading & implementing the spec somewhere |
| 14:01 |
jcamins |
Interesting. This record from OCLC does not have the prefix. |
| 14:01 |
gmcharlt |
which is ... unfortunate, because if they didn't insist on that, we would have to *care* anytime they started using a new prefix |
| 14:01 |
gmcharlt |
rather, we *wouldn't* have to care |
| 14:02 |
|
ldwhalen joined #evergreen |
| 14:03 |
dbs |
aha - http://www.oclc.org/en-US/batchload/controlnumber.html |
| 14:03 |
jcamins |
"(OCoLC)ocm79443562" <-- I guess they changed it. |
| 14:03 |
* dbwells |
is interested to know in what decade the "meaning" of the prefixes had any value whatsoever |
| 14:03 |
dbs |
035 field: |
| 14:03 |
dbs |
OCLC number is a variable-length numeric string with no leading zeros and preceded by "(OCoLC)". |
| 14:03 |
dbs |
Example: (OCoLC)198765401 |
| 14:04 |
dbs |
_that_ is what I based my implementation on |
| 14:06 |
dbs |
git commit a9e646657cf - primary blame :) |
| 14:06 |
pinesol_green |
[evergreen|Dan Scott] Treat OCLC numbers specially in maintain_control_numbers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9e6466> |
| 14:06 |
gmcharlt |
dbs: I rather think the primarly blame belongs to OCLC ;) |
| 14:07 |
|
kmlussier1 joined #evergreen |
| 14:07 |
dbs |
heh, of that there's no doubt! |
| 14:07 |
* dbwells |
also "loves" the (earlier) standard of ending a control number with a space. Invisible data is always good for matchpoints. |
| 14:07 |
* dbs |
never heard of that earlier standard. Nice! |
| 14:07 |
jcamins |
dbs: all my favorite control numbers end in spaces! Or have three spaces in the middle. |
| 14:08 |
gmcharlt |
jcamins: actually, spaces in the middle are the least objectionable |
| 14:08 |
dbs |
although a local cataloguer used a variation of that years past to avoid uniqueness constraints for ISBNs and ISSNs when importing records by inserting a space. |
| 14:08 |
dbwells |
Well, it's still used for the older records (with 'ocm' numbers). http://www.oclc.org/en-US/batchload/controlnumber.html |
| 14:08 |
gmcharlt |
of course, there's also LC with the leading-whitespace-is-signficant-but-not-really LCCNs |
| 14:09 |
dbs |
wow, by "blank" they mean a real space? yeesh |
| 14:09 |
dbwells |
look close to see the "blank" at the end of the example: ocm00012345 |
| 14:09 |
dbs |
dbwells++ |
| 14:09 |
* dbs |
stares blankly |
| 14:09 |
dbwells |
:) |
| 14:09 |
gmcharlt |
U+666 non-invisible space |
| 14:10 |
dbs |
": ocm00012345 " is what browser dev tools shows me |
| 14:10 |
dbs |
(of course, every text node in dev tools gets an extra space at the end - heh) |
| 14:11 |
dbs |
or not... nope, just random text nodes on the web page do |
| 14:11 |
* dbs |
blames royt |
| 14:12 |
* dbs |
marks "OCLC Control Number compliance" as highest priority on QA survey |
| 14:12 |
dbs |
@monologue |
| 14:12 |
pinesol_green |
dbs: Your current monologue is at least 6 lines long. |
| 14:14 |
csharp |
dbs++ |
| 14:14 |
csharp |
@blame royt |
| 14:14 |
pinesol_green |
csharp: royt caused the white screen of death! |
| 14:15 |
dbs |
dude is evil. |
| 14:21 |
jeffdavis |
2.4 release notes say a new perm ADMIN_PROXIMITY_ADJUSTMENT is added; it's in fm_IDL.xml but I don't see it in any upgrade scripts - an oversight? |
| 14:22 |
dbs |
Sounds like an oversight |
| 14:23 |
dbs |
grep PROXIMITY 950.data.seed-values.sql -- also empty |
| 14:23 |
dbs |
s/added/needed/ ? |
| 14:23 |
dbs |
:) |
| 14:24 |
jeffdavis |
heh, yes |
| 14:25 |
dbs |
jeffdavis: are you retesting with rel_2_4 latest now? |
| 14:31 |
jeffdavis |
dbs: we don't have the 8 latest commits in rel_2_4 yet |
| 14:32 |
jeffdavis |
i'll try to integrate them after hours today |
| 14:32 |
dbs |
lemme tell you, it's nice to be down to 4,000 WARN messages today |
| 14:36 |
jeffdavis |
yeah, i'd like that fix - our test server osrfsys.log has 60K WARN messages from the past 36 hours |
| 14:36 |
jeffdavis |
or I guess those multiple fixes |
| 14:37 |
* jeffdavis |
adds rebase to todo list, says goodbye to any remaining time off this weekend ;) |
| 14:37 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1192710 was a pretty good one too |
| 14:37 |
pinesol_green |
Launchpad bug 1192710 in Evergreen "QP uses numeric cmp operator for comparing strings, fills logs with warnings" (affected: 1, heat: 6) [Medium,New] |
| 14:37 |
dbs |
not yet signed off or committed |
| 14:41 |
* dbs |
glares at "GET /eg/opac/home?loc=105http:// HTTP/1.1" still causing pain for poor cstore |
| 14:51 |
dbs |
on another note, working/user/dbs/shut_up_novelist does what it says for non-Novelist sites |
| 14:52 |
dbs |
err, now it does :) |
| 14:56 |
dbs |
and bugged with 1193466 too |
| 14:59 |
* paxed |
ponders if he feels up to signoff |
| 14:59 |
paxed |
it's the midsummer eve night after all... |
| 15:00 |
dbs |
hah |
| 15:01 |
paxed |
although that numeric cmp change is so simple, i could see it being committed without a signoff. |
| 15:03 |
|
edoceo joined #evergreen |
| 15:10 |
|
kmlussier joined #evergreen |
| 15:10 |
bshum |
kmlussier: Just for you. parts-- |
| 15:10 |
* bshum |
resumes vacation |
| 15:13 |
|
kmlussier1 joined #evergreen |
| 15:15 |
bshum |
csharp: You guys are 2.3 right? Was just looking at bug 1193454 and we get confirmation on successfully placing the hold in master/2.4. |
| 15:15 |
pinesol_green |
Launchpad bug 1193454 in Evergreen "no hold placement message in TPAC" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1193454 |
| 15:15 |
* kmlussier1 |
can try it in 2.3 |
| 15:16 |
bshum |
It was slightly slower than I expected. |
| 15:16 |
kmlussier1 |
Bah! Who is that kmlussier1? |
| 15:16 |
csharp |
bshum: hmm |
| 15:16 |
csharp |
we are on 2.3.6, yes |
| 15:16 |
bshum |
But it did eventually show the me the acknowledgement. |
| 15:16 |
bshum |
*show me the... |
| 15:16 |
bshum |
Could be a bad network on my end or lag. |
| 15:17 |
bshum |
But I did see the message. |
| 15:17 |
csharp |
well bad network may be a factor on our end too |
| 15:17 |
csharp |
though I saw the same behavior from our office |
| 15:17 |
bshum |
I always hated having the Place Hold button in that lower half interface. |
| 15:18 |
csharp |
half the tickets we're getting (if not more) are all due to insufficient bandwidth at the libraries |
| 15:18 |
csharp |
and underpowered/aging workstations |
| 15:18 |
* csharp |
wishes he could seriously recommend linux to the libraries |
| 15:18 |
csharp |
at this point I just get to joke about it ;-) |
| 15:18 |
* dbs |
just got authorization to upgrade the RAM on the 1GB RAM WinXP workstations |
| 15:19 |
bshum |
I guess I should take a look at the console log and see if there are any obvious errors in the process of retrieving said page. |
| 15:19 |
csharp |
dbs: holy moly |
| 15:19 |
bshum |
Maybe there's something wonky there that's taking too long to process out. |
| 15:19 |
dbs |
kmlussier: it would be fun to be able to poke at your system to see the SQL that's getting generated and to enable the timelog for that part slowness |
| 15:19 |
bshum |
Blah |
| 15:20 |
bshum |
But of course, my only test server is running the custom new code for patron UI. |
| 15:20 |
bshum |
So that throws a kink in my testing :( |
| 15:20 |
csharp |
hrmm - I just got the message too |
| 15:20 |
bshum |
timelog++ |
| 15:20 |
csharp |
lemme try the original title reported as an example |
| 15:20 |
kmlussier1 |
csharp, bshum: I get the confirmation message on 2.3 |
| 15:20 |
bshum |
So then it's just csharp :( |
| 15:21 |
bshum |
Maybe it's some weird local customization run amok? |
| 15:22 |
bshum |
kmlussier1: You tested it via the staff client right? On behalf of a patron? I think that's where we're looking. |
| 15:22 |
csharp |
hmm - the original example (with 250+ copies attached) *doesn't* show the message |
| 15:22 |
kmlussier1 |
Yes, I followed the steps in the bug report. |
| 15:23 |
csharp |
so maybe the holdings are a factor? |
| 15:23 |
csharp |
PINES™ - Whatever Normal Libraries Have x 1000 |
| 15:24 |
dbs |
csharp: we have one library that opted to do serials as "attach thousands of individual copies to a single record" way back when and that continues to cause pain, particularly on Holdings Maintenance |
| 15:24 |
dbs |
Wouldn't surprise me if it also caused timeouts for other functions. |
| 15:25 |
dbs |
And the hold targeter would have to work through hundreds or thousands of copies, I suppose. Fun. |
| 15:25 |
csharp |
yeah - we have that issue with old microfilm stuff |
| 15:26 |
|
kmlussier joined #evergreen |
| 15:26 |
csharp |
hmm - not quite the answer here though - 50 shades of grey with 303 copies shows the message fine |
| 15:27 |
csharp |
okay - looks like it's appropriate to mark the bug "Incomplete" |
| 15:27 |
bshum |
Can we blame it on parts? Let's blame it on parts! |
| 15:27 |
bshum |
:) |
| 15:27 |
dbs |
That might be "part" of it. Ahem. |
| 15:27 |
* Dyrcona |
blames everything on parts. |
| 15:27 |
Dyrcona |
@blame parts |
| 15:27 |
pinesol_green |
Dyrcona: It's all parts's fault! |
| 15:28 |
|
dboyle joined #evergreen |
| 15:28 |
Dyrcona |
csharp: There is no such thing as a normal library. |
| 15:28 |
bshum |
Nice, I apparently crashed my test server trying to place a hold via the new patron UI. |
| 15:28 |
* bshum |
adds that to the long list of things to work out :( |
| 15:29 |
|
kmlussier1 joined #evergreen |
| 15:29 |
|
jboyer-isl joined #evergreen |
| 15:32 |
|
kmlussier joined #evergreen |
| 15:34 |
* Dyrcona |
imagines a dynamic battle for survival between kmlussier and her evil clone, kmlussier1. |
| 15:34 |
bshum |
Doesn't seem to be a parts problem either. Though I haven't found bibs with lots of holdings to try further yet. |
| 15:34 |
bshum |
Dyrcona++ # I would watch that movie. |
| 15:35 |
bshum |
... uptime 10 minutes for the test server. Well that's... interesting. |
| 15:35 |
Dyrcona |
You caused it to reboot itself? |
| 15:36 |
Dyrcona |
I'd check the logs very carefully. It likely has nothing to do with what you were doing in Evergreen. |
| 15:36 |
bshum |
Yeah |
| 15:37 |
bshum |
Probably more wackiness up in Springfield. |
| 15:38 |
|
kmlussier joined #evergreen |
| 15:39 |
bshum |
But what of Lazarus? |
| 15:39 |
dbs |
bshum: some vacation, man |
| 15:40 |
bshum |
dbs: I'm just avoiding doing chores around the house. |
| 15:40 |
bshum |
Should probably go vacuum my room/office. |
| 15:47 |
kmlussier |
csharp: I just replicated your holds issue on a title with a lot of copies. |
| 15:50 |
csharp |
kmlussier: oh great! |
| 15:50 |
bshum |
kmlussier: csharp: What's "a lot" roughly? :) |
| 15:51 |
kmlussier |
I'll add it to the bug report. |
| 15:51 |
kmlussier |
In my case, it was 900 |
| 15:51 |
csharp |
it may be related to the number of copies per volume/call number too |
| 15:51 |
csharp |
I haven't dug that deep yet |
| 15:52 |
bshum |
I just did one fine with 938 copies. |
| 15:52 |
bshum |
So I dunno |
| 15:53 |
csharp |
hmm - I wonder what the factor is? |
| 15:55 |
kmlussier |
Possibly a 2.3 vs. 2.4/master issue? |
| 15:55 |
dbs |
local indexes? |
| 15:56 |
Dyrcona |
differences in hardware and load? |
| 15:57 |
bshum |
Could be load. I am all alone on this server after all :( |
| 15:58 |
bshum |
Might also be that per volume thing csharp thought of. |
| 15:58 |
kmlussier |
Sure, but I was using a training server that doesn't have much load. |
| 15:58 |
bshum |
Or maybe it's the number of availables |
| 15:58 |
bshum |
Like if there's 900+ but of that only 30 or 40 could actually match |
| 15:58 |
bshum |
Dunno, lots of variables there :( |
| 15:58 |
* bshum |
tries another bib |
| 15:59 |
|
edoceo joined #evergreen |
| 16:01 |
bshum |
Hmm, it does seem noticeably slower though when I do try it against bibs with large number of holdings. |
| 16:02 |
bshum |
And the time it took to go from Submit to successfully placed took longer I mean. |
| 16:02 |
kmlussier |
bshum: Yes, it was much slower for me too. My first test on the record with just a few copies went through very quickly. |
| 16:04 |
kmlussier |
bshum: Did you say you had the alternate patron editor on the client where you were testing this? |
| 16:04 |
bshum |
kmlussier: I am using that, yeah. |
| 16:05 |
bshum |
kmlussier: But it's not very different. The issue I encountered previously was because the server suffered some mysterious reboot :( |
| 16:05 |
kmlussier |
I was just noticing that the catalog search/place holds screen loads in a different tab instead of being embedded in that patron frame. I wasn't sure if that would make a difference. |
| 16:05 |
|
tspindler left #evergreen |
| 16:05 |
bshum |
That is true. |
| 16:06 |
bshum |
But I doubt that leads to substantial difference. |
| 16:06 |
|
kbeswick joined #evergreen |
| 16:06 |
bshum |
For note though, there is some weird javascript error in the console for those pages. I think it has to do with the function checking for changes to the patron lookup already having the patron set. |
| 16:06 |
bshum |
But I'd have to dig deeper on that one later. |
| 16:07 |
bshum |
Probably isn't related. |
| 16:07 |
|
DPearl joined #evergreen |
| 16:13 |
|
remingtron joined #evergreen |
| 16:18 |
pinesol_green |
[evergreen|Dan Scott] Silence QP warning due to inappropriate cmp op - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb7fb21> |
| 16:20 |
|
dboyle_ joined #evergreen |
| 16:20 |
pinesol_green |
[evergreen|Dan Scott] Prevent JavaScript error on non-Novelist sites - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=31d0f9e> |
| 16:26 |
pinesol_green |
[evergreen|Kathy Lussier] Generate Password Label - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=79eb7d9> |
| 16:28 |
kmlussier |
bshum: It took a lot of tries, but I was finally able to replicate it with a client that was using the alternate patron editor. So you're right - it's not related. |
| 16:45 |
* Dyrcona |
has shut down his dev vm for the weekend. |
| 16:45 |
* Dyrcona |
will build a new one from scratch on Monday. |
| 17:07 |
|
mmorgan1 left #evergreen |
| 17:30 |
|
finnx1 left #evergreen |
| 17:40 |
|
mllewellyn left #evergreen |
| 18:14 |
|
ldwhalen joined #evergreen |
| 18:28 |
|
Dyrcona joined #evergreen |
| 18:29 |
Dyrcona |
tsbere: Thought you might like to know, the version of void wash(int repeat); with the argument is two assembly instructions shorter than the one that initializes repeat inside the function. |
| 18:38 |
Dyrcona |
Ah wait. That is weird. |
| 18:39 |
Dyrcona |
On my laptop the two are identical. |
| 18:48 |
Dyrcona |
Umm. This is strange. |
| 18:48 |
Dyrcona |
On my laptop, the version with the initialization comes out identical to the version with the argument. |
| 18:51 |
Dyrcona |
The version I compiled on my workstation earlier has two additional movl calls..... |
| 18:51 |
Dyrcona |
Oh well. I'll stop yammering about off topic things. |
| 18:55 |
Dyrcona |
Ah... I figured out where the movl instructions are coming from.....silly C. |
| 18:55 |
Dyrcona |
So, guess I was wrong. There is no difference between the version that initializes a local variable versus the one that takes the variable as an argument. |
| 18:56 |
Dyrcona |
The latter is reusable, however. |
| 18:56 |
* Dyrcona |
shuts up for realsies. |
| 19:20 |
hopkinsju |
I'm seeing this when using marc_cleanup: DUMPING RECORD: Tag 020 Junk in subfield code/Null subfield code at 3088/190700 |
| 19:21 |
hopkinsju |
The issue in almost every case is that there is a space between the $ and it's subfield code. i.e. "$ a" |
| 19:21 |
hopkinsju |
Anyone dealt with something like this in a bulk fashion? I'm thinking the library isn't going to want to hear that 4000 of their records are gonna need to be re-entered. |
| 19:44 |
jcamins |
hopkinsju: I encountered that exact data issue in "MARC" records from another system, and used MARC breaker to turn the records into something regex friendly, then fixed them all with a regex, and used MARC maker to turn them back into MARC. I'm not sure if you can get the records out of EG with them corrupted, fix them that way, and then overlay them, but if you can, that might be a solution. |
| 19:53 |
gmcharlt |
with a little care, regexps can also be used for munging the MARCXML that marc_cleanup takes as input, especially since yaz-marcdump, when used to produce the MARCXML, outputs one (XML) tag per line |
| 19:55 |
hopkinsju |
\I'll have to look at the output of yaz-marcdump and see what these hanging dollar signs do to it. |
| 19:56 |
hopkinsju |
Hopefully I can find something to find/replace on. |
| 19:57 |
jcamins |
gmcharlt: that sounds scary. |
| 19:58 |
hopkinsju |
One good thing here is that my records aren't in evergreen yet - I'm migrating a library from an Atriuum system. |
| 19:58 |
hopkinsju |
Plus they were migrated from 2 ILSs previous to Atriuum. I guess I'm the only one who cares. |
| 20:00 |
jcamins |
hopkinsju: in that case, regex is the way to go. |
| 20:11 |
|
jihpringle left #evergreen |
| 20:26 |
gmcharlt |
jcamins: not particularly; not that advocate using regexes a general mechanism for munging XML, but they have their uses for constrained schemas |
| 20:26 |
gmcharlt |
(in response to "that sounds scary") |
| 20:29 |
jcamins |
gmcharlt: I had initially thought that the script was pulling records directly out of the database and then putting them back in. |
| 20:36 |
hopkinsju |
jcamins++ |
| 20:36 |
hopkinsju |
gmcharlt++ |
| 20:36 |
hopkinsju |
That's gonna work just fine... sed --posix 's#code=" ">\(.\)\(.*\)#code=\"\1\">\2#g' |
| 20:37 |
hopkinsju |
I looked over the diff and it was all spot on. |
| 20:40 |
|
ldwhalen joined #evergreen |
| 20:42 |
gmcharlt |
hopkinsju: cool |
| 21:22 |
bshum |
岑子鑌 as my git name could be fun I think. |
| 21:23 |
bshum |
git++ |
| 21:47 |
|
RBecker joined #evergreen |
| 23:26 |
|
b_bonner joined #evergreen |
