| Time |
Nick |
Message |
| 00:22 |
|
stevenyvr2 joined #evergreen |
| 00:23 |
|
stevenyvr2 left #evergreen |
| 01:04 |
|
remingtron_ joined #evergreen |
| 02:01 |
paxed |
wth... grargh. fieldmapper doesn't obey locale, once again? (patron registration is in English-only) |
| 03:36 |
|
Mark__T joined #evergreen |
| 04:14 |
|
serflog joined #evergreen |
| 04:14 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 04:17 |
|
shadowspar joined #evergreen |
| 04:51 |
|
ddddd joined #evergreen |
| 04:56 |
|
iti_czech_republ joined #evergreen |
| 04:56 |
|
edoceo joined #evergreen |
| 04:57 |
|
rjackson-isl joined #evergreen |
| 04:57 |
iti_czech_republ |
hello to everyone. i am testing the evergreen right now and i nedd some help.. |
| 05:15 |
|
sseng joined #evergreen |
| 06:59 |
|
timlaptop joined #evergreen |
| 07:12 |
|
mrpeters joined #evergreen |
| 07:53 |
|
jboyer-isl joined #evergreen |
| 08:22 |
|
akilsdonk_ joined #evergreen |
| 08:22 |
csharp |
is the content from the old RSCEL site up somewhere? |
| 08:23 |
csharp |
"Most of the content from our original website has been archived and handed over to the current Evergreen Web Team..." looking at rscel.evergreen-ils.org |
| 08:24 |
csharp |
oh - I see, at least some of it is still up, just not navigable |
| 08:36 |
bshum |
csharp: I think moodaepo had asked LBA about it, but I don't recall exactly where that's gone (if anywhere). |
| 08:38 |
|
rfrasur joined #evergreen |
| 08:42 |
csharp |
bshum: ok - I'm doing some recent historical research on the EG project's growth and was trying for all available resources |
| 08:42 |
csharp |
thanks |
| 08:44 |
paxed |
@marc 901 |
| 08:44 |
pinesol_green |
paxed: unknown tag 901 |
| 08:44 |
rfrasur |
csharp: are you gonna write a book? |
| 08:45 |
* rfrasur |
would buy a book re: Evergreen |
| 08:45 |
paxed |
hmm... now that conjoined items are supported via 901c, how about 773/774 linking? |
| 08:46 |
csharp |
rfrasur: heh - nope - just preparing for a presentation I'm giving in a couple of months at the Georgia COMO conference |
| 08:46 |
csharp |
though I would also buy an Evergreen book |
| 08:47 |
rfrasur |
well, if you or anyone else decides to write an Evergreen book, you/they have a customer. |
| 08:47 |
rfrasur |
and good luck on the presentation as well. |
| 08:47 |
csharp |
rfrasur: thanks! |
| 08:47 |
csharp |
you may see more from me here/on the lists as I gather data |
| 08:47 |
* rfrasur |
had a discussion with an Evergreen antagonist yesterday. We both survived. |
| 08:48 |
csharp |
heh |
| 08:48 |
rfrasur |
it was close |
| 08:48 |
* csharp |
likes the term "Evergreen antagonist" |
| 08:48 |
csharp |
I know a few ;-) |
| 08:49 |
rfrasur |
yeah, me too. And, though I make a little fun, it's good to talk to them anyway. Good to know what the opinions are OUTSIDE. Kinda like getting outside the U.S. to understand Americans |
| 08:50 |
|
Shae joined #evergreen |
| 08:55 |
jboyer-isl |
rfrasur: I'm always curious, was their problem "giving up control," or something different? |
| 09:03 |
rfrasur |
jboyer-isl:Well, it was a couple things. They were apparently involved with a library looking at EG in the EARLY stages of EG-IN, when, of course, there were no acquisitions and when there was also a different atmosphere at ISL. It was before Wendy was deputy dir. |
| 09:04 |
rfrasur |
jboyer-isl: and there are still people bringing up the 2.0 update....which...come on. |
| 09:06 |
rfrasur |
so, we talked about how the product itself is being developed...as well as how the consortium has matured...and pros/cons depending on a library's situation, etc. etc., ad nauseum |
| 09:07 |
jboyer-isl |
At least it sounds like it went over well. I've heard of discussions that start heated and only get hotter, heh. |
| 09:08 |
csharp |
rfrasur++ # boots-on-the-ground advocacy |
| 09:09 |
rfrasur |
jboyer-isl: I try very hard to let people know upfront that I'm an evangelist BUT that their perspectives are just as important as mine. Listening to them can only make EG better |
| 09:10 |
rfrasur |
and...if I'm nice...who knows? Maybe someday our entire county will be EG and we won't EVER have to issue another reciprocal borrower card...EVER. |
| 09:11 |
rfrasur |
(and then we'll go to straight up county library districts....and there won't be any unserved areas...and...) |
| 09:11 |
rfrasur |
(Evergreen takes over the world...muahahah) |
| 09:14 |
|
ericar joined #evergreen |
| 09:16 |
rfrasur |
Of course...because of the conversation yesterday, now I feel duty bound to actually use the acquisitions module even though it's probably not necessary for a lib our size. |
| 09:17 |
* bshum |
remembers using acquisitions when it was still in "preview" |
| 09:17 |
bshum |
Those were the days. |
| 09:17 |
rfrasur |
I don't think it's actually even in 2.2 though, is it? |
| 09:18 |
bshum |
I think we've been using acquisitions in some form since our 2.0 days. |
| 09:19 |
rfrasur |
hmm, I'll look into it. |
| 09:19 |
rfrasur |
later |
| 09:19 |
* rfrasur |
looks into it now. |
| 09:20 |
rfrasur |
yeah, we won't have it until 2.4. |
| 09:20 |
rfrasur |
in December |
| 09:21 |
rfrasur |
(w00t) |
| 09:21 |
bshum |
Must be a local decision. |
| 09:21 |
rfrasur |
Yeah, I think so. |
| 09:21 |
bshum |
Checked my notes, and sure enough I was writing EDI documentation with folks back on 2.0 days. |
| 09:22 |
bshum |
But that's okay. Sometimes it's safer to wait. |
| 09:22 |
bshum |
:) |
| 09:22 |
rfrasur |
I suspect much of the mechanism is in our implementation, but it's more a policy and planning thing. Hard to steer 100+ little libraries into something that they have no concept of. |
| 09:22 |
* dbs |
ponders boots-on-the-fingers diplomacy |
| 09:22 |
rfrasur |
well, they're not ALL little...but enough of them are to matter |
| 09:23 |
bshum |
Yeah, we definitely only rolled acq out to the libs already using it in the past system before we handed it to new libs. |
| 09:23 |
rfrasur |
dbs: That's why some are good at building the thing and others are good at selling/advocating for it. |
| 09:23 |
bshum |
So less than a third of the libraries in the consortium use acq presently. |
| 09:23 |
bshum |
Someday, though. |
| 09:24 |
rfrasur |
bshum: yeah...and generally, here...when it gets rolled out, it's universal (with the exception of pilot libraries, of course) |
| 09:27 |
|
yboston joined #evergreen |
| 09:27 |
bshum |
it's nice to be on the same page. |
| 09:29 |
* dbs |
wonders if "TPAC sucks on mobile devices" would be considered a bug (vs "TPAC new feature: support mobile devices!") and thus eligible for post-2.5-m2 commits |
| 09:29 |
bshum |
dbs: post-beta? |
| 09:32 |
rfrasur |
dbs: I particularly like your wording rather than the vs. |
| 09:32 |
dbs |
although it works pretty well on a 1080p 7" tablet as-is :) |
| 09:32 |
dbs |
bshum: Yeah, I guess. Not paying as much attention these days. |
| 09:33 |
* paxed |
wont bother even trying on his ancient cellphone |
| 09:33 |
dbs |
paxed: hell, the JSPAC used to work on ancient cellphones (Windows Mobile 6.1, original iPhone) |
| 09:33 |
rfrasur |
It works on my phone, but I'll be glad when the responsive one that jboyer-isl is/has working/worked on is all hooked up. |
| 09:35 |
paxed |
dbs: we seem to have a differing notion of "ancient" :P |
| 09:35 |
dbs |
"work" vs. "works fast and looks natural" are two different things, of course |
| 09:35 |
rfrasur |
paxed++ #flip phone joy |
| 09:35 |
dbs |
paxed: well, yeah, if you're expecting WML... |
| 09:36 |
* dbs |
considers > 5 years old "ancient" in the world of cell phones |
| 09:36 |
rfrasur |
(see? I even mention "reciprocal borrower" and the universe decides it's time to vomit more recip. bor. drama) |
| 09:39 |
|
kmlussier joined #evergreen |
| 09:41 |
|
kbeswick joined #evergreen |
| 09:43 |
bshum |
dbs: I guess it all matters in how you define the scope of the bug and whether whatever we do can be backported? (though TPAC differences always makes that harder as we go along) |
| 09:43 |
* bshum |
wanted to find time at the Hackaway next month to poke at mobile things if it didn't come up sooner. |
| 09:45 |
|
Guest12774 joined #evergreen |
| 09:49 |
|
mllewellyn joined #evergreen |
| 09:52 |
rfrasur |
speaking of the hackaway, yboston, has the DIG not going to be involved with that at all...or is it...or...? |
| 09:53 |
berick |
dang, fell down on the job when I cut 2.3.9... |
| 09:53 |
dbs |
oh, hey, found a bug in browsing. Browse for a term, then select a facet, then hit "Browse" again and select a different term from the list that pops up. |
| 09:54 |
dbs |
In all likelihood, you'll get zero results as the facet you chose still gets applied to the new term, even though the term says there are supposed to be 2 hits or whatever. |
| 09:54 |
dbs |
berick: well, if nobody noticed until now... |
| 09:55 |
dbs |
Still time to quietly roll a new 2.3.9 and then roll out 2.3.10 |
| 09:55 |
rfrasur |
@hate facets |
| 09:55 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur hates facets. |
| 09:55 |
berick |
heh, yeah, i can feel 2.3 slipping away... |
| 09:55 |
yboston |
rfrasur: we have only had one DIG hack-a-way and it ended up being separate front he developers. One reason was to allow the chance for developers to attend both. Int he end bshum attend both. This year we are running with the same separate approach. because no one had pushed so far to make them be a single event. |
| 09:55 |
pinesol_green |
[evergreen|Bill Erickson] Copying 2.3.8-2.3.9 SQL upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=53c35f7> |
| 09:56 |
paxed |
dbs: another thing with facets: after searching, sort the results differently and the available facets are different. |
| 09:56 |
dbs |
Arguably the Doc Sprint was another DIG hack-a-way |
| 09:56 |
yboston |
rfrasur: I had sent out an email to the DIG more than a month ago about getting feedback on how we should proceed with planning the 2013 DIG hack-a-way. I will reply to my own email soon |
| 09:56 |
dbs |
paxed: heh, that's interesting |
| 09:56 |
* kmlussier |
makes a note to reply to that e-mail. |
| 09:57 |
paxed |
dbs: i guess that has to do with only loading the X first results, and estimating the rest? |
| 09:57 |
yboston |
dbs: you are right, I was not able to attend so I forgot. turns out we actually had two DIG events last year |
| 09:57 |
paxed |
dbs: time for a bug report? |
| 09:58 |
berick |
dbs: to clarify, the 2.3.9 tarball is fine, I just neglected to copy some stuff around to the other branches |
| 09:58 |
dbs |
berick: do we have a release checklist somewhere? |
| 09:59 |
rfrasur |
yboston: ty. That's what I thought, but wanted to clarify. |
| 10:00 |
dbs |
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:evergreen:release_checklist - but we also had a wiki document that outlined release tarball steps |
| 10:01 |
dbs |
I think that got rolled into the release-cutting script, but obviously not everything can or should be automated |
| 10:01 |
berick |
dbs: we have the wiki checklist and I have a bar napkin of stuff that needs to be copied to the wiki.. http://evergreen-ils.org/dokuwiki/doku.php?id=dev:evergreen:release_checklist |
| 10:01 |
berick |
indeed, the make_release script needs some patches as well |
| 10:02 |
berick |
e.g. unpacking and removing xulrunner exe's by hand |
| 10:02 |
rfrasur |
paxed: by the by - There was an interview with Amanda Ripley the other day who wrote "The Smartest Kids in the World" highlighting South Korea, Finland and Poland. Though to myself, "Paxed might be one of the smartest kids in the world." |
| 10:03 |
* rfrasur |
is getting ready to read the book, btw. w00t libraries. |
| 10:03 |
dbs |
thre was an evergreen version of http://evergreen-ils.org/dokuwiki/doku.php?id=dev:release_process:opensrf:2.0 - right |
| 10:04 |
dbs |
we need to turn that into a "So... you're the new (OpenSRF|Evergreen) release maintainer? Congratulations! Here's what you need to know / do..." |
| 10:04 |
paxed |
rfrasur: ehheh. (i don't think can call myself a kid anymore, but ...) |
| 10:04 |
rfrasur |
yeah...well, there's that. |
| 10:04 |
paxed |
rfrasur: also, i have no delusions about my intelligence. |
| 10:04 |
rfrasur |
ahh...but now the rest of the world will :D |
| 10:04 |
* rfrasur |
believes the hype |
| 10:04 |
paxed |
hey, that's just good marketing :P |
| 10:05 |
dbs |
I think there was some merit to http://evergreen-ils.org/dokuwiki/doku.php?id=dev:releases:from_git:miker&rev=1317137730 vs. the current version, even if the script automated some of those steps |
| 10:05 |
rfrasur |
hey...I live in a capitalist society. We live and die by marketing :D |
| 10:05 |
dbs |
alternately, put the human git cherry-picking / branching / tagging steps into the release_checklist at the least |
| 10:07 |
berick |
looks like make_release does most of what's in dev:releases:from_git:miker |
| 10:07 |
berick |
it may have been built from that.. |
| 10:07 |
dbs |
berick: sure, it was |
| 10:09 |
dbs |
but the release script is also close to a black box (long bash scripts, whee) |
| 10:11 |
eeevil |
yes, and it tends to error late, not early |
| 10:12 |
eeevil |
which means sitting through another 30min i18n build when something goes wrong |
| 10:14 |
|
RoganH joined #evergreen |
| 10:14 |
paxed |
is there any way to give more weight to newer items in search results? |
| 10:15 |
RoganH |
there have been several proposals for relevancy, including taking time into consideration, thrown around |
| 10:15 |
RoganH |
I don't know if any have made it into implementation |
| 10:15 |
kmlussier |
My understanding was that newness was a tiebreaker for relevancy. |
| 10:15 |
* berick |
kicks the tires on 2.3.10, finds it functional |
| 10:16 |
eeevil |
kmlussier: pubdate is, yes |
| 10:16 |
kmlussier |
But, yes, MassLNC is sponsoring a project for using an activity metric for relevancy. I believe newness will be part of that work. Wont' be ready for 2.5, though. |
| 10:18 |
* paxed |
wonders if he could just quickly hardcode something to make his users a bit happier. |
| 10:23 |
csharp |
@quote random |
| 10:23 |
pinesol_green |
csharp: Quote #8: "<Digital_Pioneer> When life gives you bad hardware, make bricks." (added by bshum at 12:31 PM, May 13, 2011) |
| 10:25 |
|
mcooper joined #evergreen |
| 10:25 |
pinesol_green |
[evergreen|Pasi Kallinen] Move HTML tags out of translatable strings in toolkit templates. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=82d65ec> |
| 10:31 |
RoganH |
@quote random |
| 10:31 |
pinesol_green |
RoganH: Quote #65: "< paxed> #evergreen: wrong questions answered correctly." (added by csharp at 02:27 PM, August 13, 2013) |
| 10:32 |
eeevil |
kmlussier / paxed: you know, that algo I shared on the LP ticket would work well for this if item create date were the "event" to boost and age out over time. kmlussier, do you recall the bug number? |
| 10:34 |
kmlussier |
eeevil: I don't think it was on LP. It was in an e-mail message. |
| 10:34 |
eeevil |
ah ... you're right |
| 10:34 |
kmlussier |
http://markmail.org/message/7i352ribf5zl7wz6 |
| 10:35 |
kmlussier |
RoganH: I don't think my response to your swag survey will be particularly helpful. I'll buy anything with an Evergreen logo slapped on it. |
| 10:36 |
RoganH |
kmlussier: that is ok. that is still a valid point of data. |
| 10:36 |
graced |
goats with the Evergreen logo it is, then |
| 10:36 |
kmlussier |
OK, almost anything. |
| 10:36 |
* berick |
slaps a logo on his old honda civic |
| 10:36 |
RoganH |
I myself haven't responded yet but I'm hoping for t-shirts at the least because I'll give them to staff. |
| 10:36 |
eeevil |
kmlussier: thanks! |
| 10:37 |
kmlussier |
I wonder if there is an interesting way we could use the #egils hashtag in swag. |
| 10:38 |
berick |
swagtag |
| 10:45 |
jboyer-isl |
Sigh. I've been chasing sed errors for days only to find that I forgot to quote substitutions with spaces in them. Thanks, shells! |
| 10:46 |
|
gsams joined #evergreen |
| 10:46 |
paxed |
dbs: shall i rebase bug 1196837 branch to master right now? |
| 10:46 |
pinesol_green |
Launchpad bug 1196837 in Evergreen "Javascript escape() is deprecated, replace it with encodeURIComponent()" (affected: 1, heat: 6) [Medium,Triaged] https://launchpad.net/bugs/1196837 |
| 10:47 |
dbs |
paxed: sure |
| 10:47 |
dbs |
paxed: it looked like the conflicting files could just be dropped out, but I wondered if there were other data: uri uses in play |
| 10:48 |
dbs |
paxed: you're using the branch in your test systems? |
| 10:49 |
* rfrasur |
agrees with kmlussier - just about anything with a logo. |
| 10:51 |
csharp |
@blame the rain |
| 10:51 |
pinesol_green |
csharp: the rain musta been an Apple employee. |
| 10:51 |
csharp |
@blame it on the rain |
| 10:51 |
pinesol_green |
csharp: it on the rain is NOT CONNECTED TO THE NETWORK!!! |
| 10:51 |
paxed |
dbs: no, we're not. the conflict is from my previous fix, which i simply forgot was in the "pipeline" so to speak. |
| 10:52 |
rfrasur |
oy vey - when people use tables/spreadsheets/database terminology interchangably. If they were the same thing, they'd be named the same thing. |
| 10:53 |
csharp |
too bad "database" means like 5 completely different things in libraries already :-/ |
| 10:53 |
rfrasur |
csharp: yes. |
| 11:01 |
|
dboyle joined #evergreen |
| 11:06 |
paxed |
dbs: done. |
| 11:19 |
|
zerick joined #evergreen |
| 11:29 |
|
leofseige joined #evergreen |
| 11:33 |
kmlussier |
I'm reviewing the to-date responses to the conference survey and see very few responses from self-identified developers. If you haven't had a chance yet (developer or not), please remember to fill one out! https://www.surveymonkey.com/s/7LXW35V |
| 11:52 |
jcamins |
eeevil: FWIW, I managed to write a grammar for super-simple (aliased) queries: https://gist.github.com/jcamins/6283892 Index configuration is done when loading the grammar via dependency injection. |
| 11:52 |
jcamins |
I see why you thought that figuring out bison might be a bridge too far. |
| 11:53 |
eeevil |
:) |
| 11:53 |
eeevil |
jcamins++ |
| 11:54 |
|
smyers_ joined #evergreen |
| 11:57 |
|
jdouma joined #evergreen |
| 11:58 |
|
acoomes joined #evergreen |
| 11:58 |
jcamins |
The high point of the experience so far was definitely spending way more time than I should have getting scope working for the last-specified-index-is-new-default rule... only to discover that the result of properly-scoped default indexes is mass confusion because people have very shallow mental stacks. |
| 11:59 |
jcamins |
I'm not sure why I never noticed that with QP. I guess I never did queries where it came up. |
| 12:02 |
eeevil |
yeah, the common case doesn't include much nesting. but for generated queries (or cannonicalized ones) it's good and important, IMO. makes order unimportant |
| 12:02 |
eeevil |
but ... in practice it's not hardly used. and now I'm running away for meetings |
| 12:02 |
eeevil |
jcamins++ # taking the fight to the big, hairy animal |
| 12:29 |
rfrasur |
RoganH++ #panel discussion re: ILS migration in Oct. |
| 12:30 |
phasefx |
dbs++ # qa feedback |
| 12:30 |
|
smyers__ joined #evergreen |
| 12:37 |
kmlussier |
I just had a relevancy question come up. I know the coverage density settings has an option for word proximity. But is word order ever taken into account with relevancy? |
| 12:44 |
bshum |
I feel like that's changed. |
| 12:44 |
bshum |
There used to be something for word order in opensrf.xml |
| 12:44 |
bshum |
But I think when cover density came into play things changed a little on that. |
| 12:44 |
kmlussier |
The coverage density settings are in opensrf.xml |
| 12:46 |
kmlussier |
There was a word order setting in search.relevance_adjustment, but we don't use that because of the performance issues. |
| 12:46 |
kmlussier |
Just don't know if word order is no longer a factor or is just covered by some other setting. |
| 12:47 |
dbs |
kmlussier: the cover density algo just cares how close the words are to each other, without caring about their order, if I recall the paper correctly. |
| 12:48 |
kmlussier |
dbs: Thanks! |
| 12:48 |
dbs |
So "open source" and "source open" should deliver the same result rankings |
| 12:49 |
dbs |
In theory it should be easy to create a custom version of ts_rank_cd that would care... |
| 12:49 |
kmlussier |
Yup, you're right. I'm seeing the same results for both. |
| 12:51 |
dbs |
the tsvectors know which positions the lexemes occupy, so if you searched for "lexeme1 lexeme2" it should be able to ever so slightly reward " lexeme1:pos lexeme2:pos+1 " over "lexeme2:pos lexeme1:pos+1" |
| 12:52 |
* dbs |
will maybe dig at some C code |
| 12:55 |
* dbs |
spies a comment from oleg: "wi - should be sorted desc, don't sort for now, just choose maximum weight. This should be corrected |
| 12:55 |
dbs |
" - heh. |
| 12:56 |
bshum |
Heh |
| 12:56 |
dbs |
That is, of course, one of only a handful of comments in 887 lines of C |
| 12:57 |
|
stevenyvr2 joined #evergreen |
| 13:12 |
mllewellyn |
Is anyone here who is familiar with serials? I have an item notes question. |
| 13:14 |
kmlussier |
mllewellyn: I would just throw the question out there. If there's nobody here now who can answer it, they may see it later and give you an answer. |
| 13:14 |
mllewellyn |
THanks, kmlussier. |
| 13:16 |
mllewellyn |
I'm playing in the Serials Control View in master_20130716, and tried out adding an item note for a received issue. I checked the box for "public", but I don't see the note anywhere in the OPAC view. Am I supposed to, or is the public box a red herring? I do like the button for editing a note, something the items in Holdings Maintenance don't yet have. |
| 13:19 |
rfrasur |
dbwells might know something about this |
| 13:20 |
mllewellyn |
I also like the way some of the Alternate Serial Control interface has been incorporated in the Serial Control view. |
| 13:22 |
mllewellyn |
And it looks like a baby step to serial claiming..right clicking while highlighting an issue gets a menu that includes "claim". I clicked on it and it said the item was now claimed, and the item went gray in the list. |
| 13:30 |
senator |
mllewellyn: the opac doesn't notes on issues yet, but could. it would be a good subject for a launchpad wishlist item. re claiming, you could run reports using evergreen's reports module to find issues that have been marked claimed, and go from there, but that's all there is for serials claiming so far |
| 13:32 |
mllewellyn |
Thanks, senator. |
| 13:34 |
senator |
specific development proposals to extend how that works would definitely get some evergreen users with thoughts on the subject to speak up |
| 13:36 |
mllewellyn |
Glad to see a way to manually mark an issuance as claimed. Would love to see a development of system-generated claims based on expected dates or skipped issuances. |
| 13:38 |
dbs |
phasefx: re: oils_header.pl - I had thought the agreed direction back when atz was in action was to build on a proper Perl module (that is, Cronscript.pm) rather than oils_header.pl |
| 13:39 |
mllewellyn |
Also, the use of the word "item" when issuance is meant is confusing. It would be nice to see that reworded to "issuance" as in "Edit Item Attributes," "Reset Items to Expected," "Claim Item", etc. |
| 13:40 |
mllewellyn |
Guess I'll go spend some time on Launchpad for these. |
| 13:41 |
senator |
mllewellyn: issuances and items are distinct but related things in serials, but of course there could be places where the terms are used inconsistently or incorrectly |
| 13:41 |
senator |
mllewellyn++ |
| 13:42 |
kmlussier |
mllewellyn: There was a long explanation in some old IRC log that I still refer to sometimes when people ask me what the different terms me. |
| 13:42 |
mllewellyn |
Well, we have the copies/item terminology that was confusing enough for Holdings Maintenance. |
| 13:44 |
mllewellyn |
Ediit Item Attributes from the Admin/Local Administration menu is a whole different critter from Edit Item Attributes in Serials Contol View. |
| 13:44 |
kmlussier |
mllewellyn: http://evergreen-ils.org/irc_logs/evergreen/2012-05/%23evergreen.23-Wed-2012.log#line125 |
| 13:45 |
mllewellyn |
Item Attribute Editor, in Admin. Still close enough to be confusing. |
| 13:45 |
mllewellyn |
Thanks, kmlussier |
| 13:48 |
rfrasur |
umm, it's been a very long time since I used the MARC create interface. What's the shortcut to delete a subfield? |
| 13:49 |
rfrasur |
n/m. I figured it out. |
| 13:49 |
kmlussier |
I can never remember, but there's a handy link in that interface with all of the shortcuts. |
| 13:49 |
mllewellyn |
Shift and delete |
| 13:49 |
* bshum |
likes using the basic editor for stuff like that. |
| 13:50 |
bshum |
But I'm also probably crazy. |
| 13:50 |
mllewellyn |
rfrasur, sorry I was slow, I was checking it. I used the flat text editor myself. |
| 13:50 |
rfrasur |
mllewellyn++ bshum++ kmlussier++ #my brain is lacking |
| 13:50 |
bshum |
kmlussier++ #joining the bug wrangler team and becoming one of the many. |
| 13:50 |
bshum |
*officially joining |
| 13:51 |
rfrasur |
I have a tendency to leave behind artifacts in the flat text editor when it's just subfields |
| 13:51 |
rfrasur |
<--very reluctant, part-time cataloger |
| 13:54 |
* rfrasur |
will have happy, 80s metalhead patrons soon |
| 13:57 |
dbwells |
Is the serials discussion over? Guess I missed it, rats. |
| 13:59 |
mllewellyn |
dbwells, you're welcome to resurrect it. :) |
| 14:00 |
kmlussier |
Looks like 2 p.m. EDT Tuesday of next week for the August developers meeting. Thanks all! Lots of people filled out the poll with no additional prodding from me. :) |
| 14:00 |
* kmlussier |
has trained you all very well. |
| 14:00 |
|
mmorgan joined #evergreen |
| 14:12 |
rfrasur |
mllewellyn: am I correct in assuming that you do cataloging? |
| 14:14 |
eeevil |
dbs: re custom ts_rank, that's been on my wish list (exactly for adding phrase, first-word and word-order rel bumps) for a long time ... I'm a'feared of 1) yet another new thing to maintain 2) the cost of switching EG USPs to one or more PG extensions (to ameliorate (1)) 3) the complexity of configurable per-bump weights like search.relevance_adjustment supports ... however, I'll happily help work on that as a secondary if you're looking to dig |
| 14:14 |
eeevil |
into it! |
| 14:16 |
mllewellyn |
rfrasur: yes, out of many things we do. |
| 14:17 |
mllewellyn |
rfrasur: mostly bib editing, our original cataloging is done on OCLC, not in Evergreen. |
| 14:20 |
rfrasur |
mllewellyn: is it okay to have more than one 505 in a MARC? |
| 14:20 |
* rfrasur |
didn't find anything about that. |
| 14:21 |
rfrasur |
I know you can repeat some fields...but not sure about that one. |
| 14:21 |
phasefx |
dbs: re: Cronscript, sounds sane to me. I'll look at it |
| 14:22 |
kmlussier |
@marc 505 |
| 14:22 |
pinesol_green |
kmlussier: The titles of separate works or parts of an item or the table of contents. The field may also contain statements of responsibility and volume numbers or other sequential designations. (Repeatable) [a,g,r,t,u,6,8] |
| 14:22 |
rfrasur |
ahh, repeatable. ty |
| 14:25 |
mllewellyn |
rfrasur,this is my bible. http://www.oclc.org/bibformats/en.html |
| 14:26 |
rfrasur |
mllewellyn: that's where I'm at...but must have overlooked the "repeatable" |
| 14:27 |
mllewellyn |
rfrasur: that's what the big R in parentheses after the note name means. |
| 14:27 |
rfrasur |
err...yes. ty |
| 14:27 |
* rfrasur |
is mildly ashamed |
| 14:27 |
mllewellyn |
ack, don't be! |
| 14:28 |
* kmlussier |
has grown quite attached to getting her MARC info from pinesol_green. |
| 14:29 |
rfrasur |
kmlussier: I always forget about that. hopefully, next time, I'll remember. |
| 14:29 |
jeff_ |
http://www.loc.gov/marc/bibliographic/bd505.html would be the source of pinesol_green's information on 505 |
| 14:30 |
jeffdavis |
FYI if you don't want to consult the bot in-channel, you can send it a private message: /msg pinesol_green marc 505 |
| 14:34 |
rfrasur |
There ya go Indiana Iron Maiden fans. Live from Birmingham UK - Maiden England '88 |
| 14:45 |
|
kbeswick_ joined #evergreen |
| 14:49 |
pinesol_green |
[evergreen|Dan Scott] Make C unit tests more robust - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e5a3ee7> |
| 15:04 |
rfrasur |
okay, I'm sick of this. No more cataloging. Ever. Until tomorrow. |
| 15:04 |
* rfrasur |
is going home. |
| 15:06 |
csharp |
marc-- |
| 15:06 |
csharp |
well, actually... |
| 15:06 |
csharp |
aacr2-- |
| 15:07 |
csharp |
and for good measure... |
| 15:07 |
csharp |
"standards"-- |
| 15:09 |
tsbere |
Don't we have a "standards" factoid? |
| 15:09 |
csharp |
~standards |
| 15:09 |
pinesol_green |
http://www.xkcd.com/927/ |
| 15:09 |
csharp |
tsbere++ |
| 15:15 |
RoganH |
help my memory, where is the last activity logs in the db? |
| 15:15 |
dbwells |
dbs: eeevil: I started poking at a custom C ranking function earlier this summer. I got as far as getting some of the logic on paper (well, a whiteboard), and also got a stub function to compile, load into postgres, and produce some values, but alas, got pulled away for other things since then. Based on my limited experience, the potential is certainly there, and I don't think the maintenance overhead would be too bad. |
| 15:15 |
csharp |
RoganH: actor.usr_activity? |
| 15:16 |
RoganH |
staring me right in the face, thanks! |
| 15:21 |
RoganH |
thanks Chris, I'm reading over the search warrant while loading up psql and my brain froze. |
| 15:26 |
jeffdavis |
search warrant? |
| 15:29 |
csharp |
wha? |
| 15:29 |
csharp |
patriot_act-- |
| 15:36 |
RoganH |
sorry, had to step away. no not patriot act, just local normal search warrant. |
| 15:44 |
dbs |
dbwells / eeevil: cool, and agreed that maintaining it shouldn't be that terrible (in fact, some generic enhancements like "tsquery term order matters!" might be acceptable in postgresql proper) |
| 15:45 |
* _bott_ |
enjoys the occasional search warrant's entertainment value |
| 15:48 |
* jeffdavis |
looks at action.purge_circulations for the first time in awhile |
| 16:02 |
rangi |
hmm |
| 16:02 |
rangi |
is RoganH around? |
| 16:05 |
rangi |
i see you are on a panel about switching ILS .. also on the panel is someone who has switched to fauxha, you can tell its not the real Koha cos the spell it as if it was an acronym, ill personally post you a chocolate fish https://en.wikipedia.org/wiki/Chocolate_fish if you manage to say something that makes it clear they are running a fork :-) |
| 16:07 |
phasefx |
rangi++ |
| 16:09 |
* jcamins |
will contribute a pound of homemade cookies to the cause. |
| 16:10 |
jcamins |
Well... if RoganH is in the US. Home-baked goods are problematic across international borders. |
| 16:12 |
rangi |
:) |
| 16:17 |
jeffdavis |
Seems like there's a cstore call to retrieve copy location groups from the db every time the org tree is loaded in TPAC, should that be cached maybe? |
| 16:18 |
jeffdavis |
s/org tree/org selector/ |
| 16:18 |
|
dMiller_ joined #evergreen |
| 16:22 |
senator |
jeffdavis: quite possibly. do you have a line of log output showing this, or better yet can you point to the guilty line of code? |
| 16:22 |
RoganH |
I'm back. |
| 16:23 |
RoganH |
Sorry rangi, it's been one of those crazy, drag me out of my office a lot days. |
| 16:23 |
berick |
jeffdavis: they're not cached because they are context-dependent |
| 16:23 |
berick |
they could be cached, of course, once per context, but they're not today |
| 16:23 |
RoganH |
rangi: I will be glad to help make the distinction |
| 16:24 |
berick |
but there are a lot of combinations of context, depending on physical location, home location, search location |
| 16:24 |
berick |
oh, and locale |
| 16:24 |
* senator |
backs away from the copy location group caching question slowly ... |
| 16:24 |
jeffdavis |
heh |
| 16:24 |
berick |
heh |
| 16:25 |
* berick |
throws cache-goo at senator |
| 16:25 |
* senator |
melts :-) |
| 16:27 |
jeffdavis |
there isn't really a clear log message, I just happened to notice regular calls to open-ils.cstore.direct.asset.copy_location_group.search.atomic on an unused server |
| 16:27 |
jeffdavis |
the timestamps of which correspond to regular nagios polling of the TPAC homepage on that server |
| 16:29 |
jeffdavis |
there is a line `self->load_copy_location_groups;` in the load_common function in EGCatLoader.pm |
| 16:30 |
jeffdavis |
which I assume is the culprit |
| 16:30 |
jeffdavis |
that said, I take berick's point :) |
| 16:34 |
|
kmlussier joined #evergreen |
| 16:42 |
|
natschil joined #evergreen |
| 16:59 |
berick |
jeffdavis: you piqued my interest -- working/user/berick/tpac-cache-copy-loc-groups |
| 17:00 |
berick |
i was seriously confused for a minute why the tpac page load routines were running twice |
| 17:00 |
berick |
until i realized that was the CSS template |
| 17:01 |
* berick |
wonders if we could optimize CSS templates to load from /eg/<not opac>/css/style.css to avoid the full EGCatLoader.pm dance |
| 17:03 |
jeffdavis |
\o/ |
| 17:03 |
berick |
looks do-able, since it's just loading constants and not relying on (as far as I can tell) the tpac context |
| 17:24 |
|
mmorgan left #evergreen |
| 18:04 |
eeevil |
caching is great, until you change something and it's not showing up... or showing inconsistently |
| 18:07 |
eeevil |
IMO, if we use more granular named caches (configured in opensrf.xml) so we can invalidate just what we want then it becomes a simpler issue |
| 18:12 |
eeevil |
'course that means giving up in-process caching too, and doing it all in memcache. but if it works for Facebook... |
| 18:12 |
gmcharlt |
eeevil: easier to invalidate one cache than play whack-a-mole with Apache or OpenSRF backends at inconveninet times |
| 18:13 |
gmcharlt |
I'm looking at YOU, postal code lookup! |
| 18:14 |
eeevil |
exactly. but we shouldn't use the same cache for with and static-ish stuff... |
| 18:15 |
gmcharlt |
eeevil: yeah, I meant "easier to invalidate one *named* cache"... |
| 18:17 |
eeevil |
maybe I'll make only-cache-in-memcache my next crusade |
| 18:20 |
jcamins |
gmcharlt: are we talking about caching in #koha because of the discussion here or vice versa? |
| 18:22 |
gmcharlt |
jcamins: spillover -- just one of the glitches of operating the two channels as just views of #kohagreen on FreeOFTC |
| 18:22 |
jcamins |
Hehe. |
| 18:27 |
jcamins |
eeevil: you're probably leaving imminently, but before you go... where in QP do we configure the facet marker? |
| 18:28 |
jcamins |
I'm staring and staring, and I just don't see it. |
| 18:32 |
eeevil |
jcamins: are you referring to part of the grammar? |
| 18:32 |
eeevil |
I mean, from the wiki page that describes the grammar |
| 18:33 |
eeevil |
jcamins: or do you mean the general facet syntax of "blah|foo[value 1][value 2]" |
| 18:33 |
jcamins |
The facet syntax. Specifically, the []. |
| 18:34 |
jcamins |
I'm staring at the code, and for the life of me, I can't find it. |
| 18:34 |
eeevil |
in O::A::St::QueryParser, at line 922 in evergreen master |
| 18:34 |
jcamins |
Oh, there it is. |
| 18:34 |
jcamins |
Thank you. |
| 18:35 |
jcamins |
I was looking further down. |
| 18:35 |
eeevil |
np |
| 18:41 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Invoke skull-and-crossbones popup in batch receive for server-side errors - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=21bc541> |
| 18:41 |
eeevil |
jcamins: the comment directly above that line doesn't help much ;) "# Build the filter and modifier uber-regexps" |
| 18:41 |
jcamins |
eeevil: not really, no. |
| 18:42 |
eeevil |
it's not false, just either 1) 3 lines too high or 2) one list element short |
| 18:43 |
jcamins |
Probably (2). It does make sense to group them. |
| 19:25 |
|
mtate joined #evergreen |
| 20:36 |
|
tfaile_ joined #evergreen |
| 22:29 |
|
kbeswick joined #evergreen |
