| Time |
Nick |
Message |
| 01:33 |
|
Mark__T joined #evergreen |
| 05:08 |
paxed |
i'm starting to hate how transient paste.evergreen-ils.org is. |
| 05:08 |
paxed |
losing the context when going through old irc logs. |
| 07:06 |
|
timlaptop joined #evergreen |
| 08:20 |
|
akilsdonk_ joined #evergreen |
| 08:20 |
|
bkuhn joined #evergreen |
| 08:23 |
|
mrpeters joined #evergreen |
| 08:47 |
paxed |
@roulette |
| 08:47 |
pinesol_green |
paxed: *click* |
| 09:14 |
jeff_ |
paxed: agreed with the pastebin transiency being an annoyance, regardless of the pastebin. one idea would be to capture the pastebin output in the irc logs somehow, though a first step might be to look into making the evergreen pastebin permanent, or have a permanent backing. |
| 09:20 |
bshum |
jeff_: It's some bug in the restart process where it keeps getting reset back to 10 every time the pastebot is reset. It's supposed to look as far ahead as we have pastes but it's some weird logic glitch that I have yet to track down. |
| 09:21 |
bshum |
We keep bringing it up but then there's other competing things that distract us ;) |
| 09:21 |
|
kmlussier joined #evergreen |
| 09:21 |
|
Dyrcona joined #evergreen |
| 09:25 |
kmlussier |
bshum++ # Experimenting with new logging bot |
| 09:45 |
|
BigRig joined #evergreen |
| 09:50 |
mrpeters |
is git.esilibrary.com down or just me? |
| 09:53 |
tsbere |
mrpeters: I am not getting a response. But I don't have anything cloned or remoted to there at this point, so I wouldn't have noticed if you hadn't said something. |
| 09:54 |
mrpeters |
cool...maybe someone from esi can look at it....trying to pull the migration tools |
| 10:03 |
|
rjackson-isl joined #evergreen |
| 10:16 |
kmlussier |
Was a bug report ever filed for the printing memory leak problem referenced in https://bugs.launchpad.net/evergreen/+bug/1086458/comments/38? |
| 10:16 |
pinesol_green |
Launchpad bug 1086458 in Evergreen "Staff client memory leaks in 2.3 and later" (affected: 6, heat: 44) [High,Fix committed] |
| 10:17 |
bshum |
kmlussier: I asked gmcharlt to do that whenever he and phasefx got further along in figuring out what the problem/solution was. He had mentioned working on it while we were at the conference. |
| 10:17 |
bshum |
To my recollection no, it has not been filed. |
| 10:17 |
gmcharlt |
correct |
| 10:17 |
* tsbere |
hates memory leaks >_> |
| 10:17 |
bshum |
(This was why I didn't close that particular bug ticket yet also, leaving it as fix committed and not released) |
| 10:22 |
|
yboston joined #evergreen |
| 10:22 |
|
ldwhalen joined #evergreen |
| 10:33 |
kmlussier |
tsbere: I don't think I've ever met anyone who likes memory leaks. :) |
| 10:34 |
kmlussier |
So it sounds like I should hold off on filing a bug report then until gmcharlt has more info, correct? |
| 10:34 |
gmcharlt |
kmlussier: yes, I'll file one with more details in a bit |
| 10:34 |
kmlussier |
gmcharlt: Thanks! |
| 10:40 |
berick |
hey, i bet people who sell RAM like memory leaks |
| 10:45 |
bshum |
tsbere++ # irclog help |
| 10:50 |
Dyrcona |
bshum: http://wiki.postgresql.org/wiki/VacuumHeadaches |
| 10:50 |
Dyrcona |
Looks like the thing you mentioned to me the other day is already there, though. |
| 10:50 |
bshum |
I'm sure it is. |
| 10:51 |
Dyrcona |
I believe "Long-Running Transactions" and/or "Batch Processing" cover it. |
| 10:52 |
Dyrcona |
No solutions there, just a page for the PostgreSQL devs to list problems that should be addresses with vacuum and analyze. |
| 11:01 |
dbs |
bshum: I was thinking that maybe it's finally time to just kill #openils-evergreen, rather than even bothering to log and advertise its continued existence? |
| 11:02 |
|
_zerick_ joined #evergreen |
| 11:02 |
dbs |
but on the whole, bravo for your work! |
| 11:05 |
jeff_ |
bshum++ |
| 11:08 |
|
zerick joined #evergreen |
| 11:24 |
|
b_bonner joined #evergreen |
| 11:25 |
moodaepo |
bshum++ |
| 11:25 |
moodaepo |
tsbere++ |
| 11:27 |
Dyrcona |
++++ |
| 11:27 |
Dyrcona |
Whee! |
| 11:34 |
b_bonner |
Question: I've been tasked with changing a bunch of marc records (~50K) in our evergreen system. the biblio.record_entry marc field contains "<datafield tag="856" ind1="4" ind2=" ">", I need to change the second indicator to a zero ("<datafield tag="856" ind1="4" ind2="0">). If I try a simple sql replace I often get an error of ERROR: index row size 4496 exceeds maximum 2712 for index |
| 11:34 |
b_bonner |
"browse_entry_value_key". Is there a better way to go about making this change? Or work around the errors? |
| 11:34 |
pastebot |
"b_bonner" at 204.193.129.146 pasted "full text of sql and error here" (13 lines) at http://paste.evergreen-ils.org/10 |
| 11:35 |
|
tspindler joined #evergreen |
| 11:37 |
|
kmlussier joined #evergreen |
| 11:51 |
|
dboyle joined #evergreen |
| 11:53 |
tsbere |
b_bonner: Dunno if it has anything to do with your error.....but why the subselect? The where and limit clauses should, in theory, work on the update statement directly |
| 11:53 |
|
jdouma joined #evergreen |
| 11:56 |
b_bonner |
tsbere: subselect was just wanting to limit the query to the bib id's that actually have this 856 condition and the limit was just a remnant of me doing smaller scale tests. |
| 11:57 |
jeff_ |
b_bonner: sounds like your error is related to an existing issue with one or more bibs. doing a straight-up reingest of the bib without changing a thing in the marc record would likely trigger the same error. |
| 11:57 |
tsbere |
b_bonner: The where clause checking position would work on the update statement itself to do the same limit, though |
| 11:58 |
jeff_ |
b_bonner: you could add RAISE DEBUG statements (or their perl equiv) to the relevant functions in the db to surface the ID of the record(s) causing the issue. |
| 12:00 |
jeff_ |
I wonder if we should a) add some RAISE DEBUG statements to the stock functions, so that seeing them is as simple as turning up {client|log}_min_messages, and/or b) add some error handling around some common issues with RAISE WARNING or similar |
| 12:02 |
jeff_ |
gmcharlt++ for quick bug feedback |
| 12:06 |
gmcharlt |
jeff++ # going after zombie code |
| 12:06 |
jeff_ |
# DON'T DEAD |
| 12:06 |
jeff_ |
# OPEN INSIDE |
| 12:11 |
|
mcooper joined #evergreen |
| 12:14 |
phasefx |
the walking code |
| 12:14 |
phasefx |
shambling mound |
| 12:14 |
eeevil |
jeff_: RAISE used to confuse dbd::pg ... unsure about cstore and friends |
| 12:14 |
paxed |
*grmbl* how do i access YAOUS in, say, patron summary.js which doesn't use dojo? |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:15 |
phasefx |
paxed: is OpenILS.data getting used in there? |
| 12:16 |
paxed |
yes |
| 12:16 |
paxed |
ah, i see |
| 12:16 |
phasefx |
obj.OpenILS.data.hash.aous['circ.obscure_dob'] is an example |
| 12:16 |
paxed |
yeah, just noticed that |
| 12:16 |
phasefx |
gathered at login time |
| 12:18 |
b_bonner |
jeff_ tsbere: sorry for delay getting back to this. I'll attempt to figure out which ID's are throwing the errors. Does this mean that these ids probably aren't indexed properly now? |
| 12:19 |
jeff_ |
eeevil: thanks. in that case, it would be good to test the effective client_min_messages for DBI, and ensure that whatever chosen could be logged without tripping up dbd::pg. |
| 12:19 |
eeevil |
b_bonner: it might mean that your update isn't doing what you expect. or it might mean that you've changed settings on some index defs |
| 12:20 |
eeevil |
jeff_: of course, it might be fine today. I ran into that long ago |
| 12:20 |
jeff_ |
eeevil: good to know that it might be an issue, even if it turns out not to be. |
| 12:24 |
b_bonner |
eeevil: Do you have any guidance about to otherwise change the marc indicators in batch as I described above? |
| 12:28 |
eeevil |
b_bonner: first thing is to find out what in one of the offending records is trying to write a browse entry that's 4.4k long. something on config.metabib_field has browse_field set to true, and either it shouldn't or you need to add an index normalizer to shorten the browse strings to, say, 1k (there's not much point in having huge browse strings) |
| 12:29 |
eeevil |
b_bonner: but the query looks ok. you could make it faster by looking at metabib.full_rec instead of the position() against the marcxml |
| 12:31 |
b_bonner |
eeevil: the end result here is that we need the marcxml to actually be correct, changing it in the full_rec doesn't change the marcxml. |
| 12:32 |
eeevil |
b_bonner: no, just use metabib.full_rec to find the records |
| 12:32 |
jeff_ |
b_bonner: but you can use full_rec to find the records to change. |
| 12:32 |
* jeff_ |
nods |
| 12:32 |
b_bonner |
jeff_ eeevil: oh, sure. position wasn't that bad actually. |
| 12:34 |
bshum |
Testing logger: i’m |
| 12:40 |
jeff_ |
@later tell berick i'm interested in your thoughts on bug 1187035 removing OpenILS::Utils::Editor -- you're the usual author on Editor/CStoreEditor |
| 12:40 |
pinesol_green |
jeff_: The operation succeeded. |
| 12:40 |
jeff_ |
bug 1187035 |
| 12:40 |
pinesol_green |
Launchpad bug 1187035 in Evergreen "Remove obsolete OpenILS::Utils::Editor" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1187035 |
| 12:40 |
jeff_ |
ah. no parsing of @ commands for bugs. makes sense. |
| 12:42 |
jeff_ |
@later tell berick also, bug 1187034 on removing a collections api method |
| 12:42 |
pinesol_green |
jeff_: The operation succeeded. |
| 12:46 |
berick |
jeff_: commenting.. |
| 12:46 |
jeff_ |
berick++ |
| 12:47 |
* bshum |
shakes fist at atz for having latin1 characters in his lines for our IRC logs |
| 12:48 |
* bshum |
grumbles and refocuses. |
| 12:51 |
berick |
jeff_++ |
| 12:51 |
berick |
cleaning house |
| 12:51 |
* berick |
may be able to sign-off on one or two of those, but not until later in the week |
| 12:54 |
dbs |
bshum: touché |
| 12:55 |
bshum |
dbs: I think the problem is the really old logs. Before we started paying more attention to fixing problems like that with the logger. |
| 12:56 |
bshum |
This current channellogger plugin was fixed more recently and the new ilbot doesn't seem to mind. |
| 12:57 |
dbs |
Like old MARC. Neither ages well :) |
| 12:58 |
gmcharlt |
dbs: I *like* vinegar! |
| 12:58 |
gmcharlt |
(not really) |
| 13:00 |
jeff_ |
two of those bugs were the outcome of "what is the difference between these two things..." resulting in "oh, this one should go away!" |
| 13:03 |
jeff_ |
umm. search.cpan.org lacks a search box for me today. wonder how long that's been that way. |
| 13:04 |
berick |
gettin' a box here |
| 13:04 |
jeff_ |
and it's back. |
| 13:06 |
jeff_ |
intermittent. glitch in the CPAN. happens when they change something. |
| 13:07 |
|
mllewellyn joined #evergreen |
| 13:07 |
gmcharlt |
jeff_: it's been more glitchy for me than normal the past few days |
| 13:27 |
bshum |
Hmm |
| 13:40 |
|
kyleonalaptop joined #evergreen |
| 13:45 |
|
bmills joined #evergreen |
| 14:01 |
|
ldwhalen joined #evergreen |
| 14:02 |
|
acoomes joined #evergreen |
| 14:29 |
|
mtcarlson joined #evergreen |
| 15:02 |
|
moodaepo_nb joined #evergreen |
| 15:03 |
|
Ruth joined #evergreen |
| 15:05 |
|
mjingle joined #evergreen |
| 15:27 |
bshum |
Just a word of caution |
| 15:27 |
|
tfaile joined #evergreen |
| 15:28 |
rfrasur |
Not Evergreen related, but I just realized there are people out there building websites for libraries (and charging for them) that have absolutely no clue what a library website should do and have absolutely no aesthetic talent. |
| 15:28 |
bshum |
Apparently ilbot has a bug in it and the [off] the record feature is not working. |
| 15:28 |
bshum |
I just filed a bug against the github: https://github.com/moritz/ilbot/issues/17 |
| 15:28 |
* rfrasur |
logs stupid stuff all the time anyway. |
| 15:28 |
rfrasur |
but, good to know bshum |
| 15:28 |
bshum |
pinesol's channellogger will skip things with [off], but the new bot is watching everything you say! |
| 15:28 |
bshum |
:D |
| 15:28 |
rfrasur |
yep |
| 15:28 |
bshum |
Hopefully get that resolved quickly enough. |
| 15:29 |
rfrasur |
well, in my case, it holds me accountable to not swear...so the longer it's broken the better. |
| 15:29 |
Dyrcona |
bshum: clone the repo and patch it. |
| 15:29 |
bshum |
Dyrcona: I'll work on that right after I finish figuring out the quirks with trying to get our old irc logs migrated to the new database. |
| 15:30 |
bshum |
Right now I'm trying to find a good way of marking delimiters between columns of data. |
| 15:30 |
bshum |
Seems every one I've tried so far has been employed in the channel at some point or another. |
| 15:31 |
bshum |
I'll figure it out soon enough. |
| 15:33 |
rfrasur |
(this automated menu is the best. If you want to do this...press 1. If you want to THIS....press 3. If you want to that...press 6) |
| 15:41 |
|
serflog joined #evergreen |
| 15:41 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 15:41 |
|
serflog joined #evergreen |
| 15:41 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 15:42 |
rfrasur |
did it work? |
| 15:42 |
bshum |
Appears to have worked :) |
| 15:42 |
rfrasur |
yep it did |
| 15:42 |
rfrasur |
good job :D |
| 15:42 |
rfrasur |
bshum++ |
| 15:43 |
bshum |
moritz (the creator) whipped up a quick fix. I asked him about it in #ilbot |
| 15:43 |
rfrasur |
and it's good that there's still a marker saying there was a message. |
| 15:43 |
bshum |
And they were kind enough to help. |
| 15:43 |
bshum |
rfrasur: Oh that's the old logs actually. We're working on brand new logs :P |
| 15:43 |
|
ericar joined #evergreen |
| 15:43 |
rfrasur |
that's right...the searchable ones. |
| 15:44 |
* rfrasur |
read the email. |
| 15:44 |
bshum |
They're prettier looking too. In my mind's eye. |
| 15:44 |
rfrasur |
well, it'd take real work to be uglier. |
| 15:46 |
rfrasur |
though ugly isn't necessarily the right word. They're basic right now. |
| 15:52 |
|
mjingle1 joined #evergreen |
| 15:55 |
|
rjackson-isl joined #evergreen |
| 16:02 |
|
mtcarlson joined #evergreen |
| 16:02 |
|
acoomes joined #evergreen |
| 16:07 |
|
dboyle joined #evergreen |
| 16:17 |
|
kyleonalaptop joined #evergreen |
| 16:34 |
|
tspindler left #evergreen |
| 16:43 |
mrpeters |
what are the proper "units" for Processing Delay in action triggers? |
| 16:43 |
tsbere |
interval type in the DB.... |
| 16:43 |
mrpeters |
days, weeks, years? |
| 16:43 |
tsbere |
so I guess no units is seconds |
| 16:43 |
tsbere |
Clarify anything else how you want to |
| 16:43 |
mrpeters |
i'm peeking at one for csharp and he has "mons" |
| 16:43 |
tsbere |
'5 minutes', '3 years', '6 hours' should, in theory, all be valid |
| 16:44 |
mrpeters |
but is "mons" valid? or shall it be "months" |
| 16:44 |
tsbere |
mrpeters: The backend datatype is "interval", not "string". If it is stored in the DB, the value you got out is acceptable. |
| 16:52 |
jeff_ |
mrpeters: for postgresql 9.2, the following attempts to document the valid inputs: http://www.postgresql.org/docs/9.2/interactive/datatype-datetime.html#DATATYPE-INTERVAL-INPUT |
| 16:52 |
jeff_ |
mrpeters: you'll note that "mons" is not explicitly listed there, but probably falls under "abbreviations or plurals of these units" |
| 16:52 |
mrpeters |
thanks, was looking for something like that |
| 16:52 |
mrpeters |
jeff_++ |
| 16:53 |
* tsbere |
points out that the output examples use mons |
| 17:43 |
|
mtcarlson joined #evergreen |
| 17:44 |
|
mrpeters left #evergreen |
| 17:45 |
|
mjingle joined #evergreen |
| 17:51 |
|
mtcarlson joined #evergreen |
| 17:58 |
|
mjingle joined #evergreen |
| 17:59 |
pinesol_green |
[evergreen|Bill Erickson] LP1183340 selectivly apply editable funds sorting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed8cb32> |
| 18:09 |
|
Hagerstown_Staff joined #evergreen |
| 18:47 |
|
mtcarlson joined #evergreen |
| 18:54 |
|
_robbat2|irssi joined #evergreen |
| 19:56 |
|
mjingle left #evergreen |
| 20:19 |
|
aj_ joined #evergreen |
| 22:38 |
|
mtcarlson joined #evergreen |
| 23:10 |
|
mjingle joined #evergreen |
