Evergreen ILS Website

IRC log for #evergreen, 2014-03-07

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to the server's local time.

Time Nick Message
00:04 kmlussier joined #evergreen
01:11 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
02:21 berick joined #evergreen
02:53 gsams joined #evergreen
02:53 mtj_ joined #evergreen
02:53 jboyer-isl joined #evergreen
02:53 Guest12083 joined #evergreen
02:53 mtcarlsoz joined #evergreen
02:53 timhome joined #evergreen
02:53 fparks_ joined #evergreen
02:53 Callender joined #evergreen
02:53 rri joined #evergreen
02:53 ningalls joined #evergreen
02:53 gmcharlt joined #evergreen
02:53 sseng joined #evergreen
02:53 Bmagic|2 joined #evergreen
02:53 _bott_ joined #evergreen
02:53 kayals joined #evergreen
02:53 artunit joined #evergreen
02:53 dreuther joined #evergreen
02:53 wjr joined #evergreen
02:53 tfaile_ joined #evergreen
02:53 shadowspar joined #evergreen
02:53 phasefx joined #evergreen
02:53 BigRig joined #evergreen
02:53 mtate joined #evergreen
02:53 RBecker joined #evergreen
02:53 rangi joined #evergreen
02:53 remingtron__ joined #evergreen
02:53 berickm joined #evergreen
02:53 b_bonner joined #evergreen
02:53 graced joined #evergreen
02:53 dconnor_ joined #evergreen
02:53 eby joined #evergreen
02:53 eeevil joined #evergreen
02:53 phasefx2_ joined #evergreen
02:53 book` joined #evergreen
02:53 pastebot joined #evergreen
02:53 csharp joined #evergreen
02:53 egbuilder joined #evergreen
02:53 paxed joined #evergreen
02:53 jcamins joined #evergreen
02:53 pmurray joined #evergreen
02:57 old_people joined #evergreen
03:51 DPearl joined #evergreen
03:57 berick joined #evergreen
03:58 DPearl1 joined #evergreen
04:12 DPearl joined #evergreen
04:31 gsams joined #evergreen
07:07 kmlussier joined #evergreen
07:46 collum joined #evergreen
07:54 bshum dbwells: Fwiw, 0864 completed on our production hardware in 29m57.139s
07:54 bshum So I guess things will probably be okay.
07:55 akilsdonk joined #evergreen
08:06 Shae joined #evergreen
08:38 eby joined #evergreen
08:40 mmorgan joined #evergreen
08:45 bshum Doh
08:46 bshum eeevil: Putting one more tiny adjustment for 0870 from yesterday to fix the located URIs
08:50 ericar joined #evergreen
08:51 bshum Okay, we're good now.
08:52 pinesol_green [evergreen|Ben Shum] LP1288938 - final adjustments for 0870 upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=19f4385>
08:54 mrpeters joined #evergreen
09:09 jl- joined #evergreen
09:10 jl- any idea where I could download a ton of marc records? I got 1.4 million from the boston college library but I need moar
09:12 Guest30779 jl-: possibly https://archive.org/details/ol_data
09:13 Guest30779 er.
09:13 Guest30779 joined #evergreen
09:15 dbwells jl-: How about this? http://openmetadata.lib.harvard.edu/bibdata
09:15 jeff jl-: in addition to the data set at archive.org for openlibrary, there's a batch (or two!) of gutenberg records here: http://www.gutenberg.org/wik​i/Gutenberg:Offline_Catalogs
09:15 jeff dbwells++
09:17 dluch joined #evergreen
09:20 * dbwells creates a '--load-sample-harvard' option, watches his test machine go up in smoke
09:21 jeff --generate-random-bibs
09:21 jeff --count 100M
09:31 yboston joined #evergreen
09:37 jl- thx
09:44 RoganH joined #evergreen
09:48 dbs jl-: archive.org has a bunch of sets of MARC records, like https://archive.org/details​/marc_records_scriblio_net
09:49 dbs https://archive.org/search.php?query=%28m​arc%29%20AND%20collection%3A%28ol_data%29 is a good search
09:50 wlayton joined #evergreen
09:51 jl- 12 million from harvard should be good
09:51 * dbs sees he's basically repeated jeff
09:51 * dbs waves at wlayton
09:52 wlayton hey everyone
09:52 bshum Hey wlayton!
09:52 wlayton for the 1st time in a while, I have some time to devote to EG
09:53 wlayton is there anything that I can help with today?
09:53 Dyrcona joined #evergreen
09:55 dbs wlayton: we're aiming for a 2.6 release real soon now, so there's always the basic "Follow the install instructions and see if you can break anything", as well as trying out and signing off on the fixes for the 2.6 blocker bugs
09:55 dbs https://bugs.launchpad.net/evergre​en/+bugs?field.tag=2.6-rc-blocker
09:55 wlayton sounds good. I'll give that a whirl
09:56 dbs wlayton++
10:24 kayals joined #evergreen
10:30 wlayton Just checking: we're still on Dojo 1.3.3?
10:30 wlayton (for evergreen 2.6)
10:31 dbs wlayton: believe it or not, yep
10:31 dbs @ana technical deficit
10:31 pinesol_green dbs: Beyond here be dragons.
10:32 dbs INDEED
10:33 wlayton I still have a Git branch kicking around from when I started trying to move things up to v1.6. I'll see if I can resurrect that.
10:34 wlayton (I think I had passed my patches on the Joe Lewis, too, when he started working on that.)
10:36 dbs In the OPAC, we're down to just one major use of Dojo (for the autosuggest widget), and I think everyone would like to see that simplified. So a TPAC-uses-Dojo-current / staff-client-uses-Dojo-ancient split could be a possibility.
10:36 dbs That said, the web-based staff client project seems likely to ditch Dojo entirely.
10:37 dbs @praise AngularJS
10:37 wlayton AngularJS, right?
10:37 * pinesol_green AngularJS is the very model of a modern major hacker
10:38 mllewellyn joined #evergreen
10:40 kmlussier dbs: Is it possible to do that (splitting the versions of Dojo between OPAC and staff client)? That question had come to my mind a while back when thinking about the autosuggest accessibility problems.
10:42 dbs kmlussier: sure, anything's possible :) We would have to be careful to avoid conflicts using the catalogue in staff client mode (don't want to introduce mysterious memory leaks for example) but it could be done.
10:48 eeevil dbs: well, ditch dojox at least ... with angular-dojo we could avoid throwing away lots of useful encapsulation
10:55 ldwhalen_ joined #evergreen
11:02 gmcharlt on account of bug 1286198, I'm going to do a RC for OpenSRF 2.3.0
11:06 geoffsams joined #evergreen
11:06 wlayton One comment for EG 2.6 install instructions: It says to install most recent version of OpenSRF "(2.2.1 or later)". Should this say "(2.3.0 or later)" or will 2.2.1 work with 2.6?
11:06 wlayton The downloads page on the website makes it look like 2.3.0 is required.
11:06 gmcharlt 2.3.0 is required
11:07 pinesol_green Launchpad bug 1286198 in OpenSRF "Improve process control at startup" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1286198
11:07 mrpeters joined #evergreen
11:09 eeevil gmcharlt: for inclusion in 2.3.0, you mean? cool!
11:09 dbwells_ joined #evergreen
11:09 gmcharlt eeevil: yep
11:09 gmcharlt eeevil: also, I'm inclined to be boring
11:09 mllewellyn joined #evergreen
11:09 gmcharlt namely, s/--are-there-no-prisons/--ignore-orphans/
11:09 eeevil ha
11:09 gmcharlt are you terribly attached to that?
11:09 eeevil sure
11:09 eeevil no, not attached
11:10 gmcharlt OK :)
11:10 eeevil I think that was senator's answer to berick's "--kill-with-fire" for shutdown with SIGKILL
11:10 gmcharlt heh, good point
11:13 kbutler joined #evergreen
11:14 gmcharlt dbwells: is it OK to use the RC-blocker tag to mark adminstrivia bugs that are nonetheless prereqs for release of 2.6?
11:14 dbwells gmcharlt: yes
11:17 Callender_ joined #evergreen
11:19 gmcharlt wlayton: https://bugs.launchpad.net/evergreen/+bug/1289450
11:19 pinesol_green Launchpad bug 1289450 in Evergreen "mark OpenSRF 2.3.0 as minimum required version" (affected: 1, heat: 6) [Low,New]
11:19 Callender__ joined #evergreen
11:22 wlayton gmcharlt: thanks!
11:23 remingtron berickm: testing your branch on bug 1281750 raised an unrelated bug, I think. Can you (or others) confirm?
11:23 pinesol_green Launchpad bug 1281750 in Evergreen 2.5 "Fetching user group info on deleted users creates unnecessary load" (affected: 2, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1281750
11:23 remingtron open-ils.actor.usergroup.leaders.retrieve always returns all users in group, but master_account='f' for all but one
11:23 remingtron my guess is 'if $u->master_account' evals the string 'f' as true?
11:24 kmlussier Hey y'all. I noticed last night that a surprising number of IRC folks hadn't added their IRC handles when registering for the conference. I suspect in most cases, it was because a central person in an org handled registrations, but there may have been cases where somebody had a reason for excluding this information.
11:25 kmlussier If it's okay to put your IRC handle on your badge and on the attendee list, could you let me know?
11:25 gmcharlt kmlussier: fine for me
11:25 dbs Fine with me
11:27 jeff i hide behind my opaque irc nickname.
11:27 kmlussier gmcharlt: And I assume you're okay with publishing your Twitter name?
11:28 jeff kmlussier: i believe i listed the requested information on the registration for both irc and twitter. :-)
11:28 gmcharlt kmlussier: yep
11:28 kmlussier jeff: Yes, you did. :)
11:28 jeff perlbrew users: this is handy: ``perlbrew list-modules | perlbrew exec --with perl-5.18.2 cpanm'' ref: http://perlbrew.pl/Reinstall-​All-Modules-On-New-Perl.html
11:29 dbwells eeevil: I was poking at bshum's funny record grouping problem a bit.  I didn't get too far is solving it, but here is what I think we may at least have a few broken assumptions in this case.
11:29 dbwells If anyone else wants to check it out, you can see the behavior here: http://spork1.biblio.org/eg/opac/results?bool=an​d;bool=and;bool=and;qtype=title;qtype=title;qtyp​e=author;contains=exact;contains=contains;contai​ns=contains;query=CONNECTICUT;query=;query=;_adv​=1;locg=1;pubdate=is;modifier=metabib;page=5
11:30 dbwells eeevil: 1) We assume that records with a common metarecord will at least share a title, or a title and an author.  In this case, we have an author == title situation (the author record has no title whatsoever).  This is certainly rare, and shouldn't happen except with questionable data.
11:30 dbwells 2) Our metarecord grabbing in get_records_and_facets() doesn't seem to be doing any deleted checks (should it?).  But when we go to count the records, we *do* check for deleted.  We then wrongly assume this metarecord has just one bib, but we've fetched two (I think).
11:31 Wyuli joined #evergreen
11:31 dbwells 3) Since we *think* we have one bib, we link directly to it, but we end up linking directly to the deleted bib we fetched.  (related questions: Should deleted bibs even have a metarecord mapping?  Is there protection against deleted bibs ending up as the 'master' record?)
11:32 dbwells It seems like we perhaps need a deleted filter at the mmr unapi level or within get_records_and_facets().  I am not sure which is better or more possible at this point, or if we need to look at yet a different layer in the stack.
11:33 dbwells eeevil: Anyway, that's just my brain dump on the matter.  It isn't code I am terribly familiar with, so take it or leave it :)
11:42 wlayton joined #evergreen
11:42 Callender joined #evergreen
11:56 kmlussier @eightball Will we get a March warm-up in 2 weeks?
11:56 pinesol_green kmlussier: Naturally.
11:56 kmlussier Hooray!
11:56 kmlussier @love magic eightball
11:56 pinesol_green kmlussier: The operation succeeded.  kmlussier loves magic eightball.
11:58 gmcharlt and thus the magic eightball gets to live another day!
12:01 eeevil dbwells: I'll look at that this afternoon, thanks for brain-dumping! unfortunately, berick has been attacked by ice, and his power is out, and we'll want him to jump into this too, I think
12:03 eeevil dbwells: the fingerprinting issue is a deficiency of the algo, and predates any of this code, of course. that would have happened in jspac. fwiw, anyway
12:03 eeevil the deleted checks, I'll definitely look into. and thanks again
12:03 * eeevil runs to lunch
12:13 pinesol_green [opensrf|Lebbeous Fogle-Weekley] LP#1286198: When doing router-specific things, we don't need as much configuration loaded - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=82f19d8>
12:13 pinesol_green [opensrf|Lebbeous Fogle-Weekley] LP#1286198: Offer ability to ignore what seem like orphan processes when starting things - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=81cdb6f>
12:13 pinesol_green [opensrf|Lebbeous Fogle-Weekley] LP#1286198: Teach osrf_router to (optionally) write its own PID files - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=ff43e38>
12:13 pinesol_green [opensrf|Galen Charlton] LP#1286198: use --ignore-orphans rather than --are-there-no-prisons - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=d3499f2>
12:27 jeff =008 FIXEDLENGTHDATAELEMENT\\\\\\\\\\\\\\\\\\
12:27 jeff "where did YOU come from?"
12:29 jcamins jeff: copy-and-pasted from RLIN?
12:32 jeff neat. we have a bib whose biblio.record_entry.tcn_source is a marc record.
12:32 bshum o.O
12:32 bshum jeff: I fear your records
12:33 jihpringle joined #evergreen
12:35 gmcharlt jeff: please tell me it's a properly constructed name authority record for OCLC
12:36 jeff it also has an interesting 024: =024 70$2Legacy Title Number$a9773
12:48 jeff and now i know where these records came from. :-)
12:48 jeff email++
12:48 jeff (correlation between create_date of this batch and an old 2011 email of a pair of libraries going live) :-)
12:51 bshum dbwells: Testing the negative balance branch on the test system.  So far, found a lost bill, paid it off to zero, then checked in the item to go and delete it.  So far no negative bills appear and no errors.  Good first sign for me.
12:51 bshum We'll keep testing here next week to look at some of the other scenarios.
12:53 kmlussier dbwells: Dyrcona has loaded the branch on his test server too. But I probably won't get a chance to look at it until after the conference.
13:00 dbwells bshum++ kmlussier++
13:02 jeff "Computer-generated, six-character numeric string that indicates the date the MARC record was created. Recorded in the pattern yymmdd."
13:03 jeff which will become more useless first, 008/00-05 or MARC itself? :P
13:04 eeevil bshum: I'll have a perl-only patch for you to try out re your deleted record issue. the fingerprinting thing is old, different and bigger, but there might be a short-term solution to help with that, too
13:04 bshum eeevil: I'm mostly worried about the deleted bibs.  The other thing is just junky bibs ruining our lives :)
13:04 bshum eeevil: So happy to try whatever you point me at.
13:04 eeevil cool
13:05 bshum Our test system is working with berick's lightly squashed branch too.  So hopefully I can check out some of the other things that have been fixed and get that signed off and in
13:05 gmcharlt bshum: OpenSRF master now eschews AUTOLAOD
13:05 jeff i mocked the two digit year-ness of 008/00-05, but in doing so realized what i was seeing.
13:05 gmcharlt it also dislieks AUTOLOAD
13:05 jeff 1061120n
13:05 gmcharlt and I can't type today
13:05 pinesol_green [opensrf|Bill Erickson] LP#1179660: remove OpenSRF.pm AUTOLOAD - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=951d97a>
13:05 jeff 2006-11-20
13:05 bshum gmcharlt: Good to know, thanks.  Lucky for me I grabbed what I needed earlier.
13:06 jeff it's the year 20106!
13:06 jeff 19106 perhaps
13:10 jeff anyway, there's 2474 mangled 008 fields that can be fixed.
13:12 Dyrcona Heh....
13:12 jeff i would feel better if they were not all devoid of any other useful data.
13:12 jeff 1000303n        xx                0 eng
13:13 Dyrcona Just delete the 008s. They aren't required are they?
13:15 jeff i suppose these also have a language and a literary form.
13:15 jeff Dyrcona: "required" in what sense? :-)
13:19 Dyrcona meh. It's MARC, it's gonna be junk.
13:27 pastebot "eeevil" at 64.57.241.14 pasted "for bshu. should avoid deleted metarecord constituents" (34 lines) at http://paste.evergreen-ils.org/28
13:31 * bshum tests
13:33 bshum eeevil: It doesn't like that
13:33 bshum egweb: Context Loader error: Can't call method "content" on an undefined value at /usr/local/share/perl/5.14.2/O​penILS/WWW/EGCatLoader/Util.pm line 301.
13:34 eeevil hrm. interesting (and odd). well, I'll look futher
13:34 bshum Oh wait, maybe just a bad refresh, hang on.
13:34 bshum Nope
13:34 bshum It's broken
13:34 eeevil and missing the deleted check
13:34 eeevil yeah, it needs more
13:34 eeevil but if you have a futher error, that'd be good
13:36 bshum Well it just shows as an internal server error in the catalog
13:36 bshum And that's all I really get in the log end
13:37 eeevil huh ... nothing in the pg log?
13:37 bshum Oh that I can check.  That's on the other server
13:37 bshum *whistles innocently*
13:38 bshum Nope, nothing interesting in the postgres logs
13:39 pastebot "eeevil" at 64.57.241.14 pasted "another for bshum. note the new first hunk, and the new part of the where clause" (46 lines) at http://paste.evergreen-ils.org/29
13:39 eeevil that'll avoid the error you got, at least
13:39 bshum Okay
13:42 bshum Well, it's a different error now.
13:42 eeevil WHEEE
13:42 bshum Or rather, nothing works at all now
13:42 bshum I'm checking my copy/paste
13:42 bshum egweb: Context Loader error: Can't locate object method "new" via package "OpenILS::WWW::EGCatLoader" at /usr/local/share/perl/5.14.2/OpenILS/WWW/EGWeb.pm line 111.\n
13:43 bshum Is the error though
13:43 eeevil we may want to wait for berick ... I'm not seeing where he's gathering the constituent record ids, and that's where we need to filter out deleted records
13:44 * bshum puts things back for now to test other stuff
14:05 wlayton stupid git question: how do I pull in berickm 's prototype code at http://git.evergreen-ils.org/?p=work​ing/Evergreen.git;a=shortlog;h=refs/​heads/collab/berick/web-staff-proto
14:05 wlayton ideally, I'd like to pull that into a separate branch
14:06 bshum You can always checkout that branch with something like git checkout -b localbranch remote/remotebranch
14:06 bshum Or what I tend to do is merge git branches of targets I want
14:07 bshum And then either rebase to move things back up or just go with it messy
14:08 bshum So err, something like git checkout -b localname working/collab/berick/web-staff-proto I guess.  To just checkout that branch as done.
14:08 bshum *where you replace "localname" there with whatever you want to call it locally.
14:15 dbwells eeevil: bshum: I think at that point, if we've come through the "grouped" code, we have a collection of mmr IDs, not bre IDs.  Of course that doesn't help us, since mmrs have no 'deleted' property.
14:16 dbwells eeevil: I think perhaps we should put a 'deleted' check right in the bre select in unapi.mmr itself.  What do you think?
14:16 wlayton bshum: sorry to bug you again, but `git checkout -b websc working/collab/berick/web-staff-proto` fails for me.
14:17 wlayton From what I tell, I need to do a git-fetch beforehand...but to where?
14:17 bshum wlayton: Did you add a git remote for the working repos?
14:17 wlayton nope
14:17 bshum http://wiki.evergreen-ils.org/doku.php?id=dev:git
14:17 bshum I'll point you here then
14:17 wlayton thanks -- I'll RTFM
14:17 bshum in the "Quick start for Evergreen contributors" section
14:17 bshum It describes how to add the working remote
14:18 bshum No sorry, I'm a poor explainer sometimes.
14:18 dbwells eeevil: maybe both the 'leadrec' and 'subrec' selects?
14:18 eeevil dbwells: I think yes ... you mean inside unapi.mmr ... ah, that's what you said. yes, sorry.
14:19 bshum wlayton: A helpful trick I've seen from our git servers is that they list the URL for where to go on the main summary page for the repo
14:19 bshum http://git.evergreen-ils.org/?p=​working/Evergreen.git;a=summary (look for the URL part)
14:19 wlayton bshum: no, not at all. I was just being too lazy.
14:19 bshum And that's handy for knowing where to set the path for the git remote
14:20 berick joined #evergreen
14:20 bshum Not all gitweb are setup that way, but that was a nice touch our git-admins did for us
14:20 eeevil dbwells: yes, I think we just need to add AND NOT bre.deleted to the subrec select
14:21 dbwells eeevil: Yeah, I guess we can't do it on the leadrec, since that is predetermined by master_record.
14:22 eeevil dbwells: I'm going to doublecheck now, but IIRC, deleting a lead bib will cause the MR to choose a new lead
14:22 dbwells eeevil: That leads again to one of my questions from earlier, though.  Do we have code to make sure that master_record records aren't deleted?
14:22 dbwells eeevil: ok :)
14:22 eeevil I know we did, once upon a time ;)
14:23 wlayton bshum: I'm in business now. Thank you very much!
14:23 RoganH joined #evergreen
14:23 bshum wlayton++
14:23 bshum yay!
14:24 eeevil dbwells: we don't now, but we're about to! :)
14:24 wlayton wlayton-- #Sucks at git
14:25 csharp @karma git
14:25 pinesol_green csharp: Karma for "git" has been increased 21 times and decreased 0 times for a total karma of 21.
14:25 csharp @loves git
14:25 pinesol_green csharp: git doesn't seem to love anything.
14:25 csharp heh
14:25 bshum Heh
14:26 bshum I know I already love git
14:26 csharp @quote add < pinesol_green> git doesn't seem to love anything.
14:26 pinesol_green csharp: The operation succeeded.  Quote #81 added.
14:27 bshum Haha
14:31 jeff @whocares git
14:31 pinesol_green Dyrcona, tsbere, bshum and csharp love git
14:31 pinesol_green kmlussier hates git
14:31 dbwells eeevil: Yeah, sorry, got your comment after I posted my question.  Did a quick test by deleting record 15 from the DB (it was master of a group of three), but it looks like the master_record is still set to 15.
14:31 bshum Maybe git should hate kmlussier :)
14:31 kmlussier git does hate kmlussier. That's the problem.
14:31 _bott_ joined #evergreen
14:32 dbwells eeevil: I think bshum managed to dig up some old demons with this one ;)
14:32 eeevil yeah ... someone (maybe me) moved some code into metabib.remap_metarecord_for_bib that is causing problems
14:32 jeff iirc, it is quite possible to delete a master record -- i don't know if there is/was protection against a deleted record being selected as master in the first place.
14:32 eeevil there was back in the open-ils.ingest days... not now though
14:34 dbwells thanks to jeff, there's no going back on that :)
14:34 jeff hey, the history's there. :-)
14:35 bshum Hehe
14:35 jeff it's just no longer an active, running service (if you followed the recommendations when upgrading). ;-)
14:36 bshum I'll admit, I found out that I initially installed an older git branch because I was using the ingest change to mark times since the last time I upgraded our test server and was surprised to still see it in my opensrf.xml.example
14:36 hbrennan joined #evergreen
14:37 bshum So jeff, your change spared me from looking really stupid for claiming we'd "upgraded" our test systems.
14:38 bshum As for old demons though, I didn't mean it, really I didn't!
14:39 dbwells That's what they all say
14:40 pinesol_green [evergreen|Elliot V] LP#1077811 Inconsistent INSTALL Instructions - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f102496>
14:52 bshum yboston++ # and now I get what MX / LATAM is all about.
14:53 yboston bshum:  :) it took me a while to understand what does meant. I thought at first the email was spam
14:54 yboston bshum: I almost mentioned that we are actually using a hybrid american / canadian English docs
14:54 yboston s/does/those/
14:55 bshum yboston: As far as status goes, I've been meaning to dust off the TPAC translation file for Spanish at some point.  Once upon a time, one of our libs helped to contrib the spanish translation for JSPAC, but we haven't had time to revisit and update it.
14:55 bshum For the client, that was ultimately a much harder process, so we didn't get to it.
14:55 yboston bshum: let me know if I can help
14:58 bshum My middle school Spanish doesn't lend itself well to verifying that things work out.  But I know some of the technical side of how things happen in LP at least.  Maybe we can put our heads together sometime at the conference.
14:58 bshum Where's the i18n interest group, eh?  :D
14:58 bshum (kidding, kidding)
14:59 gmcharlt bshum: I think you've found it!
15:00 bshum At GSOC mentor summit, I sat in and took notes for the i18n session. It was quite interesting to see the pain points for other projects. And other tools they employ.
15:00 bshum I'm still curious to see if we could do some sort of tool like Transifex to directly edit strings from the web vs. git.
15:00 bshum To make it a little easier to sync things
15:02 RoganH hopefully simple TPAC question (I'm fairly TPAC ignorant): If you wanted to set ctx_org to something static in the register.tt2 could you just give it org unit IDs?
15:04 berick RoganH: for the home library selector?
15:04 RoganH berick: yes
15:05 berick you want a default value or a value that cannot be changed?
15:05 RoganH berick: a value that can't be changed
15:05 RoganH berick: essentially we have different libraries that want custom pages that will look like parts of their sites, not the opac
15:06 RoganH berick: and many won't use it at all
15:06 berick the best way to set the value is via url param (or cookie) using physical_loc or locg.  that way the back-end uses the same org as the UI
15:07 berick you need that for the OU settings, etc. to match up
15:07 berick to prevent changing the value, set disabled='disabled' on the org unit <select>
15:07 RoganH berick: I gotcha
15:07 berick there may be a way to pass that in..
15:07 berick since you don't want to change org_selector.tt2 itself
15:07 RoganH berick: not particularly but I think I can make this work
15:09 berick aha, in register.tt2, where it says valid_org_list=ctx.register.valid_orgs , you could change it to valid_org_list=[one_org_id]
15:09 berick then you don't have to disable it, because it will only have 1 value
15:09 RoganH berick: perfect, that's what I was looking to do
15:12 RoganH berick: thanks, that worked perfectly
15:12 berick cool, welcome
15:17 hbrennan bshum: Congratulations on being my 10th Twitter follower!
15:17 bshum hbrennan: Heh, I'm honored ;)
15:17 hbrennan I still don't know how to use it. But I did resurrect my acct at the conference last year so I wouldn't miss out on eating/drinking opportunities.
15:20 bshum I tweet more often at conferences.
15:22 Dyrcona joined #evergreen
15:37 dluch joined #evergreen
15:40 jeff AHA
15:40 bshum !!
15:40 jeff just bit myself with Can't locate object method "initialize" via package "OpenILS::Application::Search::Z3950" at /usr/local/share/perl/5.14.2/​OpenILS/Application/Search.pm line 31.
15:40 jeff (opensrf autoload removal)
15:41 jeff easy to debug with "osrf_control --localhost --no-daemon --start --service open-ils.search" combined with "oh hey, this line needs to be removed!"
15:44 berick jeff: it's fixed in currrent master, btw
15:44 jeff yep! :-)
15:45 berick that's the first (and only, so far) instance of that I've hit
15:55 bshum eeevil: I can confirm that the reason I've had icon / format search issues is due to lacking reingests.  I'll schedule some time over the weekend to populate our test DB.
15:55 eeevil bshum: I'm both glad to hear it's reingest-related and sad to hear you'll have to reingest ;)
15:56 bshum Fwiw, the icons look really cool for the two or three bibs I manually reingested to test that out.
15:57 bshum Or rather, I can see potential there.
15:58 bshum For configuring these things, I'm thinking it's the coded value maps?
15:58 dbwells bshum: Are you saying a full reingest is needed, or just the new attribute-only reingest?
15:58 bshum dbwells: Let me try attribute-only if I can find the instructions for that.  I just did a full reingest to get it over with to make it known to myself that it wasn't just broken.
16:01 dbwells bshum: You could reingest all the attributes, or even try just the icon_format with a spell eeevil gave on the bug:  select count(metabib.reingest_record_attributes​(id,'{icon_format}'::TEXT[],marc,false)) from biblio.record_entry where id > 0 and not deleted;
16:01 eeevil indeed. that'll be much quicker
16:02 bshum dbwells: Yeah I was just trying to find something like that from the bug.  Let's say that's not spelled out for end users :)
16:02 dbwells just list the attributes in that text array, or I think a null for the second parameter will do them all.
16:04 bshum You guys are talking about https://bugs.launchpad.net/evergreen/+bug/1053397 right?  (doesn't know the background of this stuff entirely)
16:04 pinesol_green Launchpad bug 1053397 in Evergreen "TPAC - Missing Meta-record Level Hold" (affected: 8, heat: 42) [Wishlist,Fix committed]
16:04 dbwells bshum: whatever you do, please time it for me :)  I am always interested in early performance reports.
16:05 dbwells bshum: yes, comment 25 is where I pulled that from
16:06 bshum dbwells: Gotcha, I see.
16:06 bshum So... this is an "undocumented" step then for the upgrade process.  That might be good to add before we release.
16:07 bshum I'll let you know what the timing is.
16:07 dbwells bshum: Yes, I am definitely tracking with you on that thought.
16:08 dbwells It might end up a 'spit out instructions at the end' type thing depending on how long it takes.
16:08 bshum That makes sense.  I was also thinking about what it says in the comments about running these in parallel?
16:10 bshum To confirm, running just a single bib ID in the example noted in comment 25 works to bring up the format icons.
16:11 jboyer-isl I'm not sure there's a better way to spend a Friday afternoon than coming up with a list of 20+ indexes missing from a production database.
16:11 jboyer-isl Good times.
16:11 bshum jboyer-isl: Dude, ouch.
16:12 jboyer-isl 4-5 of them are essentially useless (we don't use edi or authority) but the 9 metabib ones will probably make a difference!
16:12 eeevil berick: whoo hoo! websockets!  I have a (probably silly) question ... could OpenSRF.ClientSession.prototype.request() notice that someone wants to use sync-mode and 1) grab the current transport 2) temporarily set the transport to XHR 3) then set it back?
16:12 jboyer-isl bshum: But it is a good thing to check now and then, upgrade path vs. stock, to make sure that everything is in order.
16:13 berick eeevil: yes, in theory, i don't see why not
16:13 RoganH joined #evergreen
16:14 eeevil jboyer-isl: look at it this way ... after you run 9 "CREATE INDEX CONCURRENTLY" statement your DB will be blazing fast
16:14 bshum Or on fire.
16:14 jboyer-isl eeevil: that is how I have chosen to interpret my situation. :D
16:15 eeevil berick: cool... I may pitch in on that, then
16:15 dbwells bshum: I would consider also including sr_format and mr_hold_format when you run the reingest command, since those are the other completely new defs (I think that is all).
16:16 bshum Hmm....
16:16 berick eeevil: i'm curious, what benefit do you see in using sync requests?
16:17 dbwells bshum: But any that are now 'multi' could potentially improve by being reingested, I think.
16:17 bshum Maybe I should just do a full reingest over the weekend anyways then.  I'm sure I can ask someone to come up with more reasons :)
16:18 * dbwells thinks this is going to need some more testing and consideration
16:18 eeevil berick: the chance to reuse some existing code in the SC rewrite, primarily
16:18 eeevil (and flexibility)
16:18 eeevil dbwells: most are now multi, in fact
16:19 jboyer-isl berick: It's not really the same with JS, but if you can do some of the network stuff in a background thread, waiting on it to return data directly is simpler than dealing with callbacks
16:19 dbwells bshum: I just *really* don't want a full reingest to be part of the 2.6 upgrade process, if it can be avoided.  I am pretty sure the worst case (for this feature group, at least) would be the full attribute reingest (i.e. reingest_record_attributes() with a null second param).
16:20 berick eeevil: aha to #1.  for #2, i would argue taht kind of flexibilty is a big negative
16:20 berick sync is never (prove me wrong) a good thing
16:20 bshum dbwells: I'm happy to try whatever you'd like me to attempt with our DB.  I just have to work out the timing with the folks who want to poke at the feature :)
16:21 berick jboyer-isl: i totally agree, which is why if we make it standard / available, people will use it, which we don't want
16:21 berick it's easier to code, but it's bad practice
16:21 berick unless you're goal is frozen browsers and serialized network communication
16:22 eeevil berick: well, with streaming responses (which, obv, we can't /actually/ do with sync) it is easier to code for, IMHO
16:22 berick right, sync is 110% easier to code
16:22 berick and humans, being lazy, will do sync in a hurry
16:22 eeevil and there are times that you want strictly serialized requests that you can't plan completely in advance
16:23 eeevil see: pcrud.apply()
16:23 berick you can serialize wt/ asycn
16:23 eeevil sure
16:23 berick the new pcrud service in the angular code is all async
16:23 * eeevil needs to go look at that
16:24 berick fwiw, using promises makes things a lot easier for async
16:24 berick well, considerably easier.. it's not a silver bullet
16:24 bshum dbwells: That said, don't kill yourself coming up with new solutions.  If we have to full reingest, it wouldn't be the first time we did that between major version upgrades (in fact I'm almost sure that's been the case for at least the last three or so)
16:25 bshum It's just especially unfun doing full reingests between upgrade scripts during ongoing development :\
16:26 eeevil so, the openils dojo module's pcrud.apply() takes an array of objects (various types) with their isnew, isupdated, isdeleted flags set (mixed is fine) and does the right thing inside a transaction ... IIRC, it can do either sync or async ... the former being good for a logicially-single update, the latter for pile of logicially separate updates
16:26 dbwells bshum: I think the upgrade might say 'do X now, do Y when convenient', where x is:
16:26 dbwells bshum: select count(metabib.reingest_record_attri​butes(id,'{icon_format,sr_format,mr​_hold_format}'::TEXT[],marc,false)) from biblio.record_entry where id > 0 and not deleted;
16:27 eeevil now, we don't use pcrud.apply a ton, except in batch admin interfaces
16:27 eeevil so it's a stick man, if not a straw man ... ;)
16:27 eeevil but, it's the example that comes to mind
16:27 dbwells bshum: So I guess I'd like you to try that version and see what you get for time.
16:27 dbwells bshum: How big is your DB?
16:28 dbwells in bib records
16:28 berick eeevil: pcrud transactions don't require sync calls.. i'm confused what sync buys you there
16:28 eeevil but, if I have to give up sync-ish code for callbacks and promises to get fast and small and non-brittle code, it's a small price ;)
16:29 bshum dbwells: We have....1163490 bibs (not deleted)
16:29 bshum In this test system
16:30 dbwells bshum: My *very* rough estimate is that that last command I gave would take about an hour for a DB that size, give or take.
16:30 bshum dbwells: Worth a shot then.  Full reingest would certainly take longer.
16:31 eeevil berick: it's the conceptual (not code-ish) difference between "rewrite the permission list for a user" (conceptually atomic) and "update these 500 copies, and tell me along the way how we're doing" (conceptually streaming)
16:31 eeevil you absolutely don't /need/ sync for the first one
16:32 bshum dbwells: I'm running it now, I'll check it later this evening to see if your estimate was on target.
16:32 bshum But either way I'll get the final time
16:32 berick eeevil: unfortunately, i'm about to lose my scrollback.  hold that thought!
16:33 dbwells bshum: Thanks!  I'll be happy if it's somewhere between half and double my estimate :)
16:33 eeevil berick: but, like I said, I think my only real argument in favor of thunking to sync is to reuse some existing code in the SC rewrite
16:33 berick eeevil: gotcha.  i def. can see the value of that.
16:34 eeevil bshum: did you have a bug for the MR display issues? with berick's help, I think I've killed it (and fixed some other general MR problems)
16:34 bshum eeevil: I haven't had a chance to file it yet now that you mention it.
16:35 eeevil I can, if you like
16:35 bshum That'd be great, and I'm happy to test those fixes too
16:35 eeevil bshum: actually, you know, I'll just tack it onto berick's ... bug 1284864
16:35 pinesol_green Launchpad bug 1284864 in Evergreen "TPAC metarecord / formats repairs and usability additions" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1284864
16:35 bshum eeevil: That sounds good to me.
16:37 bshum The hit count stuff in that branch was very nice btw.
16:37 bshum Made it much easier to figure out which were multiple bibs and all
16:37 eeevil berick++
16:37 bshum Definitely, berick++
16:37 kmlussier @marc 505
16:37 pinesol_green kmlussier: The titles of separate works or parts of an item or the table of contents. The field may also contain statements of responsibility and volume numbers or other sequential designations. (Repeatable) [a,g,r,t,u,6,8]
16:38 bshum I haven't been able to try metarecord holds yet since without the formats, it seemed unhappy with them
16:38 bshum I'm hopeful that post reingest that'll be good to test
16:43 eeevil bshum: http://git.evergreen-ils.org/?p=working/E​vergreen.git;a=shortlog;h=refs/heads/coll​ab/miker/metarecord-deleted-constituents
16:46 dbwells eeevil: so it looks like we were on the right track earlier?
16:48 dbwells glad to see it wasn't a waste of time then :)
16:58 eeevil dbwells: you were all over it, as usual :)
17:00 dbwells eeevil: thanks, as my daughter likes to say, I just do "my personal best" :)
17:00 eeevil :)
17:13 16WAA1GK3 joined #evergreen
17:17 mmorgan left #evergreen
17:21 timf joined #evergreen
17:46 kmlussier dbwells++
17:47 kmlussier And apologies if I caused any sleepless nights. :(
17:55 dbwells kmlussier: thanks, and no worries.  I should never blame others for my own compulsions :)
18:18 bshum dbwells: Fwiw, 67m33.520s for that script you had me run
18:18 bshum So pretty right on the money
18:19 dbwells bshum: sweet, thanks!  Did it get the icons to show up as expected?
18:20 bshum I'm about to apply the fix for deleted bib leakage first
18:20 bshum Then fire up the test server
18:20 bshum Two shakes and I should know
18:20 dbwells ok, I'm heading out right now, so I'll see how it went later.  Have a good weekend.
18:21 bshum Have a good one!
18:21 bshum dbwells++
18:21 bshum Icons whee!
18:21 bshum Err, mostly.
18:22 * bshum wonders what's wrong with this bib record now...
18:22 bshum Maybe I'll find out after dinner
18:27 mrpeters joined #evergreen
20:33 Dyrcona joined #evergreen
20:47 zxiiro joined #evergreen
21:15 bshum eeevil: Applied the changes in the upgrade script for the metarecord deleted bibs issue.  Doing that alone doesn't solve the problems though.  Looks like we need to tell the system to use those new functions to find non-deleted bibs where all the bibs are deleted in the metabib.metarecord.master_record
21:16 bshum Reingesting the deleted bib forced that Connecticut record out of the way at least, so that much is working right with the corrected functions.
21:23 bshum eeevil: http://pastie.org/8897557 is what I ran to find deleted bibs and correct them (the query found 121k rows that way)
21:24 bshum I guess we have lots of deleted bibs with similar fingerprints.
21:29 bshum Which actually makes sense given how many dupe bibs we've deleted over the years
21:41 * jeff works on additional "bibs with these issues are worth knowing about" criteria
22:14 zxiiro joined #evergreen
22:27 eeevil bsum: right. I fixed an old bug there. We probably need a cleanup script.
23:45 jboyer-isl joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary