| Time |
Nick |
Message |
| 00:17 |
|
tfaile_ joined #evergreen |
| 00:18 |
|
Callender_ joined #evergreen |
| 00:18 |
|
BigRig_ joined #evergreen |
| 01:03 |
|
Mark__T joined #evergreen |
| 01:47 |
|
Pirc joined #evergreen |
| 02:23 |
|
jeff_ joined #evergreen |
| 04:14 |
|
BigRig joined #evergreen |
| 04:52 |
|
wjr_ joined #evergreen |
| 07:40 |
|
jboyer-isl joined #evergreen |
| 07:48 |
|
wjr_ joined #evergreen |
| 08:09 |
|
kmlussier joined #evergreen |
| 08:26 |
|
collum joined #evergreen |
| 08:35 |
|
tspindler joined #evergreen |
| 08:41 |
|
akilsdonk_ joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:47 |
|
Shae_ joined #evergreen |
| 09:02 |
|
kbeswick joined #evergreen |
| 09:08 |
|
ericar joined #evergreen |
| 09:11 |
|
77CAAL8G9 joined #evergreen |
| 09:11 |
|
timf joined #evergreen |
| 09:18 |
csharp |
looking at tags/rel_2_5_m2 and trying to find a db upgrade script - is there one yet? |
| 09:19 |
csharp |
we're pondering the difference between a 2.3 - 2.4 upgrade and a 2.3 - 2.5 upgrade and I was trying to get a sense of what's involved from 2.4 - 2.5 |
| 09:20 |
paxed |
i don't think there's one yet. |
| 09:21 |
bshum |
csharp: There isn't one yet, no. I'm rolling my own mini-upgrade as of last night. |
| 09:22 |
bshum |
Just by doing all the numbered scripts, as per usual. |
| 09:22 |
csharp |
ok |
| 09:22 |
bshum |
The fun part out of it is reingesting all the bib records yet again. |
| 09:22 |
bshum |
Which is part of 0800 I think, for reingesting bibs to deal with post-apostrophe fixing. |
| 09:23 |
* csharp |
begins expecting that to be part of every upgrade |
| 09:23 |
bshum |
Pretty much :D |
| 09:23 |
|
rfrasur joined #evergreen |
| 09:23 |
csharp |
that really is a burden for us |
| 09:24 |
csharp |
we went live on 2.3 before the reingest was done - not pretty - though at least our records have 901c's now ;-) |
| 09:24 |
* bshum |
would consider that a burden for everybody, but won't get too derailed :P |
| 09:24 |
rfrasur |
bshum: is your internet behaving? |
| 09:24 |
bshum |
rfrasur: I went to the office for the first time before 9 am in months. |
| 09:24 |
bshum |
So unfortunately, no. |
| 09:25 |
rfrasur |
hard to believe how much we're tied to it anymore...but that, as you know, is a big pain in the patootie. |
| 09:25 |
bshum |
Have an appointment with Charter tech tomorrow morning to look into it. |
| 09:26 |
bshum |
I think it wouldn't bother me so much except that we're also outside proper cell coverage so my phone won't even work :( |
| 09:26 |
kmlussier |
berick++ #Nice detailed response to my acq question on list. Thanks! |
| 09:26 |
* bshum |
hates living in the woods. |
| 09:26 |
rfrasur |
yeah, same here...except it's corn instead of trees (and just distance) |
| 09:27 |
rfrasur |
if it was trees, I might be a little more understanding...maybe. and to think we lived with mobile broadband as our home internet for a couple years. |
| 09:27 |
* rfrasur |
doesn't miss that at all. |
| 09:27 |
paxed |
well, as long as there's a good 'net connection, i don't mind living in the woods at all. |
| 09:27 |
bshum |
csharp: Think of the plus side, 2.5'll have better metabib indexing so you don't have wacky dupe entries floating about? |
| 09:28 |
csharp |
cool |
| 09:28 |
rfrasur |
paxed: unfortunately in most places here, any type of rural location means subpar connections...or really expensive ones. |
| 09:28 |
paxed |
rfrasur: yes, i know. |
| 09:28 |
bradl |
bshum: ah, you're infected with Charter, too? |
| 09:28 |
rfrasur |
for now :D |
| 09:29 |
bshum |
bradl: Yes, unfortunately the only cable company with service in my area. :( |
| 09:29 |
* rfrasur |
is very optimistic (well...pretty optimistic) |
| 09:29 |
bradl |
bshum: same here. my internets died Friday. |
| 09:29 |
bradl |
(and are still dead) |
| 09:30 |
berick |
yikes |
| 09:30 |
|
Guest78680 joined #evergreen |
| 09:30 |
bradl |
after the first tech "forgot" us I got another tech who left wordless (without fixing it) and finally got a third tech who informed me the "tap" at the road needed to be replaced. Another two days for that. |
| 09:31 |
* bshum |
shudders at his potential future. |
| 09:31 |
bradl |
charter-- |
| 09:31 |
rfrasur |
hmm, bradl, you seem to be handling it gracefully. |
| 09:31 |
csharp |
rfrasur: do not be fooled by bradl's calm IRC facade... |
| 09:32 |
bradl |
rfrasur: thanks ;) I figure it's a first world problem |
| 09:34 |
paxed |
hmmm. |
| 09:34 |
bradl |
csharp: my house is across the interstate from the datacenter, so I've been tempted to set up a pringles can wireless attenna and point it that direction |
| 09:34 |
paxed |
rgrep ctx.get_org_setting * | grep ctx.user.home_ou |
| 09:35 |
paxed |
^ one uses ctx.user.home_ou.id, two use ctx.user.home_ou, as the first param to ctx.get_org_setting() ... |
| 09:35 |
paxed |
that sounds like a bug |
| 09:35 |
csharp |
bradl: ha! |
| 09:37 |
* rfrasur |
is not fooled |
| 09:38 |
rfrasur |
bradl++ |
| 09:40 |
rfrasur |
hmm, do you think that legislators think their constituents actually appreciate form letters with pat answers? |
| 09:40 |
* rfrasur |
deletes the email before it affects blood pressure. |
| 09:41 |
* paxed |
investigates |
| 09:42 |
|
mrpeters joined #evergreen |
| 09:43 |
rfrasur |
something that's called .id is usually a number, isn't it? while w/o the .id....it's a text string? that's just the understanding I've had when building reports (that work 50% of the time) |
| 09:43 |
paxed |
http://i.imgur.com/6jPQg1l.jpg |
| 09:43 |
paxed |
i think ctx.user.home_ou is a fieldmapper object, so it shouldn't work |
| 09:44 |
* paxed |
compiles eg and tests |
| 09:44 |
rfrasur |
just so you know...I prefer earth to the other views. much prettier....and watered |
| 09:44 |
paxed |
yup |
| 09:46 |
paxed |
(the Venus picture was taken in '67!) |
| 09:46 |
eby |
venus one had a steam punk feel |
| 09:47 |
rfrasur |
@wunder 47346 |
| 09:47 |
pinesol_green |
rfrasur: The current temperature in Hagerstown, Hagerstown, Indiana is 79.0°F (9:46 AM EDT on July 16, 2013). Conditions: Clear. Humidity: 81%. Dew Point: 73.4°F. Pressure: 30.33 in 1027 hPa (Rising). |
| 09:47 |
paxed |
@wunder Mars |
| 09:47 |
pinesol_green |
paxed: The current temperature in Adams Twp, Mars, Pennsylvania is 86.7°F (9:45 AM EDT on July 16, 2013). Conditions: Partly Cloudy. Humidity: 65%. Dew Point: 73.4°F. Pressure: 30.37 in 1028 hPa (Steady). |
| 09:47 |
paxed |
wrong Mars, damnit. |
| 09:47 |
rfrasur |
We've already got the steam. Now we just need a mouthy young adult...and we'll have the punk. |
| 09:48 |
rfrasur |
jboyer-isl: are you available? |
| 09:49 |
jboyer-isl |
I'm in and out. In now. |
| 09:51 |
rfrasur |
I did a little testing on the galaxy tab 7 last night. it worked well, looked good, etc. the only thing I was noticed was when I changed orientation it switches to traditional OPAC view (which was expected), but because it's narrower, the facets and results don't fit...and the facets show first. Is there a way to have an intermediate view that gets those facets out of the way? |
| 09:52 |
jboyer-isl |
There is. I'll have to look some things up, but there can easily be an intermediate step between everything and bare bones. |
| 09:54 |
rfrasur |
excellent. Other than that...and I also was thinking about the search view. I'm not sure that's a big deal after all. Does it show results based on relevance as default? (I don't really know how to spell relevance/relevence) |
| 09:54 |
rfrasur |
but...other than that...I think it's good. I mean, there's always something to critique/criticize, but it seems like a great step. |
| 09:55 |
|
finnx joined #evergreen |
| 09:57 |
jboyer-isl |
Relevance. It probably doesn't hurt that you can't choose date anyway, since we've got a ton of records with crap 008's. Usually the "oldest" and "newest" records are garbage. Title might be nice, if I can find a good way to fit it in. |
| 09:57 |
|
yboston joined #evergreen |
| 09:58 |
rfrasur |
jboyer-isl: I thought the same thing. Also, with just a little training, we can show people how to use the search field to do their own "advanced" search to be a little MORE relevant/ent (I need to look that up). |
| 09:59 |
rfrasur |
I'd rather show someone a "trick" than muck up the display. |
| 10:00 |
rfrasur |
(ant...not ent....though ents are more interestings than ants) |
| 10:10 |
paxed |
well, this is interesting. |
| 10:12 |
rfrasur |
? |
| 10:12 |
paxed |
using testdata, when logged in OPAC, ctx.user.home_ou == 1. When logged in via staff client, it's a fieldmapper object, so then ctx.user.home_ou.id == 1 |
| 10:13 |
rfrasur |
hmm, that actually IS kind of interesting. |
| 10:13 |
paxed |
(and if you happen to use the wrong variable as a parameter to ctx.get_org_setting(), you get the Internal Server Error. |
| 10:13 |
paxed |
) |
| 10:14 |
* paxed |
goes to file a bug. |
| 10:21 |
|
Shae_ joined #evergreen |
| 10:35 |
dbs |
bshum: hey, 2.4.1 will have better metabib indexing, won't it? I thought that was part of the fix-apostrophes branch |
| 10:35 |
bshum |
dbs: I'm sorry, that does sound correct. |
| 10:37 |
bshum |
csharp, see dbs' more accurate information about the reingesting fixes --^ |
| 10:37 |
bshum |
That is whenever we have 2.4.1 ;) |
| 10:37 |
dbs |
bshum: I'm just sorry that anyone has to reindex within a given release cycle |
| 10:38 |
bshum |
dbs: I have to figure out why we're apparently missing two metabib indexes. Throws me wildly off my game :( |
| 10:38 |
bshum |
And I assume that to mean once I add the metabib fields I end up having to redo the whole thing all over again anyways. |
| 10:38 |
dbs |
caused by dump / restore? |
| 10:39 |
bshum |
No, I must have missed some new field additions in some upgrade step. |
| 10:39 |
bshum |
I just want to make sure it's my own fault and not some weird schema drift that didn't make it into an upgrade script file. |
| 10:40 |
dbs |
bshum: which indexes? I'll do a sanity check on our own insane instance |
| 10:41 |
bshum |
dbs: Hmm, it was the last two for me. 29 - system control number, and 30 LC control number |
| 10:41 |
bshum |
For some reason they're just not there. |
| 10:41 |
bshum |
I created them manually but running the inserts from master |
| 10:44 |
|
kivilahtio joined #evergreen |
| 10:45 |
dbs |
ah, we have both of those. but doesn't look like 0680 included them in the upgrade script |
| 10:45 |
* dbs |
tries going further back in time |
| 10:46 |
dbs |
lccn is created in 2.0.7-2.0.8-upgrade-db.sql only, it seems |
| 10:47 |
dbs |
scn doesn't seem to be created in any version-upgrade script |
| 10:47 |
dbs |
so I don't think you're crazy |
| 10:47 |
* rfrasur |
interjects "about that" |
| 10:47 |
dbs |
rfrasur++ |
| 10:48 |
* rfrasur |
bows |
| 10:48 |
* rfrasur |
goes back to work |
| 10:49 |
bshum |
dbs: That totally figures then |
| 10:49 |
bshum |
We went from 2.0.6-ish to master (2.2-ish) |
| 10:49 |
bshum |
Okay, I feel much better. Thanks dbs. |
| 10:51 |
bshum |
The LCCN one is important for one of the next upgrade scripts on the way to 2.5 |
| 10:51 |
bshum |
I didn't note which one now that I think about it. |
| 10:51 |
bshum |
But that'll fumble folks who don't have their metabib field entries in order. |
| 10:52 |
dbs |
@later tell jboyer-isl yeah, facets (as secondary content) really should be loaded after the main content; my responsive branch was deliberately trying not to touch the underlying markup as a proof of concept, but there's no reason we can't start fixing things for master / 2.5 |
| 10:52 |
pinesol_green |
dbs: The operation succeeded. |
| 10:55 |
rfrasur |
dbs++ # The facets honestly haven't wowed me. I get the idea. It's cool, but they don't seem to add much value at this point. Just one perspective (and I abhor cluttered screens). |
| 10:55 |
dbs |
bshum: this is one of the reasons my position on version-upgrade scripts is that anything that goes into a minor version upgrade script (such as 2.0.6-2.0.7) needs to go into the major version upgrade script (such as 2.0-2.1) and/or a corresponding major/minor version upgrade script (such as 2.1.0-2.1.1), because people might upgrade before that lower minor upgrade exists :/ |
| 10:56 |
dbs |
rfrasur: your perspective was confirmed by a lot of research into faceted displays elsewhere, fwiw; they seem logical, but nobody clicks on them in practice |
| 10:57 |
dbs |
(which is one of the reasons, I believe, google went back to not surfacing facets on its left hand side) |
| 10:57 |
rfrasur |
I've clicked on them many times just to see how nicely they worked and was underwhelmed. I think that maybe it's an issue of so many records with such divergent quality. |
| 10:59 |
* rfrasur |
doesn't know enough to do anything other than suppose though. |
| 11:00 |
rfrasur |
@love Google Drive |
| 11:00 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves Google Drive. |
| 11:04 |
bshum |
dbs: version-upgrade scripts give me headaches, but I see what you're saying. :( |
| 11:05 |
bshum |
dbs: I guess I should bug ticket those two fields though and get the ball rolling towards getting that resolved. |
| 11:05 |
bshum |
dbs++ #for checking things out for me |
| 11:05 |
paxed |
how do i login to the selfcheck interface? |
| 11:06 |
bshum |
paxed: In our case, we use a stripped down profile with the minimum permissions needed to operate the self-check account. Though any staff account would work too. |
| 11:07 |
|
kayals joined #evergreen |
| 11:07 |
paxed |
i've been trying egadmin/egadmin, it logs in, but i can't seem to actually log in with "username" or "library barcode" after that |
| 11:10 |
berick |
paxed: beware that Firefox is busted these days. an opensrf upgrade (opensrf_xhr.js) should fix it, though. |
| 11:11 |
berick |
s/fix it/allow it to hobble along like other browsers/ |
| 11:12 |
paxed |
well, i dunno, but right now i'm trying opera, and that does even less. |
| 11:12 |
berick |
well, self-check was designed specifically with firefox in mind |
| 11:12 |
paxed |
no login, no complaints, links do nothing, etc. |
| 11:13 |
berick |
i would not be terribly surprised if other browsers failed miserably. i would expect chromium to mostly work, though. |
| 11:13 |
berick |
though there could be some formatting issues |
| 11:14 |
kayals |
By default admin account did not get associated to the top org level unit. How to assign admin to get top level permission...say Global Administrator |
| 11:14 |
kayals |
thanks |
| 11:23 |
rjackson-isl |
bshum++ for knowledge sharing |
| 11:23 |
bshum |
rjackson-isl: Please feel free to add notes or findings to that bug report. |
| 11:24 |
bshum |
I'll try to do the same once the dust settles more over here :( |
| 11:27 |
bshum |
kmlussier: "Now witness the firepower of this fully armed and operational battle station." (replace battle station with test server) |
| 11:29 |
|
kmlussier1 joined #evergreen |
| 11:31 |
kmlussier |
Heh |
| 11:31 |
rfrasur |
kmlussier++ # that sounds like a huge task |
| 11:32 |
|
zerick joined #evergreen |
| 11:36 |
rjackson-isl |
bshum: comment added to bug 1185865 |
| 11:36 |
pinesol_green |
Launchpad bug 1185865 in Evergreen "Hold targeter taking a long time to run" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1185865 |
| 11:36 |
* rfrasur |
will jump on that bug. |
| 11:36 |
rfrasur |
(not literally) |
| 11:36 |
rjackson-isl |
rfrasur++ ;-) |
| 11:37 |
bshum |
rjackson-isl: Once upon a time, I got in that scrape too. |
| 11:37 |
bshum |
I ended up manually setting the prev_check_time for all active holds to force them into off hours again. |
| 11:37 |
bshum |
And then let the hold targeter spread things back out more evenly again. |
| 11:38 |
bshum |
Like I set all active holds to a prev check time of midnight or something back then. |
| 11:38 |
bshum |
I've been thinking to push them back towards 9 or 10 pm at the rate I'm going. |
| 11:55 |
jboyer-isl |
We secretly replaced kmlussier's test server with Folgers crystals. Let's see if she notices. |
| 11:55 |
rfrasur |
jboyer-isl++ |
| 11:56 |
jboyer-isl |
dbs: agreed. I was also trying to take a light touch with the html in 2.2. I'll still try to leave as much alone in the future as I can thouhgh, or I'm likely to try to redesign the whole thing. :D |
| 11:56 |
* kmlussier |
probably wouldn't notice, but tsbere might. :) |
| 11:58 |
kmlussier |
berick: Do you mind if I plagiarize your e-mail for the acq docs? |
| 12:00 |
berick |
kmlussier: go for it |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:08 |
dbs |
paxed: chrome and firefox both worked for the self-check for me, using OpenSRF master (due to that opensrf_xhr.js issue berick mentioned) when I wrote up http://docs.evergreen-ils.org/2.4/_self_checkout.html a week or so ago |
| 12:09 |
paxed |
maybe it's just some settings i'm missing then. i tried it with the test data that comes with eg. |
| 12:09 |
paxed |
the concerto |
| 12:09 |
dbs |
paxed: there were some gotchas that I noted along the way, too - like needing to have hours of operation set - and I documented those |
| 12:10 |
paxed |
ah. well, that's it then. |
| 12:10 |
dbs |
paxed: no, that's all that I used. |
| 12:10 |
dbs |
"Setting library hours of operation |
| 12:10 |
dbs |
When the self check prints a receipt, the default template includes the library’s hours of operation in the receipt. If the library has no configured hours of operation, the attempt to print a receipt fails and the browser hangs." |
| 12:12 |
paxed |
hm, i'll have to look into it a bit more. |
| 12:13 |
paxed |
logged in with egadmin, and no matter what i entered into the username/barcode input, login always failed, and it asked the "Please Login" modal window again |
| 12:14 |
rfrasur |
(daggone it...I went back there for a FORK...not to talk about Gov. Pence's bourbon trail) |
| 12:14 |
* rfrasur |
tries again |
| 12:16 |
|
jdouma joined #evergreen |
| 12:16 |
* rfrasur |
returns with a fork and affirmation why she didn't become a children's librarian. |
| 12:17 |
dbs |
paxed: I had that problem initially too. https, not http. |
| 12:18 |
paxed |
dbs: ohhhh. |
| 12:18 |
paxed |
dbs: that works. |
| 12:21 |
* dbs |
documented https, but really we should redirect http to https in that case |
| 12:21 |
paxed |
sounds like a good idea to me. |
| 12:24 |
|
smyers_ joined #evergreen |
| 12:27 |
|
CarrieC joined #evergreen |
| 12:28 |
bshum |
paxed: dbs: There's a bug ticket for that too. |
| 12:28 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1047485 |
| 12:29 |
pinesol_green |
Launchpad bug 1047485 in Evergreen "Selfcheck needs to be run with https" (affected: 1, heat: 10) [Low,Confirmed] |
| 12:31 |
bshum |
I vaguely recall testing mrpeters' fix and there was something odd about it. But I guess I should look again... |
| 12:53 |
rfrasur |
dbwells++ |
| 12:53 |
bshum |
dbwells++ indeed |
| 12:56 |
bshum |
eeevil: I think our hold targeter is set to 3 right now. |
| 12:56 |
bshum |
For parallel |
| 12:57 |
bshum |
I was told that too high can be bad too. |
| 12:57 |
bshum |
? |
| 12:58 |
bshum |
That said, we didn't change it since the upgrade, so my thinking was the major thing to change was the addition of the new hold proximity stuff. Bad gut feeling thinking but sometimes I get lucky. |
| 13:03 |
sseng_ |
https://bugs.launchpad.net/evergreen/+bug/981074 "checkout limits based on copy location": is the following scenario possible? A consortium wants to limit checkout based on copy location for the entire consortium, however, the consortium does not own the copy locations, but the inidivual branches do (same copy location names repeated for each branch). Thanks! |
| 13:03 |
pinesol_green |
Launchpad bug 981074 in Evergreen 2.3 "Support Copy Location Circ Limit Sets" (affected: 1, heat: 8) [Undecided,Fix released] |
| 13:06 |
|
smyers__ joined #evergreen |
| 13:08 |
|
bshum joined #evergreen |
| 13:11 |
|
b_bonner joined #evergreen |
| 13:11 |
|
egbuilder_ joined #evergreen |
| 13:23 |
|
rfrasur_ joined #evergreen |
| 13:23 |
|
sseng joined #evergreen |
| 13:24 |
|
tfaile joined #evergreen |
| 13:27 |
|
edoceo joined #evergreen |
| 13:28 |
|
rri_ joined #evergreen |
| 13:52 |
|
smyers_ joined #evergreen |
| 13:55 |
|
CarrieC joined #evergreen |
| 13:58 |
|
akilsdonk_ joined #evergreen |
| 13:59 |
|
dboyle joined #evergreen |
| 13:59 |
gmcharlt |
meeting time |
| 13:59 |
gmcharlt |
#startmeeting Evergreen Developer meeting, 2013-07-16 |
| 13:59 |
pinesol_green |
Meeting started Tue Jul 16 13:59:32 2013 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:59 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 13:59 |
pinesol_green |
The meeting name has been set to 'evergreen_developer_meeting__2013_07_16' |
| 13:59 |
gmcharlt |
#info agenda is at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-07-15 |
| 13:59 |
|
dboyle joined #evergreen |
| 13:59 |
gmcharlt |
#topic introductions |
| 14:00 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 14:00 |
paxed |
#info paxed = Pasi Kallinen, Regional Library of Joensuu |
| 14:00 |
eeevil |
#info eeevil = Mike Rylander, ESI |
| 14:00 |
phasefx |
#info phasefx = Jason Etheridge, ESI |
| 14:00 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC |
| 14:00 |
|
jsime joined #evergreen |
| 14:00 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 14:01 |
|
Evergreen joined #evergreen |
| 14:01 |
berick |
#info berick Bill Erickson, ESI |
| 14:02 |
senator |
#info senator = Lebbeous Fogle-Weekley, ESI |
| 14:03 |
gmcharlt |
OK, thanks |
| 14:03 |
gmcharlt |
#topic Action items from last meeting |
| 14:03 |
gmcharlt |
#info action items were: (a) start on 2.6 road map; (b) bshum to summarize bug tracking based on dev feedback; (c) kmlussier to raise bug squashing day |
| 14:04 |
gmcharlt |
no action to report on the 2.6 roadmap |
| 14:04 |
remingtron |
#info remingtron Remington Steed, Hekman Library (Calvin College) |
| 14:04 |
gmcharlt |
bshum: kmlussier: updates? |
| 14:04 |
gmcharlt |
(I know that bshum is mostly not here) |
| 14:04 |
kmlussier |
bshum isn't here at all actually. |
| 14:05 |
kmlussier |
I need to defer my action item. I forgot I had an action item until yesterday. |
| 14:05 |
gmcharlt |
OK, that was simple enough |
| 14:05 |
gmcharlt |
#topic GSoC reports |
| 14:06 |
gmcharlt |
any updates from the mentors? |
| 14:06 |
kmlussier |
Before bshum had to leave, he mentioned that there is a working branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dmitriye/dashboard. |
| 14:07 |
gmcharlt |
#info a WIP branch from the student available at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dmitriye/dashboard. |
| 14:07 |
gmcharlt |
sounds like that's it |
| 14:07 |
gmcharlt |
#topic QA topics |
| 14:07 |
gmcharlt |
I think that item was from phasefx? |
| 14:08 |
phasefx |
yes |
| 14:08 |
gmcharlt |
phasefx: take it away, then :) |
| 14:08 |
phasefx |
I have some code I'm wanting feedback on, kudos, etc ;) And I'm hoping others may want to tie it into what we're doing now, etc. |
| 14:09 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/wheezy_installer |
| 14:09 |
|
BigRig_ joined #evergreen |
| 14:09 |
phasefx |
basically, given a pristine debian wheezy installation, this will install and run Evergreen without any prompting, and then fire off the pgTAP tests we have, and potentially whatever tests we come up with that require a live environment |
| 14:10 |
phasefx |
an area I'm really weak on is Buildbot, though it's not necessary for what I'm trying to do, it'd be nice to have some integration there |
| 14:11 |
|
tmccanna joined #evergreen |
| 14:11 |
phasefx |
so, any thoughts, interest, comments, etc? |
| 14:11 |
phasefx |
defer discussion to list? |
| 14:12 |
gmcharlt |
phasefx: it's a good idea, but sounds like discussion will in fact need to be deferred |
| 14:12 |
eeevil |
comment: +1 |
| 14:12 |
|
acoomes joined #evergreen |
| 14:13 |
berick |
phasefx: would you accept patches for teaching the script to update an existing install and firing the tests again? |
| 14:13 |
gmcharlt |
ok, moving on |
| 14:13 |
berick |
if it doesn't do that already, that is |
| 14:13 |
gmcharlt |
#topic OpenSRF release |
| 14:13 |
phasefx |
berick: yeap. it's mostly repeatable now |
| 14:13 |
* berick |
nods |
| 14:15 |
gmcharlt |
berick: does the multi-part message deprecation warrant a release? |
| 14:15 |
berick |
gmcharlt: yes. |
| 14:15 |
berick |
selfcheck is the main problem so far, since it's not run in xulrunner |
| 14:16 |
gmcharlt |
OK |
| 14:16 |
gmcharlt |
#action gmcharlt will cut OpenSRF 2.2.1 by Friday |
| 14:16 |
berick |
gmcharlt++ |
| 14:16 |
gmcharlt |
moving on |
| 14:16 |
gmcharlt |
#topic Evergreen 2.5 update |
| 14:17 |
gmcharlt |
dbwells: the floor is yours |
| 14:18 |
dbwells |
I sent an email update a few hours ago. Basic summary is that everything is going well, and the release is still on track. More details in the email: http://markmail.org/thread/zcxti4nkqkplo6uw |
| 14:18 |
gmcharlt |
dbwells++ |
| 14:18 |
berick |
dbwells++ |
| 14:18 |
dbwells |
Also, thanks again to everyone who contributed. |
| 14:18 |
kmlussier |
dbwells++ |
| 14:19 |
gmcharlt |
moving on |
| 14:19 |
gmcharlt |
#topic Evergreen 2.4.1 |
| 14:19 |
gmcharlt |
which essentially boils down to, when can we have it? |
| 14:20 |
eeevil |
will be concurrent with 2.3 and 2.2 releases, tomorrow (according the the calendar) |
| 14:20 |
senator |
2.2 is history |
| 14:20 |
* berick |
confirms 2.3 |
| 14:20 |
berick |
long live 2.2 |
| 14:20 |
eeevil |
senator: fair enough |
| 14:20 |
gmcharlt |
so 2.4.1 and 2.3.9 to be cut tomorrow? |
| 14:20 |
eeevil |
there is production use of the fix from https://bugs.launchpad.net/evergreen/+bug/1200770 but I'd be happy if others looked |
| 14:20 |
pinesol_green |
Launchpad bug 1200770 in Evergreen 2.4 "Search result rendering can crush the system" (affected: 1, heat: 6) [High,New] |
| 14:21 |
gmcharlt |
and should we tag the 2.2 series on the downloads page as deprecated? |
| 14:21 |
eeevil |
other than that, nothing burning for 2.4.1 |
| 14:21 |
eeevil |
gmcharlt: +1 |
| 14:21 |
gmcharlt |
#action berick and eeevil to cut 2.3.9 and 2.4.1 on 2013-07-17 |
| 14:22 |
senator |
gmcharlt: i believe so, re 2.2 deprecation. security releases possible through september, but that's it |
| 14:22 |
gmcharlt |
#action gmcharlt will talk to bshum about updating display of 2.2 on the downloads page |
| 14:23 |
kmlussier |
When dbs posted that agenda item, he also asked about an official 2.4 announcement. Is that something that should happen too or is it too late now? |
| 14:23 |
eeevil |
kmlussier: concurrent with the 2.4.1 announcement? |
| 14:24 |
kmlussier |
Sure, but I don't think we ever had an announcement saying 2.4 is out and here are all the new features we're getting. |
| 14:24 |
csharp |
"and - oh yeah, 2.4.0 came out too" |
| 14:26 |
eeevil |
kmlussier: I was planning to have a general "here's the new stuff in 2.4" part of of the announcement |
| 14:26 |
kmlussier |
eeevil++ |
| 14:26 |
eeevil |
do we want a separate 2.4.0 post at this point? |
| 14:26 |
csharp |
-1 |
| 14:26 |
kmlussier |
eeevil: I wouldn't think so. |
| 14:26 |
gmcharlt |
eeevil: "what's new in Evergreen 2.4", perhaps |
| 14:26 |
eeevil |
gmcharlt: sure ... I can make it separate |
| 14:27 |
eeevil |
to highlight |
| 14:27 |
gmcharlt |
highlighting++ |
| 14:28 |
eeevil |
thanks, also, to all the folks that have been backporting master bug fixes to 2.4 up to this point |
| 14:28 |
gmcharlt |
OK, I think that's it for 2.4.x |
| 14:28 |
gmcharlt |
#topic MassLNC performance evaluation |
| 14:29 |
gmcharlt |
#info Update from kmlussier: http://markmail.org/message/6yzorevfs6xtnn2u |
| 14:29 |
gmcharlt |
kmlussier: anything to add? |
| 14:29 |
kmlussier |
Not much to add. I know everyone wanted to be kept in the loop during the evaluation, so I wanted to send out our plans before we got started in earnest. |
| 14:29 |
kmlussier |
jsime and patnorton are here from OmniTI if anyone has any questions or thoughts on the plan thus far. |
| 14:30 |
kmlussier |
s/plan/plans |
| 14:30 |
kmlussier |
And we're looking forward to seeing what this evaluation turns up. |
| 14:31 |
patnorton |
hello all - jsime is our technical lead on this initiative and i'm the project manager working with jon and the team |
| 14:31 |
csharp |
patnorton: jsime: welcome! |
| 14:31 |
eeevil |
kmlussier (or patnorton/jsime): one thing was unclear to me ... the "using tsearch over ilike" part |
| 14:32 |
eeevil |
(and yes, welcome to our humble hamlet ;) ) |
| 14:32 |
jsime |
eeevil: in our initial pgbadger review of some of the production logs from MassLNC consortia, there were a few queries flagged using ILIKE comparisons |
| 14:34 |
jsime |
the dyanmically generated bib-search query, which showed frequently in the report was using tsearch, of course |
| 14:34 |
eeevil |
jsime: gotcha. those would very likely be left-anchored (indexed) searches of name columns ... for "real" search we do use tsearch |
| 14:34 |
eeevil |
righto. thanks for the clarification |
| 14:35 |
dbwells |
Maybe this was mentioned in earlier communications, but what is the estimated timeline for this project? |
| 14:35 |
jsime |
it wasn't clear from that initial review if the use of ILIKE was more extensive, though, hence the flagging of it |
| 14:35 |
eeevil |
jsime: very fair. thanks! |
| 14:35 |
jsime |
np |
| 14:36 |
patnorton |
dbwells - once we get moving with a fully functional test environment, approximately 2 − 2.5 months |
| 14:36 |
patnorton |
environment should be available this week |
| 14:36 |
patnorton |
i beleive |
| 14:36 |
dbwells |
patnorton: sounds good, thank you |
| 14:36 |
kmlussier |
Yes, we're hoping for this week unless tsbere tells me something differently. |
| 14:38 |
gmcharlt |
anything else on this topic, or any last-minute topics? |
| 14:38 |
kmlussier |
If anyone else has any other questions or comments, feel free to send them to the list. |
| 14:39 |
|
dconnor joined #evergreen |
| 14:39 |
patnorton |
kmlussier: thanks. all: we will be in the channel daily going forward to be able to ask questions and share anything we find along the way |
| 14:39 |
phasefx |
patnorton++ |
| 14:39 |
kmlussier |
patnorton++ |
| 14:42 |
gmcharlt |
ok, doesn't sound like anybody has additions to the agenda, so I'll go away and end the meeting |
| 14:42 |
gmcharlt |
thanks, everybody! |
| 14:42 |
gmcharlt |
#endmeeting |
| 14:42 |
pinesol_green |
Meeting ended Tue Jul 16 14:42:15 2013 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 14:42 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-16-13.59.html |
| 14:42 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-16-13.59.txt |
| 14:42 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-07-16-13.59.log.html |
| 14:42 |
senator |
gmcharlt++ |
| 14:42 |
kmlussier |
gmcharlt++ |
| 14:42 |
|
tmccanna left #evergreen |
| 14:42 |
kmlussier |
patnorton, jsime: Thanks for stopping in! :) |
| 14:42 |
dbwells |
gmcharlt++ # nice and quick! |
| 14:44 |
patnorton |
kmlussier: thanks for the intro. Look forward to working with everyone and getting into the details soon. |
| 15:07 |
|
stevenyvr2 joined #evergreen |
| 15:32 |
csharp |
backslash_e_in_psql++ |
| 15:32 |
csharp |
I've been going around the block and back between vim and psql for a long time |
| 15:32 |
csharp |
jeff_++ # for pointing that out one day ;-) |
| 15:33 |
jeff_ |
just passing it on from someone else who showed me. :-) |
| 15:33 |
jeff_ |
it can be handy. |
| 15:33 |
csharp |
my best use case is editing formatted sql statements |
| 15:50 |
|
gdunbar joined #evergreen |
| 15:51 |
|
patnorton left #evergreen |
| 15:53 |
|
rfrasur joined #evergreen |
| 16:01 |
|
acoomes joined #evergreen |
| 16:01 |
|
moodaepo1 joined #evergreen |
| 16:04 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e3fdd7> |
| 16:04 |
pinesol_green |
[evergreen|Kathy Lussier] Documentation for default values in Load Order Record form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d26b6e> |
| 16:05 |
|
smyers__ joined #evergreen |
| 16:06 |
|
BigRig joined #evergreen |
| 16:06 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:08 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:10 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:12 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:14 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:16 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:18 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:19 |
* berick |
chuckles |
| 16:19 |
berick |
@insult pinesol_green |
| 16:19 |
pinesol_green |
pinesol_green: You are nothing but a penguin-molesting coagulation of ruttish grits. |
| 16:20 |
rfrasur |
oh my |
| 16:20 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:21 |
rfrasur |
k |
| 16:21 |
eeevil |
dbwells is committing that as hard as he possibly can... ;) |
| 16:21 |
rfrasur |
I'd say so. |
| 16:22 |
berick |
pretty soon Evergreen will be just that one commit. |
| 16:22 |
rfrasur |
he's committed |
| 16:22 |
berick |
*rimshot* |
| 16:22 |
berick |
rfrasur++ |
| 16:22 |
* rfrasur |
bows "thank you...thank you very much" |
| 16:23 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:23 |
rfrasur |
well, lovelies...my work here is done. for now....today....and so, I bid you adieu....to you and you and...yeah. see y'all later. |
| 16:23 |
dbwells |
What is going on here? |
| 16:24 |
jboyer-isl |
pinesol_green thinks that was an awesome commit. Won't shut up about it. |
| 16:24 |
pinesol_green |
jboyer-isl: Go away, or I'll replace you with a very small shell script! |
| 16:24 |
pinesol_green |
jboyer-isl: I am only a bot, please don't think I'm intelligent :) |
| 16:24 |
dbwells |
jboyer-isl: Ok, that makes sense :) |
| 16:24 |
berick |
best I can tell, the commit was somehow committed twice to master, and how pinesol/git/i-don't-know is stuck in a fugue state |
| 16:24 |
berick |
s/how/now/ |
| 16:25 |
|
pastebot joined #evergreen |
| 16:25 |
* senator |
cringes and tentatively asks: nobody force-pushed master, did they? |
| 16:25 |
berick |
senator: i was under the impression that was disabled, could be wrong |
| 16:26 |
berick |
or, blocked i guess |
| 16:26 |
senator |
i hope you're not wrong |
| 16:26 |
|
pinesol_green joined #evergreen |
| 16:26 |
gmcharlt |
senator: doesn't look force-pushed to me |
| 16:27 |
bshum |
It's the bot |
| 16:27 |
bshum |
Doing something weird. |
| 16:27 |
dbwells |
very odd, two identical commits, right in a row. I'm just an innocent bystander, and pinesol_green is slandering my good name. |
| 16:27 |
tsbere |
I believe that gmcharlt and I can force-push master, as can anyone else with shell access to the git server, but otherwise it shouldn't happen |
| 16:27 |
kmlussier |
Ugh...my doc commit was the commit that went out before this started happening. But I don't have permission to push anywhere else but the docs repository. |
| 16:27 |
kmlussier |
At least I hope I don't. Because, to be honest, I have enough trouble pushing out docs. |
| 16:28 |
bshum |
@git repolist |
| 16:28 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 16:28 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 16:28 |
pinesol_green |
bshum: evergreen_website (Evergreen Website, branch: master) |
| 16:28 |
bshum |
Yeah I'll have to fix it later. |
| 16:28 |
bshum |
In the car |
| 16:29 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 16:29 |
bshum |
Unloading the git plugin for now... |
| 16:29 |
berick |
bshum++ |
| 16:29 |
berick |
eyes on the road! |
| 16:29 |
bshum |
Sorry about the noise folks. |
| 16:29 |
bshum |
And also, I'll be back later. |
| 16:43 |
|
smyers_ joined #evergreen |
| 17:01 |
dbwells |
still learning more about git, and with our current commit stream on master, I think this helps a lot: git log --graph |
| 17:02 |
dbwells |
It looks like that one commit was picked rather than pulled into the docs branch, so it appears with a unique hash in both, and the merge commit takes care of the duplication. Or something like that. |
| 17:03 |
dbs |
We generally avoid merge commits, so that might have thrown the bot |
| 17:04 |
dbs |
git log --graph # reminds me of "tig"'s view |
| 17:07 |
bshum |
Something definitely threw the bot |
| 17:07 |
bshum |
It was stuck at the merge commit I think |
| 17:07 |
bshum |
I had to fix the git repo, it was in some state where it was deleting tons of files and readding them. |
| 17:07 |
bshum |
Probably a quirk in the plugin |
| 17:09 |
bshum |
I'm letting it rebuild the local git repos from scratch again |
| 17:09 |
bshum |
Just to see if that helps it move on |
| 17:10 |
|
mmorgan left #evergreen |
| 17:13 |
bshum |
@git shortlog evergreen |
| 17:13 |
pinesol_green |
[evergreen|Kathy Lussier] Documentation for default values in Load Order Record form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d26b6e> |
| 17:13 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 17:13 |
bshum |
Hmm. |
| 17:15 |
pinesol_green |
[evergreen|Dan Wells] Capture and log AuthProxy logins with no account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=be36c3c> |
| 17:15 |
bshum |
Well, darn |
| 17:16 |
bshum |
Quick commit something else to get us past this hump! :D |
| 17:16 |
tsbere |
Interesting how two different people committed the same thing. And the repo shows an extra couple of commits. |
| 17:17 |
* tsbere |
is actually wondering if it was Kathy breaking something now |
| 17:17 |
dbs |
that's kind of how merge commits work |
| 17:17 |
dbs |
particularly if you allow empty commits |
| 17:55 |
bshum |
sseng: There was a netsplit during your question earlier today, so I didn't see it till I looked at the logs just now. |
| 17:55 |
bshum |
sseng: If you have to base circulation by copy locations but each location owns their own, it sounds like you're going to have quite a few rules to setup (at least one per copy location) |
| 17:57 |
sseng |
bshum: that's my suspicion as well. But the confusing part for me was to get them to work together, for example |
| 17:57 |
bshum |
sseng: What do you mean with "work together" exactly? |
| 17:57 |
bshum |
Meaning like, saying all "Adult Fiction" copy locations need to behave the same? |
| 17:58 |
sseng |
bshum: exactly! |
| 17:58 |
bshum |
I can't think of any way to do that within the existing framework. |
| 17:58 |
sseng |
bshum: but even though to the user the locations looks the same, in the db they are different... |
| 17:58 |
bshum |
I'd suspect you'd have to create a row for each location ID |
| 17:58 |
bshum |
And say, this is the expected behavior for that location |
| 17:58 |
bshum |
For each instance of it. |
| 17:59 |
bshum |
And they'd all be the same, but different in the location ID portion of the circ matrix entry. |
| 17:59 |
jeff_ |
bshum: I missed the earlier question. Why not have one Adult Fiction shelving location at a higher level in the org tree? |
| 18:00 |
bshum |
jeff_: You'd have to ask sseng that, but that's an option as well; though I think csharp covered that option in the general mailing list thread question too. |
| 18:00 |
sseng |
jeff_: earlier question: is the following scenario possible? A consortium wants to limit checkout based on copy location for the entire consortium, however, the consortium does not own the copy locations, but the inidivual branches do (same copy location names repeated for each branch). Thanks! |
| 18:02 |
sseng |
bshum: going to take a sec to try to understand suggestion you detailed avoe =) |
| 18:02 |
sseng |
bshum: above* |
| 18:02 |
bshum |
sseng: It's not a great one, but will do the job. |
| 18:02 |
|
mrpeters left #evergreen |
| 18:03 |
bshum |
It definitely works better if you can consolidate the copy locations as jeff suggests. |
| 18:06 |
bshum |
But basically if you can't consolidate, you'd have a row in circ matrix like location = 1, this is the duration, fine rate, max fine, etc. |
| 18:06 |
bshum |
Then another row for location = 2 with the same duration, etc. |
| 18:07 |
bshum |
Because 1 and 2 are both the same location name, but different actual locations by ID. |
| 18:07 |
bshum |
Lots of repetition to achieve the goal. |
| 18:07 |
bshum |
No real way to group them without consolidating the actual copy locations themselves. |
| 18:07 |
sseng |
bshum: yep consolidating would be a great plan in the near future, but going to take some political overhead |
| 18:08 |
bshum |
Always the tricky part :D |
| 18:08 |
sseng |
bshum: yep |
| 18:08 |
bshum |
If it was me, I'd write some fancy scripting to insert all the pieces into the database automatically, once you know what all the policies will have to be. |
| 18:08 |
bshum |
So like, grab all the IDs for locations named X, then insert the same policy over and over with all the different IDs |
| 18:09 |
bshum |
Tedious, but effective. |
| 18:09 |
|
smyers__ joined #evergreen |
| 18:10 |
sseng |
bshum: I see. So in short, create 30 different circ policies (if there are 30 branches and the branches own 30 different copy locations with the same name) |
| 18:10 |
bshum |
sseng: Pretty much, yes. |
| 18:11 |
sseng |
bshum: for example, to limit at most 5 checkouts from the copy location, would this enforce it for the entire consortium? |
| 18:11 |
bshum |
It's stuff like that which makes me glad that while we do allow every library in our consortium to name their locations separately and ID them separately, they don't use that as a defining factor for circulation behavior. |
| 18:12 |
sseng |
bshum: that is to say, the 5 limit applies as a consortium level total from the copy location, so that in all, only 5 items out at most for all combined (not 5 limit per branch?) |
| 18:13 |
bshum |
sseng: Hmm. |
| 18:13 |
bshum |
sseng: I haven't done limit sets that way. |
| 18:13 |
bshum |
But I think it should be possible. |
| 18:13 |
* bshum |
checks the database |
| 18:14 |
bshum |
I would envision that circ_limit_set would contain a limit set for a particular copy location name |
| 18:14 |
bshum |
And then you'd map that in circ_limit_set_copy_loc_map |
| 18:14 |
bshum |
To have a particular set of IDs for that given name |
| 18:14 |
bshum |
To create the combined effect. |
| 18:15 |
bshum |
Then you'd map the limit set to the circ matrix in circ_matrix_limit_set_map |
| 18:15 |
bshum |
Or something like that anyways. |
| 18:15 |
bshum |
And each circ matrix row would have to be mapped to the limit set. Over and over. |
| 18:15 |
bshum |
Yeah, it could work. |
| 18:16 |
bshum |
Easy peasy :D |
| 18:16 |
sseng |
bshum: O: |
| 18:17 |
bshum |
Think of it this way, at least it's a consistent pattern of behaviors that you have to repeat dozens of times. And not thousands of different scenarios created by non-consistent factors. |
| 18:17 |
bshum |
(that's my life) |
| 18:17 |
sseng |
bshum: =) |
| 18:17 |
bshum |
But anywho, off to dinner I go. Good luck sseng, let us know how it turns out ;) |
| 18:17 |
sseng |
bshum: going to try this out for sure thanks for the tips!! |
| 18:20 |
|
CarrieC left #evergreen |
| 18:44 |
|
smyers__ joined #evergreen |
| 18:44 |
|
pastebot joined #evergreen |
| 18:44 |
|
stevenyvr2 joined #evergreen |
| 18:44 |
|
dconnor joined #evergreen |
| 18:44 |
|
dboyle joined #evergreen |
| 18:44 |
|
rri_ joined #evergreen |
| 18:44 |
|
edoceo joined #evergreen |
| 18:44 |
|
egbuilder_ joined #evergreen |
| 18:44 |
|
b_bonner joined #evergreen |
| 18:44 |
|
bshum joined #evergreen |
| 18:44 |
|
jdouma joined #evergreen |
| 18:44 |
|
timhome joined #evergreen |
| 18:44 |
|
wjr_ joined #evergreen |
| 18:44 |
|
jeff_ joined #evergreen |
| 18:44 |
|
ldwhalen joined #evergreen |
| 18:44 |
|
mcooper joined #evergreen |
| 18:44 |
|
adbowling-isl joined #evergreen |
| 18:44 |
|
mtj_ joined #evergreen |
| 18:44 |
|
dbwells joined #evergreen |
| 18:46 |
|
dbs joined #evergreen |
| 18:46 |
|
pmurray_away joined #evergreen |
| 18:46 |
|
senator joined #evergreen |
| 18:46 |
|
phasefx_ joined #evergreen |
| 19:02 |
|
dboyle joined #evergreen |
| 19:11 |
|
smyers_ joined #evergreen |
| 19:21 |
|
stevenyvr2 left #evergreen |
| 19:28 |
|
dboyle_ joined #evergreen |
| 20:37 |
|
dboyle joined #evergreen |
| 22:34 |
|
kmlussier joined #evergreen |
| 23:27 |
gmcharlt |
boggling: https://github.com/mame/quine-relay |
| 23:27 |
jeff |
indeed. :-) |
| 23:54 |
jeff |
perlbrew++ |
| 23:54 |
jeff |
cpanm++ |
