| 10:13 |
dbs |
hmm. seeing the same problem as bhsum reported on ubuntu |
| 10:14 |
* dbs |
rattles the git tree to see what he can shake out of the branches |
| 10:30 |
bshum |
dbs: I think it has something to do with the scripts being referenced twice in the Makefile, but I'm not 100% sure yet. |
| 10:31 |
dbs |
eeevil: you see the "metabib.author_field_entry is getting 'name, name creator' additional entries" bug yet? |
| 10:31 |
dbs |
bshum: yep, I just pushed a fix |
| 10:31 |
dbs |
but testing it out on ubuntu and fedora with and without --prefix to be sure |
| 10:32 |
bshum |
dbs++ |
| 10:33 |
bshum |
I'll take a poke at it again later this evening. Gotta jet off for a bit. |
| 10:34 |
dbs |
and works, yay |
| 10:35 |
eeevil |
dbs: i doubt it. it's certainly a simple index def adjustment. is it causing problems for you, or just an annoyance? (afk for a while) |
| 10:35 |
dbs |
bshum++ # good jetting |
| 10:35 |
eeevil |
s/i doubt it/i have not/ |
| 10:36 |
dbs |
eeevil: it's an index bloat / inaccurate search thing - affects both 9.1 and 9.3, so yeah, index def adjustment |
| 10:36 |
dbs |
index bloat because you get approximately twice as many rows, inaccuracy because "creat*" |
| 10:42 |
dbs |
looks like we want to grab /name/namePart but not /name/role... fun fun |
| 10:43 |
dbs |
per http://laurentian-test.concat.ca/opac/extras/supercat/retrieve/mods32/record/1198543 and //mods32:mods/mods32:name[@type='personal' and mods32:role/mods32:roleTerm[text()='creator']] |
| 10:48 |
pastebot |
"bshum" at 64.57.241.14 pasted "show more details log error" (5 lines) at http://paste.evergreen-ils.org/15 |
| 10:48 |
* bshum |
fails at jetting |
| 10:48 |
dbs |
ah, sonofa |
| 11:10 |
bshum |
I see now |
| 11:10 |
bshum |
cd056eba75038c6a1fabd2a83ba97d81a444bc75 |
| 11:10 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables for result and record view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd056eb> |
| 11:11 |
bshum |
When I wrote that, what was really wrong was that record/copy_table.tt2 should never needed anything for the variables |
| 11:11 |
bshum |
We could nix it from there cause the copy_info is already set there. So my change did nothing to it. |
| 11:11 |
bshum |
Since copy isn't referenced |
| 11:11 |
bshum |
I think? |
| 11:12 |
bshum |
But when we flipped around the variable in results, it broke the display :\ |
| 11:12 |
* bshum |
fiddles around |
| 11:16 |
bshum |
dbs: Commit here seems to fix it on my test system: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/fix-copy-info-again |
| 11:16 |
bshum |
I think I've got it sorted out this time :( |
| 11:39 |
pinesol_green |
[evergreen|Dan Scott] Address some remaining hardcoded install prefixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa8ea3c> |
| 11:40 |
eeevil |
dbs: re creator, I think we'll want a search_xpath to do the same thing as facet_xpath and browse_xpath ... i've no time today, though. i'll toss it on my community day pile |
| 13:07 |
jl- |
good afternoon |
| 13:25 |
jl- |
just installed a fresh copy of evergreen on a VM |
| 13:25 |
jl- |
newest opensrf and eg |
| 13:33 |
jl- |
could someone help me import this record, possibly testing it with me http://paste.debian.net/80892/ I'm not sure if it needs to be cleansed of anything and what tools to use (I was advised not to use pg_loader before) |
| 13:53 |
dbs |
bshum: well that's hilarious! will look at it later |
| 13:55 |
dbs |
jl-: insert the <record>...</record> bit (strip off the <?xml ...><collection> bits) and you should be good to go |
| 13:56 |
dbs |
jl-: you can look at Open-ILS/tests/datasets/sql/bibs_concerto.sql for an example -- almost the only gotcha is to escape single quotes that might exist in the record |
| 13:57 |
* dbs |
out |
| 14:06 |
jl- |
dbs: I see the bibs_concerto, looks like my format -- insert, how? |
| 14:38 |
jl- |
evergreen=# \i /home/x/Desktop/test.sql |
| 14:38 |
jl- |
psql:/home/x/Desktop/test.sql:70: ERROR: relation "marcxml_import" does not exist |
| 14:38 |
jl- |
LINE 1: INSERT INTO marcxml_import (tag, marc) VALUES |
| 15:13 |
jl- |
do I need to create a table marcxml_import ? |
| 15:52 |
dbs |
jl-: Open-ILS/tests/datasets/sql/load_concerto.sql gives you all the steps for concerto stuff, but that includes authorities, call numbers, and copies |
| 15:52 |
dbs |
you could change the marcxml_import line to "INSERT INTO biblio.record_entry (marc, last_xact_id) |
| 15:52 |
dbs |
and things should work |
| 16:13 |
dbs |
bshum++ |
| 16:14 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables one last time for library_name_link purposes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=462a352> |
| 16:21 |
jl- |
brb |
| 16:25 |
jl- |
dbs: here's my test.sql http://paste.debian.net/80916/ |
| 16:26 |
jl- |
getting this error: evergreen=# \i /home/x/Desktop/test.sql |
| 16:26 |
jl- |
psql:/home/x/Desktop/test.sql:69: ERROR: |
| 16:26 |
jl- |
syntax error at line 1, column 0, byte 0 at /usr/lib/perl5/XML/Parser.pm line 187 |
| 16:26 |
jl- |
CONTEXT: PL/Perl function "maintain_901" |
| 16:39 |
jl- |
dbs: not sure if you typed anything since my last perl parse error |
| 16:40 |
jl- |
one question tho, in the concerto, there are no next line (like <br> in html) spaces |
| 16:40 |
jl- |
do I need to remove those from my record in the bibs_concerto.sql file? |
| 16:40 |
jl- |
the samples are all one single line |
| 16:40 |
jl- |
like a CSV |
| 16:50 |
|
zerick joined #evergreen |
| 16:55 |
jl- |
psql:assets_concerto.sql:99: ERROR: insert or update on table "monograph_part" violates foreign key constraint "monograph_part_record_fkey" |
| 16:55 |
jl- |
ETAIL: Key (record)=(84) is not present in table "record_entry". |
| 16:56 |
jl- |
:< |
| 17:14 |
jl- |
I did psql evergreen -f load_all.sql and it said it imported |
| 17:14 |
jl- |
how can I see it in the catalog? |
| 17:26 |
jl- |
ermahgerd |
| 17:26 |
jl- |
I'm seeing it |
| 17:26 |
jl- |
er mah gerd |
| 20:04 |
jl- |
I was able to import records with the load_all.sql initiating bib_concerta.sql, I can now search for certain authors and find them and their records |
| 20:04 |
jl- |
however, they don't show up under 'browse ALL' (next) |
| 20:05 |
jl- |
do I need to add certain meta data or do anything do build this index? |
| 20:21 |
|
sseng joined #evergreen |
| 20:21 |
|
ktomita joined #evergreen |
| 10:26 |
* Dyrcona |
wishes library vendors actually had a clue. |
| 10:26 |
jeff |
I get worked up about this when evaluating new services. Sometimes the interest fades, sometimes not. |
| 10:27 |
jeff |
But part of the idea too is that it would give me some perspective on Evergreen/Koha/etc from a "content provider" point of view also. |
| 10:28 |
dbs |
jeff: this would let us test improved core security too, like replacing unsalted MD5-hashed passwords |
| 10:29 |
jeff |
"here's an idea, let's not use a self checkout protocol with access to holds/circ/bills/more just to verify that you are a patron, and let's not require your library card number (which one?) and library password be entered on the vendor site, and let's not have the vendor store your library password in cleartext in their systems!" |
| 10:29 |
jeff |
dbs: yes, though i see that as a parallel, higher priority goal. :-) |
| 10:29 |
dbs |
jeff: so teaching Evergreen to be an OAuth2 provider? |
| 11:35 |
bshum |
And yay, Marque.pm whee! |
| 11:35 |
Dyrcona |
I'm target it for the beta now. I'll see if I can't finish it by the end of the week. |
| 11:36 |
Dyrcona |
Everything is going into working/dyrcona/lp1223903-MARC-export-Mk.2 from now on. |
| 11:37 |
jboyer-laptaupe |
bshum: Re: commit db7b99e8ccba2ebf81a345157de5a90ba5387626, is there anything else that may need changing for rel_2_5? We have a test system built from rel_2_5 pulled just after that commit went in, but auto-print still doesn't seem to stick on the checkout page with a fresh staff client. |
| 11:37 |
pinesol_green |
[evergreen|Ben Shum] Revert "Eliminate an annoying and useless warning in the JavaScript Console." - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7b99e> |
| 11:38 |
bshum |
jboyer-laptaupe: It's a server side change. |
| 11:38 |
bshum |
Not just a client one |
| 11:40 |
bshum |
The one that gets me is the chrome directory stuff I think |
| 11:44 |
Dyrcona |
Yeah, just changing the file on the server fixed it for me. |
| 11:45 |
Dyrcona |
bshum: We've got six inches of snow at my house and its still coming down. |
| 11:45 |
jboyer-laptaupe |
Well never mind that. Our test system isn't running the version of evergreen we wanted to test. :( |
| 11:45 |
jeff |
jboyer-laptaupe: oops. |
| 11:47 |
jboyer-laptaupe |
jeff: I'd actually feel better about it if it were my fault. :/ |
| 11:49 |
|
akilsdonk joined #evergreen |
| 15:12 |
|
stevenyvr joined #evergreen |
| 15:13 |
dbwells |
roses: depending on when 2.4 was released, there might not be a direct route from 2.3.7 to 2.4.0, so you may need to massage the early upgrade scripts until you are back on track. |
| 15:14 |
roses |
dbwells: I'm running the first script (.sql) and I'm having trouble with the password for evergreen - shouldn't it be evergreen because of #10 in the instructions? perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all \ --create-offline --database evergreen --host localhost --user evergreen --password evergreen |
| 15:15 |
dbwells |
roses: There is also at least one supplemental script for 2.4, so make sure you run that too, or at least understand what it does (sometimes scripts do something which gets done again later anyway, especially reingesting records). |
| 15:15 |
dbwells |
roses: Is this a test server? |
| 15:15 |
roses |
dbwells: Yes - a test server |
| 15:15 |
roses |
dbwells: Which I might just wipe and start with a fresh installation of 2.5 |
| 15:16 |
dbwells |
The password will be whatever you set it to when you set it up, your evergreen DB password. |
| 15:17 |
dbwells |
That is, if you ever login to the evergreen DB using 'psql', it will be the same username/password you use for that. |
| 15:19 |
dbwells |
It's might be nice to run through the upgrade scripts for general practice, understanding, and to test the scripts themselves, but unless you have a lot of data in your test server, installing fresh is probably easier. |
| 15:20 |
roses |
dbwells: Thanks. I found my password and now am going to run through the scripts. I might be back later. |
| 15:24 |
fparks |
I am working on a new rendition of Boolean Search https://bugs.launchpad.net/evergreen/+bug/1152863 |
| 15:24 |
pinesol_green |
Launchpad bug 1152863 in Evergreen "Support for traditional Boolean operators" (affected: 3, heat: 18) [Wishlist,Triaged] |
| 15:44 |
Dyrcona |
'course we only 56 SREs in our database, so more eyes might be good on that part. :) |
| 15:44 |
Dyrcona |
...only [have] 56.... |
| 15:47 |
|
roses joined #evergreen |
| 16:10 |
phasefx |
bshum: I tried looking at the commit log for that line re: non-cat in-house, and I think it was indeed oversight + intermediate testing |
| 16:12 |
phasefx |
for those curious (and I only just now learned how to do this), I did git blame in_house_use.js, got a useless commit message for some whitespace cleanup, but then did this to get the commit prior to that: git blame in_house_use.js b228af4f~1 |
| 16:12 |
pinesol_green |
[evergreen|phasefx] Change each tab to 4 spaces in the staff client javascript files. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b228af4> |
| 16:35 |
Dyrcona |
learning++ |
| 16:35 |
Dyrcona |
I learned a new git trick today. |
| 18:19 |
pinesol_green |
Launchpad bug 1155769 in Evergreen "Items repeated in tpac display, others not visible" (affected: 3, heat: 16) [Undecided,Confirmed] |
| 18:19 |
bshum |
Do you know how that bug is replicated? I've never been able to consistently get broken displays as described. |
| 18:19 |
Dyrcona |
dbs: git rebase -i / then edit the commit, reset HEAD^, add some files, commit, add the remaining files, commit, rebase --continue |
| 18:20 |
kmlussier |
I've seen it happen. You've got to find the right record to make it happen. |
| 18:20 |
kmlussier |
I was just about to test it and was first looking for a record. |
| 18:20 |
bshum |
And I'm not sure the change ktomita makes there to order by barcode instead of copy number would necessarily be good. Just for the folks who do use copy number in their cataloging. |
| 18:20 |
bshum |
Not us, for sure, but someone might? |
| 18:21 |
kmlussier |
Sounds like a good comment to make on the bug report. :) |
| 05:43 |
|
mtj_ joined #evergreen |
| 07:06 |
|
b_bonner joined #evergreen |
| 07:07 |
|
tfaile joined #evergreen |
| 07:11 |
csharp |
@later tell hbrennan you should ask your IT dept for a testing server that you can play with too |
| 07:11 |
pinesol_green |
csharp: The operation succeeded. |
| 07:25 |
|
timlaptop joined #evergreen |
| 07:40 |
|
kbeswick joined #evergreen |
| 09:09 |
jeff |
create three dirs /openils/var/web/opac/extras/ac/jacket/{small|medium|large}/r |
| 09:09 |
csharp |
StephenGWills: the lines beginning with \qecho will let you know what you need |
| 09:10 |
StephenGWills |
kk looking |
| 09:10 |
jeff |
place an .htaccess file in each dir (you might be able to do this at a common ancestor directory -- i've not tried) containing: "ForceType image/jpeg" |
| 09:11 |
jeff |
place a jpeg file named "12345" in the large/r/ medium/r/ and small/r/ directories |
| 09:11 |
jeff |
if you have multiple app servers without /openils/var/web/opac/extras/ac/jacket being shared storage between them all, you'll need to copy the images to each app server. |
| 09:11 |
jeff |
then, test. |
| 09:12 |
csharp |
so the ../r directory contains any custom jpegs that are named by the bib id number, correct? |
| 09:12 |
jeff |
right |
| 09:12 |
StephenGWills |
the bib in question does not have a 901$c, I'm feeling hopeful :) thanks Chris |
| 09:18 |
csharp |
wow |
| 09:18 |
csharp |
well, we're discussing sustainability at this point - we're pretty sure we can't handle an influx of local image requests at this point |
| 09:18 |
bshum |
jeff: I was thinking about custom images the other day as I looked at some random 856 lines. |
| 09:18 |
csharp |
but I still want to test it (and possibly script it) |
| 09:19 |
jeff |
yeah, we have an interface that staff use to upload jacket images. |
| 09:19 |
* csharp |
imagines a staff upload interface that would act like an "incoming" directory |
| 09:19 |
csharp |
heh |
| 12:51 |
jeff |
but the "can i do this with a function returning SETOF in this circumstance" seemed useful to determine an answer to, for future. |
| 12:52 |
tsbere |
jeff: Well, I can give you "the first alert in the list" easily. "All alerts in the list" is harder. |
| 12:52 |
jeff |
i'll take that for starters. |
| 12:53 |
* tsbere |
could be wrong on the "all" front now that he ran a test |
| 12:54 |
tsbere |
jeff: Add this to the end of your SELECT DISTINCT line: , (actor.address_alert_matches(au.home_ou, aaua.street1, aaua.street2, aaua.city, aaua.county, aaua.state, aaua.country, aaua.post_code, aaua.mailing, aaua.billing))).alert_message |
| 12:54 |
jeff |
ah, see i was trying to think of how to do it with a subselect -- suddenly, easier! |
| 12:56 |
tsbere |
I might have an extra ) in there |
| 12:56 |
tsbere |
<_< |
| 12:56 |
jeff |
you did, i'm pretty sure. |
| 12:56 |
* tsbere |
can't actually test this due to MVLC not *having* any such alerts defined right now |
| 12:57 |
jeff |
we recently started using them, and i'm trying to make them do double duty for reporting as well as the alerts in the user editor. |
| 12:58 |
jeff |
currently takes over a minute to run, but that's reasonable for this report. |
| 13:01 |
|
jeffdavis joined #evergreen |
| 13:18 |
csharp |
looks like closed dates are acting more like grace periods with the current behavior |
| 13:19 |
Dyrcona |
next breaks from the loop at that point and starts again at the top with the next iteration. |
| 13:21 |
dbwells |
csharp: I am pretty sure the code is meant to do what you want it to do. If I understand your situation correctly, for some reason, actor::org_unit::closed_date->search_where() isn't finding your closed dates. |
| 13:22 |
csharp |
dbwells: I can dig for this, but can you see a simple-ish way to test that hypothesis? |
| 13:22 |
Dyrcona |
I was about to say something along the lines of what dbwells just said. |
| 13:22 |
Dyrcona |
I needed more context. :) |
| 13:23 |
dbwells |
csharp: That function basically is a straight DB lookup (I think), so I'd start by looking in the DB and see if everything is in line there. |
| 16:41 |
eeevil |
Dyrcona: for your next trick, convince B&T a library might want to use all 35 bytes available to name itself in EIDFACT, not just 5. ;) |
| 16:42 |
eeevil |
see also: item identifiers |
| 16:45 |
|
roses joined #evergreen |
| 16:46 |
roses |
Several months ago (almost a year) I was working on setting up a test Evergreen server and someone here told me about where to find some fake/test records to import into my catalog? Where can I find something like that? |
| 16:50 |
bshum |
roses: If you're just setting up some sort of demo system, you can always use the stock concerto dataset that comes with Evergreen 2.4+ |
| 16:50 |
roses |
bshum: I installed 2.3.7 |
| 16:51 |
bshum |
That step gets described a bit in step 9.1 of the 2.5 README |
| 16:48 |
Dyrcona |
bshum: When you try to renew a lost item, after applying the above patch, you are supposed to get a dialog asking if you want to force action. |
| 16:48 |
Dyrcona |
Instead, I'm getting a FIX ME followed by another FIX ME. |
| 16:51 |
Dyrcona |
I was going to say that kmlussier and I both saw the force action dialog before, but I'm less certain of that, now. |
| 16:51 |
Dyrcona |
After looking through my email, I see she mentions getting it on a different test. |
| 16:52 |
Dyrcona |
I don't see her mentioning on testing renewal of a lost item, but I thought I had seen it. |
| 16:52 |
Dyrcona |
I now believe I was mistaken. |
| 16:52 |
bshum |
Renewing a lost item should generate some sort of stupid error I thought. |
| 16:52 |
Dyrcona |
The patch I pasted above gets rid of it. |
| 16:53 |
bshum |
or trying to |
| 16:53 |
|
zerick joined #evergreen |
| 16:53 |
Dyrcona |
Now, you get a different stupid error, but is should be a force action, instead. |
| 16:53 |
kmlussier |
I'm almost certain I saw it. I suppose it's possible I confused it with the other test, but I really thought I saw it. |
| 16:53 |
Dyrcona |
s/is/it/ |
| 16:53 |
Dyrcona |
kmlussier: I'm not saying we didn't see it. I'm just not certain at this point. |
| 16:54 |
kmlussier |
However, it is unusual for me not to mention seeing the override when I reported the bug. |
| 16:57 |
Dyrcona |
Well, it should mention three events: COPY_NOT_AVAILABLE, COPY_STATUS_LOST, PATRON_EXCEEDS_MAX_FINES. |
| 16:57 |
kmlussier |
Which is why I was so certain I saw it. Because I remember seeing it and thinking that I should pay the lost bill ahead of time to see if it changed the behavior. |
| 16:58 |
Dyrcona |
Those three should be overridable if the user has the .override permission. |
| 16:58 |
* kmlussier |
used to be more diligent about capturing screenshots during testing. :( |
| 16:58 |
Dyrcona |
I think I am just going to have to tinker with the renewal code until it works. |
| 16:59 |
bshum |
Well, at least back in 2011 when I had the original ticket in our helpdesk, they only mention the ACTION_CIRCULATION_NOT_FOUND error |
| 16:59 |
bshum |
Nothing about overrides |
| 16:59 |
kmlussier |
bshum: Yes, that's right. The overrides came with the code I'm testing. |
| 16:59 |
bshum |
Oh |
| 16:59 |
bshum |
Well then! |
| 16:59 |
bshum |
:) |
| 17:00 |
* bshum |
should just be quiet and let you guys do your thing |
| 17:01 |
Dyrcona |
bshum: You realize I've made a change to get past the ACTION_CIRCULATION_NOT_FOUND, right? |
| 17:01 |
* Dyrcona |
points at paste 10 above. |
| 17:02 |
bshum |
Dyrcona: I hadn't gotten to the paste yet. I was trying to figure out what the "broken" behavior was before I applied a proposed fix to learn what else it breaks. |
| 17:02 |
bshum |
I was just going to try adding it to our master test server next. |
| 17:03 |
bshum |
Just refamiliarizing myself with what's going on. 2011/2012 seems like forever ago. |
| 17:03 |
Dyrcona |
ok |
| 17:10 |
bshum |
Well I got a network error as it tried to find the billing to deal with voiding the lost. But then yeah I got the two FIXMEs back to back after that. |
| 17:10 |
Dyrcona |
Thanks. |
| 13:29 |
tsbere |
jeff: Yea. Though ensuring you don't hit max too soon might be an issue. |
| 13:30 |
tsbere |
not to mention overnight issues <_< |
| 13:31 |
Dyrcona |
jeff: Sound overly complicated. Are the exclusions based on some rarely changing property of the user, or is it arbitrary for each report? |
| 13:32 |
jeff |
Dyrcona: the idea is "don't count circs by test or otherwise not-real patrons". usually this is just done with an infrequently (never!) changing patron profile on the "patron" account. |
| 13:32 |
jeff |
but right now i'd like (for training and/or for testing-for-real) to have some patrons who are in other groups also be excluded, without excluding that entire group. |
| 13:33 |
jeff |
i don't want to edit every report to "also exclude these patrons" or "also exclude patrons with this attribute", hence the idea that "at this point, if i decide to do this, i want a view to help me" :-) |
| 13:34 |
jeff |
(a reporting view for sql reports, not necessarily a full-on view in the IDL and such. |
| 13:34 |
jeff |
) |
| 13:35 |
jeff |
but another option is to change a test user in the excluded group to a non-excluded group to test "can this user really check out only one chromebook and no other items at all", then return the user to the excluded group -- but that involves: |
| 13:35 |
jeff |
1) hope nobody runs a report that would be affected |
| 13:35 |
jeff |
2) don't forget to change the group back |
| 13:35 |
jeff |
sometimes i think i just worry too much about reporting on "not real" things. |
| 13:36 |
jeff |
other times i think "more test servers!" |
| 13:36 |
* jeff |
shrugs |
| 13:36 |
jeff |
i'm just babbling now |
| 13:37 |
tsbere |
jeff: Make a table of "don't report on these user ids", fill it however you want (perhaps with a DB function), then ensure that reports say "and the user id is not in that table" either directly or via a view? |
| 13:37 |
|
rfrasur joined #evergreen |
| 13:37 |
tsbere |
Would likely be faster than looking up stat cat or user pref entries, though you could do that to populate the table |
| 15:57 |
dbwells |
jtaylorats: Yes. At that point they will display in the OPAC and be editable in the client. If the records contain any kind of individual copy/volume level data, there is no code which will do anything special with that type of data. |
| 15:57 |
* Dyrcona |
decides to program in BrainFuck from now on. |
| 15:58 |
kmlussier |
Dyrcona++ bshum++ # Doing your part to contribute to Evergreen even if you are human and sometimes make mistakes. |
| 15:58 |
jtaylorats |
Thanks. That is the last piece. I've gotten the test migration done for the entire database. |
| 15:58 |
jboyer-isl |
Dyrcona, have you seen Whitespace? http://compsoc.dur.ac.uk/whitespace/ |
| 15:59 |
jtaylorats |
Now to wipe it out and put all the pieces together and do it again :-) |
| 15:59 |
jtaylorats |
Appreciate all the help. |
| 16:04 |
bshum |
jboyer-isl: Heh, well it's fixed for rel_2_5 now too. |
| 16:05 |
bshum |
Every time I think about being a "hero" I think of the movie Sky High. Where there's heros and sidekicks. |
| 16:05 |
bshum |
I always thought I was more of a sidekick. |
| 16:05 |
jboyer-isl |
Huzzah! Thanks. We were just about to cut off changes to a new test environment 10 mins ago :) |
| 16:05 |
jboyer-isl |
I haven't seen that one, but I vaguely remember when it came out. |
| 16:28 |
pinesol_green |
[opensrf|Bill Erickson] osrf_control router-de/re-register and reload commands - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=5b3f804> |
| 16:28 |
pinesol_green |
[opensrf|Galen Charlton] typo fix - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=0c0b02e> |
| 16:28 |
pinesol_green |
[opensrf|Galen Charlton] x - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=d90a415> |
| 16:56 |
* bshum |
watches it explode now |
| 16:57 |
pinesol_green |
[opensrf|Bill Erickson] LP#1066131: srfsh.py should not require opensrf.settings - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2fae356> |
| 16:59 |
gmcharlt |
bshum: while you're in the area, a look at 1155446 would be nice |
| 17:00 |
* bshum |
doesn't really want to test on Lucid |
| 17:00 |
bshum |
But I'll look at the rest of it. |
| 17:00 |
gmcharlt |
well, lucid is less relevant now than it was in March of last year |
| 17:01 |
gmcharlt |
I'll see how wheezy likes it |
| 17:01 |
bshum |
I'm checking precise right now. |
| 17:20 |
bshum |
gmcharlt: Looks okay to me on precise. |
| 17:20 |
bshum |
I'll sign off and push it |
| 17:20 |
gmcharlt |
thanks |
| 17:22 |
pinesol_green |
[opensrf|Galen Charlton] LP#1155446: add Debian/Ubuntu deps required for Python tests to pass - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=02a93da> |
| 17:25 |
* jeff |
waits patiently to see if collectionHQ extract will complete |
| 17:26 |
bshum |
egbuilder: status |
| 17:26 |
egbuilder |
evergreen-master-debian-6.00-x86_64: idle, last build 1h30m42s ago: build successful |
| 10:13 |
|
tsbere joined #evergreen |
| 10:14 |
eeevil |
there is that path, yes ;) |
| 10:31 |
|
mcooper joined #evergreen |
| 10:55 |
mceraso |
gmcharlt: I tested the candidate tarball for OpenSRF 2.2.2 using Ubuntu 12.04 LTS and it works well |
| 10:56 |
gmcharlt |
mceraso++ # thanks for testing! |
| 10:56 |
|
mrpeters joined #evergreen |
| 10:56 |
mceraso |
Anytime :) |
| 10:57 |
|
mcooper joined #evergreen |
| 13:39 |
|
schatz joined #evergreen |
| 13:39 |
mrpeters |
we're going to be building out a new installation with 900TB of SSD for their DB's. Should be fun to see how it screams. |
| 13:39 |
mrpeters |
I know PINES has talked about going SSD as well. |
| 13:40 |
bshum |
900TB? Whoa? |
| 13:40 |
bshum |
:) |
| 13:41 |
bshum |
So far, I'm noticing significant gains in search response and hold placement via the catalog on my test server with SSD. |
| 13:41 |
bshum |
Like an example bib where hold placement took 24 seconds in production system took 6 seconds in that test laptop. |
| 13:43 |
* bshum |
should switch out to GIN indexes and see what happens.... |
| 13:44 |
eeevil |
oh, that reminds me. 9.4 looks like it's going to greatly improve GIN speed |
| 13:44 |
bshum |
Yay! :) |
| 13:44 |
* bshum |
loves postgres |
| 14:09 |
|
hbrennan joined #evergreen |
| 14:13 |
|
snowball joined #evergreen |
| 14:26 |
|
akilsdonk joined #evergreen |
| 14:33 |
bshum |
berick: I just setup the prototype code on one of our test servers, we're going to play around. Just curious about one thing though: |
| 14:33 |
bshum |
What might cause this to happen where it seems to get stuck a bit on the patron search and I can't seem to retrieve new result sets. |
| 14:34 |
bshum |
Logging out I could get back to it again and things seemed fine, but on my first go, it found a patron, then I opened their record, then couldn't search for anybody new. |
| 14:34 |
* bshum |
keeps playing around |
| 14:34 |
berick |
bshum: haven't seen that. i'd suggest checking the JS console for errors |
| 14:34 |
berick |
bshum++ # testing |
| 14:34 |
bshum |
berick: Yeah I thought of that after I'd left the client |
| 14:34 |
bshum |
I'll try to replicate it and check the console next time. |
| 14:35 |
bshum |
It's quite fun so far. |
| 15:40 |
sseng |
jeff: gmcharlt: alright, thanks! |
| 15:46 |
Dyrcona |
rfrasur: Turns out, one of our members is also doing a seed lending program. |
| 15:47 |
Dyrcona |
rfrasur: Groton Public Library (gpl.org), and they are reusing the card catalog shelves. :) |
| 16:06 |
sseng |
gmcharlt: can I confirm that from the memory leak test report, I perform the test in the same tab right? that is to say, I press F1, enter the patron barcode, checkout a book, and click "Done", and this represent one iteration? |
| 16:06 |
jeff |
Right now, if you have a standing penalty such as PATRON_EXCEEDS_FINES, you can configure what things that penalty blocks (CIRC, or CIRC|RENEW, etc), but you can't have that penalty block certain things for different groups of patrons. Does anyone else have interest in such functionality? |
| 16:07 |
gmcharlt |
sseng: yes |
| 16:07 |
jeff |
I'm trying to decide between a hack and a wishlist bug. :-) |
| 16:56 |
bshum |
Bah, and now it works again. Might just be some weird browser effect... |
| 16:56 |
bshum |
I'll play more tomorrow. |
| 16:57 |
berick |
bshum: holler when you do. Now that it's browser-based, I can poke too! (if you give me a login :) |
| 16:58 |
bshum |
berick: Unfortunately I rolled it in with my local SSD test server. Which is hidden behind too many layers to unveil. |
| 16:58 |
bshum |
But I'm going to work on installing it to our public demo system soon. |
| 17:00 |
berick |
ah |
| 17:02 |
bshum |
Just have to remind myself how to log into everything... too many passwords. |
| 17:02 |
berick |
feel free to type them in here if you need a backup |
| 17:03 |
bshum |
:) |
| 17:22 |
|
kimo_sabe joined #evergreen |
| 17:31 |
kimo_sabe |
I'm having an odd issue trying to do some testing on 2.5.2 but when I try and clone my production database over to dev to try the upgrade stuff goes missing. Anyone seen that before? I'm at a loss |
| 17:39 |
|
mmorgan left #evergreen |
| 18:10 |
dbwells |
kimo_sabe: There have been a few recent conversations about needing to set the search_path before using pg_restore. |
| 18:11 |
dbwells |
e.g. here: http://evergreen-ils.org/irc_logs/evergreen/2014-01/%23evergreen.22-Wed-2014.log at 12:54:55 |
| 17:41 |
|
dcook joined #evergreen |
| 18:44 |
|
Dyrcona joined #evergreen |
| 18:45 |
Dyrcona |
If renewal is mostly just a checkin and then checkout, why have all these extra checks just for renewing? |
| 18:46 |
Dyrcona |
We end up running those, then the checkin tests, and then essentially the same checks for the checkout. |
| 18:46 |
dcook |
I'm not an Evergreen person, but I imagine there are extra rules for renewing? |
| 18:47 |
dcook |
Like only being able to renew certain types of items, only renewing if there are no other holds, etc. |
| 18:48 |
Dyrcona |
dcook: I'm going through the circ code, and I am an "Evergreen person." |
| 18:48 |
Dyrcona |
There are slightly different checks for renewals, but virtually all of the tests get run again. |
| 18:49 |
dcook |
In that case, no idea, but sounds like a valid question :) |
| 18:49 |
Dyrcona |
I'm tempted to remove the database check for the status not being equal to 1 on a renewal. |
| 18:54 |
Dyrcona |
I also don't like how the same events come up three times in my log before we actually hit a bail statement. |
| 18:58 |
Dyrcona |
If I wish to introduce a permission-based check to override this, I have to add the checks for the permissions in all of the multiple places the checks occur. |
| 18:59 |
Dyrcona |
I also rather naively based the permissions on the stop fines values from action.circulation, so I'm now I'm slightly stumped at the approach to take with the status of the copy. |
| 19:00 |
Dyrcona |
Pardon me. This is mostly thinking "out loud" at this point. |
| 19:01 |
Dyrcona |
The other problem, is the renew (and checkout tests) return COPY_NOT_AVAILABLE regardless of the copy's status. |
| 19:01 |
hbrennan |
I'm "listening" to ya, Dyrcona. :) |
| 19:02 |
Dyrcona |
heh. |
| 19:02 |
Dyrcona |
That means I have to check the copy's status yet again rather than relying on the return code from the database check. |
| 19:22 |
Dyrcona |
In checkin, we push a COPY_STATUS_LOST, check bail_out (which hasn't been set), and then keep right on going. |
| 19:24 |
Dyrcona |
neato: We call checkin_handle_lost_or_lo_now_found twice in a row. I have to find out why. |
| 19:25 |
Dyrcona |
We get through checkin and push a SUCCESS event! So, we have 3 failures (this patron also owes too many fines, but I was ignoring that) and 1 success. |
| 19:26 |
Dyrcona |
Then, we do the indb circ tests again, but I don't think we've made it to checkout, yet. |
| 19:37 |
Dyrcona |
So, I should probably add a new function to be called from do_permit that checks for my particular conditions and permissions. |
| 19:39 |
Dyrcona |
Since this isn't a case of override permissions.... Err, wait.... |
| 19:40 |
* Dyrcona |
mulls the impact of override permissions. |
| 11:51 |
dbs |
yikes. |
| 11:51 |
ldwhalen |
eeevil: I think it leaves out all of the public. normalizers |
| 11:51 |
|
schatz joined #evergreen |
| 11:53 |
eeevil |
looks like it never did ... |
| 11:54 |
eeevil |
ldwhalen: that's purely an oversight, there's no reason to not add them (especially since we attempt to make use of them). I suspect a big fat me-- for not propagating testing env changes to the seed and upgrade scripts |
| 11:55 |
ldwhalen |
eeevil: If I add them is there anything in config.index_normalizer that needs a specific value other than config.index_normalizer.func? |
| 11:56 |
eeevil |
ldwhalen: depends on the function ... if it takes parameters /beyond/ the input text, the number of them must be recorded in param_count |
| 11:56 |
eeevil |
for that one, it's 0 |
| 15:39 |
jeff |
and much credit to berick and eeevil (and others?) for their help on that a few years ago. :-) |
| 15:39 |
jeff |
jboyer-isl: i'll be interested in what your eventual resolution is, if you care to follow up. |
| 15:41 |
* berick |
notes that w/ websockets (and no translator) we can remove the x-domain jabber requirement / brick cross-talk |
| 15:41 |
jboyer-isl |
I can smack it with a hammer whenever, it's just on our test instance. :) Thanks for the pointers, if I can get it going I'll be back to grouse/brag, heh. |
| 15:41 |
eeevil |
ldwhalen: the seed file should really just insert the proc name (no schema), no need to check pg_proc. see related ones for isbn and replace normalizers. the the upgrade file could check pg_proc to avoid double insertion, I suppose |
| 15:44 |
eeevil |
berick: or, at least not depend on it for staff client interaction ... still nice for simple HTTP clients with transactional requirements :) |
| 15:47 |
eeevil |
ldwhalen: or just check that it's not there already with a CTE, or blindly insert outside any explicit transaction |
| 15:49 |
ldwhalen |
eeevil: Is it worth while adding the param_count from pg_proc? |
| 15:50 |
eeevil |
you need the param_count when it's not 0. I'd suggest just setting it to what it should be. I wouldn't involve pg_proc at all. IMO, just look at the definition of the proc, count the params requested, and subtract 1 |
| 15:53 |
jboyer-isl |
jeff: route_subdomains was commented out on both test bricks, but setting it to s2s doesn't seem to have been the whole fix. I could/should check the other service machines, but these bricks should be talking straight to the db without too much bouncing around. |
| 15:58 |
eeevil |
jboyer-isl: can the other domains find each other via dns or /etc/hosts? (IOW, is ejabberd listening on all IPs, and are the foreign IPs named something they would recognized) |
| 16:01 |
tsbere |
jboyer-isl: I would also check for local firewalling - If the server(s) aren't allowing incoming traffic on the S2S port the rest of the proper config won't help....and are your different bricks using different ejabberd domains for that matter? |
| 16:03 |
jboyer-isl |
the machines appear to be able to find each other by name, I don't believe there's a firewall running (they're off on a private 10. network) and they are all using individual private.name.evergreen.lib.in.us and public.evergreen...., and localhost domains. |
| 16:14 |
eeevil |
berick: agreed ... I was really just thinking of xdr JS clients, though I don't know if that's strictly possible right now, and since only older MOZ supports multipart/mixed-replace, it's probably never going to be worth worrying about |
| 16:15 |
* dbs |
does a bit of a double-take at "Bill Erickson moved some example seed data out of the base install and into a sample data set." |
| 16:16 |
* eeevil |
goes to look more closely and make sure he didn't lie... |
| 16:17 |
dbs |
berick does _tons_ of stuff that deserves credit, and I certainly appreciate his testing & signing off |
| 16:17 |
eeevil |
I did lie. dbs, my apologies |
| 16:17 |
* eeevil |
updates |
| 16:21 |
dbs |
thanks eeevil |
| 11:52 |
berick |
that is a lot of OUS calls. just switching to the cstore / stored-proc variant would help a lot |
| 11:54 |
csharp |
I can see how this wouldn't have manifested itself in an instance with fewer Ous |
| 11:54 |
berick |
yeah |
| 11:57 |
csharp |
that gap looks like this on the test server (different hold): http://pastebin.com/YmC7pUNq |
| 11:58 |
csharp |
(between Processing hold blah... and when it starts checking OU settings |
| 11:58 |
csharp |
) |
| 12:00 |
berick |
huh, wonder which of those is taking so long on your prod servers. I take it the prod hold is on a popular record with lots of copies? |
| 12:04 |
csharp |
lemme look |
| 12:06 |
csharp |
227 total copies - 4 current holds |
| 12:07 |
csharp |
http://gapines.org/eg/opac/record/5606034 - "Calculated in Death" - apropos title ;-) |
| 12:07 |
berick |
heh |
| 12:08 |
csharp |
I'll place a hold on it in our test server and see what the log output is there |
| 12:10 |
tsbere |
I wonder if we have similar problems when records have a couple hundred copies. We appear to have less than 300 total records with >100 copies, actually... |
| 12:13 |
csharp |
whoa 22968 lines for that threadtrace |
| 12:13 |
csharp |
but it took 73 seconds to process |
| 12:13 |
tsbere |
Hmmm. 48% of our records have ONE copy. >_> |
| 12:34 |
senator |
csharp: if you're feeling saucy, on your test system, |
| 12:34 |
senator |
you might try working/collab/senator/slow-targeter-try-faster-settings-lookup |
| 12:34 |
* csharp |
is feeling saucy and SASSY |
| 12:34 |
senator |
that has two commits |
| 12:34 |
|
rsinger joined #evergreen |
| 12:51 |
sseng |
dbs: that's sounds like it, now curious to see where in eg code the barcode gets written to that subfield. |
| 12:52 |
sseng |
dbs: thanks a bunch for your help! |
| 12:52 |
|
smyers_ joined #evergreen |
| 12:54 |
csharp |
senator: I saw that speed up from 73 to 61 seconds on the test server after applying the patches and restarting opensrf |
| 12:54 |
csharp |
Method duration for [open-ils.storage.action.hold_request.copy_targeter]: 59.706 |
| 12:55 |
csharp |
Method duration for [open-ils.circ.holds.test_and_create.batch]: 61.294 |
| 12:55 |
csharp |
^^after |
| 12:55 |
csharp |
vv before |
| 12:55 |
csharp |
Method duration for [open-ils.circ.holds.test_and_create.batch]: 71.550 |
| 12:56 |
csharp |
Method duration for [open-ils.storage.action.hold_request.copy_targeter]: 73.370 |
| 12:56 |
csharp |
the frontend still times out, but it's better on the server side |
| 12:58 |
* dbs |
wonders about caching the COUST rather than fetching it fresh every time |
| 12:59 |
eeevil |
sseng: re barcode in 905u, evergreen doesnt write that, it reads it from external tools |
| 13:00 |
* eeevil |
disappears as quickly as he appeared |
| 13:00 |
sseng |
eeevil: ooh i see. so, might not be a good idea to comment that check out, thanks! |
| 13:01 |
|
Dyrcona joined #evergreen |
| 13:02 |
Dyrcona |
More pgtap questions. |
| 13:02 |
Dyrcona |
Should a test file related to a database upgrade script go in t or t/regress? I assume t, but thought I would ask. |
| 13:15 |
|
rsinger joined #evergreen |
| 13:20 |
|
rfrasur joined #evergreen |
| 13:25 |
|
RoganH joined #evergreen |
| 13:27 |
Dyrcona |
Hmm. Also, what about a branch with two upgrade scripts? So far I'm putting the tests in a single .pg file. |
| 13:28 |
Dyrcona |
The scripts could be merged into one upgrade script, I guess. |
| 13:31 |
|
ericar joined #evergreen |
| 13:54 |
tsbere |
senator / csharp: Thinking about holds and the stuff being done, wouldn't most of the lookups in the targeter not affect placement at all? respond_complete happens *before* the hold creation process fires off a blind request to the copy targeter after all... |
| 13:58 |
* csharp |
has no idea... |
| 13:59 |
* senator |
thinks and looks |
| 13:59 |
senator |
csharp: also, cool, thanks for testing that, at least it's a small win. more to do i see... |
| 13:59 |
csharp |
senator: happy to help! |
| 14:02 |
|
ktomita_ joined #evergreen |
| 14:05 |
senator |
tsbere: so you mean the respond_complete near the end of sub create_hold aka open-ils.circ.holds.create.override ? |
| 14:07 |
senator |
i see tpac code calling open-ils.circ.holds.test_and_create.batch instead |
| 14:09 |
* Dyrcona |
sings: "Let's do the 'rebase' again...." |
| 14:11 |
Dyrcona |
senator: Note tsbere is talking about the targeter and not tpac. |
| 14:12 |
tsbere |
senator: test and create batch ends up calling open-ils.circ.holds.create (or the .override variant) if the "test" succeeds |
| 14:12 |
senator |
right, well i thought we're talking about whether the targeter must be waited on at hold placement time |
| 14:12 |
Dyrcona |
Also, pgtap is easy. :) |
| 14:13 |
senator |
ah there it is, i see |
| 14:13 |
tsbere |
senator: And that leads us into create_hold, which is where the targeter comes into play. I think the problem with hold *placement* is the "test" phase of that, the call to open-ils.circ.title_hold.is_possible call |
| 14:13 |
Dyrcona |
senator: OK. I know we have some internal tickets, related to checkin, that we like to blame on holds code being slow but we've not figured out what exactly is the problem. |
| 14:14 |
* graced |
thinks eeevil would be helpful about now... |
| 14:14 |
* Dyrcona |
shuts up, so as not to confuse things. |
| 14:36 |
rfrasur |
jeff++ |
| 14:38 |
Dyrcona |
So, another pgtap question. |
| 14:39 |
Dyrcona |
What should I do with views that were altered by the upgrade script? |
| 14:40 |
jeff |
as in, how should you test them? |
| 14:41 |
jeff |
sorry, in the context of pg_tap, i suppose that was a silly question on my part. |
| 14:42 |
* dbs |
doesn't understand the question |
| 14:42 |
tsbere |
Dyrcona: I think you can do tests as though you would for a table (columns and types for the columns) - Beyond that you may want to look at ensuring test data is there and pulling from the view to ensure you got the correct info, maybe? |
| 14:44 |
Dyrcona |
dbs: I'm working on tests for an upgrade script that alters existing view definitions. I'm also discovering that there is no easy way to check if a view definition (i.e. its underlying query) is correct. |
| 14:44 |
Dyrcona |
jeff: Basically, yes. |
| 14:44 |
Dyrcona |
Testing for the existence of the views is easy. |
| 14:45 |
Dyrcona |
Testing it the view has or hasn't certain columns is also easy. |
| 14:45 |
Dyrcona |
s/it/if/ |
| 14:45 |
csharp |
senator: https://bugs.launchpad.net/evergreen/+bug/1272316/comments/4 |
| 14:45 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 2, heat: 10) [Undecided,New] |
| 14:45 |
phasefx |
Dyrcona: test the views behavior with test data? |
| 14:45 |
senator |
csharp++ kmlussier++ |
| 14:46 |
dbs |
Dyrcona: given that the view probably surfaced incorrect data before, and that's why it has been upgraded, wouldn't you just insert data into the underlying tables that you know would trigger the bad "before" case and test that the view now shows "good" data? |
| 14:46 |
dbs |
what phasefx said, only more verbose :) |
| 14:46 |
Dyrcona |
dbs: The views are being changed not because they were incorrect before, but because columns are disappearing from a base table. |
| 14:47 |
tsbere |
Dyrcona: In that case I would mainly focus on "the view does not have the column that went away" |
| 14:47 |
phasefx |
Dyrcona: I would still pick some data that exercised the boundaries of whatever query powered the view.. find data that should fall in and outside of the view |
| 14:47 |
phasefx |
if it is indeed the query you're concerned with |
| 14:50 |
jeff |
beyond testing a view for columns being present / not-present and testing data types of those columns, i think you have to use data to test the underlying query of a view. |
| 14:50 |
Dyrcona |
phasefx: I'll give that some thought. Since we're talking about billing and 8 views (3 or which are only modified if they exist), that could be a lot of test data. |
| 14:51 |
jeff |
i'm not sure that "view's definition is [SQL HERE]" is a good test. |
| 14:51 |
Dyrcona |
jeff: I'm not sure "view's definition is ...." is easily done. |
| 14:52 |
jeff |
i don't see a way, short of extending. i'm just saying "maybe there isn't an easy way because it's not a great test" :-) |
| 14:52 |
phasefx |
when it comes to testing structure (which I think is not being advocated here), I think we could do that better / more centrally for everything |
| 14:52 |
|
stevenyvr joined #evergreen |
| 14:52 |
Dyrcona |
tsbere: Also, I don't recall at this point if the view columns changed. It may only be from statements in many cases. |
| 14:53 |
Dyrcona |
jeff: I agree. |
| 14:53 |
dbs |
SELECT definition FROM pg_catalog.pg_views WHERE schemaname = blah, viewname = blah; # but I agree with data view |
| 14:53 |
Dyrcona |
Are there transactions in the concerto data, and are bills included? |
| 14:54 |
Dyrcona |
If yes && yes, I may just test the views in live_t? |
| 14:54 |
dbs |
Dyrcona: Yes, but you would need to run the fine generator to actually generate bills |
| 14:54 |
dbs |
So no |
| 14:54 |
jeff |
i am interested in having or creating sample bills and payments, fwiw. |
| 14:55 |
phasefx |
care would have to be taken if we use the fine generator for test data, because of the day's date changing |
| 14:55 |
jeff |
i have some pretty fun test cases from our live data. ;-) |
| 14:56 |
Dyrcona |
dbs: (I am not knocking automated tests.) I think that speaks to my arguments about the complexity of testing things in a system as complicated and why automated tests will never catch everything. |
| 14:56 |
jeff |
i think we could have bills and payments in the sample data without need for using the fine generator to create the bills. |
| 14:56 |
Dyrcona |
jeff++ |
| 14:56 |
phasefx |
could and should |
| 14:56 |
dbs |
Dyrcona: Jesus, man, I never claimed automated tests will catch everything! |
| 14:56 |
Dyrcona |
dbs: OK. :) |
| 14:57 |
Dyrcona |
I don't mean to start a war. |
| 14:57 |
dbs |
jeff: I'm pretty sure berick and I kicked that around but didn't want to insert artificial data that might end up not matching what the fine_generator would actually produce |
| 14:57 |
dbs |
Dyrcona: You should have just let me win |
| 14:57 |
Dyrcona |
dbs++ |
| 14:57 |
dbs |
Dyrcona++ |
| 14:58 |
Dyrcona |
dbs: I'm writing tests. I think you did win. :) |
| 14:58 |
* dbs |
was looking for a wrecking ball |
| 14:58 |
Dyrcona |
Yeah, I can see issues with bogus data that doesn't match fine generator. |
| 14:58 |
phasefx |
hrmm. I think historical bills are fair game if they do indeed match what non-artificial data for that point in time looks like |
| 15:00 |
jeff |
dbs: yeah, was that conversation on list or on irc, or did it happen elsewhere? |
| 15:00 |
jeff |
i seem to recall it, and that this is at least somewhat of a rehash. |
| 15:00 |
dbs |
irc or launchpad, or perhaps a mix of both |
| 15:02 |
Dyrcona |
I'll leave out those tests for now. I can come back and add them later. |
| 15:03 |
|
BlerenMen joined #evergreen |
| 15:03 |
|
BlerenMen left #evergreen |
| 15:03 |
Dyrcona |
I think I'll move on to tests for branches that just add settings and permissions. Those are simple. |
| 15:03 |
* phasefx |
remembers having this sort of pain with sample data to power the receipt template editor, and we see how that turned out :( |
| 15:03 |
keynote2k |
Hi, all. Tony from Software Freedom Conservancy here. I'm looking for photos of Evergreen Conference 2012 in Indiana to use in Conservancy's FY2012 annual report. Anyone have any photos I could use (ideally, under a Creative Commons license)? |
| 15:03 |
jeff |
but i'd still like to figure out a way of having the test data, so maybe we can revisit. |
| 15:03 |
keynote2k |
if so: privmsg me. Thanks! |
| 15:04 |
jeff |
phasefx: yeah, good example. the data was buried and drifted significantly. i've been thinking about receipts and receipt macros lately. :-) |
| 15:04 |
phasefx |
jeff: yeah, I'm doing a talk on it at the EG conference, so I'll probably get the itch soon to make it better first :) |
| 15:04 |
jeff |
oh, receipts? |
| 15:04 |
phasefx |
two talks, one for QA, and one for customizing receipt templates |
| 15:05 |
jeff |
ah. i see why those intersected for you, then. :-) |
| 15:05 |
phasefx |
QA talk: need more tests :) |
| 15:06 |
jeff |
"Please join me after the receipt printer talk in the atrium, where we will be destroying a series of receipt printers using various weapons and solvents." |
| 15:06 |
phasefx |
haha |
| 15:06 |
jeff |
now THERE'S a fund raising opportunity. |
| 16:58 |
|
ElliotFriend joined #evergreen |
| 17:00 |
ElliotFriend |
@wunder 63033 |
| 17:00 |
pinesol_green |
ElliotFriend: The current temperature in Jost Farm, Florissant, Missouri is 35.4°F (4:00 PM CST on January 24, 2014). Conditions: Scattered Clouds. Humidity: 26%. Dew Point: 3.2°F. Windchill: 26.6°F. Pressure: 30.05 in 1018 hPa (Falling). |
| 17:14 |
ElliotFriend |
Dyrcona: Did we talk a couple (few) months back about using Git to push EG upgrades from a laptop to testing to production? |
| 17:14 |
ElliotFriend |
Or was that someone else? |
| 17:25 |
Dyrcona |
That was probably me. |
| 17:26 |
ElliotFriend |
Any chance you remember when that was? I'm trying to find the conversation for reference, but for the life of me can't |
| 18:45 |
jtaylorats |
Hard to say why those characters are in there. |
| 18:45 |
Dyrcona |
Oh, its easy to say why the characters are in there: Most software that works with MARC records just plain sucks. |
| 18:46 |
Dyrcona |
When I load records I usually run them through some Perl code to convert them to MarcXML, convert the charset if necessary, and to "scrub" the records of control characters and other junk, first. |
| 18:47 |
jtaylorats |
Partly curious why the admin tool has no problem with the insert. Can't say for sure but I don't think it scrambled anything. |
| 18:47 |
jtaylorats |
I'll have to do some more checking. This is a test load and not worrying about it at the moment but need to cover that base before the next load. |
| 18:48 |
jtaylorats |
Thanks all. |
| 18:48 |
jtaylorats |
Need to get out of here. |
| 18:48 |
jtaylorats |
Bye for now. |
| 18:48 |
jtaylorats |
Hopefully one day I can answer a question for someone :-) |
| 18:49 |
jtaylorats |
...and maybe it will even be the right answer ;-) |
| 18:50 |
jtaylorats |
WooHoo!!! Looks like the server went down....that means I can quit for the night. |
| 20:14 |
|
timhome joined #evergreen |
| 20:26 |
|
rsinger joined #evergreen |
| 23:05 |
|
zerick joined #evergreen |
