| # | Time | Nick | Message |
|---|
| # | 00:20:07 | Faiz | phasefx i am downloading prepacked version from evergreen site available for download |
| # | 00:44:09 | Faiz | evergreen-setup-rel_2_0_9_2.exe |
| # | 00:57:12 | Faiz | i have installed the evergreen client 2.0.9 it registers and gives error Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow I have installed it from the evergreen site download link it was the pre-packed installer evergreen-setup-rel_2_0_9_2.exe |
| # | 00:58:43 | Faiz | i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer evergreen-setup-rel_2_0_9_2.exe |
| # | 01:00:21 | jamesrf has quit IRC |
| # | 01:00:23 | Faiz | i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer----- evergreen-setup-rel_2_0_9.exe |
| # | 01:02:09 | jamesrf has joined #evergreen |
| # | 01:11:49 | tater has joined #evergreen |
| # | 01:11:51 | mtate has quit IRC |
| # | 01:31:14 | youdonotexist has quit IRC |
| # | 01:39:55 | phasefx | Faiz: what language/locale are you selecting with the staff client? en-US? |
| # | 02:03:22 | Faiz | hi phasefx Yes english US and windows 7 |
| # | 02:03:50 | Faiz | i am installing the client evergreen-setup-rel_2_0_9.exe on windows 7 |
| # | 02:23:31 | Faiz | i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer----- evergreen-setup-rel_2_0_9.exe on windows 7 with english as language |
| # | 02:26:30 | phasefx | Faiz: you should try your client against the 2.0.9 demo server listed here: http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers see if it works for that server |
| # | 02:28:33 | Faiz | same error |
| # | 02:28:56 | Faiz | i downloaded and installed but same error |
| # | 02:31:46 | phasefx | you used the server 75.101.133.94 with the login staff and password demo123? |
| # | 02:32:25 | Faiz | no i used that installer |
| # | 02:32:38 | Faiz | ok if i use that login it works fine |
| # | 02:33:46 | Faiz | it means i have problem in my server |
| # | 02:35:39 | phasefx | compare this file, http://75.101.133.94/xul/server/locale/en-US/offline.properties with the one produced by your server |
| # | 02:35:58 | phasefx | if identical, try the other .property files in that en-US/ directory |
| # | 02:43:22 | Faiz | yeah they are ok |
| # | 02:43:44 | Faiz | what do i do with .property file |
| # | 02:45:34 | Faiz | i have compared the two files mentioned they are same |
| # | 02:47:14 | phasefx | .property files get used by the code that's breaking for you; so if your files are different, or if apache is mangling them in some way when serving them, that could account for the message catalog error |
| # | 02:48:32 | phasefx | Faiz: I fear I must get some sleep; but I'll check my scrollback later. If you find any more clues, I suggest sharing them on the mailing list |
| # | 02:50:08 | Faiz | ok |
| # | 02:51:18 | phasefx | incidentally, I've never seen that error before |
| # | 02:56:11 | Faiz | niether did i |
| # | 02:56:44 | Faiz | where should i start diging now |
| # | 03:46:44 | artunit_ has joined #evergreen |
| # | 03:49:41 | artunit has quit IRC |
| # | 03:49:51 | artunit_ is now known as artunit |
| # | 04:03:37 | Callender has quit IRC |
| # | 04:42:24 | Faiz has quit IRC |
| # | 05:12:29 | Callender has joined #evergreen |
| # | 07:32:13 | bott-otr has quit IRC |
| # | 08:12:29 | dmoses has joined #evergreen |
| # | 08:12:41 | adbowling-isl has joined #evergreen |
| # | 08:18:39 | sfortin has joined #evergreen |
| # | 08:19:35 | dmoses has quit IRC |
| # | 08:29:00 | AaronZ-PLS has joined #evergreen |
| # | 08:34:34 | Faiz has joined #evergreen |
| # | 08:35:07 | Faiz | i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer----- evergreen-setup-rel_2_0_9.exe on windows 7 with english as language |
| # | 08:35:47 | Faiz | i have also chkd the demo server and it resulted that my server end is faulty |
| # | 08:45:55 | Meliss has joined #evergreen |
| # | 08:49:17 | plux has joined #evergreen |
| # | 09:09:29 | natschil has joined #evergreen |
| # | 09:11:29 | natschil has joined #evergreen |
| # | 09:16:47 | natschil has quit IRC |
| # | 09:16:50 | Dyrcona has joined #evergreen |
| # | 09:18:04 | natschil has joined #evergreen |
| # | 09:18:13 | akilsdonk has joined #evergreen |
| # | 09:18:41 | natschil has quit IRC |
| # | 09:19:31 | natschil has joined #evergreen |
| # | 09:21:33 | natschil has joined #evergreen |
| # | 09:23:45 | natschil has joined #evergreen |
| # | 09:25:39 | natschil has quit IRC |
| # | 09:26:02 | natschil has joined #evergreen |
| # | 09:26:35 | natschil has joined #evergreen |
| # | 09:27:07 | jenny1 has joined #evergreen |
| # | 09:28:51 | jamesrf has quit IRC |
| # | 09:31:00 | jamesrf has joined #evergreen |
| # | 09:33:00 | natschil has quit IRC |
| # | 09:36:52 | dbs has joined #evergreen |
| # | 09:36:52 | dbs has joined #evergreen |
| # | 09:42:40 | kmlussier has joined #evergreen |
| # | 09:43:51 | tater has quit IRC |
| # | 09:44:06 | mtate has joined #evergreen |
| # | 09:46:52 | IRCReaderBOT has joined #evergreen |
| # | 09:47:48 | Faiz has quit IRC |
| # | 10:08:42 | collum has joined #evergreen |
| # | 10:11:03 | sal_ has joined #evergreen |
| # | 10:27:49 | gmcharlt has quit IRC |
| # | 10:31:25 | bott-otr has joined #evergreen |
| # | 10:34:06 | kmlussier has quit IRC |
| # | 10:34:29 | kmlussier has joined #evergreen |
| # | 10:45:43 | gmcharlt has joined #evergreen |
| # | 10:55:08 | yboston has joined #evergreen |
| # | 10:57:28 | bott-otr has quit IRC |
| # | 11:06:32 | gdunbar has joined #evergreen |
| # | 11:11:56 | matt_carlson has joined #evergreen |
| # | 11:13:43 | youdonotexist has joined #evergreen |
| # | 11:16:55 | tsbere | hmmm |
| # | 11:17:18 | tsbere | What happens if I have a reporter datatype of "id' on a field that is not guaranteed to be unique when looking at that single data source? |
| # | 11:22:43 | gdunbar | tsbere: nothing good (says eeevil) |
| # | 11:25:50 | tsbere swaps it to "link" then |
| # | 11:26:46 | dbs | phasefx: huh, can't find the evergreen trademark / logo info on the web site or wiki |
| # | 11:27:23 | dbs | phasefx: specifically, the usage criteria |
| # | 11:29:07 | phasefx | hrmm |
| # | 11:30:27 | phasefx | I think this is the right end-point: http://www.georgialibraries.org/lib/pines/evergreenlogo/ |
| # | 11:31:14 | collsk12 has joined #evergreen |
| # | 11:31:52 | dbs | phasefx++ |
| # | 11:31:59 | dbs | yeah, search was doing nothing for me |
| # | 11:32:22 | dbs | I think the logo / trademark is being transferred to SFC, but for now I'll link to that |
| # | 11:34:02 | Dyrcona | Is there a pull request meeting today? |
| # | 11:34:18 | dbs | Supposed to be |
| # | 11:36:02 | phasefx | dbs: oh man, I so thought that email was spam *8) |
| # | 11:36:09 | dbs | heh |
| # | 11:37:47 | phasefx | so the trademark/etc. are being transferred directly to the SFC? I thought we formed some legal entity that itself joined the SFC? |
| # | 11:38:19 | dbs | phasefx: no, SFC is the legal entity |
| # | 11:38:44 | dbs | of which the Evergreen project is a member organization, represented by the Evergreen Oversight Board |
| # | 11:38:57 | phasefx | ah, okay |
| # | 11:39:25 | phasefx | tells you how mushy my brain is |
| # | 11:39:43 | dbs | So the Evergreen Oversight Board will need to draft some form of logo/trademark guidelines if GPLS transfers the logo/trademark to the SFC |
| # | 11:40:22 | dbs | (probably s/GPLS/SFC under the advisement of the Evergreen Oversight Board/ or whatever) |
| # | 11:42:21 | dbs has been very un-devvy for the past few weeks owing to beginning of school deadlines :( |
| # | 11:42:32 | dbs | so much ldap, so little time |
| # | 11:46:30 | collsk12 has joined #evergreen |
| # | 11:47:08 | jrodge01 has joined #evergreen |
| # | 11:50:58 | collsk12 | Odd question: I recently imported a MARC record into a brand new installation of Evergreen 2.1. After a great deal of struggle, I have the title showing up on the OPAC; however, when I use the "Holdings Maintenance" it still shows the example branches, even though I've already removed them. |
| # | 11:51:20 | mrpeters-isl | collsk12: have you re-run autogen since deleting them? |
| # | 11:51:29 | collsk12 | Yes |
| # | 11:52:13 | mrpeters-isl | have you made sure they don't exist in actor.org_unit? |
| # | 11:52:46 | mrpeters-isl | SELECT * FROM actor.org_unit WHERE shortname = 'BR-1'; -- that should be a good check |
| # | 11:53:02 | mrpeters-isl | or maybe it's BR1 |
| # | 11:53:19 | mrpeters-isl | yeah, BR1 |
| # | 11:53:37 | collsk12 | I've checked. Just the ones I've added show up. |
| # | 11:53:48 | phasefx | also, the staff client doesn't get its org info from the file autogen produces, but from an opensrf method. may need to restart perl services to eliminate caching |
| # | 11:54:08 | collsk12 | phasefx: Let me try that. |
| # | 11:58:10 | collsk12 | Nah, still there. The OPAC searches are also acting strangely. I have to manually select the library I want to search. Otherwise, I just get a spinning mouse cursor with no results. |
| # | 11:59:22 | dbs | sounds kind of like org_unit depths and org_unit_types are mismatched |
| # | 11:59:25 | phasefx | may want to sanity check org depths/types and ... |
| # | 11:59:56 | dbs also doesn't know if the version of 2.1 collsk12 is running needs cache-generator.sh still |
| # | 12:00:03 | phasefx | http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#finding_mis-matched_depths_with_org_units_and_org_unit_types |
| # | 12:04:55 | collsk12 | No results came back from the query and it's still showing this record as belonging to SYS2 and circulating in SYS2, yet it's available at CLMC. |
| # | 12:05:47 | collsk12 | What's cache-generator.sh? |
| # | 12:11:46 | artunit_ has joined #evergreen |
| # | 12:12:27 | matt_carlson has quit IRC |
| # | 12:13:19 | dbs | collsk12: it was a temporary replacement for autogen.sh; you would call "cache-generator.sh -u". we're back to autogen.sh now I think. |
| # | 12:13:31 | dbs | pull requests? or no |
| # | 12:13:38 | artunit has quit IRC |
| # | 12:13:53 | artunit_ is now known as artunit |
| # | 12:15:04 | collsk12 | dbs: Ah...thanks. There is a cache-generator.sh in bin folder. Should I run it, or is that a bad idea? |
| # | 12:15:23 | dbs | I would try it, just to see. |
| # | 12:18:19 | jrodge01 | I'm having some trouble with the installation. |
| # | 12:18:28 | collsk12 | dbs: No dice :( |
| # | 12:18:57 | tsbere | dbs: I think we should do pull requests. But I dunno if enough people are paying attention to IRC. |
| # | 12:19:32 | dbs | tsbere: I would like to, but the fire being applied to me for LDAP synchonizing here suggests I won't be able to pay attention either |
| # | 12:24:27 | collsk12 | jrodge01: What kind of trouble are you having? |
| # | 12:27:14 | dbwells | collsk12: I just pushed a branch which may fix what you are seeing. It is for 2.0, but I suspect if affects 2.1 as well. Here is the one simple commit: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=de74179598ecc00bcf0629382929dfeb9481757e |
| # | 12:28:51 | collsk12 | dbwells: Now that's service!! :) I'll check it out. Thank you. |
| # | 12:30:17 | dbwells | collsk12: Well, it might seem like it, but really just coincidence :) To test, apply the fix, then re-run autogen.sh. You may also need to clear the client cache, not sure. |
| # | 12:30:41 | collsk12 | OK...thanks again. |
| # | 12:31:30 | dbwells | collsk12: I am out for a bit, but will check the scrollback this afternoon to see how it went. |
| # | 12:32:03 | collsk12 | OK...enjoy. I'll update you in a few. |
| # | 12:44:39 | jrodge01 | collsk12: I have trouble starting OpenSRF. When I do, I get an error with Jabber saying I couldn't authenticate. I can type the error if needed. |
| # | 12:45:49 | eeevil | re pull requests, it looks like tomorrow at noon won't conflict with any other community meetings. this being a short week in the US making today feel like monday for some of us, shall I put out a suggestion on -dev to coordinate for that? |
| # | 12:46:07 | gmcharlt | +1 |
| # | 12:49:28 | collsk12 | jrodge01: OK. How far along did you get? Did you register your Jabber users? And, if so, did you modify the conf files to reflect the passwords you registered? |
| # | 12:51:09 | Dyrcona | eeevil: tomorrow works for me. |
| # | 12:54:39 | jrodge01 | collsk12: I believe so. I followed the installation instructions here: http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.6:install |
| # | 12:55:04 | jrodge01 | collsk12: Up until "Starting OpenSRF" |
| # | 12:58:10 | akilsdonk has quit IRC |
| # | 12:59:16 | jrodge01 | collsk12: If you have any advice, please share. I have to step out for a bit, but will check back. If not, I'll go through the installation instructions one more time. |
| # | 13:04:25 | collsk12 | I would double check your conf files. If they look good, I would "unregister" your users and re-register them. I've had that work for me before. Keep in mind I am not a developer, nor do I play one on tv. |
| # | 13:08:57 | sal_ | jrodge01: why are you using the 1.6 install instructions? |
| # | 13:09:08 | sal_ | Which version of Evergreen are you planning to run? |
| # | 13:10:13 | sal_ | jrodge01: (Not sure how much difference there is, but opensrf is up to version 2.0.1; install directions here: http://open-ils.org/dokuwiki/doku.php?id=opensrf:2.0:install) |
| # | 13:27:09 | tsbere | Anyone have opinions on how I did this? http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=shortlog;h=refs/heads/extra_idl |
| # | 13:27:40 | tsbere | Well, beyond "apparently should throw some of it further down the file so it doesn't show up as a *core* source" that I am discovering happens. |
| # | 13:35:35 | collsk12 | dbwells: Applied the fix and re-ran autogen. Restarted the client and all looks good. Thanks for the fix! |
| # | 13:45:26 | jrodge01 has quit IRC |
| # | 13:54:33 | matt_carlson has joined #evergreen |
| # | 14:05:16 | matt_carlson has quit IRC |
| # | 14:26:02 | collsk12 has quit IRC |
| # | 14:39:10 | adbowling-isl has quit IRC |
| # | 14:39:52 | adbowling-isl has joined #evergreen |
| # | 14:41:25 | natschil has joined #evergreen |
| # | 14:48:53 | eeevil | tsbere: it shows up as a core source because of reporter:core="true", fwiw |
| # | 14:49:10 | tsbere | eeevil: I literally just noticed that and was removing it from my new ones. <_< |
| # | 14:49:59 | tsbere is having issues with one of the two new ones, but has at least one more thing to try before trying to dig out errors |
| # | 14:51:02 | eeevil | tsbere: I'm not a fan of a magic number when "unknown" (aka NULL) is a reasonable answer ... any reason to coalesce there? |
| # | 14:51:33 | tsbere | eeevil: On which piece? |
| # | 14:51:33 | eeevil | also, may want to use the all_circulation view to account for aged circs |
| # | 14:51:52 | eeevil | the rlc <class> |
| # | 14:52:14 | eeevil | sorry, was just looking at the last commit |
| # | 14:52:15 | tsbere | and yea, I realized I wasn't using all_circulation. Am more concerned with getting it to work, then I will make that one behave. |
| # | 14:53:34 | tsbere | as for the magic number.....what happens if I try and say the age of a null is greater than X? |
| # | 14:54:28 | eeevil | NULL > X -> false |
| # | 14:54:34 | eeevil | NULL < X -> false |
| # | 14:55:05 | eeevil | if it hasn't circ'd, it doesn't have a last circ date :) |
| # | 14:55:17 | tsbere | That particular one is intended for use with a weeding report (with the commented out form of it for us). They want "never circulated" copies to show up in such reports. |
| # | 14:56:16 | eeevil | so, the semantics are more like "created or last circ'd", yes? |
| # | 14:56:37 | eeevil | I mean, you don't want to include brand new copies in a "haven't circed in 10 years" report, right? |
| # | 14:57:19 | tsbere | The way they talk? Some of them might. |
| # | 14:57:26 | eeevil | so, a created_or_circulated timestamptz column seems reasonable, assuming I'm right ;) |
| # | 14:57:44 | tsbere is trying to figure out why the reporter thinks asset.copy has a last_circ column right now |
| # | 14:59:10 | eeevil | sounds like a virtual field for holding the id of the most recent circ |
| # | 14:59:24 | eeevil | missing oils_persist:virtual="true" maybe? |
| # | 14:59:32 | eeevil | yep |
| # | 14:59:48 | eeevil | nope |
| # | 15:00:10 | tsbere | While I am in the file anyway |
| # | 15:00:24 | eeevil | ahh... because it's a has_a relationship |
| # | 15:00:27 | tsbere moves to all_circulation view and changes magic number of year 1 to the copy creation date |
| # | 15:01:10 | eeevil | might_have is probably what you want (even though it will always be there in your view) |
| # | 15:01:38 | tsbere | ok |
| # | 15:02:38 | jamesrf has quit IRC |
| # | 15:02:48 | tsbere | The other new one appeared to work right away for me. Ran a couple tests, moved on. <_< |
| # | 15:04:40 | tsbere | You see any issues with it while I test some of the changes to the last circ one? |
| # | 15:06:07 | jamesrf has joined #evergreen |
| # | 15:06:15 | eeevil | the other one is interesting ... it's a point in time only report ... the WHERE clause may need to grow, but it's probably "close enough" since the data it's using will be constantly changing anyway |
| # | 15:06:52 | tsbere | It is supposed to be a point in time report |
| # | 15:06:58 | eeevil | right |
| # | 15:07:07 | eeevil | just observing the obvious ;) |
| # | 15:07:19 | tsbere | There is a similarish one next to it in the IDL that does things very differently. |
| # | 15:11:00 | tsbere | Oh, hey, cool, an error message I understand........because postgresql is a PITA sometimes. <_< |
| # | 15:13:25 | eeevil | that other one is meant to be a relatively performant approximation. how fast does your new one run on large datasets? (I may be able to test that soon, btw) |
| # | 15:13:59 | tsbere | I can run both queries and compare them on the same large dataset if you want |
| # | 15:15:22 | eeevil | if you include a definition of large, I'd love to see that, actually (hold count, bib count, copy count, hold-copy-map size) ... and, obv, it only needs to be fast when there's a where-clause supplied, like, for bib id, or pickup lib in yours. |
| # | 15:15:31 | eeevil | I wouldn't expect the baseline to be fast ;) |
| # | 15:16:06 | tsbere | Mine just spit out 37323 rows in 13924 ms. The one that was already there is still running. |
| # | 15:16:16 | tsbere | Sans where clauses |
| # | 15:16:33 | eeevil | like: SELECT * FROM ( ... that big view ... ) WHERE bib_id = xxx; |
| # | 15:16:43 | eeevil | tsbere: right, but with a param... |
| # | 15:16:46 | tsbere | The one already in the IDL returned 21663 rows in 66670 ms |
| # | 15:17:11 | eeevil | the old one is used with a param from within the UI |
| # | 15:17:17 | tsbere | Well yea. |
| # | 15:17:35 | tsbere | But how do you expect me to pick a bib number with holds unless I grab a list of bibs with holds? ;) |
| # | 15:17:42 | eeevil | heh |
| # | 15:19:05 | akilsdonk has joined #evergreen |
| # | 15:19:28 | tsbere | Also, the two give me very different results on a lot of holds for copy count |
| # | 15:21:06 | tsbere | doing the "SELECT * FROM ( blah ) WHERE id = x" for a specific X (and with an alias on the blah) mine is actually much faster, though. Let me find one with a bigger hold count, though. I randomly grabbed one with a single hold, period. |
| # | 15:23:20 | tsbere | Running on the exact same dataset, mine returned 37 rows for a bib with 442 holds and 43 copies everywhere in 10,834ms. The one from the IDL sees the same number of holds and copies but due to lack of pickup library returned one row, but took 64,254ms to do so. |
| # | 15:28:07 | tsbere wasn't really expecting his to be faster, due to trying to return more info |
| # | 15:31:36 | tsbere | eeevil: I think the one in the IDL is hindered by all the subselects going on. |
| # | 15:36:08 | berick thinks the EG git server might need NTP |
| # | 15:36:35 | senator thinks every server needs ntp |
| # | 15:36:41 | berick | well, yeah ;) |
| # | 15:36:43 | dbs curses the barbarians that force YY-MM-DD date format even in civilized locales like en-CA |
| # | 15:37:29 | dbs | "Why is this person's account expired? It's not Oct 2011 yet!" |
| # | 15:37:48 | berick | (checks to see if the commit author's machine was not the source of the future timestamp) |
| # | 15:38:18 | dbs | commit time vs. authoring time? |
| # | 15:39:22 | berick | note to committers, plz install NTP :) |
| # | 15:39:59 | tsbere | berick: I think at one point I installed NTP on the git server already |
| # | 15:41:04 | berick | tsbere: indeed, I take back my comment about the server. |
| # | 15:41:13 | berick | 'twas a client-side issue |
| # | 15:41:24 | kmlussier has quit IRC |
| # | 15:41:29 | phasefx has chaos powers across time and space |
| # | 15:41:47 | kmlussier has joined #evergreen |
| # | 15:42:08 | tsbere | eeevil: Would you like me to take a crack at re-writing the hold ratio query that was already there? |
| # | 15:42:56 | dbs religiously types "date --set '1972-01-01'" before committing anything |
| # | 15:43:45 | eeevil | tsbere: sorry, stepped away. sure, go for it. I'll look for some time to test it on another large dataset soon |
| # | 15:45:43 | tsbere | eeevil: For the record, the dataset I was running on has 902196 bibs, 3267915 copies, 55232 active holds |
| # | 15:46:04 | tsbere | (excluding deleted bibs and copies) |
| # | 15:55:35 | eeevil | tsbere: thanks. I should be able to test on something comparable ... are you building a test script, btw? (np if not) |
| # | 15:56:04 | tsbere | I have not built a test script. I keep running things via pgadmin |
| # | 16:05:12 | Meliss has quit IRC |
| # | 16:24:06 | tsbere | eeevil: http://paste.lisp.org/display/124516 |
| # | 16:27:30 | adbowling-isl has quit IRC |
| # | 16:28:20 | dbs has quit IRC |
| # | 16:28:49 | kmlussier_ has joined #evergreen |
| # | 16:29:54 | eeevil | arg! can't force-push to working... bah |
| # | 16:30:34 | kmlussier has quit IRC |
| # | 16:30:46 | kmlussier_ is now known as kmlussier |
| # | 16:31:24 | eeevil | grabbing 0615 |
| # | 16:31:55 | tsbere | eeevil: You should be able to force-push to working. Unless it is someone else's collab? |
| # | 16:32:22 | eeevil | tsbere: it is |
| # | 16:32:40 | eeevil | it's fine, though. was just going to push an amended commit msg |
| # | 16:32:45 | eeevil | and then merge |
| # | 16:32:48 | eeevil | so... no biggy |
| # | 16:35:38 | collum has quit IRC |
| # | 16:39:24 | plux has quit IRC |
| # | 16:42:59 | tsbere | eeevil: You have any opinions on potential accuracy versus speed where both options are a massive improvement on the original? |
| # | 16:45:02 | eeevil | tsbere: if the semantics of the new version are as correct or more so than the original, then I have no problem replacing it ... but I haven't looked very closely at that. Is that what you mean? |
| # | 16:45:52 | tsbere | eeevil: I came up with two replacements. The slower one uses the hold copy maps and I think gets more accurate copy counts on a number of hold types. The faster one should return things identically to the original. |
| # | 16:47:35 | eeevil | tsbere: using the hold-copy-map has the drawback of missing "new" copies (not yet placed on the potentials list) .... the one without can overestimate the copy count, of course (and is more work to maintain, as the definition of holdability changes) |
| # | 16:49:17 | tsbere | so one can overestimate copy counts and is potentially more work to maintain. The other can underestimate copy counts but automatically obtains new holdable information from the perl layer. |
| # | 16:49:22 | eeevil | since it's meant to be an approximation for immediate use in a UI, I'd tend toward faster if it's close enough |
| # | 16:49:58 | tsbere | Some of the records I see go by have hundreds of potential copies in the non-maps version and <10 in the maps version |
| # | 16:50:01 | eeevil | or, that's an important use case ... not the only one, of course |
| # | 16:51:12 | tsbere | and I see a few metarecord related holds that result in a reversal. The non-maps version reports a smaller number than the maps version, because the non-maps version doesn't take into account the other format records and their copies. |
| # | 16:51:12 | eeevil | hrm... that amount of a discrepancy is a concern |
| # | 16:51:33 | eeevil | right, I'd expect that for M-type |
| # | 16:52:13 | tsbere | The "hundreds without the hold copy maps, only a few with" happens when all of the holds are part holds, copy holds, and volume holds, it seems. |
| # | 16:52:40 | eeevil | ahh... /that/ sounds like an improvement, then |
| # | 16:53:25 | eeevil | how big is your hold-copy-map? |
| # | 16:53:53 | tsbere | 947886 |
| # | 16:54:10 | bgoble has joined #evergreen |
| # | 16:59:46 | tsbere | eeevil: So do you think the slower version using the hold copy map table is the better choice (given that even it is significantly faster than what is there now)? |
| # | 17:04:50 | eeevil | tsbere: well, the times you're getting don't jibe with what's in use at a production site, so I'll need to look closer, but I'd like to test all variants for sure |
| # | 17:05:46 | eeevil | which I'll have to do later ... COMMUTE TIME! :) |
| # | 17:06:17 | eeevil | biab |
| # | 17:06:26 | natschil has quit IRC |
| # | 17:06:37 | tsbere is using a copy of MVLC's production database that tends to get less CPU and memory than the actual production DB |
| # | 17:07:00 | tsbere | Production data (as of Sunday morning) though |
| # | 17:23:39 | akilsdonk has quit IRC |
| # | 17:30:46 | Dyrcona has quit IRC |
| # | 17:36:31 | kmlussier has quit IRC |
| # | 17:37:56 | artunit_ has joined #evergreen |
| # | 17:39:23 | artunit has quit IRC |
| # | 17:39:33 | artunit_ is now known as artunit |
| # | 17:52:19 | bott-otr has joined #evergreen |
| # | 17:57:07 | jenny1 has left #evergreen |
| # | 18:01:35 | sal_ has quit IRC |
| # | 18:12:28 | sfortin has quit IRC |
| # | 18:25:39 | yboston has quit IRC |
| # | 18:32:59 | matt_carlson has joined #evergreen |
| # | 18:53:15 | _bott_ has quit IRC |
| # | 18:54:02 | _bott_ has joined #evergreen |
| # | 19:00:07 | matt_carlson has quit IRC |
| # | 19:17:40 | youdonotexist has quit IRC |
| # | 19:23:13 | bott-otr has quit IRC |
| # | 19:26:40 | bott-otr has joined #evergreen |
| # | 20:25:54 | jtgorman has joined #evergreen |
| # | 20:31:38 | bott-otr has quit IRC |
| # | 20:32:53 | bott-otr has joined #evergreen |
| # | 20:37:16 | bott-otr has quit IRC |
| # | 20:48:04 | jtgorman has quit IRC |
| # | 21:00:05 | bgoble has quit IRC |
| # | 21:26:25 | _bott_ has quit IRC |
| # | 21:56:12 | gdunbar has quit IRC |
| # | 21:56:12 | leed has quit IRC |
| # | 21:58:12 | gdunbar has joined #evergreen |
| # | 21:58:12 | leed has joined #evergreen |
| # | 22:59:29 | youdonotexist has joined #evergreen |
April 10-13