| Time |
Nick |
Message |
| 01:06 |
|
Mark__T joined #evergreen |
| 01:36 |
|
j_scott left #evergreen |
| 03:17 |
|
mrpeters joined #evergreen |
| 04:49 |
|
mcooper joined #evergreen |
| 07:37 |
|
jboyer-isl joined #evergreen |
| 07:40 |
|
rjackson-isl joined #evergreen |
| 07:46 |
|
collum joined #evergreen |
| 08:18 |
|
kbeswick joined #evergreen |
| 08:21 |
|
akilsdonk joined #evergreen |
| 08:21 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
ericar joined #evergreen |
| 08:52 |
|
timlaptop joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 08:57 |
|
rfrasur joined #evergreen |
| 09:00 |
|
Shae joined #evergreen |
| 09:01 |
|
rfrasur joined #evergreen |
| 09:01 |
rfrasur |
Pardon. setting up new computer. |
| 09:02 |
|
rfrasur joined #evergreen |
| 09:02 |
Dyrcona |
"It's just the normal noises in here." |
| 09:03 |
* Dyrcona |
just discovered a query running on his development database since the 5th. |
| 09:06 |
Dyrcona |
Killed it and my pg_restore actually gets going. |
| 09:06 |
* Dyrcona |
thinks this is going to be another long day. |
| 09:07 |
rfrasur |
We'll see. |
| 09:07 |
Dyrcona |
Now to run some untested code that alters bills in production! |
| 09:07 |
Dyrcona |
It *is* going to be a long day! :) |
| 09:08 |
rfrasur |
:D - but maybe fun |
| 09:08 |
rfrasur |
in which case, a long day is good. |
| 09:13 |
|
RoganH joined #evergreen |
| 09:21 |
rfrasur |
(and now I shall force myself to use Chrome) |
| 09:22 |
* Dyrcona |
uses Chromium. |
| 09:22 |
Dyrcona |
There's a small difference. |
| 09:30 |
Dyrcona |
Grr. |
| 09:30 |
* Dyrcona |
has to do the restore again. |
| 09:33 |
rfrasur |
I just have to break my Firefox habit more than anything. |
| 09:33 |
rfrasur |
and the Raspberry Pis arrived. |
| 09:36 |
jboyer-isl |
Those were for micro-staff stations, or catalogs? I forget. |
| 09:36 |
rfrasur |
first, for opacs. |
| 09:36 |
jboyer-isl |
Ah. |
| 09:37 |
rfrasur |
I figure that's the lowest impact way to get used to Linux...for me to learn some more before doing something more ambitious |
| 09:37 |
rfrasur |
Our IT dude had no clue...so, that was a fun conversation. |
| 09:37 |
Dyrcona |
rfrasur++ |
| 09:37 |
* Dyrcona |
wishes she were a director in his consortium. |
| 09:38 |
rfrasur |
I dunno if I'm a good director or not, honestly. But thank you. |
| 09:38 |
* rfrasur |
forgot to buy wireless dongles though |
| 09:43 |
rfrasur |
I did look up some information about modding the Pi to upgrade the RAM to at least 1G but it involves a soldering iron....and yeah. |
| 09:43 |
* rfrasur |
does not solder |
| 09:43 |
rfrasur |
(snap circuits raspberry pi?) |
| 09:44 |
|
kmlussier joined #evergreen |
| 09:44 |
jeff |
snap circuits are fun. we were trying to figure out a way to circ kits without going insane over parts. |
| 09:47 |
rfrasur |
jeff: if you ever DO figure out a way, please share the info. I did hear a presentation from a guy from Detroit's innovation center or whatever it's called. They have maker kits (oh how I despise that label)...some with snap circuits...and you can imagine other things as well, but they don't go out to the public yet either...though they're also talking about it at some branch locations. I dunno. Circulating that type |
| 09:47 |
rfrasur |
of thing inherently involves loss..plus...how to handle it staff side...and yeah. insanity. |
| 09:47 |
Dyrcona |
parts: Have I told you lately that I hate you? |
| 09:47 |
Dyrcona |
@hate parts |
| 09:47 |
pinesol_green |
Dyrcona: But Dyrcona already hates parts! |
| 09:47 |
rfrasur |
:D |
| 09:49 |
Dyrcona |
None of our libraries are even talking about that sort of thing, afaik. |
| 09:49 |
rfrasur |
and none of my staff was impressed w/ the Pi..s. They said "that's a computer?"....to which I said "yes" (w/o trying to explain to them what a computer really is...because...yeah, no...gone down that road) |
| 09:49 |
jeff |
we would not be dealing with the parts in an ILS "parts" sense. that would be something i'd discourage, no matter how amusing it is to think about. |
| 09:50 |
rfrasur |
Then they asked what I was going to do with them (build OPACs)....and then I had to explain the diff between the OPAC and staff client...really? |
| 09:50 |
jeff |
placing a hold on a resistor... |
| 09:50 |
Dyrcona |
rfrasur: You really want to freak them out, tell them their phone is a computer, even a flip phone. |
| 09:50 |
|
BigRig joined #evergreen |
| 09:50 |
rfrasur |
Dyrcona: I did that one day....and had dreams about them coming to my house w/ blazing torches and pitchforks. It was ugly. |
| 09:50 |
Dyrcona |
rfrasur: That sounds about right. At least it jibes with my experience.... |
| 09:51 |
* rfrasur |
will not let them destroy my enthusiasm though |
| 09:51 |
rfrasur |
I'll leave that for the first unsuccessful OS install |
| 09:53 |
|
sseng joined #evergreen |
| 09:58 |
jeff |
hrm. SIP renewals can fail in the case of multiple active library card numbers on a patron account. |
| 09:59 |
Dyrcona |
jeff: That's an unexpected condition, because Evergreen in general assumes only 1 active barcode per patron. |
| 09:59 |
Dyrcona |
At least, that's my assumption of what Evergreen assumes. :) |
| 10:01 |
jeff |
evergreen does a pretty good job of not making that assumption, in my experience. sip, not so much. NCIP spec/standard does a great job, the single third party vendor implementation of ncip I get to deal with... not so much. |
| 10:02 |
Dyrcona |
jeff: Well, it seems bug worthy. |
| 10:02 |
Dyrcona |
A lot of things happen in the wild that are unexpected. :) |
| 10:02 |
jeff |
yeah. |
| 10:03 |
jeff |
we used to have automatic check-in enabled on these self checkout workstations -- if a checkout was denied, the sip client would query item status, and if it was one of a handful of statuses, it would perform a checkin, then check out. |
| 10:03 |
jboyer-isl |
rfrasur: threaten staff to a group project for their next staff day: https://mmm1127.verio-web.com/grayma/catalog/809v2.htm |
| 10:04 |
jboyer-isl |
(I loved building that thing. Not so good at programming it though.) |
| 10:04 |
jeff |
two issues there: 1) unlimited renewals on non-renewable items and 2) the checkin wasn't no-op, so copies were being captured for a hold and placed in transit, then were walking out the door. :-) |
| 10:05 |
rfrasur |
jboyer-isl, that's so stinkin' awesome. It might be a way to do staff weeding, too. |
| 10:05 |
* rfrasur |
wants one |
| 10:05 |
Dyrcona |
8085? Seriously.... |
| 10:05 |
Dyrcona |
1977 wants it's CPU back. |
| 10:05 |
jboyer-isl |
jeff: We've got a library with an issue like that. Their selfchecks expect complete "standard" support, including the "This checkin is actually a cancellation of a previous checkout" |
| 10:05 |
rfrasur |
Dyrcona: I don't know any better. |
| 10:06 |
jboyer-isl |
8085? This is v2! Mine came with an 8080 I think. |
| 10:06 |
rfrasur |
I want all those things. |
| 10:06 |
jboyer-isl |
I don't think you want to be scratch-building for a much more recent CPU. (an SOC, though...) |
| 10:08 |
* Dyrcona |
would want at least a Motorola 68020 with MMU. :) |
| 10:08 |
jeff |
jboyer-isl: support for checkout cancellation is an annoing thing to have to deal with. i'm assuming the sip clients in question are using EM-style security strips? |
| 10:09 |
jboyer-isl |
jeff: Yes, EM AND RFID. Two great tastes that blargble. |
| 10:10 |
pinesol_green |
[evergreen|Elliot V] Documentation: Update links in installation instructions. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=59a6698> |
| 10:11 |
jeff |
jboyer-isl: in SIP3, the "cancel" field is "depreciated" [sic] in favor of new UndoCheckin and UndoCheckout messages. Still annoying, but slightly less so. |
| 10:11 |
jeff |
(the final copy of the standard may use "deprecated" -- I had a draft handy) |
| 10:12 |
jboyer-isl |
I've seen that. At least that won't cause so many fake circs, even though they still won't work. |
| 10:13 |
jeff |
I'm not sure when "undo checkin" would ever come into play. |
| 10:13 |
jeff |
I'm guessing that "undo checkout" is for times when it fails to set security on the item? |
| 10:14 |
Dyrcona |
I doubt we'll ever actually see SIP3 implemented anywhere. |
| 10:14 |
jeff |
I doubt that we've ever actually seen SIP2 implemented anywhere. |
| 10:14 |
Dyrcona |
heh. |
| 10:15 |
Dyrcona |
I was waiting for someone to make that comment. :) |
| 10:15 |
Dyrcona |
Library Standards: The Standards That Aren't™ |
| 10:17 |
jboyer-isl |
jeff: I think both cancellations can be used for security reasons. If, say, your selfcheck doesn't enable security until after the checkin completes, but the patron pulls the item too soon, etc. (That's not the way I'd do it, but I'm sure some of them work that way.) |
| 10:17 |
jeff |
sometime after Oct 21, there should be a recording of the NISO "open teleconference" regarding SIP. Not sure how much live participation will take place the day of. |
| 10:17 |
jcamins |
Dyrcona: or, Library Standards: Implement Different. "MARC killed my inner child." |
| 10:17 |
rfrasur |
Standards, ho! err...n/m. that's thundercats. |
| 10:17 |
jeff |
jboyer-isl: yeah, that's the only use case I've ever heard described for SIP "undo" or "cancel" flags/messages. |
| 10:18 |
Dyrcona |
MARC == Garbage |
| 10:18 |
jeff |
rfrasur: "Sword of <mumble>, give me SIP beyond SIP?" |
| 10:18 |
jboyer-isl |
rfrasur: Snarf rolls his eyes at lib standards implementations. |
| 10:18 |
rfrasur |
jeff++ |
| 10:18 |
rfrasur |
jboyer-isl++ |
| 10:19 |
jeff |
not sure of a library standards related analogue for "Sword of Omens" |
| 10:19 |
|
gdunbar joined #evergreen |
| 10:19 |
jboyer-isl |
Heh. Omens is as good as anything. It's all tea-leaves when it comes to support. |
| 10:19 |
rfrasur |
it's just been miscataloged. |
| 10:19 |
rfrasur |
It's there...just in the wrong spot somewhere. |
| 10:20 |
* Dyrcona |
prefers sheep entrails, but if tea leaves works for you... |
| 10:21 |
|
mllewellyn joined #evergreen |
| 10:30 |
RoganH |
Dyrcona: I prefer to call it haruspex. |
| 10:43 |
mrpeters |
oh ejabberd....why are you napping.... |
| 10:43 |
mrpeters |
following up on last week's deal....logins stop working, if you poke ejabberd by doing "ejabberdctl connected-users" logins start working again |
| 10:43 |
mrpeters |
freaking bizzare |
| 10:44 |
mrpeters |
no service restarts, just a poke of ejabberdctl |
| 10:44 |
jeff |
mrpeters: anything in any logs (opensrf or ejabberd, etc) before you poke? |
| 10:45 |
mrpeters |
nothing that jumps out at me |
| 10:45 |
jeff |
interesting. |
| 10:45 |
mrpeters |
yeah, its funky |
| 10:45 |
mrpeters |
oh, we also switched to droneless config to simplify troubleshooting |
| 10:46 |
mrpeters |
so the head is running all services |
| 10:48 |
mrpeters |
i threw an ejabberd.cfg from another debian system on there, just for kicks |
| 10:48 |
mrpeters |
there were some slight differences in maxrate but that was about it |
| 10:50 |
rfrasur |
(getting everything synced back up after new computer...yikes) |
| 10:50 |
pinesol_green |
[evergreen|Robert Soulliere] Documentation: Update EG upgrade instructions to 2.5 beta1 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2bfda0> |
| 11:03 |
|
j_scott joined #evergreen |
| 11:13 |
|
Shae joined #evergreen |
| 11:24 |
|
j_scott1 joined #evergreen |
| 11:37 |
jcamins |
Some folks on the #koha IRC channel were wondering about the accuracy of the "Developing Partnerships" article in LJ. In particular, the claim that KCLS forked Evergreen and is going in a different direction from the community. |
| 11:37 |
jcamins |
Does anyone know if that's correct? |
| 11:38 |
rfrasur |
jcamins: from my understanding...and simply put...yes. Which is not to say that partnerships weren't developed. |
| 11:39 |
jcamins |
Thanks. I didn't read the article because I don't want high blood pressure, but it sounds like the sections on LibLime's fork are somewhat less than researched. |
| 11:39 |
rfrasur |
I'm not sure it was an intentional forking...but necessary for their implementation |
| 11:40 |
jcamins |
Sure, I can understand that. |
| 11:40 |
rfrasur |
It was a pretty good article...insomuch as any article written from outside can be good. |
| 11:40 |
rfrasur |
it's hard for someone just asking questions to get a real sense of context and history |
| 11:40 |
jcamins |
Apparently it included the claim that all of LibLime's code is publicly available (as I said, didn't read it). |
| 11:41 |
rfrasur |
I'll be honest - I skipped over the Koha stuff because I don't know anything about it other than our library's experience with it lasted only 9 months...and the probs were administrative rather than software. |
| 11:41 |
* jcamins |
skipped over all the stuff. |
| 11:42 |
rfrasur |
;-) |
| 11:50 |
* rfrasur |
cutes up article about Pi so librarians will read it...with Skippy Jon Jones |
| 11:52 |
gmcharlt |
mmmmm, Pi |
| 11:53 |
rfrasur |
and Skippy Jon Jones :D |
| 11:58 |
Dyrcona |
Come to the Math Side. We have Pi! |
| 11:59 |
rfrasur |
http://rfrasur.wordpress.com/2013/10/10/raspberry-pi-ala-mode/ There she is. It's not pretty but hopefully some other librarians will get warm fuzzies. |
| 12:03 |
|
jdouma joined #evergreen |
| 12:09 |
|
smyers_ joined #evergreen |
| 12:10 |
|
BigRig joined #evergreen |
| 12:22 |
|
kmlussier1 joined #evergreen |
| 12:33 |
|
fparks joined #evergreen |
| 12:43 |
rfrasur |
jboyer-isl: although I think the payment program is a great one, getting period envelopes from the auditor of the state of Indiana is going to cause me blood pressure spikes. |
| 13:18 |
|
kmlussier1 joined #evergreen |
| 13:29 |
dbwells |
grabbing 0841 |
| 13:35 |
|
dconnor joined #evergreen |
| 13:35 |
jboyer-isl |
rfrasur: just keep telling yourself, "Ooh, our check finally came!" Feel free to do this when other auditor-addressed envelopes come to your mailbox, just don't blame me when you open them. :D |
| 13:35 |
|
sseng joined #evergreen |
| 13:35 |
pinesol_green |
[evergreen|Dan Wells] Make some FK constraints on config.metabib_field.id deferrable - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6eaa123> |
| 13:35 |
pinesol_green |
[evergreen|Dan Wells] Upgrade script for config.metabib_field sequence redo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04d34ab> |
| 13:35 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0841: make space in config.metabib_field sequence - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e917670> |
| 13:35 |
rfrasur |
jboyer-isl++ |
| 13:35 |
|
fparks joined #evergreen |
| 13:36 |
|
ktomita joined #evergreen |
| 13:37 |
|
smyers__ joined #evergreen |
| 13:41 |
rfrasur |
I hate printers so very much |
| 13:42 |
senator |
rfrasur: you and me both |
| 13:43 |
phasefx_ |
jfyi, I'm helping (a tiny bit) with reorganizing and going through the wiki, and take full blame for clean slating the front page :) |
| 13:43 |
phasefx_ |
it is a wiki, so if anyone is horrified, I can revert |
| 13:44 |
jboyer-isl |
Now, now, let's be fair. It's usually the software that really sucks. |
| 13:45 |
jboyer-isl |
Like a certain japanese company who's drivers crash because its log can't certain charsets properly. |
| 13:45 |
kmlussier |
Speaking of wiki cleanup, I was on the magic spells page today and was wondering if there is any reason we should be keeping instructions for reingesting bib records before 2.0. |
| 13:45 |
kmlussier |
http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#reingesting_bib_records_before_20 |
| 13:46 |
kmlussier |
phasefx_++ #That page needs a lot of love. |
| 13:46 |
* rfrasur |
also blames the software. brb...stupid stupid stupid |
| 13:48 |
eeevil |
dbwells: I didn't have a chance to look at it before it was pushed, but the sequence pushing commit e917670aee ... why didn't those get ON UPDATE CASCADE clauses? |
| 13:48 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0841: make space in config.metabib_field sequence - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e917670> |
| 13:50 |
|
ktomita_ joined #evergreen |
| 13:51 |
dbwells |
eeevil: no reason, other than that it wasn't needed for what I was trying to do. Should I go ahead and add them as well? I am going to need another upgrade script due to some backport funniness anyway. |
| 13:52 |
* Dyrcona |
agrees with eeevil. I added ON UPDATE CASCADE ON DELETE CASCADE to all of those constraints on my local db. |
| 13:53 |
eeevil |
dbwells: IMO, it makes things much easier down the road. DEFERRABLE at least lets one succeed in the end, but CASCADE makes it magical |
| 13:53 |
eeevil |
(sorry for causing churn... :( ) |
| 13:54 |
eeevil |
dbwells: I'd personally be fine with revising the existing upgrade script in-line, fwiw |
| 13:54 |
eeevil |
because it's so new |
| 13:54 |
eeevil |
(others may disagree with /that/ part, though) |
| 13:55 |
* Dyrcona |
thinks that is all right. |
| 13:55 |
dbwells |
eeevil: Do you want DELETE CASCADE as well? That sort of magic tends to scare me a little. |
| 13:55 |
eeevil |
if it's a leaf table, yes |
| 13:55 |
eeevil |
if it's an origin or intermediate table, then it's debatable |
| 13:56 |
eeevil |
but for the outer-most tables in the schema, either ON DELETE CASCADE or, if the data has other links and the fkey is nullable, ON DELETE SET NULL is good |
| 13:56 |
Dyrcona |
Prior to this, some had ON DELETE CASCADE, some didn't. |
| 13:57 |
Dyrcona |
One had both ON UPDATE CASCADE and ON DELETE CASCADE, fwiw. |
| 13:57 |
|
remingtron joined #evergreen |
| 13:58 |
dbwells |
Thing is, I have neither the brain cycles nor the tuits to determine whether any of these choices were intentional or not. |
| 13:58 |
eeevil |
yeah, there was a big-ish fkey cleanup a couple years ago, but it probably didn't catch everything, and new ones may have leaked in with ON blah CASCADE|NULL clauses |
| 13:58 |
* eeevil |
looks at this commit in particular |
| 13:59 |
dbwells |
If you guys can tell me how these should be, I can push the buttons. |
| 13:59 |
Dyrcona |
Well, ON UPDATE CASCADE is necessary in this case, since that makes it possible to fix things like my local entry with id 28. |
| 14:00 |
eeevil |
all should got ON UPDATE CASCADE in this case... what Dyrcona said |
| 14:00 |
dbwells |
Well, it isn't necessary because of the handy-dandy function I stole from the 1.6 upgrade script. |
| 14:00 |
dbwells |
1.6-2.0, that is. |
| 14:01 |
eeevil |
dbwells: well, yes, but it would be magic with ON UPDATE CASCADE ;) |
| 14:01 |
dbwells |
Of course, with ON UPDATE CASCADE, we might not need the function at all. |
| 14:01 |
Dyrcona |
right, on both the latter counts. |
| 14:02 |
dbwells |
eeevil: any final call for ON DELETE CASCADE for these four? |
| 14:02 |
eeevil |
I think POLA says leave ON DELETE alone |
| 14:03 |
eeevil |
CASCADE is /probably/ fine ... but the likelyhood of deleting any of those is low, and a roadblock to that isn't the end of the world |
| 14:06 |
dbwells |
okay, so, add ON UPDATE CASCADE, leave everything else alone. Right? I know the function will have some extra lines in it, but they're harmless. |
| 14:08 |
dbwells |
eeevil: also, I wasn't planning to push the other stuff yet to give you as much time today as possible. I thought this part I just pushed was non-controversial, but I guess not ;) |
| 14:09 |
eeevil |
heh |
| 14:09 |
eeevil |
not controversial, per se |
| 14:09 |
eeevil |
I REQUIRE MOAR HOURS. GIVE ME MORE HOURS. |
| 14:16 |
jboyer-isl |
eeevil: The beatles had 8 days a week at one point, there's a handy trick. |
| 14:17 |
berick |
jboyer-isl: even then, it was not enough (to show they cared) |
| 14:17 |
dbwells |
Yeah, but they wasted it all loving some girl. |
| 14:21 |
* Dyrcona |
wishes he fork() himself they way his programs can to do more all at once. |
| 14:21 |
Dyrcona |
oof. |
| 14:21 |
* Dyrcona |
shakes his head at his own mistakes. |
| 14:27 |
|
smyers_ joined #evergreen |
| 14:34 |
berick |
phasefx: any reason the top two commits in collab/phasefx/livetests don't have sign-offs? planning on squashing those? |
| 14:38 |
eeevil |
dbwells: so, AIUI, the main complaint about titleNonfiling is the lack of chopPunctuation on $a when there are no following subfields (typically, $c or $d). does that correctly restate the crux of d84b9220bb491 ? |
| 14:40 |
eeevil |
c'mon pinesol_green: d84b9220bb49170bd8728ac05fb025d3bc18032c |
| 14:42 |
jeff |
commit d84b9220bb49170bd8728ac05fb025d3bc18032c |
| 14:42 |
jeff |
huh. |
| 14:42 |
jeff |
well, that doesn't seem to be an Evergreen commit hash |
| 14:43 |
dbwells |
eeevil: the changes to titleNonfiling in that commit are inconsequential at this point, but were part of the evolution of the code, and left in because they seemed better overall given the limited and targetted scope of titleNonfiling. The more meaningful change in that commit is the addition of titleBrowse. |
| 14:43 |
jeff |
ah, it's in working. i wonder if pinesol_green doesn't track working, or doesn't fetch often enough to be realtime |
| 14:44 |
phasefx |
berick: oversight |
| 14:44 |
eeevil |
dbwells: right. based on the commit message, the substance of that seems to be meant to avoid dropping punctuation between 'a' and following subfields, while retaining nonSort |
| 14:45 |
phasefx |
berick: you're welcome to forge my signature if that's easiest, or I can push a new branch |
| 14:45 |
dbwells |
titleBrowse was added because titleNonfiling gave a better display, but couldn't be sorted, while titleInfo could be sorted, but I couldn't find a way to make the display as good as titleNonfiling. Yes, what you said. |
| 14:47 |
berick |
Signed-off-by: Jason "The War Hammer" Etheridge <jason aol.com> |
| 14:47 |
|
mrpeters left #evergreen |
| 14:47 |
eeevil |
ok ... I'm fine (happy) with that, then. the "problem" is that MODS (well, really, AACR2+ISBD) is at odds with display, and/or MODS is incomplete WRT the dual uses of semantic interpretation for indexing /and/ display |
| 14:47 |
berick |
phasefx: k, and you're cool w/ the top commit msg consisting entirely of "use TestUtils" ;) |
| 14:47 |
eeevil |
berick++ |
| 14:48 |
berick |
phasefx: i'll forge and augment the msg, if no objections |
| 14:48 |
phasefx |
berick: no objections, thanks man |
| 14:48 |
dbwells |
eeevil: yes, I think MODS is definitely more targeted at simpler semantics, so our use of it for display gets a little edgy sometimes. |
| 14:49 |
kmlussier |
Looks like Tuesday, 1 p.m. Eastern, 10 a.m. Pacfic for next week's dev meeting. Mark your calendars! |
| 14:50 |
dbwells |
eeevil: down the line I think it could be cool to associate 'formatter' functions with config.metabib_field rather than just a 'joiner' for display, but that obviously would be post 2.5 :) |
| 14:50 |
eeevil |
dbwells: are there commits, in particular, that you want signoff from me on? senator's are enough for "the rules", of course, but I agree this is all step in the right direction. the only question I have is whether we should consider using titleBrowse for title|proper, and dropping title|browse. IMO, that would be the best of all possible worlds |
| 14:52 |
dbwells |
eeevil: I'm in favor of that, but I ran out of steam trying to determine of the titleNonfiling 'stick together' plan still did anything useful. |
| 14:52 |
eeevil |
dbwells: a joiner of '' should do that ... let me look real quick |
| 14:54 |
|
remingtron joined #evergreen |
| 14:54 |
eeevil |
dbwells: yes, a joiner of <empty-string> instead of NULL should do exactly what dbs wants in title|proper |
| 14:54 |
dbwells |
eeevil: IIRC, using the joiner of '' would fail when the call-template "part" made nodes (that is, they would stick together too). I thought about stringifying that too, but called it a day instead. |
| 14:54 |
* eeevil |
looks |
| 14:55 |
eeevil |
arg ... yeah... you're right |
| 14:55 |
eeevil |
ok, separate for now ... more thinking on this for .NEXT |
| 14:56 |
eeevil |
dbwells: ok. I've exhausted all complaints with the branch. there's too much to do to make it perfect, and it's good enough. :) |
| 14:56 |
eeevil |
dbwells++ |
| 14:56 |
eeevil |
and |
| 14:56 |
eeevil |
bshum++ |
| 14:56 |
eeevil |
senator++ |
| 14:56 |
eeevil |
for testing |
| 14:57 |
dbwells |
eeevil: we arrived at exactly the same place :) |
| 14:59 |
dbwells |
eeevil: I do want to continue down the better road for .NEXT, and really, the sooner, the better. 3-4 months out I am not likely to remember any of this. |
| 14:59 |
berick |
phasefx: finally, is this expected when running the tests? "Subroutine section_pkg redefined at (eval 1493) line 4."? -- seems to repeat w/ each test. |
| 14:59 |
berick |
they pass OK |
| 15:01 |
dbwells |
eeevil: I am also very keen to start documenting all the reasons for what we are doing, and I tried to do some of that on the bug / in the commits. It's definitely the sort of case where you try to push down one thing and something pops out on the other side, so to speak. |
| 15:01 |
phasefx |
berick: it happens with however make livecheck does it, but does not happen if you run the tests directly out of the live_t/ directory with perl or prove. I didn't try very hard to figure out why |
| 15:01 |
|
rfrasur joined #evergreen |
| 15:02 |
* phasefx |
blindly based livecheck off of what check was doing, but it may not make sense to do it that way |
| 15:02 |
berick |
phasefx: copy that. i'll leave it for another day -- maybe the same day we fix uninitialized value $dup_args{"real_api_name"} |
| 15:02 |
berick |
(from make check) |
| 15:03 |
phasefx |
whenever someone goes on a holy mission to eliminate all warnings :) |
| 15:05 |
berick |
skabam! live tests. |
| 15:05 |
* berick |
tries to think of a good live test to add |
| 15:07 |
phasefx |
berick++ |
| 15:07 |
pinesol_green |
[evergreen|Jason Etheridge] tests against stock test data and live Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=310a0d5> |
| 15:07 |
pinesol_green |
[evergreen|Jason Etheridge] test bill payment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5c883f0> |
| 15:07 |
pinesol_green |
[evergreen|Jason Etheridge] Add a TestUtils library for live tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6530fb4> |
| 15:08 |
phasefx |
berick: we could use examples for how to use MARC in a perl test |
| 15:10 |
berick |
phasefx: as in, inspect bre.marc (e.g. via xml::Libxml) or specifically marc::record? |
| 15:11 |
phasefx |
berick: let's say someone wants to test some parameter to an opensrf marc update method, how might they represent/get the MARC they're using in the perl environment? |
| 15:14 |
berick |
phasefx: k, i can probably come up w/ something. gracias |
| 15:14 |
eeevil |
dbwells: indeed. we've turned search into a stress ball! ;) |
| 15:15 |
dbwells |
heh |
| 15:15 |
dbwells |
only the more you squeeze the more stressful you feel |
| 15:16 |
berick |
that's how stress balls work, too |
| 15:16 |
berick |
until they go through a window, anyway |
| 15:16 |
* dbwells |
thought that was only for him |
| 15:19 |
|
krvmga joined #evergreen |
| 15:20 |
|
krvmga left #evergreen |
| 15:30 |
|
jecs joined #evergreen |
| 15:35 |
jboyer-isl |
RRrraaage. It would seem that open-ils.storage:open-ils.storage.actor.user.checked_out.count and open-ils.actor:open-ils.actor.user.checked_out.count do not return the same things (in 2.2...) |
| 15:36 |
jeff |
not too surprising. the former would meant to be used by things like the latter. |
| 15:36 |
jeff |
not too surprising, but i can see how you might find it annoying. :-) |
| 15:36 |
jeff |
how do they differ? |
| 15:36 |
* jeff |
looks |
| 15:37 |
jboyer-isl |
They differ in what they count, not what they return. |
| 15:37 |
jboyer-isl |
Here's the actor version: |
| 15:37 |
jboyer-isl |
Received Data: { |
| 15:37 |
jboyer-isl |
"out":15, |
| 15:37 |
jboyer-isl |
"claims_returned":0, |
| 15:37 |
jboyer-isl |
"long_overdue":0, |
| 15:37 |
jboyer-isl |
"overdue":0, |
| 15:37 |
jboyer-isl |
"total":15, |
| 15:37 |
jboyer-isl |
"lost":0 |
| 15:37 |
jboyer-isl |
} |
| 15:37 |
jboyer-isl |
and storage: |
| 15:37 |
jboyer-isl |
Received Data: { |
| 15:37 |
jboyer-isl |
"out":15, |
| 15:37 |
jboyer-isl |
"claims_returned":1, |
| 15:37 |
jboyer-isl |
"long_overdue":0, |
| 15:37 |
jboyer-isl |
"overdue":0, |
| 15:37 |
jboyer-isl |
"total":16, |
| 15:37 |
jboyer-isl |
"lost":0 |
| 15:37 |
jboyer-isl |
} |
| 15:37 |
jboyer-isl |
The difference is subtle, and infuriating. |
| 15:39 |
jboyer-isl |
I've been trying to track down why our staff clients aren't showing any claimed returned items for some patrons. (I don't think it's all of them, which is even worse.) |
| 15:39 |
dbwells |
grabbing 0842 and 0843 |
| 15:45 |
jeff |
jboyer-isl: i suspect that in this case your "missing" claims returned has an xact_finish set. |
| 15:46 |
jeff |
jboyer-isl: can you confirm that's the case? do you have an example of a patron where the counts match and one where they don't? (keeping in mind it may only be the claims returned count that differs) |
| 15:46 |
jboyer-isl |
I'm sure it does. Depending on your Eg version that does or doesn't matter. For claimed returned items, checkin_time is consulted rather than xact_finish. Sometimes. |
| 15:47 |
jboyer-isl |
This appears to be "fixed" in 2.(>2), for instance our dev server shows claimed returned items regardless of xact_finish null-ness. |
| 15:47 |
jeff |
the storage method uses the action.open_circulation view, which includes anything without a checkin_time -- the actor method uses slightly different logic defined in an IDL view, which i agree -- is annoying, especially in this case. |
| 15:48 |
jeff |
oh? i was looking at master, though not re-creating the issue you observed. |
| 15:48 |
jboyer-isl |
I was just noticing "my $meth = 'retrieve_action_open_circ_';" in Application/Actor.pm. Bummer. :/ |
| 15:49 |
jeff |
hmm? |
| 15:49 |
jboyer-isl |
I meant I was coming to the same conclusion about it using open circs vs. all circs. I'm just slow about the typage. |
| 15:50 |
jeff |
action::open_circ_list and action::open_circ_count IDL views may pre-date the action.open_circulation database view -- or they may not. |
| 15:51 |
tsbere |
jeff: I don't see action.open_circulation being used in storage for that call? |
| 15:52 |
tsbere |
jeff/jboyer-isl: What I *do* see is storage not caring about xact_finish for CLAIMSRETURNED, but the IDL view does (looks to be the same for LONGOVERUDE but they both agree on checking it for LOST) |
| 15:53 |
jeff |
tsbere: you're right. it uses the same logic but not the view itself. |
| 15:53 |
Dyrcona |
GAMEOVERDUDE |
| 15:53 |
jeff |
Dyrcona++ |
| 15:53 |
jboyer-isl |
Dyrcona++ |
| 15:54 |
jboyer-isl |
inconsistency-- |
| 15:54 |
jboyer-isl |
:/ |
| 15:54 |
jeff |
jboyer-isl: i wonder if the behavior difference you're seeing is not due to a change in the methods between 2.2 and current, but a change in what method the UI uses. |
| 15:54 |
jeff |
jboyer-isl: in both cases, are you observing this in the staff client on the patron summary/sidebar? |
| 15:54 |
jboyer-isl |
It's possible. I looked at the newer version of Actor.pm and it doesn't appear to have changed, but I haven't looked at the more recent version of chrome/content/main/constants.js. |
| 15:55 |
jeff |
the staff client wouldn't be calling storage, as it isn't exposed via the gateway, but could have changed in some other way. |
| 15:55 |
jeff |
it's not impossible that there's ANOTHER method for this data somewhere. :-) |
| 15:56 |
eeevil |
jeff: and, in reality, even likely |
| 15:56 |
* phasefx |
thinks the patron summary pane even grabs mous's and adds them up client-side |
| 15:57 |
phasefx |
or whatever the right fieldmapper object is |
| 15:57 |
eeevil |
phasefx: it used to, I'm sure. I remember the pain of mous's |
| 15:57 |
|
remingtron joined #evergreen |
| 15:57 |
eeevil |
mubs? |
| 15:58 |
eeevil |
something like that |
| 15:59 |
phasefx |
uses open-ils.actor.usergroup.members.balance_owed.authoritative today |
| 15:59 |
phasefx |
for the individual and the rest of their group |
| 16:00 |
phasefx |
and that, is using new_editor and some query for mous' |
| 16:01 |
phasefx |
json_query |
| 16:01 |
phasefx |
money.open_usr_summary |
| 16:02 |
jboyer-isl |
jeff: I don't know that I ever got back to your last Q: yes, this is in the staff client. I'm not really looking for resolution today (I imagine this isn't new), just venting some frustrations. :/ |
| 16:02 |
rfrasur |
(amazon is just being mean....sending a PAL format DVD...seriously...and does my staff read cases before processing? No...they do not) |
| 16:03 |
jeff |
jboyer-isl: sure, sure. can you confirm by checking your 2.2 system that the difference between a user with claims returned circs showing and not showing is that the not-showing circs have xact_finish set? |
| 16:03 |
phasefx |
and money.open_usr_summary is against money.materialized_billable_xact_summary where xact_finish is null |
| 16:03 |
jboyer-isl |
rfrasur: You could offer it for EU ILL's. |
| 16:04 |
rfrasur |
or frisbee golf. We're just going to use it and say it'll only play on computers (though it'll prolly play on some other players) |
| 16:04 |
jeff |
jboyer-isl: also, are you sure you aren't running into circ.do_not_tally_claims_returned OUS? |
| 16:04 |
jeff |
(which might not exist in 2.2) |
| 16:05 |
* Dyrcona |
knows there are Princess Bride related jokes in all of these ouses. |
| 16:05 |
jboyer-isl |
It does exist and I've set and cleared it to no avail. I'm finding a patron with claimed items now. |
| 16:07 |
jeff |
jboyer-isl: on the patron whose counts you pasted earlier... can you confirm that they have a circ with a null checkin_time and with stop_fines of CLAIMSRETURNED, and that circ has an xact_finish that is non-null? |
| 16:07 |
berick |
phasefx: is this at all what you were thinking? http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/bre-marc-live-test (top commit) |
| 16:07 |
|
kbutler joined #evergreen |
| 16:09 |
jboyer-isl |
jeff: Yes. For the pasted account xact_finish is set (no fines) and checkin_time is null |
| 16:10 |
jeff |
jboyer-isl: okay. and on your dev system you have a patron with a circ matching that same criteria, and it is shown where in production is it not? |
| 16:10 |
jeff |
s/shown/counted/, whatever |
| 16:11 |
phasefx |
berick++ that's not, but looks like a perfectly fine example to me. I was picturing some quoted MARC-XML or something :) |
| 16:12 |
phasefx |
much more useful/sane |
| 16:12 |
phasefx |
what you have, that is |
| 16:14 |
berick |
phasefx: cool |
| 16:15 |
jboyer-isl |
Oh damn it. |
| 16:15 |
jboyer-isl |
jeff: I was looking at the wrong action.circulation row when I said that xact_finish wasn't consulted. (there was a renewal in there.) |
| 16:16 |
jboyer-isl |
So yes, if you set xact_finish they still disappear, even on 2.4. |
| 16:16 |
jeff |
jboyer-isl: meaning that the issue you're observing seems to be present in both 2.2 and later? |
| 16:16 |
jeff |
jboyer-isl: that's actually good news. :-) |
| 16:16 |
jboyer-isl |
whether or not they should is something entirely different. |
| 16:16 |
eeevil |
Dyrcona: there are Princess Bride related jokes in all conversations, AFAICT |
| 16:17 |
rfrasur |
eeevil++ |
| 16:18 |
jeff |
live_t is messing with my tab completion muscle memory. |
| 16:18 |
jeff |
no idea why my fingers type l<tab> rather than lib. |
| 16:19 |
jeff |
actually, i suspect they've been typing li<tab> which is almost more silly. |
| 16:19 |
jboyer-isl |
jeff: I suppose that means that tomorrow I can file a bug on it in LP. At least I can stop chasing geese. |
| 16:23 |
jeff |
it appears that the storage method is more accurate but slower, and is only used by legacy scripts. the IDL view could just have its logic fixed rather easily. |
| 16:25 |
jboyer-isl |
That's good. I may see if I can get it working on our dev server tomorrow unless someone beats me to it. I'm out today in a couple mins. |
| 16:26 |
jeff |
it's an edit to fm_IDL.xml and some testing. :-) |
| 16:27 |
jboyer-isl |
Splendid. |
| 16:28 |
jboyer-isl |
thanks for talking it out, it would likely have taken me longer to find my mistake on my own. |
| 16:28 |
jboyer-isl |
jeff++ |
| 16:28 |
jeff |
jboyer-isl++ |
| 16:29 |
jeff |
always happy to turn frustration into bugfixes. |
| 16:36 |
rfrasur |
Is there a way to close for ALL the Sundays at one time? or do they have to be entered manually? |
| 16:38 |
Dyrcona |
rfrasur: hours of operation in the actor org unit editor, but your central site may have to do it. |
| 16:38 |
Dyrcona |
might need to run autogen.sh on the server afterward, too, but not sure. |
| 16:38 |
rfrasur |
hmm, probably. I don't think any of us have that kind of access. |
| 16:39 |
* rfrasur |
was just hoping for something a little easier in the staff client itself. |
| 16:39 |
Dyrcona |
rfrasur: It is in the staff client, but access to that is usually restricted. |
| 16:40 |
rfrasur |
gotcha. I try to not even pretend to click stuff in the server administration menu. I don't think I could break anything because of permissions... |
| 16:40 |
rfrasur |
But I've broken stuff thinking that before. |
| 16:42 |
Dyrcona |
maybe jboyer-isl can sneak it in for you before he goes home? |
| 16:42 |
rfrasur |
nah. ISL locks down like a vault at 4:30. |
| 16:43 |
Dyrcona |
oops. missed that he already left the channel. That's what I get for actually doing work. |
| 16:43 |
Dyrcona |
;) |
| 16:43 |
rfrasur |
it's cool. I'll hopefully remember to get 2014 ready before Dec. rolls around. Just picking at dumb stuff right now anyway. |
| 16:44 |
pinesol_green |
[evergreen|Dan Wells] Adding 0842, 0843 to help with 0841 deficiencies - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d4b3479> |
| 16:44 |
dbwells |
Apologies to all for the generall messiness of the 0841/0842/0843 upgrade chain. It turned out to be a complex backport, mostly because tables disappeared with each version. |
| 16:44 |
dbwells |
at least they are all short and simple |
| 16:49 |
eeevil |
dbwells++ |
| 16:51 |
* Dyrcona |
sings: "bshum on the run....bshum on the run...." |
| 16:51 |
rfrasur |
lol |
| 16:54 |
rfrasur |
alright...this Thursday hasn't been too traumatic, so I'm leaving before it turns on me. |
| 16:54 |
* rfrasur |
quit y'all be safe and happy and well fed unless you're fasting...then be really hungry |
| 16:54 |
* rfrasur |
really quits |
| 16:59 |
bshum |
Dyrcona: I really ran too. 30 gates or so away. |
| 17:00 |
bshum |
But of course the flight is now marked delayed too... so I can stop and breathe a moment. |
| 17:04 |
Dyrcona |
bshum: Headed to GSOC? |
| 17:06 |
jeff |
depesz++ |
| 17:06 |
depesz |
jeff: what did I do? |
| 17:07 |
jeff |
depesz: I was just reading your most recent post to open-ils-dev. |
| 17:07 |
depesz |
ah. :) |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
dbwells |
grabbing 0844 |
| 17:14 |
jeff |
depesz: is your switch from plperlu to plperl because plperlu would no longer be required since the triggers are no longer using "use" statments? |
| 17:14 |
jeff |
depesz: or is there another reason? |
| 17:15 |
bshum |
Drycona: Yeah, GSOC is the last leg of my trip up and down the west coast. |
| 17:16 |
bshum |
Course I spoke too soon, they moved us another 30 gates away. |
| 17:19 |
Dyrcona |
bshum on the run.... bshum on the run.... :) |
| 17:20 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 17:20 |
pinesol_green |
[evergreen|Dan Wells] Add new MODS <titleBrowse> to the default config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02368ab> |
| 17:20 |
pinesol_green |
[evergreen|Dan Wells] Upgrade script for better MODS browse and Name Subject facets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6211cbf> |
| 17:20 |
pinesol_green |
[evergreen|Dan Wells] Don't index browse extracts as search terms unless needed - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=844facb> |
| 17:20 |
pinesol_green |
[evergreen|Dan Wells] Add new functions and optional reingest to upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c70072> |
| 17:20 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0844: better MODS for browse, etc. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1ef503b> |
| 18:00 |
|
jecs left #evergreen |
| 18:01 |
phasefx |
wonder if we should just go negative with our stock id's :-) or move to natural keys |
| 22:37 |
|
RBecker joined #evergreen |
| 22:44 |
|
paxed joined #evergreen |
| 22:44 |
|
zxiiro joined #evergreen |
| 22:45 |
|
paxed joined #evergreen |
| 22:45 |
|
eeevil joined #evergreen |
| 22:45 |
|
fparks joined #evergreen |
| 22:47 |
|
tater joined #evergreen |
| 23:34 |
|
senator joined #evergreen |
| 23:34 |
|
remingtron joined #evergreen |
| 23:35 |
|
phasefx2 joined #evergreen |
| 23:35 |
|
timlaptop joined #evergreen |
