| Time |
Nick |
Message |
| 00:46 |
|
zerick joined #evergreen |
| 01:38 |
|
stevenyvr2 joined #evergreen |
| 01:39 |
|
stevenyvr2 left #evergreen |
| 02:49 |
|
Lunchb0x joined #evergreen |
| 05:44 |
|
laque joined #evergreen |
| 07:21 |
|
Dyrcona joined #evergreen |
| 07:32 |
|
jboyer-isl joined #evergreen |
| 07:34 |
|
bkuhn joined #evergreen |
| 08:25 |
csharp |
okay - I'm back to troubleshooting my circ rule issue - the problem is that we have a rule based on a circ modifier called 'dvd' assigned to dvd items. When I use the find_circ_matrix_matchpoint test on an item, patron, and location on our production server, the correct rule matches. When I do the same test on our test server, it picks a different rule. |
| 08:25 |
csharp |
The only thing I've changed is linking a circulation limit set |
| 08:26 |
csharp |
the rule it selects on our test server is based on the item's marc type |
| 08:27 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ policy matching descrepancy" (16 lines) at http://paste.evergreen-ils.org/34 |
| 08:27 |
csharp |
as you'll see in the paste, rule 159 no longer matches |
| 08:27 |
|
timf joined #evergreen |
| 08:28 |
|
6JTAAYHEW joined #evergreen |
| 08:28 |
|
5EXAA0D1E joined #evergreen |
| 08:29 |
csharp |
oddly, removing the circ limit set association does *not* restore it to normal |
| 08:29 |
|
timf joined #evergreen |
| 08:30 |
Dyrcona |
@quote random |
| 08:30 |
pinesol_green |
Dyrcona: Quote #21: "< Dyrcona> Writing software is more fun than working." (added by csharp at 09:29 AM, November 29, 2011) |
| 08:36 |
|
kbeswick joined #evergreen |
| 08:37 |
csharp |
created CSVs of a dump of circulation policies on test and production and diffed them - no difference |
| 08:39 |
csharp |
btw - test image is from 6/26, so no substantial differences between the datasets |
| 08:40 |
|
finnx joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
Dyrcona |
csharp: I've not ever seen the behavior you described in my environment. If I check something out in production and in development, I get the same matchpoint. |
| 08:47 |
Dyrcona |
unless, I've deliberately changed the mathcpoints in order to get a different one. |
| 08:47 |
* Dyrcona |
tells his fingers to wake up. |
| 08:48 |
|
finnx left #evergreen |
| 08:48 |
|
finnx joined #evergreen |
| 08:52 |
|
ericar joined #evergreen |
| 08:56 |
csharp |
Dyrcona: thanks - that helps |
| 09:17 |
Dyrcona |
really? that helps? |
| 09:18 |
Dyrcona |
mcooper isn't back. |
| 09:18 |
Dyrcona |
I was gonna ask if his computer crashed trying to process a 4GB MARC with the command line xpath program. |
| 09:18 |
Dyrcona |
My guesstimate is that it would want 200GB of RAM. |
| 09:19 |
bshum |
Dyrcona: mcooper is in California, but maybe he's an early bird. |
| 09:23 |
csharp |
Dyrcona: it helps to know that the same behavior isn't universal |
| 09:23 |
csharp |
since I'm troubleshooting |
| 09:24 |
csharp |
(admittedly, it would've helped *more* if you'd seen the same thing) |
| 09:24 |
bshum |
csharp: The assigned circ weights are the same right? |
| 09:24 |
csharp |
bshum: yep - no other differences between configurations |
| 09:24 |
* bshum |
is curious what the weighting is like anyways. |
| 09:25 |
csharp |
but as tsbere pointed out, if the rule isn't matching, weights won't help |
| 09:25 |
csharp |
it just makes the right one "float to the top" |
| 09:25 |
bshum |
True. |
| 09:26 |
csharp |
I'm using the Default weightset, which has worked fine for us until now |
| 09:28 |
* bshum |
checks to see what that is :) |
| 09:33 |
pastebot |
"csharp" at 204.193.129.146 pasted "default weightset" (7 lines) at http://paste.evergreen-ils.org/35 |
| 09:36 |
bshum |
csharp: Can you paste the rules 139 and 159 from your test server? |
| 09:36 |
bshum |
Curious to see what the rows look like. |
| 09:37 |
pastebot |
"csharp" at 204.193.129.146 pasted "more details on circ limit set setup" (43 lines) at http://paste.evergreen-ils.org/36 |
| 09:37 |
|
rfrasur joined #evergreen |
| 09:38 |
csharp |
I'll paste 139 too |
| 09:38 |
pastebot |
"csharp" at 204.193.129.146 pasted "circ matrix matchpoint 139" (4 lines) at http://paste.evergreen-ils.org/37 |
| 09:39 |
bshum |
What's the copy location of the item you're testing? |
| 09:39 |
bshum |
Just the first thing that jumped out to me looking at rule 159 |
| 09:39 |
|
remingtron joined #evergreen |
| 09:39 |
bshum |
Hopefully 7404 |
| 09:39 |
csharp |
we don't use copy locations in our rules since copy locations are managed at the library level |
| 09:40 |
csharp |
that would multiply our number of rules exponentially |
| 09:40 |
bshum |
But 7404 is in the column for "copy_location" in the paste. |
| 09:40 |
bshum |
That's why I was asking. |
| 09:40 |
csharp |
hmm |
| 09:40 |
bshum |
It might be why it doesn't match. |
| 09:41 |
csharp |
bshum: good catch |
| 09:41 |
rfrasur |
collaboration++ |
| 09:41 |
csharp |
copy location is unset in the UI |
| 09:42 |
* bshum |
scoffs at "the UI" :) |
| 09:42 |
bshum |
But that is annoying... |
| 09:42 |
csharp |
wth? |
| 09:42 |
bshum |
We don't use copy location for any of our rules, so I'm afraid I wouldn't know why it doesn't show properly... |
| 09:42 |
bshum |
:( |
| 09:42 |
csharp |
that copy location is owned by a single one of our branches |
| 09:43 |
Dyrcona |
UI is for wimps. Real hackers use butterflies. |
| 09:43 |
* bshum |
has always just looked directly at the rows in the table. |
| 09:43 |
csharp |
so something about adding the circ limit set added a copy location without telling anybody |
| 09:43 |
bshum |
UI doesn't work when one is playing with over 4k entries. |
| 09:44 |
rfrasur |
Dyrcona++ |
| 09:44 |
csharp |
I like the UI because that means we don't need server access to manage/tweak configs |
| 09:44 |
bshum |
Well, it does... but very slowly with 15 a clip :) |
| 09:45 |
* csharp |
can't believe he's having to justify UI usage |
| 09:46 |
rfrasur |
hah |
| 09:46 |
csharp |
okay - when I nullify the copy location, the right rule is (unsurprisingly) retrieved again |
| 09:46 |
csharp |
bshum: thanks for your eagle eyes |
| 09:47 |
rfrasur |
it worked? |
| 09:47 |
csharp |
well, we're at least back to getting the right circ rule |
| 09:47 |
bshum |
csharp: Glad it works. Not so glad that the UI didn't catch it, and also that it magically appeared. |
| 09:47 |
Dyrcona |
heh. I was just telling someone else here why we don't configure circ matchpoints with copy locations. |
| 09:47 |
rfrasur |
yay! |
| 09:47 |
rfrasur |
bshum++ |
| 09:47 |
csharp |
I can file a bug about the UI issue |
| 09:47 |
* Dyrcona |
points to csharp's issue. |
| 09:47 |
bshum |
For fun, csharp, I might recommend adding auditor tracking to the matrix tables. |
| 09:47 |
bshum |
If you're going to leave it open for others to poke at via the UI. |
| 09:48 |
csharp |
actually, that's a great idea on many levels |
| 09:48 |
bshum |
Then you could have a history of what they changed. |
| 09:48 |
bshum |
And how to unchange it. |
| 09:48 |
Dyrcona |
csharp: I think there's already a bug about the UI issues, but adding that copy location doesn't show up may be helpful. |
| 09:48 |
csharp |
absolutely |
| 09:48 |
bshum |
We recently activated auditor tracking a few months back |
| 09:48 |
bshum |
And I *love* it. |
| 09:48 |
csharp |
I bet |
| 09:48 |
Dyrcona |
I'm the only who touches the matrices here. Even tsbere is too chicken. :p |
| 09:49 |
csharp |
same here - I'm the only one who understands... er who *best* understands the interface ;-) |
| 09:49 |
|
eeevil joined #evergreen |
| 09:49 |
|
berick joined #evergreen |
| 09:49 |
bshum |
It's not always just who but when, if only because inevitably the library asks, why's our circ this way, we didn't say to do that. |
| 09:49 |
bshum |
And you can point back to when it changed or didn't change |
| 09:50 |
Dyrcona |
we point to RT, 'cause nothing changes without a ticket. |
| 09:50 |
bshum |
Which happens to us all the time when the librarians don't always get the message from top down on circ policies. |
| 09:50 |
bshum |
So we get calls at different levels asking for different rules :( |
| 09:50 |
Dyrcona |
Ah well, back to perusing 9xx tags in a MARC file to see if I can figure out what they mean. |
| 09:50 |
csharp |
well tracking would've helped me a couple of years ago when I broke circ *during the day* and had to quickly fix it ;-) |
| 09:50 |
Dyrcona |
So, have a ticketing system, and say "No tickee, no changee." |
| 09:51 |
bshum |
Dyrcona: We do that too. And still nobody gets it. |
| 09:51 |
bshum |
:D |
| 09:51 |
rfrasur |
lol, Dyrcona - are y'all wanting to use 9xx as access points or something? |
| 09:51 |
csharp |
I wasn't sure what I'd changed, and that was... panic-inducing |
| 09:51 |
bshum |
csharp++ # using the UI is intended, just doesn't always work evidently :( |
| 09:51 |
bshum |
Or at least, I imagine it's intended for somebody. |
| 09:52 |
Dyrcona |
rfrasur: We are getting a new member this summer, and there current ILS uses 949 for copy information, so I'm looking at a dump before I try loading/merging their records with ours. |
| 09:52 |
rfrasur |
csharp: "during the day" - sounds like a party...that no one wanted to go to |
| 09:52 |
csharp |
whew - that was fun |
| 09:52 |
csharp |
ah the memories |
| 09:52 |
rfrasur |
Dyrcona: our cataloging policy doesn't allow for local notes in the MARC |
| 09:53 |
* Dyrcona |
smacks his fingers again. |
| 09:53 |
|
remingtron joined #evergreen |
| 09:53 |
rfrasur |
EG has plenty of other functionality that can handle copy notes |
| 09:53 |
|
remingtron joined #evergreen |
| 09:53 |
Dyrcona |
rfrasur: Right, but this how their current ILS handles those things. Looks like I'll be throwing most of it out. |
| 09:53 |
bshum |
rfrasur: We'll love it more once we get the ability to search for copy notes in TPAC. Not that we're working on it, we just dream for it. |
| 09:54 |
* bshum |
still isn't entirely happy with the way public notes appear in the catalog yet. |
| 09:54 |
mmorgan |
csharp: I've recently added some circ rules by copy location, and realized that only the ones that match the workstation registration show. If I'm logged in as another library, it's blank. |
| 09:54 |
bshum |
But I can live with it. |
| 09:55 |
bshum |
mmorgan: csharp: :\ is my unhappy, well *that's* awkward face to hearing that... |
| 09:55 |
rfrasur |
bshum: I anticipate that it'll happen sooner rather than later because it's something that librarians talk (harp) about. |
| 09:56 |
bshum |
rfrasur: Without question. |
| 09:56 |
bshum |
Especially now that public notes are visible. |
| 09:56 |
rfrasur |
lol, yes :D |
| 09:57 |
csharp |
yay!! |
| 09:57 |
csharp |
it works |
| 09:57 |
rfrasur |
csharp++ |
| 09:57 |
csharp |
bshum++ |
| 09:57 |
csharp |
bshum++ |
| 09:57 |
csharp |
bshum++ |
| 09:57 |
|
mrpeters joined #evergreen |
| 09:57 |
rfrasur |
:D |
| 09:58 |
bshum |
The fortunate (or unfortunate) side effect of having spent too many days looking at the circ matrix in my lifetime. |
| 09:58 |
* dbs |
wonders whether the copy location didn't show up in the UI because it was outside of the workstation scope |
| 09:59 |
rfrasur |
bshum:can you spend too many days? |
| 09:59 |
bshum |
rfrasur: I used to think "why can't we just create the rules and be done with it" |
| 09:59 |
bshum |
Boy was I wrong :( |
| 10:00 |
rfrasur |
bshum: but wouldn't it be nice? |
| 10:00 |
dbs |
You guys aren't helping my nerves around our eventual cut-over to in-DB from scripts. |
| 10:01 |
csharp |
dbs: yes - it was outside of the scope - the copy location belongs to our sister library |
| 10:01 |
* dbs |
will miss the ability to use regexen against circ mods to determine rules |
| 10:01 |
* rfrasur |
takes a deep breath and a swig of coffee and heads back to the soul sucking collection list that will be an inventory list...by tomorrow? (yeah, right) |
| 10:01 |
dbs |
csharp: that would probably be useful info for the bug report :) |
| 10:01 |
bshum |
I remember being all bright-eyed and so happy to be on 1.6 and using in-DB circ instead of having to learn writing scripts for our library rules :D |
| 10:02 |
|
yboston joined #evergreen |
| 10:02 |
dbs |
OTOH, I won't miss continuing breakage of script-based circ as only the dark pockets of libraries like Conifer and UPEI limp on with them... |
| 10:03 |
bshum |
Just thinking aloud, but it seems bad to allow copy location to be set for a specific library if they're also creating consortium level rules (or rules in general that affect greater than just them). |
| 10:03 |
csharp |
Indiana's still using script-based circ too, I think |
| 10:04 |
* csharp |
agrees |
| 10:04 |
bshum |
Since we don't let end users create policy, I don't think we've ever tested restricting the level of rules they can create. |
| 10:04 |
rfrasur |
csharp: yes...I think we are (because it breaks from time to time) |
| 10:04 |
bshum |
Or if that's possibly restricted by permission. |
| 10:12 |
rfrasur |
So, explain to me while I'm editing a million call #s - why not to use the "circ as type" attribute? |
| 10:13 |
jeff_ |
The copy-level "circulate as type" attribute is designed as an override for the MARC type. |
| 10:13 |
jeff_ |
If you have circ rules based on marc type, and for some reason you want a copy attached to a bib of MARC type g to circulate as MARC type a, you would set the copy-level override. |
| 10:14 |
rfrasur |
okay...in that case, I do stick behind using it at least for now. |
| 10:14 |
jeff_ |
In our environment, we have no need for the override. |
| 10:14 |
* csharp |
is having a hard time finding the existing bug on the circ policies UI |
| 10:14 |
jeff_ |
And to the best of my knowledge, the copy-level attribute is used for nothing else. |
| 10:15 |
jeff_ |
I can see how it could be a shortcut for reporting, but that doesn't apply for us. |
| 10:15 |
rfrasur |
we have enough poor MARCs coming in as people migrate (and legacy from old migrations), that that attribute could make things behave...ish |
| 10:15 |
rfrasur |
well....libs migrate...not people (at least not into Evergreen) |
| 10:16 |
rfrasur |
jeff_++ # thanks |
| 10:16 |
jeff_ |
If you have a high number of bibs with an incorrect MARC type, and if you have circ policies based on MARC type and not something like circ modifier, then the copy-level circulate as type override is useful. |
| 10:17 |
rfrasur |
hmm, our circ policies are based on circ modifiers |
| 10:17 |
rfrasur |
meh |
| 10:17 |
jeff_ |
But those incorrect bibs should still be fixed -- because the copy-level override for circulate as type will do nothing to fix the other issues caused by the incorrect MARC data -- mostly with searching and display in the catalog. |
| 10:17 |
dbs |
paxed's fixes in bug 1195334 looks like it's probably golden, but because we lack any sort of UI test automation to reproduce the problems before the patch and show that it's fixed after the patch, I'm reluctant to wade into applying & testing it myself |
| 10:17 |
pinesol_green |
Launchpad bug 1195334 in Evergreen "Some data URIs don't define character set" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1195334 |
| 10:18 |
dbs |
and without testing, I'm not going to commit anything. Which is a major part of our QA problem in a nutshell, methinks. (surprise, broken record, whatever) |
| 10:22 |
mrpeters |
is there any way to test a LONG (14 day) grace period without checking out an item and waiting 2 weeks? --- using in-db circ |
| 10:24 |
mrpeters |
i suppose i could check out an item for 1 day and see if it accrues fines over the weekend... |
| 10:26 |
bshum |
mrpeters: I haven't tried it recently, but I think you could edit the circulation entry to be in the past, like 10 days past due or whatnot. |
| 10:26 |
Dyrcona |
mrpeters: Check it out and change the due date to the past? |
| 10:26 |
bshum |
mrpeters: Through the DB |
| 10:27 |
mrpeters |
thats a thought |
| 10:27 |
bshum |
And then run the fine generator and see if it shows up. |
| 10:32 |
mrpeters |
thanks guys |
| 10:32 |
rfrasur |
(there is no way Breakfast Club is rated-R) |
| 10:33 |
dbs |
Such filth. |
| 10:33 |
rfrasur |
wha? It IS! |
| 10:34 |
* rfrasur |
is incredulous |
| 10:34 |
rfrasur |
on the upside, my cataloger isn't dumb |
| 10:34 |
* rfrasur |
is |
| 10:34 |
senator |
i say the mpaa is |
| 10:34 |
rfrasur |
senator++ |
| 10:37 |
* csharp |
recommends http://www.imdb.com/title/tt0493459/ |
| 10:38 |
rfrasur |
csharp: It's far too early in the morning to be blinded by that much backside, but I'll watch the movie later....much later |
| 10:38 |
csharp |
ha! |
| 10:38 |
* rfrasur |
drinks more coffee |
| 10:38 |
* rfrasur |
might have stayed up too late |
| 10:39 |
* csharp |
got sucked into Sopranos marathons this week, so knows how you feel |
| 10:40 |
* dbs |
finally got rolling on Mad Men, Season 1. Mr. Late-to-the-Party. In 2020 I'm looking forward to reading and then maybe watching Game of Thrones. |
| 10:41 |
rfrasur |
tv_marathons++ |
| 10:41 |
rfrasur |
next_morning-- |
| 10:43 |
Dyrcona |
But, it says right there, NC-17, so it is rated... ;) |
| 10:43 |
rfrasur |
hah! That movie, on Amazon, has the butt censored. |
| 10:44 |
rfrasur |
and is listed as Not Rated there...interesting |
| 10:45 |
Dyrcona |
The rating may come from the UK, since it is by the UK release date on IMDB. |
| 10:46 |
rfrasur |
yeah - the only streaming I've found is through YouTube - maybe on Netflix but we don't subscribe anymore. |
| 10:46 |
Dyrcona |
The whole film on Youtube? |
| 10:46 |
rfrasur |
in parts |
| 10:46 |
Dyrcona |
grr. |
| 10:46 |
rfrasur |
(which is terribly annoying) |
| 10:46 |
Dyrcona |
@hate parts |
| 10:46 |
pinesol_green |
Dyrcona: The operation succeeded. Dyrcona hates parts. |
| 10:46 |
Dyrcona |
:) |
| 10:46 |
bshum |
Heh, Dyrcona++ :) |
| 10:46 |
jeff |
our jacket for that DVD is also censored. looks like we're getting it from syndetics. |
| 10:46 |
rfrasur |
:D |
| 10:47 |
rfrasur |
there's not a copy in EG-IN (you're shocked, I'm sure) |
| 10:48 |
mrpeters |
which movie? |
| 10:48 |
* rfrasur |
considers buying it for the collection just for the contraryness of it all. |
| 10:48 |
rfrasur |
This Film Is Not Yet Rated |
| 10:48 |
Dyrcona |
Five of our libraries have it... Puts in a request. |
| 10:48 |
* rfrasur |
adds it to cart |
| 10:48 |
mrpeters |
hmm |
| 10:49 |
rfrasur |
reflexive collection development |
| 10:50 |
rfrasur |
csharp: you should get Amazon Affiliate money for that, right? |
| 10:56 |
jeff |
trivia: This Film is Not Yet Rated was the first NC-17 film at the Traverse City Film Festival |
| 10:59 |
jeff |
(in 2006) |
| 10:59 |
csharp |
jeff: interesting |
| 10:59 |
rfrasur |
huh - I dunno what to say/think about that other than...that's kinda cool (for adults....I think?) |
| 10:59 |
rfrasur |
okay, this is happening right now in EG |
| 11:00 |
rfrasur |
I'm selecting 20 records in the item status screen to do a batch edit on the volumes...and only 19 are showing up in the volume editor |
| 11:00 |
csharp |
does that usually work? |
| 11:01 |
rfrasur |
yeah, it's the first time I've had an issue |
| 11:01 |
jeff |
rfrasur: is it possible that there is a duplicate in the item status screen? |
| 11:01 |
rfrasur |
hmm...mayyyyyyybe |
| 11:01 |
Dyrcona |
rfrasur: could be two on the same volume? |
| 11:01 |
* rfrasur |
checks the obvious |
| 11:01 |
jeff |
rfrasur: i would imagine if you scan one item twice, then a second item, and select all three "lines" in item status, that you will only be editing two copies. |
| 11:02 |
Dyrcona |
Doesn't item status also get duplicates if you edit a copy from there? |
| 11:02 |
rfrasur |
jeff: I uploaded barcodes straight out of report output... |
| 11:02 |
Dyrcona |
Or something that changes it? |
| 11:02 |
rfrasur |
there are two copies of the same volume |
| 11:02 |
* rfrasur |
found it |
| 11:02 |
jeff |
Dyrcona: correct. there's a reload triggered when you edit something in the list. |
| 11:03 |
jeff |
rfrasur: ah, good! |
| 11:03 |
rfrasur |
thanks all |
| 11:05 |
rfrasur |
(it doesn't reload though if you only edit the volume...which would be kinda nice) |
| 11:08 |
bshum |
rfrasur: That sounds like something we had developed for 2.4 |
| 11:08 |
bshum |
commit 626df868, I think |
| 11:08 |
pinesol_green |
[evergreen|Jason Etheridge] lp1092644 refresh row with Item Status Edit Volume - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=626df86> |
| 11:08 |
* rfrasur |
gets more and more excited to upgrade to 2.4 |
| 11:09 |
rfrasur |
not that 2.2 is bad...but new stuff is fun...and handy...and shiny |
| 11:13 |
|
zerick joined #evergreen |
| 11:14 |
mrpeters |
is there a way to pull the LAST circulation date of an item in a report? |
| 11:15 |
mrpeters |
i've tried using Checkout Date/Time MAX but the data doesn't sync up with what the database says is the last checkout |
| 11:15 |
csharp |
mrpeters: you could try circ ID max |
| 11:15 |
mrpeters |
csharp: that seems to break the count of circs though |
| 11:15 |
csharp |
hmm |
| 11:15 |
rfrasur |
circs and checkouts aren't the same... |
| 11:16 |
rfrasur |
are you really wanting circs? or checkouts? |
| 11:16 |
mrpeters |
or are you saying a filter on max circd id |
| 11:16 |
csharp |
mrpeters: yeah, that |
| 11:16 |
mrpeters |
rfrasur: i dont understand the question |
| 11:17 |
rfrasur |
the way that circs seems to be calculated in the system includes renewals and maybe some other things...status changes |
| 11:17 |
mrpeters |
csharp: can't do that...no operator for max |
| 11:17 |
csharp |
bleh |
| 11:17 |
mrpeters |
yeah, we want that stuff |
| 11:17 |
csharp |
@karma reports |
| 11:17 |
pinesol_green |
csharp: Karma for "reports" has been increased 0 times and decreased 3 times for a total karma of -3. |
| 11:17 |
rfrasur |
okay |
| 11:17 |
csharp |
reports-- |
| 11:17 |
mrpeters |
its a weeding report, we're looking for inactive stuff |
| 11:17 |
mrpeters |
39068000030835 JF WINTHRO c.2 the castle in the attic winthrop, elizabeth Juv. Fiction Default 1999-05-21 01:00:00-05 2007-12-22 11:39:00-06 7 6/18/2011 |
| 11:18 |
mrpeters |
EG report says 2007 is last checkout, the staff client says 2011 is the last |
| 11:18 |
rfrasur |
is this in Indiana? |
| 11:18 |
mrpeters |
nope |
| 11:18 |
mrpeters |
i can't work on indiana until November 1 |
| 11:18 |
rfrasur |
lol, okay...and I can't look at it in the staff client |
| 11:19 |
rfrasur |
can you take a screen shot? |
| 11:19 |
mrpeters |
of the report? |
| 11:20 |
rfrasur |
of what you're looking at that has that info you pasted |
| 11:20 |
mrpeters |
well, thats just a spot check of 20 items the library did to compare against the reports data |
| 11:20 |
mrpeters |
now my winders vm is locked up |
| 11:21 |
rfrasur |
okay...well...fwiw, I wouldn't go by the last circ date. I'd go by the last check out date |
| 11:21 |
jeff_ |
mrpeters: perhaps you are joining a table in your report which is restricting the circs in scope for the report. |
| 11:22 |
mrpeters |
thats what im using, ruth, max check out date |
| 11:22 |
mrpeters |
jeff: maybe, i'll post sql |
| 11:22 |
jeff_ |
also, be aware that max on circ id operates on assumptions which can be bent/broken by migrations. |
| 11:23 |
mrpeters |
yeah...i have some fear about migrated data playing a part in this |
| 11:23 |
jeff_ |
mrpeters: you pasted a line of ourput -- what are the fields? |
| 11:23 |
mrpeters |
Barcode Call Number Label Title Proper (normalized) Author (normalized) Copy Location Name Circ Modifier Creation Date/Time Check Out Date/Time Count of Circs Actual Last CKO |
| 11:23 |
jeff_ |
barcode, call number, title, author, location... ah. |
| 11:24 |
rfrasur |
the last field is your own input? after checking item status or a generated result? |
| 11:24 |
mrpeters |
yeah |
| 11:24 |
jeff_ |
mrpeters: what criteria are you filtering on? are there any sources in use which are not being used in the output? |
| 11:25 |
mrpeters |
im going to paste the debug output....1 sec |
| 11:25 |
jeff_ |
k. |
| 11:25 |
jeff_ |
i forget that reports have debug output now. :-) |
| 11:25 |
mrpeters |
ya itsnice |
| 11:26 |
* rfrasur |
is running a test report (obviously not the same one...but similar) |
| 11:26 |
rfrasur |
so...in a couple hours.... |
| 11:28 |
mrpeters |
http://pastie.org/private/af01zwkuj3hikoucyobttg |
| 11:30 |
rfrasur |
(is it just me or are Indiana reports taking longer and longer and longer to generate?) |
| 11:33 |
mrpeters |
big database.... |
| 11:33 |
rfrasur |
yeah, I know |
| 11:35 |
rfrasur |
I thought doing just a small part of the collection would make it run faster though. |
| 11:35 |
* rfrasur |
was mistaken |
| 11:36 |
rfrasur |
That's a good book, btw |
| 11:37 |
jeff_ |
mrpeters: odd. nothing jumps out at me with regard to that report. can you get the circ ID of the most recent circ shown in the staff client, the 2011-06-18 date? |
| 11:37 |
mrpeters |
15620022 is the proper last circ |
| 11:37 |
jeff_ |
mrpeters: i wonder if that circ is special, such as it's aged, or it's an in-library use, etc. |
| 11:37 |
mrpeters |
50636 is what shows up |
| 11:38 |
|
acoomes joined #evergreen |
| 11:38 |
mrpeters |
they all look like normal circs.....except the "migrated" ones have no due date |
| 11:39 |
mrpeters |
http://imageshack.us/a/img838/5477/auvn.png |
| 11:39 |
|
collum joined #evergreen |
| 11:39 |
jeff_ |
mrpeters: er, that contains patron data. |
| 11:39 |
jeff_ |
unless those are test users. |
| 11:40 |
mrpeters |
yeah, guess i better obscure that |
| 11:40 |
mrpeters |
image deleted |
| 11:41 |
mrpeters |
http://imageshack.us/a/img834/102/hj51.png |
| 11:41 |
jeff_ |
and for that copy, what does your report show? |
| 11:42 |
jeff_ |
(it seems to be a different copy than that you pasted output for before) |
| 11:43 |
mrpeters |
hmmmm |
| 11:43 |
mrpeters |
i just ran the report again and the dates match up |
| 11:43 |
mrpeters |
all i did was add a deleted filter |
| 11:44 |
rfrasur |
GitM |
| 11:46 |
* mrpeters |
goes back to customer to see if its better now |
| 11:46 |
mrpeters |
spot check of 5 items and the data matches |
| 11:46 |
rfrasur |
mrpeters++ |
| 11:47 |
rfrasur |
deleted_filter++ # one of my favorites |
| 11:52 |
jeff_ |
mrpeters: your generated sql was after you added the deleted filter, correct? |
| 11:52 |
mrpeters |
ya |
| 11:52 |
jeff_ |
mrpeters: do you have generated sql from before that change? |
| 11:53 |
mrpeters |
im not sure |
| 11:54 |
mrpeters |
http://pastie.org/8091667 |
| 11:55 |
|
jdouma joined #evergreen |
| 12:06 |
jeff_ |
mrpeters: that paste has a date filter on xact_start of <= '2008-06-26' -- which explains why your report output line way back above had a most recent circ of 2007-12-22 while the staff client showed the 2011-06-18. |
| 12:06 |
jeff_ |
and i think that solves the mystery. |
| 12:06 |
rfrasur |
jeff_++ |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:14 |
Dyrcona |
@later tell mcooper Did your computer blow up using the xpath program on that 4GB file of MARC records? |
| 12:14 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 12:31 |
|
mcooper joined #evergreen |
| 12:33 |
|
jdouma_ joined #evergreen |
| 12:43 |
|
ericar joined #evergreen |
| 12:51 |
|
ldwhalen joined #evergreen |
| 12:51 |
|
mcooper joined #evergreen |
| 13:14 |
|
stevenyvr2 joined #evergreen |
| 13:27 |
jeff_ |
has anyone here successfully configured a single launchpad account to send bug email to two email addresses, short of using one address that re-sends/forwards? |
| 13:28 |
Dyrcona |
jeff_: I can say that I have not even tried. |
| 13:29 |
Dyrcona |
I have two emails associated with my launchpad account, but mail only goes to one, and that's what I want. |
| 13:29 |
* jeff_ |
nods |
| 13:29 |
jeff_ |
it seems like an insane thing to want -- MORE bug mail |
| 13:29 |
rfrasur |
is there a reason you don't want to re-send/forward? |
| 13:30 |
rfrasur |
are they both your email accounts? |
| 13:31 |
Dyrcona |
jeff_: It seems reasonable to me. |
| 13:32 |
|
stevenyvr2 joined #evergreen |
| 13:42 |
jeff_ |
rfrasur: both mine, yes. a work account and a personal account. |
| 13:43 |
rfrasur |
I have all my stuff shoveled into one inbox...but we also use Google mail for work...so don't have to deal w/ locally hosted server or any of that. |
| 13:44 |
Dyrcona |
I use IMAP and configure multiple accounts in Thunderbird. |
| 13:44 |
Dyrcona |
I have 4 accounts on this laptop. |
| 13:45 |
* rfrasur |
does like Thunderbird |
| 13:45 |
rfrasur |
but I don't use it anymore |
| 13:46 |
rfrasur |
I'd like to note that, for all the complaining I do about my staff, they're flippin' awesome in almost every way. |
| 13:48 |
rfrasur |
and Whoppers (as long as they're not stale) are yummy |
| 13:52 |
rfrasur |
(I wonder if I can find money to send two of them - not the Whoppers - to GenCon) |
| 13:55 |
Dyrcona |
GenCon, really? I'd like to justify that in my budget.... ;) |
| 13:57 |
rfrasur |
well...we have two legit gamers (not just video gamers...not that there's anything wrong with that), and I told the staff yesterday that I'm going to purposefully drop the ball as far as programming (events) so that they'll pick it up (for a variety of reasons) and so several of the things they came up with had to do w/ gaming and fan culture |
| 13:57 |
rfrasur |
and it's not far away...and...I don't want to go |
| 13:57 |
* rfrasur |
is def not THAT cool |
| 13:58 |
bshum |
jeff_: I have multiple accounts to LP but only get notifications to one as well. I don't think it sends to more than one. |
| 13:58 |
bshum |
Since you're cool and have gapps though, you could probably setup a filter to find LP emails and forward them on and only those. |
| 14:05 |
hopkinsju |
jeffdavis: I added CASCADE to the upgrade script and it completed successfully. It took quite a while but I'm finally done upgrading this test DB to 2.4. OPAC searching is being weird though... |
| 14:05 |
hopkinsju |
Searching takes forever and so far I'm seeing queries that should return results not returning any results on the first try, but oddly returning them on the second attempt. |
| 14:05 |
rfrasur |
Hah! One of those two staff members is already GOING to GenCon (no money from lib needed) |
| 14:06 |
hopkinsju |
I need to have a better way to test that the db upgrades *really* worked well. |
| 14:07 |
bshum |
hopkinsju: Returning on the second attempt sounds like the query ran long and didn't finish till later. And it being cached. |
| 14:07 |
hopkinsju |
bshum: Makes sense |
| 14:07 |
Dyrcona |
hopkinsju: You probably have to reingest. |
| 14:07 |
hopkinsju |
Dyrcona: ╯°□°）╯︵ ┻━┻ |
| 14:07 |
Dyrcona |
???? |
| 14:07 |
* hopkinsju |
flips a table out of frustration |
| 14:08 |
|
mcooper joined #evergreen |
| 14:08 |
hopkinsju |
That's gonna take ages. |
| 14:08 |
bshum |
Dyrcona: hopkinsju: reingest would have been one of the last steps required as part of the upgrade to 2.4. |
| 14:08 |
bshum |
I think. |
| 14:08 |
bshum |
Or maybe it's just a partial reingest... hmm, don't remember now. |
| 14:08 |
hopkinsju |
Is it taken care of in the supplimental? |
| 14:09 |
bshum |
hopkinsju: That's something for the indexes I think. |
| 14:09 |
bshum |
No, I was wrong, no reingests. |
| 14:09 |
csharp |
hopkinsju: if you're getting spotty results, and not just slow results, you might have to reingest |
| 14:10 |
csharp |
I would suspect a cold cache |
| 14:10 |
bshum |
That's kind of what I was leaning towards, heating up the database, or perhaps lack of server resources/tuning |
| 14:10 |
* dbs |
had to reingest, but that was due to the 2.3 -> 2.4.0 -> 2.4.1 fun |
| 14:10 |
csharp |
spotty = results page says 1 of 10 but 3 are showing, etc |
| 14:11 |
bshum |
dbs: I'm looking forward to that fun. (NOT) |
| 14:11 |
hopkinsju |
csharp: cold cache was my thought too, but I do this all the time and I've never seen anything other than the very first search after restarting to take very long. |
| 14:11 |
|
bkuhn joined #evergreen |
| 14:11 |
hopkinsju |
I'll keep experimenting. |
| 14:11 |
csharp |
hopkinsju: anything in the logs? |
| 14:11 |
dbs |
hopkinsju: do you have GIN indexes on your metabib.title_field_entry tables? |
| 14:11 |
csharp |
hopkinsju: also have you done a vacuum analyze on the db? |
| 14:11 |
csharp |
specifically the metabib tables? |
| 14:12 |
hopkinsju |
csharp: Nothing in the logs, no errors anyway. Nothing looks suspicious in general. |
| 14:12 |
hopkinsju |
dbs: GIN indexes? |
| 14:12 |
csharp |
might need a good vacuum if you haven't already |
| 14:12 |
hopkinsju |
csharp: I didn't think I'd need to vacuum analyze what with autovacuum and all. |
| 14:12 |
hopkinsju |
Ok, I'll do that. |
| 14:13 |
csharp |
hopkinsju: yeah - anytime you do massive table updates you need to manually invoke vacuum analyze |
| 14:13 |
bshum |
autovacuum might not cut if depending on the size of your data tables. |
| 14:13 |
hopkinsju |
I suppose postgres might not have taken into account all these changes. |
| 14:13 |
csharp |
autovacuum is fine for normal use |
| 14:13 |
bshum |
Or might get called off. |
| 14:13 |
hopkinsju |
Since the rows didn't really change |
| 14:14 |
bshum |
dbs: GIN indexes would be scary there. |
| 14:14 |
bshum |
Or at least.. unexpected right? |
| 14:14 |
* bshum |
goes to remind himself which is which again... |
| 14:15 |
* csharp |
cracks open another bottle of GIN |
| 14:15 |
bshum |
Oh, okay, I got those backwards :( |
| 14:15 |
Dyrcona |
Don't let the Djinn out of the bottle..... |
| 14:16 |
hopkinsju |
Maybe I'm just paranoid, but I'm concerned that the heavy hand I used to get the 2.3-2.4.0 upgrade script to run had unintended consequences. |
| 14:16 |
* hopkinsju |
crosses fingers and waits for the vacuum analyze |
| 14:18 |
dbs |
bshum: nosir, GIN all the way |
| 14:18 |
bshum |
dbs: I checked and we're still using GiST in ours. |
| 14:18 |
* dbs |
was wondering if, maybe, the DROP CASCADE dropped the indexes |
| 14:19 |
Dyrcona |
The supplemental script is supposed to take care of that, I think. |
| 14:19 |
Dyrcona |
It spends a lot of time rebuilding indexes. |
| 14:19 |
* dbs |
probably also would have just ANALYZEd the tables individually to begin with, to get the stats sorted |
| 14:20 |
dbs |
specifically, ANALYZE metabib.*_field one by one as the most critical beasties :) |
| 14:21 |
bshum |
Dyrcona: The create INDEX for the metabib stuff happens in the main upgrade SQL. |
| 14:21 |
bshum |
The indexes in the supplemental are different ones. |
| 14:22 |
dbs |
huh, I'm surprised to see that GIST is still the default in the evergreen scripts... |
| 14:23 |
bshum |
:) |
| 14:23 |
dbs |
hopkinsju: do you have an index of type gist or gin showing up if you run "\d metabib.title_field_entry" ? |
| 14:23 |
dbs |
"metabib_title_field_entry_index_vector_idx" gist (index_vector) -- or the like |
| 14:24 |
Dyrcona |
bshum: Ah... I think we're passed that one in production, so it is all a vague memory now. |
| 14:24 |
* Dyrcona |
curses his fingers, again. |
| 14:25 |
Dyrcona |
past.. passed.... psst.... |
| 14:25 |
bshum |
Dyrcona: Oh yes, we're way past that too. |
| 14:25 |
hopkinsju |
"metabib_title_field_entry_index_vector_idx" gist (index_vector) |
| 14:25 |
* dbs |
looks with surprise at production which is back to being GIST. huh, missed that during the upgrade I guess. Oh well... |
| 14:26 |
dbs |
hopkinsju: okay, that's good :) |
| 14:26 |
hopkinsju |
dbs: I'm glad |
| 14:26 |
Dyrcona |
out indexes are gist or btree. |
| 14:26 |
bshum |
dbs: Oops. Yeah, the version-upgrade script probably applied them back as GIST. Though now I'm curious to see what you've got in mind to change those to GIN (though if I recall doesn't that take more space?) |
| 14:26 |
dbs |
We were running GIN instead of GIST, before the upgrade |
| 14:27 |
dbs |
GIN takes more space, more time to build, but is faster |
| 14:27 |
bshum |
faster++ |
| 14:27 |
* csharp |
peruses http://www.postgresql.org/docs/9.1/static/textsearch-indexes.html |
| 14:27 |
jeffdavis |
metabib_title_field_entry_index_vector_idx is a GIN index on our upgraded 2.4 test db |
| 14:27 |
dbs |
and will be required if oleg / alex gets their super-fast text search patches in |
| 14:27 |
rfrasur |
faster++ |
| 14:27 |
* Dyrcona |
has had some recent experience with faster in a different context. |
| 14:28 |
bshum |
dbs: Ah okay, it's slowly wading back to me; PGCon feels like it was forever ago already :( |
| 14:28 |
dbs |
jeffdavis: you probably took more care than we did :) |
| 14:28 |
jeffdavis |
heh |
| 14:28 |
jeffdavis |
I don't think so, at least in this case ;) |
| 14:28 |
Dyrcona |
rfrasur: While you're dishing out money for conferences, can you send me to PGCon next year? |
| 14:28 |
dbs |
We were just happy to get to the other side with "it works! (mostly, with a crazy amount of warnings and apostrophe weirdness...)" |
| 14:28 |
dbs |
PGCon++ |
| 14:29 |
rfrasur |
Dyrcona: If I find money that I can just dish out willy nilly (yeah...I said "willy nilly"), I'll dish some in your direction |
| 14:29 |
jeffdavis |
I guess my point being, I am not aware of anything in the version upgrade scripts that would change the index type, and it didn't change ours |
| 14:29 |
rfrasur |
I'd recommend against you holding your breath until that time. |
| 14:29 |
Dyrcona |
:) |
| 14:29 |
Dyrcona |
We're talking about 0788, right? |
| 14:30 |
* Dyrcona |
runs off to look at the script again. |
| 14:30 |
rfrasur |
hmm, unless you've learned the elusive art of anaerobice respiration...which would be cool and creepy |
| 14:30 |
rfrasur |
s/anaerobice/anaerobic |
| 14:31 |
Dyrcona |
Nope, strictly aerobic here. |
| 14:31 |
rfrasur |
k - still cool...and not creepy |
| 14:34 |
jeffdavis |
hmm |
| 14:34 |
jeffdavis |
there are some GIST indexes being created on metabib.combined_*_field_entry tables though |
| 14:35 |
jeffdavis |
in 0757 |
| 14:36 |
jeffdavis |
those should probably be GIN instead, no? |
| 14:43 |
* bshum |
looks forward to this weekend's downtime. |
| 14:44 |
bshum |
And nuking old auditor data from the tables, whee! |
| 14:44 |
rfrasur |
bshum: Aren't you on vacation? |
| 14:44 |
bshum |
rfrasur: I might have July 4th off this year instead of doing an upgrade. So that's a plus? |
| 14:45 |
rfrasur |
lol...I suspect that is a plus |
| 14:45 |
bshum |
In 2011 I don't think I had any holidays where I wasn't doing an upgrade or fixing a server during the break. |
| 14:45 |
bshum |
Or maybe that was 2012. |
| 14:46 |
bshum |
The years go fast :( |
| 14:46 |
rfrasur |
that's crazy talk |
| 14:49 |
Dyrcona |
When I take vacation, I go where there is no phone or Internet.... |
| 14:50 |
rfrasur |
depends on the vacation...but I'm very good at ignoring things...like burning buildings...alien attacks... |
| 14:56 |
|
kbeswick joined #evergreen |
| 15:00 |
rfrasur |
I cannot wait until inventory is over and I can weed the collection w/in an inch of its life |
| 15:01 |
rfrasur |
err....use appropriate collection development/maintenance practices to deselect various items |
| 15:02 |
* Dyrcona |
suddenly remembers the first sentnce of Fahrenheit 451, and imagines rfrasur holding a lit match that is reflected in her eye. |
| 15:03 |
rfrasur |
well, I don't want them destroyed...I just want space to display the good stuff and get rid of the stuff that nobody gives a rip about |
| 15:04 |
* rfrasur |
is now imagining having to wear 60s clothes and having a rip-off flat screen tv with a poorly designed remote |
| 15:04 |
rfrasur |
but a firetruck w/ a mounted flamethrower COULD be cool. |
| 15:14 |
jeffdavis |
I'd like to redirect URLs like this to an equivalent in TPAC: http://catalogue.bclibraries.ca/opac/en-US/skin/BCD/xml/rresult.xml?ol=BCD&rt=list&rl=108287084&rl=107955774&rl=107955777&rl=108307959&rl=107949063 |
| 15:14 |
jeffdavis |
is there a way to pass a list of specific record IDs to the TPAC like this? |
| 15:15 |
bshum |
jeffdavis: I can't remember if the apache eg_vhost.conf in 2.4 has stuff for that already. Maybe it doesn't and still needs to add one for that scenario. |
| 15:15 |
bshum |
I know there was some redirect stuff added for JSPAC to TPAC |
| 15:16 |
jeffdavis |
there is some stuff in there, but URLs of that form aren't covered (or anyway don't work) |
| 15:17 |
rfrasur |
are permalinks included in 2.4? or 2.5? |
| 15:18 |
bshum |
rfrasur: I think that was just an idea kmlussier was working on with NOBLE or one of the other MassLNC consortia. |
| 15:18 |
bshum |
rfrasur: Not sure if it made its way into a pullrequest against 2.5. |
| 15:18 |
rfrasur |
okay |
| 15:19 |
rfrasur |
(oh the lovely sounds of the "I don't want to leave the library" temper tantrum) |
| 15:19 |
Dyrcona |
Sounds like my kid.... |
| 15:19 |
* Dyrcona |
was in the "Library Club" in fourth grade. |
| 15:19 |
rfrasur |
I'm of two minds - the mind that is very glad the kid loves being here...and the mind that really don't enjoy screaming children |
| 15:20 |
rfrasur |
my youngest was like that |
| 15:20 |
bshum |
jeffdavis: Come to think of it, I didn't know JSPAC could do lists that way :P |
| 15:21 |
jeffdavis |
yeah, I have no idea how the library got that URL |
| 15:21 |
rfrasur |
now he plays Minecraft...and watches YouTube and reads Pokemon forums and Minecrafta and some game that's the digital equivalent of Ninja...w/ spurting blood |
| 15:21 |
* rfrasur |
preferred the "Library Club" days |
| 15:21 |
hopkinsju |
Pfft. Vacuum analyze finishes and now my searches return 0 results every time. |
| 15:22 |
hopkinsju |
Super quick though... |
| 15:22 |
jeffdavis |
ha! |
| 15:22 |
hopkinsju |
¯\_(ツ)_/¯ |
| 15:22 |
bshum |
Quick to 0 sounds bad. I was hoping it was slow to 0. |
| 15:22 |
bshum |
Anything in the logs? |
| 15:23 |
hopkinsju |
Oh, yeah, there is now. Need to restart opensrf stuff. |
| 15:23 |
mcooper |
bshum: wait a minute, you're on vacation? i think i've found someone worse than me for not getting away from work =) |
| 15:26 |
bshum |
mcooper: I like chit-chatting with everyone in IRC. Maybe that means I do need to find non-community related hobbies :( |
| 15:26 |
bshum |
Maybe next cycle. |
| 15:26 |
bshum |
I do like traveling and visiting other libraries :D |
| 15:26 |
mcooper |
nah … =) |
| 15:28 |
hopkinsju |
Ok, now I'm back to taking forever to return 0 results on the first try but seeing results on subsequent re-queries. Any suggestions on an EXPLAIN query to see if it's even hitting on these indexes? |
| 15:34 |
rfrasur |
bshum: hah! I thought about taking a vacation to visit other libraries then wondered how vacationy that would actually be. Fun, but not relaxing. |
| 15:35 |
bshum |
rfrasur: I just do that in general now. Wherever I travel to, I try to find either the public library or other famous ones. And then the first thing I do is check their OPAC station to see which system they're on :D |
| 15:35 |
rfrasur |
lol, me too :D |
| 15:36 |
hopkinsju |
We always visit the libraries when we travel. It's always neat. |
| 15:36 |
rfrasur |
btw, just so y'all know...the library on Hilton Head Island uses Evergreen |
| 15:36 |
mcooper |
yup, and me -- I think it's one of those ingrained behaviors for library types |
| 15:36 |
rfrasur |
Beaufort County - I think it's part of SCLends |
| 15:36 |
bradl |
it is |
| 15:37 |
rfrasur |
Evergreen is in lots of nice places to live or visit :D |
| 15:37 |
rfrasur |
and Indiana |
| 15:40 |
|
rfrasur_ joined #evergreen |
| 15:41 |
bshum |
Okay, I can't really find any definitive answer yet via my googling (cause there's so many competing thoughts), but seriously px, pt or whichever for fonts? |
| 15:41 |
bshum |
For dbs and jboyer-isl since it came up in the thread. |
| 15:43 |
jboyer-isl |
I like pt, since it's based on an actual (outdated, unusual...) physical measurement that I'm familiar with. If I weren't from the US, I'd probably prefer mm. :) |
| 15:49 |
rfrasur_ |
(that tree just hit my car with a branch - how rude) |
| 15:49 |
bshum |
jboyer-isl: Hmm, guess I'll read up on that all. I know Meliss and I have been confused on which direction that needs to be from time to time. For not just fonts but margins, etc. |
| 15:49 |
Dyrcona |
bshum: Looking through my css files, I seem to us pt for font-size and px for nearly everything else. |
| 15:50 |
Dyrcona |
pt = point = 1/72 of an inch |
| 15:50 |
jboyer-isl |
Margins aren't quite as vital, sometimes you really do just want to nudge a box by 2px, but a 10px font on a tiny screen is a tiny crime. |
| 15:51 |
rfrasur_ |
fwiw - pt is pretty important for font because it's scalable w/ screen resolution |
| 15:55 |
jboyer-isl |
rfrasur: to be fair, just about everything other than px will scale ok, but some of them are just unusual. Picas? Get out of here. |
| 15:57 |
Dyrcona |
jboyer-isl: Seriously? 1/72 of an inch is cool with you, but 1/6 isn't? ;) |
| 15:57 |
Dyrcona |
bshum: just use mm for everything. It's the logical way. |
| 15:57 |
bshum |
Now I regret asking the question :D |
| 15:57 |
rfrasur |
jboyer-isl: truth...was just saying that px won't |
| 15:58 |
jboyer-isl |
You can't choose your muse! |
| 15:58 |
rfrasur |
lol |
| 15:58 |
rfrasur |
(did Google try to encourage the use of picas?....I'll google it to find out) |
| 15:59 |
rfrasur |
(that answered nothing and I don't care less than I didn't care before) |
| 16:00 |
* Dyrcona |
measures distance in furlongs, time in fortnights, volume in hogs heads.... |
| 16:03 |
|
ktomita joined #evergreen |
| 16:04 |
rfrasur |
hogs heads...interesting. wouldn't you have to puree them to get a good standard? |
| 16:09 |
* bshum |
ponders how safe it is to make a copy of m_* migration schemas and then drop them from production DBs. |
| 16:09 |
rfrasur |
you live dangerously, remember? |
| 16:10 |
* rfrasur |
does payroll and prepares to be entertained by bshum living dangerously. |
| 16:10 |
bshum |
rfrasur: You've got a point. And hey that's what test databases are for right? :D |
| 16:11 |
rfrasur |
bshum: that's exactly right. |
| 16:11 |
* rfrasur |
cues music https://www.youtube.com/watch?v=7nqcL0mjMjw |
| 16:13 |
|
stevenyvr2 joined #evergreen |
| 16:14 |
bshum |
Catchy. |
| 16:14 |
rfrasur |
old school |
| 16:14 |
rfrasur |
well, depending on how old a person is |
| 16:19 |
Dyrcona |
Edward Furlong! |
| 16:20 |
bshum |
'93, I guess I was living in CT then. |
| 16:21 |
rfrasur |
'93 was a good year |
| 16:22 |
* Dyrcona |
thinks..... |
| 16:23 |
bshum |
I was probably in the middle of skipping from 2nd to 3rd grade. |
| 16:23 |
Dyrcona |
'91-'92 was better for me. |
| 16:23 |
* rfrasur |
graduated from HS in '92 |
| 16:23 |
* Dyrcona |
feels old....graduated college in '93. |
| 16:23 |
* rfrasur |
was away to college in '93 |
| 16:24 |
rfrasur |
bshum was a whipper snapper |
| 16:24 |
rfrasur |
:D |
| 16:24 |
rfrasur |
Dyrcona - you ARE old, but isn't it fun? |
| 16:25 |
* rfrasur |
is a big fan of getting old. It beats the alternative. |
| 16:25 |
bshum |
In '92 then, I was in 1st grade, where I didn't know how to subtract. I thought the - was a typo and changed them all to + by putting a cross through them. I added the equations quite effectively after that though. |
| 16:26 |
* rfrasur |
laughs |
| 16:28 |
Dyrcona |
This about sums it up for me: https://www.youtube.com/watch?v=R3RPArL6SXk |
| 16:28 |
bshum |
Hehe |
| 16:29 |
rfrasur |
excellent |
| 16:30 |
rfrasur |
not for me though. I'm embracing the ugly and grumpy. :D |
| 16:33 |
Dyrcona |
Brad puts his music up for free download on his site, but I bought his first two CDs to support him. |
| 16:33 |
rfrasur |
It's good music...as in sounding |
| 16:34 |
rfrasur |
and fun...which is also good |
| 16:34 |
Dyrcona |
Yeah. |
| 16:35 |
Dyrcona |
He has a dark sense of humor that comes through in his songs. |
| 16:35 |
Dyrcona |
Oops, humour, forgot he's Canadian. ;) |
| 16:35 |
bshum |
Some day, I think we need to create more themes for our TPAC in honor of major holidays. |
| 16:37 |
rfrasur |
Dyrcona: I'm gonna to actually take more of a look at him later. And...well...I like dark humo[u]r (like pureed hogs heads...because it's funny to say) |
| 16:37 |
rfrasur |
(it might be dark because they're so far north) |
| 16:38 |
rfrasur |
(maybe) |
| 16:38 |
rfrasur |
(for half the year) |
| 16:38 |
Dyrcona |
I see he has finally put out his third album, well last November, anywya. |
| 16:38 |
Dyrcona |
something to download when I get home. |
| 16:39 |
rfrasur |
is his stuff on iTunes? (yes...Apple. I know and apologize.) |
| 16:39 |
|
Rogan joined #evergreen |
| 16:40 |
Dyrcona |
Dunno if he's on iTunes. You could buy CDs from Amazon. |
| 16:41 |
Dyrcona |
Or, you can buy at his website, or download there for free. Dunno how that works with iTunes. |
| 16:41 |
Dyrcona |
Dunno if Amazon still has CDs or not. |
| 16:41 |
rfrasur |
I don't like not paying anymore |
| 16:41 |
Dyrcona |
Oh, yeah. It is on iTunes.. Says so on his home page. |
| 16:42 |
* rfrasur |
ripped enough from Napster and Limewire and yeah...that it's time to start paying for stuff now. |
| 16:42 |
Dyrcona |
I like supporting stuff I like, so I understand. |
| 16:42 |
Dyrcona |
Never used Napster or Limewire. |
| 16:42 |
rfrasur |
Winsomething and Bearshare (which stunk) |
| 16:43 |
rfrasur |
WinMX? |
| 16:44 |
Dyrcona |
Ripping CDs mostly...I am old skool.... |
| 16:44 |
rfrasur |
well....that and then p2p. It was WinMX |
| 16:45 |
Dyrcona |
I use p2p to get Linux and *BSD distro images, that's about it. |
| 16:45 |
rfrasur |
apparently Napster came back to life but I haven't seen it for many years. |
| 16:45 |
Dyrcona |
I think AOL or MySpace tried to turn it into a pay service. |
| 16:45 |
rfrasur |
lol, because you were building stuff. I was just listening to music |
| 16:46 |
Dyrcona |
Jamendo.com is a good place to check out indy artists. |
| 16:46 |
Dyrcona |
I don't like a lot of the mainstream stuff. What I do like, I buy. |
| 16:47 |
rfrasur |
There are few things that I like anymore of the new things. Most of it's overdone/autotune junk/ripped off and not improved/boring |
| 16:48 |
rfrasur |
so, I'll look at jamendo when I get home. |
| 16:51 |
rfrasur |
well, I looked at it...but I'll actually listen to stuff |
| 17:06 |
|
kbeswick joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:08 |
senator |
@wunder glendale, az |
| 17:08 |
pinesol_green |
senator: The current temperature in S.E. Glendale, Arizona, Glendale, Arizona is 114.4°F (2:08 PM MST on June 28, 2013). Conditions: Partly Cloudy. Humidity: 5%. Dew Point: 26.6°F. Pressure: 29.78 in 1008 hPa (Falling). Excessive heat warning in effect from 10 am this morning to 8 PM MST Sunday... |
| 17:08 |
senator |
^-- no thanks |
| 17:12 |
rfrasur |
senator: are you there? |
| 17:13 |
senator |
no |
| 17:13 |
rfrasur |
that's good. blech. |
| 17:14 |
senator |
was just noticing heat wave news, and reflecting on my good fortune |
| 17:14 |
rfrasur |
indeed |
| 17:14 |
rfrasur |
I'm pretty happy w/ the midwest right now. Of course, I don't have allergies. |
| 17:14 |
rfrasur |
I think my husband would rather be in AZ |
| 17:15 |
senator |
i lived in ohio for a while, and everybody's idea of paradise there was arizona or new mexico. i didn't get it, but i guess it's a grass-is-greener thing |
| 17:19 |
rfrasur |
I like moody weather - far more interesting. Michigan (where I grew up) has better winters than Indiana but that's about it. |
| 17:22 |
rfrasur |
alrighty...time to go home |
| 17:30 |
Dyrcona |
Time for me to go. |
| 17:32 |
|
finnx left #evergreen |
| 17:42 |
|
mcooper joined #evergreen |
| 18:24 |
|
Rogan joined #evergreen |
| 18:25 |
|
ldwhalen joined #evergreen |
| 20:00 |
|
stevenyvr2 left #evergreen |
| 20:27 |
|
rfrasur joined #evergreen |
| 21:40 |
|
stevenyvr2 joined #evergreen |
| 21:41 |
|
stevenyvr2 left #evergreen |
| 22:07 |
|
ldwhalen_mobile joined #evergreen |
| 22:47 |
|
rfrasur joined #evergreen |
