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/1oxM5dA2FqPhUD81IIhnsoTuVkbfB2VoYTBKfhGMPwjk/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/OpenILS/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 |