| Time |
Nick |
Message |
| 01:28 |
* bshum |
needs to work on cutting back on the number of words he uses in emails. |
| 01:28 |
bshum |
And sleeping. |
| 01:31 |
jeff |
work on sleeping. don't work on cutting back on sleeping. |
| 02:39 |
|
Callender_ joined #evergreen |
| 07:35 |
|
rjackson_isl joined #evergreen |
| 07:38 |
|
ericar joined #evergreen |
| 07:41 |
|
jboyer-isl joined #evergreen |
| 07:52 |
|
mrpeters joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 08:42 |
Dyrcona |
@weather 01845 |
| 08:42 |
pinesol_green |
Dyrcona: North Andover, MA :: Overcast :: 54F/12C | Friday: Chance of a morning shower. Mostly cloudy early, then sunshine for the afternoon. High 56F. Winds WNW at 10 to 20 mph. Friday Night: Mainly clear skies. Low 32F. Winds NW at 5 to 10 mph. | Updated: 48m ago |
| 08:43 |
Dyrcona |
Gotta love Spring in New England. |
| 08:46 |
jeff |
yeah. cold morning here. |
| 08:46 |
jeff |
@weather ktvc |
| 08:46 |
pinesol_green |
jeff: Cherry Capital, MI :: Overcast :: 36F/2C | Wind Chill: 28F/-2C | Friday: Scattered snow flurries and snow showers this morning. Becoming partly cloudy later. Temps nearly steady in the mid to upper 30s. Winds W at 10 to 20 mph. Chance of snow 30%. Friday Night: Cloudy skies with late-night snow showers. Low 29F. Winds light and variable. Chance of snow 40%. | Updated: (1 more message) |
| 08:47 |
jeff |
that forecast of snow is obviously wrong, though. we're not done raking leaves yet. |
| 08:47 |
* mmorgan |
loves it when spring makes a surprise appearance in the fall :) |
| 08:49 |
csharp |
@weather 30033 |
| 08:49 |
pinesol_green |
csharp: Decatur, GA :: Clear :: 46F/8C | Friday: Abundant sunshine. High 66F. Winds light and variable. Friday Night: Mostly clear. Low near 40F. Winds E at 5 to 10 mph. | Updated: 56m ago |
| 09:14 |
|
collum joined #evergreen |
| 09:29 |
|
remingtron joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 10:12 |
Dyrcona |
Whee! Another circ matrix ticket. |
| 10:13 |
Dyrcona |
This time they want to set the load period for cake pans. |
| 10:13 |
berick |
awesome |
| 10:13 |
Dyrcona |
A different library from the member who already circulates cake pans. |
| 10:13 |
Dyrcona |
berick++ # For pointing out EDI Reader and friends. |
| 10:14 |
berick |
probably a busy time for cooking implements |
| 10:14 |
Dyrcona |
Yes, indeed. |
| 10:14 |
berick |
Dyrcona: glad it's helpful |
| 10:14 |
Dyrcona |
Well, it shows me that the JEDI doesn't match the EDI, so now I have to figure that out. |
| 10:15 |
Dyrcona |
I was going to ask if its possible to delete the stuff from the database and process the EDI again. |
| 10:15 |
Dyrcona |
I imagine yes, but it won't be simple. |
| 10:15 |
Dyrcona |
Anyway, back to cake pans... |
| 10:16 |
* berick |
confirms it's possible |
| 10:19 |
berick |
well, hmm |
| 10:19 |
berick |
no, that's only possible for ORDERS, that go through A/T |
| 10:19 |
Dyrcona |
cake pans: item_type: r, circ_as_type: o, so looks for circ rules for kits. |
| 10:19 |
berick |
inbound messages all happen in one action, read the remote file and process in one go |
| 10:19 |
berick |
so, not so easy to reproduce |
| 10:20 |
Dyrcona |
Well, I was hoping there was some back end call or stuffing the message into webrick |
| 10:20 |
berick |
plus if it created data (e.g. an invoice), it would not recreate it |
| 10:20 |
berick |
webrick is totally skipped on inbound messages |
| 10:20 |
berick |
it's perl all the way down |
| 10:21 |
berick |
edi_fetchter -> edi.pm -> insert into db |
| 10:21 |
Dyrcona |
Sounds like I'll be learning more than I probably wanted to know. :) |
| 10:21 |
Dyrcona |
Thanks, berick, I now know where to look. |
| 10:24 |
dbwells |
hopkinsju: I added you to the libraries.json. I did change your directory name to conform to the others (State, Country (Name)), but please let me know if that's not alright. |
| 10:25 |
hopkinsju |
That's groovy. I didn't notice that was a convention. |
| 10:25 |
hopkinsju |
Thanks dbwells! |
| 10:25 |
dbwells |
No problem. Anyone else have an entry to add while I am in here? I'll keep it open a minute or two. |
| 10:26 |
|
krvmga joined #evergreen |
| 10:27 |
krvmga |
it's a real puzzle to me how the catalog's search return order works |
| 10:27 |
krvmga |
i thought it was by active/create date |
| 10:27 |
krvmga |
seems no |
| 10:27 |
jeff |
krvmga: when ordering by what? |
| 10:27 |
krvmga |
i thought it might be tcn |
| 10:27 |
krvmga |
also seems no |
| 10:28 |
krvmga |
jeff: for instance, a title search for sinatra the life |
| 10:29 |
krvmga |
http://bark.cwmars.org/eg/opac/results?query=sinatra+the+life&qtype=title&fi%3Asearch_format=&locg=1&sort= |
| 10:29 |
dbwells |
default sort is "relevance" |
| 10:29 |
krvmga |
the order of the first four returns in the catalog |
| 10:29 |
dbwells |
Ah, you mean when they are all the same-ish. |
| 10:29 |
krvmga |
dbwells: so record density |
| 10:29 |
krvmga |
i didn't check to see if they all had the same density |
| 10:30 |
jeff |
there is a tie breaker, i forget if it's date1 or something else. |
| 10:30 |
jeff |
(and of course, that's not a guaranteed tie breaker -- i don't recall if there's a final) |
| 10:30 |
dbwells |
I think jeff is right, pubdate is at least one tie breaker. |
| 10:31 |
krvmga |
pubdate... |
| 10:32 |
krvmga |
what can we understand about the order? |
| 10:32 |
krvmga |
first = relevance |
| 10:32 |
krvmga |
second = ? |
| 10:32 |
krvmga |
tiebreakers = pubdate and/or ? |
| 10:33 |
krvmga |
over here, this discussion originated in complaints over large print copies of books appearing ahead of regular print |
| 10:34 |
krvmga |
this was causing inattentive patrons to place holds on LP materials and not noticing the regular print a few returns lower in the return list |
| 10:34 |
krvmga |
so i was trying to investigate so i could come up with some "definitive" answer for them |
| 10:35 |
jeff |
ah. we fixed that by displaying (LARGE PRINT) in the catalog. :-) |
| 10:36 |
jeff |
i.e., http://catalog.tadl.org/eg/opac/results?query=the+help&qtype=keyword&locg=22 |
| 10:37 |
krvmga |
jeff: lol, that'll get their attention |
| 10:37 |
jeff |
answering your original question may not help, but Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm has an ORDER BY on fields 4 ("rank"), 5 (FIRST(pubdate_t.value) AS tie_break, and 3. |
| 10:38 |
jeff |
er, paste hit enter for me. |
| 10:38 |
jeff |
3 is "rel" |
| 10:38 |
krvmga |
how did you get (LARGE PRINT) to display. i don't see it in the record. |
| 10:39 |
krvmga |
jeff: thanks. i'll look at that code. |
| 10:40 |
krvmga |
jeff: did you put some tt code in that if x then print (LARGE PRINT)? |
| 10:40 |
jeff |
https://github.com/tadl/Evergreen_templates_tadlskin/commit/28cedb7d1a2f475d69ebeb09771a80e96d87759f |
| 10:40 |
jeff |
and somewhat related are several of the other commits in Dec 2014 here: https://github.com/tadl/Evergreen_templates_tadlskin/commits/rel_2_7 |
| 10:41 |
jeff |
I think that's before we rebased our templates to 2.7. |
| 10:41 |
krvmga |
jeff: we have a lot of admiration for your catalog at cwmars. |
| 10:43 |
krvmga |
jeff++ |
| 10:43 |
dbwells |
krvmga: beyond (or within) what jeff posted, the only things I am aware of which affect the "relevance" sort order are preferred language settings and search.relevance_adjustment bumps (if enabled). The built in bump types wouldn't help in this case, I don't think. |
| 10:43 |
krvmga |
dbwells: interesting |
| 10:44 |
dbs |
maybe the large print catalogue records have less text, so the term frequency/inverse document frequency kicks the butt of the more complete non-large print records? |
| 10:44 |
krvmga |
dbs: i'm going to check that next |
| 10:44 |
* dbs |
looks at the actual results |
| 10:46 |
jeff |
dbs: that's what we've typically found -- the non-large-print records have more things like abstracts, etc. |
| 10:46 |
dbs |
"Sinatra" appears way more times in the higher ranked records than in the large print record |
| 10:47 |
dbs |
(at least for the example krvmga provided) |
| 10:47 |
krvmga |
dbs++ |
| 10:47 |
dbs |
and "life" appears twice, instead of just once in the large print record |
| 10:47 |
dbs |
and "the" appears a bunch of times in the higher ranked records because of the summary |
| 10:49 |
* dbs |
didn't notice that krvmga's search was on title, bah |
| 10:49 |
dbs |
switching to keyword, I think TF/IDF kicks in bigtime |
| 10:54 |
krvmga |
dbs: important note! |
| 10:59 |
Dyrcona |
Nothing's ever "simple," is it? |
| 11:00 |
krvmga |
Dyrcona: you can say that again |
| 11:00 |
* krvmga |
is off to a meeting. back later. |
| 11:00 |
Dyrcona |
Nothing's ever "simple," is it? |
| 11:02 |
miker |
krvmga: there's a penalty on "long" documents -- that is, in this case, shorter combined title index rows rank higher. if you want to lessen that penalty (allow longer titles to gain more from cover density) then you could consider swapping #CD_documentLength with #CD_logDocumentLength in the <default_CD_modifiers> part of opensrf.xml. or, even, remove #CD_documentLength completely from that element. but caveat emptor ... push one thing down, anothe |
| 11:02 |
miker |
pops up... |
| 11:03 |
miker |
krvmga: (and, after your meeting) you can also empty out that whole element in opensrf.xml and experiment with different CD normalizers directly in the search box |
| 11:04 |
miker |
(one of the caveats to keep in mind: searches like, say, "title:it" may (probably will) suffer) |
| 11:20 |
Dyrcona |
@marc leader |
| 11:20 |
pinesol_green |
Dyrcona: unknown tag leader |
| 11:21 |
Dyrcona |
@marc ldr |
| 11:21 |
pinesol_green |
Dyrcona: unknown tag ldr |
| 11:21 |
Dyrcona |
Figures. |
| 11:30 |
jeff |
the marc leader should always be set to '48151nam a2262342 a 4500' |
| 11:30 |
|
bmills joined #evergreen |
| 11:34 |
Dyrcona |
jeff: Not if that is incorrect for your record, and really, I just wanted to refresh my memory on what o and k stand for. |
| 11:35 |
Dyrcona |
o is Kit and k is Two-dimensional nonprojectable graphic, naturally. |
| 11:36 |
* Dyrcona |
has some crazy circ matchpoints. |
| 11:36 |
bshum |
Crazy, or CRAZY??! |
| 11:36 |
bshum |
:) |
| 11:36 |
tsbere |
bshum: All of the above? |
| 11:36 |
Dyrcona |
fractal. |
| 11:36 |
jeff |
Dyrcona: i'm just trying to follow DHARMAACR2 here. ;-) |
| 11:36 |
Dyrcona |
:) |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:23 |
|
bmills joined #evergreen |
| 12:43 |
krvmga |
miker: thanks very much. |
| 12:43 |
krvmga |
miker++ |
| 12:48 |
|
bmills joined #evergreen |
| 12:51 |
gsams |
jeff++ #implemented the LARGE PRINT in my catalog because that's great. |
| 13:17 |
krvmga |
jeff: i just put it out to my opac discussion group and everyone's loving (LARGE PRINT) atm. will probably implement it next week. |
| 13:18 |
dbs |
It's like a GMD! |
| 13:20 |
Dyrcona |
dbs: Don't say that in an airport, at least not in the USA. |
| 13:23 |
jeff |
local hack escapes confinement: [videorecording] at eleven. |
| 13:28 |
dbs |
Dyrcona+++ |
| 13:28 |
dbs |
Dyrcona++ even |
| 13:28 |
dbs |
jeff++ |
| 13:30 |
jeff |
If others are going to adopt something based off of that, I wonder what can be done to make it 1) easier and 2) less of a hack. I'll have to look and see if I did the right thing with regard to schema.org when we did it in our 2.7 rebase. |
| 13:30 |
dbs |
I still think wrapping the pertinent record in style="font-size: 3em" would be more appropriate :) |
| 13:30 |
Dyrcona |
hah |
| 13:30 |
Dyrcona |
dbs++ |
| 13:31 |
jeff |
hrm. not sure how to do this "better": <h1 id="rdetail_title" property="name">The Help (LARGE PRINT)</h1> |
| 13:33 |
dbs |
jeff: you would have to do something like: <h1 id="rdetail_title"><span property="name">The Help</span> (<span property="bookFormat">LARGE PRINT</span>)</h1> |
| 13:33 |
dbs |
For some definition of "better" |
| 13:35 |
dbs |
jeff: or <h1 id="rdetail_title"><span property="name">The Help</span> (LARGE PRINT)</h1> with <meta property="bookFormat" content="largePrint"> appearing somewhere else in the description |
| 13:35 |
dbs |
argh, not bookFormat in that case, accessibilityFeature |
| 13:35 |
dbs |
<meta property="accessibilityFeature" content="largePrint"> |
| 13:39 |
dbs |
It's not clear whether that attribute has any real impact on search engines, though. Maybe yandex, as chaals was one of the hard workers on the accessibility schema. |
| 13:54 |
jeff |
dbs++ thanks! |
| 13:59 |
|
bmills joined #evergreen |
| 14:04 |
jeff |
oh hey. our mobile apps are using elasticsearch now and nothing exploded. |
| 14:04 |
berick |
jeff: i'm listening... |
| 14:05 |
jeff |
we tend to put experiments into production. |
| 14:05 |
kmlussier |
jeff++ |
| 14:06 |
jeff |
i have an indexer that inserts things into an Elasticsearch cluster. |
| 14:06 |
jeff |
There is a rails app that queries that: https://github.com/tadl/elastic_evergreen |
| 14:07 |
jeff |
There was an existing rails app that backs our mobile app, mostly did a lot of screen scraping. We shifted that over to querying the "elastic-evergreen" app for searches, instead of scraping: https://github.com/tadl/ilscatcher2 |
| 14:08 |
jeff |
So, without needing to update the mobile apps (and that was good, because we did have to roll back once for a Ruby version issue), searching on mobile apps is fast and more... elastic-y. |
| 14:09 |
jeff |
I need to slap a license on the indexer and push that to github (slide 12 rule). currently it's only in our internal gitlab instance. |
| 14:10 |
jeff |
We're using Elasticsearch 1.7 (looking to upgrade to 2.0 -- "breaking changes" list is long but mostly doesn't impact us) |
| 14:10 |
berick |
ah, was looking for the indexer |
| 14:10 |
berick |
jeff++ indeed |
| 14:11 |
jeff |
I still consider all of this an experiment, and the approach we used was influenced by that. This isn't something that can be treated as a QueryParser backend or anything, for example... |
| 14:12 |
kmlussier |
I hate missing search discussions in the #evergreen channel. |
| 14:12 |
* berick |
chuckles at ruby's "rescue" keyword |
| 14:12 |
berick |
jeff: indeed. just like seeing how others are using it |
| 14:12 |
* jeff |
nods |
| 14:13 |
kmlussier |
krvmga: A little more info on the CD modifiers miker mentioned earlier. Back before the C/W MARS migration, we tried removing documentLength from the opensrf.xml file. But shorter records continued to appear high in results. |
| 14:13 |
kmlussier |
There's an email thread on it at http://markmail.org/message/ykzdejpb735t33t2 |
| 14:13 |
krvmga |
kmlussier: very interesting. thanks! |
| 14:13 |
krvmga |
kmlussier++ |
| 14:14 |
kmlussier |
miker then suggested that we try removing uniqueWords in addition to documentLength. And we did. |
| 14:14 |
kmlussier |
krvmga: That's what you went live with. |
| 14:14 |
* krvmga |
adds opensrf.xml file to watch list |
| 14:15 |
kmlussier |
It didn't work out very well. Coverage density didn't come into play at all. So we restored them. |
| 14:15 |
kmlussier |
krvmga: I think the lesson is, don't touch those settings unless you do a lot of testing ahead of time. I personally have been scared away from touching them ever again. |
| 14:15 |
krvmga |
lol |
| 14:16 |
kmlussier |
krvmga: If you think back to the phrase search bug we discovered this week, search relevance in your early days were very similar to those results. |
| 14:16 |
miker |
kmlussier: removing all is effectively the phrase bug I just fixed, BTW. |
| 14:16 |
miker |
heh |
| 14:16 |
kmlussier |
miker: yup! |
| 14:16 |
krvmga |
heh |
| 14:16 |
kmlussier |
miker: Not sure why removing documentLength on its own didn't do anything for us, because it is a question that has come up time and time again at all of our sites. |
| 14:18 |
miker |
kmlussier: part of it is that "document" really means "each individual field indexed, on its own" in evergreen |
| 14:19 |
kmlussier |
Yeah, but IIRC, we were testing it on keyword searches at the time. And it's back before we had added additional indexes before the blob. |
| 14:20 |
miker |
which, for titles especially, is a pretty narrow range of lengths |
| 14:21 |
miker |
tuits, but it wouldn't hurt to analyze in detail |
| 14:21 |
kmlussier |
We've generally found that the preference for shorter documents also leads to older records coming up high, because apparently we didn't catalog as much detail decades ago. |
| 14:22 |
krvmga |
yes, we have seen that is so. |
| 14:22 |
kmlussier |
Yeah, it might be worth taking another look at again since I don't have the pressure of two upcoming migrations as I did the last time we looked at it. |
| 14:23 |
krvmga |
i'm up for it. what i'm trying to do is document and test and document... |
| 14:23 |
* krvmga |
has to run to another meeting. back in a while. |
| 14:24 |
kmlussier |
Yes. One thing I want to do is put some of the search configuration for C/W MARS and NOBLE on the Evergreen wiki as examples of what they have done for adding indexes and improving relevancy. Maybe putting failed experiments there would be worthwhile too. |
| 14:36 |
gmcharlt |
dbs: looking at bug 1516867, and a quick question: any objection if sortable were moved to under Open-ILS/web/js/ ? |
| 14:36 |
pinesol_green |
Launchpad bug 1516867 in Evergreen "HTML reports should be dynamically sortable" [Wishlist,Confirmed] https://launchpad.net/bugs/1516867 - Assigned to Galen Charlton (gmc) |
| 14:37 |
* berick |
bites the bullet and updates to 15.10 on the laptop |
| 14:39 |
dbs |
gmcharlt: no particular objections; I had avoided it largely because everything under web/js/ appeared to be dojo, but there's always a first :) |
| 14:40 |
dbs |
gmcharlt: would you like me to refactor and push a revised branch? |
| 14:41 |
gmcharlt |
dbs: that would be great; meanwhile I'll finish testing its functionality |
| 15:23 |
* dbs |
suspects a Google Form might help the "CC gmcharlt" barrage (then either working with a google sheet backend to generate the JSON, and/or store the JSON in git for pull request delight) |
| 15:24 |
gmcharlt |
yeah, we'll certainly want something of the sort by the time it goes from beta to production |
| 15:27 |
dbs |
Oh right, it was the disturbing nature of having a CSS file located under a /js/ directory that gave me pause :) |
| 15:27 |
gmcharlt |
cats and dogs, living together... |
| 15:29 |
gmcharlt |
but not unprecented; lots of CSS files accompanying the Dojo stuff under /js/ |
| 15:30 |
dbs |
gmcharlt: I've pushed the branch with a second commit; you can squash it if you like |
| 15:31 |
gmcharlt |
thanks |
| 15:31 |
dbs |
thanks for testing! |
| 15:31 |
gmcharlt |
speaking of which, my substantive feedback from said testing |
| 15:31 |
gmcharlt |
1. looks nice and necessary |
| 15:32 |
gmcharlt |
2. the time it takes to render the table and sort it can really bog down after a certain point. with some emperical testing I've done in the XUL client and Chrome, up to 10,000 rows or so is fine |
| 15:33 |
gmcharlt |
but 100,000 can be a browser-killer |
| 15:33 |
dbs |
I think 100,000 rows is a killer without any javascript, isn't it? |
| 15:33 |
gmcharlt |
since the average # of rows in report output I've measured for a large consortium today is 4,300, on average things are fine as is |
| 15:34 |
gmcharlt |
but I'm thinking that perhaps picking a magic row count number, after which the JS isn't loaded, might be good |
| 15:34 |
* dbs |
avoids creating or looking at any massive reports in HTML |
| 15:34 |
dbs |
sounds like it would be a nice add |
| 15:34 |
dbs |
steel toes |
| 15:35 |
gmcharlt |
yeah |
| 15:39 |
gmcharlt |
dbs: I'll make a signoff branch that squashes your patches + adds such a limit |
| 15:43 |
miker |
kmlussier: re failed experiments, yes please, along with the context of EG version and PG version, that will help us avoid going down forgotten blind alleys (I do that approximately monthly...) |
| 15:47 |
|
jlitrell joined #evergreen |
| 15:49 |
gmcharlt |
miker: but sometimes you find such interesting stuff in blind alleys! ;) |
| 15:49 |
miker |
"interesting" he says... ;) |
| 15:50 |
miker |
but, when the {EG|PG} context changes, yes you certainly do, sometimes! |
| 15:52 |
kmlussier |
miker: Thanks, I'll do that! I'm planning to explore this particular blind alley again, so I'll add those versions. Can't say I recall what the PG version was when we tried it earlier and I only know the eg version because I noted it in that long-ago email thread. |
| 15:52 |
kmlussier |
2.2alpha. Those were the days. |
| 15:59 |
Bmagic |
Hey yall! Exciting news - Our bib deduplication software just finished on the production database. There was a 16.9% dedupliation, removing 169k bibs. Resulted in filling 1129 holds. |
| 16:01 |
jeff |
Bmagic: sounds exciting! code shared anywhere yet? |
| 16:09 |
Bmagic |
jeff: sure https://github.com/mcoia/mobius_evergreen/tree/master/seek_and_destroy |
| 16:10 |
Bmagic |
jeff: it's sort of a "manual" code edit for each of the tasks right now |
| 16:11 |
* jeff |
nods |
| 16:11 |
jeff |
Bmagic++ |
| 16:12 |
Bmagic |
The cataloging comittee and I spent the last 12 months moving through all of the formats in the catalog and automatically/manually editing the marc to make the format icons correct |
| 16:12 |
Bmagic |
and finally, dedupe |
| 16:12 |
kmlussier |
Bmagic++ |
| 16:16 |
Bmagic |
I think that asset.merge_record_assets should melt the 856's natively. |
| 16:20 |
jeff |
berick: indexer is here: https://github.com/tadl/marc-indexing-for-es |
| 16:21 |
berick |
jeff++ |
| 16:21 |
jeff |
many rough edges and undocumented TODOs |
| 16:21 |
berick |
understood |
| 16:23 |
jeff |
off the top of my head: holdings fetch is very inefficient in what's currently committed. this is very apparent in the add_due_date branch. |
| 16:23 |
jeff |
pending commit greatly improves that by fetching all holdings for a "page" worth of bibs in one query. |
| 16:25 |
jeff |
also, the holdings field in particular needs to (i'm pretty sure) be mapped as a nested object, because the implicit flattening makes it impossible to query for records with an available copy that is ALSO at a given library. |
| 16:26 |
berick |
makes sense |
| 16:28 |
berick |
i always imagined the data separated as bib stuff and holdings stuff. worked well in my (limited) parent/child experiments. nested should be faster for searches, though. |
| 16:30 |
berick |
jeff: if you haven't already, this is a handy index navigator / search tool: https://github.com/mobz/elasticsearch-head |
| 16:30 |
Dyrcona |
Well, this can't be good: Can't locate object method "retrieve_all_actor_org_unit_type" via package "OpenILS::Utils::CStoreEditor" at /usr/local/share/perl/5.18.2/OpenILS/Application/AppUtils.pm line 1392. |
| 16:30 |
Dyrcona |
And, no, I've not hacked AppUtils.pm. |
| 16:30 |
Dyrcona |
Nor CStoreEditor. |
| 16:31 |
jeff |
Dyrcona: broken IDL? |
| 16:31 |
Dyrcona |
I don't think so, but maybe. |
| 16:32 |
berick |
Dyrcona: i usually see stuff like that when there are startup problems. like a syntax error in a perl dependency |
| 16:33 |
berick |
jeff: in that plugin, there's a browser w/ a handy index auto-complete search |
| 16:34 |
Dyrcona |
Well, this will be fun. |
| 16:34 |
jeff |
here's the WIP on the holdings optimizations: https://github.com/tadl/marc-indexing-for-es/commit/ac5eb1526b0c1ac3fe7bfd4e49b0ded0435edcba |
| 16:34 |
jeff |
i'll likely rebase that before final merge/commit. |
| 16:36 |
Dyrcona |
Well, the IDL is valid XML. |
| 16:36 |
Dyrcona |
All the services are running. |
| 16:39 |
Dyrcona |
Lots of warnings about subroutines being redefined, but no syntax errors in AppUtils or CStoreEditor. |
| 16:45 |
Dyrcona |
Hmm... AppUtils.pm has undergone some changes in the past few weeks, including some from a test branch of my own, so guess I did modify AppUtils. :) |
| 16:47 |
Dyrcona |
So, I added a new subroutine that looks good and self-contained. |
| 16:48 |
Dyrcona |
I would almost think if this failed that the staff client would be unusuable. |
| 16:54 |
|
vlewis joined #evergreen |
| 16:57 |
Dyrcona |
I just don't see anything.... |
| 16:57 |
vlewis |
kmlussier: If you have time, could you take a look at the comment from jschrader on https://bugs.launchpad.net/evergreen/+bug/1502292 to see if I answered the question adequately? |
| 16:58 |
pinesol_green |
Launchpad bug 1502292 in Evergreen "web client: Need ability to add volumes from the bib record" [Undecided,New] |
| 16:58 |
|
bmills joined #evergreen |
| 17:02 |
jeff |
berick: alas, elasticsearch-head seems at least partially broken on 1.7 |
| 17:02 |
jeff |
berick: good excuse for me to continue the experiment with 2.0 |
| 17:02 |
kmlussier |
vlewis: Yeah, I think so, but I can follow up with her just to make sure. I think knowing it is in the record summary pane answers the question. |
| 17:02 |
kmlussier |
vlewis++ |
| 17:02 |
vlewis |
kmlussier: Thanks |
| 17:05 |
Dyrcona |
Ooh. I bet I know what it is, now. |
| 17:07 |
Dyrcona |
Yep... I had to init CStoreEditor. I'm not using it directly in my script, just via AppUtils. |
| 17:09 |
Dyrcona |
Time to go home. No one should stay late at the office on their birthday. |
| 17:09 |
jeff |
berick: https://github.com/mobz/elasticsearch-head/pull/218 should fix it. |
| 17:12 |
kmlussier |
Birthday? And Dyrcona left before I had a chance to send him bday cake. |
| 17:12 |
kmlussier |
@dessert search cake |
| 17:12 |
pinesol_green |
kmlussier: 8 found: #14: "Coconut Cream Cake", #20: "Red Velvet Cake", #23: "Pineapple Upside Down Cake", #24: "Carrot Cake", #34: "pineapple coconut cheesecake", #38: "Lemon Cupcakes", #39: "Key Lime Cheesecake", and #5: "of mllewellyn's Cupcakes" |
| 17:13 |
kmlussier |
@dessert add birthday cake with lots of candles |
| 17:13 |
pinesol_green |
kmlussier: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 17:13 |
kmlussier |
Oh yeah. Forgot about that. |
| 17:14 |
kmlussier |
@dessert add birthday cake with lots of candles |
| 17:14 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #41 added. |
| 17:14 |
berick |
jeff: huh, i'm using 1.7.2. didn't even notice. good to know |
| 17:14 |
kmlussier |
@dessert 41 Dyrcona |
| 17:14 |
* pinesol_green |
grabs some birthday cake with lots of candles for Dyrcona |
| 17:14 |
|
mmorgan left #evergreen |
| 17:15 |
gmcharlt |
Dyrcona++ # keep on incrementing... :) |
| 17:47 |
berick |
twice today i've made nontrivial C code changes and they worked on the first run. I should play the lottery. |
| 20:33 |
|
bmills joined #evergreen |
| 21:02 |
jeff |
berick: 1.7.2 here also. since there are no branches or releases, you may have just installed the plugin before the breaking changes were made. |
| 21:18 |
|
phasefx__ joined #evergreen |
| 21:18 |
|
dbs_ joined #evergreen |
| 21:18 |
|
jeffdavi1 joined #evergreen |
| 21:18 |
|
csharp_ joined #evergreen |
| 21:18 |
|
edoceo_ joined #evergreen |
| 21:18 |
|
berick_ joined #evergreen |
