| Time |
Nick |
Message |
| 00:14 |
|
montgoc1 joined #evergreen |
| 00:26 |
|
dbwells_ joined #evergreen |
| 00:27 |
|
remingtron joined #evergreen |
| 00:32 |
|
zerick joined #evergreen |
| 00:34 |
|
remingtron joined #evergreen |
| 00:34 |
|
dbwells joined #evergreen |
| 03:27 |
|
dbwells_ joined #evergreen |
| 03:28 |
|
ktomita joined #evergreen |
| 03:28 |
|
tfaile joined #evergreen |
| 04:55 |
* csharp |
wakes up too damn early |
| 04:56 |
csharp |
I never sleep well before travel days ;-) |
| 05:48 |
bshum |
I'm awake now too. Slept early instead of packing :) |
| 06:37 |
jeff |
safe travels, everyone. :-) |
| 06:45 |
* jeff |
considers grabbing breakfast and checking out BPL |
| 06:45 |
bshum |
Mmm, breakfast |
| 06:45 |
bshum |
Maybe after I finish deciding which laptop (or laptops?) to bring. |
| 07:18 |
|
Callender joined #evergreen |
| 07:58 |
* csharp |
sits at the terminal, watching planes depart and land |
| 08:01 |
|
rjackson-isl joined #evergreen |
| 08:03 |
csharp |
bleh - no free wifi at Hartsfield |
| 08:08 |
|
eby__ joined #evergreen |
| 08:09 |
gmcharlt |
for folks traveling today and tomorrow, the conference hotel is very conveniently located w.r.t. public transit |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:13 |
csharp |
gncharlt: nice to hear! |
| 08:18 |
|
Dyrcona joined #evergreen |
| 08:20 |
|
bott_otr joined #evergreen |
| 08:22 |
bott_otr |
Is everyone normally here traveling today? |
| 08:27 |
jeff |
Not I, as I am already in Cambridge. :-) |
| 08:31 |
bott_otr |
I'll be there in a few hours. |
| 08:35 |
jeff |
Excellent! |
| 08:40 |
|
DPearl joined #evergreen |
| 08:45 |
DPearl |
I need advice! I'm looking into some monograph parts changes which would require the entire parts list to be displayed. This works nicely for a low number of parts, but when the list is long (say at least 200 parts), the display of the list takes a VERY long time (MINUTES), and "has stopped responding" messages sometimes appear. The resulting display grid might suffer from anomalies: gaps, column width control problems, etc. T |
| 08:46 |
phasefx |
DPearl: got truncated after "column width control problems, etc. Th" |
| 08:49 |
|
mmorgan joined #evergreen |
| 08:50 |
DPearl |
...The db query to retrieve the parts, when executed by itself, is quick. Is there something about dojo I need to know? |
| 08:51 |
DPearl |
phasefx: thanks! Without the rest of the sentence, my question would be more incomprehensible than usual! |
| 08:51 |
phasefx |
I would have expected the parts list to be generated within template toolkit |
| 08:52 |
|
Shae joined #evergreen |
| 08:54 |
|
finnx_ joined #evergreen |
| 08:58 |
|
timlaptop joined #evergreen |
| 09:17 |
|
mrpeters joined #evergreen |
| 09:25 |
|
yboston joined #evergreen |
| 09:28 |
|
ericar joined #evergreen |
| 09:31 |
eeevil |
DPearl: can you explain the use cases? |
| 09:48 |
eeevil |
DPearl: IOW, parts are designed for small lists -- what is the use case for a large list? |
| 09:50 |
DPearl |
eeevil: We use (misuse) parts for issues of periodicals. One part per issue (e.g. 2010 May). Over time, the parts have been entered in inconsistent formats. The work I'm doing is to allow items to be selected and merged into one part with a cannoical name. |
| 09:53 |
eeevil |
DPearl: hrm... is there interest in using serials instead? it supports binding already, and doesn't suffer from the same issues. I realize that there's a workflow, um, impedence mismatch between what you're doing now and serials receiving, but IMO effort there to make manual cataloging of periodicals simpler (or, at least, more like monograph cataloging) would end up paying bigger dividends ... I feel like we've discussed this before ;) |
| 10:22 |
DPearl |
eeevil: I know we have discussed this here quite a bit. From what I know, serials doesn't totally do the job. If a patron is searching for May 2003 of Psychology Today, then they will take ANY issue out there, not just a specific item in a library. |
| 10:22 |
eeevil |
DPearl: by "take" you mean place a hold on? |
| 10:23 |
eeevil |
if that's the case, there may just be misunderstanding ... there are issuance-level holds for exactly the purpose of requesting a specific issuance. akin to callnumber holds |
| 10:24 |
eeevil |
but not bound to a specific branch |
| 10:24 |
eeevil |
hrm... well, wait |
| 10:26 |
eeevil |
I think I see what you're saying. you'd want location-specific subscriptions that share issuances. that is, indeed, not there today, but it certainly could be, and (OTTOMH) with about the same amount of effort as it would take to redefine parts in terms of serials semantics |
| 10:27 |
eeevil |
the thing about parts is that they are intended to support monographs, where the set size is well-bounded. the serials infrastructure is meant to support unbounded sets (which is, of course, the "shape" of a continuing resource) |
| 10:29 |
eeevil |
given a single serial.record_entry for all libraries to use, I could certainly see a way to (virtually) deduplicating issuances, so they're effectively shared across subscriptions. and issuance holds would then be able to cross library (read: subscription) boundaries, all else (like holds rules) being equal |
| 10:31 |
eeevil |
it could even be transparent to the existing infrastructure... a new table with sre.id, issuance-label and shared id; when placing an issuance hold, use the new shared id instead of the issuance id; use triggers to maintain the shared-issuance-label table, and adjust the hold targetter to use the shared id instead of the subscription-specific issuance id |
| 10:32 |
eeevil |
(actually, that's a lot less effort than I'd imagine it'll take to reshape parts) |
| 10:32 |
phasefx |
does anyone have a good rule of thumb for staff client broadband requirements, scaled against number of workstations, cat vs circ loads, etc? |
| 10:33 |
mmorgan |
I think users would also like to be able to place holds on periodicals using the same Place Hold links they use for everything else rather than having to go to a different place to hold a periodical issue. |
| 10:35 |
eeevil |
mmorgan: that's certainly within the realm of possibility ... we detect parts today, we could detect issuances too |
| 10:47 |
DPearl |
eeevil: Thanks for your guidance. It may help me rethink what we are doing. |
| 10:58 |
|
bott_otr joined #evergreen |
| 12:07 |
|
finnx_ joined #evergreen |
| 12:38 |
|
DPearl joined #evergreen |
| 13:17 |
bshum |
That's fancy, the googleguest wifi is the same here in Boston as it was in California. That seems logical now that I think about it. |
| 13:27 |
|
finnx joined #evergreen |
| 13:27 |
|
finnx left #evergreen |
| 13:32 |
|
tspindler joined #evergreen |
| 14:05 |
|
DPearl1 joined #evergreen |
| 14:09 |
|
DPearl joined #evergreen |
| 14:23 |
|
tsbere joined #evergreen |
| 14:53 |
|
Dyrcona joined #evergreen |
| 15:26 |
|
Polonel joined #evergreen |
| 15:26 |
Polonel |
I get this warning in my log when trying to run the hold_targeter.pl script and sometimes my holds will get updated and sometimes it wont. http://paste2.org/NK46w1sf |
| 15:48 |
|
kmlussier joined #evergreen |
| 15:55 |
dreuther |
Can someone explain to me the difference between /openils/conf/fm_IDL.xml and /openils/var/web/reports/fm_IDL.xml |
| 15:56 |
Dyrcona |
dreuther: There shouldn't be any difference. They should be copies of the same file. |
| 15:57 |
remingtron |
Dyrcona: doesn't the reports version of the file use the translatable versions of labels? |
| 15:59 |
Dyrcona |
Hmm... Not sure, you are probably correct. |
| 15:59 |
remingtron |
(from my vague recollection) |
| 15:59 |
dreuther |
So which one should you edit in the source tree? |
| 16:00 |
eeevil |
remingtron: correct |
| 16:00 |
eeevil |
dreuther: there is only one in the source tree. the one under reports/ is generated during packaging |
| 16:02 |
dreuther |
I see two in the source tree one in Open-ILS/examples and one in Open-ILS/web/reports |
| 16:03 |
dreuther |
The reason I ask is I was making a UI for the staff client and could not access a table. I had the FM information in the examples version. So on a whim I copied it to the one in reports and now it works |
| 16:03 |
eeevil |
dreuther: not sure what copy of the git source you're looking at, but there's only one in the repo |
| 16:03 |
dreuther |
Interesting |
| 16:04 |
eeevil |
dreuther: if you're looking at a packaged tarball, that's something different |
| 16:07 |
eeevil |
in any case, they need to match (other than the string literals being replaced by entities in the reports/ version) in an installation |
| 16:10 |
dreuther |
So the file in examples in the source tree is the only one that should be there. Then the other two under openils get built is that correct? |
| 16:11 |
eeevil |
yes. the one under conf/ is a copy, and the one under reports/ is generated for i18n |
| 16:12 |
dreuther |
Ok. I will look into it. I am not sure what is going on. Thanks for the help |
| 16:22 |
* Dyrcona |
heads down to the lobby. |
| 16:40 |
|
tspindler left #evergreen |
| 16:58 |
|
bottotr joined #evergreen |
| 17:21 |
|
mmorgan left #evergreen |
| 17:36 |
|
edoceo joined #evergreen |
| 17:58 |
|
kmlussier joined #evergreen |
| 18:16 |
|
dcook joined #evergreen |
| 18:23 |
|
bott-inhand joined #evergreen |
| 18:26 |
|
bott-inhand joined #evergreen |
| 18:40 |
|
bott-inhand joined #evergreen |
| 19:09 |
|
bott-inhand joined #evergreen |
| 19:24 |
|
rfrasur joined #evergreen |
| 19:43 |
|
bottotr joined #evergreen |
| 20:02 |
|
bbqben joined #evergreen |
| 20:05 |
bbqben |
egils14 attendees - lits of folks@ meadhall |
| 20:05 |
bbqben |
lits = lots |
| 20:14 |
csharp |
bbqben++ # your nick is cool |
| 20:16 |
bbqben |
csharp: thx! |
| 20:20 |
|
burlingtonwa joined #evergreen |
| 20:24 |
|
bbqben left #evergreen |
| 20:53 |
|
gsams joined #evergreen |
| 21:06 |
|
geoffsams joined #evergreen |
| 21:13 |
|
Geoff joined #evergreen |
| 21:18 |
pinesol_green |
[evergreen|Bill Erickson] LP#1294156 TPAC activate hold Submit on load w/ barcode - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d59d8f9> |
| 21:19 |
|
gsams joined #evergreen |
| 21:20 |
|
bottotr joined #evergreen |
| 21:34 |
bshum |
Calling 0874 |
| 21:42 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 21:42 |
pinesol_green |
[evergreen|Mike Rylander] LP#1243023: Make sure URLs are not broken - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a3a81ab> |
| 21:42 |
pinesol_green |
[evergreen|Mike Rylander] LP#1243023: Clean up string handling variable types - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cdb4940> |
| 21:42 |
pinesol_green |
[evergreen|Dan Wells] LP#1243023 Add upgrade script and pgTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=624e0dc> |
| 21:42 |
pinesol_green |
[evergreen|Dan Wells] LP#1243023: Add optional quick reingest to upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8e5dc73> |
| 21:42 |
pinesol_green |
[evergreen|Ben Shum] LP#1243023: Stamping upgrade script for oils_expath-tweaks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e48814> |
| 22:18 |
|
gsams joined #evergreen |
| 22:43 |
bshum |
Calling 0875 |
| 22:45 |
|
Geoff joined #evergreen |
| 22:48 |
pinesol_green |
[evergreen|Mike Rylander] LP#1253163: Materialize authority headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cccf893> |
| 22:48 |
pinesol_green |
[evergreen|Dan Wells] LP#1253163: Make authority functions more truthful - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3f0411f> |
| 22:48 |
pinesol_green |
[evergreen|Dan Wells] LP#1253163: Replace dropped unique index, if we can - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fa417ff> |
| 22:48 |
pinesol_green |
[evergreen|Ben Shum] LP#1253163: stamping upgrade for authority.in-line-headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ffa622> |
| 23:25 |
|
ningalls2 joined #evergreen |
| 23:29 |
|
ningalls2 joined #evergreen |
| 23:31 |
|
ningalls2 joined #evergreen |
| 23:39 |
|
ningalls2 joined #evergreen |
| 23:46 |
|
ningalls2 joined #evergreen |
| 23:53 |
|
ningalls2 joined #evergreen |
| 23:58 |
|
geoffsams joined #evergreen |
