2010-09-09T00:00:55 gah... morning edition again 2010-09-09T00:10:55 perky segue DIE! 2010-09-09T00:16:09 *** tildeequals has quit IRC 2010-09-09T00:28:14 *** tildeequals has joined #evergreen 2010-09-09T00:57:06 *** artunit has quit IRC 2010-09-09T00:57:09 *** artunit_ has joined #evergreen 2010-09-09T00:57:11 *** artunit_ is now known as artunit 2010-09-09T01:21:29 *** dbs has quit IRC 2010-09-09T01:27:30 *** pmpafk has quit IRC 2010-09-09T02:12:31 *** jamesrf has joined #evergreen 2010-09-09T02:12:45 *** jamesrf has quit IRC 2010-09-09T02:17:11 *** tildeequals has quit IRC 2010-09-09T02:28:23 *** tildeequals has joined #evergreen 2010-09-09T05:17:52 *** atz_ has joined #evergreen 2010-09-09T05:20:45 *** atz__ has quit IRC 2010-09-09T07:53:09 *** granitize has joined #evergreen 2010-09-09T07:57:01 *** sfortin has joined #evergreen 2010-09-09T08:11:34 *** gdunbar has quit IRC 2010-09-09T08:32:20 *** gdunbar has joined #evergreen 2010-09-09T08:35:43 *** cameronpurvis has quit IRC 2010-09-09T08:35:47 *** cker has quit IRC 2010-09-09T08:36:10 *** cameronpurvis has joined #evergreen 2010-09-09T08:36:15 *** cker has joined #evergreen 2010-09-09T08:38:00 *** Dyrcona has joined #evergreen 2010-09-09T08:42:10 *** Dyrcona has quit IRC 2010-09-09T08:43:09 *** collum has joined #evergreen 2010-09-09T08:53:39 *** r123 has joined #evergreen 2010-09-09T09:01:16 *** Melissa has joined #evergreen 2010-09-09T09:01:50 *** Melissa has left #evergreen 2010-09-09T09:02:16 *** Melissa has joined #evergreen 2010-09-09T09:02:20 miker_ or anyone else who wants to comment, on the copy_hold_ratio fallthrough bit, any thoughts on only having it fall through on them for renews? Or in general only check them for renews? I don't see how useful they would be for initial checkout anyway. 2010-09-09T09:08:59 *** bshum has joined #evergreen 2010-09-09T09:09:00 tsbere: you can make a renew-specific rule, so if we go with "0 means don't check and don't fall through" then I don't think we do anything different with renew vs circ 2010-09-09T09:09:08 *** bshum has quit IRC 2010-09-09T09:09:08 *** bshum has joined #evergreen 2010-09-09T09:10:22 I am trying to take performance into account. If you never have one of those set and I make it fall through until it runs out of rows or fills them then it will always loop through every possible match. 2010-09-09T09:14:47 I'm not too concerned about that unless you see specific empirical issues. are you? 2010-09-09T09:15:30 even with 100 rules, it should only need to check, maybe, 5 org+group combinations 2010-09-09T09:17:53 I am wondering if I should change it to one query for all permission groups rather than one query per permission group 2010-09-09T09:18:08 I think definitely no 2010-09-09T09:18:17 because we want the closest match to ours 2010-09-09T09:18:26 and that does not equal any ordering of ids 2010-09-09T09:18:30 Didn't say I would change what the closest is 2010-09-09T09:18:45 I'm confused then 2010-09-09T09:19:06 We already have tablefunc available. Connectby gives me a "level" I can sort on. 2010-09-09T09:19:08 let's get it working as expected, then concern ourselves with performance if it proves to be an issue 2010-09-09T09:19:30 tsbere: there are platforms where connectby is pathologically slow 2010-09-09T09:19:41 in particular, debian lenny x64 2010-09-09T09:19:53 *** yboston has joined #evergreen 2010-09-09T09:20:54 Ok, if that is the case, should I be trying to remove the org_unit_ancestors check from the called multiple times query as it is implemented with connectby? 2010-09-09T09:21:10 *** natschil has joined #evergreen 2010-09-09T09:21:32 no 2010-09-09T09:21:53 let's worry about correctness of this one thing and actually test performance 2010-09-09T09:22:22 if it's unacceptably slow, we can revisit 2010-09-09T09:32:36 *** jenny has joined #evergreen 2010-09-09T09:40:25 One more thing miker_: On the "out by circ mod" stuff, should I use the most specific matchpoint only, or have it include all considered/included matchpoints from the fall through? 2010-09-09T09:48:29 I actually (finally) responded to your thread on that. I think we /have/ to use only the inner-most matchpoint. The email gives (I think) a good example of why. 2010-09-09T09:54:45 *** natschil has quit IRC 2010-09-09T09:57:21 * tsbere thinks that some things may need more re-working in the future 2010-09-09T09:57:25 *** natschil has joined #evergreen 2010-09-09T09:58:36 tsbere: they usually do :) 2010-09-09T09:59:14 I am going to implement the ratios fall through as a "check a global flag. If it is set, fall through until they fill, otherwise fall through until the other four fill" bit. 2010-09-09T09:59:15 tsbere: but working code wins 2010-09-09T10:00:46 sounds fine 2010-09-09T10:01:32 *** dbs has joined #evergreen 2010-09-09T10:19:49 without digging into the code, what is the intended use of the holds ratio logic in the circ matrix? 2010-09-09T10:19:59 shorter loan durations for high-demand items? 2010-09-09T10:22:43 Mainly, rejecting checkout on renew when there are too many holds. 2010-09-09T10:23:23 It is used after it has selected a "valid" matchpoint and triggers a failure to checkout rather than changing what rules may be selected 2010-09-09T10:33:23 ah. more sane. :) 2010-09-09T10:34:26 *** natschil has quit IRC 2010-09-09T10:36:29 *** tildeequals has quit IRC 2010-09-09T10:38:25 * tsbere has what he thinks is a valid, functional patch, but has no way to test it right now 2010-09-09T10:43:56 *** tsbere has quit IRC 2010-09-09T10:43:57 *** CmptrWz has joined #evergreen 2010-09-09T10:44:23 *** CmptrWz is now known as tsbere 2010-09-09T10:53:58 *** natschil has joined #evergreen 2010-09-09T10:56:08 * tsbere waits for ubuntu to install in a virtualbox, as he has no clue when the tech will show up with parts for their dev DB server 2010-09-09T11:02:45 * atz_ isn't sure about the eg state of integration... do we do amazon user reviews? 2010-09-09T11:03:10 Didn't a patch recently turn amazon off by default? And it implied only amazon images. 2010-09-09T11:03:39 just noticed (from nengard on koha dev list) that the amazon API is about to drop user review content 2010-09-09T11:04:04 if it's just images and links, then we aren't affected 2010-09-09T11:04:42 the module Evergreen uses for Amazon just deals with images 2010-09-09T11:10:35 tsbere: yes, my patch last night turned off Evergreen by default, and switched to OpenLibrary 2010-09-09T11:11:36 From OpenLibrary we get images + tables of content 2010-09-09T11:12:18 and pr0n according to NGC4LIB :) 2010-09-09T11:12:51 That's what serials support is for. 2010-09-09T11:13:03 ha 2010-09-09T11:13:04 *rimshot* 2010-09-09T11:13:22 * senator switches from popular mechanics to playboy in all his test data 2010-09-09T11:14:12 so dbs, how much code did you have to remove to turn off Evergreen by default? ;) (I know you meant amazon) 2010-09-09T11:15:41 tsbere: Oh, we switched to Horizon 8 a while ago, it's the ILS of the future 2010-09-09T11:16:12 Given what I have seen of Horizon 7, I think that turning evergreen back on would be less headache-inducing ;) 2010-09-09T11:19:50 i doubt openlibrary will be as scalable as amazon, especially internationally 2010-09-09T11:20:42 Which is probably one reason why the default was changed and amazon wasn't removed from the codebase entirely. 2010-09-09T11:20:53 *** tildeequals has joined #evergreen 2010-09-09T11:21:27 *** StephenGWills has joined #evergreen 2010-09-09T11:27:04 tsbere: the main reason was the T&C for amazon -- nasty 2010-09-09T11:27:45 I didn't say the reason the default was changed, I said the reason the amazon code wasn't purged entirely. The commit note said the defautl was because of the T&C. 2010-09-09T11:28:06 Yeah. If you're unhappy with OpenLibrary or want to shill for Amazon to comply with their terms of use, it's easy enough to change. That's what configuration is for. 2010-09-09T11:28:55 grabbing 0390 2010-09-09T11:30:45 though ironically, I hear lots of patrons use Amazon as a front-end for their libraries :) 2010-09-09T11:34:08 *** alxp has joined #evergreen 2010-09-09T11:36:13 *** Dyrcona has joined #evergreen 2010-09-09T11:39:36 grabbing 0391 2010-09-09T11:40:38 phasefx: LibX forever! 2010-09-09T11:42:07 So cool to see example config in opensrf.xml. Computers hooked up to phones! It's a crazy technology world 2010-09-09T11:42:58 We need someone to make evergreen talk to an array of bluetooth cell phones ;) 2010-09-09T11:43:58 I hear you can put a beowulf cluster on those 2010-09-09T11:56:39 * Dyrcona heard you could put a beowulf cluster on just about anything.--Toast, anyone? 2010-09-09T11:58:17 * dbs imagines a beowulf cluster of self-check machines. poor, sickly bastards 2010-09-09T11:59:32 BeoLepers 2010-09-09T12:00:08 *** moodaepo1 is now known as moodaepo 2010-09-09T12:07:34 *** kmlussier has joined #evergreen 2010-09-09T12:20:53 *** natschil has quit IRC 2010-09-09T12:21:58 *** rjackson-isl has joined #evergreen 2010-09-09T12:24:43 *** mck9 has joined #evergreen 2010-09-09T12:29:02 *** pmplett has joined #evergreen 2010-09-09T12:32:32 miker_: since i know you want to lock down schema changes soon... could action.hold_notification grow a boolean for "failed"? 2010-09-09T12:32:46 the other option would be to delete failed notifications, but i think that loses too much data. 2010-09-09T12:33:19 (i've experimented with both approaches) 2010-09-09T12:34:37 jeff: how will it be set? 2010-09-09T12:34:58 automatically in most cases. api call for "mark this notification id failed". 2010-09-09T12:34:59 and will it be nullable, and if so, would that be its default? 2010-09-09T12:36:07 nullable is up to you. usage scenarios would be having the staff client and/or hold shelf expiry routines consider "first non-failed notification" 2010-09-09T12:36:15 display/sort by "first non-failed notification" 2010-09-09T12:36:33 show failure status in the list of notifications when staff are viewing in the client 2010-09-09T12:37:20 also, "create this failed notification" using the existing api with an additional argument. 2010-09-09T12:37:44 jeff: if you can send a patch/tarball with IDL, perl CDBI, schema change and upgrade script, and it doesn't do anything obviously bad by virtue of it existing, I think that's a small enough change 2010-09-09T12:38:01 jeff: so, based on that, I would suggest NOT NULL DEFAULT FALSE 2010-09-09T12:38:07 yeah, i can't. i guess it'll have to wait. 2010-09-09T12:38:18 thanks. :) 2010-09-09T12:38:35 sorry, I'm burried in final run-up :( 2010-09-09T12:38:38 jeff_overlords-- 2010-09-09T12:38:39 * jeff nods 2010-09-09T12:38:43 (not to miker) 2010-09-09T12:38:47 (nod to miker) 2010-09-09T12:39:00 finger-brain-interface requires additional caffeine 2010-09-09T12:44:37 * tsbere wonders if the OpenSRF.pm file in the OpenSRF trunk/rel_1_6 branch should still say version 1.4.0 2010-09-09T12:44:56 jeff: How do classify a failed notification, bad email addresses don't get reported back to EG.... 2010-09-09T12:45:16 moodaepo: Obviously someone has to make that happen! :P 2010-09-09T12:45:30 Really wouldn't be all that hard, though. 2010-09-09T12:45:31 * moodaepo tsbere's it 2010-09-09T12:46:01 Only problem is now you need to decide what mail server to run on one of your boxes. And I am not starting that war. :P 2010-09-09T12:46:26 tsbere: So the mailserver will connect to EG on failure and put in a note? 2010-09-09T12:47:27 Ideally, you find a way to jam a unique ID header in the message, then on bounce you send the message back to an EG server and have the mail server software call a script that is provided with EG that then pulls the ID out and passes that into a function to set the failure state/add a note 2010-09-09T12:47:30 I should put it up on the launchpad as a wishlist. 2010-09-09T12:47:44 tsbere: we stamp it when we roll a release, so in most cases it really doesn't matter 2010-09-09T12:48:25 dbs: I only noticed because when I checked out trunk it said 1.4.0 during one of the steps that was flying by 2010-09-09T12:48:51 we track failed phone notifications and failed emails are not difficult. we'll soon be setting a patron penalty and removing the invalid email address. 2010-09-09T12:48:58 this is a solved issue. 2010-09-09T12:49:05 it should soon be a shared solution. 2010-09-09T12:49:18 jeff++ 2010-09-09T12:49:30 tsbere: I could change the trunk version to OpenSRF-trunk if it would prevent people from worrying about it. 2010-09-09T12:50:27 gah, can't really do that for CPANish reasons I guess 2010-09-09T12:51:30 I do wonder if the rel_1_6 branch should at least have the version set to 1.6.0 2010-09-09T12:51:42 (although I will still be using trunk for this install) 2010-09-09T12:55:00 *** jamesrf has joined #evergreen 2010-09-09T12:55:08 tsbere: rel_1_6 now says 1.6.0, hopefully we can focus on bigger things now :) 2010-09-09T12:55:39 * tsbere focused on that while his virtualbox chugged along with other things 2010-09-09T12:56:51 * jeff prepares to hack on browse slips some more 2010-09-09T12:57:32 jeff: maybe we can get someone from the Software Freedom Conservancy to talk with your director. In all seriousness. 2010-09-09T12:58:39 check out http://laurentian-test.concat.ca/opac/en-CA/skin/lul/xml/rresult.xml?rt=subject&tp=subject&t=encyclopedia&l=106&d=1&f=&av= - after four items, it says "okay, go check the record for more items" 2010-09-09T12:59:01 the concept and theory is approved. the issue is one of details and policy. 2010-09-09T12:59:17 * jeff looks 2010-09-09T12:59:24 dbs: love it! 2010-09-09T13:00:52 jeff: that's straight from the work I did for UPEI, which built on miker_'s fledgling stub for local call numbers in trunk 2010-09-09T13:01:13 dbs: That is so cool. 2010-09-09T13:01:27 mayhaps we should put that (or something like it) into trunk? 2010-09-09T13:03:51 *** natschil has joined #evergreen 2010-09-09T13:04:42 <_bott_> dbs++ well done. That would help with our crazy call numbers that some would love to see before rdetails 2010-09-09T13:08:03 perlmodstyle says "A correct CPAN version number is a floating point number with at least 2 digits after the decimal." Whoops. 2010-09-09T13:10:09 Why does everyone use wildly varying version number requirements? Seriously complicates things. 2010-09-09T13:10:59 We could do "1.60" for 1.6.0 I suppose, but that still complicates / confuses things. 2010-09-09T13:11:15 What if we hit 1.6.10? 2010-09-09T13:11:30 1.6100 obviously. 2010-09-09T13:11:33 * jeff ducks 2010-09-09T13:11:53 *** parser has joined #evergreen 2010-09-09T13:11:54 1.70! Did we learn nothing from Y2K? 2010-09-09T13:12:18 parser! 2010-09-09T13:12:20 *** parser is now known as Guest99327 2010-09-09T13:15:05 *** Guest99327 has left #evergreen 2010-09-09T13:15:36 dang, was about to throw a bunch of MARC records that way 2010-09-09T13:23:43 *** natschil has quit IRC 2010-09-09T13:26:58 *** collum has left #evergreen 2010-09-09T13:38:34 *** jenny1 has joined #evergreen 2010-09-09T13:38:44 *** jenny1 has left #evergreen 2010-09-09T13:41:25 *** jenny has quit IRC 2010-09-09T13:54:09 *** sidi has joined #evergreen 2010-09-09T13:55:12 chrome is giving non-valid security certificate for evergreen site (https://gapines.org/) is this normal? 2010-09-09T13:55:43 as other browsers (firefox safari, etc) are not necessarily generating this error message. 2010-09-09T13:55:49 sidi: is it an invalid cert, or just a mixed content warning? 2010-09-09T13:56:19 IOW, do you get a warning /page/, or just a red X through the "https" part of the URL 2010-09-09T13:56:38 invalid cert as far as i can tell yes red x through https (skull & cross bones) 2010-09-09T13:57:38 miker_: this didn't happen last week and only happens on account log-in so i went to firefox 3.6.8- mac OS10.6 2010-09-09T13:58:37 miker_: with firefox when you enter log-in details it returns a blank page so you have to reload to get a 'real' page. 2010-09-09T13:58:59 sidi: that's just the mixed-content warning. a chrome update may have made it more sensitive. IE will complain about that too, fwiw. it's the fact that some images and CSS are coming through http instead of https 2010-09-09T13:59:09 sidi: now /that/ is something else 2010-09-09T13:59:15 the blank screen 2010-09-09T14:00:06 i am also seeing the skull and crossbones. i believe that is a new UI enhancement with the latest update to chrome stable. clicking on it reveals the meaning: "However, this page includes other resources which are not secure" (the CSS/JS includes that miker_ explained) 2010-09-09T14:00:48 previously, chrome's UI just did a strike-through the URL scheme "https" as a mixed-content warning. 2010-09-09T14:00:59 now it's red and has the skull and crossbones. 2010-09-09T14:01:00 jeff: ok i though It generated for me one of the google type 'do not enter this site' warnings but I could be mistaken 2010-09-09T14:01:10 jeff: *thought 2010-09-09T14:01:25 *** tspindler has joined #evergreen 2010-09-09T14:02:58 miker_: so IOW it is safe, secure to enter details via chrome? ( I am using chrome V. 6.0.472.53 on mac 10.6.x mind you...) 2010-09-09T14:04:02 sidi: it is, yes 2010-09-09T14:04:14 all entered data goes over https 2010-09-09T14:04:32 it's just retrieving some parts of the page via http 2010-09-09T14:04:38 my chrome does the red slash-through and the big nasty warning on the first visit before I say "this one's OK" 2010-09-09T14:05:16 so for most things i visit regularly, it's just the red slash-through 2010-09-09T14:06:15 I asked this offline to Drycona but not finding the problem. In any case, we cannot see the org units in the local admin area for circ policies, hold policies, and copy templates editor (eg 2.0), I had previously tried to do a load of our permissions directly into permissions.grp_perm_map. I thought this was a problems so I reinstalled the defaults. Drycona then suggested our tree might be broken but I can't see any direct pro 2010-09-09T14:07:02 tspindler: i don't have advice for you, but your message was truncated at "might be broken but I can't see any direct pro" 2010-09-09T14:07:05 sidi: it's possible to configure Evergreen to avoid the mixed HTTP/HTTPS settings - try http://laurentian.concat.ca for example 2010-09-09T14:07:42 miker_: ok good to know 2010-09-09T14:07:45 dbs: that is 1.6+, correct? PINES is 1.4.0.7 2010-09-09T14:08:07 jeff: you didn't miss much, but drycona said our org unit tree might be broken, the data looks ok in actor.org_unit, is there somethinig else I should check? 2010-09-09T14:08:08 1.4 can easily support the mixed-content fix. 2010-09-09T14:08:44 as long as your https servers can handle any increased load for hanging out the css/js to https clients, or that your 'static' servers can serve over https. 2010-09-09T14:08:50 dbs: looks good... though all the jacket images are placeholders for me... 2010-09-09T14:08:53 IIRC, IE goes crazy over that mixed-content problem, which is why we had to put it in place 2010-09-09T14:09:12 miker_: SCLends is 1.4 right? Cause I see the skull/crossbones/slash thing on theirs, but for none of the 1.6 sites I've tried so far. 2010-09-09T14:09:23 atz_: I'm filtering you, of course 2010-09-09T14:09:23 miker_: i missed the boat on that one. isn't that for another Lib system? 2010-09-09T14:09:31 :) 2010-09-09T14:09:35 it's a valid issue, and IE 7 and 8 screamed louder than previous versions, but Firefox and Chrome warn you with UI bits also. It was fixed for all of those reasons. :) 2010-09-09T14:10:07 tspindler: if you can paste the output of the following 2 SQL commands, I'll take a look ... 2010-09-09T14:10:07 mmm... crepes 2010-09-09T14:10:24 tspindler: select * from actor.org_unit order by id; 2010-09-09T14:10:26 miker_: sorry wrong person 2010-09-09T14:10:28 tspindler: select * from actor.org_unit_type order by id; 2010-09-09T14:10:32 sidi: :) 2010-09-09T14:10:36 dbs: i missed the boat on that one. isn't that for another Lib system? 2010-09-09T14:10:38 dbs: nm, looks like it was just w/ less popular titles 2010-09-09T14:10:54 bshum: I don't recall ... just a lowly developer here :) 2010-09-09T14:11:18 "I am not my product users' keeper!" 2010-09-09T14:11:45 miker_: tee-hee, just trying to see if I could help. I've been poking at every library who has a listed OPAC on the EG page to see what their https pages respond with in Chrome. I did it once a long time ago when I was learning what SSL certs everybody used. 2010-09-09T14:12:01 bshum: the mixed-content fix is default in 1.6, can be manually backported to 1.4. i don't know if it was ever backported-and-released in 1.4. We ran it in production 1.4 from the time just before it was checked into trunk. 2010-09-09T14:12:28 atz_: the broken jacket images are an artifact of Syndetics, or our implementation of the Syndetics added content, I think 2010-09-09T14:12:47 * dbs goes to change offices again 2010-09-09T14:13:10 jeff: Aha, then maybe that's why I can only see the problem sidi described for gapines and sclends. 2010-09-09T14:13:35 bshum: if you'd like to see the fix, it's in this changeset: http://svn.open-ils.org/trac/ILS/changeset/13288 2010-09-09T14:14:13 *** dbs has quit IRC 2010-09-09T14:14:26 bshum: 1.4, yes 2010-09-09T14:14:44 so sayeth /gateway?service=open-ils.actor&method=opensrf.open-ils.system.ils_version 2010-09-09T14:15:00 miker_: That's a cool trick, I'll have to remember that one. 2010-09-09T14:18:12 *** eby_ has joined #evergreen 2010-09-09T14:18:12 *** eby has quit IRC 2010-09-09T14:18:12 *** eby_ is now known as eby 2010-09-09T14:21:34 miker:I put it on google docs, its long (https://docs.google.com/document/edit?id=1oTJSQ5StlGMlS-Ey1NNBvdemvlfEfGfedxACjSfRFw0&hl=en&authkey=CMLK2boN) 2010-09-09T14:24:04 *** branflakes has joined #evergreen 2010-09-09T14:26:35 miker: I thought this had to do with permisions because when I login as admin (super user), there is not problem, but the other logins have the permission "everything" and seem to have problems 2010-09-09T14:28:09 ahh, well, it certainly could be permissions 2010-09-09T14:29:25 shouldn't the permission "everything" give them everything, but it doesn't seem to 2010-09-09T14:29:56 tspindler: depends on the depth you gave it at 2010-09-09T14:30:05 or, it may 2010-09-09T14:31:03 tspindler: your short names are not very ... short :)( 2010-09-09T14:31:59 anyone have a feel for what information staff find useful or not useful in the Record Summary bar in the staff client? the one that gets layered over the embedded OPAC, and re-used in other places 2010-09-09T14:32:52 miker: lol, we didnn't use true short names to avoid unreadable codes, its a test at this point to see what happens with notices etc. 2010-09-09T14:33:53 miker: the permissions are given at consortium level and for every org unit 2010-09-09T14:34:17 phasefx: I haven't looked at the most recent version but have we added record ID anywhere? 2010-09-09T14:34:20 tspindler: if you're hitting a permission problem you should see something to that effect in the staff client console 2010-09-09T14:35:05 bshum: it exists as a tooltip if you mouse hover over the label "Record Summary" 2010-09-09T14:35:15 phasefx: Ahh, fancy. 2010-09-09T14:35:22 and hidden 2010-09-09T14:35:32 Right, most people wouldn't need to know that. 2010-09-09T14:35:35 a selectable/copyable record id (like the TCN is) would be useful 2010-09-09T14:35:37 tspindler: sec 2010-09-09T14:36:09 well, maybe not to most. *shrug* 2010-09-09T14:36:18 tspindler: http://open-ils.org/dokuwiki/doku.php?id=scratchpad:debug_console 2010-09-09T14:36:19 phasefx: asked the question. i'll let you know what i hear back. 2010-09-09T14:36:35 jeff: I would enjoy having something like that actually. It would make my life easier trying to troubleshoot. 2010-09-09T14:36:44 * phasefx is adding call number info from the bib record (not from asset.call_number), and is thinking about how configurable to make it, and how to juggle layout/real estate 2010-09-09T14:36:49 jeff: But you're right about "most" 2010-09-09T14:38:09 jeff: thanks man 2010-09-09T14:38:52 exit 2010-09-09T14:38:53 miker: thanks, I'll take a look at that. The main problem we are having is that we don't see org_units in the drop down for circ_policies, circ holds matrix, and copy templates editor. This is viewable for those logged in as superuser but not everything at consortium level. 2010-09-09T14:38:57 got at least one "oh, there was something... now i can't remember" :) 2010-09-09T14:38:59 *** sidi has quit IRC 2010-09-09T14:38:59 * phasefx is considering moving Created By and Last Edited By into a tooltip over Last Edited On to make space 2010-09-09T14:40:22 tooltips++ 2010-09-09T14:40:48 don't want to remove data altogether if it's there now, but I'm not adverse to burying it 2010-09-09T14:41:04 in some environments, created by is a very strong quality indicator... staff might miss having quick access to it. 2010-09-09T14:41:24 * bshum agrees with jeff 2010-09-09T14:41:38 but at least you're not getting rid of it completely 2010-09-09T14:41:47 we'll be getting an owner field before long 2010-09-09T14:41:54 if that's not already in trunk 2010-09-09T14:42:21 phasefx: it is 2010-09-09T14:44:07 * phasefx could make it configurable by putting a right-click context menu on each label, where you can change the field being shown for each slot and have it "stick". But there are folks wanting to lock down columns in lists; they'd probably want to lock that down as well 2010-09-09T14:45:04 the other thing is that the summary bar doesn't compress well horizontally, and we're trying to use it in the record merge interface 2010-09-09T14:46:23 phasefx: could style some of them "hidden" in that context? 2010-09-09T14:46:49 it would be very ugly, but we _could_ replace the static layout with a 1-row list (same as used with Record Buckets), and let folks use the column picker as desired, and the copy to clipboard function 2010-09-09T14:47:09 phasefx: boooo :) 2010-09-09T14:47:36 miker_: yeah, it's meant to be overlayed. Right now the Item Status alternate View is layering a Call Number field into it. Easy enough to layer CSS into it 2010-09-09T14:48:22 * berick also notes the unnecessarily large textboxes 2010-09-09T14:48:45 another option is to use HTML and bibtemplate. Make it easy for libs to create their own layout there 2010-09-09T14:50:57 * phasefx experiments some more 2010-09-09T14:51:44 phasefx: are those text boxes to make the data selectable? 2010-09-09T14:52:34 yeah, and it looked cool at the time. Previous incarnation had click-links for trigger the clipboard dialog for certain fields 2010-09-09T14:52:57 change "Publication Date" to "Pub Date" and shrink the data boxes, you could get another column in there 2010-09-09T14:53:15 at least in English 2010-09-09T14:53:17 phasefx: can't regular text be selectable? (have some recollection of that working in other places 2010-09-09T14:53:46 berick: it can be; I'd have to work a bit for the context menus 2010-09-09T14:53:49 *** yboston has quit IRC 2010-09-09T14:54:10 but would be much more compact, eh? 2010-09-09T14:54:43 * phasefx could also style those textboxes differently, so that they're more compact 2010-09-09T14:55:44 incidentally, we're using bre's and mvr's for the data 2010-09-09T14:56:39 I plan to re-use the same callnumber retrieval method that the volume/item wizard is using for the callnumber firled 2010-09-09T14:56:40 DIE MVR, DIE! 2010-09-09T14:57:00 show the first one, tooltip the rest 2010-09-09T14:57:13 *** dbs has joined #evergreen 2010-09-09T15:06:25 Hmm, what does the setting for "Charge Lost on Zero" do? 2010-09-09T15:13:49 phasefx: with the "doesn't compress horizontally" and the merge record interface, consider stacking them vertically instead of having the records-to-be-merged next to each other? i guess that does make it more difficult to visually diff the marc data... 2010-09-09T15:13:53 ...so nevermind. :) 2010-09-09T15:14:14 catalogers deserve large monitors, I say ;) 2010-09-09T15:14:30 they'll still set the resolution to 800x600 2010-09-09T15:14:34 haha 2010-09-09T15:17:30 We're running 1024x768 on 19" monitors here 2010-09-09T15:24:51 majority 1280x1024 here. 1024x768 is second-popular. 2010-09-09T15:25:10 six at 800x600, one at 640x480 2010-09-09T15:25:50 i don't believe that 640 x 480... 2010-09-09T15:25:59 if I ever do a curses interface, I'm dictating at least 80 columns :) 2010-09-09T15:26:10 ah. youth department. inventory caught it while it was in Reader Rabbit or similar. 2010-09-09T15:38:04 *** tspindler has quit IRC 2010-09-09T15:42:15 phasefx: 132col FOREVER 2010-09-09T15:49:47 *** alxp has quit IRC 2010-09-09T15:51:03 *** Callender_ has joined #evergreen 2010-09-09T15:53:18 *** Callender has quit IRC 2010-09-09T15:53:25 *** Callender_ is now known as Callender 2010-09-09T15:56:37 *** Melissa has quit IRC 2010-09-09T15:57:25 *** dbs has quit IRC 2010-09-09T15:59:35 jeff: are you serious? 640x480? I have more than that on my *phone* 2010-09-09T16:00:01 atz_: then you could probably run TWO instances of Reader Rabbit. :) 2010-09-09T16:00:28 atz_: but yes, i confirmed. it was a current and accurate inventory record, the computer just happened to be in-game when it recorded the resolution. 2010-09-09T16:00:42 *** bshum has quit IRC 2010-09-09T16:00:43 ah 2010-09-09T16:00:49 so, no workstations running 640x480 under normal circumstances. :) 2010-09-09T16:00:57 didn't get your RR reference 2010-09-09T16:03:07 *** granitize has quit IRC 2010-09-09T16:03:31 realtime inventory is pretty useful though 2010-09-09T16:05:30 they all seem pretty small though. of course i'm running dual w/ 1600x1200 dell 20-inch secondary. 2010-09-09T16:06:53 *** Melissa has joined #evergreen 2010-09-09T16:06:58 and that monitor's >5 years old. 2010-09-09T16:09:53 *** sfortin has quit IRC 2010-09-09T16:13:02 *** Melissa has left #evergreen 2010-09-09T16:13:33 *** jamesrf has quit IRC 2010-09-09T16:14:22 *** dbs has joined #evergreen 2010-09-09T16:18:20 *** kmlussier has quit IRC 2010-09-09T16:33:41 <_dkyle_> I'm learning a bit about bibtemplate at the moment, and wondering does one need to be running trunk to use format marcxml-full? 2010-09-09T16:40:58 _dkyle_: nope, it's in 1.6 2010-09-09T16:41:08 in fact, it was the default in 1.6 I think 2010-09-09T16:48:19 *** r123 has quit IRC 2010-09-09T16:49:47 *** alxp has joined #evergreen 2010-09-09T16:52:27 <_dkyle_> dbs: hm, ok thanks. back to poking at it 2010-09-09T16:53:15 bibtemplate is enabled in 1.6 -- that's what was part of the cause of the 'doubled titles' bug on rdetail pages. :) 2010-09-09T16:53:27 indeed 2010-09-09T17:07:37 *** jamesrf has joined #evergreen 2010-09-09T17:14:22 *** Dyrcona has left #evergreen 2010-09-09T17:17:56 *** atz__ has joined #evergreen 2010-09-09T17:21:32 *** atz_ has quit IRC 2010-09-09T17:24:54 huh, I went poking around the various naco_normalize() functions in 1_6 trying to make 'ł' convert to 'l' for indexing purposes and finally re-realized that the actual pertinent code doesn't call naco_normalize() at all 2010-09-09T17:25:36 O:A:Ingest::class_index_string_xml() is where the normalizing happens, and there's not much of it 2010-09-09T17:49:15 and we need to adjust O:A:Storage:Driver:Pg:fts::compile() to include that normalization on the incoming search terms 2010-09-09T17:51:14 for some reason I thought we were running everything through a consistent naco_normalize() function. I've been on drugs for a long time, I guess. 2010-09-09T17:53:44 (2.0 can't get here fast enough) 2010-09-09T17:57:43 *** natschil has joined #evergreen 2010-09-09T18:02:56 *** dbs has quit IRC 2010-09-09T18:41:11 *** bshum has joined #evergreen 2010-09-09T18:46:22 has anyone experienced a problem where pcrud processes start going wildly out of control and consuming all the RAM on a given Evergreen machine? 2010-09-09T18:57:16 *** bshum has quit IRC 2010-09-09T19:12:19 branflakes: nothing here 2010-09-09T19:13:01 thanks, moodaepo 2010-09-09T19:13:13 well there was one time some eg process caused something similar on our server a couple of months ago but we couldn't figure out what happened 2010-09-09T19:13:39 a restart fixed the error and we've been waiting for it to happen again 2010-09-09T19:13:48 is it consistent with you? 2010-09-09T19:13:56 I mean the spike 2010-09-09T19:14:03 yeah, we've experienced it a couple times, mostly on our VMs 2010-09-09T19:14:26 usually, though, the first symptom is oom-killer killing getty and ssh, so we can't connect to the machine anymore or log on 2010-09-09T19:14:36 today, i was able to catch it early, by random 2010-09-09T19:15:23 jamesrf (hey jamesrf) is able to reliably recreate the problem on our server by retrieving a list of resource types in the booking module 2010-09-09T19:15:35 from our support IRC channel 2010-09-09T19:15:43 just go to administration -> server admin -> booking -> create resource type -> click "New Resource Type" 2010-09-09T19:16:17 didn't have any "oom-killer killing getty and ssh" issue 2010-09-09T19:16:27 and our problem is/was also on a VM 2010-09-09T19:16:50 i think it might have to do with the fact that there's a 'record id' field and cstore is maybe trying to get every bre.id or something 2010-09-09T19:17:03 we've had one similar incident on our production servers 2010-09-09T19:17:25 it doesn't seem to happen on other bookings screens 2010-09-09T19:17:40 er what version are yous guys running? 2010-09-09T19:17:59 1.6.1 2010-09-09T19:18:05 [custom patched] 2010-09-09T19:18:09 opensrf 1.4 2010-09-09T19:19:21 evergreen rel_1_6_1@17493 2010-09-09T19:20:09 I don't see a booking under administration -> server admin -> 2010-09-09T19:20:22 running 1.6.0.6 2010-09-09T19:20:32 oh right it's in the 1.6.1 branch 2010-09-09T19:24:22 branflakes: PINES had some similar symptoms in the late spring, but I think you're aware of those 2010-09-09T19:24:38 *** jamesrf has quit IRC 2010-09-09T19:25:06 symptom was high system load, not mem-specific, I don't think - but I was not doing the actual troubleshooting 2010-09-09T19:25:16 csharp: yeah, that was the CONNECT BY problem 2010-09-09T19:25:24 ah 2010-09-09T19:25:29 which we're pretty sure we're not experiencing here 2010-09-09T19:25:35 good :-) 2010-09-09T19:25:48 it affected permission calls and org-tree calls (like ou_descendants) 2010-09-09T19:25:49 * csharp had very little fun during those weeks 2010-09-09T19:25:54 right 2010-09-09T19:26:08 it wouldn't be so bad, if those two calls weren't used by pretty much everything :) 2010-09-09T19:26:19 definitely :-) 2010-09-09T19:28:46 I hear that connect by is very slow on some platforms for some reason 2010-09-09T19:31:43 tsbere: miker_ is really the expert on it 2010-09-09T19:32:00 miker_ is the one I heard it from. 2010-09-09T19:32:02 but, in my discussions with him, i was able to garner that it had something to do with glibc 2010-09-09T19:32:08 but that was about it 2010-09-09T19:37:01 I believe it was libc6 on debian lenny 2010-09-09T19:37:29 but only x64 if I understood his comment correctly. Or nobody tested i386 builds. 2010-09-09T19:37:58 we're on x64, but I don't know if it was limited to that 2010-09-09T19:39:30 Yeah, we're on x64, and on Ubuntu hardy, which is based on lenny 2010-09-09T19:44:05 *** phasebb has quit IRC 2010-09-09T19:57:23 there was memcopy "improvement" that affected a certain range of glibc versions -- exactly those that lenny uses. I havent looked at hardy, and they generallyuse more up to date system code 2010-09-09T19:57:41 but there's always a chance that it's a problem 2010-09-09T19:58:36 so, I created a pgmemcache-based alternative 2010-09-09T19:59:49 the problem was only manifest when you do a bunch of the same calls from within a dlopen'd .so 2010-09-09T20:00:13 which connectby does, if you use it a lot 2010-09-09T20:01:42 so we just cache the result for 10 minutes 2010-09-09T20:02:41 reduce the concurrency, the problem goes away 2010-09-09T20:33:42 *** dbs has joined #evergreen 2010-09-09T20:34:10 branflakes: do you know of anyone else running opensrf 1.4.0? 2010-09-09T20:34:40 we're running EG 1.6.1.2-ish but we're still on OpenSRF 1.2.2 2010-09-09T20:35:29 that said, we also haven't done any booking administration work 2010-09-09T20:53:52 dbs: i don't know of anyone else running 1.4 2010-09-09T20:54:55 I'm turning up the logging on the affected server to see if anything jumps out at me, but i'm having some unrelated issues preventing me from running the staff client 2010-09-09T20:56:43 branflakes: okay. Just wanted to try and isolate the possible variables. One change in OpenSRF 1.4 was the switch to libmemcached. 2010-09-09T20:57:05 That shouldn't cause open-ils.pcrud to go nuts though. 2010-09-09T20:57:45 dbs: once i run this increased-level logging test, i will downgrade to 1.2.2 and see if i can replicate the problem 2010-09-09T20:58:18 hmmm... i think that hyphen shouldn't be there 2010-09-09T20:58:41 branflakes++ 2010-09-09T21:09:22 well, jamesrf's theory above was correct 2010-09-09T21:09:30 this appears to show the cause of the problem 2010-09-09T21:09:55 open-ils.pcrud 2010-09-09 18:05:26 [DEBG:28331:oils_cstore.c:4232:12840736162761738] open-ils.pcrud SQL = SELECT "bre".active, "bre".create_date, "bre".creator, "bre".deleted, "bre".edit_date, "bre".editor, "bre".fingerprint, "bre".id, "bre".last_xact_id, "bre".marc, "bre".quality, "bre".source, "bre".tcn_source, "bre".tcn_value FROM biblio.record_entry AS "bre" WHERE "bre".id IS NOT NULL; 2010-09-09T21:10:06 that won't return many records, will it? :) 2010-09-09T21:19:51 senator pasted "oh my" at http://paste.lisp.org/display/114408 2010-09-09T21:20:21 branflakes: see my paste, that ought to fix it if you haven't already. can you confirm? 2010-09-09T21:21:19 senator: best titled paste of the day 2010-09-09T21:29:49 senator: the screen seems to load faster than before, but the runaway loop still seems real 2010-09-09T21:30:05 i restarted Apache and OpenSRF, and i cleared the cache on my client 2010-09-09T21:30:22 branflakes: hrm. 2010-09-09T21:30:40 since those restarts, have you seen any repeats of that query against bre in your logs? 2010-09-09T21:31:54 for that matter, i wonder if a postgres client may still be trying to run one of the earlier instances of that query :-/ 2010-09-09T21:31:58 senator: i'm making sure that it's not a caching issue by restarting both the server and clients 2010-09-09T21:32:00 s/client/process/ 2010-09-09T21:35:04 senator: the call is still being made 2010-09-09T21:36:29 branflakes: i see. only in apparent response to that action in the booking resource type interface, or at other times? 2010-09-09T21:36:45 that's the only action being taken on that server 2010-09-09T21:37:00 * senator looks further 2010-09-09T21:38:40 *** tildeequals has quit IRC 2010-09-09T21:47:32 branflakes: not seeing what would be doing it yet. idea: as for the dialog that gets created when you click "New Resource Type", it should now /not/ have a field labeled "Bibliographic Record", where it had one before. this will just confirm that the patch was applied correctly. can you confirm? 2010-09-09T21:48:31 senator: it still had the record field 2010-09-09T21:48:35 so i am flummoxed a bit 2010-09-09T21:48:42 since the patch is in place correctly 2010-09-09T21:49:55 branflakes: aha. if you're sure that the server-side version of resource_type.tt2 is now updated to include the new line about suppressEditFields, then try clearing the cache on your staff client (alt - - 3), closing any tabs, and going back to that interface. 2010-09-09T21:50:15 i've heard it alleged that the cache can survice staff client restart sometimes. maybe that's all it is here. 2010-09-09T21:51:30 yeah, but cache shouldn't survive 'Clear Cache' 2010-09-09T21:51:35 :) 2010-09-09T21:51:47 Which I did before and after the client restart 2010-09-09T21:52:20 and the booking resource type screen wasn't being displayed when you hit clear cache? 2010-09-09T21:52:47 ah i think i know 2010-09-09T21:53:05 support for that suppressEditFields attr may only be in trunk/2.0 2010-09-09T21:53:05 no 2010-09-09T21:53:07 looking 2010-09-09T21:53:55 dbs: but i did have firefox open 2010-09-09T21:54:09 and i've seen cached objects stick around if other xul applications are open 2010-09-09T21:54:25 branflakes: wow, weird 2010-09-09T21:54:42 i think i was blaming the cache too easily. one more patch forthcoming. this won't require a server restart, but client cache clearing after this patch will be needed 2010-09-09T21:56:59 senator: much obliged for the patches at all :) 2010-09-09T21:57:19 good way of getting a better insight into the workings of autogrid 2010-09-09T21:57:21 i would not get this sort of help from any PNAILSVs. 2010-09-09T21:57:46 senator pasted "this one too" at http://paste.lisp.org/display/114409 2010-09-09T21:59:53 branflakes: no prob. i probably broke it in the first place :-) 2010-09-09T22:02:32 senator: someone unset us up the bomb! it's you! 2010-09-09T22:02:58 s/us up/up us 2010-09-09T22:04:25 hehehe 2010-09-09T22:07:36 so it's all better now? wanna be sure, then i'll make the needed commits 2010-09-09T22:07:42 not that these should hurt anything 2010-09-09T22:11:58 yeah, it's much better, thanx 2010-09-09T22:12:05 np! 2010-09-09T23:02:42 *** phasebb has joined #evergreen 2010-09-09T23:06:11 oof 2010-09-09T23:25:45 *** branflakes has quit IRC 2010-09-09T23:27:38 *** tildeequals has joined #evergreen 2010-09-09T23:41:20 *** phasebb has quit IRC