| Time |
Nick |
Message |
| 00:31 |
|
misilot joined #evergreen |
| 00:56 |
|
Mark__T joined #evergreen |
| 01:01 |
|
ktomita joined #evergreen |
| 01:19 |
|
stevenyvr2 joined #evergreen |
| 01:19 |
|
stevenyvr2 left #evergreen |
| 01:59 |
|
Bamba705 joined #evergreen |
| 01:59 |
|
Bamba705 left #evergreen |
| 02:25 |
|
ktomita_ joined #evergreen |
| 02:53 |
|
VGFAA228 joined #evergreen |
| 02:53 |
|
VGFAA228 left #evergreen |
| 03:04 |
|
VGFAA582 joined #evergreen |
| 03:04 |
|
VGFAA582 left #evergreen |
| 03:19 |
|
jdouma_ joined #evergreen |
| 03:23 |
|
VGFAA677 joined #evergreen |
| 03:23 |
|
VGFAA677 left #evergreen |
| 03:35 |
|
VGFAA637 joined #evergreen |
| 03:35 |
|
VGFAA637 left #evergreen |
| 05:29 |
|
b_bonner- joined #evergreen |
| 05:30 |
|
b_bonner- joined #evergreen |
| 05:43 |
|
VGFAA778 joined #evergreen |
| 05:43 |
VGFAA778 |
Want to take someone offline Friends, Game Servers, Website? Join iBooter ! ibooter.me |
| 05:43 |
|
VGFAA778 left #evergreen |
| 06:04 |
|
b_bonner joined #evergreen |
| 06:04 |
|
b_bonner_ joined #evergreen |
| 06:23 |
|
timhome joined #evergreen |
| 07:44 |
|
BigRig_ joined #evergreen |
| 08:21 |
|
Hagerstown_Staff joined #evergreen |
| 08:28 |
|
kbeswick joined #evergreen |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:29 |
|
BigRig joined #evergreen |
| 08:42 |
|
ericar joined #evergreen |
| 08:44 |
|
akilsdonk_ joined #evergreen |
| 08:46 |
|
tspindler joined #evergreen |
| 08:52 |
|
kmlussier joined #evergreen |
| 09:15 |
|
bkuhn joined #evergreen |
| 09:25 |
senator |
pinesol_green: ping |
| 09:25 |
pinesol_green |
pong |
| 09:27 |
jcamins |
Does anyone know of any EG sites that use MARC-AMC? |
| 09:27 |
jcamins |
Or whatever we're calling it these days. |
| 09:28 |
jcamins |
Bonus points if you can think of a site that uses both collection-level and item-level records instead of just collection-level. |
| 09:29 |
jcamins |
Double bonus points if the library uses TPAC. |
| 09:33 |
csharp |
I don't know of any libraries that do much in the way of archives using EG |
| 09:34 |
csharp |
yboston (Yamil Suarez) works for a music library, so that may be close (but I don't know that ;-) ) |
| 09:35 |
jcamins |
I will poke their catalog a bit and see if I can figure it out. |
| 09:35 |
jcamins |
Assuming I can find their library on the website. |
| 09:35 |
jeff |
aren't all the cool kids using ArchivesSpace now? :-) |
| 09:35 |
jcamins |
jeff: probably. |
| 09:36 |
jcamins |
Woohoo! It's TPAC! |
| 09:36 |
csharp |
yay |
| 09:36 |
jcamins |
Does anyone know how to search by LDR/06 in Evergreen? |
| 09:39 |
|
collum joined #evergreen |
| 09:40 |
dbs |
jcamins: On our catalogue, I think that would be advanced search -> Item Type search filter (but you still need at least a keyword) |
| 09:40 |
dbs |
http://laurentian.concat.ca/eg/opac/advanced?loc=105 for example |
| 09:40 |
jcamins |
dbs: so if my desired item type isn't listed, it probably isn't in the catalog? |
| 09:40 |
jcamins |
Thanks. |
| 09:41 |
dbs |
jcamins: well, all LoC item types valid for LDR//06 are represented in the filter, but yeah. that, or the search timed out. |
| 09:42 |
|
Dyrcona joined #evergreen |
| 09:43 |
dbs |
jcamins: as a truly advanced user, you could directly add "item_type(j)" to your query to limit to musical recordings (as that's what the advanced UI effectively does) |
| 09:43 |
jcamins |
dbs: yeah, once you clued me in to the limit, I started trying that. |
| 09:43 |
jcamins |
And it worked! :D |
| 09:46 |
dbs |
glorious |
| 09:46 |
* paxed |
tries to create his own search filters, once again... |
| 09:47 |
jcamins |
dbs: I presume you won't mind if I provide a link to your OPAC as an example of how Evergreen handles archival records just fine? |
| 09:47 |
dbs |
jcamins: not at all |
| 09:47 |
dbs |
we might be upgrading over the weekend, but otherwise we're pretty stable :) |
| 09:49 |
jcamins |
And, final question: there are no technical impediments to using OCLC/Worldcat with Evergreen, are there? I should probably ask before I blithely assure catalogers that "Evergreen will work with OCLC out-of-the-box as well." |
| 09:50 |
dbs |
Depends on what you mean by "work with OCLC" - I've exported records for inclusion in WorldCat, but we don't catalogue via OCLC. I know other sites do, though. |
| 09:51 |
* dbs |
out for a bit |
| 09:51 |
jcamins |
That answers my question. Thanks. |
| 09:51 |
csharp |
jcamins: our catalogers work in OCLC connexion then import the records from OCLC into EG via z39.50 |
| 09:52 |
bshum |
jcamins: There's also some tool that can stream marc imports from connexion into Evergreen directly. (though we don't use it, because our catalogers like importing the old fashioned way) |
| 09:52 |
csharp |
jcamins: we're working on getting marc_export working to send batch holdings updates to them too |
| 09:52 |
bshum |
tool/script |
| 09:52 |
Dyrcona |
csharp jcamins Our catalogers currently do the same, but we're working on alternatives. |
| 09:53 |
Dyrcona |
bshum: do you think bug 965656 should be targeted at 2.3 and 2.4 as well as master/2.5? |
| 09:53 |
pinesol_green |
Launchpad bug 965656 in Evergreen "Close transactions after fines are voided, " (affected: 7, heat: 38) [Medium,Confirmed] https://launchpad.net/bugs/965656 |
| 09:54 |
bshum |
Dyrcona: Probably. |
| 09:54 |
bshum |
Dyrcona: There's alot of old bugs that need refreshing of series targets. |
| 09:55 |
Dyrcona |
bshum: Yep. I'm also working on that one this morning, at least one aspect of it. |
| 10:10 |
Dyrcona |
paxed++ #busy making i18n branches |
| 10:11 |
paxed |
only if i did those right :P |
| 10:14 |
paxed |
also, those seemed like something i could do, and doing those will get it fixed faster... |
| 10:33 |
* Dyrcona |
disappears into OpenILS::Application::Circ::* |
| 10:34 |
* csharp |
calls the OpenILS::Application::Circ::Dyrcona subroutine |
| 10:36 |
bshum |
dbwells: I've been thinking we've got less bug churn now that we're not actively moving milestones for bugs that don't have actual code being reviewed yet. The 2.5-m1 milestone still does have targeted bugs with no code, but it's the only milestone that does. |
| 10:36 |
bshum |
dbwells: So bug churn has been significantly reduced already. |
| 10:36 |
bshum |
But we can think more on that if you'd like. |
| 10:39 |
bshum |
I guess what I would have done would be to move all m1 bugs with unfinished pullrequests to m2. And then untarget m1 bugs with no retargeting to m2 if they don't have active working code on them yet. |
| 10:41 |
|
zerick joined #evergreen |
| 10:43 |
|
dboyle joined #evergreen |
| 10:50 |
bshum |
senator: re bug 1172373, we're playing vacation tag on this one (Mary is out this week) so I might not get everything sorted till later. |
| 10:50 |
pinesol_green |
Launchpad bug 1172373 in Evergreen 2.4 "Acq: In EDI invoices, avoid taking reference to PO too seriously" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1172373 |
| 10:51 |
senator |
bshum: understood. no pressure as far as i'm concerned. thanks. |
| 10:51 |
bshum |
senator: That said, I think the issue is as you've described, B&T slipped in order data from sources outside of Evergreen |
| 10:52 |
bshum |
Turns out something like the selection list name in Evergreen was being used by the library to create a purchase order in B&T's side of things. |
| 10:52 |
dbwells |
bshum: Part of what I have asked people to do is to deliberately target bugs at future milestones as a planning mechanism. That suggestion implies targetting things without code. Should I rethink that? |
| 10:52 |
bshum |
And some of that data made its way into the EDI data |
| 10:53 |
gmcharlt |
dbwells: well, targetting a bug to a milestone doesn't in and of itself mean that anybody will take it up |
| 10:54 |
bshum |
dbwells: I think if people make the move to target their bug to a particular milestone (and not us - the wranglers) then that's good faith commitment from them to try working on the bug. And if it doesn't end up with code on it and we end up shifting it along, that's fine. |
| 10:55 |
dbwells |
gmcharlt: I don't mean assignment, I mean as an (loose) promise of the person doing the targetting. |
| 10:55 |
bshum |
But there are plenty of bugs that got assigned to m1 that were just shifted from 2.4 alpha as part of my moving things a couple months back before I came to the understanding of using more proactive series targeting. |
| 10:55 |
dbwells |
i.e. I am working on such-and-such, and expect it to land here. |
| 10:56 |
dbwells |
Maybe it is enough to say that bugs get targeted when there is either code or a strong intention of code :) |
| 10:56 |
bshum |
dbwells: In the case of "I am working on such and such, it might be helpful to use the bug assignments to indicate ownership of the bug then. In addition to milestone targeting. |
| 10:57 |
gmcharlt |
dbwells: OK, that's along the lines of what I was thinking (i.e., somebody who is working on or expecting to work on it doing the initial targeting) |
| 10:57 |
bshum |
That way we know there are people supposedly paying attention to them. |
| 10:57 |
bshum |
For those of us wrangling |
| 10:58 |
phasefx |
and if a bug needs advocacy, not having a milestone gives some impetus |
| 10:58 |
pinesol_green |
[evergreen|Angela Kilsdonk] Edits to documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3087ab4> |
| 11:01 |
bshum |
Okay, for an example of the kind of bug I'm reluctant to assign back to a milestone without more action... |
| 11:01 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1084732 |
| 11:01 |
pinesol_green |
Launchpad bug 1084732 in Evergreen "tpac: copy location filter missing from tpac" (affected: 4, heat: 24) [Wishlist,Confirmed] |
| 11:01 |
bshum |
Has been kicking around since reported and shifted from milestone to milestone without any takers |
| 11:02 |
bshum |
That's the sort of bug I'd like to see removed from active milestones unless someone takes active interest in it. |
| 11:02 |
bshum |
If only because we always shuffle them along because yes they're important, but no, nobody writes new code to address it. |
| 11:03 |
dbwells |
Okay, thanks for the clarifications, everyone. So a bug is only targeted if a) it has a valid pullrequest or b) it is assigned to (i.e. claimed by) someone, and that someone has set the target themselves to communicate expectations. |
| 11:06 |
|
jdouma joined #evergreen |
| 11:06 |
dbwells |
I'll go ahead and make the current m1 targetted bugs conform to this, and that will greatly reduce the mindless zombie bugs which wander from target to target indefintely. |
| 11:08 |
bshum |
dbwells: That sounds like a good summary of the new approach we're trying with the bugs. Thanks! |
| 11:08 |
bshum |
dbwells++ |
| 11:12 |
pastebot |
"Dyrcona" at 204.193.129.146 pasted "finish fines and voiding" (23 lines) at http://paste.evergreen-ils.org/17 |
| 11:13 |
Dyrcona |
berick: Can you tell me the reason for line 2782 in OpenILS::Application::Circ::Circulate.pm? It has your name on it. It also runs counter to what is desired in lp 965656. |
| 11:13 |
pinesol_green |
Launchpad bug 965656 in Evergreen "Close transactions after fines are voided, " (affected: 7, heat: 38) [Medium,Confirmed] https://launchpad.net/bugs/965656 |
| 11:14 |
Dyrcona |
I've pasted the whole function in the paste above. The line in question is the call to reopen the xact. |
| 11:16 |
Dyrcona |
I just want to know before I go changing things. |
| 11:16 |
|
ktomita joined #evergreen |
| 11:19 |
|
acoomes joined #evergreen |
| 11:22 |
berick |
Dyrcona: can check in a bit |
| 11:22 |
bshum |
@hate apostrophes in search |
| 11:22 |
pinesol_green |
bshum: The operation succeeded. bshum hates apostrophes in search. |
| 11:22 |
tsbere |
@hate search |
| 11:22 |
pinesol_green |
tsbere: The operation succeeded. tsbere hates search. |
| 11:22 |
tsbere |
My hate is more general ;) |
| 11:23 |
bshum |
tsbere++ |
| 11:36 |
|
DPearl joined #evergreen |
| 11:45 |
DPearl |
Help! I'm installing opensrf on a new machine and it is not starting up. The srfsh test failed with "unable to bootstrap client". It looks like the router is failing. |
| 11:46 |
DPearl |
I have checked and rechecked the ejabber users, and they look fine. |
| 11:47 |
DPearl |
The .srfsh.xml is fine. |
| 11:47 |
phasefx |
if you grep your osrfsys.log for ERR, what's the first hit there? |
| 11:49 |
DPearl |
opensrf 2013-06-11 11:03:25 [ERR :13433:osrf_system.c:228:] Unable to bootstrap for host localhost from configuration file /openils/conf/opensrf_core.xml |
| 11:51 |
tsbere |
I would check that the xml file in question exists and is valid XML |
| 11:51 |
* Dyrcona |
was about to suggest the same. |
| 11:52 |
Dyrcona |
Also that the user that runs opensrf can read it. |
| 11:52 |
phasefx |
and if you used -l with osrf_ctrl.sh, then your opensrf.xml should also have a <localhost> entry under <hosts> |
| 11:52 |
DPearl |
Lots to check. Standby.. |
| 11:56 |
berick |
Dyrcona: the comment for Circulate.pm:2782 is misleading. it should be more like, "make sure the circ isn't closed if voiding these fines caused the transaction to go from balance_owed == 0 to balance_owed != 0" |
| 11:56 |
* berick |
notes that CircCommon->reopen_xact will only reopen a transaction if it's supposed to be open |
| 11:57 |
Dyrcona |
berick: The reality is backdated checkins that void fines are never closed. |
| 11:57 |
Dyrcona |
berick: So I could add a line or two to say if the xact is open and balance == 0 and then close the xact? |
| 11:59 |
berick |
Dyrcona: that sounds sane to me. |
| 11:59 |
berick |
i.e. forcing the xact into the correct state, regardless of the state it's in |
| 11:59 |
Dyrcona |
ok will do. |
| 12:00 |
berick |
i've long thought we should push the xact_close-setting logic into a DB trigger |
| 12:00 |
berick |
i bugs me how spread through the code that stuff is |
| 12:00 |
Dyrcona |
me, too. |
| 12:00 |
berick |
s/i/it/ |
| 12:00 |
|
ldwhalen joined #evergreen |
| 12:00 |
Dyrcona |
I told bshum in private earlier that I have to fight the urge to refactor Circulate.pm |
| 12:01 |
berick |
indeed, it has grown into a very awkward teenager |
| 12:01 |
|
ktomita_ joined #evergreen |
| 12:01 |
|
jdouma joined #evergreen |
| 12:02 |
Dyrcona |
So, I'll add a couple of lines to check for 0 balance and close the xact if it is open below the reopen xact call. |
| 12:02 |
|
bkuhnIdl` joined #evergreen |
| 12:02 |
Dyrcona |
We can figure out an overall reorganization of the circ code later. :) |
| 12:02 |
paxed |
eeevil: re the search filters... i just can't it to work. |
| 12:02 |
DPearl |
tsbere: xml files are still valid xml |
| 12:03 |
DPearl |
phasefx: localhost present |
| 12:03 |
berick |
Dyrcona: fwiw, Money.pm:_check_open_xact() will do both, open or close as necessary. could move that into AppUtils or some such and replace reopen_xact w/ that. just a thought |
| 12:04 |
berick |
and w/ that, i'll leave it in yr capable hands |
| 12:04 |
Dyrcona |
berick: Ok. |
| 12:04 |
tsbere |
DPearl: Who owns the xml file and what is the mode string on it? You haven't mentioned if it can be read by the right user yet ;) |
| 12:05 |
DPearl |
I went to the user and cat-ted the file. |
| 12:06 |
|
csharp_ joined #evergreen |
| 12:06 |
Dyrcona |
berick: I'll move _check_open_xact to AppUtils and make the appropriate changes. |
| 12:06 |
berick |
Dyrcona++ |
| 12:07 |
DPearl |
tsbere: opensrf/opensrf owns the .xml files and rights are 644 |
| 12:09 |
DPearl |
tsbere: ejabberd complains only of auth. of "router" user. The opensrf user is ok. I(<0.585.0>:ejabberd_c2s:508) : ({socket_state,gen_tcp,#Port<0.1871>,<0.584.0>}) Failed le gacy authentication for router private.localhost/router |
| 12:11 |
tsbere |
DPearl: Check passwords! ;) |
| 12:12 |
DPearl |
tsbere: I'll try it again ;-{ |
| 12:12 |
phasefx |
DPearl: stay away from special characters in the passwords |
| 12:13 |
DPearl |
phasefx: My passwords were just ascii letters, alas. |
| 12:13 |
bshum |
You could try purging ejabberd (and its config) and then starting over with just that piece of it. |
| 12:14 |
|
edoceo joined #evergreen |
| 12:14 |
* bshum |
tended to do that whenever he mucked up hostnames or passwords |
| 12:14 |
DPearl |
bshum: Not quite sure how to do that. I have restarted ejabberd regularly, but it didn't help |
| 12:16 |
bshum |
DPearl: This is a bad shotgun approach, but it's something like "apt-get purge ejabberd" and then "apt-get install ejabberd" and then re-run through config changes and re-registering user/pass. |
| 12:17 |
bshum |
(there may be better ways, but if you're starting over anyways...) |
| 12:17 |
DPearl |
bshum: Wow! You don't mess around! I'll try it. |
| 12:19 |
gmcharlt |
DPearl: on Debianish, stopping ejabberd, clearing out the contents of /var/lib/ejabberd, then starting and reregistering has the same effect |
| 12:20 |
gmcharlt |
and saves you a step of redoing your ejabberd.cfg changes |
| 12:21 |
DPearl |
gmcharlt: Thanks |
| 12:25 |
|
mcooper joined #evergreen |
| 12:28 |
pastebot |
"DPearl" at 204.193.129.146 pasted "router.log output" (17 lines) at http://paste.evergreen-ils.org/18 |
| 12:29 |
DPearl |
Still no joy.. |
| 12:30 |
|
ktomita joined #evergreen |
| 12:31 |
|
jihpringle joined #evergreen |
| 12:35 |
pastebot |
"DPearl" at 204.193.129.146 pasted "opensrf.log" (51 lines) at http://paste.evergreen-ils.org/19 |
| 12:36 |
|
bkuhn joined #evergreen |
| 12:42 |
DPearl |
phasefx: For fun, I changed passwords...again. Same authentication errors. |
| 12:47 |
pastebot |
"DPearl" at 204.193.129.146 pasted "ejabberd log" (189 lines) at http://paste.evergreen-ils.org/20 |
| 12:47 |
|
mmorgan1 joined #evergreen |
| 12:54 |
|
mmorgan1 left #evergreen |
| 12:55 |
|
mmorgan joined #evergreen |
| 12:58 |
|
acoomes_ joined #evergreen |
| 13:04 |
|
kmlussier joined #evergreen |
| 13:11 |
|
yboston joined #evergreen |
| 13:15 |
|
csharp joined #evergreen |
| 13:16 |
csharp |
bshum: re: apostrophes in search, what are you seeing happen? |
| 13:17 |
bshum |
csharp: Today's new fun was somebody complaining about using "matches exactly" against a title search |
| 13:17 |
csharp |
ah - I think we've heard that too |
| 13:17 |
bshum |
The terms they used included an apostrophe, so we're wondering if that affected it. |
| 13:17 |
bshum |
But matches exactly is wacky weird anyways |
| 13:17 |
csharp |
right |
| 13:18 |
csharp |
DPearl: this is your key line: "opensrf 2013-06-11 12:28:56 [ERR :2118:osrf_system.c:228:] Unable to bootstrap for host localhost from configuration file /openils/conf/opensrf_core.xml" |
| 13:18 |
bshum |
csharp: The one that's more troublesome is unresolved bug 1187433 |
| 13:18 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433 |
| 13:19 |
csharp |
bshum: so that's with the new QP in place, yes? |
| 13:19 |
bshum |
But that's a 2.4 issue where using the term without the apostrophe (or space) breaks |
| 13:19 |
bshum |
Correct, new QP introduced in 2.4 |
| 13:19 |
* csharp |
sees dbs's comment that shows that 2.3 doesn't have the problem |
| 13:20 |
bshum |
Right. |
| 13:22 |
bshum |
csharp: Are you seeing oddness with apostrophe searching too? |
| 13:25 |
DPearl |
csharp: So what problem do you suspect? |
| 13:29 |
|
stevenyvr2 joined #evergreen |
| 13:41 |
|
mjingle joined #evergreen |
| 13:46 |
csharp |
DPearl: can you cleanse /openils/conf/opensrf_core.xml and /etc/ejabberd/ejabberd.cfg of passwords/other sensitive info and pastebin them? |
| 13:48 |
|
tspindler left #evergreen |
| 13:50 |
DPearl |
csharp: will do |
| 13:52 |
pastebot |
"DPearl" at 204.193.129.146 pasted "ejabberd cfg" (644 lines) at http://paste.evergreen-ils.org/21 |
| 13:53 |
csharp |
that looks okay to me |
| 13:54 |
pastebot |
"DPearl" at 204.193.129.146 pasted "opensrf core" (161 lines) at http://paste.evergreen-ils.org/22 |
| 13:55 |
csharp |
DPearl: can you also pastebin /openils/conf/opensrf.xml? |
| 13:55 |
DPearl |
csharp: The only changes I made to the core file is log level and usernames/passwords |
| 13:55 |
csharp |
k |
| 13:59 |
bshum |
kmlussier++ # screencast for bug 1187993 |
| 13:59 |
pinesol_green |
Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1187993 |
| 14:00 |
kmlussier |
bshum: I thought it would be easier to follow than the novel I wrote in my initial report. :) |
| 14:00 |
* bshum |
wishes for more soothing voices. |
| 14:00 |
csharp |
kmlussier++ |
| 14:00 |
|
ericar joined #evergreen |
| 14:02 |
paxed |
perhaps the autosuggest could be set to "always on", "disabled", "let patron choose, default to off", "let patron choose, default to on" in YAOUS |
| 14:02 |
* bshum |
dislikes that |
| 14:03 |
bshum |
For many reasons. |
| 14:03 |
|
ktomita joined #evergreen |
| 14:04 |
kmlussier |
I like the idea of letting the patron choose because some users love autosuggest and some hate it. |
| 14:05 |
kmlussier |
But, if you were promoting the autosuggest feature, you would probably want the default to be "on" (otherwise, how would a patron know to turn it on?), so you still would come across the accessibility issue. |
| 14:06 |
dbs |
we should probably default to "off" for anything known to introduce an accessibility issue as serious as that |
| 14:08 |
paxed |
detection via User Agent? |
| 14:08 |
paxed |
or whatever? |
| 14:09 |
dbs |
We should just turn it off until we have a properly working version available. |
| 14:09 |
bshum |
dbs: +1 |
| 14:10 |
bshum |
paxed: I'm not fully up to speed with the details, but I think the screen reader just works alongside the browser, so there's no clear indication whether they're using one or not vs. just using a browser. |
| 14:10 |
paxed |
bshum: ah... right. |
| 14:10 |
kmlussier |
Yup. I was using standard browsers in my own testing. |
| 14:12 |
senator |
if dijit removes the aria-label attribute, can the problem be solved by adding it back to some <span> element surrounding the input widget? or is there more to it than that? |
| 14:13 |
* dbs |
looks at Driver/Pg/QueryParser.pm and wonders if line 311/312 is where the pain in apostrophe searching arrives |
| 14:13 |
* bshum |
peruses |
| 14:13 |
dbs |
this code could use some comments, and maybe some more expressive var names. $c looks pretty important, just have to figure out what it is |
| 14:14 |
dbs |
a boolean for "is combined" I guess |
| 14:15 |
akilsdonk_ |
kmlussier: it looks like all the new documentation has been processed into 2.4 now. |
| 14:17 |
kmlussier |
senator: I don't know much about the code, but I wouldn't be surprised if the problem goes beyond the arial-label attribute. 2.2 catalogs didn't use the arial-label attribute, and, if autosuggest wasn't enabled, you could still identify the correct form elements by tabbing or using the JAWS commands. But that was just my uneducated gut feeling when I was testing. |
| 14:18 |
kmlussier |
akilsdonk_++ Thanks! Of course, now that it's displaying, I now see I neglected to make some changes to the root file. |
| 14:20 |
akilsdonk_ |
kmlussier: Yeah, I had to make a few changes too. :) Thank you! |
| 14:20 |
akilsdonk_ |
kmlussier++ dbs++ rsoulliere++ We have docs! |
| 14:20 |
kmlussier |
http://www.nomensa.com/blog/2011/how-do-you-detect-a-screen-reader/ tells us we can't detect screen readers. |
| 14:20 |
dbs |
akilsdonk++ |
| 14:28 |
|
ldwhalen joined #evergreen |
| 14:31 |
|
ldw joined #evergreen |
| 14:32 |
paxed |
apart from eeevil, does anyone else know about making your own search filters? |
| 14:35 |
eeevil |
paxed: my ears just started burning ... AND! I have a few minutes to look at your server, if you still want |
| 14:36 |
paxed |
eeevil: go ahead. i recreated the filter stuff and reingested the bibs, and no worky. |
| 14:37 |
dbs |
Oh, hello. I just noticed that the queries for 2.4 search use the 'simple' text configuration. Which means no stemming algorithm gets applied. Which means "mens" stays as "mens", not "men". Which may be pertinent. |
| 14:37 |
* eeevil |
ssh's |
| 14:38 |
bshum |
dbs: Sounds important. |
| 14:38 |
eeevil |
dbs: that's only in weigh-slot A. slot C should be using the english snowball stemmer, without a stopword list |
| 14:39 |
eeevil |
dbs: if you're /not/ seeing weight C lexems, there's an issue (and the search terms should get the same treatment, sans actual weighting, of course, because tsquery's don't have weights) |
| 14:40 |
dbs |
eeevil: there is a very significant issue |
| 14:40 |
eeevil |
tsbere: let's loop you into what dbs is seeing |
| 14:42 |
* tsbere |
is hereish but wasn't paying a lot of attention to IRC |
| 14:43 |
eeevil |
dbs: mind pasting some contents from, say, metabib.title_field_entry? |
| 14:44 |
|
kmlussier1 joined #evergreen |
| 14:45 |
dbs |
eeevil: man, I've posted this to the bug already |
| 14:45 |
dbs |
like a week ago |
| 14:46 |
eeevil |
do you have the bug # handy? |
| 14:46 |
dbs |
And I've just confirmed that to_tsquery('simple', blah(blah('mens')) returns "mens" which will _not_ match fe.index_vector, whereas to_tsquery('english_nostop', blah(blah('mens')) returns "men" which does match fe.index_vector |
| 14:46 |
dbs |
which of course does contain both stemmed and non-stemmed versions of "men's" in different weights |
| 14:47 |
dbs |
bug 1187433 |
| 14:47 |
pinesol_green |
Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433 |
| 14:47 |
dbs |
I'll add a sample of the full query that gets generated by QP |
| 14:54 |
dbs |
On the bright side, this suggests that 2.4 sites don't need to reindex again. We just need to figure out where in the twisty maze of QP 'simple' should be replaced by 'english_nostop' or the like appropriately. |
| 14:54 |
dbs |
Oh, I think I see it. We set the class_ts_config to 'english_nostop' to begin with, then promptly stomp on it with 'simple' |
| 14:54 |
eeevil |
it should be getting both simple /and/ stemmed ||'d together |
| 14:55 |
eeevil |
IIRC |
| 14:55 |
eeevil |
hrm... maybe not |
| 14:55 |
* eeevil |
thinks more |
| 14:55 |
dbs |
Check line 583 of Driver/Pg/QueryParser.pm |
| 14:55 |
tsbere |
dbs: Isn't that the *test* setup, where we don't have a DB to pull things from? |
| 14:56 |
dbs |
tsbere: I dunno, I'm just trying to unravel this! |
| 14:58 |
dbs |
so "config_metabib_class_ts_map" should bring us DB-based config? |
| 14:59 |
dbs |
I have simple -> A, english_nostop -> C in my test config.metabib_class_ts_map table. Doesn't seem to be resulting in any english_nostop in the actual queries. |
| 14:59 |
tsbere |
we *do* assume "just simple" if we don't have any info, so if something is broken on the "fetch from DB" side of things that would be the only thing we got... |
| 15:00 |
dbs |
Sounds like something might be broken (quite consistently) then. |
| 15:00 |
dbs |
As this has been confirmed on all sites running 2.4 |
| 15:01 |
dbs |
1427 lines of gnarly code, with about 1 comment every 50 lines :/ |
| 15:02 |
dbs |
Only Publisher/metabib.pm attempts to set config_metabib_class_ts_map it seems. |
| 15:10 |
* eeevil |
suspects a typo in the initialization code (simply due to a gut feeling and another instance of that from before) |
| 15:10 |
tsbere |
dbs: Sometimes no comments are better than out of date or otherwise incorrect comments..... |
| 15:11 |
dbs |
tsbere: Getting punched in the face is better than getting stabbed, too! |
| 15:12 |
dbs |
But I don't want either to happen to me :) |
| 15:12 |
tsbere |
dbs: I would rather try and understand code with good, up to date comments. This is followed by no comments at all. Understanding code with out of date and incorrect comments is a headache inducer and usually results in me running a "remove all the comments" script and starting over ;) |
| 15:15 |
jcamins |
dbs: I recommend against belonging to a cat in that case. In the past two days I have been both stabbed *and* punched in the face by my owner in protest over the way I was trying to type instead of paying attention to him. |
| 15:18 |
dbs |
meanwhile, actually looking at the code, the comment leading into good old line 1249 gives us the clue: " # Assume we want exact if none otherwise provided. |
| 15:18 |
dbs |
# Because we can reasonably expect this to exist |
| 15:18 |
dbs |
$ts_configs = ['simple'] unless (scalar @$ts_configs); |
| 15:18 |
dbs |
swap 'simple' out with 'english_nostop' and "mens health" matches "men's health". Thank you, comment! |
| 15:21 |
|
isl-JBoyer joined #evergreen |
| 15:22 |
mrpeters |
welcome isl-JBoyer ;) |
| 15:22 |
isl-JBoyer |
Hey |
| 15:22 |
mrpeters |
for those who don't know....isl-Jboyer is a wicked talented Evergreener |
| 15:23 |
isl-JBoyer |
In small doses, babysteps, etc. |
| 15:23 |
eeevil |
dbs: right, but the problem is that ~1238 isn't finding english_nostop for the keyword class. (for those playing along at home) |
| 15:23 |
dbs |
eeevil: yes, pretty much exactly what my comment in the bug just said |
| 15:24 |
dbs |
For those playing along in the future. |
| 15:24 |
eeevil |
dbs: sorry, looking here and the code instead of hitting refresh on the bug |
| 15:24 |
eeevil |
;) |
| 15:24 |
eeevil |
thinking_of_the_future++ |
| 15:25 |
jeff_ |
isl-JBoyer++ welcome! |
| 15:26 |
dbs |
eeevil: actually, note that all of my tests have been against the 'title' field |
| 15:27 |
eeevil |
dbs: consider it noted |
| 15:27 |
dbs |
hmm, and config.metabib_field_ts_map is devoid of rows on our test database |
| 15:27 |
eeevil |
using_the_same_words_for_testing++ |
| 15:27 |
eeevil |
well... that's something |
| 15:28 |
eeevil |
if, with those, it still fails ... it be code problems. |
| 15:28 |
eeevil |
well, no |
| 15:28 |
eeevil |
that's only used for fielded searches. title|proper: foo |
| 15:28 |
tsbere |
dbs: You want config.metabib_class_ts_map, I think... |
| 15:29 |
dbs |
tsbere: yeah, that's populated |
| 15:29 |
dbs |
per 14:59 < dbs> I have simple -> A, english_nostop -> C in my test config.metabib_class_ts_map table. Doesn't seem to be resulting in any english_nostop in the actual queries |
| 15:29 |
dbs |
and 15:02 < dbs> Only Publisher/metabib.pm attempts to set config_metabib_class_ts_map it seems. |
| 15:31 |
|
ldwhalen joined #evergreen |
| 15:39 |
eeevil |
found it... |
| 15:39 |
dbs |
yay |
| 15:39 |
eeevil |
we're not loading the class->ts mapping |
| 15:39 |
eeevil |
the calling code in open-ils.search calls the fts wrapper |
| 15:40 |
eeevil |
the wrapper has an initialize block instead of using _initialize($parser) |
| 15:40 |
eeevil |
once /any/ initialization has occurred, we never reinitialize the parser singleton (well, effective singleton) |
| 15:41 |
eeevil |
and the wrapper's block does not do the class and field to ts config mapping |
| 15:42 |
eeevil |
dbs: I'll toss a patch on the bug for you to test, if you want |
| 15:44 |
* bshum |
has been watching quietly and can help test too. |
| 15:44 |
bshum |
If I don't get carried away by flood waters that is. |
| 15:44 |
bshum |
Crazy rain. |
| 15:46 |
eeevil |
bshum: it's attached now |
| 15:52 |
* tsbere |
is not surprised he missed that when figuring out the parser initializations |
| 15:56 |
dbs |
eeevil++ |
| 15:59 |
bshum |
eeevil++ |
| 16:08 |
dbs |
Looks like it works in my limited tests |
| 16:10 |
bshum |
Likewise |
| 16:11 |
bshum |
Or at least, we get results where we didn't before. |
| 16:14 |
* dbs |
added more details to the bug |
| 16:25 |
* eeevil |
adds some more... |
| 16:42 |
eeevil |
I'll toss up a branch with that patch embedded |
| 16:52 |
eeevil |
pullrequested branch with targets for 2.4+ |
| 17:04 |
|
evergreen joined #evergreen |
| 17:05 |
|
cr-ver joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:13 |
|
mrpeters left #evergreen |
| 17:29 |
jeffdavis |
anyone have experience using automatic updates to update staff clients remotely during a major version upgrade to 2.4? |
| 18:00 |
|
dbwells joined #evergreen |
| 18:37 |
|
acoomes joined #evergreen |
| 18:58 |
|
ldwhalen joined #evergreen |
| 19:21 |
|
mjingle left #evergreen |
| 19:27 |
bshum |
jeffdavis: We have used auto update for all upgrades since we first got onto a version that made use of them. |
| 19:28 |
bshum |
jeffdavis: As far as I'm aware, most everything "just works". Though there's always the few stragglers who don't have admin rights to perform the update (schools with locked down IT, etc.) |
| 19:29 |
bshum |
One time I messed up the chain of upgrade, and it forced everybody to redownload the full client to reacquire the new chain of upgrades. |
| 19:29 |
|
ldwhalen joined #evergreen |
| 19:30 |
jeff |
meanwhile, we use wpkg for deploying our updates. |
| 19:30 |
bshum |
Otherwise, it wasn't bad. And we did upgrade our folks from master to master builds, including the big code bits that went from 2.3 to 2.4. (well, and 2.2) |
| 19:30 |
jeff |
mostly since we've been doing that since 1.2 days, and because we operate in an environment where user accounts are not local administrator accounts. |
| 19:55 |
|
stevenyvr2 left #evergreen |
| 20:58 |
|
ldwhalen joined #evergreen |
| 21:48 |
|
ldwhalen joined #evergreen |
| 22:37 |
|
ldwhalen joined #evergreen |
| 22:44 |
|
ldwhalen_mobile joined #evergreen |
| 23:11 |
jeffdavis |
hm, not sure what I'm doing wrong |
| 23:12 |
jeffdavis |
any variant on 'make updates' results in this: |
| 23:12 |
jeffdavis |
Making full update |
| 23:12 |
jeffdavis |
external/make_updates.sh: line 182: /home/sitkastaff/evergreen/Open-ILS/xul/staff_client/external/mar: No such file or directory |
| 23:12 |
jeffdavis |
yet that file exists, is world-readable and world-executable |
