| Time |
Nick |
Message |
| 04:27 |
|
jamesrf joined #evergreen |
| 05:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:51 |
|
collum joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:48 |
mmorgan |
@coffee [someone] |
| 08:48 |
* pinesol |
brews and pours a cup of Ethiopia Awassa Special, and sends it sliding down the bar to csharp |
| 08:48 |
mmorgan |
@tea [someone] |
| 08:48 |
* pinesol |
brews and pours a pot of Wild Snow Sprout Tea, and sends it sliding down the bar to gsams__ (http://ratetea.com/tea/wild-tea-qi/wild-snow-sprout-tea/6447/) |
| 08:48 |
mmorgan |
@praise [someone] |
| 08:48 |
* pinesol |
I come to praise jamesrf, not to bury them. |
| 08:53 |
|
mdriscoll joined #evergreen |
| 08:54 |
rhamby |
for ( i = 0; i < 10000000, i++ ) { pourCoffeeDownThroat; } |
| 08:55 |
mmorgan |
:) |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:05 |
|
bos20k joined #evergreen |
| 09:06 |
remingtron |
rhamby: due to a syntax error, your loop condition is always true. Infinite coffee! |
| 09:06 |
JBoyer |
remingtron++ |
| 09:08 |
|
sandbergja joined #evergreen |
| 09:11 |
rhamby |
remingtron++ that is acceptable |
| 09:11 |
|
nfBurton joined #evergreen |
| 09:11 |
Dyrcona |
Er, no, but it is funnier than the reality. rhamby++ remingtron++ |
| 09:12 |
* rhamby |
suspects that would just throw an error but doesn't care enough to check |
| 09:15 |
Dyrcona |
In Perl, you get something like can't modify scalar in constant context. I've made that typo before. |
| 09:17 |
JBoyer |
So no coffee? (╯°□°)╯︵ ┻━┻ |
| 09:18 |
Dyrcona |
Instead, you blow up the coffee pot. :) |
| 09:19 |
JBoyer |
I've had those mornings. |
| 09:33 |
|
aabbee joined #evergreen |
| 09:35 |
Dyrcona |
JBoyer: You run the autorenew event in production? |
| 09:36 |
JBoyer |
Many of them, yes. |
| 09:36 |
Dyrcona |
Have you noticed it taking a long time? It's taking over 6 hours to do about 20,000 on our training system. |
| 09:37 |
|
yboston joined #evergreen |
| 09:40 |
JBoyer |
I know it's the reason I finally started using parallel event processing, but I haven't timed it properly in a while. |
| 09:40 |
JBoyer |
I |
| 09:40 |
Dyrcona |
The a/t runner also seems to leave some behind in pending and reacting states. |
| 09:40 |
Dyrcona |
I'm using parallel of 3. |
| 09:40 |
JBoyer |
'm looking at today's run to see where things landed. |
| 09:43 |
JBoyer |
Oops. don't want to see all 270K... |
| 09:46 |
Dyrcona |
heh. |
| 09:47 |
Dyrcona |
I'm truncating the output and event tables to have clean data for tomorrow's run. |
| 09:47 |
JBoyer |
So today there were 7831 autorenewals across 64 systems and it took less than 3 hours to process them all. |
| 09:47 |
JBoyer |
That's not blazing speed at all, but the notifications don't go out until after 8 so it's not a problem. |
| 09:48 |
Dyrcona |
That's too long, but sounds about right for A/T. |
| 09:48 |
JBoyer |
We're also only running 3 parallel collectors and reactors. |
| 09:49 |
Dyrcona |
So, I suppose 6 hours for 19 to 20 thousand is not bad. |
| 09:49 |
JBoyer |
I don't know about right, but it sounds consistent. |
| 09:51 |
Dyrcona |
Well, that's what I meant by "right" with a small dose of sarcasm. |
| 09:53 |
JBoyer |
That was me taking myself down a tangent before actually doing the typing. I had initially written "that sounds right" and then decided to change it. :) |
| 09:55 |
Dyrcona |
:) |
| 09:59 |
|
Christineb joined #evergreen |
| 10:02 |
|
bos20k_ joined #evergreen |
| 10:23 |
pinesol |
[evergreen|Sam Link] LP#1796914: Right Navbar Menu Title - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=59d80af> |
| 10:48 |
|
khuckins joined #evergreen |
| 12:02 |
|
sandbergja joined #evergreen |
| 12:11 |
Bmagic |
anyone have ideas on how an invoice would successfully connect back to lineitem_detail for the majority of the invoice items but miss filling in fund_debit for some? |
| 12:11 |
pinesol |
[evergreen|Galen Charlton] LP#1812900: fix retention of saved defaults in holdings editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5c49146> |
| 12:13 |
berick |
Bmagic: by 'filling in fund_debit' to you mean marking the debit as encumbrance=false or creating the debit? |
| 12:13 |
Bmagic |
creating the debit |
| 12:13 |
berick |
the debits are created at PO activation time |
| 12:13 |
Bmagic |
oh |
| 12:13 |
berick |
if they're not already there, the invoice won't create them |
| 12:14 |
Bmagic |
somehow they weren't created at activation time then |
| 12:14 |
Bmagic |
select * from acq.lineitem_detail where lineitem in(select lineitem from acq.invoice_entry where invoice in(select id from acq.invoice where inv_ident='2033393129')) |
| 12:14 |
Bmagic |
lots of fund_debit ID's with some missing |
| 12:15 |
berick |
any chance some of the li details were canceled? |
| 12:15 |
Bmagic |
cancel_reason null |
| 12:16 |
Bmagic |
in this example, there are 22 lineitem_detail rows without a fund_debit. None of them have a cancel_reason |
| 12:17 |
berick |
copies added to an order after PO activation? |
| 12:17 |
Bmagic |
that's one idea, however, I don't know how to prove it |
| 12:18 |
berick |
yeah, no create time on li detail, unfortunately. |
| 12:18 |
berick |
probably have to scan the logs |
| 12:18 |
Bmagic |
yeah, this stuff was activated 2 years ago |
| 12:19 |
Bmagic |
well, thanks for the info. I am a bit more educated now. |
| 12:19 |
Bmagic |
I guess I will have to insert the rows to fix? |
| 12:22 |
Bmagic |
does the interface allow you to add more stuff to the PO after it was activated? |
| 12:23 |
berick |
i think it might |
| 12:24 |
Bmagic |
it's getting angularized soon? |
| 12:27 |
Dyrcona |
RE adding things after a PO has been activated: The interface probably shouldn't allow that. |
| 12:27 |
Bmagic |
Dyrcona: that's where I was going but if it's getting re-written..... |
| 12:31 |
|
yboston joined #evergreen |
| 12:35 |
|
jihpringle joined #evergreen |
| 12:35 |
|
Dyrcona joined #evergreen |
| 12:39 |
Dyrcona |
@blame Ubuntu 19.04 |
| 12:39 |
pinesol |
Dyrcona: Your failure is now complete, Ubuntu 19.04. |
| 13:23 |
JBoyer |
timezones-- |
| 13:25 |
JBoyer |
I don't suppose anyone remembers offhand anything time related going in to either Eg or Osrf in the last month or two? |
| 13:26 |
JBoyer |
I'll be looking, but something somewhere is not talking. (38 systems have items due 7/4 even though everyone has a closed date that day.) |
| 13:28 |
Dyrcona |
Manual due date? |
| 13:30 |
JBoyer |
I'm starting to wonder. We're now up to 39 systems and it's not timezone related, because most of them are in Eastern. :/ |
| 13:31 |
JBoyer |
That seems like a lot of people making a very obvious mistake though. |
| 13:34 |
|
sandbergja_ joined #evergreen |
| 13:37 |
JBoyer |
Uh, the logs would indicate that if you give enough people a web client some number of them will in fact choose to force things due on 7/4. No word on their progress recreating the manuscript to Hamlet. |
| 13:43 |
|
yboston joined #evergreen |
| 13:43 |
JBoyer |
Oh, maybe not. Looks like that perm is checked whether you change it or not. I do feel better about that now. |
| 13:48 |
|
remingtron joined #evergreen |
| 13:50 |
|
yar joined #evergreen |
| 13:58 |
pinesol |
[evergreen|Galen Charlton] LP#1831786: add demo of cross-tab communications - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c6b4d1f> |
| 13:58 |
pinesol |
[evergreen|Jane Sandberg] LP#1831786 (follow-up): release note for cross-tab communication demo - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f1e35fe> |
| 15:04 |
|
mmorgan1 joined #evergreen |
| 15:18 |
|
khuckins joined #evergreen |
| 15:30 |
|
Khaun joined #evergreen |
| 15:38 |
Dyrcona |
jeff: While you're looking at ahopl, maybe you could add preferred names to it, too? ;) |
| 15:39 |
jeff |
possibly! |
| 15:43 |
|
yar joined #evergreen |
| 16:04 |
Dyrcona |
Hmm... Anyone know any good tricks for getting the original size of a gzip'd file? |
| 16:04 |
Dyrcona |
I'm trying to avoid writing something complicated in Perl. |
| 16:07 |
Dyrcona |
Something like this looks like my best bet, but now I'm heading into scripting territory: gzip -dc gateway.00.log.gz | wc |
| 16:12 |
|
nfBurton joined #evergreen |
| 16:17 |
nfBurton |
Hey all. I am doing a full Development Server installation and have everything working, except the JS directory is barking at me about blocking a cross-origin frame. Is there something I may have missed to clear this up? Only shows while searching the OPAC and blocks the frame |
| 16:19 |
jeff |
Dyrcona: gzip -l is likely helpful to you |
| 16:20 |
Dyrcona |
jeff: Thanks, but I'm leaning towards using all the first and last fields from the wc output. |
| 16:21 |
Dyrcona |
I started to type "all the fields" and realized I really only care about lines and bytes. Number of words is not so interesting. |
| 16:21 |
jeff |
Dyrcona: gzip -l has the advantage of using the gzip file header to get the size, which doesn't then require decompression of the entire stream. |
| 16:21 |
Dyrcona |
Well... |
| 16:22 |
jeff |
if you just want the uncompressed size, gzip -l messages.1.gz | tail --lines=+2 | awk '{print $2}' |
| 16:23 |
jeff |
and if you want to compare them, then... do both? :-) |
| 16:23 |
jeff |
"gzip -dc messages.1.gz | wc -c" and the above gzip -l | tail | awk match on the sample file I tested with. |
| 16:24 |
jeff |
one takes longer and decompresses the file to wc, the other does not. |
| 16:25 |
|
mmorgan joined #evergreen |
| 16:25 |
Dyrcona |
jeff: Yes. I'll try this because maybe I don't care about numbers of lines, either: gzip -l --quiet gateway.00.log.gz | awk ' {print $2}' |
| 16:26 |
jeff |
ah, nice use of --quiet in place of tail. |
| 16:26 |
Dyrcona |
But, I'll likely end up with something more complicated and it could very well end up being written in Perl. |
| 16:26 |
jeff |
what are you trying to do? |
| 16:27 |
Dyrcona |
I intend to use the size of our gateway logs as a round indication of server busyness. I'm going to go back to January, and our older logs get compressed after a week or so. |
| 16:28 |
Dyrcona |
s/round/rough/ |
| 16:28 |
Dyrcona |
We've had complaints of slowness this week, and I want to see if we're busier than "normal." |
| 16:29 |
Dyrcona |
I'd go back to last June for a more fair comparison, but we don't have logs that old. |
| 16:30 |
jeff |
ah. if you're looking to sum the uncompressed size of the gz files in a dir, something like this: |
| 16:30 |
jeff |
find . -maxdepth 1 -type f -name \*.gz -print0 | xargs --null gzip -l --quiet | awk '{c+=$1} END {print c}' |
| 16:30 |
jeff |
sum of values in first column |
| 16:30 |
Dyrcona |
nah. Our logs are rotated hourly, and I'm fine with that level of granularity. The complaints are mostly for 1 to 5 pm. |
| 16:30 |
jeff |
you want the second column, though. :-) |
| 16:31 |
jeff |
heh, and awk will happily give you something like 4.03933e+09 for output. |
| 16:31 |
Dyrcona |
I'm thinking of producing a csv with date,hour,size. |
| 16:31 |
Dyrcona |
Then I can sort on any of the factors. |
| 16:32 |
Dyrcona |
jeff++ for suggestions. |
| 16:32 |
|
nfBurton joined #evergreen |
| 16:32 |
jeff |
find . -maxdepth 1 -type f -name \*.gz -print0 | xargs --null gzip -l --quiet | awk '{c+=$2} END {printf "%i\n", c}' |
| 16:33 |
jeff |
(revised to correct column and use printf to avoid 4.03933e+09 |
| 16:33 |
jeff |
) |
| 16:33 |
Dyrcona |
Yeah, but they aren't all gzip'd. I think I may just pipe the output of ls -R to an awk script. |
| 16:38 |
|
yboston joined #evergreen |
| 16:42 |
mmorgan |
Web client question - would clearing (only) cached images and files for all time break offline circulation? |
| 16:45 |
berick |
mmorgan: seems likely, yes, at least until you log back into the web client after clearing files. |
| 16:47 |
mmorgan |
berick: Thanks. Is there a good rule of thumb for the time period to choose when clearing the cache? |
| 16:48 |
mmorgan |
Seems like we need to clear cache a fair amount in the web clietn. |
| 16:48 |
miker |
mmorgan: yes, insofar as the upup offline service worker uses the browser cache to retain files, I'm pretty sure |
| 16:48 |
mmorgan |
er, client |
| 16:49 |
miker |
mmorgan: hrm... I'm wrong. it uses internal cache storage that /should/ be separate |
| 16:50 |
miker |
mmorgan: so, you should be ok for offline clearing files and images |
| 16:50 |
miker |
(and you'd be fine after the next online page load anyway) |
| 16:51 |
berick |
miker: ah, good to know |
| 16:53 |
mmorgan |
Ok, that helps. Seems like after an upgrade, clearing files and images for all time is necessary. I'd like to just put that out as a general rule whenever cache clearing is necessary. |
| 16:53 |
sandbergja |
Grabbing 1167 |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
sandbergja |
Core committers: this is my first time stamping an upgrade. Could somebody please give this a once over before I add to master and the release branches? |
| 17:02 |
sandbergja |
I've got my work here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1759343_sticky_annotate |
| 17:03 |
sandbergja |
(by which I mean JBoyer's work) |
| 17:03 |
sandbergja |
(but my upgrade stamping :-)) |
| 17:04 |
bshum |
sandbergja: Taking a quick look over now |
| 17:05 |
sandbergja |
Thanks, bshum! |
| 17:05 |
bshum |
Looks fine to me, the stamping commit |
| 17:06 |
sandbergja |
Thanks for taking a look! |
| 17:06 |
mmorgan |
sandbergja++ |
| 17:06 |
sandbergja |
bshum++ |
| 17:06 |
mmorgan |
bshum++ |
| 17:06 |
bshum |
You might have some interesting interactions with backporting when you go to do that |
| 17:06 |
bshum |
Cause there might be commit conflicts to resolve if the older branches are not up to latest 1166 in them |
| 17:06 |
bshum |
But it's a minor conflict resolution |
| 17:07 |
|
mdriscoll left #evergreen |
| 17:08 |
bshum |
sandbergja++ |
| 17:08 |
bshum |
Time to head home for me. I'll watch for the results of your commits later ;) |
| 17:09 |
berick |
go_team++ |
| 17:10 |
|
mmorgan left #evergreen |
| 17:56 |
pinesol |
[evergreen|Jason Boyer] LP1759343: Bills Annotation Persistance - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b727b50> |
| 17:56 |
pinesol |
[evergreen|Jane Sandberg] LP1759343 (follow-up): Add bill annotation setting to seed data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5e4261e> |
| 17:56 |
pinesol |
[evergreen|Jane Sandberg] LP1759343: Stamping upgrade: annotate payment setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3afd523> |
| 18:03 |
|
yar joined #evergreen |
| 19:05 |
|
sandbergja_ joined #evergreen |
| 21:14 |
|
yar joined #evergreen |
| 21:37 |
|
Dyrcona joined #evergreen |
| 23:38 |
|
Glen joined #evergreen |
| 23:38 |
|
remingtron joined #evergreen |
| 23:38 |
|
bshum joined #evergreen |
| 23:38 |
|
dbwells joined #evergreen |
| 23:38 |
|
csharp joined #evergreen |
