| Time |
Nick |
Message |
| 12:34 |
|
serflog joined #evergreen |
| 12:34 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 12:35 |
kmlussier |
Welcome back serflog! |
| 12:39 |
dbs |
thanks jihpringle :) |
| 12:40 |
* csharp |
files bug 1509014 |
| 12:40 |
jihpringle |
csharp yes and there |
| 12:40 |
jihpringle |
's a related bug |
| 12:41 |
csharp |
jihpringle: huh - I searched but didn't see one :-/ |
| 12:41 |
csharp |
launchpad-- |
| 12:41 |
csharp |
jihpringle++ # answering an acq question! |
| 12:41 |
jihpringle |
https://bugs.launchpad.net/evergreen/+bug/1175400 |
| 12:41 |
csharp |
oh - pinesol_green is absent too |
| 12:42 |
|
pastebot0 joined #evergreen |
| 12:45 |
csharp |
ugh - we need bshum - I don't know how to run the bots |
| 12:45 |
gmcharlt |
csharp: i'm there, just a moment |
| 12:45 |
csharp |
(since the move from supybot) |
| 12:45 |
csharp |
gmcharlt: thanks |
| 12:45 |
|
pinesol_green joined #evergreen |
| 12:46 |
csharp |
jihpringle: thanks - I'll mark my new bug as a dupe |
| 12:48 |
gmcharlt |
@quote random |
| 12:48 |
pinesol_green |
gmcharlt: Quote #37: "bkuhn: ... my wife is watching the Les Miserables anniversary concert... and it was just at that point where that Jonas brother comes on as Marius and he's really bad. :)" (added by Dyrcona at 10:16 PM, December 01, 2012) |
| 12:48 |
|
dMiller_ joined #evergreen |
| 12:49 |
gmcharlt |
@quote get 124 |
| 12:49 |
pinesol_green |
gmcharlt: Quote #124: "<kmlussier> True fact. NOBLE never runs out of coffee." (added by gmcharlt at 02:44 PM, October 15, 2015) |
| 12:49 |
Dyrcona |
@quote random |
| 12:49 |
pinesol_green |
Dyrcona: Quote #38: "<jcamins> At least your MARC frameworks aren't painful to use." (added by Dyrcona at 07:42 PM, December 06, 2012) |
| 12:51 |
kmlussier |
I'm so happy to see that NOBLE will now always be known in the Evergreen community as the place that doesn't run out of coffee. |
| 12:53 |
gmcharlt |
when all else fails, our last, best hope against the perils of uncaffeination |
| 12:53 |
tsbere |
kmlussier: Right up until someone comments that NOBLE is out of coffee and it gets added to the quotes list, right? :P |
| 12:53 |
mmorgan |
Heh. We have often discussed having it piped through the walls and ceiling to our desks. I *think* we were only half serious. |
| 12:53 |
Dyrcona |
I.V. drip. |
| 12:54 |
Dyrcona |
I guess you don't get the aroma or the flavor that way, though. |
| 12:56 |
* mmorgan |
notes that we also have decaf, and tea. |
| 12:58 |
mmorgan |
Dyrcona: But I would worry about that I.V. thing. Don't think we'll pursue that as a development item ;-) |
| 12:58 |
* kmlussier |
was about to make a snide remark about decaf and then realized that csharp will probably appreciate having decaf available. |
| 12:59 |
|
dMiller_ joined #evergreen |
| 13:00 |
kmlussier |
Speaking of caffeine, I appear to be in need of some. |
| 13:04 |
|
bmills joined #evergreen |
| 13:06 |
csharp |
kmlussier++ # yep ;-) |
| 13:08 |
|
ericar joined #evergreen |
| 13:29 |
csharp |
kmlussier: mrpeters: (I just read up) - yes, we're running PG 9.3 in production and testing EG 2.9 on PG 9.4 |
| 13:30 |
kmlussier |
csharp: And your using GIN indexes? |
| 13:30 |
kmlussier |
*you're* |
| 13:36 |
csharp |
kmlussier: yes'm |
| 13:37 |
* kmlussier |
is going to add the postgres details to the spreadsheet since it's a bit more useful than eg release. |
| 13:37 |
kmlussier |
csharp: Thanks! |
| 13:37 |
csharp |
sure thing ;-) |
| 13:37 |
jeffdavis |
buh, scrollback |
| 13:40 |
jeffdavis |
kmlussier: as jihpringle said earlier, Sitka is on PG 9.4 and using GIN indexes; we are also having some general slowness issues not directly related to EG which may be resolved soon |
| 13:40 |
kmlussier |
jeffdavis: OK, thanks! Sorry to hear about the slowness issues. :( |
| 13:42 |
jeffdavis |
we've also run into a few places where PG is not behaving as well as expected after upgrading 9.1->9.4, but I'm not sure of the causes there or indeed if it's a general issue with our db setup vs. a few smaller isolated problems |
| 13:44 |
jeffdavis |
Bmagic et al: regarding the Overdrive integration stuff |
| 13:45 |
jeffdavis |
I agree, CoffeeScript is a terrible choice. Incorporating the compiled JS (which lacks comments but is readable if you don't minify it) is definitely a possibility. |
| 13:45 |
Bmagic |
jeffdavis: I was just compiling it into js to see |
| 13:45 |
gmcharlt |
jeffdavis: cool, thanks for confirming that the compiled JS is readable |
| 13:45 |
jeffdavis |
That said, IMO Coffeescript is less of an issue, dependency-wise, than the use of jquery and require.js. |
| 13:46 |
jeffdavis |
I have been looking at the OneClickdigital API, which is pretty similar to Overdrive's, and thinking about writing a proper Evergreen service to talk to it with a minimal JS layer to handle the UI bits in the OPAC. |
| 13:47 |
jeffdavis |
The idea being, if that worked, I could then expand that so that it also works with the Overdrive API (learning from the existing Overdrive integration code) and ultimately discard the existing Overdrive stuff. |
| 13:48 |
jeffdavis |
Which is not really an ideal approach to a dev project of course... |
| 13:49 |
Dyrcona |
jeffdavis: Have you considered a front end with a single API, then adaptors are written for the backends: Overdrive, OneClick, etc.? |
| 13:49 |
jeffdavis |
Yes that's basically what I had in mind. |
| 13:49 |
Dyrcona |
OK. I wasn't sure from your last two statements, but I thought that is what you meant. |
| 13:50 |
jeffdavis |
Similar to how added content handles different providers. |
| 13:50 |
Dyrcona |
+1 |
| 13:53 |
Bmagic |
kmlussier++ #nice spreadsheet |
| 14:02 |
|
jlitrell joined #evergreen |
| 14:03 |
|
mmorgan joined #evergreen |
| 14:10 |
|
rlefaive joined #evergreen |
| 14:31 |
dbs |
jeffdavis: yeah! Or how resolver resolver handles different OpenURL resolvers. 'twould be very Evergreen/OpenSRFy :) |
| 14:34 |
kmlussier |
jeffdavis++ |
| 14:35 |
jeffdavis |
dbs: yup, your resolver code is the other place I'm planning to poach stuff from :) |
| 14:53 |
|
jihpringle joined #evergreen |
| 15:12 |
Bmagic |
Those of you who have a working knowledge of the bugs. I can't seem to find one related to this: "Cataloging a new item does not complain about barcode conflicts with precats until you click 'modify copy' " |
| 15:13 |
Dyrcona |
I'm not aware of that one, either. |
| 15:15 |
Dyrcona |
Grabbing 0945... oh wait. ;) |
| 15:15 |
kmlussier |
Bmagic: Are you saying this happens when adding a precat or are you saying when adding a regular copy, you don't get the barcode conflict for precats? |
| 15:15 |
berick |
Dyrcona++ |
| 15:16 |
Bmagic |
kmlussier: it's happening when cataloging a regular item |
| 15:17 |
tsbere |
If that is an issue I imagine it is closer to "when cataloging a new item barcode conficts are not reported until you click 'modify copy'" - The kind of record the barcode is already on may not matter |
| 15:17 |
kmlussier |
I could be operating on old experience, but I didn't think it complained about barcode conflicts at all until you clicked modify. It didn't matter if the conflict was with a precat or not. |
| 15:18 |
kmlussier |
yeah, what tsbere said |
| 15:18 |
Dyrcona |
berick++ |
| 15:19 |
Bmagic |
kmlussier: I see, I was about to test that. So, it's really a wishlist item, to have the barcode conflict tested before the modify copy window? |
| 15:19 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 DoB as date SQL upgrade repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=01b0255> |
| 15:20 |
kmlussier |
Bmagic: I recall there be discussion about an enhancment for that a long time ago, but I can't remember if it was an LP bug or just a comment on the mailing list. |
| 15:21 |
kmlussier |
hmmm...I wonder if I tested that in webby. I think the same thing happens there too. |
| 15:21 |
kmlussier |
But I think it's more of an annoyance when you're using the separate copy and volume editors in the xul client. |
| 15:43 |
jboyer-isl |
Bmagic, kmlussier: to change "when" that error happens would require querying the server each time the barcode changes, similar to the way some online services do new usernames when signing up. (a green check for "this username is available" vs a red x for "someone else is using this name already") |
| 15:44 |
jboyer-isl |
Is the real issue that the changes made to the item are lost once that message is displayed, or just that it should warn the user sooner? |
| 15:44 |
|
Christineb joined #evergreen |
| 15:47 |
kmlussier |
jboyer-isl: When I first came across the problem, it was when I was using the separate copy / volume editor. In that scenario, you actually click a "Continue" button to get to the volume editor, and didn't get an alert. But I never use the separate editors anymore. Not sure if it's still the case. |
| 15:47 |
* kmlussier |
needs to disappear. |
| 16:10 |
|
jboyer-isl joined #evergreen |
| 16:14 |
Bmagic |
jboyer-isl: the complaint is that it wastes time. The error doesn't show itself until after the staff has taken the time to fill out the details of, price, copy location, circ mod, etc |
| 16:16 |
jboyer-isl |
That's true, but I don't know enough about that workflow to know how much time. Do they have to re-enter everything, or just change the barcode and click Modify again? |
| 16:27 |
berick |
almost just told someone, "in the Bills interface, lick the History button" |
| 16:31 |
jboyer-isl |
berick: I thought I was the big Mac fan around here, heh. |
| 16:32 |
jboyer-isl |
(Uh, context for logs: I believe Jobs referred to the buttons in the first OS X release as lickable. They have since recovered.) |
| 16:55 |
berick |
jboyer-isl: har! |
| 17:05 |
|
jwoodard joined #evergreen |
| 17:15 |
Bmagic |
jboyer-isl: in one example, the conflicting barcode was checked out as a precat, and therefore, the precat needs to be delt with first. Meaning the item has the barcode attached to it physically, and needs to remain |
| 17:29 |
|
bmills joined #evergreen |
| 21:48 |
|
bmills joined #evergreen |
