Evergreen ILS Website

IRC log for #evergreen, 2019-06-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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/u​ser/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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat