Evergreen ILS Website

IRC log for #evergreen, 2019-05-23

| 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
00:42 jamesrf joined #evergreen
01:08 sandbergja joined #evergreen
01:53 jamesrf joined #evergreen
01:58 sandbergja joined #evergreen
03:27 jamesrf joined #evergreen
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:03 agoben joined #evergreen
07:07 rjackson_isl joined #evergreen
07:17 JBoyer joined #evergreen
08:04 _bott_ joined #evergreen
08:07 collum joined #evergreen
08:40 Dyrcona joined #evergreen
08:45 mmorgan joined #evergreen
08:51 mdriscoll joined #evergreen
09:02 aabbee joined #evergreen
09:09 yboston joined #evergreen
09:17 terran joined #evergreen
09:36 bos20k joined #evergreen
10:16 khaun joined #evergreen
10:22 jamesrf joined #evergreen
10:29 sandbergja joined #evergreen
10:30 * berick chuckles at PG stemming "puppies" to "puppi"
10:33 JBoyer oui, oui, mon puppi.
10:36 berick :)
10:37 mmorgan Fun with stemming!!
10:40 khuckins joined #evergreen
10:46 sandbergja joined #evergreen
10:53 bos20k_ joined #evergreen
10:53 gmcharlt dbwells: are you actively working on bug 1704819?
10:53 pinesol Launchpad bug 1704819 in Evergreen 3.2 "Fine generator can generate overdue fines beyond max-fine amount (rounding error)" [Medium,Confirmed] https://launchpad.net/bugs/1704819
10:59 mmorgan1 joined #evergreen
11:05 dbwells gmcharlt: I think I assigned myself there during the final push for 3.1.  I got sidetracked during that review by the two places where it checks "if $xyz * 100 == 0", because why would we multiply a number by 100 just to check whether it was 0 to begin with?  If that sounds like a crazy thing to care about, please feel free to push it in.  OTOH, if it at all fries your circuits like it does mine, I'd be happy to either whip up or sign-off on a foll
11:05 dbwells ow-up patch to get rid of those :)
11:07 gmcharlt dbwells: I don't feel strongly about it, but I do think the "* 100" bit there has a value as a a "danger will robinson! danger! floating point math here!" signal
11:08 berick fwiw, the x*100==0 struck me as odd too, but since they were already there, I just left them
11:09 terran I got behind on the bug squashing tracking sheet yesterday due to having to get my eyes dilated, but it's up to date now: https://docs.google.com/spreadsheets/d/1oxM5dA2​FqPhUD81IIhnsoTuVkbfB2VoYTBKfhGMPwjk/edit#gid=0
11:09 terran bugsquashers++
11:09 berick terran: bug squashing will do that to a person
11:10 terran lol
11:12 dbwells Well, if we get rid of the "* 100", we aren't doing any math there anymore :)  It's fine, really.  I've felt too silly caring about it to bring it up, and now I feel silly having brought it up, but at least I've said my peace :)  I'll just unassign myself, but feel free it pass it back if it needs another sign-off.  As far as I have tested, it works fine.
11:15 Dyrcona If x is a floating point number maybe we want x == 0.0 ?
11:16 Dyrcona I can't remember if the decimal really matters in Perl. In some languages the floating number will be silently cast to int if compared to an int.
11:17 dbwells berick: I certainly can appreciate the idea of not changing more than needed in this case, being on the edges of FP-voodoo land.  Just back away slowly, don't bump anything.
11:19 berick dbwells: exactly... in and out like a robbery
11:21 * Dyrcona makes the bold move of editing the system crontab....
11:21 Dyrcona Hrm... No. Better idea: add something to /etc/cron.weekly/
11:22 * dbwells shudders to think that a floating point representation of 0 would not be reliable
11:23 gmcharlt yet another option would be using the fpsum utility function that Dyrcona added ages ago
11:23 gmcharlt HOWEVER
11:23 gmcharlt since this patch has been in production as is for a while, I'm inclined to push it as is
11:23 gmcharlt then walk away slowly
11:24 gmcharlt then once I'm a hundred yards away
11:24 gmcharlt RUN
11:24 Dyrcona My comment about float being cast to int had more to do with 0.64 == 0 in some languages.
11:24 berick heh
11:24 berick gmcharlt: well you (obviously) have my support
11:24 Dyrcona Not so much relying on the value of float 0.
11:25 Dyrcona Not sure that I can take full credit for fpsum, I think someone (dbwells?) added the fpdiff function, first.
11:27 Dyrcona And, no, I need to modify /etc/crontab because /etc/cron.weekly jobs go through run-parts and are all run as root. I want my new cronjob to run as opensrf, but I don't want it in opensrf's crontab, because I want it to be separate from those for reasons.
11:27 Dyrcona :/
11:27 dbwells gmcharlt++
11:30 pinesol [evergreen|Bill Erickson] LP#1704819 Fine generator avoids int() rounding - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=297fedb>
11:40 Dyrcona gmcharlt++ berick++
11:41 Dyrcona And, my script to shut down opensrf services and remove the opensrf user's crontab works from cron. I'm doing this on a test VM where I refresh the database weekly. Don't want the database being used to prevent the reload.
11:42 aabbee floats are the worst. as the bug notes, int(100*2.30) is 229. testing "near enough" can be done: perl -e 'my $c = ((100*2.30) - 230); print(($c==0?'zero':'nonzero'), ", ", (abs($c)<(10**-10)?'near':'nope'), "\n");' # says "nonzero, near'
11:43 aabbee or force rounding to behave: int((100*2.30)+.5) ==> 230.
11:44 Dyrcona Oddly enough, computers are bad at math. :)
11:44 aabbee idk if the zeros here are "real" zeros or if they are be calculated like $c was above, so unsure if this applies here
11:44 * Dyrcona decides on a new file in /etc/cron.d rather than junking up /etc/crontab.
11:49 JBoyer A common thing to do when regularly working with floats is to have an fp_eq(a, b) that is basically just  { return (a - b) <= very_small_value; } because floating point math is hard. The * 100 stuff allows perl to decide to round *pretty much* however it likes without getting too many false positives.
11:49 JBoyer (I dabbled with 3D graphics Back In The Day so I've got no love for floats.(
11:51 JBoyer re: the prett much part: *100 is basically doing (a - b) <= .001
11:56 Dyrcona I figure we ought just handle money as ints in pennies, but that doesn't work for monetary systems that use fractions smaller than 1/100.
11:56 * Dyrcona wonders how the bitcoin devs deal with it. Bitcoins are divisible to 8 decimal places.
11:57 Dyrcona Bitcoin is C++ code, though, so they probably use some high precision library.
11:57 JBoyer probably using one of the "infinite precision" libraries that are around. When cryptography is the backbone of the thing using one of those for the money aspect won't affect the overall speed much.
11:57 * Dyrcona should check it out again and have a look.
11:58 Dyrcona yeahp
11:58 * JBoyer should look up what currencies deal in < .01
11:59 * Dyrcona contributed a small patch to monero. They require the commits be cryptographically signed.
12:00 JBoyer Because the closest Eg is ever going to come to using bitcoin is the ridiculous example I gave in that money doc; if that's all we could conceivably move to fixed precision and never have to worry about rounding again.
12:00 Dyrcona Well, you never know. There's talk of a "FedCoin" and similar things going on.
12:01 aabbee fixed point to avoid rounding errors is generally preferred. https://stackoverflow.com/questions/3730019/why​-not-use-double-or-float-to-represent-currency
12:01 aabbee something like https://perldoc.perl.org/Locale/Currency.html might be helpful.
12:02 aabbee sorry that's for identification, not precision.
12:02 aabbee https://metacpan.org/pod/Math::Currency that one's for precision.
12:02 Dyrcona Still might come in handy.
12:07 JBoyer Ah, so if it weren't for dinars or rials we could drop the FP: https://en.wikipedia.org/wiki/​List_of_circulating_currencies
12:07 JBoyer though I don't think they're especially well supported currently.
12:08 * JBoyer climbs out of rabbit hole...
12:10 sandbergja joined #evergreen
12:16 aabbee still base 10, so could still go fixedpoint if you have one more precision place. if they were base 12 or something, things would get weird.
12:19 * berick invents dodecacoin
12:25 sandbergja If anybody has the time/inclination, I'd appreciate some eyes on bug 1821094.  It improves the performance issue that I added with 1721109 (and am feeling kinda guilty about, haha).
12:25 pinesol Launchpad bug 1821094 in Evergreen 3.2 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
12:28 Christineb joined #evergreen
12:31 jihpringle joined #evergreen
12:36 Dyrcona sandbergja: I've asked if John would like to have a look. He's commented on the Lp bug.
12:36 sandbergja Dyrcona++
12:36 sandbergja thanks!
12:53 gmcharlt berick: please note updates to bug 1823393
12:53 pinesol Launchpad bug 1823393 in Evergreen "Port Org Unit Type editor to Angular / FM Editor Translate Buttons" [Wishlist,Confirmed] https://launchpad.net/bugs/1823393
12:53 gmcharlt sandbergja: dbwells: once berick has had a chance to look at my follow-up, I commend this bug to one of you for final review and committing
12:57 * berick looks
13:00 * dbwells also looks
13:07 * berick updates ticket
13:13 pinesol [evergreen|Jeff Godin] LP#1796942 Treat VISA SIP payments as credit card - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7b3a620>
13:31 _sandbergja joined #evergreen
13:33 sandbergja joined #evergreen
13:39 pinesol [evergreen|Remington Steed] Docs: Fix list formatting in recent release notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d5fe8e5>
13:52 _sandbergja gmcharlt: dbwells: I can take a look at bug 1823393
13:52 pinesol Launchpad bug 1823393 in Evergreen "Port Org Unit Type editor to Angular / FM Editor Translate Buttons" [Wishlist,Confirmed] https://launchpad.net/bugs/1823393 - Assigned to Jane Sandberg (sandbej)
13:54 dbwells _sandbergja: thanks
13:54 dbwells FWIW, it all looked good to me.
14:04 littlet joined #evergreen
14:10 terran joined #evergreen
14:41 khuckins_ joined #evergreen
14:54 Dyrcona hmmm.... actor drones maxed out on one of my bricks.
14:58 littlet7 joined #evergreen
15:05 mmorgan1 joined #evergreen
15:11 Dyrcona Looks like I should increase the max child count.
15:18 Dyrcona Is there some known condition that causes actor drones to get hung up?
16:00 csharp Dyrcona: we've seen actor drones get exhausted pretty regularly since moving to the web client - happens less often since we migrated into our new server environment, but sometimes we still see it
16:01 Dyrcona csharp: I'm seeing it pretty frequently in my logs, too: every day for the past week except Sunday.
16:02 Dyrcona I'm going to increase the number and see if that helps.
16:04 csharp we're up to 96 children per brick
16:04 csharp well, app server - we don't have "bricks" anymore and haven't for years now
16:13 mmorgan joined #evergreen
16:15 Dyrcona csharp: I'll be going to 100 per brick, i.e. 50 per drone server.
16:15 Dyrcona We're currently at 80 per brick.
16:20 aabbee my test server was on eg3.3ish with various customizations. i want to test some stuff on vanilla eg3.2. i did a `git checkout rel_3_2`, rebuilt and restarted everything i know of.
16:20 aabbee but i think i missed something. some, but not all, osrf calls are coming back 404: two examples: open-ils.circ.open_non_cataloged​_circulation.user.authoritative, open-ils.circ.copy_note.retrieve.all
16:20 aabbee sound familiar to anyone?
16:23 Dyrcona aabbee: Going backwards isn't really supported. Might be a good idea to rm -rf /openils and reinstall fresh.
16:24 aabbee ok, i'll try that.
16:36 aabbee nope. :-( error log says: "Method [open-ils.circ.copy_note.retrieve.all] not found for OpenILS::Application::Circ", but `grep 'open-ils.circ.copy_note.retrieve.all' /usr/local/share/perl/5.26.1/​OpenILS/Application/Circ.pm` shows:
16:36 aabbee api_name        => 'open-ils.circ.copy_note.retrieve.all',
16:36 aabbee so idk why it wouldn't find it
16:36 berick aabbee: that typically happens when one of the Perl modules fails to compile
16:37 berick should be an error log entry for that
16:38 jeff and yes, often "perl -c /usr/local/share/perl/5.26.1/​OpenILS/Application/Circ.pm" will show you a compile-time error if you're having trouble finding it in the logs.
16:38 aabbee indeed, `perl -c Circ.pm` says:
16:38 aabbee Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE EMAIL_SENDER}/ at /usr/local/share/perl/5.26.1/OpenI​LS/Application/Circ/HoldNotify.pm line 358.
16:39 aabbee ..but this is the same file that's in git, so it hopefully isn't be broken for everyone. what'd i do worng?
16:39 jeff what distro are you using, and what version of perl?
16:39 Dyrcona It's your Perl version.
16:39 aabbee perl v5.26.1
16:39 Dyrcona That's fixed in a later Evergreen release. I fixed it.
16:39 jeff oh, i see that in the path above now. sorry.
16:39 * jeff nods
16:40 Dyrcona Probably was fixed in the Ubuntu 18 branch that wasn't backported.
16:40 aabbee ubuntu18.04, yes.
16:41 jeff bug 1793585
16:41 pinesol Launchpad bug 1793585 in OpenSRF "Installation Support for Ubuntu 18.04 "Bionic Beaver"" [Wishlist,Fix released] https://launchpad.net/bugs/1793585
16:41 jeff commit 47ddb4 in master
16:41 pinesol jeff: [evergreen|Jason Stephenson] LP#1793585: Fix Unescaped left brace in regex Perl error. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=47ddb4b>
16:42 Dyrcona aabbee: working/collab/dyrcona/ubuntu-bionic-support for Evergreen.
16:43 Dyrcona Same branch name for OpenSRF if you need it.
16:43 aabbee does this mean it's best to use ubuntu16.04 for eg3.2, and upgrade to 18.04 with eg3.3?  i was hoping to minimize deviation from rel_3_2 more than i want to run any specific version of ubuntu.
16:45 Dyrcona aabbee: Generally, yes, it would be safer to run 3.2 on Ubuntu 16.04, but I have a machine in production running 3.2 on Ubuntu 18.04. I backported the branches for Ubuntu 18.04.
16:46 aabbee ok, thank you all, this helps. Dyrcona++ berick++ jeff++
16:51 pinesol [evergreen|Jason Stephenson] Lp 1768987: Use FindBin in 24-sql-gettext-unique.t. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=25dfa52>
17:00 Bmagic does websocketd not work with opensrf 3.0.2? It's only included in the official install instructions for opensrf 3.1.0
17:01 berick Bmagic: it's trivial to back port, but I don't think it's included in 3.0
17:01 Bmagic there is something needed in opensrf for it to work?
17:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:02 Bmagic how about this: any reason to not use opensrf 3.1.0 with EG 3.1.6?
17:05 berick nothing is needed in osrf to run websocketd.  it's a standalone pass-thru replacement for the apache2-websockets
17:05 berick osrf has no knowledge either exists
17:06 Bmagic that's what I thought. Therefore, I could use websocketd against 3.0.2?
17:06 berick yes, definitely
17:06 Bmagic you meant that it would be easy to backport the install instructions?
17:06 jeffdavis FWIW, the release notes say "OpenSRF 3.1 can be used by Evergreen 3.0.x, 3.1.x, and 3.2.x."
17:06 berick i meant it would be easy to backport the websocket commits in your osrf branch
17:06 Bmagic jeffdavis++ # I missed that
17:07 Bmagic ok, fair enough. I think I am going to go with EG 3.1.6 OpenSRF 3.1.0 and websocketd
17:08 mmorgan left #evergreen
17:10 mdriscoll left #evergreen
17:15 ngf314 joined #evergreen
17:20 * berick considers a hatch omnibus for 1824391 1825896 and 1817932
17:20 Dyrcona Sorry I missed that websocketd/OpenSRF conversation. I have backported the websocketd patch to OpenSRF 3.0 and used it in production.
17:21 Dyrcona You should also be able to use OpenSRF 3.1 with Evergreen 3.1.
17:21 Dyrcona I'm pretty sure OpenSRF 3.1 works with Evergreen 3.0 through 3.3.
17:22 Dyrcona Not that I'm adding much other than I've used websocketd with OpenSRF 3.0 in production.
17:22 * Dyrcona signs out now and leaves berick to his considering... :)
17:22 Bmagic good to konw
17:22 Bmagic konw/know
17:27 jihpringle joined #evergreen
17:28 pinesol [evergreen|Jason Boyer] LP1790896: Receipt Errors with invalid emails - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=78389b7>
17:34 pinesol [evergreen|Jane Sandberg] LP1760599: Only show merge records action when multiple bucket records selected - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7114cd6>
17:42 pinesol [evergreen|Rogan Hamby] LP#1440890: add vandelay_queue to the types of containers retrieved by batch edit - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=36795cc>
17:56 pinesol [evergreen|Suzanne Paterno] LP 1744386 & LP 1777184 - stat cats & stat cat entries not alphabetical - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=3ac2009>
18:09 berick gmcharlt++ # comments 1825851
18:09 * berick will review tomorrow
18:10 yboston_ joined #evergreen
18:12 pinesol [evergreen|a. bellenir] LP1775639: Refresh required to see Patron Credit - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1a4a74a>
18:14 jamesrf joined #evergreen
18:24 ngf314 left #evergreen
19:34 jamesrf joined #evergreen
20:00 jamesrf hey!  I filed 1239043 but I see on the feedback fest wikipage there is another sec bug with a title that sounds similar 1822630
20:00 jamesrf I can't see because I'm not on the sec group.  maybe someone on that group can check if they're duplicates
20:00 jamesrf not sure how the bot shows these LP 1239043
20:00 jamesrf LP 1822630
21:11 sandbergja joined #evergreen

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