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.blogspot.com/2013/12/google-compute-engine-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.com/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 |