| Time |
Nick |
Message |
| 05:42 |
|
sarabee joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 08:04 |
|
ericar joined #evergreen |
| 08:16 |
|
mrpeters joined #evergreen |
| 08:25 |
|
jboyer-isl joined #evergreen |
| 08:26 |
|
mdriscoll joined #evergreen |
| 08:31 |
|
DPearl joined #evergreen |
| 08:33 |
* jeff |
idly wonders if BISAC has a category for Self Help - Fiction |
| 08:34 |
jeff |
(having just come across a title of a self-help book that included "a true story" in the title, i wondered if the genre of fictional self-help books was a thing or not. |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:43 |
jeff |
morning, #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:46 |
|
Shae joined #evergreen |
| 08:47 |
kmlussier |
jeff: good morning! |
| 08:48 |
mmorgan |
Good Morning! |
| 08:49 |
* csharp |
sips decaf from his new NOBLE Evergreen mug ;-) |
| 08:50 |
* jeff |
straps the steaycam rig to his coffee mug and makes the journey from his desk to the coffee pot |
| 08:52 |
mmorgan |
Heh. |
| 08:56 |
|
tsbere joined #evergreen |
| 08:57 |
* Dyrcona |
signs out to install kernel updates on his laptop. |
| 09:00 |
|
mmorgan1 joined #evergreen |
| 09:01 |
|
mmorgan2 joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
mmorgan joined #evergreen |
| 09:12 |
|
RoganH joined #evergreen |
| 09:13 |
csharp |
oh - cool - Google docs will look up the bug for you if you highlight "Bug #XXXXXX" and click the "link" icon |
| 09:13 |
* csharp |
is writing his after-hacktion report |
| 09:13 |
gmcharlt |
in which database? |
| 09:14 |
gmcharlt |
or is it just doing a Google search? |
| 09:14 |
csharp |
gmcharlt: I think it's just googling... yeah |
| 09:14 |
gmcharlt |
*phew* |
| 09:14 |
csharp |
heh |
| 09:14 |
gmcharlt |
for a moment I had fears that Google Telepathy had exited alpha |
| 09:14 |
csharp |
gmcharlt++ |
| 09:15 |
csharp |
@quote add <gmcharlt> for a moment I had fears that Google Telepathy had exited alpha |
| 09:15 |
pinesol_green |
csharp: The operation succeeded. Quote #128 added. |
| 09:23 |
|
maryj joined #evergreen |
| 09:54 |
* jeff |
adds some more complicated mappings to elasticsearch and watches indexing speed drop by one record per second (oh noes!) |
| 09:54 |
* jeff |
tests a theory to confirm where the extra time is being spent |
| 09:55 |
jeff |
okay, bulk of the time is still being spent in fetching records and extracting fields data. |
| 09:55 |
jeff |
(as i'd expect) |
| 09:55 |
jeff |
meaning, i probably won't bother with bulk insert API yet. |
| 09:57 |
|
yboston joined #evergreen |
| 10:03 |
berick |
jeff: i played w/ bulk insert and it increased speed dramatically. |
| 10:04 |
* berick |
was doing a bib/copy parent/child experiment |
| 10:25 |
Dyrcona |
Decisions.... Decisions.... To install CPAN modules in my $HOME or as root. |
| 10:30 |
jeff |
when not doing the full perlbrew dance, i've been making more use of local::lib + cpanm |
| 10:33 |
Dyrcona |
jeff: Yep, going with local::lib. |
| 10:35 |
Dyrcona |
I may drop the perl5 prefix that it uses, though. I already have my $HOME setup with bin, lib, and man, and a lib/perl5 for my own "packages." |
| 10:36 |
jeff |
berick: i found the denormalized approach to work well. i didn't venture further into experimenting with relationships. |
| 10:36 |
jeff |
berick: the bulk of time in my current experiment is spent fetching holdings in a very inefficient manner. |
| 10:38 |
berick |
jeff: cool. yeah, i kind of just wanted to see how it worked. |
| 10:38 |
jeff |
https://gist.github.com/jeff/d85ff92cc3e73aa4715a |
| 10:39 |
jeff |
berick: yeah. i think relationships may still be useful when it comes to adding metarecords or similar. not sure yet. |
| 10:39 |
jeff |
And I don't know what Solr supports in terms of parent/child relationships yet. |
| 10:42 |
berick |
i know solr has a basic join operation, which can be used to similar effect. up to a point, anyway |
| 10:55 |
|
Shae joined #evergreen |
| 11:06 |
|
mmorgan joined #evergreen |
| 11:09 |
|
krvmga joined #evergreen |
| 11:10 |
krvmga |
i am, so far, having a very happy Monday. |
| 11:10 |
krvmga |
I only mention it because it's so different from my usual Mondays. |
| 11:11 |
krvmga |
Please do not take this as a challenge. :) |
| 11:12 |
|
Christineb joined #evergreen |
| 11:12 |
kmlussier |
krvmga: Challenge accepted |
| 11:13 |
krvmga |
lol |
| 11:15 |
* Dyrcona |
left his house keys on the kitchen counter at home. |
| 11:16 |
Dyrcona |
So, yeah, it's Monday here. :) |
| 11:16 |
* kmlussier |
isn't really working today. |
| 11:20 |
krvmga |
Dyrcona: now THAT's my usual Monday |
| 11:32 |
kmlussier |
@quote random |
| 11:32 |
pinesol_green |
kmlussier: Quote #95: "< jeff> i feel a great disturbance in the code... as if $NUMBER of Dumper() calls cried out, and were removed." (added by csharp at 11:40 AM, October 29, 2014) |
| 11:37 |
csharp |
jeff++ |
| 11:41 |
Dyrcona |
Fun little tidbit: If you're saving xlsx files from LibreOffice, LO will output XML entities for characters like ' and so on. |
| 11:41 |
Dyrcona |
From whence my CPAN chatter earlier. I installed the XML::Entities module to decode them. |
| 11:44 |
Dyrcona |
kmlussier++ |
| 11:46 |
kmlussier |
:) |
| 11:49 |
|
edoceo joined #evergreen |
| 11:49 |
|
sandbergja joined #evergreen |
| 12:45 |
|
jihpringle joined #evergreen |
| 12:58 |
jeff |
What is the current state of the art in terms of documentation of hold policies? |
| 12:59 |
jeff |
evergreen in action has a nice section, though i'm sure it could be outdated. |
| 13:00 |
kmlussier |
jeff: Evergreen in action was written before the best holds selection orders were put into place. |
| 13:00 |
jeff |
*nod* |
| 13:01 |
kmlussier |
Having said that, Evergreen in action was never meant to be comprehensive coverage of holds documentation. It was meant to be "these are the most important settings to configure to get started." |
| 13:01 |
kmlussier |
I've always thought it would be nice to write an entire book on holds. |
| 13:01 |
jeff |
heh |
| 13:03 |
|
mmorgan1 joined #evergreen |
| 13:05 |
|
mmorgan joined #evergreen |
| 13:15 |
jeff |
oh hey, i remember this lesson! if you're going to throw an error on an unexpectedly-formed record, remember to have the record id handy somewhere that you can output! |
| 13:19 |
csharp |
jeff: using marc_export? |
| 13:19 |
jeff |
More Elasticsearch indexing experimentation. |
| 13:20 |
csharp |
ah |
| 13:23 |
csharp |
jboyer-isl: I was thinking about opening a bug on slow searches due to pub date filtering/sorting, but didn't want to duplicate effort - were you already working on one? |
| 13:24 |
jboyer-isl |
csharp: Alas, no. If you're in a good position to enter one soon that would be helpful. |
| 13:24 |
csharp |
can do |
| 13:24 |
gmcharlt |
https://evergreen-ils.org/welcome-evergreens-newest-core-committer-kathy-lussier/ |
| 13:25 |
* csharp |
notices bug 1470957 when doing an LP search |
| 13:25 |
pinesol_green |
Launchpad bug 1470957 in Evergreen 2.8 "Items are incorrectly sorting when using the Sort By Publication date feature" [Undecided,New] https://launchpad.net/bugs/1470957 |
| 13:25 |
csharp |
kmlussier++ |
| 13:25 |
csharp |
looks like that just needs a test |
| 13:27 |
jboyer-isl |
kmlussier++ |
| 13:28 |
gmcharlt |
kmlussier++ |
| 13:29 |
berick |
kmlussier++ |
| 13:35 |
berick |
gmcharlt++ # blog |
| 13:38 |
|
bmills joined #evergreen |
| 13:44 |
dbwells |
kmlussier++ |
| 13:44 |
jboyer-isl |
csharp: are you thinking that bug fix will speed up the searches, or are were you pointing out that it needs a sign-off? I couldn't tell from your reply, but I'm not sure it would effect the search/sort speed. |
| 13:45 |
yboston |
kmlussier++ |
| 13:45 |
dbs |
csharp: kmlussier++ needs a test? |
| 13:45 |
dbs |
because I'm happy to test it: kmlussier++ |
| 13:45 |
dbs |
kmlussier++ |
| 13:45 |
gmcharlt |
let's see if that worked... |
| 13:46 |
gmcharlt |
@karma kmlussier |
| 13:46 |
pinesol_green |
gmcharlt: Karma for "kmlussier" has been increased 161 times and decreased 0 times for a total karma of 161. |
| 13:46 |
kmlussier |
Wait, nobody told me there were tests involved! ;) |
| 13:46 |
kmlussier |
Thanks everyone! |
| 13:47 |
krvmga |
Saw the email announcement just now. Congratulations, Kathy! |
| 13:47 |
krvmga |
kmlussier++ |
| 13:48 |
jboyer-isl |
kmlussier: if 2 unladen african swallows leave the station at the same time, one going east, the other going north... |
| 13:48 |
krvmga |
jboyer-isl: wait! wait! i know this one!.... |
| 13:48 |
jeff |
kmlussier++ |
| 13:48 |
kmlussier |
krvmga: Quick! Send me the answer in a pm. |
| 13:48 |
krvmga |
lol |
| 13:48 |
krvmga |
42 |
| 13:48 |
* berick |
invites kmlussier to the VIP channel |
| 13:49 |
krvmga |
ooo, the VIP channel. |
| 13:49 |
berick |
... where the karma auto-increments |
| 13:49 |
krvmga |
lol |
| 13:50 |
csharp |
the first rule of the VIP channel is YOU DO NOT TALK ABOUT THE VIP CHANNEL! |
| 13:51 |
RoganH |
kmlussier++ |
| 13:51 |
mceraso |
kmlussier++ |
| 13:51 |
csharp |
dbs: heh - sometimes I wish IRC supported threaded discussions ;-) |
| 13:51 |
krvmga |
and, if it's your first time, you have to VIP! (that didn't make sense. sorry. i thought i had somewhere to go with it.) |
| 13:52 |
berick |
krvmga++ |
| 13:53 |
csharp |
bug 1514549 is now open and ready for input |
| 13:53 |
pinesol_green |
Launchpad bug 1514549 in Evergreen "Pub date sorting/filtering causes slow OPAC search" [Undecided,New] https://launchpad.net/bugs/1514549 |
| 13:54 |
csharp |
yes, there are bad stats, but since jboyer-isl can confirm the same, I'm not sure it should be seen as a local issue initially |
| 13:55 |
csharp |
seq scans of metabib.record_attr_vector_list |
| 13:58 |
Dyrcona |
There's a VIP channel? |
| 13:59 |
berick |
it just got raided and shut down. we're all back in gen-pop now. |
| 13:59 |
Dyrcona |
berick++ |
| 14:00 |
* csharp |
ironically hangs out in plain old #evergreen |
| 14:04 |
Dyrcona |
It's apple time! |
| 14:04 |
Dyrcona |
And, I believe it is a McKintosh, not a Macintosh. :) |
| 14:10 |
|
sarabee joined #evergreen |
| 14:15 |
* Dyrcona |
can't even spell the name of his apple correctly: Mcintosh. |
| 14:22 |
* jboyer-isl |
wonders how grim the calculations would be to pay the 2.25% for stripe out of pocket... Possibly worth the stress relief of using a more reliable method? |
| 14:26 |
* tsbere |
isn't sure what jboyer-isl is up to but isn't sure it is good to contemplate |
| 14:26 |
jeff |
jboyer-isl: 2.9%, unless you've hit a certain volume. |
| 14:27 |
jeff |
(and don't forget the $0.30) |
| 14:27 |
jboyer-isl |
jeff, Ah, I might have been thinking of Square. (or complete make-believe, because anything is possible!) |
| 14:28 |
jboyer-isl |
tsbere: Indeed, I sometimes forget how much we bring in through the OPAC (until something breaks, and then these kinds of thoughts start popping up...) |
| 14:29 |
jeff |
Square is 2.75% for physical swipes, unless you're keying by hand (which means it processes as a higher risk CNP), then it's 3.5% + $0.15 |
| 14:32 |
jeff |
and then there's Square Cash, which is debit card only, but is a flat 2.75% (all online, but mostly revolving around either a person to person transaction (in which case there's no fee!) or more of a manual invoice-then-pay for a business (where the fee kicks in) |
| 14:32 |
Dyrcona |
Just BTC.... :) |
| 14:32 |
jeff |
jboyer-isl: what are you currently using for credit card payments, and what has you currently thinking about Stripe again? :-) |
| 14:34 |
jboyer-isl |
jeff: one of those systems where the user is redirected to another site, completes the transaction, and is redirected back. Their server contacts our servers as the transaction is approved. |
| 14:35 |
jboyer-isl |
There are 2 main failure modes, 1: we just never hear from their servers, and have to put the transactions in by hand, and 2, we do hear from them, but the user's last_xact_id has changed, and I get an hourly complain-o-gram from a log watching utility until it's taken care of. |
| 14:36 |
jboyer-isl |
(followup to failure 1 above: we get a daily spreadsheet of accepted transactions, if that doesn't balance with a simple query to pulls yesterday's OPAC intake, we do some digging through logs and etc.) |
| 14:36 |
jeff |
Authorize.net SIM API, or something else? |
| 14:36 |
jboyer-isl |
Something else. As far as I can tell it's entirely custom, as is my code for talking to it. |
| 14:37 |
jeff |
Ah. I thought you guys were using Authorize.net for that, and was going to say... I've not had problems like that lately. :-) |
| 14:41 |
|
mmorgan joined #evergreen |
| 14:43 |
|
jihpringle joined #evergreen |
| 15:18 |
|
bmills joined #evergreen |
| 15:22 |
|
edoceo joined #evergreen |
| 16:01 |
phasefx |
would folks be interested in me adding more variables to colors.tt2 to de-couple how some of them get re-used and give us more granularity without having to tweak style.css.tt2 all the time? |
| 16:05 |
csharp |
miker: I was chatting with others at the Hack-A-Way about page size - I don't recall the full discussion as to why we're using 10K pages, except that irrelevant results were showing up with the 1K number |
| 16:05 |
csharp |
that was several years ago, before QP improvements |
| 16:05 |
miker |
csharp: yeah, there's risk to smaller page sizes, certainly |
| 16:06 |
csharp |
I'll play with that on one of our test machines and try (and possibly try to find a balance with Elaine ;-)) |
| 16:09 |
miker |
csharp: that won't make things "fast", mind. I think a "show me stuff with this attribute" set of API methods could be, though. |
| 16:09 |
jboyer-isl |
I was looking at some of our 60+s searches in pgbadger and they all appear to be blank keywords with formats, or subject searches . (subject: United States seems to be a favorite.) |
| 16:09 |
miker |
the search query structure assumes search terms of some sort |
| 16:09 |
jboyer-isl |
Also sorted by pubdate, not every subject search is that slow. |
| 16:10 |
jboyer-isl |
I was looking for examples of slow searches with keywords, but came up empty. |
| 16:10 |
miker |
jboyer-isl: we may be able to make sorters faster ... TUITS!!!! :) |
| 16:11 |
miker |
(but that would still assume a search of some sort) |
| 16:11 |
jboyer-isl |
miker: I don't doubt it. I'm very familiar with the scarcity of tuits lately. |
| 16:11 |
jboyer-isl |
(locally) |
| 16:12 |
miker |
we need a different query structure to make list-by-attributes fast, I think, is my main point (re csharp's bug) |
| 16:13 |
jboyer-isl |
That makes sense, different sets of attributes, different join strategies, etc. |
| 16:29 |
|
jihpringle joined #evergreen |
| 16:38 |
Dyrcona |
My new mantra: Ticket or didn't happen. |
| 16:38 |
Dyrcona |
Gah.... Long day. |
| 16:39 |
Bmagic |
ha! |
| 16:58 |
|
mmorgan1 joined #evergreen |
| 17:00 |
|
mmorgan2 joined #evergreen |
| 17:01 |
|
mdriscoll left #evergreen |
| 17:02 |
Bmagic |
Patron standing penalties are branch owned which makes them exclusive to that branch. Another branch doesn't see the alert? |
| 17:05 |
|
ericar joined #evergreen |
| 17:09 |
|
mmorgan2 left #evergreen |
| 17:27 |
tsbere |
Bmagic: You can set the depth they are created at for some things (like staff created ones). For others they use the penalty threshold org unit. |
| 18:14 |
|
mrpeters left #evergreen |
| 19:29 |
|
jihpringle_ joined #evergreen |
