| Time |
Nick |
Message |
| 00:49 |
|
Christineb joined #evergreen |
| 03:11 |
|
Mark__T joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:43 |
|
kmlussier joined #evergreen |
| 07:14 |
|
dcook__ joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
Callender_ joined #evergreen |
| 08:34 |
|
Dyrcona joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:11 |
Dyrcona |
Given the context of the surrounding code, this message makes no sense: Use of uninitialized value $filename in concatenation (.) or string at /usr/local/share/perl/5.14.2/OpenILS/Utils/RemoteAccount.pm line 619. |
| 09:12 |
Dyrcona |
There's a check for if ($@ or not filename) with a return in the if above that line. |
| 09:14 |
dbs |
is it because the initialization would happen in an eval block, if it does happen? |
| 09:15 |
dbs |
runtime or compile-time error? |
| 09:16 |
dbs |
I dunno. another meeting to prep for :( |
| 09:16 |
Dyrcona |
dbs: The assignment does happen in an eval block, but the if is outside the eval block, so if it was undefined outside of the eval, the if should still trigger. |
| 09:19 |
dbs |
maybe the "or not $filename" normally never gets tested because the error condition occurs and so evaluation of the if condition stops at $@ |
| 09:20 |
dbs |
and maybe now you're seeing a case where the return value is undefined, without an error occurring. |
| 09:20 |
dbs |
that _almost_ makes sense but then the "or not" should catch it! hah |
| 09:21 |
* dbs |
really goes into meeting prep mode |
| 09:22 |
Dyrcona |
dbs: I've tried replicating it with a smaller script, and I can't. |
| 09:22 |
Dyrcona |
Even running it on the server that runs edi_fetcher to use the same version of Perl. |
| 09:32 |
Dyrcona |
Oh, nice. This server is losing messages in rsyslog by the hundreds, so no wonder I can find neither success nor failure messages in the logs. |
| 09:32 |
|
yboston joined #evergreen |
| 09:37 |
|
maryj joined #evergreen |
| 10:00 |
Dyrcona |
Bingo! Line 177 of OpenILS/Application/Acq/EDI.pm. local_file is an IO::Scalar object. |
| 10:01 |
Dyrcona |
tsbere++ for suggesting that $filename is getting set to an object that stringifies as undef. |
| 10:03 |
tsbere |
I have run into that kind of thing before. |
| 10:03 |
tsbere |
Drove me nuts the first time I saw that happen too ;) |
| 10:08 |
jeff |
tsbere++ |
| 10:13 |
|
collum joined #evergreen |
| 10:22 |
Dyrcona |
heh. The manpage for IO::Scalar says that stringification works. It returns the content of the scalar. |
| 10:23 |
Dyrcona |
So guess we didn't get an error and we didn't retrieve a file, so the content of $filename is undefined. |
| 10:27 |
Dyrcona |
Weird. It's not like this is new code, either. |
| 10:40 |
Dyrcona |
So, I think there are two options for fixing this. |
| 10:41 |
Dyrcona |
1) Just delete $filename from the log output string. |
| 10:41 |
Dyrcona |
2) Add an if block to lock the same message, minus the local filename, when filename is a ref. |
| 10:41 |
Dyrcona |
s/lock/log/ |
| 10:42 |
Dyrcona |
I'm partial to #1. |
| 10:45 |
Dyrcona |
Guess I'll LP it and branch it. These emails every half hour are annoying. :) |
| 10:47 |
|
Christineb joined #evergreen |
| 10:53 |
|
sandbergja joined #evergreen |
| 10:54 |
Dyrcona |
No, maybe a different solution when $filename is a ref and it's contents are undefined. |
| 10:57 |
tsbere |
Dyrcona: my $logfilename = "$filename"; $logfilename = 'buffer' unless $logfilename; |
| 10:58 |
tsbere |
I know the first one needs adjusting, but I was too lazy to remember how to properly do the stringify directly. |
| 10:59 |
Dyrcona |
tsbere: In this case, we got an empty file or no content from the server without an error, so I think it would be a mistake to log a successful download, but that's a matter of opinion. |
| 11:02 |
Dyrcona |
Well, actually, a little playing on the command line indicates that I can't be sure if we did get something or not. |
| 11:03 |
Dyrcona |
Another option: $logilename = (ref $filename) ? $$filename : $filename; |
| 11:04 |
Dyrcona |
That would print *IO::Scalar::FH in this case. |
| 11:13 |
Dyrcona |
None of this is new code, either, so I wonder why I suddenly started seeing this in the past few days/weeks.... That's what makes me think it's retrieving an empty file or something like that. |
| 11:31 |
|
bmills joined #evergreen |
| 11:33 |
|
bmills1 joined #evergreen |
| 11:34 |
Dyrcona |
And this message leads me to say that we didn't get any content via FTP: |
| 11:34 |
Dyrcona |
Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.14.2/OpenILS/Application/Acq/EDI.pm line 187. |
| 11:34 |
Dyrcona |
So, this is likely caused by a busted EDI Account configuration which is why I've pretty much ignored it until now, but I'm not sure what to look for on that front. |
| 11:40 |
csharp |
usually a typo in the username/pass/remotedir |
| 11:41 |
csharp |
so annoying to fix, too |
| 11:41 |
csharp |
bug 1218423 is on my radar, but not this week :-) |
| 11:41 |
pinesol_green |
Launchpad bug 1218423 in Evergreen "Acq: Do we need a feature to resend EDI purchase orders?" [Wishlist,Triaged] https://launchpad.net/bugs/1218423 |
| 11:42 |
csharp |
of course, a fix to bug 863445 would help too |
| 11:42 |
pinesol_green |
Launchpad bug 863445 in Evergreen "Improve and harmonize logging in EDI scripts" [Wishlist,Triaged] https://launchpad.net/bugs/863445 |
| 11:46 |
|
brahmina joined #evergreen |
| 11:47 |
|
abowling joined #evergreen |
| 11:57 |
dbs |
tsbere++ |
| 11:57 |
dbs |
Dyrcona++ |
| 11:57 |
dbs |
perl+- |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:06 |
|
brahmina_ joined #evergreen |
| 13:40 |
|
collum_ joined #evergreen |
| 14:02 |
Dyrcona |
Hmm. Lots of fun stuff going on with RemoteAccount.pm, EDI.pm, Net::FTP..... |
| 14:03 |
Dyrcona |
It looks like the best solution is to add a helper function to RemoteAccount.pm to see if we got any data back. |
| 14:53 |
|
jihpringle joined #evergreen |
| 14:54 |
jeff |
Hrm. Time to think about multiple email addresses per patron for notification. |
| 14:56 |
Dyrcona |
He's just kidding you. No one has more than one email. |
| 14:56 |
jeff |
:-) |
| 14:56 |
jeff |
Many do, they just don't bother checking them all. ;-) |
| 14:57 |
|
jihpringle joined #evergreen |
| 14:57 |
tsbere |
jeff: My recommendation for that is "use one that you can configure to send messages matching patterns to other addresses" ;) |
| 14:57 |
tsbere |
Less EG development needed that way |
| 14:58 |
* tsbere |
supposes you could go with allowing them to put multiple addresses split by commas as well |
| 14:58 |
tsbere |
Just don't try and attach their name to the email address in the A/T templates |
| 15:03 |
jeff |
Oh, you assume these notifications are being generated by A/T. :-) |
| 15:05 |
jeff |
Environment is one where most patrons are batch loaded. Institution issues an email address, but some people check that address rarely and check a personal address more frequently (or exclusively). No real simple way to determine (or ask) which they prefer/use. |
| 15:05 |
jeff |
Thus, the idea of just putting both in place on the account and sending to both. |
| 15:07 |
tsbere |
Provided you aren't doing something like "Name <email>" then making the email on file "email1,email2" should work for most cases |
| 15:12 |
|
mmorgan1 joined #evergreen |
| 15:15 |
jeff |
trying to think if we'd care if it was one email sent to multiple addresses -- as opposed to one email per. |
| 15:17 |
tsbere |
outside of not wanting to reveal one email address to the other I don't see many issues there |
| 15:26 |
|
kmlussier joined #evergreen |
| 16:24 |
|
mmorgan1 joined #evergreen |
| 16:42 |
Dyrcona |
jeff: Can I remove your assignment on lp 1463943? |
| 16:42 |
pinesol_green |
Launchpad bug 1463943 in SIPServer "Non-ascii Unicode characters in messages cause SIP client problems" [Undecided,New] https://launchpad.net/bugs/1463943 - Assigned to Jeff Godin (jgodin) |
| 16:43 |
* Dyrcona |
had fun with different versions of the oils_sip.xml file making their way into production and one lacked the configuration for my little hack for that bug. |
| 16:43 |
Dyrcona |
So, now I feel motivated to fix it for real. |
| 16:44 |
|
mmorgan joined #evergreen |
| 16:45 |
jeff |
you can remove me, i may still have opinions. :-) |
| 16:46 |
Dyrcona |
heh. |
| 16:46 |
Dyrcona |
I always expect opinions. |
| 16:47 |
Dyrcona |
I plan to fix it so that clean_text is used more thoroughly, though IIRC you have a bug open to get rid of it? |
| 16:47 |
Dyrcona |
Do you think we should merge the two issues and fix them at the same time? |
| 16:48 |
Dyrcona |
Oh, yeah, it can crash. |
| 16:48 |
Dyrcona |
I'll see about fixing both of those at once. |
| 16:48 |
csharp |
anyone out there dealt with 3M selfchecks' offline/stored transactions feature? |
| 16:49 |
csharp |
we have a library that's having trouble with that and this is the first time I've known of a library in PINES trying to use it |
| 16:49 |
jeff |
csharp: just enough to know that i don't recommend using them without some additional development work to support their proper use. :-) |
| 16:49 |
csharp |
jeff: development work on the EG/SIPServer end? |
| 16:49 |
jeff |
da. |
| 16:49 |
csharp |
ok |
| 16:49 |
csharp |
thanks - that's really all I wanted to know :-) |
| 16:50 |
Dyrcona |
csharp: SIPServer does report that it does not support that mode. |
| 16:50 |
Dyrcona |
Well, unless you change the configuration, that is. ;) |
| 16:51 |
Dyrcona |
I vaguely recall hearing that 3M ignores that flag, though. |
| 16:51 |
Dyrcona |
tsbere might remember better than I do. |
| 16:51 |
jeff |
Dyrcona: i haven't looked at it in a week or more, but in general i support the idea of decoding/encoding in one place in sipserver -- which i think is similar to the approach koha took, and eliminates clean_text. |
| 16:52 |
csharp |
Dyrcona: oh, interesting |
| 16:52 |
tsbere |
I believe 3M has a "does the server support that" flag in most of their stuff that overrides what the server says |
| 16:52 |
Dyrcona |
csharp: That said, I don't recall anyone having issues with 3M self checks and offline mode. |
| 16:52 |
csharp |
well, the sample export file the library provided to me contains several garbage characters within barcodes, so there's that too |
| 16:53 |
Dyrcona |
jeff: OK. I can get behind doing it in SIPServer. I sometimes waffle on where the responsibility should lie. :) |
| 16:55 |
csharp |
I see, so offline=false in the sip config file is what tells them that, right? |
| 16:55 |
|
mmorgan joined #evergreen |
| 16:55 |
Dyrcona |
Hmm... I thought it was in, maybe it just sets that to false. |
| 16:55 |
Dyrcona |
Oh, duh..... I need to read better. :) |
| 16:55 |
Dyrcona |
yeah, it does. |
| 16:55 |
Dyrcona |
:) |
| 16:56 |
Dyrcona |
My brain turned "so" into "no" for some reason. |
| 16:56 |
* jeff |
gets the email from launchpad and laughs |
| 16:56 |
Dyrcona |
Well, I said I was waffling. :) |
| 16:56 |
jeff |
heh |
| 16:57 |
Dyrcona |
I wonder if I should just merge the two bugs as duplicates... I don't know any other way to link them in Launchpad. |
| 16:57 |
csharp |
huh - we have it set twice (one section probably ignored) <item name='offline operation' value='false'/> |
| 16:57 |
csharp |
within a <supports> section |
| 16:58 |
jeff |
i don't think that they're duplicates, but again -- haven't looked in a week or more. a comment referencing each other might be sufficient. |
| 16:58 |
jeff |
also, a bug can "affect" multiple projects. |
| 17:00 |
Dyrcona |
csharp: I think the supports section is actually used. |
| 17:01 |
Dyrcona |
I'd have to look at the code again to be sure. |
| 17:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:02 |
jeff |
supports and policy are different things. |
| 17:02 |
csharp |
well, either way, I indicated to the library that it's not supported and they'll just need to take them out of service when the connections aren't working (a separate issue on their end they are trying to resolve) |
| 17:03 |
* csharp |
once again broadcasts his wish to the universe that libraries would consult with us before purchasing things and expecting them to work based on sales pitches |
| 17:04 |
|
mmorgan left #evergreen |
| 17:41 |
dbs |
haha, jeff and Dyrcona, you and your clean_text circles make me laugh :) |
| 18:58 |
kmlussier |
@sortinghat |
| 18:58 |
pinesol_green |
Hmm... kmlussier... Let me see now... SLYTHERIN! |
