| Time |
Nick |
Message |
| 00:09 |
|
sandbergja joined #evergreen |
| 00:33 |
|
sandbergja joined #evergreen |
| 00:45 |
|
sandbergja joined #evergreen |
| 02:14 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
agoben joined #evergreen |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
rfrasur joined #evergreen |
| 08:17 |
|
collum joined #evergreen |
| 08:30 |
alynn26 |
exit |
| 08:40 |
|
mantis1 joined #evergreen |
| 08:41 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
rjackson_isl |
stage left |
| 08:48 |
mmorgan |
No! Stage right! |
| 08:49 |
Dyrcona |
exeunt |
| 08:56 |
Dyrcona |
exeunt socialis instrumentis quidquid sit |
| 08:57 |
Dyrcona |
...scaena tergo |
| 08:57 |
Dyrcona |
:) |
| 08:57 |
* Dyrcona |
stops showing off...:) |
| 09:03 |
Dyrcona |
Bummer. I can't find the "coolest bug report ever." |
| 09:04 |
Dyrcona |
And, just as I type that.... I see bug 922128 in the list! |
| 09:05 |
pinesol |
Launchpad bug 922128 in Evergreen "Scrollbars non sunt multiplicanda praeter necessitatem" [Undecided,Won't fix] https://launchpad.net/bugs/922128 |
| 09:06 |
mmorgan |
Heh. |
| 09:11 |
|
dbwells joined #evergreen |
| 09:11 |
Dyrcona |
Oh well, today is not the day for a massive bug triage. |
| 09:28 |
csharp |
Dyrcona++ |
| 09:28 |
csharp |
sylvar++ |
| 09:28 |
Dyrcona |
sylvar++ ... indeed. |
| 09:38 |
|
yboston joined #evergreen |
| 09:44 |
rfrasur |
Hmm, Dyrcona - that's the "smart people only" bug. |
| 09:44 |
Dyrcona |
heh.... rfrasur++ |
| 09:47 |
rfrasur |
Though...would that be...latinglish? I dunno. |
| 09:47 |
rfrasur |
it's all worrisome. |
| 09:48 |
Dyrcona |
Well, I don't think there's a Latin word for scrollbars, and I'm not sure you could invent that would have the same meaning. |
| 09:49 |
rfrasur |
I'm pretty sure you're right. |
| 09:51 |
mmorgan |
Seems like there isn't really an English word for scroll-bars either ;-) |
| 09:51 |
Dyrcona |
:) |
| 09:51 |
rfrasur |
Unless there's some level of pre/medieval society that we just don't know about yet - a technology component that was obliterated before they could decide on a way to store and retrieve what would become deprecated formats. |
| 09:51 |
Dyrcona |
Atlantis maybe.... :) |
| 09:52 |
rfrasur |
Do you think they spoke Latin? or a some dialect/derivative? |
| 09:52 |
mmorgan |
Atlantis must've had a place where they served drinks and you could read scrolls. |
| 09:52 |
Dyrcona |
No. IF there was an Atlantis, I doubt that they spoke Latin. |
| 09:53 |
Dyrcona |
They would have likely spoken an earlier and lost form of Indo-European, possibly an older form of Greek or Persian. |
| 09:58 |
berick |
now I want to open a bar called The Scroll Bar that's wrapped in a Faraday cage (no phones) and has scrolls about for reading |
| 09:58 |
Dyrcona |
berick++ |
| 09:58 |
alynn26 |
berick++ |
| 09:58 |
mmorgan |
berick++ |
| 10:00 |
alynn26 |
That bug is from Zagazig, Egypt. |
| 10:01 |
JBoyer |
berick++ |
| 10:09 |
rfrasur |
berick++ |
| 10:10 |
rfrasur |
We might need to have a Faraday cage at the next conference. And a theremin band. And a Tesla coil. |
| 10:10 |
rfrasur |
what could go wrong? |
| 10:11 |
Dyrcona |
:) |
| 10:11 |
csharp |
@band add Faraday Cage |
| 10:11 |
pinesol |
csharp: Band 'Faraday Cage' added to list |
| 10:11 |
csharp |
@band add Tesla Coil |
| 10:11 |
pinesol |
csharp: Band 'Tesla Coil' added to list |
| 10:11 |
Dyrcona |
I would add a band called..... |
| 10:12 |
Dyrcona |
csharp: There's already a real band called "Tesla." |
| 10:12 |
* csharp |
plays Little Suzi and bangs head |
| 10:12 |
Dyrcona |
:) |
| 10:13 |
rfrasur |
Dyrcona, I think there needs to be a new bug, related to scrollbars, that references lost Indo-European language and technology. Possibly including references to an additional bug related to the 5th Element. |
| 10:14 |
Dyrcona |
:) |
| 10:14 |
* rfrasur |
shrugs |
| 10:14 |
berick |
@band add Multipass |
| 10:14 |
pinesol |
berick: Band 'Multipass' added to list |
| 10:14 |
Dyrcona |
There's a guy named Randall Carlson who has some interesting ideas regarding human prehistory. However, that's not an endorsement of his statements. :) |
| 10:16 |
rfrasur |
Dyrcona, still interesting even sans endorsement. |
| 10:19 |
alynn26 |
I thought all geometry was sacred. |
| 10:22 |
Dyrcona |
Pythagoras thought so. |
| 10:23 |
* rfrasur |
thinks all mathematics are sacred. |
| 10:23 |
* rfrasur |
refers to herself in the third person a lot. |
| 10:24 |
Dyrcona |
:) |
| 10:24 |
alynn26 |
algebra is not sacred. |
| 10:27 |
|
sandbergja joined #evergreen |
| 10:38 |
Dyrcona |
Oh, yeah! I was going to look at bug 1855329 for miker. |
| 10:38 |
pinesol |
Launchpad bug 1855329 in Evergreen "Followup to bug 1827250, hold shelf issues" [High,New] https://launchpad.net/bugs/1855329 |
| 10:39 |
Dyrcona |
Guess I'll do that after I finish up what I'm working on, now. |
| 10:41 |
mmorgan |
miker: if you're around, I'm all ears about that factor of 1000 in relevance calculation. |
| 11:00 |
miker |
mmorgan: it basically comes down to scaling. the core relevance ranking spits out a number between 0 and 1 with /many/ digits of precision. the popularity ranking spits out a value between 1 and 5 (or null, no popularity bump). much of the time, because (for instance) keyword indexed fields are long compared to the query, the top rel ranking value starts in the 0.00xxxx range. the 1000 multiplier just shifts the decimal point right by 3 places, so x. |
| 11:00 |
miker |
xxxx. that's at the same order of magnitude as the popularity value and sets a baseline for comparability. we /then/ scale the pop value down (or up) using the popularity scaling modifier (global flag, defaulting to 0.2 IIRC) to soften or strengthen the effect of the popularity bump. |
| 11:09 |
* mmorgan |
goes to check the global flag... |
| 11:09 |
berick |
sandbergja++ # i was just about to request feedback on the marc edit stuff, thanks! |
| 11:10 |
csharp |
pretty sure that Fedora Firefox bug is playing havoc with all my extensions too, not just EG staff client |
| 11:11 |
* csharp |
lags behind dbs in finding the problems :-) |
| 11:12 |
miker |
mmorgan: so, yeah, to make popularity more important you should adjust that setting. |
| 11:15 |
miker |
mmorgan: and, finally, the reason for the change is that there was no real functional difference between sort on pop vs poprel because of the (lack of) scaling before application of the popularity addition. it was all popularity all the time for both, effectively |
| 11:15 |
mmorgan |
miker: Any processing needed after changing the global flag? |
| 11:21 |
* csharp |
confirms that installing from https://koji.fedoraproject.org/koji/buildinfo?buildID=1420745 solves the EG and extensions issues |
| 11:25 |
mmorgan |
I'm not seeing the effect of popularity I would expect. |
| 11:25 |
mmorgan |
I have a 3.2.9 Concerto system. My test search is a title search on symphony, result set is 5 hits. |
| 11:26 |
mmorgan |
I give the least relevant hit a popularity score of 5, (added directly in the db to rating.record_badge_score). Global flag search.max_popularity_importance_multiplier is set to the max at 2.0. |
| 11:27 |
miker |
mmorgan: you might need to restart services (storage in particular) |
| 11:27 |
mmorgan |
My record with the badge is #4 in the poprel sort. |
| 11:27 |
* mmorgan |
will restart. |
| 11:31 |
* mmorgan |
restarted services. The record with the popularity badge is still 4 out of 5 on the list of hits. |
| 11:35 |
mmorgan |
I captured the search query from the logs |
| 11:36 |
pastebot |
"mmorgan" at 168.25.130.30 pasted "poprel search title:symphony" (74 lines) at http://paste.evergreen-ils.org/10106 |
| 11:36 |
mmorgan |
will see if I can paste the query result |
| 11:38 |
Bmagic |
Looking at upgrading 3.3.4 to 3.3.5. The SQL script makes a massive update to action.circulation which takes *awhile* - auto_renewal = false where it's NULL. I was thinking of making the updates in smaller batches ahead of time. Any reason I shouldn't? |
| 11:39 |
mmorgan |
Bmagic: That's what we're doing. |
| 11:39 |
Dyrcona |
Bmagic: Lots of reasons that you should, actually. |
| 11:39 |
jeff |
mmorgan: is it possible that the popularity score isn't enough to bring the least-relevant record up in the rankings any more than it already has? |
| 11:39 |
Bmagic |
oh good! |
| 11:39 |
Dyrcona |
Bmagic: Do you have log shipping replication enabled? |
| 11:39 |
Bmagic |
yes |
| 11:40 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "SQL for chunking 3.3.5" (61 lines) at http://paste.evergreen-ils.org/10107 |
| 11:40 |
Dyrcona |
That update if run all at once will generate lots of logs, so that's a good reason to break it up into chunks. It could fill up the space where the logs are being shipped. |
| 11:41 |
Dyrcona |
I'd do it over a number of days, or whatever period you clean up the shipped logs. |
| 11:41 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "run_auto_renewal_updates.sh" (24 lines) at http://paste.evergreen-ils.org/10108 |
| 11:42 |
mmorgan |
jeff: The popularity score is the highest it can be. If it can't ever push that record higher, than 4 out of 5, then the popularity badge will always be ineffective. We noticed a significantly decreased effect of our popularity badges after upgrading to 3.1 |
| 11:42 |
Dyrcona |
Part of the troulbe that I had with systemd during out last update was the query to update action.aged_circulations filled up the log space on the replication db server. |
| 11:43 |
Bmagic |
That's the code I've created to do the job (sql file and bash sh file) |
| 11:43 |
Dyrcona |
Yeah, I'm not sure it needs to be so complicated. Have you tested it on a test db server? |
| 11:44 |
Bmagic |
It seems to be working, one of the bugs I found came when updating action.circulation rows with target_copy IDs that don't exist in asset.copy. Stemming from trigger fake_fkey_tgr() |
| 11:44 |
Bmagic |
Dyrcona: yep, it's purring like a kitten |
| 11:44 |
Bmagic |
and the server is functional wihle it's running. I can renew/circ/etc with no perceived slowness |
| 11:46 |
Dyrcona |
Bmagic: I'd make pointer, chunk, and stop_at_total parameter of the function, or maybe just chunk and stop_at_total. |
| 11:46 |
pastebot |
"mmorgan" at 168.25.130.30 pasted "poprel search query result" (8 lines) at http://paste.evergreen-ils.org/10109 |
| 11:47 |
Bmagic |
I was concerned that the rows needed to have auto_renewal = NULL for the 3.3.4 server to "work" correctly but if that's not the case, then I'd like to make these updates ahead of time to save time on upgrade day |
| 11:47 |
Dyrcona |
Bmagic: Or maybe just have a start id parameter and total parameter and have the function return the next id after the last one that it processed. |
| 11:48 |
Dyrcona |
Bmagic: They don't need auto_renewal = NULL for anything to work correctly. FALSE or NULL works from a functional point of view. FALSE is much better for reporting. |
| 11:49 |
Bmagic |
Dyrcona++ # cool, that's good news |
| 11:49 |
Dyrcona |
FALSE is also more logical and what should have been done from the start. |
| 11:49 |
Dyrcona |
The update of the aged_circulation table will likely take much longer, since it usually has more rows. |
| 11:50 |
Bmagic |
whilst on the topic of auto_renewal - I would expect the action.circulation rows (that were created when matching an auto_renew rule) to have TRUE set for that column, but that doesn't seem to be the case (at least on 3.3.4) |
| 11:50 |
csharp |
Bmagic: I have already made the change on action.circulation and am not planning on worrying about action.aged_circulation - if we ever implement autorenew and need reports and people run reports on historical circs expecting anything useful, I'll tell them to stop that |
| 11:50 |
Dyrcona |
Bmagic: They should. |
| 11:51 |
Dyrcona |
Bmagic: Oh wait... I think you misunderstand the auto_renewal field and I misunderstood your statement. :) |
| 11:51 |
Bmagic |
ok, then I guess the action.circulatoin rows weren't matched on those circ rules, but it begs the question why the autorenewal AT triggers hit those rows.... |
| 11:51 |
Dyrcona |
auto_renewal should only be TRUE if the circ in question is created by an auto-renewal. |
| 11:51 |
miker |
mmorgan: FTR, sorting by popularity alone /does/ fall back to tie-breaking on relevance. does sort(pop) do what you want? |
| 11:52 |
Bmagic |
Dyrcona: ah! I was wondering if that were the case |
| 11:53 |
mmorgan |
miker: Yes, pop sort does what I would expect, most popular item sorts first. |
| 11:53 |
Dyrcona |
csharp: While I agree with your sentiment, I was "asked" to update aged_cirulcation, too. |
| 11:53 |
csharp |
heh |
| 11:54 |
csharp |
I figure there's no need for the NOT NULL on the aged table since it's just going to get whatever was in action.circulation |
| 11:54 |
csharp |
but I understand |
| 11:58 |
mmorgan |
miker: For comparison, I'll paste in query and result from a poprel search on a 3.0.9 Concerto system set up with the same badge and global flag. |
| 11:59 |
Dyrcona |
I was asked to do it on aged_circulation to keep the reports simple, mainly. |
| 11:59 |
csharp |
makes sense |
| 12:01 |
pastebot |
"mmorgan" at 168.25.130.30 pasted "poprel search query 3.0.9" (68 lines) at http://paste.evergreen-ils.org/10110 |
| 12:04 |
pastebot |
"mmorgan" at 168.25.130.30 pasted "poprel search query 3.0.9 result" (8 lines) at http://paste.evergreen-ils.org/10111 |
| 12:07 |
mmorgan |
Order of results for a poprel search between 3.0.9 and 3.2.9 is quite different. |
| 12:10 |
|
sandbergja joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 12:13 |
miker |
mmorgan: I'm not sure that the pop stuff is the only factor, though I imagine it's impacting things ... you're using different dictionaries (simple vs english_nostop), and of course the virtual index def addition of keyword to the title class changes ranking input (for instance, longer records will have lower baseline rel due to cover density on the keyword data) |
| 12:13 |
miker |
mmorgan: but, to be clear, you don't want to switch to sort(pop)? |
| 12:14 |
* miker |
drifts away, but will be back ... |
| 12:23 |
|
mantis2 joined #evergreen |
| 12:30 |
|
collum joined #evergreen |
| 12:31 |
|
khuckins joined #evergreen |
| 12:34 |
mmorgan |
miker: for when you return: we want to be able to use the sort that fits the situation. Sometimes pure relevance, sometimes pop, and sometimes poprel. |
| 12:52 |
dbs |
Bmagic / Dyrcona: bonus of being way back on 3.1 is that I was able to tweak 3.1.5-3.2.0-upgrade-db.sql to add DEFAULT FALSE NOT NULL to the ADD COLUMN statement and avoid all of that pain |
| 12:52 |
Bmagic |
dbs: nice! |
| 12:53 |
dbs |
Maybe we should actually backport that to the 3.1.5-3.2.0 upgrade script in case anyone else needs to go through that |
| 12:53 |
Bmagic |
( I had similar thoughts like "If I just knew ahead of time, I could have tweaked the query to default FALSE) |
| 13:10 |
* Dyrcona |
shrugs. It's OK with me, but too late for many of us. |
| 13:13 |
Dyrcona |
There are probably enough sites left that will be affected by it for the change to be worthwhile. |
| 13:18 |
Dyrcona |
Of course, that complicates applying the later update scripts. |
| 13:20 |
dbs |
Yep, there would likely be some ripple effect |
| 13:23 |
dbs |
actually - it seems that ALTER TABLE foo ALTER COLUMN bar SET DEFAULT FALSE; for a column that already is set to DEFAULT FALSE doesn't trigger an error. So... maybe not? |
| 13:32 |
|
gerlevi joined #evergreen |
| 14:18 |
|
cmalm joined #evergreen |
| 14:22 |
|
mantis1 joined #evergreen |
| 14:55 |
|
sandbergja joined #evergreen |
| 15:00 |
|
agoben joined #evergreen |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:19 |
jeff |
that worked! |
| 15:19 |
jeff |
that worked a little too quickly... |
| 15:20 |
jeff |
SELECT count(*) FROM action.circulation; |
| 15:20 |
jeff |
491 |
| 15:20 |
jeff |
(oh. that's why.) |
| 15:23 |
|
rjackson_isl joined #evergreen |
| 15:25 |
|
remingtron joined #evergreen |
| 15:28 |
|
pastebot joined #evergreen |
| 15:35 |
|
mantis1 left #evergreen |
| 15:53 |
|
khuckins joined #evergreen |
| 16:45 |
|
mmorgan joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:36 |
|
rfrasur joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:25 |
|
Christineb joined #evergreen |
| 19:07 |
|
cmalm_ joined #evergreen |
| 19:33 |
|
rfrasur joined #evergreen |
| 20:14 |
|
librarionator joined #evergreen |
| 20:14 |
librarionator |
hello! I was wondering if it were simple to start a home library system |
| 20:16 |
librarionator |
I have a private collection that I would like to catalogue since a lot of people are interested in it |
| 20:17 |
librarionator |
I run linux, and I can keep the computer always on or program it to run on start. Is it mandatoryt to install the network server? |
| 20:18 |
librarionator |
I installed the windows GUI launcher via wine, but it asked to connect to my evergreen server |
| 20:19 |
librarionator |
if the server and GUI were running on the same computer, I wouldn't need to worry about the networking hassle, right? since it could access it within the same macine? |
| 20:39 |
jihpringle |
hi librarionator, this channel is most active between 9am and 5pm Eastern Time so if you donm |
| 20:39 |
jihpringle |
don't see a response tonight you may want to check back during that window |
| 20:40 |
jihpringle |
another option is to ask your question on the general mailing list - https://evergreen-ils.org/communicate/mailing-lists/ |
| 20:50 |
|
sandbergja joined #evergreen |
| 23:37 |
dbs |
jeff: Not sure if you were referring to the ALTER TABLE DEFAULT FALSE NOT NULL working quickly, but it was pretty much instantaneous on our 471,000 row action.circulation table |
| 23:37 |
dbs |
(I know that's a pittance compared to public library numbers) |
