Time |
Nick |
Message |
02:22 |
|
nhilton joined #evergreen |
07:09 |
|
Callender joined #evergreen |
07:55 |
|
ericar joined #evergreen |
08:10 |
|
collum joined #evergreen |
08:23 |
|
TaraC joined #evergreen |
08:26 |
|
mrpeters joined #evergreen |
08:32 |
|
mrpeters joined #evergreen |
08:44 |
|
abowling joined #evergreen |
08:56 |
|
graced joined #evergreen |
09:01 |
|
BigRig joined #evergreen |
09:20 |
|
maryj joined #evergreen |
09:30 |
|
wsmoak joined #evergreen |
09:59 |
wsmoak |
Pines looks different! I remembered the Firefox search widget and tried to install it... didn't *seem* to work. |
10:00 |
wsmoak |
Turns out that it did install, it's just using a plain magnifying glass icon that I didn't recognize as Pines. Maybe you could use the little tree icon? |
10:02 |
wsmoak |
The tree is there next to "Add Evergreen OpenSearch", but isn't used in the 'Search With' options later. |
10:15 |
jeff |
@later tell csharp wsmoak has some feedback for you on OpenSearch icons -- see logs if you haven't already :-) |
10:15 |
pinesol_green |
jeff: The operation succeeded. |
10:16 |
jeff |
wsmoak: on csharp's behalf, since he's probably either still working hard or resting well -- thanks! :-) |
10:23 |
wsmoak |
sure. :) Here's a screen shot: http://wsmoak.net/temp/pines-firefox-search.png |
10:24 |
wsmoak |
it was confusing because it still says "Add Evergreen OpenSearch" (possibly it always will when you're on the pines site, just because that xml file exists) |
10:24 |
wsmoak |
I couldn't catch the hover text in the screen shot, but that grey magnifying glass is actually PINES. |
10:26 |
dbs |
wsmoak: take a look at the "Add opensearch" option for https://laurentian.concat.ca - that's relatively stock for the next version of Evergreen (assuming a patch of mine is accepted) |
10:27 |
dbs |
I think the icon just comes from /favicon.ico |
10:27 |
dbs |
(which reminds me, I need to update ours to get away from the stock favicon.ico...) |
10:28 |
wsmoak |
dbs: yours works the same way. (now I have two grey magnifying glasses to choose from) |
10:29 |
dbs |
wsmoak: strange, sir. when I go to http://gapines.org/eg/opac/home in Firefox 35 and add the opensearch from there, it gives me the pines icon |
10:29 |
dbs |
what browser are you using? |
10:30 |
dbs |
specifically Firefox 35.0 for Linux here. |
10:30 |
wsmoak |
Firefox 35.0 . So your search drop down doesn't look like my screen shot above, you get your icon under "Search for xyz with:" ? |
10:30 |
wsmoak |
mac osx |
10:31 |
|
ningalls joined #evergreen |
10:31 |
dbs |
Yep, mine looks quite different. You running a non-stock theme or extension perhaps? |
10:31 |
wsmoak |
I don't think it's using favicon -- I see the tree up in the browser tab next to the site title. |
10:31 |
wsmoak |
this is a fairly fresh Yosemite install, and I haven't customized FF at all |
10:33 |
wsmoak |
will be interesting to see what another osx user sees. Norton might be to blame, it sticks its nose where it isn't wanted all the time. |
10:34 |
wsmoak |
anyway... the search works fine now that I know what I'm looking at. :) minor issue. |
10:48 |
dbs |
http://i.imgur.com/dbmZDa9.png is what mine looks like |
10:48 |
dbs |
(highlighting PINES obscures the icon sadly, oh well) |
10:53 |
|
julialima_ joined #evergreen |
10:54 |
* dbs |
wonders idly why Browse catalog by title works in one library in our instance but not in another |
10:54 |
dbs |
(returns a server 500 error, yikes) |
10:58 |
* dbs |
peers at egweb: Context Loader error: Can't use an undefined value as a HASH reference at WWW/EGCatLoader/Browse.pm line 271. |
11:00 |
dbs |
suggests its a database error, and the there's no $self->editor->event member that was returned I guess. |
11:03 |
* dbs |
opts to stop testing defensive code in production after making every page request return 500 :) |
11:21 |
|
yboston joined #evergreen |
12:00 |
|
Dyrcona joined #evergreen |
12:09 |
dbs |
my defensive code is simply offensive |
12:12 |
dbs |
even weirder, that browse works on our test instance where we haven't reingested all of the records. hrm. |
12:18 |
|
jihpringle joined #evergreen |
12:23 |
eeevil |
dbs: any chance the osrf translator memcache instance is misconfigured in the apache configs? I've seen that break browse and just a couple other things in the past. A/T event def editor would also break, for instance |
12:24 |
dbs |
eeevil: definitely possible |
12:26 |
dbs |
hmm. matches our opensrf.xml values of 127.0.0.1:11211 |
12:26 |
dbs |
and browse works for one locg value in production but not another |
12:36 |
eeevil |
well, that rules out one problem, at least |
12:36 |
dbs |
thanks for the idea - yeah |
12:36 |
Dyrcona |
I've been seeing this in 2.7.1 and master lately when stopping services: timed out waiting on open-ils.acq pid=8347 to die |
12:37 |
Dyrcona |
It's always acq. |
12:37 |
Dyrcona |
But then, I'm "off" today. |
12:38 |
|
sandbergja joined #evergreen |
12:47 |
julialima_ |
Hello evergreeners!!! The web client is not working, at least for me. In the patron search I can´t perform any search, I have no feedback so I don´t know what is going on. Anyone know if there is a problem? |
12:47 |
bshum |
Dyrcona: I've seen that too actually. |
12:47 |
bshum |
Also "off" :) |
12:51 |
bshum |
julialima_: I'm probably not the best person to answer you (I'm not sure how many folks have off today in the US). Anywho, which server are you using to test with? |
12:52 |
dbwells |
julialima_: Some folks might be at lunch, which is where I am headed. Also, just to clarify, are you talking about webby.evergreencatalog.com, or some other test site? |
12:52 |
bshum |
Maybe there might be a hint in the browser console |
12:53 |
gmcharlt |
julialima_: try webby now; I've restarted services there and it's now working for me |
12:54 |
julialima_ |
gmcharlt: It is working now, thank you very much! :) |
12:59 |
jeff |
gmcharlt++ |
13:24 |
* dbs |
looks sideways at the default limit of 64mb being used for memcached. hmmmmm |
13:27 |
|
mrpeters joined #evergreen |
13:37 |
abowling |
hey, all. have another noob question that i think i have the answer to: does search_prefs.xul run on a user's local machine? |
13:38 |
abowling |
i ask, because i can find no instance of it on the server, which makes me believe it runs client-side |
13:57 |
dbs |
abowling: rough rule of thumb, stuff under "chrome/" runs client-side |
13:57 |
dbs |
anyone else care to share what their memcached memory is set to? |
13:58 |
abowling |
dbs: thanks. i thought so, but wanted to confirm after editing a file in the wrong place last week. |
14:00 |
jeffdavis |
dbs: our memcached memory is 1024 MB |
14:01 |
jeffdavis |
(assuming you mean the -m option) |
14:08 |
|
sandbergja joined #evergreen |
14:09 |
dbs |
jeffdavis: yeah, that's exactly what I was looking for -- thanks |
14:09 |
dbs |
might be another "knobs to tune for production systems" bit to add to that mythical section of the documentation |
14:15 |
eeevil |
dbs: most we have here are 64MB. a few are bigger |
14:19 |
dbs |
eeevil: huh. so much for that then, maybe. that said we have search engines hungrily crawling our 2+ million record system so perhaps > 64m is warranted (for ~the AC for example) |
14:53 |
|
nhilton joined #evergreen |
15:58 |
Dyrcona |
Not bad for five hours, I s'pose: 2 files changed, 139 insertions(+), 319 deletions(-) |
16:20 |
|
julialima_ left #evergreen |
16:29 |
jeff |
deletions++ |
17:35 |
|
gsams joined #evergreen |
18:14 |
|
phasefx joined #evergreen |
20:50 |
|
dcook joined #evergreen |