| Time |
Nick |
Message |
| 07:10 |
|
collum joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:48 |
|
mantis joined #evergreen |
| 09:55 |
|
sandbergja joined #evergreen |
| 10:54 |
|
sandbergja joined #evergreen |
| 11:29 |
csharp_ |
@band add Jargon Failure |
| 11:29 |
pinesol |
csharp_: Band 'Jargon Failure' added to list |
| 11:37 |
|
Christineb joined #evergreen |
| 14:22 |
mantis |
HI all just trying to understand this error that came up in our logs: open-ils.vandelay.bib_record.list.import: Use of uninitialized value within @_ in list assignment at /usr/local/share/perl/5.34.0/Open​ILS/Application/Cat/BibCommon.pm line 9 |
| 14:22 |
mantis |
*line 92 |
| 14:22 |
mantis |
when referencing this in the code, it stops after the sub biblio_record_xml_import within the perl script |
| 14:34 |
csharp_ |
mantis: @_ is a generic array variable that holds whatever is passed into the subroutine, so that subroutine is expecting an array with the values for each of the vars it's assigning to but one of them is undefined/uninitialized |
| 14:36 |
csharp_ |
mantis: you can add something like 'print "@_ \n";' to the beginning of the sub to see what's there - or $logger->info("MANTIS: \@_ is @_"); and it will come through in the info logs |
| 14:37 |
csharp_ |
(adding "MANTIS:" to have something easy to grep) |
| 14:50 |
mantis |
csharp++ |
| 14:56 |
csharp_ |
(adding that I dislike the use of @_ or $_ - its scalar version - in production code) |
| 14:56 |
csharp_ |
here it's pretty obvious what's happening - simple assignment, but some places in EG do things with the received and anonymous variables |
| 14:57 |
csharp_ |
troubleshooting in those cases is UnFun™ |
| 15:00 |
mantis |
we did trace it down to the call number it seems and the PO is stuck trying to activiate |
| 15:01 |
mantis |
the system says that it did import with a match but when one of our catalogers is trying to update the call number, the PO has a failure trying to write to the db |
| 15:01 |
mantis |
our cataloger would like to know if trying to activiate with more than half the line items that already generated is causing this issue since the system might see them as duplicates |
| 15:23 |
|
mantis left #evergreen |
| 16:35 |
jeff |
found the embedded maintenance counter in one of our checkin workstation receipt printers: 46.333 kilometers of paper have passed over the thermal head. |
| 16:35 |
csharp_ |
whoa |
| 16:38 |
eeevil |
jeff: that's nearly 29 freedom units! |
| 16:42 |
eeevil |
@later tell mantis if you change certain parts of where a PO puts items before they're received, IIRC, it can't find them anymore. I don't recall CN being an issue specifically, but I know if you move an acq item to a different (real EG) bib, stuff gets unhappy |
| 16:42 |
pinesol |
eeevil: The operation succeeded. |
| 17:02 |
|
mmorgan left #evergreen |
| 18:08 |
|
sandbergja joined #evergreen |
