| Time |
Nick |
Message |
| 00:30 |
|
Stompro joined #evergreen |
| 02:45 |
|
StomproJ joined #evergreen |
| 02:56 |
|
Stompro joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 07:53 |
|
kmlussier joined #evergreen |
| 07:57 |
kmlussier |
@coffee [someone] |
| 07:57 |
* pinesol_green |
brews and pours a cup of Ethiopia Nekisse, and sends it sliding down the bar to sandbergja |
| 07:57 |
kmlussier |
@tea [someone] |
| 07:57 |
* pinesol_green |
brews and pours a pot of BH02: Holy Basil Purple Leaf, and sends it sliding down the bar to RBecker (http://ratetea.com/tea/upton/bh02-holy-basil-purple-leaf/1937/) |
| 08:01 |
jeff |
morning, kmlussier! |
| 08:01 |
jeff |
morning, #evergreen! |
| 08:01 |
kmlussier |
jeff: Good morning! Happy Friday! |
| 08:13 |
jeff |
happy friday! |
| 08:19 |
|
collum joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:51 |
csharp |
@praise [coffee [someone]] |
| 08:51 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to rjackson_isl |
| 08:52 |
rjackson_isl |
csharp++ more coffee is always welcome! |
| 08:53 |
|
bos20k joined #evergreen |
| 09:09 |
|
yboston joined #evergreen |
| 09:12 |
|
bos20k joined #evergreen |
| 09:26 |
|
jvwoolf joined #evergreen |
| 09:36 |
tsbere |
@praise [coffee [tea [blame [someone]]]] |
| 09:36 |
* pinesol_green |
brews and pours a cup of Starlight Blend, and sends it sliding down the bar to brews and pours a pot of Golden Orchid, and sends it sliding down the bar to Forget it, Jake. It's just BigRig. (http://ratetea.com/tea/whispering-pines/golden-orchid/7244/) LOVES the RESISTANCE! |
| 09:39 |
* jeff |
resists the urge to debug pinesol_green |
| 09:39 |
|
Dyrcona joined #evergreen |
| 09:52 |
|
maryj joined #evergreen |
| 09:52 |
|
maryj_ joined #evergreen |
| 09:54 |
|
maryj joined #evergreen |
| 11:00 |
Dyrcona |
"I love it when a plan comes together." |
| 11:05 |
dbs |
@praise <script>alert('XSS!!!!!');</script> |
| 11:05 |
* pinesol_green |
<script>alert('XSS!!!!!');</script> is kind and patient to newbies |
| 11:10 |
Dyrcona |
@blame <script>alert('XSS!!!!!');</script> |
| 11:10 |
pinesol_green |
Dyrcona: <script>alert('XSS!!!!!');</script> WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
| 11:12 |
Dyrcona |
And, "Grr!" to DBI... You're supposed to finish a statement handle after 1 row if I give you the {MaxRows=>1} attribtue option, but you're not.... |
| 11:12 |
Dyrcona |
@blame DBI |
| 11:12 |
pinesol_green |
Dyrcona: DBI broke Evergreen. |
| 11:14 |
* Dyrcona |
doesn't like unnecessary warnings. |
| 11:15 |
Dyrcona |
Of course, $dbh->selectcol_arrayref documentation doesn't actually say that, selectall_arrayref does.... |
| 11:16 |
* Dyrcona |
changes method calls to test. |
| 11:17 |
Dyrcona |
man DBI: You lie to me! |
| 11:19 |
Dyrcona |
Hmm... What if I treat the function like a table? |
| 11:22 |
* tsbere |
wonders what Dyrcona is fighting with now |
| 11:22 |
Dyrcona |
So, I manually call finish() and no more warning, but I'm annoyed at an extra line of code. |
| 11:22 |
Dyrcona |
I prepared a statement with DBI that should always return 1 row. |
| 11:24 |
Dyrcona |
Then I call it with $dbh->selectcol_arrayref($qh, {MaxRows=>1}, $bindval); |
| 11:24 |
Dyrcona |
It gets called at least once for each record in a file. |
| 11:25 |
Dyrcona |
When the script ends, I get the warning about an active statement handle, even though the DBI docs say I shouldn't. |
| 11:25 |
Dyrcona |
Even if it returned more than 1 row, MaxRows=>1 is supposed to tell it to return 1 row and call finish. |
| 11:26 |
Dyrcona |
Or, maybe I misunderstand it's purpose....Whatever... |
| 11:30 |
|
bmills joined #evergreen |
| 11:44 |
* Dyrcona |
waits. The query to find matches is pretty slow. |
| 11:44 |
Dyrcona |
And, that's not the one I was complaining about, either. |
| 11:50 |
|
rlefaive joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:47 |
|
tsbere_ joined #evergreen |
| 12:55 |
mmorgan |
typos-- |
| 13:01 |
Dyrcona |
mmorgan: Indeed. |
| 13:01 |
tsbere |
I dunno. Is one enough? |
| 13:01 |
tsbere |
typos-- |
| 13:01 |
tsbere |
typos-- |
| 13:10 |
jeffdavis |
tpyos-- |
| 13:11 |
mmorgan |
@karma typos |
| 13:11 |
pinesol_green |
mmorgan: Karma for "typos" has been increased 0 times and decreased 3 times for a total karma of -3. |
| 13:12 |
mmorgan |
Doesn't seem right. |
| 13:12 |
mmorgan |
typos-- |
| 13:12 |
mmorgan |
@karma typos |
| 13:12 |
pinesol_green |
mmorgan: Karma for "typos" has been increased 0 times and decreased 4 times for a total karma of -4. |
| 13:31 |
kmlussier |
On the other hand, typos can sometimes lead to much-needed comic relief. |
| 13:32 |
mmorgan |
True! I can't help smiling when I type "gerp", which I frequently do :-/ |
| 13:33 |
* phasefx |
thinks they should change the SQL spec to accept "form" as an alternative to "from" |
| 13:34 |
mmorgan |
:) |
| 13:34 |
gmcharlt |
... to go along with from designers, of course |
| 13:35 |
gmcharlt |
typos++ # without them, I likely would have no writings whatsoever |
| 13:36 |
berick |
phasefx: don't forget UDPATE |
| 13:36 |
phasefx |
:D |
| 13:36 |
phasefx |
that even looks correct when skimming |
| 13:37 |
mmorgan |
even looks correct after reading it a few times ;-) |
| 13:38 |
phasefx |
Paris in the the spring |
| 13:38 |
Dyrcona |
If the first and last letters of a word are correct, and the other letters are not too jumbled (whatever that means), the brain will fix it for you. |
| 13:39 |
Dyrcona |
A computer, on the other hand, is not so clever. |
| 13:39 |
phasefx |
one input out of many |
| 13:40 |
* mmorgan |
would not trust a computer to automatically fix my typos, judging by its spellcheck suggestions. |
| 13:41 |
Dyrcona |
;) |
| 13:41 |
Dyrcona |
Emacs has an abbrevs feature. It's useful for putting in short character combinations that expand to longer words. |
| 13:42 |
Dyrcona |
It can also be used to correct for common typos. |
| 13:42 |
* mmorgan |
runs awry for a bit ;-) |
| 13:43 |
phasefx |
thank you autocorrect |
| 13:44 |
Dyrcona |
:) |
| 14:03 |
Dyrcona |
Grr! Not exactly a typo, but had the wrong table alias in an = statement. |
| 14:09 |
Dyrcona |
Funny how that became obvious when looking at a diff of some changes. |
| 14:38 |
csharp |
hmm - does memcached store locale stuff? we're troubleshooting an issue where the locale switcher isn't sticking |
| 14:49 |
dbs |
csharp: I believe it does, yes |
| 14:51 |
dbs |
IIRC it seemed like years ago a given locale would be cached for a given Apache process, and then you would randomly get that locale based on which process served that request |
| 14:51 |
berick |
a lot of that was also per-process cache instead of memcache. |
| 14:51 |
berick |
well, yeah, basically what dbs said |
| 14:54 |
bshum |
Eww.... |
| 14:54 |
Dyrcona |
Fun..... |
| 14:54 |
* bshum |
imagines a Spanish app server and URL :) |
| 14:58 |
berick |
@roulette |
| 14:58 |
pinesol_green |
berick: *click* |
| 14:59 |
|
ejk joined #evergreen |
| 15:04 |
miker |
the TT caching stuff re locales is long since fixed, btw. the cache key includes $ctx's interpretation of the locale. that was fixed within one minor release IIRC |
| 15:06 |
berick |
yes, indeed, whatever csharp is experiencing is not that.. or an unknown variation of that |
| 15:08 |
berick |
@band add Pony In The Lobby (for b_bonner) |
| 15:08 |
pinesol_green |
berick: Mr. Spock: Something fascinating just happened. |
| 15:08 |
bshum |
Maybe check to see if whatever browser isn't keeping the cookie right? It's some cookie or session thing isn't it? |
| 15:08 |
bshum |
Maybe not cookie, maybe something else |
| 15:08 |
bshum |
Can't remember now what it was called |
| 15:08 |
bshum |
And now I'm only thinking about finding cookies to eat |
| 15:09 |
csharp |
@dessert bshum |
| 15:09 |
* pinesol_green |
grabs some Boston Cream doughnuts for bshum |
| 15:09 |
csharp |
aw - close |
| 15:09 |
berick |
cookie is 'eg_locale' |
| 15:09 |
bshum |
I have mint chocolate chip cookies at home. Like an idiot, I didn't pack a small bag to come with me to the office. |
| 15:10 |
berick |
though, eg_boston_cream_donut might be better |
| 15:11 |
gmcharlt |
wouldn't last, though |
| 15:11 |
gmcharlt |
only because I would eat all of them |
| 15:12 |
berick |
mmmm, locale sprinkles |
| 15:14 |
bshum |
The compiled caching for TT2 stuff doesn't affect locale stuff? |
| 15:15 |
csharp |
https://frinkiac.com/meme/S07E06/384767.jpg?b64lines=IE1tbS4uLiBsb2NhbGUgc3ByaW5rbGVzLiA= |
| 15:15 |
bshum |
well probably not. I imagine dbs would have noticed if there was a glitch by now. |
| 15:15 |
berick |
csharp++ |
| 15:16 |
dbs |
Uhh, I've given up on a lot of things, to be honest |
| 15:16 |
csharp |
yeah, the fact that laurentian is working is why we have confidence that it *should* work :-) |
| 15:16 |
bshum |
csharp: Are you using the same cache source for all your heads? |
| 15:16 |
csharp |
we also have it working on a non-clustered test server |
| 15:17 |
csharp |
bshum: the same 2 servers, yes |
| 15:17 |
csharp |
hmm |
| 15:17 |
csharp |
so 2 non-redundant memcache servers - could that be the issue? |
| 15:17 |
bshum |
I'm thinking about OILSWebCompiledTemplateCache |
| 15:17 |
bshum |
But uh, dunno |
| 15:20 |
bshum |
if that wasn't shared I would expect it to be compiling and showing potentially different looking pages on different app heads. But not necessarily a bad thing. And probably shouldn't have anything to do with the cookie reading for locales... hmm |
| 15:20 |
csharp |
very interesting |
| 15:21 |
bshum |
How often does it not apply the locale? |
| 15:21 |
bshum |
or is it sporadic? |
| 15:21 |
bshum |
Or only applies to parts of the page? |
| 15:21 |
* bshum |
notices that facets didn't translate, but that's probably in-DB strings not being in the locale tables |
| 15:24 |
bshum |
Meh, random |
| 15:24 |
bshum |
It doesn't like me either. |
| 15:24 |
* bshum |
checks the cookies being set |
| 15:25 |
bshum |
Well the cookie is being set |
| 15:25 |
bshum |
Expires November 30, 2026. Plenty of time... |
| 15:25 |
csharp |
bshum: I think you're on to something - removing one of the app servers from rotation looks like it's solving the problem |
| 15:25 |
csharp |
I don't think it's cookies |
| 15:25 |
csharp |
(leaving a single app server) |
| 15:26 |
bshum |
That stuff I was worried about is a 2.9 feature: https://bugs.launchpad.net/evergreen/+bug/1449709 |
| 15:26 |
pinesol_green |
Launchpad bug 1449709 in Evergreen "support caching of compiled Template Toolkit templates" [Wishlist,Fix released] |
| 15:26 |
bshum |
So it's long ago added |
| 15:27 |
bshum |
Did you also set the memcache server to be shared in the eg_vhost.conf? |
| 15:27 |
bshum |
OSRFTranslatorCacheServer |
| 15:28 |
bshum |
To be the same on both app heads |
| 15:28 |
bshum |
by default if it's commented out, it will go with local memcache if installed, not any designated memcached server in opensrf.xml config |
| 15:28 |
csharp |
bshum: yeah, that doesn't appear to be the problem - I'm pretty sure is the template cache |
| 15:28 |
csharp |
gonna put that on an NFS share as an experiment and see if it fixes things |
| 15:28 |
bshum |
csharp: I cheated by making the template cache a shared folder in our NFS mounts |
| 15:29 |
berick |
csharp: is it the static template text or dynamic stuff that comes from the DB, like drop-downs |
| 15:29 |
csharp |
bshum: jinx |
| 15:29 |
bshum |
I'm sure it wasn't the best idea, but it was quick |
| 15:29 |
bshum |
Haha |
| 15:29 |
csharp |
berick: it's the whole page coming back in English when the html header shows it to be es-es |
| 15:29 |
csharp |
not just specific elements |
| 15:36 |
berick |
csharp: and the locale selector says the page is English? |
| 15:39 |
bshum |
When I tested it on his server, it looked like the selector said Spanish, but the page was showing all english |
| 15:39 |
bshum |
Well, his URL anyways |
| 15:39 |
* bshum |
waits to try again when csharp adds back the second app server |
| 15:40 |
* tsbere |
wonders if it is something like "the language is defined, but someone forgot to make sure that the actual strings were on all the servers" |
| 15:41 |
bshum |
Worth double checking what tsbere said too :) |
| 15:41 |
bshum |
Given what happened the first time 'round |
| 15:49 |
miker |
csharp: fwiw, when I looked at it (yours) yesterday, the first time it did act like that -- click "change" and see spanish selected but english text -- but a refresh of the page made it work. I wonder if it's a browser cache issue that apache needs to help with via some new header |
| 15:50 |
miker |
well, now it's not working at all ... so, something changed since I looked yesterday |
| 15:53 |
csharp |
miker: I was experimenting |
| 15:53 |
csharp |
should be back to working |
| 15:53 |
csharp |
but it's on a single app server |
| 15:54 |
csharp |
when I enable the second app server (shared template cache and memcache) it stops working |
| 15:54 |
bshum |
csharp: Check what tsbere said, just in case. |
| 15:55 |
miker |
well, sharing the template cache is probably not going to be a good idea. it does not need to be shared |
| 15:55 |
miker |
each apache builds its own, they're pretty small |
| 15:56 |
miker |
plus, sharing over nfs will be so slow that it defeats the purpose of a cache backed by the FS |
| 15:56 |
csharp |
miker: thanks |
| 15:56 |
miker |
(which is, really, an in-memory cache that survives apache restarts, in practice. the files stay in memory because they're used often) |
| 15:56 |
csharp |
tsbere: you were right - the locale file wasn't on the second app server |
| 15:57 |
bshum |
tsbere++ # simple answer |
| 15:57 |
csharp |
now THAT's the way to end a Friday :-/ |
| 15:57 |
csharp |
miker++ bshum++ berick++ dbs++ # helping me |
| 15:59 |
dbs |
mmm, not so sure I helped but I'll take it :) |
| 16:01 |
bshum |
csharp: You should still follow up with berick's mention about the dropdowns though. I'm pretty sure those can be translated too, but in-db, not via the PO files. |
| 16:02 |
bshum |
That and it'll help your facet translation |
| 16:03 |
tsbere |
csharp: As I saw things go by it was the one possibility I hadn't seen someone else mention. So I mentioned it. |
| 16:03 |
berick |
yeah, if the PO files were the only issue, the drop-downs should have shown es-es data, assuming you have in-db translations for the affected data |
| 16:04 |
csharp |
yeah - it appears to be all fixed now |
| 16:05 |
csharp |
I didn't check the basics first :-( |
| 16:06 |
|
bmills joined #evergreen |
| 16:07 |
bshum |
berick: Well my thinking is that if this is a copy of production database, they probably haven't loaded the strings for in-db translation |
| 16:07 |
bshum |
And I don't think we add them during upgrades; cause we don't want to overwrite any local translations |
| 16:08 |
bshum |
From back when paxed, etc. were doing direct translations in the database via those "translate" buttons |
| 16:08 |
csharp |
yeah, we haven't done any of that - we're new to non-en-US locales |
| 16:08 |
* berick |
nods |
| 16:09 |
csharp |
we've wanted it for a long time, seems long overdue |
| 16:41 |
Dyrcona |
Custom columns in the staff client are stored in the profile, correct? I mean, unless aa_per_machine.js is present. |
| 16:43 |
berick |
Dyrcona: yep |
| 16:43 |
berick |
well, profile dir or on the server |
| 16:43 |
Dyrcona |
berick++ For answering late on a Friday. |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:10 |
|
jvwoolf left #evergreen |
| 17:30 |
|
bmills joined #evergreen |
| 17:31 |
|
rlefaive_ joined #evergreen |
| 17:40 |
Dyrcona |
Time to go! |
| 17:46 |
|
rlefaive joined #evergreen |
| 21:24 |
|
StomproJ joined #evergreen |
| 21:34 |
|
Stompro joined #evergreen |
