Evergreen ILS Website

IRC log for #evergreen, 2013-12-03

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:01 jeff Which distro are you using, and did you do anything unusual to end up with JSON::XS 3.01?
00:10 smyers_ centos 5.9
00:10 smyers_ err 5.10
00:11 smyers_ and lots of stuff unusual
00:15 jeff interesting. peter lux's report said he was using debian squeeze and ubuntu precise. neither of those use the more recent version of JSON::XS that I can tell.
00:15 jeff Do you have any more details as to what happens for you when you have JSON::XS 3.01 installed?
00:15 jeff I'm trying to reproduce the "breaks with JSON::XS 3.01" issue.
00:28 smyers_ if you cpan JSON::XS you should get the latest version then restart autogen and try to login with a staff client
00:28 jeff sure -- when you do that, what breaks?
00:28 smyers_ boolean returns
00:29 smyers_ OpenSRF/Utilies/JSON.pm
00:31 smyers_ jeff: I need to go to bed, if you have more questions for me or if I can help anyway let me know
00:32 jeff huh. i wonder what "boolean returns" means. guess i'll find out when i upgrade JSON::XS to 3.01 on my second test instance.
02:01 senator joined #evergreen
03:16 mjingle left #evergreen
06:38 b_bonner joined #evergreen
06:39 mtcarlson_away joined #evergreen
06:53 jeff bug to follow, but user/jeff/fix_json_xs_booleans_option1 and user/jeff/fix_json_xs_booleans_option2 OpenSRF working branches have a fix for latest JSON::XS issues
07:17 jeff bug 1257264
07:17 pinesol_green Launchpad bug 1257264 in OpenSRF "JSON::XS 3.0 changes the way booleans are represented" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1257264
07:31 eeevil jeff: I'm going to look at a third option in a bot using opensrf type registration
07:41 rjackson-isl joined #evergreen
07:41 jboyer-isl joined #evergreen
08:14 kbeswick joined #evergreen
08:24 kmlussier joined #evergreen
08:28 pinesol_green [evergreen|Remington Steed] Docs: integrate holds docs from EG 2.1 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cc78604>
08:29 akilsdonk joined #evergreen
08:42 mmorgan1 joined #evergreen
08:42 mmorgan1 left #evergreen
08:43 Shae joined #evergreen
08:44 mmorgan joined #evergreen
08:51 timlaptop joined #evergreen
08:59 _bott_ joined #evergreen
09:01 ericar joined #evergreen
09:01 jeff eeevil: a bot, or typo?
09:06 rfrasur joined #evergreen
09:07 mrpeters joined #evergreen
09:10 dbwells jeff: s/bot/bit/  methinks :)
09:13 jeff i guessed.
09:15 dbwells jeff: OpenSRF already had "drones" before Amazon, so eeevil is just keeping us a step ahead ;)
09:15 bshum dbwells++
09:15 rfrasur Hmm, are talkin' Amazon drones?
09:16 rfrasur *insert "we"
09:17 kmlussier I notice at the bottom of  bug 1029591, there is a mention of backporting the code. I know it's too late for 2.3. but could we get it into 2.4?
09:17 pinesol_green Launchpad bug 1029591 in Evergreen 2.4 "ACQ backordered items show up as canceled" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/1029591
09:24 eeevil jeff: yes, a bit :)
09:25 dbs paxed: sorry to hear that i18n on the koha side of the fence has its problems too :/
09:26 paxed dbs: well, i knew it was a bit annoying, but the whole mess is really getting to me now that i'm translating it...
09:28 dbs paxed: maybe someday you'll be able to put together an i18n roundup: what evergreen and koha do wrong, what they do right, and the holy grail they should aim for :)
09:29 jeff in retrospect, i should have slept.
09:29 bshum dbs: Random aside, I've gotten some initial feedback on the format description being included as part of the results/record display.  Staff seem to really hate seeing stuff like "Projected medium" and trying to explain that.
09:30 paxed bshum: not to mention those aren't translated. :P
09:30 bshum dbs: I'm currently pondering either rejiggering that stuff or changing it to employ use of the search_label field
09:30 bshum (which may be more friendly language)
09:30 bshum paxed: Yeah that's on me for not following up on the bug :(
09:30 jeff dbwells: any more thoughts or questions on https://github.com/jonscott/iNCIPit/pull/4 ? i know i kinda' cheated with my "I have not summarized the changes here." :-)
09:32 dbwells jeff: looking at that right now, actually, will respond shortly
09:32 jeff dbwells: thanks!
09:33 kmlussier joined #evergreen
09:34 dbs bshum: good, so my plan of "Let's expose the crazy strings that we're asking visually impaired people to make sense of and see how everyone else likes it" has worked!
09:35 eeevil bah ... we gutted a lot of the original opensrf type registration magic :(
09:36 bshum dbs: Indeed, I suppose it has then.
09:37 * dbs gathers around the slide projector for a nice vacation Projected Medium show.
09:37 Dyrcona joined #evergreen
09:39 bshum So it seems like the coded-value gets drawn from unapi.mra
09:40 bshum And if we altered that function to use cvm.search_label instead of cvm.value
09:40 bshum It would display the search_label instead
09:40 bshum Though I'm unsure where that trickles down into issues
09:40 bshum I'm sure that variable gets used in a bunch o' places
09:41 bshum Also, the what if nobody sets up their coded value map to include search_label
09:41 dbs bshum: And each site would have to provide their own interpretation of what "Projected medium" means, right?
09:41 bshum dbs: True.
09:42 bshum I guess there's not an easy win in here
09:45 dbs Sounds kind of like we have to go deeper to figure out the 006/00 & 008/18-34 combos to come up with clear, meaningful terms for each possibility?
09:46 dbs Projected medium + short running time + audience = preschool + type = motion picture + technique = animation = Cartoon!
09:46 paxed isn't there an eg project that's going to do something like this?
09:47 paxed add original country = japan  => anime :P
09:47 eeevil paxed: there's a proposed project, yes
09:50 eeevil jeff: so, going back as far as JSON 2.23 (earliest CPAN-able JSON module, Sept 2010) there's a is_bool class function. it's also in both of the available JSON::XS modules. I think we should use that instead of testing the object directly, if it's a scalar ref. should do the right thing in any reasonable version
09:51 dbs So right now we have one icon that means exactly what the string says: "Projected medium" - which could be a magic lantern show, a set of slides, a filmstrip, a vhs tape, a dvd, a bluray, a laserdisc... we don't even use the 007 currently in figuring out what icon to display, IIRC
09:52 jeff urgh. i know i was up too late when AWS doesn't even want me to re-authenticate in the morning.
09:52 dbs I guess if the bulk of your collection is DVD movies, then change the string to "Movies, etc" or something like that?
09:53 bshum Our string is currently a generic "Video recording" which is slightly better sounding I guess.
09:54 jeff is it unusual to hear this text in the voice of Dr. Strangelove? "Improve your instance's security. Your security group, eg-pub-test, is open to the world."
09:54 dbs bshum: yeah, that sounds better to me :)
09:54 jeff "Why didn't you tell the WORLD?!"
09:57 dbs ah, the proposal eeevil mentions is http://list.georgialibraries.org/pipermail/​open-ils-general/2013-September/008961.html - right
09:57 jeff eeevil: looking at is_bool now. can't remember if i found a reason not to use it last night.
09:57 eeevil dbs: aye
09:58 eeevil jeff: we might want to set the required min version of JSON::XS as well...
10:00 BigRig joined #evergreen
10:00 eeevil jeff: for now, though, I've pushed working/user/miker/json_bool_api
10:01 * eeevil runs away for a bit
10:14 bshum MARC--
10:14 rfrasur @karma MARC
10:14 pinesol_green rfrasur: Karma for "MARC" has been increased 0 times and decreased 11 times for a total karma of -11.
10:15 Dyrcona MARC-- # because -11 is just not low enough
10:15 rfrasur truth
10:18 rfrasur We're going to have the best Dr. Who collection of any class C library in Indiana.  Just saying.  Doesn't hurt that half my employees are fans.
10:18 yboston joined #evergreen
10:20 dbs rfrasur++
10:20 rfrasur rfrasurs_staff++ #I just order the stuff.  They make the lists.
10:22 kmlussier paxed: Regarding that proposed project, we're having difficulty getting the funds we need. It may take a while before it becomes a reality.
10:23 * dbs is tempted to do something at the TPAC level, which could at least serve as a stop-gap measure in the short term, and possibility help work out kinks in the logic
10:24 dbs Wouldn't help with searching but at least display wouldn't be quite as crazy.
10:24 dbs (and would help with exposing structured data, naturally)
11:01 linuxhiker Dyrcona: the problem I spoke of yesterday is because of JSON::XS...
11:01 linuxhiker Dyrcona: Downporting to 2.34 versus 3.01 solves it
11:02 Dyrcona I gathered after reading (your?) email on the list.
11:02 linuxhiker Dyrcona: no that was probably Scott
11:03 Dyrcona Ok.
11:19 paxed kmlussier: unfortunately i don't work with evergreen anymore. so this is all on my own time.
11:19 rfrasur paxed, :-(
11:19 mjingle joined #evergreen
11:19 mjingle left #evergreen
11:20 kmlussier paxed: Yes, I was sorry to hear it. :(
11:22 paxed at least my contribs benefits others.
11:22 rfrasur paxed: and maybe you'll be part of another EG project in the future.  It could happen.
11:24 paxed the chances of that went down a bit; it's more likely the libraries in finland will start using Koha - assuming our project manages to make it work
11:24 rfrasur it's the translation issue?
11:25 paxed herd mentality
11:25 rfrasur or something broader than that?
11:25 rfrasur oh, lol.  well, I think that's the human condition.  we do tend to be sheeplike.
11:41 collum joined #evergreen
11:57 fparks joined #evergreen
12:01 dMiller__ joined #evergreen
12:03 smyers_ joined #evergreen
12:27 j_scott joined #evergreen
12:40 ldwhalen Does OpenSRF impose any limits to the number of calls that can be made by public requests?
12:40 ldwhalen e.g. is there an API limit of x calls per minute?
12:46 tsbere ldwhalen: There is a hard limit of "whatever your network connection and server can handle" - Beyond that, not really.
12:47 ldwhalen tsbere: thank you.
12:50 Dyrcona ldwhalen: Is there a particular problem that you are trying to solve or are you asking for informational purposes?
12:55 gmcharlt jeff: I've cobbled a branch together with eeevil's patch and a test case adjustment for lp1257264 that I think is ready for review, if you care to test
12:55 ldwhalen Dyrcona: another programmer asked me, and I did not know the answer.
12:56 Dyrcona ldwhalen: There are a lot of configurations for number of drones to run and how many requests a drone can process before it is recycled. While these don't lead to connection limits directly, if you set these too low, it will seem like you have a connection limit.
13:00 eeevil gmcharlt++
13:01 eeevil ldwhalen: well, the story is a little more nuanced ... there are ejabberd settings to rate-limit messages
13:04 ldwhalen eeevil: So, in the case of public calls I would be looking at the configurations for localhost.public?
13:04 ldwhalen or whatever the ejabberd public network is?
13:05 eeevil ldwhalen: yep. many setups use one ejabberd instance, of course
13:06 ldwhalen Dyrcona: and eeevil thanks for the information.  I will look into this further.
13:07 Dyrcona tsbere once considered running more than one ejabberd instance here, but ran out of tuits.
13:08 Dyrcona I think the last tuit is stuck to my desk via magnet.
13:08 bshum We used to run separate ejabberd on the heads of every brick for head/drones.
13:08 tsbere I didn't run out of tuits. My plans for test hardware fell through. ;)
13:09 Dyrcona heh
13:23 jeff gmcharlt: heh. your new branch and mine in-progress look very similar. this is probably good. :-)
13:24 jeff who needs test hardware when you have spot instances? ;-)
13:24 gmcharlt jeff: yeah, I think main difference is that my branch avoids any direct testing of JSON::{XS,PP}::Boolean
13:25 jeff yeah, mine also. i'll append my additional tests and sign off on what's there and if the tests don't seem ridiculous, great!
13:26 jeff also, if anyone hadn't seen it yet, google compute engine has gone General Availability, and supports neat things like freebsd: http://googlecloudplatform.blogspo​t.com/2013/12/google-compute-engin​e-is-now-generally-available.html
13:28 jeff gmcharlt: is it good/bad form to have use strict / use warnings in tests?
13:28 Dyrcona use Modern::Perl;
13:29 gmcharlt jeff: use strict & use warnings is always good form -- positively elegant, in fact
13:29 * Dyrcona should make hacker t-shirts and stickers.
13:29 tsbere jeff: I wanted to actually have real networking equipment in the mix >_>
13:30 Dyrcona tsbere: All those switches that we gave to the community college?
13:30 tsbere Dyrcona: Meh, one cheap-ass netgear switch. Just needed several machines plugged into it.
13:31 tsbere The "borrow several nearly identical machines to test with" aspect is what fell through on me
13:32 Dyrcona Yeah, not much homogeneity in our closet of broken toys.
13:57 kmlussier joined #evergreen
14:14 jboyer-isl joined #evergreen
14:25 sseng joined #evergreen
14:31 mjingle joined #evergreen
14:37 sseng joined #evergreen
14:41 jeff gmcharlt++ eeevil++ i think bug 1257264 is almost ready to die.
14:41 pinesol_green Launchpad bug 1257264 in OpenSRF "JSON::XS 3.0 changes the way booleans are represented" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1257264
14:45 jeff and if my tests don't make sense, feel free to leave that commit behind. :-)
14:48 kmlussier joined #evergreen
14:51 gmcharlt jeff: looks fine to me; I will push
14:51 jeff gmcharlt++ thanks!
14:54 pinesol_green [opensrf|Galen Charlton] LP#1257264: make test cases for JSON::XS Boolean-ness more generic - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=ff472c0>
14:54 pinesol_green [opensrf|Mike Rylander] LP#1257264: Use the built-in JSON-y test for bools - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=a5be2f1>
14:54 pinesol_green [opensrf|Jeff Godin] Add some additional boolean-related JSON tests - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=b93e0ca>
14:55 rfrasur joined #evergreen
14:57 gsams joined #evergreen
14:58 rfrasur berick: I have a question about a web-based staff client.  Does that mean it would open in a browser?  in other words, does that mean I could have the staff client in this or that tab and have email or whatever in another tab but only have one browser window open?
15:00 berick rfrasur: yes, it would ru[Cn in a browser, like any other web page (with some limitations on which browsers are supported)
15:00 berick rfrasur: https://bill-dev2.esilibrary.com/eg/staff/
15:00 rfrasur so, full support for opera?
15:01 kmlussier berick: Ooh! It's pretty.
15:01 berick chrome and firefox are the only browsers we've generally agreed to target
15:02 rfrasur yeah, agreed on those choices.  and mac people are okay with those?
15:02 berick rfrasur: as a (sometimes) mac person, I do ;)  I can't speak for everyone.
15:02 berick safari almost works, but there's something odd with the html5 routing -- possibly something that will be fixed soon.
15:03 berick in theory, safari should work fine
15:03 berick i tried opera not too long ago and IIRC, it worked OK too
15:03 berick kmlussier: thanks, bootstrap++ :)
15:04 berick most of that works, btw
15:04 berick feel free to poke at it
15:04 rfrasur Okay.  I mean, I personally couldn't care less.  just thinking for people that think diff than me.  and I know this is just getting started, but I see the workstation being optional.  Would this potentially use a cookie or something...or no?
15:04 berick that's what it's there for
15:04 berick workstation will not be optional (or likely not) in the long run
15:04 rfrasur oh good
15:04 berick it's only optoinal now for technical reasons
15:05 rfrasur gotcha
15:05 berick and yes, it could use a cookie, but we'll likely go with something a little more permanent
15:06 rfrasur well, I can just imagine deleting cookies as a maintenance step for the work station and then some staff member freaking out because they don't know the work station name or mistyping something or whatever.
15:06 berick exactly
15:06 berick i've had the workstation question come up more than once.. i should add a note to the log about that
15:07 rfrasur do you have a login credential that we can use to poke around a little?
15:07 berick (though, i think only devs read the log, since it's heavily code oriented)
15:07 rfrasur (should I already know this?)
15:08 berick rfrasur: admin / demo123 -- also, go here instead https://bill-dev2.esilibrary.co​m/eg/staff/login?ws=BR1-jupiter
15:08 berick that will populate the workstation for you
15:09 rfrasur (pretty)
15:11 rfrasur The implications of that are pretty awesome.
15:11 berick indeed
15:24 sseng joined #evergreen
15:25 paxed very pretty indeed.
15:25 smyers__ joined #evergreen
15:29 dbs while we're future-proofing for JSON::XS, maybe it's time to look at the Encode.pm bug 1242999 again?
15:29 pinesol_green Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] https://launchpad.net/bugs/1242999
15:46 Dyrcona joined #evergreen
16:00 kbeswick_ joined #evergreen
16:05 stevenyvr2 joined #evergreen
16:12 kmlussier joined #evergreen
16:25 dMiller__ joined #evergreen
16:37 jeff logs++
16:39 * dbwells thinks "they're better than bad, they're good!"
16:53 Dyrcona jeff: Provided you are not trying to diagnose a system freeze, and all you can find in syslog and kern.log for the time in question is an array of nul bytes.
16:54 jeff indeed.
16:54 Dyrcona jeff: When I left and came back around 15:40 EST, that's what happened.
16:54 jeff hopefully that isn't an indication of new laptop or server problems.
16:54 jeff doh.
16:54 jeff sorry to hear.
16:55 Dyrcona I had umounted a smb share in the Unity file manager (Nautilus, I guess) and then freeze.
17:02 jeff of course "encode" and "Encode.pm" pick up two different tickets.
17:02 kbeswick joined #evergreen
17:06 mmorgan left #evergreen
17:22 dMiller__ joined #evergreen
17:26 mjingle left #evergreen
17:31 ktomita joined #evergreen
17:43 dMiller___ joined #evergreen
17:50 stevenyvr2 joined #evergreen
17:53 sseng joined #evergreen
18:07 dcook joined #evergreen
18:16 Dyrcona joined #evergreen
18:25 smyers__ joined #evergreen
18:25 dMiller__ joined #evergreen
21:47 Dyrcona joined #evergreen
22:14 j_scott1 joined #evergreen
22:16 rangi` joined #evergreen
22:17 Callender_ joined #evergreen
22:19 gmcharlt joined #evergreen
22:22 kmlussier joined #evergreen
22:50 dac joined #evergreen
22:51 linuxhiker1 joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat