| Time |
Nick |
Message |
| 07:02 |
|
timf joined #evergreen |
| 08:07 |
|
collum joined #evergreen |
| 08:31 |
|
akilsdonk joined #evergreen |
| 08:41 |
|
Shae joined #evergreen |
| 08:46 |
|
kbeswick joined #evergreen |
| 08:48 |
|
finnx joined #evergreen |
| 09:03 |
berick |
tpac accessibility question for you all... the red $1.23 fines amount shown in the patron summary of the tpac (once logged in, assuming fines) does not have a high enough luminosity contrast ratio w/ the background (green) to be considered accessibile. |
| 09:04 |
berick |
thinking about changing the color to match the Checked Out / On Hold count color (yellow-ish) instead, which contrast very highly |
| 09:05 |
berick |
a mostly-red color does not appear to be an option |
| 09:05 |
* berick |
is playing with http://www.dasplankton.de/ContrastA/ |
| 09:05 |
berick |
for that text size, the ratio has to be at least 4:1 |
| 09:06 |
* berick |
is impressed that so much of the tpac is just fine in this regard |
| 09:06 |
berick |
after all the recent work |
| 09:06 |
|
mmorgan joined #evergreen |
| 09:06 |
berick |
anyway, if anyone has alt suggestions, i got my ears on |
| 09:09 |
tsbere |
Huh. MVLC's choices don't work either, apparently, by that determination. Not that our choices would be community-appropriate, granted... |
| 09:11 |
berick |
beware that as the text size / weight increases, the required ratio goes down |
| 09:11 |
berick |
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html |
| 09:11 |
kmlussier |
berick: I don't have an alternate suggestion, but I had once heard that yellow is a more difficult color for older people to see. |
| 09:12 |
berick |
so, lots of the tpac seems to have a low ratio, but it's actually fine, cuz it's 14pt/bold |
| 09:12 |
berick |
kmlussier: that's too bad, the other high-contrast colors for that dark green are pink-ish / purple-ish |
| 09:12 |
berick |
not very attractive |
| 09:13 |
kmlussier |
No, not at all. |
| 09:13 |
tsbere |
berick: Honestly, I find the different colors distracting and had considered making them all uniform. The Green "Ready for Pickup" and red "Fines" (which stays red even when 0 or negative, which is a complaint itself) is distracting and to some misleading. |
| 09:13 |
kmlussier |
I'm not sure if what I heard was fact or myth, but it might be worth looking into. |
| 09:14 |
dbs |
tsbere++ |
| 09:14 |
berick |
tsbere: i feel the same. related, i'm really hoping we can avoid the insane color explosions the staff client -- 8 penalties, 8 different colors! |
| 09:14 |
* dbs |
is not a fan of much color either |
| 09:15 |
* tsbere |
would prefer symbols for penalties if we don't trust people to read text, and then we can show more than just one and not have to worry about color blind people having issues |
| 09:15 |
dbs |
red and green have their own color blindness issues, too (family members have that) |
| 09:15 |
berick |
kmlussier: i don't know, but given that we already use that color, i'm emboldened ;) |
| 09:16 |
berick |
tsbere: +1 |
| 09:17 |
|
mrpeters joined #evergreen |
| 09:18 |
kmlussier |
berick: I just did a quick search and didn't see anything to support what I just said, so I withdraw my concern. |
| 09:18 |
berick |
kmlussier++ thanks |
| 09:25 |
* berick |
borrows bootstrap's "sr-only" class to add some hidden accessibilty navigation to the tpac |
| 09:32 |
|
yboston joined #evergreen |
| 09:40 |
dbwells |
berick: Not saying it applies here, but as an old graphic design trick, a subtle text shadow can often increase contrast without being too noticeable. For example, adding something like 'text-shadow: 0 0 2px #000000;' to #dash_fines certainly helps. Is it enough? In this case, hard to say. I do agree with the others that a different overal strategy might be better here. |
| 09:40 |
dbs |
berick: just switch it all over to bootsrap while you're at it! |
| 09:41 |
berick |
dbwells: ah, i like it. i'll play around with that. |
| 09:41 |
* dbs |
raps an ode to his old boots: https://plus.google.com/116747292129029460979/posts/55yY5Z3s7m5 |
| 09:41 |
berick |
dbs: hah |
| 09:42 |
* berick |
would rather spend his time porting autosuggest to non-dojo |
| 09:43 |
dbs |
_that_ would be great |
| 09:43 |
berick |
yowza, that's a lot script files for so few features |
| 09:44 |
dbs |
I'm still shocked the browser people haven't come up with an <input type='autosuggest' src='json_feed'> standard widget |
| 09:44 |
berick |
and rest assured when they do, IE won't support it for 8 years :( |
| 09:53 |
* dbs |
was tempted to mess more with the OpenSearch functionality last night, e.g. to use the full name of the library rather than the shortname for the search engine widget, but realized that a) many libraries would have crazy long names and b) probably .05% people would actually use it anyway |
| 09:55 |
bshum |
dbs: I haven't tested the latest branch, but remember fiddling with it back in the day. I think the only part that made me wary was how scoping could be applied if possible. |
| 09:56 |
bshum |
I'll try it again when I get a moment to breathe. |
| 10:02 |
|
kbeswick_ joined #evergreen |
| 10:04 |
|
keynote2k joined #evergreen |
| 10:04 |
dbs |
bshum: there are no real options for scoping; the code takes whatever your current search library is and uses that for the widget scope |
| 10:05 |
dbs |
So if you're searching at BR4 when you add the widget to your browser, you'll get a search engine widget named "BR4" that searches at "BR4". Of course you can adjust your search as normal after the search returns results, because it returns results in TPAC as of this branch |
| 10:05 |
bshum |
dbs: That might be why it wasnt entirely happy with me then. Our system is only making use of the pref_lib and doesn't set scope unless someone manually chooses something. |
| 10:05 |
|
jwoodard joined #evergreen |
| 10:06 |
dbs |
bshum: I'm not sure you tried this branch ever, as I'm sure it didn't exist until around midnight last night |
| 10:06 |
bshum |
Well... Right. Fine, I'll just have to go test it now then. :) |
| 10:06 |
dbs |
:) |
| 10:07 |
* bshum |
should rename our top level someday from CONS... |
| 10:14 |
bshum |
dbs: Ahh, I see. The hostname stuff? |
| 10:14 |
bshum |
Either way, works fine and does what I expect now. |
| 10:15 |
bshum |
dbs++ |
| 10:16 |
bshum |
With one tiny thing |
| 10:16 |
bshum |
I think there's a hanging " at the end of the base.tt2 change |
| 10:16 |
bshum |
So it shows up at the top of the TPAC |
| 10:21 |
|
mllewellyn joined #evergreen |
| 10:23 |
dbs |
bshum: good catch! |
| 10:23 |
dbs |
I will stare at my midnight branch |
| 10:23 |
dbs |
yep, I see it. will force-push the fix |
| 10:25 |
bshum |
Heh, it's fun how logc=SHORTNAME works as a variable now. |
| 10:25 |
* bshum |
remembers when that didn't |
| 10:25 |
bshum |
Oh how things change |
| 10:25 |
dbs |
locg |
| 10:25 |
bshum |
Well, locg |
| 10:25 |
bshum |
Right :) |
| 10:50 |
|
mcooper joined #evergreen |
| 11:16 |
* csharp |
sends a carefully worded email to a library staffer who has been scheduling 5-6 concurrent item list reports at a time |
| 11:17 |
rjackson-isl |
csharp I feel your pain! |
| 11:17 |
csharp |
book title: "Staring at the Midnight Branch" by dbs |
| 11:18 |
* bshum |
would buy that book. |
| 11:24 |
jboyer-isl |
does anyone know what a query that looks like this might be for: |
| 11:24 |
berick |
"the night was... sultry. And so was the code" |
| 11:24 |
jboyer-isl |
SELECT count(DISTINCT "mmrsm".source ) AS "count", "mfae".field AS "id", "mfae".value AS "value" FROM metabib.facet_entry AS "mfae" INNER JOIN metabib.metarecord_source_map AS "mmrsm" ON ( "mmrsm".source = "mfae".source ) INNER JOIN config.metabib_field AS "cmf" ON ( "cmf".id = "mfae".field ) WHERE ( "cmf".facet_field = 't' ) AND ( "mmrsm".source IN ( |
| 11:24 |
jboyer-isl |
(and then a bunch of ids). I'm guessing OPAC related because of the facet fields, but that's just a guess. |
| 11:25 |
eeevil |
jboyer-isl: it's part of facet counting, yes |
| 11:26 |
eeevil |
the list of IDs is the current superpage of visible records |
| 11:26 |
jboyer-isl |
ok. Occasionally they'll appear to get "stuck" and hang around 5+ minutes, just wanted to make sure we weren't knocking out anything important. |
| 11:27 |
eeevil |
you're not. if you can grab the whole query and share an EXPLAIN of it, that would be great. could just be out-of-date stats for a table, or tuning required ... or could be "that case wants a new index" |
| 11:28 |
jboyer-isl |
I'll see if it's in the logs. pg_stat_activity cuts current_query short so I'm not 100% that's the end of the relevant bits. |
| 11:29 |
eeevil |
cool |
| 11:37 |
csharp |
jboyer-isl: you might look into pgfouine http://pgfouine.projects.pgfoundry.org/ - we use that to track long-running queries - setup is pretty simple - also pgbadger is supposed to be good, though I haven't used it http://sourceforge.net/projects/pgbadger/ |
| 11:38 |
csharp |
berick++ # just saw your quote from dbs's book - lulz |
| 11:41 |
jboyer-isl |
Thanks csharp, I'll check them out. |
| 11:49 |
jboyer-isl |
Looks like I entered my nick wrong on the paste site: http://paste.evergreen-ils.org/53 |
| 11:49 |
jboyer-isl |
Re: that query plan, I've seen worse. I'm thinking disk io is such a bottleneck that it's causing huge delays semi-randomly. (That query doesn't take more than 3-4 seconds usually) |
| 11:51 |
jboyer-isl |
Actually, in this case I know it's disk io, because there are some issues to be dealt with. :/ |
| 12:11 |
eeevil |
jboyer-isl: was that one of the ones that was /actually/ stalling, or just representative of the query shape in general? |
| 12:12 |
eeevil |
(specific parameters can sometimes change the plan chosen) |
| 12:12 |
jboyer-isl |
Same type, different time. |
| 12:12 |
eeevil |
parameter values, I mean |
| 12:12 |
jboyer-isl |
I can look for the one that was stuck, but I thought only the ids would be different. |
| 12:14 |
eeevil |
yes, but if the IDs fell into a set that was pathologically /included/ in the stats histogram for the facet value table, PG might think that it should use a seq-scan because "hey, the request IDs seem to make up more than 10% of the sampled data" |
| 12:15 |
eeevil |
long shot, but possible. another possibility is, of course, an i/o storm as you suggest :) |
| 12:20 |
jeff |
today's excuse: IO storms off the atlantic seaboard. |
| 12:20 |
jeff |
(off the moons of jupiter?) |
| 12:20 |
* jeff |
ducks |
| 12:20 |
|
smyers_ joined #evergreen |
| 12:22 |
jboyer-isl |
jeff: Comsmic Rays. A bunch of Ray Ramono clones in Intel bunny suits. |
| 12:22 |
jeff |
*groan* |
| 12:22 |
jboyer-isl |
BAH. Cosmic is not comsic. |
| 12:22 |
jeff |
MS Cosmic Sans |
| 12:22 |
jboyer-isl |
Could only help. |
| 12:24 |
* csharp |
has enjoyed the perfect view of Jupiter in the east over the last couple of weeks |
| 12:26 |
|
dMiller__ joined #evergreen |
| 12:28 |
jeff |
this all started with someone's slow query log and ended with me putting a hold on Blade Runner |
| 12:28 |
pastebot |
"jboyer-isl" at 64.57.241.14 pasted "QP comparison" (34 lines) at http://paste.evergreen-ils.org/54 |
| 12:30 |
jboyer-isl |
eeevil: You were right, though I'm not sure why it would be a problem. |
| 12:33 |
csharp |
@eightball *do* androids dream of electric sheep? |
| 12:33 |
pinesol_green |
csharp: What are you asking me for? |
| 12:33 |
|
stevenyvr2 joined #evergreen |
| 12:37 |
|
stevenyvr2 left #evergreen |
| 12:38 |
|
stevenyvr joined #evergreen |
| 12:41 |
eeevil |
jeff: I read "... excuse: IO ..." as "excuse::IO" and was about to ask where one might avail themselves of that particular module |
| 12:42 |
gmcharlt |
eeevil: surely you mean Blame::IO |
| 12:42 |
eeevil |
gmcharlt++ |
| 12:43 |
jeff |
heh. just realized i have a report called bucket_list.jrxml |
| 13:40 |
csharp |
jeff++ |
| 13:41 |
|
afterl joined #evergreen |
| 13:41 |
csharp |
@blame IO |
| 13:41 |
pinesol_green |
csharp: It's all IO's fault! |
| 13:58 |
jeff |
wishing i could checkpoint my brain sometimes. |
| 13:59 |
jeff |
serializing thoughts to ascii just doesn't cut it at times. |
| 14:18 |
pinesol_green |
[evergreen|Galen Charlton] LP#1234201: fix menu item to display patron requests (if summary is horizontal) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7a049d> |
| 14:19 |
|
kbeswick joined #evergreen |
| 14:23 |
bshum |
@hates horizontal summary display |
| 14:23 |
pinesol_green |
bshum: (hates [<channel>] [<user>]) -- Find out what <user> hates |
| 14:23 |
bshum |
@hate horizontal summary display |
| 14:23 |
pinesol_green |
bshum: The operation succeeded. bshum hates horizontal summary display. |
| 14:24 |
bshum |
@hate vertical summary display |
| 14:24 |
pinesol_green |
bshum: The operation succeeded. bshum hates vertical summary display. |
| 14:24 |
jeffdavis |
@whocares diagonal summary display |
| 14:24 |
pinesol_green |
jeffdavis: I can't find anyone who loves or hates diagonal summary display. |
| 14:39 |
|
dMiller___ joined #evergreen |
| 14:57 |
jboyer-isl |
@love diagonal summary display |
| 14:57 |
pinesol_green |
jboyer-isl: The operation succeeded. jboyer-isl loves diagonal summary display. |
| 14:57 |
jboyer-isl |
Being late to the party doesn't mean it's not a party. |
| 14:59 |
jeffdavis |
:) |
| 15:03 |
csharp |
@whocares display |
| 15:03 |
pinesol_green |
csharp: I can't find anyone who loves or hates display. |
| 15:26 |
|
DPearl1 joined #evergreen |
| 15:27 |
jboyer-isl |
Here's a fun question in case anyone knows: If you run autogen.sh -u on multiple bricks, should the cache key be the same each time it runs (provided no changes are made)? |
| 15:28 |
|
dMiller__ joined #evergreen |
| 15:34 |
gmcharlt |
jboyer-isl: yes, the cache key should be identical; if it isn't, it indicates that there's a difference in the files it's checksumming |
| 15:35 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "list of files that the cache key is calculated from" (7 lines) at http://paste.evergreen-ils.org/55 |
| 15:35 |
jboyer-isl |
That's what I expected. Makes the 2 different results I just got less amusing though. |
| 15:35 |
jboyer-isl |
thanks for the list of files too |
| 15:35 |
jboyer-isl |
gmcharlt++ |
| 15:37 |
gmcharlt |
also, nowadays -u isn't really necessary |
| 15:37 |
gmcharlt |
and if you use that option at all, it need only be used once |
| 15:38 |
jboyer-isl |
ok. Are there any potential issues, or is it basically a noop the second+ times? |
| 15:41 |
gmcharlt |
jboyer-isl: it refreshes actor.org_unit_proximity in the DB |
| 15:41 |
gmcharlt |
it's unecessary because triggers on actor.org_unit handing updating the proximity list nowadys |
| 15:42 |
gmcharlt |
and even back when it was useful, it only needed to be run just once after any changes to the OU tree |
| 15:46 |
jboyer-isl |
I see. |
| 16:02 |
jeff |
note to self: next time, reserve hotel room before getting travel request approved |
| 16:03 |
jboyer-isl |
jeff: dates filling up? |
| 16:12 |
jeff |
default date range resulted in no availability. i adjusted to 3/18 - 3/22 and it was happier |
| 16:14 |
jeff |
> Connect to see which of your Facebook friends are going to Evergreen 2014 International Conference. |
| 16:29 |
kmlussier |
jeff: Which date was the problem? |
| 16:32 |
|
snowball joined #evergreen |
| 16:32 |
kmlussier |
Oh, I see. It's strange that it defaults to an ending date of 3/23. We didn't block rooms on that day. |
| 16:34 |
* jeff |
nods |
| 16:34 |
jeff |
i booked for not-quite-the-dates-i-need and will call to adjust. :-) |
| 16:35 |
kmlussier |
Yes, if you call and they have the right rooms available, they might be able to extend the discount to those additional days. |
| 16:39 |
jeff |
hate hate hate booking travel. |
| 16:41 |
|
jboyer-isl joined #evergreen |
| 17:05 |
|
mrpeters left #evergreen |
| 17:11 |
|
dcook joined #evergreen |
| 17:42 |
|
mmorgan left #evergreen |
| 18:10 |
|
Callender joined #evergreen |
| 18:11 |
|
pinesol_green` joined #evergreen |
| 18:12 |
|
smyers__ joined #evergreen |
| 18:13 |
|
bshum_ joined #evergreen |
| 18:17 |
|
keynote2k joined #evergreen |
| 18:18 |
|
kmlussier joined #evergreen |
| 18:22 |
|
dac joined #evergreen |
| 18:32 |
|
dcook joined #evergreen |
| 18:49 |
|
keynote2k joined #evergreen |
| 18:53 |
|
ktomita joined #evergreen |
| 18:53 |
|
fparks joined #evergreen |
| 18:56 |
|
fparks_ joined #evergreen |
| 19:08 |
|
sseng joined #evergreen |
| 19:08 |
|
fparks joined #evergreen |
| 19:08 |
|
smyers_ joined #evergreen |
| 19:08 |
|
ktomita_ joined #evergreen |
| 19:10 |
|
dconnor joined #evergreen |
| 19:11 |
|
ktomita__ joined #evergreen |
| 19:12 |
|
smyers_ joined #evergreen |
| 19:12 |
|
sseng joined #evergreen |
| 19:12 |
|
fparks joined #evergreen |
| 19:14 |
|
dconnor_ joined #evergreen |
| 19:14 |
|
sseng_ joined #evergreen |
| 19:33 |
|
ktomita joined #evergreen |
| 19:50 |
|
ktomita_ joined #evergreen |
| 19:54 |
|
ktomita joined #evergreen |
| 19:59 |
|
ktomita_ joined #evergreen |
| 22:11 |
|
stevenyvr2 joined #evergreen |
| 22:11 |
|
stevenyvr2 left #evergreen |
| 22:28 |
|
stevenyvr joined #evergreen |
| 23:23 |
|
mrpeters joined #evergreen |
