| Time |
Nick |
Message |
| 00:50 |
|
dcook joined #evergreen |
| 04:40 |
|
gmcharlt_ joined #evergreen |
| 04:40 |
|
ldw_ joined #evergreen |
| 04:40 |
|
phasefx__ joined #evergreen |
| 04:40 |
|
jeffdavi1 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
tspindler joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
kmlussier joined #evergreen |
| 07:38 |
|
agoben joined #evergreen |
| 07:43 |
kmlussier |
Good morning #evergreen! |
| 07:43 |
kmlussier |
@coffee [someone] |
| 07:43 |
* pinesol_green |
brews and pours a cup of Guatemala El Injerto, and sends it sliding down the bar to dkyle |
| 07:43 |
kmlussier |
@tea [someone] |
| 07:43 |
* pinesol_green |
brews and pours a pot of Honey Black Tea, and sends it sliding down the bar to tsbere (http://ratetea.com/tea/health-and-tea/honey-black-tea/7529/) |
| 07:53 |
graced |
good morning kmlussier and #evergreen |
| 08:50 |
jeff |
good morning! |
| 08:50 |
kmlussier |
graced and jeff: good morning. :) |
| 08:52 |
|
bos20k joined #evergreen |
| 09:08 |
JBoyer |
So, seeing the comment about the upcoming MADS dev reminded me of something. Is there a reason we're not using a recent(ish) MODS transform? I had to wedge some changes in to get Publishers to appear in some interfaces after we automatically converted most of our records to RDA. |
| 09:09 |
JBoyer |
I didn't know if it was heavily customized or required a lot of massaging, etc. |
| 09:18 |
|
pgardella joined #evergreen |
| 09:18 |
kmlussier |
JBoyer: That question popped into my head as well. I've always guess it's because nobody has taken the time to do it. |
| 09:20 |
JBoyer |
I suppose it's just a matter of diff-ing the version we have against LOC's copy of that same version and seeing what changes there may be and why. If it were as simple as 'cp new old' that would be delightful. |
| 09:21 |
|
rlefaive joined #evergreen |
| 09:44 |
|
yboston joined #evergreen |
| 09:46 |
|
mmorgan joined #evergreen |
| 09:47 |
dbs |
JBoyer: oh my goodness, I just added a comment about upgrading to MODS 3.6 to that bug |
| 09:47 |
dbs |
I even pointed out the RDA-related improvements |
| 09:47 |
JBoyer |
Great minds, etc., etc. ;) |
| 09:48 |
dbs |
Then I open up IRC and ... great minds :) |
| 09:48 |
JBoyer |
Boom. |
| 09:49 |
dbs |
just note that for quite a while LoC would update the same XSL version but wasn't using publicly visible version control, so differences between our version of MODS 3.2 and theirs might be due to bug fixes in their copy that didn't get applied to ours |
| 09:50 |
JBoyer |
Your comment isn't showing up for me, but you don't happen to know off hand if the xslt's had to be heavily modified do you? I am sure that there will be the occasional code changes for new / changed element names, but that's all I'm currently aware of. |
| 09:51 |
JBoyer |
That makes sense. I've also made a few local additions here and there so I'd really be looking more for major structural changes than little things here and there. |
| 09:55 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/1662541/comments/2 |
| 09:55 |
pinesol_green |
Launchpad bug 1662541 in Evergreen "bib browse and facet index definition improvements" [Wishlist,New] |
| 09:56 |
dbs |
git log -- Open-ILS/xsl/MARC21slim2MODS32.xsl # will tell the tale |
| 09:56 |
dbs |
or perhaps not :/ |
| 09:57 |
JBoyer |
Ah, that's not the bug I thought you were referring to so I missed it. |
| 10:01 |
|
Dyrcona joined #evergreen |
| 10:01 |
berick |
csharp: I force-pushed a fix for the hold targeter |
| 10:27 |
|
bos20k joined #evergreen |
| 10:28 |
|
collum joined #evergreen |
| 11:24 |
|
jeffdavis joined #evergreen |
| 11:29 |
|
khuckins joined #evergreen |
| 11:32 |
|
Christineb joined #evergreen |
| 11:47 |
|
bmills joined #evergreen |
| 12:01 |
csharp |
berick: 10-4 |
| 12:09 |
|
mmorgan1 joined #evergreen |
| 12:09 |
csharp |
berick: looks like the DB function is mad because it's expecting an integer and is getting an array |
| 12:09 |
csharp |
open-ils.cstore: Error with query [SELECT * FROM actor.org_unit_ancestor_setting_batch_by_org( 'circ.holds.org_unit_target_weight', '{200,333,7,208,143,63,269,204,32,153,3,101,144,111,71, |
| 12:09 |
csharp |
26,206}' ) AS "actor.org_unit_ancestor_setting_batch_by_org" ;]: 3484946 3484946: ERROR: invalid input syntax for integer: "{200,333,7,208,143,63,269,204,32,153,3,101,144,111,71,26,206}"#012LINE 1: ...atch_by_org( 'circ.holds.org_unit_target_weight', '{200,333,...#012 |
| 12:10 |
berick |
csharp: did you replace the db func too? |
| 12:10 |
berick |
it'll need to be updated w/ the new func in YYYY.schema.batch_settings_by_org.sql |
| 12:10 |
csharp |
no - I didn't see that it had changed |
| 12:10 |
csharp |
ok |
| 12:11 |
|
brahmina joined #evergreen |
| 12:11 |
* berick |
should have thought to mention that |
| 12:11 |
csharp |
nah - it's ok |
| 12:11 |
csharp |
I should've checked |
| 12:18 |
|
sandbergja joined #evergreen |
| 12:23 |
csharp |
berick: everything looks happy so far |
| 12:23 |
|
jihpringle joined #evergreen |
| 12:27 |
csharp |
super fast lookups now |
| 12:28 |
berick |
csharp: excellent |
| 12:29 |
csharp |
berick++ |
| 12:29 |
csharp |
this was totally worth your time :-) |
| 12:30 |
berick |
csharp++ # testing machine |
| 12:30 |
csharp |
pines++ # the ultimate test case |
| 12:30 |
berick |
seriously |
| 12:30 |
berick |
the reference install of evergreen |
| 12:39 |
Dyrcona |
csharp++ berick++ |
| 12:42 |
|
teletype01 joined #evergreen |
| 12:43 |
kmlussier |
csharp++ berick++ indeed |
| 12:48 |
csharp |
data point - before the latest 2 commmits, it took ~15 seconds to process a hold for a bib with 132 potential copies over a similar number of libraries (for setting lookups) - post-patch, one with 220 potential copies over similar number of libraries took ~ 1 second |
| 12:49 |
csharp |
dayyum |
| 12:52 |
berick |
woohoo |
| 12:53 |
|
mmorgan joined #evergreen |
| 12:59 |
|
bmills joined #evergreen |
| 13:05 |
csharp |
and my example from bug 1416438 comes right back now too |
| 13:05 |
pinesol_green |
Launchpad bug 1416438 in Evergreen "slow hold placement on titles with many copies" [Undecided,Confirmed] https://launchpad.net/bugs/1416438 |
| 13:15 |
kmlussier |
csharp: That is going to me people I know very very happy. |
| 13:20 |
kmlussier |
s/me/make |
| 13:21 |
csharp |
yeah - this is great |
| 13:25 |
|
khuckins_ joined #evergreen |
| 13:26 |
|
krvmga joined #evergreen |
| 14:03 |
|
khuckins_ joined #evergreen |
| 14:04 |
|
khuckins__ joined #evergreen |
| 14:09 |
|
brahmina joined #evergreen |
| 14:42 |
|
ejk joined #evergreen |
| 14:43 |
|
brahmina joined #evergreen |
| 14:44 |
|
Christineb joined #evergreen |
| 14:48 |
|
bmills joined #evergreen |
| 15:01 |
Bmagic |
miker: remember the reporter.hold_request_record trigger function fix? I just found my old bug report from November LP 1642715 |
| 15:01 |
pinesol_green |
Launchpad bug 1642715 in Evergreen "EG 2.11 Merging records will time out with large amounts of holds" [Undecided,New] https://launchpad.net/bugs/1642715 |
| 15:02 |
Bmagic |
Was there an associated bug to go with your commit a few weeks ago? |
| 15:02 |
|
wsmoak joined #evergreen |
| 15:03 |
kmlussier |
Bmagic: bug 1657237 |
| 15:03 |
pinesol_green |
Launchpad bug 1657237 in Evergreen "Trigger function maintaining hold-target mapping not well constrained" [Critical,Fix released] https://launchpad.net/bugs/1657237 |
| 15:04 |
Bmagic |
Ah, well, I think we can link/close the bug report that I opened in November |
| 15:07 |
kmlussier |
Calling 1006 |
| 15:15 |
Dyrcona |
To make an OpenSRF tarball does one just do configure and then make dist? |
| 15:15 |
Dyrcona |
heh. I should read first, ask later. :) |
| 15:16 |
Dyrcona |
To answer my own question: It looks like it. |
| 15:17 |
pinesol_green |
[evergreen|Dan Pearl] LP#1308090 Relator fields and facets need normalization. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fd7f904> |
| 15:17 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1308090: pgTAP fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dcc74b3> |
| 15:17 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1308090: Updating release notes to reflect both parts of this new feature - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d107f15> |
| 15:17 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1308090: Stamping upgrade script for trim trailing punctuation normalizer - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2644ddd> |
| 15:28 |
Dyrcona |
Bleh. Not enough free memory to start a vm on my laptop....Where's that command to force Linux to clear the cache? |
| 15:30 |
JBoyer |
Dyrcona, rm -rf /sys/mem ? |
| 15:30 |
Dyrcona |
Heh. No. :) |
| 15:30 |
miker |
Bmagic: sorry, was on a call. what kmlussier said :) |
| 15:30 |
JBoyer |
:D |
| 15:30 |
Bmagic |
:) |
| 15:31 |
Dyrcona |
JBoyer: Though I think it involves cat and some value and some file under /proc/sys/mem or thereabouts. |
| 15:31 |
* Dyrcona |
is doing some git archeology in the mean time. |
| 15:32 |
miker |
Dyrcona: http://unix.stackexchange.com/questions/17936/setting-proc-sys-vm-drop-caches-to-clear-cache |
| 15:32 |
Dyrcona |
miker: That's probably where I read about it the first time that I tried it. :) |
| 15:33 |
JBoyer |
I was about to say that StackOverflow suggests free && sync && echo 3 > /proc/sys/vm/drop_caches && free, though I suspect you only actually need the echo > bit in the middle. |
| 15:34 |
miker |
I'd think a sync, telling the kernel to write dirty data, would be enough ... the page cache is "usable" memory, it shouldn't restrict something else starting |
| 15:37 |
Dyrcona |
miker: True. |
| 15:37 |
JBoyer |
I'd also think it would free it on demand if something actually tried to request it. |
| 15:37 |
Dyrcona |
Jboyer: I don't think I need 3. |
| 15:38 |
JBoyer |
Unless you vm manager is asking what's free and giving up. |
| 15:38 |
Dyrcona |
It should. Usually, I just quit Firefox and I get enough RAM back, but Firefox is not running at the moment and there's nothing else I want to quit. :) |
| 15:39 |
Dyrcona |
Well, last time I cleared cache it was on a drone server because it was acting "weird" compared to the others, so I thought I'd see what happened after I cleared it. |
| 15:39 |
Dyrcona |
It went right on being weird. |
| 15:45 |
Dyrcona |
Meh. I have like 3.7GB "available." The VM is configured for 4GB, but it really won't use more than 1-2GB once it is actually running. |
| 16:10 |
Dyrcona |
Oh well. Doesn't look like I'll get to test that branch today. |
| 16:16 |
|
brahmina joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:10 |
Bmagic |
csharp: kmlussier: bug 1508208 is pretty much the same as 1416438 or at least (most likely) has the same root issue |
| 17:10 |
pinesol_green |
Launchpad bug 1508208 in Evergreen "Checkin age based hold protected item may not fill fillable holds" [Undecided,New] https://launchpad.net/bugs/1508208 |
| 17:31 |
kmlussier |
Bmagic: From what csharp said earlier, it sounds like berick's holds targeting branch may have fixed the problem reported in bug 1416438. |
| 17:31 |
pinesol_green |
Launchpad bug 1416438 in Evergreen "slow hold placement on titles with many copies" [Undecided,Confirmed] https://launchpad.net/bugs/1416438 |
| 17:32 |
Bmagic |
sweet! |
| 17:50 |
csharp |
well, I can definitely say that the example bib I cited in that ticket taking 15+ seconds took < 1 second with the new targeter + latest patches |
| 17:51 |
berick |
and to be fair, that specific hold may not have taken 15 seconds with the current targeter. so apples/oranges |
| 17:51 |
berick |
unless csharp tested that too |
| 17:55 |
* csharp |
didn't |
| 17:56 |
csharp |
I can say though, that since day one on new hardware (faster processors) and the new hold targeter, we've gotten many positive comments from staff about improved hold placement speed in general |
| 17:57 |
csharp |
I'll do some investigation of old vs. new (though "old" was on older slower HW) |
| 17:57 |
csharp |
so more than one variable here |
| 18:00 |
Bmagic |
right on |
| 18:02 |
csharp |
Message processing duration: 18.852 <-- hold with 175 potential copies on old system |
| 18:04 |
berick |
csharp: you can also do this to compare on the same server (assuming it's OK to retarget the hold in question): |
| 18:04 |
berick |
srfsh# request open-ils.storage open-ils.storage.action.hold_request.copy_targeter, "", 1 |
| 18:04 |
berick |
srfsh# request open-ils.hold-targeter open-ils.hold-targeter.target {"hold":1} |
| 18:04 |
berick |
replace '1' with a hold id |
| 18:07 |
csharp |
open-ils.storage: Request Time in seconds: 5.138330 |
| 18:07 |
csharp |
open-ils.hold-targeter: Request Time in seconds: 0.466618 |
| 18:07 |
csharp |
that's one with 206 potentials |
| 18:08 |
berick |
awesome |
| 18:08 |
csharp |
yeah - it literally is |
| 21:13 |
|
ldw joined #evergreen |
| 21:13 |
|
jeff joined #evergreen |
| 21:13 |
|
rlefaive joined #evergreen |
