Time |
Nick |
Message |
01:00 |
|
Mark__T joined #evergreen |
03:37 |
|
BigRig_ joined #evergreen |
03:37 |
|
Mark__T joined #evergreen |
03:37 |
|
Pibbits joined #evergreen |
03:37 |
|
dconnor joined #evergreen |
03:37 |
|
gdunbar joined #evergreen |
03:37 |
|
bshum joined #evergreen |
03:37 |
|
phasefx_ joined #evergreen |
03:37 |
|
fparks joined #evergreen |
03:37 |
|
dbs joined #evergreen |
03:37 |
|
edoceo_ joined #evergreen |
03:37 |
|
jeff__ joined #evergreen |
03:37 |
|
mtate joined #evergreen |
03:37 |
|
eby joined #evergreen |
03:37 |
|
sseng joined #evergreen |
03:37 |
|
ktomita joined #evergreen |
03:37 |
|
misilot joined #evergreen |
03:37 |
|
AaronZ-PLS joined #evergreen |
03:37 |
|
RBecker joined #evergreen |
03:37 |
|
Callender joined #evergreen |
03:37 |
|
zxiiro joined #evergreen |
03:37 |
|
moodaepo joined #evergreen |
03:37 |
|
hopkinsju joined #evergreen |
03:37 |
|
senator joined #evergreen |
03:37 |
|
paxed joined #evergreen |
03:37 |
|
tfaile joined #evergreen |
03:37 |
|
rri joined #evergreen |
03:37 |
|
pastebot joined #evergreen |
03:37 |
|
gmcharlt joined #evergreen |
03:37 |
|
bradl joined #evergreen |
03:37 |
|
artunit joined #evergreen |
03:37 |
|
jeff_ joined #evergreen |
03:37 |
|
shadowspar joined #evergreen |
03:37 |
|
jcamins joined #evergreen |
03:37 |
|
phasefx joined #evergreen |
03:37 |
|
wjr joined #evergreen |
03:37 |
|
jeffdavis joined #evergreen |
03:37 |
|
pmurray_away joined #evergreen |
03:37 |
|
Simon21 joined #evergreen |
03:37 |
|
eeevil joined #evergreen |
03:37 |
|
berick joined #evergreen |
03:37 |
|
mtj_ joined #evergreen |
03:47 |
|
laque joined #evergreen |
03:52 |
|
jeff joined #evergreen |
06:11 |
|
laque joined #evergreen |
06:38 |
csharp |
fwiw, I would *not* want OpenSRF to have its own page... I'm also not sure how valuable a "layman's" explanation of the functionality of OpenSRF would be. It's a complex enough program to require technical knowledge just to grasp the basics IMHO |
06:39 |
csharp |
s/page/site/ |
07:24 |
|
collum joined #evergreen |
07:30 |
|
jboyer-isl joined #evergreen |
07:31 |
|
rjackson-isl joined #evergreen |
08:20 |
|
kbeswick joined #evergreen |
08:34 |
|
Dyrcona joined #evergreen |
08:36 |
Dyrcona |
jcamins: So I rebooted my workstation, and after I got home I reran my xpath command. It took 5 hours to generate a 134 line output file! Granted, I also piped the output through sort -u. |
08:37 |
Dyrcona |
jcamins: It used 3.6GB of RAM to process an approximately 70MB xml file. |
08:37 |
Dyrcona |
I probably could have done what I wanted faster with sed. |
08:40 |
|
Meliss joined #evergreen |
08:42 |
jcamins |
Wow. |
08:43 |
jcamins |
Yeah, I think next time it might be worth doing so. |
08:44 |
|
bkuhn joined #evergreen |
08:44 |
|
mmorgan joined #evergreen |
08:48 |
|
DPearl joined #evergreen |
08:53 |
|
mtj_ joined #evergreen |
08:54 |
|
laque joined #evergreen |
08:55 |
|
rfrasur joined #evergreen |
08:56 |
rfrasur |
jboyer-isl: do you have a quick link to our installation download? |
08:57 |
rfrasur |
or rjackson-isl |
09:00 |
jboyer-isl |
You mean to just grab the client? it's (server)/updates/manualupdate.html It should always have current clients |
09:00 |
jboyer-isl |
Well, for Windows at least. |
09:00 |
rfrasur |
yep |
09:00 |
rfrasur |
I need to start from scratch on a laptop |
09:01 |
|
ericar joined #evergreen |
09:02 |
rfrasur |
okay, I got it going. thank you |
09:03 |
rfrasur |
okay, thanks sir. see ya later. |
09:22 |
|
ericar joined #evergreen |
09:27 |
* dbs |
noticed, while testing the upgrade path for the catapostrophe fix from 2.3 - 2.4, that the 2.3-2.4.0 upgrade script will bomb out for anyone who recently installed 2.3 due to having already applied upgrade 0788. I suppose we should move that into its own transaction in the upgrade script. |
09:29 |
dbs |
huh, or is that because I installed from rel_2_3 and not a packaged version which might get a different value in 002.schema.config.sql? |
09:29 |
* dbs |
looks |
09:31 |
dbs |
Nope, that's in the packaged 2.3.8 tarball |
09:31 |
|
afonit joined #evergreen |
09:32 |
dbs |
and 2.3.7 |
09:34 |
|
DPearl joined #evergreen |
09:36 |
eeevil |
yeah ... I'll pull 788 into its own chunk. soon |
09:36 |
paxed |
bah. character encoding problems in javascript. |
09:37 |
dbs |
encodeURIComponent() instead of escape()? |
09:37 |
dbs |
eeevil++ |
09:38 |
|
mrpeters joined #evergreen |
09:38 |
paxed |
dbs: right. but also, some window.open() calls don't get the charset in data URIs. fixing that one. |
09:39 |
paxed |
the js escape() is deprecated, so perhaps we should s/escape/encodeURIComponent/ or something |
09:41 |
hopkinsju |
Had that same error with the 2.3-2.4.0 database upgrade script. Can anyone help me debug this morning? I think this is going to be a problem for anyone with an older database and it'd be great to get a patch in. |
09:41 |
hopkinsju |
dbs: you working on this already? |
09:42 |
dbs |
hopkinsju: eeevil just said he was going to fix it for the 2.4.1 release |
09:42 |
dbs |
hopkinsju: if you want, I'll throw a simple branch up for you to try |
09:43 |
hopkinsju |
Right on, not sure if I was reading that right... but I think I'm tracking you. |
09:44 |
hopkinsju |
You're saying that I need to commit the transaction after all the table altering happens, then start a new one before dropping tsearch2? |
09:49 |
dbs |
hopkinsju: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/do_not_duplicate_0788 |
09:50 |
dbs |
ahem - just force-pushed a fix : |
09:51 |
hopkinsju |
Right on. |
10:02 |
|
yboston joined #evergreen |
10:05 |
csharp |
is there a way for the upgrade script to continue on if the numbered upgrade script has already been applied? (e.g. "oh, I see you already have 0788 - skipping...." |
10:05 |
csharp |
) |
10:21 |
dbs |
csharp: no, it errors out. Thus, moving it into its own transaction... |
10:22 |
dbs |
If we created a stored procedure for each numbered upgrade, then that could return gracefully. |
10:27 |
Dyrcona |
I use a perl script to check what upgrades are needed, but that works mainly for master, and assumes that you have been keeping up with numbered upgrades in the proper order. |
10:28 |
Dyrcona |
http://git.mvlcstaff.org/?p=jason/evergreen_utilities.git;a=blob;f=scripts/db_upgrade.pl;h=b5532b789f688ec7afae47bd88b25a2060a6ddf7;hb=b212ac95e7d7e06a5ed1fdfd075109ca89c16926 |
10:29 |
hopkinsju |
dbs: Well, I did in fact already have 0788 so this will save me time, but I wasn't clear when I jumped in this morning - that's not the problem I was having yesterday. |
10:29 |
hopkinsju |
I'm aborting when trying to drop tsearch2 because it has dependencies. |
10:30 |
hopkinsju |
gmcharlt suggested altering my search_path, which did need to happen, but that didn't resolve the issue. |
10:33 |
|
akilsdonk_ joined #evergreen |
10:46 |
|
BigRig joined #evergreen |
11:02 |
eeevil |
dbs: Imma steal your branch for 0788. thanks! |
11:03 |
dbs |
eeevil: my pleasure sir |
11:12 |
|
sseng joined #evergreen |
11:12 |
|
ktomita joined #evergreen |
11:13 |
|
mllewellyn joined #evergreen |
11:18 |
pinesol_green |
[evergreen|Dan Scott] Avoid 0788 duplication from 2.3 failure - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=77b750d> |
11:27 |
|
acoomes joined #evergreen |
11:33 |
|
afonit_ joined #evergreen |
11:35 |
|
acoomes_ joined #evergreen |
11:47 |
|
tfaile_ joined #evergreen |
11:48 |
|
Callender joined #evergreen |
11:52 |
|
pastebot joined #evergreen |
11:57 |
|
jdouma joined #evergreen |
12:04 |
|
jihpringlw joined #evergreen |
12:37 |
jboyer-isl |
Anyone have a quick clue where I might need to poke around to add an option to the Advanced Search page on the OPAC? templates/opac/parts/advanced/search.tt2 appears to pull everything from another source. |
12:38 |
jboyer-isl |
Looking at 2.4, forgot to mention. |
12:38 |
paxed |
option? you mean drop-down box like "Item Type" etc? |
12:38 |
bshum |
jboyer-isl: Depends on what version of TPAC you have. config.tt2 arranges things and the database does the rest. |
12:38 |
bshum |
Coded_value_map |
12:39 |
paxed |
and searc.adv_config in config.tt2 |
12:39 |
paxed |
search* |
12:39 |
jboyer-isl |
I wasn't specific enough. I'd like to add a Search Filter Group to the page, not add or remove an option in one of the existing select boxes |
12:40 |
jboyer-isl |
I'll check out config.tt2, that sounds good |
12:42 |
jboyer-isl |
Excellent. have it all mapped out. Thanks bshum and paxed! |
12:42 |
dbs |
hopkinsju: hmm. does it say which dependencies are left? |
12:45 |
|
laque joined #evergreen |
13:00 |
hopkinsju |
dbs: psql:version-upgrade/2.3-2.4.0-upgrade-db.sql:98: ERROR: cannot drop extension tsearch2 because other objects depend on it |
13:00 |
hopkinsju |
DETAIL: function tsvector_concat(tsvector,tsvector) depends on type tsvector |
13:00 |
hopkinsju |
HINT: Use DROP ... CASCADE to drop the dependent objects too. |
13:02 |
dbs |
hopkinsju: right, so can you put a "DROP AGGREGATE agg_tsvector(tsvector); DROP FUNCTION tsvector_concat(tsvector, tsvector);" before that DROP EXTENSION call? |
13:17 |
hopkinsju |
dbs: gotta run an errand, but will do! |
13:25 |
|
ericar joined #evergreen |
13:38 |
|
mcooper joined #evergreen |
13:52 |
csharp |
circ policy changes (in-db) are immediate, right? no need for autogen/opensrf restart? |
13:52 |
* csharp |
has apparently borked circ on his test server |
13:53 |
csharp |
same dataset, same ruleset on prod/test, same item, same patron, same, location, different rules are chosen |
13:54 |
csharp |
test is picking the default rule, prod selects the correct rule |
13:54 |
csharp |
"default rule" = id 1 |
13:54 |
csharp |
@monologue |
13:54 |
pinesol_green |
csharp: Your current monologue is at least 6 lines long. |
13:56 |
mcooper |
csharp: believe they are immediate … delete all rules and circs can't happen, w/o having to restart anything (if I recall correctly) ... |
13:56 |
csharp |
ok |
13:56 |
csharp |
thanks |
13:56 |
bshum |
Correct, immediate. |
13:56 |
bshum |
Or rather, each circulation consults the table anew. |
13:56 |
csharp |
ok - that makes sense |
13:59 |
csharp |
same weights |
14:00 |
* bshum |
cues twilight zone music |
14:00 |
|
stevenyvr2 joined #evergreen |
14:03 |
* csharp |
decides to start fresh |
14:30 |
|
jcamins_ joined #evergreen |
14:35 |
|
jrshaw joined #evergreen |
14:41 |
bshum |
@coin |
14:41 |
pinesol_green |
bshum: tails |
14:45 |
* Dyrcona |
yawns. |
14:45 |
Dyrcona |
Is it just me or has this been a strange week for anyone else? |
14:45 |
bshum |
It's been a strange week. |
14:48 |
phasefx |
si, aqui tambien |
14:49 |
Dyrcona |
I think my latest xpath foray has actually produced all the output that it is going to, but the program has been spinning its wheels for past 3 hours. |
14:51 |
Dyrcona |
Guess I'll let it go until it decides its finished. |
14:52 |
jrshaw |
So I worked with the client Tuesday and liked what I saw. Now I am on to the server installation. Working on the OpenSRF installation on a VirtualBox ubuntu 12.04 server. Section 2. Prerequisites: The second command fails: ~$ make -f src/extras/Makefile.install ubuntu-precise ErrorMsg=> make: src/extras/Makefile.install: no such file or directory Any ideas? Is there an assumed (but undocumented) git needed here? |
14:53 |
Dyrcona |
You're not in the right directory for that. |
14:53 |
Dyrcona |
You need to be in the directory where your git checkout or tarball was extracted. |
14:54 |
Dyrcona |
You will also need sudo on that command. |
14:55 |
jrshaw |
I did do the sudo. sorry I left that out. Now is the documenter assuming that the opensrf has been extracted already? |
14:58 |
Dyrcona |
jrshaw: Yes, you can't very well read the README where that comes from unless you've extracted the tarball already. |
14:59 |
Dyrcona |
Not saying you're reading the extracted README, but that's where the online directions come from. |
14:59 |
dbs |
The documenter assumes that the person doing the install of a package from a tarball has done so before, because the documenter must assume some level of familiarity with command line linux administration. |
15:01 |
jrshaw |
Ah, but I cheated!!!. I'm reading it off the documentation from the OpenSRF download page. This one of those chicken or egg deals... Now I get it. Thanks Dyrcona dbs |
15:13 |
|
finnx joined #evergreen |
15:17 |
|
mrpeters joined #evergreen |
15:40 |
jeffdavis |
http://pastebin.com/1yM4fdRF <- we're seeing a difference between 2.2 and 2.4 with open-ils.search.biblio.multiclass.query.staff which I can't explain |
15:41 |
bshum |
@blame new QP |
15:41 |
pinesol_green |
bshum: everything was going great until new QP came along |
15:41 |
bshum |
Precisely. |
15:41 |
bshum |
(not) |
15:42 |
jeffdavis |
:( |
15:42 |
bshum |
That was just a gut reaction. Not an actual statement of fact. |
15:42 |
jeffdavis |
Basically in 2.4 the search returns a bunch of records for e-resources which don't have any URIs within the search scope, which is not desirable. |
15:43 |
jeff_ |
doh. opened a ticket with no subject. oops. |
15:43 |
jeff_ |
too much rushing. |
15:43 |
jeffdavis |
I guess this is just a case of bug 925776 |
15:43 |
pinesol_green |
Launchpad bug 925776 in Evergreen 2.4 "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 4, heat: 22) [Medium,Confirmed] https://launchpad.net/bugs/925776 |
15:43 |
bshum |
That's kind of what I would think |
15:44 |
jeffdavis |
it worked for us in 2.2 though, but if we did local customizations to fix it I can't figure out where they are |
15:44 |
bshum |
It's supposed to do that with empty bibs, I think for catalogers to add new holdings for. |
15:44 |
bshum |
The located URI mess is a problem indeed. |
15:48 |
jeffdavis |
It would probably be acceptable if the out-of-scope records appeared but were grayed out, so I guess I will see if I can hack something together for that, but this is going to look like a significant regression to our libraries |
15:50 |
dbs |
jeffdavis: that's in the staff client, right? |
15:51 |
jeffdavis |
yes |
15:51 |
jeffdavis |
non-client is ok |
15:52 |
jeffdavis |
I could force use of open-ils.search.biblio.multiclass.query instead of open-ils.search.biblio.multiclass.query.staff I guess, but I imagine that would have undesirable side-effects in other ways... |
15:52 |
bshum |
jeffdavis: Well, in JSPAC they used to be gray bibs. We *hated* that. :D |
15:52 |
bshum |
In TPAC they're white, so that's not much nicer really. |
15:56 |
mmorgan |
We have a lot of libraries that get confused by the empty bibs. They're searching in their own scope and it makes it look like they own those titles. |
16:04 |
bshum |
Something for people to throw development resources at, I guess? It's been talked about in bugs and threads numerous times I feel... |
16:07 |
bshum |
I'd look around at it some more, but none of my servers are reachable for the moment while there's work being done on our networks. |
16:07 |
* bshum |
twiddles thumbs and tries to remember he's on vacation too. |
16:07 |
jeffdavis |
bshum: you're on vacation? If I had ops in this channel I'd be tempted to /kick you ;) |
16:08 |
jeffdavis |
(but I'm glad you're here and answering my questions!) |
16:09 |
bshum |
I want to say there was a bug where folks were talking about developing some sort of "show only actual holdings" kind of button that would avoid showing all the empty bibs. |
16:09 |
bshum |
For catalogers, it seemed important for them to attach holdings, but for everybody else it does seem like a waste of time. |
16:10 |
phasefx |
since the Z39.50 interface has the native catalog option, showing those empty bibs elsewhere seems less important to me |
16:11 |
bshum |
Hmm |
16:11 |
bshum |
Interesting thought. |
16:12 |
bshum |
I'd have to ask our cataloging group what they think of that idea (I think z39.50 is offlimits to front-line staff catalogers) |
16:12 |
|
rfrasur joined #evergreen |
16:16 |
phasefx |
because where else will you get a duplicate bib? |
16:16 |
dbs |
jeffdavis: i do wonder whether the "re:imagining" part is throwing QP for a loop (thinking "re:" is some kind of search class) |
16:17 |
bshum |
phasefx: Something like that. I think it's policy that HQ is the only one loading new bibs unless it's an acq library using the loader (which now does some slightly smarter matching to prevent too much duplication). |
16:17 |
mmorgan |
Wouldn't the catalogers be searching unscoped? If they're searching scoped, they're seeing empty bibs and their own bibs, missing bibs that other libraries own. |
16:23 |
bshum |
mmorgan: That does sound logical. |
16:23 |
jeffdavis |
dbs: good thought, but nope - search for "imagining change how to" gives the out-of-scope e-resource records too |
16:23 |
* bshum |
shrugs, problem for a less rainy day? |
16:24 |
dbs |
jeffdavis: okay, cool |
16:24 |
mmorgan |
bshum: and probably a problem for when you're not on vacation. |
16:24 |
Dyrcona |
Give me elebenty billion dollars and I'll fix it! |
16:25 |
jeffdavis |
Dyrcona: I've $20 and a Starbucks gift card... :) |
16:25 |
rfrasur |
hmm, if you give me elebenty billion dollars, I'll find a way to fix it! |
16:26 |
* rfrasur |
will use to hire Dyrcona (and use the balance for an extended vacation) |
16:26 |
bshum |
I think there's chocolate chip cookies downstairs. That sounds like an effective course of action for this moment. |
16:27 |
rfrasur |
(or chocolate chip cookies) |
16:34 |
|
jihpringlw left #evergreen |
16:35 |
|
jihpringle joined #evergreen |
16:54 |
dbs |
Favourite problem report of the day: circ staff reported they could not place a hold for a patron since the upgrade. Resolution: they had looked up the book in a regular browser, not in the staff client. Problem solved. |
16:54 |
bshum |
dbs: That story makes me want to cry. |
16:54 |
bshum |
And scream |
16:54 |
rfrasur |
dbs: That story makes me want to laugh and cry |
16:54 |
bshum |
But at least it was solved. |
16:55 |
* rfrasur |
made her staff watch a billing webinar today though. Vindication |
16:55 |
* rfrasur |
smiles evilly |
16:55 |
dbs |
Yes, it being solved is why it's my favourite problem |
16:56 |
rfrasur |
(and I chuckled when I saw their eyes droop and little drops of spittle form at the corners of their mouths) |
16:56 |
* dbs |
imagines the Nazis at the end of Raiders of the Lost Ark |
16:58 |
rfrasur |
that's probably not too far from accurate - but I did feed them lunch and cinnamon rolls earlier. that MIGHT make up for it...maybe. |
17:00 |
dbs |
_Frosted_ cinnamon rolls could make me forgive you for anything. |
17:00 |
* dbs |
now goes home |
17:00 |
rfrasur |
dbs++ # safe travels |
17:04 |
|
mmorgan left #evergreen |
17:07 |
* rfrasur |
is also going home very soon after planting some donated tomato plants. |
17:13 |
Dyrcona |
Jeez, XML::XPath! Eight hours to parse a file and the last five of those spent apparently doing nothing. |
17:17 |
bshum |
:( |
17:18 |
Dyrcona |
Suddenly wants Hill Billy Tacos.... |
17:18 |
Dyrcona |
That's tacos, basically, on a plate of Fritos instead of taco shells. |
17:20 |
Dyrcona |
Of course, Hill Billy Tacos would not be complete with re-runs of '80s BBC sitcoms.... |
17:20 |
Dyrcona |
s/with/without/ |
17:23 |
Dyrcona |
And Blatz..... |
17:26 |
|
ldwhalen joined #evergreen |
17:28 |
|
finnx left #evergreen |
17:58 |
hopkinsju |
dbs: can you be more specific about where to add those two lines? Here's what I've got (with some extra lines for context) http://paste.evergreen-ils.org/32 |
17:59 |
hopkinsju |
And it failed. Sadface. |
18:14 |
|
Dyrcona joined #evergreen |
18:19 |
|
shadowspar joined #evergreen |
18:21 |
|
rfrasur joined #evergreen |
18:35 |
pastebot |
"jeffdavis" at 204.193.129.146 pasted "2.3-2.4.0-upgrade.sql tsvector customizations" (53 lines) at http://paste.evergreen-ils.org/33 |
18:35 |
jeffdavis |
hopkinsju: ^ that's what the relevant version of that upgrade script looks like for us |
18:35 |
jeffdavis |
we're using DROP ... CASCADE |
18:39 |
Dyrcona |
Hurrah for backups! |
18:39 |
rfrasur |
backups++ |
18:40 |
* jeffdavis |
is scared to ask... |
18:40 |
Dyrcona |
Y'know that complaint I made earlier about xpath taking 8 hours? |
18:41 |
Dyrcona |
I, uh, did something before I realized, and lost that plus the source files.... |
18:41 |
Dyrcona |
rsync with --del can be dangerous..... |
18:41 |
jeffdavis |
backups++ |
18:41 |
jeffdavis |
@karma backups |
18:41 |
pinesol_green |
jeffdavis: Karma for "backups" has been increased 3 times and decreased 0 times for a total karma of 3. |
18:41 |
Dyrcona |
Anyway, now I have a chance to test a C version of xpath. |
18:42 |
rfrasur |
backups needs more karma |
18:42 |
Dyrcona |
backups++ |
18:42 |
Dyrcona |
backups times elebenty! |
18:42 |
rfrasur |
Dyrcona: that phrase "I, uh, did something before I realized..." should somehow be immortalized as well. |
18:43 |
rfrasur |
"If I had a nickel..." |
18:43 |
Dyrcona |
<Bill Gates> If I had a nickel for every time Windows crashed....Oh wait! I do! |
18:43 |
* rfrasur |
laughs |
18:44 |
rfrasur |
Right now, as I sort through our library's entire collection, and try to get it into a manageable format and cleaned before inventory, I'm am immensely happy about the billing webinar from earlier today that I didn't watch and my staff did. |
18:45 |
* rfrasur |
thinks of other things to balance the scales of mind numbing horror. |
18:51 |
rfrasur |
Hmm, they did come up with some awesome program ideas though. |
18:53 |
Dyrcona |
Before I figure out how to munge an example program in C to do what I want, I think I'll XML::LibXML in Perl to compare its performance with XML::XPath. |
18:55 |
rfrasur |
backups++ |
18:57 |
rfrasur |
I'm creating a shelving location called "Find Me" for the things in the database that I'd never be able to find based on info that's been provided. It'll be a staff scavenger hunt. I should get prizes. |
18:57 |
mcooper |
Dyrcona: 8 hours for xpath? how big is the file? or a huge number of queries? sounds painful ... |
18:58 |
Dyrcona |
mcooper: 70MB, 1 query. |
18:58 |
Dyrcona |
Apparently, installing XML::XPath also installs a command line program called xpath. That is what I was using. |
18:59 |
Dyrcona |
rfrasur: Too bad other directors aren't as cool as you! |
19:00 |
rfrasur |
I'm not cool. I'm grumpy, but I still want them to work...and I've found that flogging tends to impede that. |
19:00 |
* rfrasur |
would MUCH rather flog. |
19:00 |
|
ldwhalen joined #evergreen |
19:01 |
mcooper |
Dyrcona: really … that goes against my experience with various langs/libs and xpath - don't believe i've ever used that program though |
19:03 |
Dyrcona |
XPATH(1p) User Contributed Perl Documentation |
19:03 |
Dyrcona |
xpath uses the XML::XPath perl module to make XPath queries |
19:04 |
rfrasur |
okie - time to start dumping this into EG and start makin' some magic happen. |
19:04 |
Dyrcona |
I'm about to try 5 sloc using XML::LibXML instead. |
19:05 |
* Dyrcona |
wishes he had magic. |
19:05 |
rfrasur |
You code the magic. |
19:05 |
mcooper |
Dyrcona: who doesn't =) |
19:06 |
rfrasur |
the benefit of not knowing how something works is that it looks like magic |
19:06 |
* rfrasur |
likes to live under the illusion from time to time. |
19:07 |
* rfrasur |
probably should have used a copy bucket |
19:07 |
rfrasur |
oh well, too late now |
19:10 |
rfrasur |
yeah...def copy buckets. it was a bad idea to use the item status screen |
19:13 |
mcooper |
Dyrcona: i see i have this xpath of which you speak … going to see what happens when run against a 4gb file of marcxml records … pulling out the records ids =) |
19:29 |
|
ldwhalen joined #evergreen |
19:41 |
Dyrcona |
mcooper: I'm finding XML::LibXML to be picky about name spaces. |
19:54 |
Dyrcona |
For the record: XML::LibXML is much faster. |
19:54 |
Dyrcona |
Also, who names a method registerNs()? That lower-case s is a trick, I tell you! |
19:56 |
rfrasur |
the worst Jeopardy ever. Words of Stevie Wonder...seriously |
19:56 |
rfrasur |
:p |
19:56 |
Dyrcona |
Really? |
19:57 |
rfrasur |
well, for me it was. I'm sure there are experts at the words of Stevie Wonder |
19:57 |
* Dyrcona |
tries to remember the words to that one song...the one that the Chili Peppers covered..... fails |
19:58 |
rfrasur |
lol, see? |
19:58 |
rfrasur |
hmm, you can't upload a file into a bucket? |
19:59 |
rfrasur |
unfortunate |
20:00 |
|
stevenyvr2 left #evergreen |
20:02 |
Dyrcona |
I might just to document this little xpath script that I wrote. |
20:03 |
Dyrcona |
"just to" |
20:03 |
* Dyrcona |
scratches his head. |
20:03 |
Dyrcona |
It has been a long day. |
20:03 |
rfrasur |
lol...do it. and yes...it has been...and continues to be. |
20:03 |
rfrasur |
but just imagine how awesome it'll be to have something that works and is documented. |
20:04 |
rfrasur |
and I'll imagine the beauty of the digital representation of our collections |
20:04 |
* rfrasur |
can see it now |
20:16 |
rfrasur |
EG is the best software ever. Just saying. |
20:19 |
* Dyrcona |
could use some "Potent Potables" about now. ;) |
20:20 |
rfrasur |
I drank all my chocolate milk or I'd share. |
20:20 |
Dyrcona |
hah |
20:21 |
* Dyrcona |
goes for some ginger ale and some popcorn. |
20:21 |
rfrasur |
not particularly potent...but quite lovely. oooo...ginger ale is good too |
20:22 |
jcamins |
rfrasur: you're having chocolate milk today too? |
20:23 |
rfrasur |
yep! |
20:23 |
jcamins |
We're having frozen mint chocolate milk. |
20:23 |
jcamins |
The frozen was accidental. |
20:23 |
rfrasur |
it cures what ails ya...unless what ails ya is dairy intolerance |
20:23 |
rfrasur |
hmm, that sounds awesome |
20:23 |
jcamins |
I put it in the freezer yesterday because it was lukewarm. |
20:23 |
jcamins |
Then I forgot about it for 24 hours. |
20:23 |
* rfrasur |
laughs |
20:24 |
jcamins |
But I think I actually like it this way. |
20:24 |
jcamins |
Next time I think I might freeze it in an ice cube tray. |
20:24 |
rfrasur |
yeah, especially with the mint |
20:24 |
jcamins |
(the mint, by the way, is from the schnapps) |
20:24 |
rfrasur |
oooooooo, even BETTER |
20:25 |
* rfrasur |
was just trying to figure what to use other than extract |
20:25 |
jcamins |
Yeah, the Schnapps works really well. I highly recommend it. |
20:26 |
rfrasur |
I'm gonna try it this weekend since apparently if you don't attend ALA, you're supposed to pretend that you're there...and apparently what you do there is drink (I learned this recently) among other things |
20:27 |
* rfrasur |
thought you went to seminars and stuff |
20:27 |
* rfrasur |
was wrong |
20:27 |
jcamins |
Very wrong. |
20:27 |
rfrasur |
very |
20:36 |
jcamins |
rfrasur: also, if you're not at ALA you're supposed to sing something about librarians to the tune of "Here's to the ladies who lunch," I think. Unfortunately, "librarians" and "ladies who lunch" have the same number of syllables, but don't scan the same. |
20:37 |
rfrasur |
hmm, I'll give a try...after the schnapps |
20:37 |
* rfrasur |
has a reputation for singing ridiculous things at inappropriate times anyway |
20:52 |
csharp |
so does adding a circulation limit to a circ matchpoint change the "matchability"? I added a dvd limit to our existing dvd rule (based on circ mod) and now the original rule doesn't match the item |
20:52 |
* csharp |
headdesk |
20:53 |
rfrasur |
you know more than me |
20:54 |
csharp |
:-D |
20:54 |
rfrasur |
I wanna know why NO book in this section has any "circulate as type" set |
20:55 |
csharp |
I'm just going to work under the assumption that the circ limit sets does not work the way I'm expecting it to :-/ |
20:55 |
rfrasur |
catalogers relying on templates and not double checking quality |
20:55 |
rfrasur |
that seems to be a fair assumption |
20:55 |
csharp |
circulate as type shouldn't be necessary if a circ mod is assigned |
20:56 |
rfrasur |
it's not necessary, but I like consistency across the collections :p |
20:57 |
rfrasur |
and it can affect reports depending on how their built and what someone is looking for |
20:57 |
jeff_ |
"circulate as type" only comes into play if you are using circ rules based on marc type, and for some reason you want to override the record marc type for that copy when it circulates. |
20:58 |
rfrasur |
aye - but it doesn't come into play at all if it's not set |
20:58 |
jeff_ |
in our environment, i consider "circulate as type" on a copy as something that should always remain unset. |
20:58 |
csharp |
same here |
20:59 |
jeff_ |
also, we try to keep holdable / opac visible / circulate always set to the default of Yes on copies, then rely on the copy / shelving location settings to determine those settings. |
20:59 |
jeff_ |
our QA reports will soon flag those as errors |
21:00 |
rfrasur |
I don't disagree w/ either of you. |
21:00 |
rfrasur |
but... |
21:00 |
rfrasur |
do it or don't do it. consistency |
21:00 |
jeff_ |
what works for us does not always work for everyone. :-) |
21:03 |
rfrasur |
honestly, I barely can tell what works most of the time. |
21:04 |
jeff_ |
we've started maintaining QA rules in the reporting database which say "this shelving location at this library should only contain copies with these circ modifiers" or "...should only contain copies attached to volumes with a label that looks like PATTERN" |
21:04 |
jeff_ |
then reporting on when things don't match. |
21:04 |
jeff_ |
it catches errors, either in copy templates or just in data entry. |
21:04 |
rfrasur |
ooooooo, that sounds quite wonderful |
21:05 |
rfrasur |
that's what I'm fixing right now....all the data entry errors |
21:05 |
bshum |
csharp: I don't think that sounds right. Re: circ limit set breaking matching. |
21:05 |
rfrasur |
for 35k items |
21:05 |
rfrasur |
(thankfully, they're not all wrong) |
21:05 |
jeff_ |
once i upgrade the reporting server, those reports will run nightly or weekly, and only send email (with attached pdf) when there's an error. |
21:05 |
csharp |
bshum: I saw it match the correct rule - then added the circ limit sets to the rules, now it doesn't match |
21:05 |
csharp |
that's what I saw earlier |
21:06 |
rfrasur |
jeff_: show off :p |
21:06 |
csharp |
and removing/deactivating the circ limit set doesn't change it back |
21:06 |
jeff_ |
we're also grouping shelving locations into "departments", so that the teen librarian at main branch will get a report of the errors in her collection, but not the A/V issues at Branch 2, for example. |
21:06 |
bshum |
csharp: So it comes up with no matchpoint found or that it's going to some other rule? |
21:06 |
csharp |
I have no idea |
21:06 |
rfrasur |
jeff_: Can I hire you for free? |
21:06 |
csharp |
it no longer matches the circ mod based rule - now it matches on marc type |
21:06 |
bshum |
csharp: It could be that maybe there are two rules of similar weight and it's spontaeously picking the wrong one on you. Happened to me before. |
21:07 |
bshum |
When two rules were close but still unique enough to screw things up. |
21:07 |
csharp |
yeah - that's what I'll try again next |
21:07 |
csharp |
gonna hang it up for tonight though |
21:07 |
* csharp |
sighs in disgust |
21:07 |
bshum |
We don't use marc types in our system, so I can't speak to how that matching works (our rules leave that NULL I think). |
21:08 |
bshum |
But maybe it's some weird weighting issue and it's shifted slightly in the wrong direction. |
21:08 |
bshum |
I'll be happy to take a look at it with you later on csharp. Sorry it's frustrating. |
21:08 |
csharp |
bshum: thanks - I appreciate your help |
21:09 |
jeff_ |
very pleased that i figured out the (simple, really!) means of having the contents of a drop-down for Criteria FOO dynamic based on what you selected in Criteria BAR and Criteria BAM |
21:09 |
jeff_ |
that makes reports on "circ lib + copy location" more sane, in terms of not setting you up for failure by presenting you with copy locations from something other than the selected circ lib. |
21:09 |
rfrasur |
jeff_: seriously, it sounds very cool. It'd definitely cut down on the mess we have (which is actually better than it was....but still not pretty) |
21:09 |
jeff_ |
no custom jsp required. |
21:11 |
|
mcooper joined #evergreen |
21:11 |
jeff_ |
looking at some hold ratio reports and some ">1 hold at this pickup lib, but this lib has no local copies" reports, i really want to get back to metarecords and some duplicate detection QA reports. |
21:12 |
jeff_ |
because i'm seeing things like "22 holds on the 2-disc collectors edition of this recent movie" which would probably be Just Happy being filled by the 1 disc copies which we have lots of copies of. |
21:12 |
|
jihpringle left #evergreen |
21:12 |
jeff_ |
(and/or vice versa) |
21:13 |
rfrasur |
you're right...but they might not be? how would you differentiate? |
21:13 |
jeff_ |
rfrasur: thanks! i talk about it here in the hope that some other libraries will become interested and join us in reporting this way, so that we're not just doing it ourselves. :-) |
21:15 |
jeff_ |
rfrasur: by grouping similar formats/editions by default, having metarecord holds (for the same marc type) be default, but letting users know that their hold will be filled by copies on any of the following records -- can get tricky when you get into things like DVD vs blu-ray, but that should be possible as a "hey, do you want to hold out and wait longer for the blu-ray, or take what you get?" |
21:15 |
jeff_ |
back in the days when people smoked in restaurants, it's the "first available" response to "smoking or non?" |
21:15 |
rfrasur |
jeff_: I think there's a pretty diverse emphasis on QA throughout our consortium, but for OUR library - I want it to be "perfect." though I try not to phrase it that way w/ staff since "perfect" is unattainable and terrifying (for some) |
21:15 |
rfrasur |
ahhh....yes, that makes sense |
21:16 |
jeff_ |
yeah. "perfection" is actually more attainable in smaller collections, it seems. we have 100% cover art coverage for our main branch videogame collection, because it was "only" 130 or so titles at launch. |
21:16 |
jeff_ |
so we made sure they all had covers. |
21:16 |
jeff_ |
and as a retult, the search results look pretty nice. |
21:16 |
jeff_ |
but that's extra effort. :P |
21:17 |
rfrasur |
for most of collections...we can get close. for some, not so much, but at least the shelving locations can be right and call number consistent |
21:17 |
jeff_ |
hrm. 189 titles now. neat. |
21:18 |
rfrasur |
for which consoles do y'all collect? |
21:20 |
jeff_ |
huh. 27 branch videogame titles have been upgraded with a "real" bib record, so now they're showing in searches (good and bad, because that branch says "no holds") |
21:21 |
jeff_ |
rather, 27 of the bibs that were "brief/stub" and have now been upgraded stood out to me in a search because they lacked covers. :-) |
21:21 |
rfrasur |
lol...real=less accessible |
21:21 |
jeff_ |
rfrasur: we buy for xbox 360, wii, and playstation 3. we take donations for anything. mostly those three plus some playstation 2. |
21:21 |
rfrasur |
gotcha |
21:22 |
jeff_ |
we had dreams of having a lot of retro games donated and loaning retro consoles, but that didn't happen for Reasons. |
21:23 |
jeff_ |
if it was during open hours, i'd be tempted to reload this search results page a few times so that someone else would get these missing covers in their queue, but main branch is closed, so i doubt anyone's looking. :-) |
21:23 |
rfrasur |
yeah - we had dreams of several things that have been backburnered for Reasons - but it's probably for the best at this point. I'm wanting to go in different direction and have money for this OR that. |
21:23 |
rfrasur |
lol |
21:26 |
* rfrasur |
calculates the odds of inventory being finished by the end of July. |
21:34 |
jeff_ |
inventory interests me. this might be a sign of some illness, but i'm curious -- how do you do yours, why do you do it, etc? |
21:35 |
jeff_ |
are you just scanning books to check them in (even though they're likely already checked in), then reporting on copies in Available/Reshelving status that haven't been edited since you began your inventory? |
21:35 |
jeff_ |
Or are you going out with a printed list and checking items off of it? |
21:36 |
rfrasur |
at my old lib (in the same consortium) we just called it reading shelves - apparently it's called inventory elsewhere. It involves running lists of items...taking the lists to the shelves...and yes, checking them off. making sure that statuses make sense, things are in order, etc. |
21:36 |
rfrasur |
and then fixing whatever's messed up. It's pretty intensive. |
21:36 |
jeff_ |
any reason why you don't just take a laptop or a tablet into the stacks? |
21:37 |
jeff_ |
i'd imagine that the bulk of the items are correct, then you could cart those needing attention back, or just fix some in-place (depending on what needs fixin') |
21:37 |
rfrasur |
I, personally, do. My staff has a variable amt of comfort w/ tech. It's much harder to ruin a paper list of materials than to trash a spreadsheet. |
21:38 |
rfrasur |
of course, I know that a trashed spreadsheet can be fixed generally...but some of them don't and panic. |
21:38 |
jeff_ |
(but i understand if my ideas show a terrible naiveté and you decide to laugh at me) |
21:39 |
jeff_ |
oh, i wasn't thinking of a spreadsheet, just using the staff client. |
21:39 |
jeff_ |
check in items, most will just already be checked in. some will say "hey, this was missing!" or "hey, this was still checked out!" |
21:39 |
jeff_ |
and just keep an eye on the call number and shelving location reported at checkin to ensure that those seem right. |
21:40 |
jeff_ |
of course, doesn't do anything for "this item should go five places back on the shelf" |
21:40 |
jeff_ |
but that might be out of scope anyway. |
21:41 |
rfrasur |
it's not a bad idea - but this works and we end up with nice lists. Actually, it's more than an inventory...which is one reason I never used the phrase before this lib. |
21:41 |
jeff_ |
and that's kinda' why i was wondering both -- how you do it, and what the goals and outputs are. :-) |
21:41 |
jeff_ |
so, what kinds of things do you do above and beyond "inventory"? |
21:42 |
jeff_ |
what makes it more than an inventory? |
21:42 |
rfrasur |
we'd have to redo the workflow though - and this forces staff to get pretty up close and personal with the collection (which improves their customer service) |
21:42 |
jeff_ |
the "this book is out of order", or more? |
21:42 |
rfrasur |
well, what I'm doing right now. Before they ever get to the stacks, I'm cleaning the database. |
21:42 |
jeff_ |
yeah. i can't really walk the stacks without placing something on hold or checking it out. |
21:42 |
rfrasur |
It's more of a systemic maintenance |
21:44 |
rfrasur |
it also helps me get ready to weed (which I wanted to do BEFORE inventory, but oh well...maybe I'll be more on the ball next time...though I guess it doesn't matter...just more materials to take note of) |
21:45 |
* jeff_ |
nods |
21:45 |
jeff_ |
we weeded as part of RFID conversion |
21:46 |
rfrasur |
If we were an RFID library this would all be a little less intense, lol. |
21:46 |
jeff_ |
fed reports of barcodes matching certain criteria into the conversion laptops, those items were set aside for staff consideration/examination, some made the cut, others did not. |
21:47 |
jeff_ |
i'm not sure that RFID is as magic as some vendors try to make it out to be. it's helpful, and i'm very happy that we did it, but i haven't seen any automatic shelf-reading bots organizing our stacks yet. ;-) |
21:47 |
rfrasur |
what size is the collection now? (roughly) |
21:48 |
rfrasur |
yeah - I think it's a cool thing and has some nice features, but we're small enough that the cost still outweighs the benefit. |
21:48 |
jeff_ |
huh. our dashboard doesn't actually have a grand total. guess i never noticed that. |
21:49 |
jeff_ |
call it approx. 350k copies district-wide. |
21:49 |
rfrasur |
and how many branches? |
21:50 |
jeff_ |
six locations. |
21:51 |
rfrasur |
I wouldn't want to do our style of inventory w/ a collection of that size. |
21:51 |
jeff_ |
six awesome branches, one larger in size than the others. |
21:52 |
rfrasur |
:D |
21:52 |
jeff_ |
http://www.tadl.org/locations |
21:53 |
rfrasur |
wait a sec! I know your lib! |
21:53 |
* rfrasur |
wants to work there someday...or at least visit |
21:53 |
rfrasur |
you work at the COOL library |
21:53 |
* jeff_ |
laughs |
21:54 |
jeff_ |
come visit! lots of fun things happen around here in the summer. |
21:54 |
bshum |
Well, there are actual COOL libraries in Ohio. So maybe we'll go with "cool" library. (but, jeff's library is awesome) |
21:54 |
jeff_ |
cherry festival starts... tomorrow, i believe. |
21:55 |
rfrasur |
okay...don't tell OH (and I'll say this because I think interstate rivalry is healthy) but if you have to call yourself COOL...well, then... |
21:56 |
gmcharlt |
on the other hand, maybe this gives us an excuse to hold bookcart duels^Wdrills at the next EG conference? |
21:56 |
rfrasur |
and...back in the day, everyone in MI knew that Traverse City and the surrounding area was the best part of Michigan...except some places in the UP...but that's debatable. |
21:56 |
rfrasur |
gmcharlt++ |
21:57 |
rfrasur |
was/were (stupid usage) |
21:57 |
bshum |
gmcharlt: Should suggest that to the organizing social committee :D |
21:59 |
rfrasur |
our lib isn't ready to be cool yet. It just strives to be functional |
21:59 |
rfrasur |
and vaguely relevant |
22:01 |
rfrasur |
(if we had a jousting tournament w/ book carts, however, we could be awesome...and not worry about the functional!) |
22:06 |
rfrasur |
yeah...this is more than enough work for today. thanks y'all for being good sports. and, jeff_: I have plans to visit the MI libs in the nearish future (it helps to have family in proximal locations). |
22:06 |
jeff_ |
rfrasur: excellent! come visit and be a tourist! |
22:06 |
jeff_ |
@later tell rfrasur excellent! come visit and be a tourist! |
22:06 |
pinesol_green |
jeff_: The operation succeeded. |
23:35 |
|
Pibbits2 joined #evergreen |