| Time |
Nick |
Message |
| 01:21 |
|
sandbergja_ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:48 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:36 |
|
bdljohn joined #evergreen |
| 07:38 |
|
bdljohn joined #evergreen |
| 08:21 |
|
bos20k joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 09:29 |
|
yboston joined #evergreen |
| 09:38 |
|
sandbergja_ joined #evergreen |
| 10:18 |
|
Dyrcona joined #evergreen |
| 10:47 |
csharp |
things seem a bit happier this morning with round-robin scheduling in place |
| 10:47 |
csharp |
we'll see what happens this afternoon |
| 10:48 |
berick |
csharp++ |
| 10:49 |
berick |
csharp: which websocket setup? |
| 11:00 |
csharp |
websocketd |
| 11:00 |
csharp |
when I confirmed that wasn't the likely cause, I switched back |
| 11:02 |
berick |
cool |
| 11:02 |
* berick |
leaves his ears on |
| 11:11 |
pinesol |
[evergreen|Galen Charlton] LP#1709698: fix error made when stamping DB update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f497f41> |
| 11:11 |
pinesol |
[evergreen|Galen Charlton] LP#1780639: fix error made when stamping DB update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8706a27> |
| 11:27 |
aabbee |
this isn't a bug, and i don't know if this sort of comment is considered helpful, but i stumbled across the compare_array function (https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/staff/cat/services/holdings.js;h=d78c049bc3fda634839600fcc802d47d635d3f99;hb=refs/heads/master#l92) and thought the implementation could be cleaner (or at least shorter): |
| 11:27 |
aabbee |
function compare_array (x, y, i) { |
| 11:27 |
aabbee |
if(i >= x.length || i >= y.length){ return y.length - x.length; } |
| 11:27 |
aabbee |
return x[i].localeCompare(y[i]) || compare_array(x,y,i+1); |
| 11:27 |
aabbee |
} |
| 11:28 |
Dyrcona |
aabbee: That is a bug if you think it would be an improvement. |
| 11:28 |
csharp |
gmcharlt++ # eagle eyes |
| 11:29 |
csharp |
csharp-- # too hasty sometimes |
| 11:30 |
aabbee |
"improvement" is highly subjective. it's not faster or more memory efficient. there's nothing functionally wrong with the existing implementation. i guess that's what i'm asking: does anyone consider this an improvement, or am i just making noise? |
| 11:31 |
Dyrcona |
I haven't looked at the current implementation, but I generally think less code is better, unless it is a case of iteration versus recursion and recursion leads to a performance hit. |
| 11:31 |
aabbee |
they're both recursive. |
| 11:32 |
|
khuckins joined #evergreen |
| 11:33 |
Dyrcona |
I think your version is an improvement. |
| 11:34 |
aabbee |
hey, thanks! :-) i'll create a wishlist bug for it. |
| 11:36 |
|
Christineb joined #evergreen |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:43 |
csharp |
autogen.sh-- |
| 13:13 |
|
nfBurton joined #evergreen |
| 13:20 |
* mmorgan |
sometimes wishes there was an autogen.sh for humans. |
| 13:21 |
Dyrcona |
:) |
| 13:22 |
JBoyer |
\me, a curmudgeon: "Hey, weird-o! Reset yourself." The kid on his lawn stands up straight, says "Good day sir!" and vacates the lawn with much haste. |
| 13:22 |
JBoyer |
Thanks slashes. |
| 13:50 |
|
bdljohn left #evergreen |
| 13:50 |
|
bdljohn joined #evergreen |
| 13:53 |
|
bdljohn joined #evergreen |
| 14:31 |
|
eby joined #evergreen |
| 14:34 |
sandbergja |
remingtron++ # closing merged pull requests in Github |
| 14:35 |
|
kipd joined #evergreen |
| 14:35 |
remingtron |
sandbergja++ #merging pull requests on Github |
| 14:37 |
sandbergja |
remingtron++ # teaching me how to merge Github PRs |
| 14:37 |
sandbergja |
(I just have to have the last word :-P) |
| 14:39 |
remingtron |
sandbergja: I'll never argue with a karma battle |
| 14:44 |
Dyrcona |
remingtron++ sandbergja++ |
| 14:51 |
berick |
finally we get to call the karma police |
| 14:53 |
|
khuckins joined #evergreen |
| 14:53 |
Dyrcona |
:) |
| 14:53 |
dbwells |
ha |
| 15:12 |
|
yboston joined #evergreen |
| 15:13 |
pinesol |
[evergreen|Bill Erickson] LP1776736 Record merge marc edit repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a2b8f7b> |
| 15:14 |
csharp |
things appear much more stable today - we put round-robin into place and upped the max_children for pcrud (reducing the max_children for cstore at the same time) |
| 15:15 |
Dyrcona |
csharp: Good to hear. The web staff client uses pcrud a lot more than the old staff client or other services did. |
| 15:24 |
berick |
csharp: cool |
| 15:32 |
dbwells |
berick: reviewed bug #1776736, but it didn't apply cleanly to 3.1, so a rebase is there if you feel like taking a look. |
| 15:32 |
pinesol |
Launchpad bug 1776736 in Evergreen 3.1 "Web client: Edit function in merge screen does not keep edits" [Undecided,Confirmed] https://launchpad.net/bugs/1776736 |
| 15:32 |
berick |
dbwells++ |
| 15:32 |
berick |
thanks |
| 15:40 |
phasefx |
Stompro: Dyrcona: the call number pull list fix (lp1749502), for me, if you do Print Full List twice in a row, it renders the affix id's and not the labels |
| 15:41 |
csharp |
ok, so the next step, I think, is to implement cross-domain registration in a test environment. Does anyone out there have docs or examples I could use for this? I have a high-level understanding of what needs to happen, but I'm not sure how to actually do it |
| 15:42 |
* csharp |
steps away for a bit but will be back soon |
| 15:49 |
|
sandbergja_ joined #evergreen |
| 15:50 |
berick |
csharp: take w/ grain of salt cuz I'm not using it, but IIRC you just have to add public and private <router> entries in opensrf_core.xml per each host |
| 15:50 |
berick |
that's assuming the bricks can already route to each other and jabber is using non-localhost domains (e.g. private.brick01, public.brick01, etc.) |
| 15:52 |
Dyrcona |
phasefx: I see that one some rows but not others. I'm getting -1 on some prefixes. |
| 15:52 |
Dyrcona |
Also, doing it a third time, everything looks OK. |
| 15:53 |
Stompro |
phasefx, Interesting, I'll test that out. |
| 15:55 |
phasefx |
I imagine most folks will only invoke it once per page load, but my chaos powers are compulsive |
| 15:55 |
Dyrcona |
Doesn't seem to be much rhyme nor reason when it happens and if it it is prefix, suffix, or both. |
| 15:55 |
Dyrcona |
Well, if you do it again and again you get different results each time, at least I seem to. |
| 15:58 |
Stompro |
phasefx, I cannot replicate that. I just loaded the pull list, then printed it (it looked fine), then clicked print again and it looked the same. Using Chrome. |
| 15:58 |
phasefx |
Stompro: with the Print Full List action or a grid print? |
| 15:59 |
Stompro |
phasefx, print full list. |
| 15:59 |
phasefx |
I'll share a server with you if you want to see it in action |
| 16:01 |
Dyrcona |
I'm seeing it on our training server with 3.2 installed. |
| 16:01 |
Stompro |
phasefx, now I see it. If I double click on the print full list... or just keep clicking. The first print preview pops up, then I close that, then the next one pops up and shows affix IDs for some of the items. Not all. |
| 16:03 |
phasefx |
cool deal |
| 16:05 |
csharp |
berick: thanks - I'll give it a shot |
| 16:05 |
Stompro |
phasefx, maybe multiple instances of the print full list are stepping on each other, trying to update the same info? Maybe we just disable the print full list after the first click until it is done? |
| 16:07 |
phasefx |
Stompro: for me, it didn't seem to be concurrent pop-ups that showed the bug, but open close open close |
| 16:08 |
Stompro |
phasefx, have you already taken down your dev system? |
| 16:09 |
Stompro |
phasefx, could I try there quick? |
| 16:09 |
phasefx |
Stompro: sure, it's back up, but with an extra commit beyond master |
| 16:09 |
phasefx |
in the pull list grid UI, no less :) but shouldn't affect the bug |
| 16:10 |
Dyrcona |
Stompro: I saw the same thing as phasefx. I could open it, look at it, close, then open it again. |
| 16:12 |
Stompro |
phasefx, yep, I see it too on your test system. Hmm, I'll check to see what I missed when creating the commit. |
| 16:15 |
Dyrcona |
I'm only seeing it with affixes of -1. phasefx did you see it with others? |
| 16:15 |
phasefx |
Dyrcona: yes, the REF one from concerto |
| 16:16 |
Dyrcona |
OK. Could be that the list I was looking at had no actual affixes. |
| 16:16 |
Dyrcona |
I was using production data with a small library. |
| 16:16 |
phasefx |
I created a pull list in concerto by hitting up 3 bibs with copy level holds, and specifically modifying the item for the 2nd hold to have a prefix and suffix |
| 16:17 |
Dyrcona |
Good way to test it. I just logged in and brought up the pull list. :) |
| 16:17 |
phasefx |
I also played with location affixes too, because I forgot those were just for label printing |
| 16:19 |
* phasefx |
is poking at lp1779316 and wanted to see what changes were made recently |
| 16:19 |
Dyrcona |
I wonder if fleshing the affixes would be better than going back and retrieving them? We seem to do a lot of pcrud lookups in the web staff client for that sort of thing. |
| 16:20 |
Dyrcona |
Lp1779316 |
| 16:20 |
Dyrcona |
Hey! Where's pinesol? |
| 16:21 |
berick |
@who silenced pinesol |
| 16:21 |
pinesol |
ericar silenced pinesol. |
| 16:22 |
Dyrcona |
Oh, I forget that pinesol is out of order in my list of people in the room. |
| 16:22 |
phasefx |
bug 1779316 |
| 16:22 |
pinesol |
Launchpad bug 1779316 in Evergreen "Web Client: Pull List Call Number include Prefix / Suffix" [Undecided,New] https://launchpad.net/bugs/1779316 - Assigned to Jason Etheridge (phasefx) |
| 16:22 |
Dyrcona |
I thought Lp was supposed to work, too. |
| 16:25 |
csharp |
still seeing actor drones get maxxed. I upped them from 72 to 96, but they maxxed out on one server pretty quickly (I guess it's like adding highway lanes not improving traffic) - still seeing a single brick get pegged while others are underutilized - I guess cross-server xmpp is the only/best solution? |
| 16:27 |
berick |
yeesh. seen any patterns on what they are doing? |
| 16:27 |
berick |
i wonder if we just have an interface or two that are spewing an unreasonable number of requests |
| 16:27 |
Dyrcona |
The auth drones are C. One could actually attach a debugger to them. |
| 16:28 |
berick |
there are places where a large grid will render w/ one or more API calls per row getting fired |
| 16:28 |
berick |
Dyrcona: open-ils.actor |
| 16:28 |
Dyrcona |
Oh... Time to call it a day, I think. :) |
| 16:29 |
bshum |
Dyrcona: LP does work, but only if you have a space between ;) |
| 16:29 |
bshum |
LP 1779316 |
| 16:29 |
pinesol |
Launchpad bug 1779316 in Evergreen "Web Client: Pull List Call Number include Prefix / Suffix" [Undecided,New] https://launchpad.net/bugs/1779316 - Assigned to Jason Etheridge (phasefx) |
| 16:29 |
berick |
csharp: would be useful if you could check activity log for one of the explody bricks, fitler by open-ils.actor, and see if there are chunks of calls coming from a single client (e.g. by authtoken) |
| 16:30 |
berick |
if you get a huge humber of calls (especially if they're the same api call) in a very short period of time, there may be a UI we can fix |
| 16:33 |
csharp |
berick: will do |
| 16:36 |
csharp |
berick: at first blush I'm seeing a lot of open-ils.actor.settings.retrieve.atomic calls |
| 16:37 |
csharp |
also open-ils.actor open-ils.actor.settings.apply.user_or_ws |
| 16:38 |
csharp |
open-ils.actor.ou_setting.ancestor_default.batch |
| 16:39 |
csharp |
also open-ils.actor.user.itemsout.notices |
| 16:39 |
csharp |
lots of each of those, but not so many that any one of them is obviously the cause |
| 16:42 |
csharp |
but yeah, after trawling through about 20 minutes worth of activity logs, looks like it's mostly settings checks |
| 16:45 |
berick |
but no clear cases of, say, 50 calls from a single client within a few seconds? |
| 16:49 |
csharp |
fwiw, pcrud is no longer maxxing since I upped those limits, so we are better overall |
| 16:50 |
csharp |
and only one brick is maxxing with actor at the moment |
| 16:57 |
|
sandbergja__ joined #evergreen |
| 17:00 |
sandbergja__ |
Hey all -- I've got Evergreen running on localhost, using docker. But Firefox doesn't like weird ports like 7682 under a self-signed certificate. Does anybody know if there's a way I can adjust about:config so that Firefox isn't so picky about that? |
| 17:00 |
sandbergja__ |
FWIW, I can use Chromium just fine. |
| 17:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-20T16:59:00,937625555-0400 -0> |
| 17:03 |
sandbergja__ |
I tried setting network.security.ports.banned.override to 7682, but that didn't help :-( |
| 17:05 |
|
mmorgan left #evergreen |
| 17:13 |
berick |
sandbergja__: try navigating to https://HOST:7682/osrf-websocket-translator |
| 17:13 |
berick |
it should prompt you to click through the cert warning |
| 17:14 |
berick |
on FF even though it's the same cert from the same host, you have to click through per port. |
| 17:15 |
berick |
or use nginx so you can share the port |
| 17:16 |
sandbergja |
berick++ |
| 17:16 |
sandbergja |
thanks! |
| 17:30 |
Bmagic |
Has anyone put a capcha on the patron "request a library card" form? |
| 20:30 |
|
sandbergja joined #evergreen |
| 20:35 |
|
Christineb joined #evergreen |
