| Time |
Nick |
Message |
| 02:09 |
|
Bmagic_ joined #evergreen |
| 02:16 |
|
bshum joined #evergreen |
| 02:17 |
|
kmlussier joined #evergreen |
| 02:17 |
|
mceraso joined #evergreen |
| 07:22 |
|
jboyer-isl joined #evergreen |
| 07:33 |
|
sarabee joined #evergreen |
| 07:40 |
|
Callender_ joined #evergreen |
| 07:48 |
|
ericar joined #evergreen |
| 07:56 |
|
mrpeters joined #evergreen |
| 08:03 |
|
rjackson_isl joined #evergreen |
| 08:31 |
|
Callender joined #evergreen |
| 08:39 |
|
Dyrcona joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:42 |
|
mmorgan1 joined #evergreen |
| 08:44 |
|
mmorgan2 joined #evergreen |
| 08:44 |
|
mmorgan2 left #evergreen |
| 08:51 |
|
krvmga joined #evergreen |
| 08:51 |
|
sbrylander joined #evergreen |
| 08:52 |
|
dkyle joined #evergreen |
| 08:54 |
|
Shae joined #evergreen |
| 08:55 |
|
mmorgan joined #evergreen |
| 08:56 |
|
mrpeters joined #evergreen |
| 08:59 |
Dyrcona |
Yuk. Merge conflicts in css, and I'll have to spend time to figure out which branches conflict. |
| 08:59 |
Dyrcona |
Cause the conflict markers don't reveal enough information. |
| 09:01 |
Dyrcona |
Nifty! Looks like the conflict is with master. |
| 09:01 |
Dyrcona |
Though more investigation is required. |
| 09:02 |
Dyrcona |
Eh, nope. |
| 09:03 |
Dyrcona |
working/user/berick/lp1452950-web-client-patron-reg and working/collab/gmcharlt/webstaff-sprint2-sprint3 conflict in Open-ILS/src/templates/staff/css/style.css.tt2 |
| 09:03 |
Dyrcona |
But, I think I can resolve it for my purposes. |
| 09:05 |
kmlussier |
g'morning #evergreen |
| 09:06 |
mmorgan |
'morning! |
| 09:10 |
Dyrcona |
Good morning. |
| 09:24 |
|
mdriscoll joined #evergreen |
| 09:25 |
|
maryj joined #evergreen |
| 09:27 |
jeff |
conflict markers in css in tt2. your editor's syntax highlighting must have loved that. |
| 09:29 |
Dyrcona |
jeff: They look perfectly normally because their is no syntax highlighting configured for tt2. :) |
| 09:30 |
jeff |
probably a good overall plan for tt2 files. |
| 09:30 |
jeff |
though i've sometimes manually toggled syntax file type between tt2 and js/html/css when editing. |
| 09:32 |
* tsbere |
checks, finds that he has not set syntax=tt2 as the default for tt2 files |
| 09:32 |
Dyrcona |
There's a vim mode at the bottom of the file, but none for Emacs. |
| 09:33 |
tsbere |
I also, at times, want to say "let me STACK syntax sets" <_< |
| 09:33 |
|
sarabee joined #evergreen |
| 09:33 |
Dyrcona |
Emacs will do that. :) |
| 09:33 |
Dyrcona |
With multi-mode. |
| 09:35 |
Dyrcona |
Now, what I want to figure out is why our OPAC is so busy this morning. |
| 09:35 |
* tsbere |
digs up his notes, finds that he has, in fact, done multi-syntax before, but found the places he wanted to confused the crap out of the resulting setup |
| 09:37 |
Dyrcona |
I've multi-mode with php-mode and sgml-mode (html) and it works pretty well. |
| 09:38 |
tsbere |
I was apparently trying with files that attempted to figure start/end of blocks, and the start/end chars didn't play nice with the second setup. :/ |
| 09:39 |
Dyrcona |
Hello, Baidu! I see you, but soon you will not see me. |
| 09:47 |
|
sarabee joined #evergreen |
| 10:00 |
|
yboston joined #evergreen |
| 10:14 |
|
ericar joined #evergreen |
| 10:17 |
|
RBecker joined #evergreen |
| 10:28 |
Dyrcona |
kmlussier: My development system is up and running with the branches listed in my development document on Google Drive if you care to have a look at the browser client branches. |
| 10:30 |
Dyrcona |
Alas, poor Baidu. I knew him well, Horatio. |
| 10:32 |
Dyrcona |
Hmm. Looks like my firewall is on UTC. Guess I can live with that. |
| 10:35 |
kmlussier |
@marc 246 |
| 10:37 |
Dyrcona |
pinesol appears to be missing |
| 10:40 |
|
pinesol_green joined #evergreen |
| 10:42 |
|
sbrylander joined #evergreen |
| 10:45 |
kmlussier |
@marc 246 |
| 10:45 |
pinesol_green |
kmlussier: A form of the title appearing on different parts of an item or a portion of the title proper, or an alternative form of the title when the form differs significantly from the title contained in field 245. (Repeatable) [a,b,f,g,h,i,n,p,5,6,8] |
| 10:53 |
kmlussier |
Dyrcona: Thank you! |
| 10:54 |
kmlussier |
A question about coverage density in relevance ranking. If I do a search for 'the blue' (not enclosed in quotation marks), I get good relevance ranking. |
| 10:54 |
kmlussier |
http://bark.cwmars.org/eg/opac/results?query=the+blue&qtype=keyword&fi%3Asearch_format=&locg=1&sort= |
| 10:55 |
kmlussier |
But if I enclose my search terms in quotation marks to search it as a phrase, the relevance is not so good. |
| 10:55 |
kmlussier |
http://bark.cwmars.org/eg/opac/results?query=%22the+blue%22&qtype=keyword&fi%3Asearch_format=&locg=1&sort= |
| 10:55 |
kmlussier |
Does coverage density not come into play when doing a phrase search? |
| 10:57 |
|
RoganH joined #evergreen |
| 11:07 |
|
ericar joined #evergreen |
| 11:08 |
|
Christineb joined #evergreen |
| 11:09 |
|
vlewis joined #evergreen |
| 11:11 |
kmlussier |
Based on other sample searches, I am going to say adding a phrase to a search definitely messes with relevance ranking. |
| 11:12 |
berick |
jeff: for your elasticsearch experiments => https://github.com/jprante/elasticsearch-analysis-standardnumber |
| 11:19 |
jeff |
that might be handy. could save from having to normalize beforehand. |
| 11:20 |
jeff |
If nothing else, encouraging to see other library-related Elasticsearch use/work. :-) |
| 11:20 |
jeff |
berick++ |
| 11:22 |
|
collinanderson joined #evergreen |
| 11:23 |
|
collinanderson left #evergreen |
| 11:49 |
|
dkyle left #evergreen |
| 11:57 |
kmlussier |
bug 1516707 |
| 11:57 |
pinesol_green |
Launchpad bug 1516707 in Evergreen "Relevance ranking deteriorates when phrases are added to search" [Medium,New] https://launchpad.net/bugs/1516707 |
| 12:08 |
|
RoganH joined #evergreen |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:27 |
|
sarabee joined #evergreen |
| 14:01 |
jeff |
interesting. i have two indexes on action.circulation.target_copy |
| 14:01 |
jeff |
"action_circulation_target_copy_idx" btree (target_copy) |
| 14:01 |
jeff |
"circ_copy_idx" btree (target_copy) |
| 14:02 |
dbs |
and is access twice as fast? :) |
| 14:02 |
berick |
dbs++ |
| 14:02 |
berick |
all problems solved |
| 14:02 |
berick |
maybe you need to index your indexes |
| 14:02 |
dbs |
Ours matches, for what it's worth |
| 14:04 |
dbs |
My guess is that circ_copy_idx predated action_circulation_target_copy_idx, and at some point the duplication was noted and circ_copy_idx got dropped from stock schema |
| 14:04 |
jeff |
we also have a action.circ_all_usr_idx and a action.circ_usr_idx |
| 14:05 |
jeff |
circ_all_usr_idx is in stock. |
| 14:05 |
jeff |
dbs: do you have a action.circ_usr_idx index? |
| 14:05 |
dbs |
Or maybe was received wisdom in #openils / #evergreen before we decided to get it into the stock schema |
| 14:05 |
dbs |
jeff: yes |
| 14:10 |
dbs |
Heh, I love this quote from https://aerotwist.com/blog/the-cost-of-frameworks/ |
| 14:10 |
dbs |
"As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet" |
| 14:11 |
jeff |
circ_copy_idx does not appear in git. |
| 14:11 |
* dbs |
wonders that the time-to-interactive cost is for Dojo 1.3 :) |
| 14:12 |
dbs |
jeff: yeah, I time travelled back to rel_2_0 and didn't see it there either |
| 14:12 |
dbs |
which is why I suggested that it might have been an IRC suggestion for performance optimization (we had a number of those in early days) that then got codified |
| 14:12 |
jeff |
commit f2a5b46 introduced the action_circulation_target_copy_idx index |
| 14:12 |
pinesol_green |
[evergreen|scottmk] Create two new indexes on action.circulation & action.aged_circulation, - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f2a5b46> |
| 14:12 |
jeff |
and commit 85373da added them to the baseline schema |
| 14:12 |
pinesol_green |
[evergreen|scottmk] For action.circulation and action.aged_circulation: add indexes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=85373da> |
| 14:14 |
dbs |
yay blame |
| 14:16 |
dbs |
too bad pg_catalog.pg_index doesn't have a create_date timestamp column |
| 14:27 |
jeff |
we have 17 duplicate indexes. those are the largest duplicates. |
| 14:37 |
jeff |
when i started pulling due_date for holdings data, my index speed went from ~1.753 to ~15.391 rec/s |
| 14:37 |
jeff |
unfortunately, it wasn't because there was a missing index. :-) |
| 14:38 |
jeff |
er, scratch that. reverse it. |
| 14:38 |
jeff |
from ~15.391 to ~1.753 rec/s |
| 14:39 |
jeff |
i realized i'd eventually have to change the method by which i was fetching holdings. it is apparently no longer premature to optimize now. |
| 14:39 |
* csharp |
is directed to https://github.com/johnpapa/angular-styleguide in our angularJS bootcamp class |
| 14:48 |
jboyer-isl |
Pizza and AngularJS? Is there anything Papa can't do? |
| 14:49 |
Dyrcona |
Pay his workers? |
| 14:52 |
kmlussier |
heh |
| 14:54 |
csharp |
oooh burn(ed pizza) |
| 14:55 |
csharp |
@blame Papa John |
| 14:55 |
pinesol_green |
csharp: It's all Papa John's fault! |
| 14:55 |
jboyer-isl |
Well there's one failing, anyway. |
| 14:56 |
|
jboyer_isl joined #evergreen |
| 14:57 |
Dyrcona |
csharp: The style guide looks good. |
| 14:57 |
* Dyrcona |
should do another Angular tutorial/play with Angular some more. |
| 14:58 |
* jboyer_isl |
feels bad for missing the perfect "sick burn comeback," but csharp saves the day. |
| 14:58 |
csharp |
Dyrcona: the recommendation here was "start with this guide, and ignore as necessary" ;-) |
| 14:58 |
jboyer_isl |
Hmph. Any more quoting like that and my code will stop working. :-/ |
| 14:59 |
Dyrcona |
csharp: heh |
| 15:00 |
|
jboyer-isl joined #evergreen |
| 15:17 |
|
dwgreen joined #evergreen |
| 15:26 |
Bmagic_ |
anyone else have issues using the "message center" interface? It endlessly spins (loading) with no results. The server logs do not provide any feedback. |
| 15:26 |
Bmagic_ |
I get an error in the javascript console: Use of getAttributeNode() is deprecated. Use getAttribute() instead. Source File: oils://remote/js/dojo/dojo/dojo.js Line: 16 |
| 15:30 |
bshum |
oils? |
| 15:31 |
bshum |
Is this in the staff client? |
| 15:31 |
bshum |
Bmagic_: staff client vs. browser? |
| 15:31 |
* bshum |
only tested message center in the browser, not the client |
| 15:33 |
Dyrcona |
bshum: That's the oils wrapper that tricks xul into loaded stuff remotely. |
| 15:34 |
Dyrcona |
s/loaded/loading/ |
| 15:34 |
bshum |
Right, so .... staff client. :) |
| 15:43 |
kmlussier |
I'm surprised the message center link even shows in the staff client. Isn't that bar with the My Account stuff usually removed? |
| 15:45 |
kmlussier |
Oh, Bmagic_ must be talking about the message center interface from the patron record. |
| 15:46 |
kmlussier |
Bmagic_: Does the patron you're looking up have any messages to view? |
| 15:46 |
|
jlitrell joined #evergreen |
| 15:52 |
kmlussier |
Bmagic_: It shows as spinning for me in 2 circumstances 1) if there are no messages and 2) if the context OU is incorrect. |
| 15:53 |
kmlussier |
Huh, even when the messages display, the spinner keeps spinning. That's a bit annoying. |
| 15:57 |
|
Bmagic joined #evergreen |
| 15:58 |
Bmagic |
I thought the action triggers that send emails would also create a note for the patron to read in the message center? |
| 16:00 |
kmlussier |
Bmagic: You have to configure it to send the messages to the message center. The only ones done by default are the hold cancellation messages. |
| 16:00 |
Bmagic |
ah! |
| 16:01 |
Bmagic |
We must not have that setup right, is that per event definition? |
| 16:01 |
kmlussier |
Bmagic: There are some brief instructions about halfway down the page at http://docs.evergreen-ils.org/2.9/_patron_message_center.html |
| 16:02 |
Bmagic |
oh, I see, another action trigger for the message to go into the notes |
| 16:13 |
Dyrcona |
bshum: lp 1516786 and i'll have a branch in a jiffy. |
| 16:13 |
pinesol_green |
Launchpad bug 1516786 in Evergreen "0938 upgrade script ends in END; and not COMMIT;" [Undecided,New] https://launchpad.net/bugs/1516786 |
| 16:14 |
bshum |
Dyrcona++ # I'll push it on for us |
| 16:15 |
Bmagic |
kmlussier: just to make sure I am understaning correctly - Action triggers cannot both send an email and create a message for the patron's message center? |
| 16:16 |
kmlussier |
Bmagic: I thought you could do both in one, but I could be wrong. |
| 16:16 |
csharp |
Bmagic: as far as I know, you'd need to do two action triggers based on the same hook |
| 16:16 |
csharp |
I believe each A/T definition can only have one reactor |
| 16:17 |
Bmagic |
right, but what is the reactor for message center? |
| 16:17 |
Bmagic |
I don't think there is one |
| 16:17 |
csharp |
though I suppose you could write a custom reactor to do more than one thing |
| 16:17 |
csharp |
dunno (yet) |
| 16:17 |
csharp |
Bmagic: btw, Terran and I are in STL right now |
| 16:17 |
* csharp |
waves out the window |
| 16:17 |
Bmagic |
haha! |
| 16:17 |
berick |
see the message_ fields on action_trigger.event_definitino |
| 16:18 |
berick |
IIRC, any A/T event def can contain a user message just by adding values to those fields |
| 16:18 |
csharp |
oh - cool |
| 16:18 |
Bmagic |
berick: yeah, the way it looks, you can just add stuff in the message_template, Message Library Path, Message User Path for existing email A/T's |
| 16:19 |
Dyrcona |
bshum: and branch pushed user/dyrcona/lp1516786_0938_upgrade_fix |
| 16:23 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1516786: 0938 Upgrade Script ends in END and not COMMIT. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=162dfb1> |
| 16:37 |
* gmcharlt |
blinks and wonders how the heck I missed that |
| 16:38 |
Dyrcona |
Well, it's not fatal, the transaction still commits. |
| 16:38 |
bshum |
Fortunately. |
| 16:39 |
berick |
crazy, it does? |
| 16:39 |
* berick |
looks at END sideways |
| 16:39 |
miker |
http://www.postgresql.org/docs/9.1/interactive/sql-end.html |
| 16:40 |
berick |
oh, so it was totally fine |
| 16:40 |
berick |
(Just unusual) |
| 16:40 |
berick |
er, atypical |
| 16:40 |
miker |
aye, and bad for our scripts |
| 16:41 |
gmcharlt |
heisentypos... oy |
| 16:41 |
berick |
ah, right |
| 16:42 |
miker |
unfortunately, not easily fixed in the scripts, either ... hard to find the correct END when we use lots of PL/PGSQL where END means something else |
| 16:43 |
miker |
(I was about to suggest supporting it ... then realized -^ ) |
| 16:43 |
berick |
yeah, makes sense |
| 16:44 |
gmcharlt |
0446.schema.naco-normalize-modifiers.sql is another bad one |
| 16:46 |
miker |
git can't tell us who to blame for that one ... svn didn't track renames |
| 16:47 |
Dyrcona |
Yeah, I found it in 2.8.4 to 2.9.0 because of transaction issues when testing. |
| 16:48 |
* miker |
suspects miker, or dbs, for 0446 |
| 16:48 |
Dyrcona |
I'm not sure we should fix 0446 at this point, that is so old. |
| 16:48 |
* miker |
now runs away |
| 16:48 |
gmcharlt |
miker: sure it can -- as it turns out, I'm also to blame for that one :/ |
| 16:48 |
miker |
Dyrcona: I'm not excited about changing it |
| 16:49 |
miker |
gmcharlt: well, git blames you, but did you author the original or just stamp the upgrade script? |
| 16:51 |
gmcharlt |
appears I did both -- I think this predates the days when we were doing the XXXX => review => real stamp dance |
| 16:52 |
miker |
I think you're right :) |
| 16:52 |
miker |
ALL BLAME TO GMCHARLT! END IS WHY WE CAN'T HAVE NICE THINGS! |
| 16:52 |
* miker |
runs away now |
| 16:53 |
* gmcharlt |
in turn blames the cat ;) |
| 16:53 |
kmlussier |
@blame gmcharlt's cat |
| 16:53 |
pinesol_green |
kmlussier: It really IS gmcharlt's cat's fault! |
| 16:53 |
berick |
@blame cats |
| 16:53 |
pinesol_green |
berick: It's all cats's fault! |
| 16:53 |
berick |
heh |
| 16:54 |
kmlussier |
@praise dogs |
| 16:54 |
* pinesol_green |
Shall I compare dogs to a summer's day? dogs is more lovely and more temperate. |
| 16:57 |
|
mmorgan1 joined #evergreen |
| 17:03 |
|
mdriscoll left #evergreen |
| 17:28 |
Bmagic |
Anyone put any thought into having SIP return valid patrons from the pending patrons table as well? |
| 17:35 |
Bmagic |
We had a branch that wanted to allow pending patrons access electronic materials. AKA overdrive. Which I suppose would be a change to the SIP logic |
| 17:41 |
berick |
yeah, as it stands, pending users have zero access |
| 17:41 |
Bmagic |
I can see some obvious security issues though. berick: what do you think of the notion? |
| 17:43 |
|
dcook joined #evergreen |
| 17:45 |
berick |
Bmagic: i think it's interesting |
| 17:45 |
berick |
and maybe doable |
| 17:48 |
Bmagic |
jeffdavis: ldw said you were the one to ask about the Overdrive coffeescript code |
| 17:49 |
Bmagic |
jeffdavis: have you found that the coffee script code has been stable, not needing care and feeding since you went live with it? |
| 17:52 |
jeffdavis |
Bmagic: yes, that's been our experience |
| 17:52 |
Bmagic |
If we translated it into pure javascript, and integrated into master, I was thinking about long term care and feeding. Would it need to be in coffeescript to make it understandable everytime we needed edit it? |
| 17:52 |
|
dac joined #evergreen |
| 17:52 |
|
Callender_ joined #evergreen |
| 17:52 |
|
geoffsams joined #evergreen |
| 17:53 |
|
serflog joined #evergreen |
| 17:53 |
|
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 |
| 17:54 |
|
rangi joined #evergreen |
| 17:54 |
|
rangi joined #evergreen |
| 17:54 |
jeffdavis |
I don't think you can compile coffeescript to JS without losing the comments. Other than that it should be possible to just maintain the JS directly. |
| 17:55 |
jeffdavis |
That said, I am working on OneClickdigital API integration using a different approach, and hoping to eventually fold OverDrive API support into that. |
| 17:56 |
jeffdavis |
"different approach" = native EG service for talking to 3rd-party APIs + generic JS integration layer for the OPAC that doesn't add extra dependencies like jQuery |
| 17:59 |
Bmagic |
jeffdavis++ |
| 17:59 |
|
sbrylander joined #evergreen |
| 18:02 |
|
jyorio joined #evergreen |
| 18:23 |
|
jihpringle joined #evergreen |
| 18:25 |
|
jihpringle joined #evergreen |
| 21:09 |
dbs |
jeffdavis: that would be awesome |
| 21:09 |
dbs |
jeffdavis++ |
| 22:03 |
dbs |
Hmm, ~3K of Javascript and a couple of lines of change to the report generator, and we've got ourselves sortable tables in the HTML view of reports. |
| 22:03 |
dbs |
Seems like a decent effort-to-utility ratio |
| 22:05 |
dbs |
(and no, not using dojo grids) |
| 22:25 |
|
mmorgan joined #evergreen |
| 22:25 |
|
mmorgan left #evergreen |
| 22:29 |
|
sarabee joined #evergreen |
| 22:34 |
|
kmlussier joined #evergreen |
| 22:34 |
|
sarabee joined #evergreen |
| 22:48 |
dbs |
And thus bug 1516867 (enhancement, really) was created |
| 22:48 |
pinesol_green |
Launchpad bug 1516867 in Evergreen "HTML reports should be dynamically sortable" [Undecided,New] https://launchpad.net/bugs/1516867 |
| 23:51 |
|
sbrylander joined #evergreen |
| 23:51 |
|
Callender joined #evergreen |
| 23:56 |
|
Bmagic_ joined #evergreen |
| 23:56 |
|
jeff_ joined #evergreen |
| 23:56 |
|
jeff_ joined #evergreen |
