| Time |
Nick |
Message |
| 02:46 |
|
mtcarlson joined #evergreen |
| 04:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:42 |
|
berick_ joined #evergreen |
| 05:44 |
|
jeffdavi1 joined #evergreen |
| 05:44 |
|
jcamins_ joined #evergreen |
| 05:44 |
|
csharp_ joined #evergreen |
| 05:44 |
|
jboyer-isl joined #evergreen |
| 05:44 |
|
tsbere joined #evergreen |
| 05:50 |
|
jeff joined #evergreen |
| 05:50 |
|
jeff joined #evergreen |
| 08:03 |
|
akilsdonk joined #evergreen |
| 08:08 |
|
rjackson-isl joined #evergreen |
| 08:12 |
|
csharp joined #evergreen |
| 08:19 |
|
Dyrcona joined #evergreen |
| 08:25 |
|
mrpeters joined #evergreen |
| 08:27 |
|
ericar joined #evergreen |
| 08:29 |
|
collum joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:44 |
csharp |
hmmm - I'm seeing an issue with marc_export where I feed it a list of 30K bib ids, it processes around 400, then dies with "substr outside of string at /usr/share/perl5/MARC/Record.pm line 568." |
| 08:44 |
Dyrcona |
Bad MARC data. |
| 08:45 |
Dyrcona |
If it comes from MARC::Record, it's converting the record at that point. |
| 08:45 |
csharp |
interestingly, when I begin the next file at line 401 (for instance), it processes 400 more, then dies again |
| 08:45 |
csharp |
I'm having trouble isolating the source |
| 08:46 |
Dyrcona |
Well, I've never seen that and I regularly dump almost 1 billion bibs. |
| 08:46 |
|
mrpeters left #evergreen |
| 08:46 |
Dyrcona |
Oops. <dr_evil>1 milllleeeyun....</dr_evil> |
| 08:46 |
csharp |
Dyrcona: is there a simple way to output the record id that's currently being processed? |
| 08:46 |
csharp |
1 MILLION DOLLARS! |
| 08:47 |
Dyrcona |
A simple way? I don't think so. |
| 08:47 |
csharp |
ok - that's consistent with my reading of the marc_export code |
| 08:50 |
Dyrcona |
You might try outputting records as bre, but that bypasses the conversion to MARC. |
| 08:51 |
csharp |
I'm going to go brute force and import each id individually until I hit the bad record |
| 08:52 |
|
DPearl joined #evergreen |
| 08:52 |
|
mrpeters joined #evergreen |
| 08:53 |
Dyrcona |
You'd have to modify Marque::Biblio::next() to add a print STDERR $r->id() . "\n"; somewhere that makes sense. |
| 08:54 |
Dyrcona |
csharp: Or are you using the old one? |
| 08:55 |
phasefx |
csharp: just curious, are you leaving things as xml? |
| 08:55 |
Dyrcona |
Yeah, I was wondering about that, myself. It's probably blowing up around line 515. |
| 08:56 |
Dyrcona |
That's the call to MARC::Record->as_usmarc, and it's the one MARC::Record call not wrapped in an eval block. |
| 08:59 |
csharp |
Dyrcona: I'm using the new one |
| 08:59 |
csharp |
I'm outputting USMARC |
| 09:00 |
Dyrcona |
csharp: I'll post a patch that you could apply to your marc_export that should output the id of the failed records and continue exporting, unless you want the export to stop. |
| 09:00 |
csharp |
the crazy thing is that of my 34 files of 50K records, the last one of 38K is the only one to have any trouble |
| 09:01 |
csharp |
Dyrcona: that would rock - and yes it would be ideal to keep exporting after the error |
| 09:01 |
Dyrcona |
I find newer records are often "brief" records, and "brief" records tend to have issues. |
| 09:01 |
csharp |
ah |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:01 |
csharp |
that would explain that (probably) |
| 09:01 |
tsbere |
"issues" like "not being valid marc"? ;) |
| 09:01 |
csharp |
marc-- |
| 09:02 |
Dyrcona |
I don't know what you do in PINES, but here librarians often create brief records for new materials, and later central site catalogers overlay the brief records with fuller records from OCLC. |
| 09:02 |
csharp |
yes, that happens here too |
| 09:02 |
csharp |
I would imagine that is a likely cause of trouble |
| 09:04 |
|
yboston joined #evergreen |
| 09:06 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "marc_export_for_csharp.patch" (20 lines) at http://paste.evergreen-ils.org/13 |
| 09:07 |
Dyrcona |
That should just apply to marc_export in /openils/bin, like so: patch /openils/bin/marc_export marc_export_for_csharp.patch |
| 09:08 |
Dyrcona |
Also, if you think it is a good idea, file a Launchpad bug, and we can add that code as a permanent part of marc_export. |
| 09:08 |
bshum |
+1 that looks like it would be helpful. |
| 09:08 |
csharp |
thanks! |
| 09:13 |
* Dyrcona |
will make a branch anyway. |
| 09:14 |
csharp |
Dyrcona++ |
| 09:14 |
csharp |
yep, that gave me the record causing the trouble |
| 09:14 |
csharp |
LDR pam\a\ 00a |
| 09:18 |
Dyrcona |
I'll go ahead and file a bug, if you haven't already. |
| 09:20 |
csharp |
I haven't yet. I appreciate it! |
| 09:20 |
Dyrcona |
NP. |
| 09:21 |
* jeff |
yawns |
| 09:21 |
jeff |
morning! |
| 09:22 |
|
ericar left #evergreen |
| 09:32 |
Dyrcona |
csharp && bshum: lp 1350345 |
| 09:32 |
pinesol_green |
Launchpad bug 1350345 in Evergreen "marc export can blow up with bad records" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1350345 |
| 09:35 |
Dyrcona |
Hmm... I see that fix *may* be too simplistic because the Biblio exporter also handles sres and the error message won't distinguish between the two. |
| 09:36 |
Dyrcona |
Eh, "We'll fix it, later." ;) |
| 09:41 |
Dyrcona |
Heh, typoed my user name in the bug ticket. I should always copy and paste. ;) |
| 09:42 |
csharp |
Dyrcona++ # thanks |
| 09:43 |
kmlussier |
Heh...that's how I always wanted to spell your name when I first started. It just seemed right that the r should come after the d. |
| 09:47 |
jeff |
everyone's favorite coffee, Dry Kona |
| 09:47 |
kmlussier |
jeff++ |
| 09:50 |
Dyrcona |
heh. |
| 09:51 |
Dyrcona |
For those who don't know: Dyrcona is an anagram of Cyrano d., which de Bergerac used to sign many of his pamphlets and some of his longer polemics. |
| 09:53 |
kmlussier |
Ah, I had always wondered what the source of the name was. |
| 09:54 |
phasefx |
I always read it like Dire Cona, which makes me think of a Dire Wolf :-) |
| 09:55 |
Dyrcona |
Dire Kona: the coffee that bites back! |
| 09:55 |
kmlussier |
In the timbers of Fennario the wolves are running round |
| 09:56 |
jeff |
@coffee |
| 09:56 |
* pinesol_green |
brews and pours a cup of Tres Santos Micro-Lot La Dorada Cauca, and sends it sliding down the bar to jeff |
| 09:56 |
Dyrcona |
Dire Badger attacks! Dire Badger misses! |
| 09:57 |
Dyrcona |
phasefx attacks! phasefx misses! |
| 09:57 |
jeff |
that sounds much more interesting than the officially licensed (special DRM and everything) k-cup I'm about to shove in the machine |
| 09:57 |
phasefx |
:D |
| 09:57 |
phasefx |
@roll |
| 09:57 |
pinesol_green |
phasefx: Fire BAD! Reading GOOD! |
| 09:58 |
|
mllewellyn joined #evergreen |
| 09:58 |
jeff |
@dice 1d20 |
| 09:58 |
pinesol_green |
jeff: 13 |
| 09:59 |
jeff |
@dice 10d1000000 |
| 09:59 |
pinesol_green |
jeff: Error: You can't roll more than 6 dice. |
| 09:59 |
jeff |
@dice 6d1666666 |
| 09:59 |
pinesol_green |
jeff: Error: Dice can't have more than 100 sides. |
| 10:00 |
Dyrcona |
I guess pinesol_green's hands aren't big enough, or the dice aren't small enough. :) |
| 10:00 |
jeff |
@dice 6d100 |
| 10:00 |
pinesol_green |
jeff: 18, 14, 50, 11, 37, and 42 |
| 10:00 |
phasefx |
wonder if it can do exploding dice |
| 10:00 |
Dyrcona |
Well, I got interrupted and didn't finish my story. |
| 10:00 |
Dyrcona |
Oh well, we'll never if the Dire Badger gives phasefx rabies or not. :) |
| 10:00 |
Dyrcona |
know, even. |
| 10:01 |
* phasefx |
won't even look for that chart |
| 10:01 |
Dyrcona |
Heh... I should write up Wereweasels...just because. |
| 10:02 |
csharp |
@dnd |
| 10:02 |
pinesol_green |
csharp: strength:11 dexterity:12 constitution:12 intelligence:14 wisdom:13 charisma:16 |
| 10:03 |
jeff |
there must be a name for those "features of the moment" where a specific problem leads to a specific feature idea that may or may not have any actual use 99.999% of the time. |
| 10:04 |
phasefx |
bell |
| 10:04 |
phasefx |
or maybe whistle |
| 10:05 |
jeff |
specific example: emphasize the area code in a phone number when the area code is not the local area code. use case: it's easy to get in the habit of skipping the area code entirely because often it is the local area code and does not need to be dialed. |
| 10:05 |
kmlussier |
@librarian |
| 10:05 |
pinesol_green |
kmlussier: Management:15, Cataloging:7, Acquisitions:8, Reference:12, Circulation:15, Systems:12, Research:12, Custodial:14 |
| 10:05 |
Dyrcona |
actually that sounds useful for most of the country where you don't have to dial the area code first. |
| 10:06 |
|
jwoodard joined #evergreen |
| 10:06 |
Dyrcona |
In Mass, we do have to dial the area code, even for local calls. |
| 10:07 |
jeff |
and for our SIP phones, they all use ten digit dialing behind the scenes, with a single default area code pre-pended for seven digit dials |
| 10:07 |
jeff |
so there's no situation where you'd omit the local area code and be wrong, because you forgot that it's local toll. |
| 10:07 |
Dyrcona |
Yeah, was thinking of VOIP and cell phones, too. |
| 10:08 |
Dyrcona |
Well, its fun when someone else in your area code is "outside your calling area" and you forget. |
| 10:08 |
Dyrcona |
"You must dial 1 for numbers outside your calling area." |
| 10:08 |
jeff |
just something that randomly came to mind as i was assisting with the investigation of a problem report of "we keep calling this person" :-) |
| 10:08 |
Dyrcona |
Um, hello, I dialed the area code, that should be enough. |
| 10:09 |
Dyrcona |
legacy_technology-- |
| 10:09 |
Dyrcona |
jeff++ |
| 10:09 |
jeff |
issue appears to be that staff dialed the local area code (231) when the patron they were trying to reach was actually a downstate area code (313) |
| 10:09 |
kmlussier |
Dyrcona: I've just gotten in the habit of dialing 1 for all numbers so that I don't have to worry about local calling areas anymore. |
| 10:10 |
Dyrcona |
kmlussier: I typically use my cell phone, so I don't worry about 1. :) |
| 10:10 |
jeff |
i've gotten in the habit of ten digit dialing with cell phones, but sometimes mistakenly omit the one when dialing a toll free number on the SIP phone on my desk. |
| 10:11 |
jeff |
dialing ESI's number that way leads to a very odd sounding system. |
| 10:14 |
jeff |
pressing digits for 877-675-6457 (and forgetting the leading 1) gets truncated to 877-6736 which then gets the local 231 area code prefixed, and I am connected to 1-231-877-6736 which appears to be a find-me/follow-me number that passes through at least two different generic voice recordings |
| 10:16 |
tsbere |
jeff: I suppose I should feel lucky that our phones don't require the 1 <_< |
| 10:21 |
jeff |
i'm pretty sure we could adjust the dial plan if we cared to. |
| 10:21 |
jeff |
i'm just happy we no longer need to dial 9,0, to get out. |
| 10:21 |
|
Shae joined #evergreen |
| 10:24 |
Dyrcona |
"Jenny! I've got your number..." |
| 10:25 |
|
kmlussier1 joined #evergreen |
| 10:50 |
kmlussier |
Just a reminder to fill out the Doodle poll for bug squashing day - http://doodle.com/6ush6hyx9pa39pv3 |
| 10:53 |
berick |
well, now we have more reason to port the existing HTML staff code to angular/websockets... working on some ACQ stuff, Firefox just warned, "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/" |
| 10:53 |
* berick |
feels somewhat vindicated in his dislike of synchronous ajax |
| 11:07 |
|
RoganH joined #evergreen |
| 11:11 |
RoganH |
If you're going to the hack-a-way please respond here : https://www.surveymonkey.com/s/C9W2Y5W so I can get a room count. |
| 11:12 |
berick |
RoganH: that's the same survey from before, correct? |
| 11:13 |
Dyrcona |
I always thought they have gone with extra-strengh tide instead of ajax, but whatever. ;) |
| 11:13 |
berick |
iow, no need to re-do |
| 11:13 |
RoganH |
berick: yep, just reposting for stragglers |
| 11:13 |
berick |
k |
| 11:13 |
csharp |
berick asked my question ;-) |
| 11:14 |
Dyrcona |
I'll have to talk with tsbere about who is going. He should probably go this time, since I went last time. |
| 11:15 |
Dyrcona |
I could always participate via hangout. |
| 11:16 |
RoganH |
Drycona: send him! |
| 11:21 |
|
mllewellyn1 joined #evergreen |
| 11:22 |
|
mrpeters left #evergreen |
| 11:54 |
jeff |
Hrm. I should find out if I'm going to the hack-a-way. |
| 11:55 |
|
gsams joined #evergreen |
| 11:56 |
RoganH |
jeff: The more the merrier. |
| 12:04 |
|
ericar joined #evergreen |
| 12:11 |
* dbs |
assumes the ESI easter eggs have long since disappeared from the voice mail system |
| 12:17 |
|
ericar left #evergreen |
| 12:42 |
|
dcook__ joined #evergreen |
| 12:43 |
|
jeffdavis joined #evergreen |
| 12:47 |
jeff |
dbs: you know what happens when you assume, right? you end up getting a call from our systems with the following audio: https://soundcloud.com/jefej/courtesy :-) |
| 12:54 |
* graced |
makes a mental note to reapply easter eggs to voice mail system |
| 12:54 |
phasefx |
jeff++ |
| 13:06 |
jeff |
_bott_++ for the original idea of using the Mac voices as output by the "say" command |
| 13:06 |
jeff |
That is not our courtesy call script, I modified it quite a bit to make it fit the tone of the voice. :-) |
| 13:07 |
jeff |
That's the voice "cellos". |
| 13:13 |
|
mtcarlson joined #evergreen |
| 13:14 |
jeff |
and this is "good news": https://soundcloud.com/jefej/courtesy-good-news |
| 13:26 |
csharp |
jeff++ |
| 13:27 |
jeff |
little annoying how soundcloud tries to start playing "related" tracks after those are done... they're apparently only related to themselves. |
| 13:44 |
|
hbrennan joined #evergreen |
| 13:44 |
|
jwoodard joined #evergreen |
| 13:48 |
|
tsbere joined #evergreen |
| 14:27 |
|
mtcarlson joined #evergreen |
| 14:28 |
|
vlewis joined #evergreen |
| 14:45 |
|
ktomita joined #evergreen |
| 14:46 |
bshum |
800x600? pfft! |
| 14:47 |
kmlussier |
Is the staff client generally usable at that screen resolution? |
| 14:47 |
bshum |
No |
| 14:47 |
bshum |
Generally I don't agree to support anything less than 1024x768 in my consortium. But that's just our practices here. |
| 14:48 |
jeff |
"responsive XUL" isn't really a thing. |
| 14:49 |
Dyrcona |
It's not really usable at less than 1920x1080, cause some wider screens don't get horizontal scroll bars when they should. |
| 14:49 |
csharp |
trying to install/test the web client, but it looks like I'm missing something |
| 14:49 |
bshum |
@quote add <jeff> "responsive XUL" isn't really a thing. |
| 14:49 |
pinesol_green |
bshum: The operation succeeded. Quote #87 added. |
| 14:49 |
Dyrcona |
I'm looking at you Item Status. |
| 14:49 |
csharp |
File does not exist: /openils/var/web/js/dojo/opensrf/opensrf_ws.js |
| 14:49 |
kmlussier |
We should probably add something to http://docs.evergreen-ils.org/2.6/_staff_client_requirements.html with minimum requirements for screen resolution. |
| 14:49 |
bshum |
Dyrcona: Agreed, Item Status is screwy at lower resolutions :( |
| 14:49 |
csharp |
berick: any ideas about why that file^^ wouldn't exist? |
| 14:50 |
kmlussier |
I also question the 512 MB of RAM in those minimum requirements. |
| 14:50 |
bshum |
That's definitely wrong. |
| 14:50 |
berick |
csharp: opensrf -> websockets branch |
| 14:50 |
* csharp |
looks for clues as to what bshum kmlussier jeff and Dyrcona are referring to ;-) |
| 14:51 |
csharp |
berick: ah.... |
| 14:51 |
csharp |
ok - thanks |
| 14:51 |
berick |
yeah, gotta get that all setup first |
| 14:51 |
jeff |
bug 1350488 |
| 14:51 |
pinesol_green |
Launchpad bug 1350488 in Evergreen "With a Screen Resolution of 800 x 600, Users Cannot Create or Save Custom Toolbars" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1350488 |
| 14:51 |
csharp |
jeff: thanks ;-) |
| 14:51 |
csharp |
holy frijoles |
| 14:52 |
csharp |
I understand lack of funds in libraries, but I think you reach a point where you say you've got to upgrade your hardware :-/ |
| 14:53 |
Dyrcona |
csharp: It's often a lack of eyesight, not funds. |
| 14:53 |
bshum |
kmlussier: I think idle starting footprint for the Evergreen client is more like 900 MB or so |
| 14:53 |
Dyrcona |
At 800x600 on a larger monitor stuff looks bigger. |
| 14:53 |
bshum |
I'd have to refer back to all the testing notes that was done during the memory leak. |
| 14:53 |
csharp |
whew - that's bad |
| 14:53 |
kmlussier |
But we also have options for increasing font size. |
| 14:54 |
csharp |
it's a bad workaround |
| 14:54 |
Dyrcona |
It's not just font size. |
| 14:54 |
Dyrcona |
Our members' staff have consistently used 1024x768 on all of our ILS and most workstations. |
| 14:55 |
Dyrcona |
However, I have found Item Status to be not completely usable at even 720p. |
| 14:55 |
Dyrcona |
Never bugged it though. |
| 14:56 |
* Dyrcona |
knows less about what members' staff are doing today. |
| 14:56 |
dbs |
Man. I thought our 1024x768 adherents were dragging things down |
| 14:57 |
dbs |
Responsive xul actually can be a thing... |
| 14:57 |
jeff |
1366x768 is my usual working resolution (hooray mobility!), but i often have a second display at 1920x1200 |
| 14:58 |
jeff |
and of course, i'm non-typical. |
| 14:59 |
eeevil |
jeff: according to my sample size of n=2, you are exactly typical |
| 14:59 |
jeff |
eeevil++ |
| 15:06 |
kmlussier |
I use 1600x900. I just changed it to 800x600, and the staff client is technically usable if you don't mind a lot of horizontal scrolling and limiting yourself to about 6 toolbar buttons. |
| 15:08 |
kmlussier |
Can't really use the generate password button in the patron editor, though. |
| 15:10 |
csharp |
I would imagine any of the dojo interfaces would be useless at that resolution |
| 15:11 |
kmlussier |
I don't know. The only dojo screen I checked was patron registration, Then I had to put things back to normal. I was feeling claustrophobic. |
| 15:21 |
kmlussier |
So here's a question. If dojo interfaces don't perform well at that resolution and if we're porting dojo interfaces to the web client, will they fit in with the responsive design goals for the project? |
| 15:22 |
bshum |
That is a good question. |
| 15:22 |
bshum |
I was on the fence with the first bug since it was directed at XUL interfaces and my feeling was to mark it as "won't fix" (aka, not meeting project plans with the web client in mind) |
| 15:22 |
bshum |
But for dojo stuff... hmm |
| 15:22 |
bshum |
That seems like a legitimate concern. |
| 15:22 |
eeevil |
kmlussier: well, we're only porting them to the web client so we can actually have a web client. it's not that they shouldn't be addressed at some point in the future |
| 15:23 |
kmlussier |
Sure, but I thought building screens responsively was part of the project plan. |
| 15:23 |
eeevil |
it is, for those that /absolutely can't work/ in a browser |
| 15:24 |
eeevil |
it's a choice between rewriting 30-40% of the staff client, or all of it |
| 15:24 |
eeevil |
for the "make a web client exist" phase |
| 15:25 |
kmlussier |
Another thing I was wondering about (not needling, it's just been a question I haven't had time to send to the list yet) is whether the dojo interfaces is part of the websockets work. IOW, will those interfaces be making calls the same way they always have? |
| 15:27 |
* Dyrcona |
hopes Dojo is going away with the adoption of Angular. |
| 15:27 |
eeevil |
that, I don't know. I would assume they'll use XHR for now, since many depend on sync mode, which is impossible with websockets. maybe async calls can be transparently handled via websockets, but I haven't personally attempted |
| 15:28 |
berick |
as of right now, the Dojo interfaces will continue to operate as they always have |
| 15:29 |
kmlussier |
OK, I was just wondering because, as you know from the e-mail discussion a few weeks back, we've had complaints with performance for loading the patron editor. Since our libraries know that performance is one of the reasons we're moving to the web client, I think they'll be disappointed if it's still loading slowly. |
| 15:30 |
csharp |
kmlussier: that was because of the large number of stat cats in use, right? |
| 15:30 |
csharp |
s/was/is/ |
| 15:31 |
kmlussier |
I don't know. tspindler said he got rid of all of his unnecessary stat cats, but it didn't make a huge difference. |
| 15:31 |
csharp |
that seemed to be the factor when krmvga and I were comparing a couple weeks back |
| 15:31 |
csharp |
it loads fine for us, but we barely use patron stat cats |
| 15:33 |
eeevil |
kmlussier: another thing to remember is that, while anecdotal, /everything/ seems to run faster (dojo included) in chrome than in xulrunner, because of the different js engine. again, anecdotal, but something that folks should also look into testing |
| 15:33 |
berick |
eeevil: good point |
| 15:33 |
csharp |
yeah - we tested chrome and firefox |
| 15:33 |
tsbere |
I think another issue was number of permission groups that the permission to edit had to be checked for |
| 15:33 |
csharp |
both were *way* faster, especially chrome |
| 15:34 |
|
tspindler joined #evergreen |
| 15:34 |
eeevil |
tsbere: see: my pcrud patch that's in 2.7 :) |
| 15:34 |
berick |
some of the pcrud changes in 2.7 may help as well (avoiding unnecessary perm checks) -- just a theory at this point, though |
| 15:34 |
berick |
heh, jinx |
| 15:35 |
tsbere |
eeevil: Your pcrud patch changes the "do you have permission to add someone to this permission group?" check when populating that dropdown? |
| 15:35 |
berick |
i don't think it will affect that |
| 15:35 |
eeevil |
I know everyone (except me) hates dojo, but it's far from the lone (or biggest) bottleneck we've managed to make heavy use of |
| 15:35 |
berick |
more the auto-field-widget selectors |
| 15:35 |
tsbere |
I think the more groups you have, and thus the more permissions to potentially check for those groups, the longer it takes to populate the permission group dropdown. |
| 15:36 |
eeevil |
tsbere: mmmm... it (can) remove object-user perm checks, so yes, it could make that faster |
| 15:36 |
eeevil |
I'd have to look at the details of that call in particular to predict for realz, though |
| 15:38 |
kmlussier |
eeevil/berick: Yeah, I was hoping that just switching from xul to a browser would help, so I'll keep my fingers crossed for that. I just loaded the interface on berick's server, and it took about 10 seconds on the first try. Afterwards, it was more like 3 or 4 seconds. |
| 15:38 |
* kmlussier |
is counting on her fingers, so those numbers may not be entirely accurate. |
| 15:38 |
eeevil |
tsbere: ah... well, now that I think harder, is that a pcrud call, or a loop over cstore json_query's? the latter won't be sped up, no |
| 15:39 |
tsbere |
eeevil: Load all pgt objects, extract any perms from them, call user has work perm at batch variant, then loop over things to check for failed perms |
| 15:40 |
berick |
tsbere: but it's just the one API call? |
| 15:40 |
* jeff |
yawns |
| 15:40 |
berick |
jeff++ |
| 15:40 |
berick |
just cuz |
| 15:40 |
jeff |
heh |
| 15:40 |
jeff |
old habit |
| 15:40 |
tsbere |
berick: That is the workflow of the javascript in register.js file. As in client-side. |
| 15:40 |
berick |
kmlussier: and that's different data, too, so not a wholly accurate test. |
| 15:41 |
berick |
tsbere: gotcha. do you think that API call takes too long or processing the results? |
| 15:42 |
kmlussier |
berick: Sure, not that the code is in LP, I think we'll look at loading it with some production data. But it still won't be the same data, so it may not be the best test either. |
| 15:42 |
kmlussier |
That is, now that the code is in LP. |
| 15:42 |
tsbere |
berick: Unless the has_work_perm_at.batch function filters dupes I imagine we are getting a backend dance for each permission group with a perm attached, instead of for each permission (I haven't checked the actor code to see though). Other than that massive playing with the tree of permissions may slow down things when there are a lot of them. |
| 15:43 |
phasefx |
semi-related aside, the xul side of things used to share data with the patron editor to save some network requests, but I don't think that is any longer the case |
| 15:43 |
berick |
kmlussier: another test.. you can go to .. https://YOUR-DOMAIN/eg/actor/user/register |
| 15:44 |
berick |
tsbere: gotcha, yeah, not sure about the api |
| 15:44 |
tsbere |
berick: Actually, now having looked at Actor.pm, it doesn't look like it filters dupes. So if you have 50 groups that use the same permission I think we verify that permission 50 times, instead of just once. Not sure which end we should be filtering it on, though. |
| 15:44 |
|
Shae joined #evergreen |
| 15:44 |
* tsbere |
suspects the backend is a good place though |
| 15:44 |
berick |
tsbere: ohhh, well, that's something. i'd favor filtering on both, but at minimum on the server |
| 15:46 |
tsbere |
not sure how to best do that in perl before the map call, though |
| 15:50 |
|
mtcarlson joined #evergreen |
| 16:09 |
Dyrcona |
On the screen resolution LP bugs, I'm thinking "won't fix" because of the web staff client. |
| 16:10 |
kmlussier |
Dyrcona: I think bshum made a good point on the patron registration editor bug still being relevant since we're porting that interface to the web client. |
| 16:11 |
Dyrcona |
kmlussier: In the web staff client, scrolling will be up to the browser an not controlled by staff client code. |
| 16:11 |
* kmlussier |
checks. |
| 16:13 |
Dyrcona |
The overlap *should* be a non-issue in a proper scroll pane. |
| 16:13 |
kmlussier |
I think it's still an issue in the web client. Buttons are overlapping on form fields. |
| 16:14 |
Dyrcona |
@blame Dojo |
| 16:14 |
pinesol_green |
Dyrcona: Dojo stole bradl's tux doll! |
| 16:16 |
kmlussier |
This is what the web client patron registration form looks like at 800x600 http://www.screencast.com/t/D66vWhIhG |
| 16:16 |
kmlussier |
If we were sticking with xul, we could reasonably argue that 800x600 isn't supported, but since we're shooting for responsive design, I don't think we can make that argument for the web client. |
| 16:18 |
|
Shae_ joined #evergreen |
| 16:18 |
berick |
kmlussier: i'm curious, is that w/ the patron summary minimized? |
| 16:18 |
tsbere |
kmlussier: Why can't we say 800x600 isn't supported for the staff side of things? |
| 16:19 |
tsbere |
berick: I think that is outside of any wrapper (and is a new patron view anyway, so there isn't a summary) |
| 16:19 |
kmlussier |
berick: Yes |
| 16:19 |
berick |
tsbere: there wrapper's there along the top, but point taken re: new patron |
| 16:19 |
berick |
ok, that's full screen, essentially |
| 16:20 |
kmlussier |
tsbere: Because one of the stated goals of the web client project was to be responsive. For example, people may want to bring a tablet to an offsite "get a library card" event. |
| 16:21 |
kmlussier |
tsbere: And even though the Dojo interfaces won't be responsive immediately, I think it's a goal we should keep in mind. |
| 16:21 |
tsbere |
kmlussier: Let me re-phrase that, then. Since when does "responsive" mean "we have no minimum requirements"? :P |
| 16:22 |
kmlussier |
OK, so it's only responsive if you use a resolution that's higher than 800x600? It kind of defeats the purpose IMO. |
| 16:24 |
tsbere |
kmlussier: I have a number of "responsive" sites that I visit for a number of different things that have entire areas of the site, if not the whole site, that don't work at below 1024 pixels wide, resulting in fairly annoying scrolling. They do, however, provide a much nicer interface if you have a wider screen. Still responsive, but with a minimum width. |
| 16:25 |
kmlussier |
tsbere: OK, well I personally think we should be aiming higher and supporting mobile where we can, even for staff tasks. |
| 16:26 |
* mmorgan |
agrees with kmlusser |
| 16:28 |
mmorgan |
Our library staff members want to be mobile with all sizes of devices, providing all levels of service |
| 16:28 |
berick |
the disconnect here may be that even iphone 4's had higher resolution than 800 x 600. |
| 16:28 |
Dyrcona |
berick++ |
| 16:28 |
berick |
800 x 600 is really low and probably off most people's radar under normal circumstances |
| 16:29 |
Dyrcona |
800x600 is like some 20 year old PC monitor. |
| 16:29 |
* tsbere |
just checked, and his tablet is a minimum of 800 pixels wide, and that is in portrait mode. In landscape mode it is 1280. |
| 16:30 |
berick |
i'm not arguing against anything, necessarily, i'm just not surprised it's cumbersome at that level |
| 16:31 |
berick |
porting the dojo UI's to bootstrap would almost certainly help |
| 16:31 |
berick |
or making an effort to mobilzie the dojo css |
| 16:31 |
berick |
kmlussier: have you looked at the other browser staff UI's at that level? |
| 16:31 |
berick |
i'm assuming the flow OK. not perfect by any means, but not overlapping, etc? |
| 16:33 |
berick |
s/the/they/ |
| 16:33 |
berick |
they flow on my phone OK, but this freakin' nexus is 1280x768 |
| 16:38 |
eeevil |
fwiw, the overlap there is not dojo's fault, it's simply suboptimal layout |
| 16:38 |
kmlussier |
Sorry, I just walked away to test on my son's phone. It's overlapping there. The phone is a few years old, but it's there. |
| 16:39 |
kmlussier |
berick: No, I haven't looked at much at that level. I try to stay away from 800x600 when I can. :) |
| 16:39 |
berick |
eeevil: yeah, dojo is def. not to blame for a lot of stuff we're throwing around. at this point, I think "dojo" really just means "those interfaces" |
| 16:39 |
berick |
kmlussier: i hear ya |
| 16:41 |
eeevil |
berick: I understand. I want to make sure it's clear that making the pages flow better is not necessarily dependent upon completely replacing them with alternate implementations. and could be done by anyone, not just you, without harming the browser-client target, as long things like element ids and classes don't get blown away |
| 16:42 |
eeevil |
(more or less) |
| 16:42 |
berick |
eeevil: absolutely. that's good to reiterate |
| 16:42 |
|
tspindler left #evergreen |
| 16:43 |
eeevil |
if someone feels like removing floats and tables and moving the /containers/ to divs and whatnot, that should not have an impact on the logic (ideally ... testing would tell, obv) |
| 16:48 |
kmlussier |
eeevil: Sure, I understand that. I was just trying to make the point that it might not be a bad idea to keep that specific bug open. |
| 16:49 |
kmlussier |
If anyone's interested, this is what the patron registration screen looked like on my son's phone. http://www.screencast.com/t/GaEAqcYw |
| 16:49 |
eeevil |
kmlussier: I agree with keeping it open |
| 16:51 |
dbwells |
Just reading backscroll, and thought I should chime in to say that I don't believe making the staff client 100% responsive is a reasonable or wise goal. For some interfaces, it absolutely makes sense, but for others, I think responsive design can lead to unnecessary compromises. |
| 16:56 |
dbwells |
I should also add that this statement is from the perspective of realistically available resources, and is not meant to apply to what would be ideal or technically possible. |
| 16:57 |
|
dMiller__ joined #evergreen |
| 16:58 |
hopkinsju |
csharp: Yesterday you mentioned "password is also available in that same stgu source" I see that the stgu class includes 'passwd' but adding that to my template does not produce the field. |
| 16:59 |
hopkinsju |
Since I don't really understand what I'm working with here, I also tried adding passwd from the au class |
| 17:00 |
hopkinsju |
Also no effect |
| 17:12 |
|
mmorgan left #evergreen |
| 17:13 |
jeff |
i don't know one way or the other if there's a means by which you can easily add that field to a form, but unless there are existing mechanisms for special treatment of that field that are new from the last time I looked at the staging APIs, i would caution against making use of the password field for staged users, as you'll end up storing visible patron passwords in cleartext. |
| 17:13 |
jeff |
and "visible" in the sense that they are displayed as a column in the staff Pending Patrons display |
| 17:15 |
jeff |
I would support enhancements to enable safer staging of patron passwords, as I like that better than "here is your four digit initial password" and "please speak a password to me here at the circ desk for all to hear" (hopefully nobody does this), etc. |
| 17:21 |
hopkinsju |
jeff: I agree with what you're saying for sure, and I wasn't aware of the plaintext storage issue with staging users. |
| 17:47 |
|
mtcarlson joined #evergreen |
| 18:12 |
|
RoganH joined #evergreen |
| 18:44 |
|
mtcarlson joined #evergreen |
| 18:58 |
|
frank____ joined #evergreen |
| 19:01 |
frank____ |
Hi all, I have a question, Does someone know why when I run the command cat /home/opensrf/recordsBabelExportar30Julio14.txt | ./marc_export -i -c /openils/conf/opensrf_core.xml -e UTF8 -x /openils/conf/fm_IDL.xml -f USMARC --timeout 5 > /home/opensrf/exported_files14Julio14SummonUpdate.mrc, it doesnt export the e-books records? |
| 20:47 |
|
jeff joined #evergreen |
| 20:55 |
|
ldw joined #evergreen |
