| 02:20 |
|
alynn26_away joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl_hom joined #evergreen |
| 07:50 |
|
rfrasur joined #evergreen |
| 07:54 |
|
eady joined #evergreen |
| 10:19 |
mantis |
jeff: Were those carousels manually made? |
| 10:19 |
jeff |
i haven't looked at how carousels are implemented in Evergreen to know how simple it might be. |
| 10:19 |
mantis |
We have a sql we use to create an automated one |
| 10:19 |
* jeff |
nods |
| 10:19 |
jeff |
we have a bunch that are based on lists, and a bunch that are based on canned searches. |
| 10:20 |
jeff |
they all have their images tested by a recurring task, and the carousels displayed to users omit any without an image. |
| 10:21 |
jeff |
i'd have to do some looking to see how difficult it would be to adapt the technique to Evergreen. |
| 10:21 |
jeff |
your issue is that you're creating them automatically, and of course without a human reviewing the items, you don't have the chance to omit (or upload local images for) records that lack images? |
| 10:22 |
jeff |
and you don't want placeholder images or broken images, and the carousel isn't able to exclude them at display time? |
| 10:25 |
mantis |
jeff: Yeah that's basically it |
| 10:26 |
mantis |
We don't want to get rid of the automated carousel implemented just because it works so well, but every now and then you get records without images |
| 10:26 |
mantis |
I understand the image is tied to the ISBN or UPC so that might make this impossible to filter for automated buckets |
| 17:21 |
|
mmorgan left #evergreen |
| 17:23 |
|
jvwoolf left #evergreen |
| 17:36 |
|
Bmagic joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:08 |
|
tsadok joined #evergreen |
| 23:18 |
|
sandbergja joined #evergreen |
| 00:01 |
|
sandbergja joined #evergreen |
| 00:13 |
|
sandbergja joined #evergreen |
| 00:51 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl_hom joined #evergreen |
| 08:04 |
|
Dyrcona joined #evergreen |
| 08:09 |
|
collum joined #evergreen |
| 13:14 |
|
jvwoolf joined #evergreen |
| 13:47 |
|
rjackson_isl_hom joined #evergreen |
| 14:10 |
rfrasur |
bmagic++ |
| 14:58 |
mmorgan |
I'm unable to load records through vandelay on some local test/training systems, the only error I can find is this: |
| 14:58 |
mmorgan |
[2021-04-29 11:50:04] open-ils.vandelay [ERR :33994:Vandelay.pm:272:16197113152449916] unable to read MARC file /tmp/f6dc92e68315c37f04c9882c887239d8.mrc |
| 14:59 |
mmorgan |
The file loads on 3.6.2 with perl 5.24.1, but not on 3.6.1 with perl 5.28.1 or 3.6.3 with perl 5.28.1. |
| 15:00 |
mmorgan |
I'm wondering if this is bug 1923076 |
| 15:00 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] https://launchpad.net/bugs/1923076 |
| 15:01 |
mmorgan |
I also have a master concerto server with perl 5.26.1, and the file will NOT load there either. |
| 15:01 |
|
jihpringle joined #evergreen |
| 16:25 |
|
jvwoolf joined #evergreen |
| 16:54 |
|
jamesrf joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:08 |
|
rjackson_isl_hom joined #evergreen |
| 18:13 |
|
rjackson_isl_hom joined #evergreen |
| 18:48 |
JBoyer |
systemd++ |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl_hom joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:25 |
|
mantis joined #evergreen |
| 12:23 |
|
collum joined #evergreen |
| 12:45 |
|
jihpringle joined #evergreen |
| 12:55 |
pastebot |
"jeffdavis" at 168.25.130.30 pasted ""INSERT INTO biblio.record_entry" performance on an upgraded 3.7 system" (37 lines) at http://paste.evergreen-ils.org/10138 |
| 12:57 |
jeffdavis |
^ In my 3.7 test environment, once search.symspell_dictionary is populated, the maintain_symspell_entries_tgr triggers on metabib tables make creating a bib record unusably slow. Not sure if this is an issue with the environment or a performance problem with the symspell stuff. |
| 12:59 |
jeff |
the aaa_indexing_ingest_or_delete line is unfortunately a little opaque there. :-( |
| 13:05 |
jeff |
(though we can probably safely assume all the extra time is search.symspell_maintain_entries) |
| 13:07 |
jeffdavis |
yeah, the only difference between the two results is that I disabled the symspell triggers before re-running the same insert |
| 14:49 |
Bmagic |
right |
| 14:49 |
Bmagic |
maybe it's a search path thing? |
| 14:49 |
Dyrcona |
Does the 035 already exist in the record? |
| 14:51 |
Bmagic |
no, I deleted all the 035 prior to my test |
| 14:51 |
Dyrcona |
Is the 001 the same as the biblio.record_entry.id? |
| 14:52 |
Bmagic |
no |
| 14:53 |
Bmagic |
in my SQL statement, I have my marc xml setup so that the 001 is something totally different. And I would expect it to land in the database in the 035, and the 001 would be assigned the bib ID |
| 17:31 |
|
dbwells joined #evergreen |
| 17:33 |
|
jvwoolf1 left #evergreen |
| 17:50 |
|
dbwells joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:15 |
|
dbwells joined #evergreen |
| 18:35 |
|
sandbergja joined #evergreen |
| 19:49 |
|
jihpringle joined #evergreen |
| 01:58 |
|
stephengwills joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:17 |
|
dbwells joined #evergreen |
| 07:13 |
jeff |
Bmagic: is this for EBSCO EDS RTAC? |
| 07:44 |
|
rjackson_isl_hom joined #evergreen |
| 09:24 |
|
dbwells joined #evergreen |
| 09:35 |
|
jvwoolf joined #evergreen |
| 09:36 |
|
jvwoolf1 joined #evergreen |
| 10:37 |
mmorgan |
Should I expect the bootstrap opac to look oddly unstyled on a local test server without a security certificate? |
| 10:49 |
csharp |
mmorgan: you're sure that /etc/apache2/eg_vhost knows about the boostrap templates? |
| 11:03 |
* mmorgan |
will check that, this was installed using berick's ansible script. |
| 11:06 |
mmorgan |
csharp: Yep, it does. |
| 12:56 |
|
jvwoolf joined #evergreen |
| 12:58 |
mmorgan |
csharp: rhamby: Ok, thanks. All in all, awesome tool! |
| 12:59 |
mmorgan |
berick++ |
| 12:59 |
rhamby |
oh yeah, I only found out because I use it to throw up VMs quickly for testing so berick++ definitely |
| 13:04 |
|
sandbergja joined #evergreen |
| 14:18 |
mantis |
Has anyone run into an issue with baskets that if you put more than one item in there, go to Print, title fields repeats the titles of the other items in the basket and not just the one item? |
| 14:18 |
mantis |
it's a mouthful but the best way I can describe this |
| 14:32 |
mantis |
tpac |
| 14:41 |
mmorgan |
mantis: I don't think I've seen what you describe. I remember we made changes to the action trigger that produces the print out. I vaguely remember that the numbering on the titles didn't work right, and that was something we fixed. |
| 14:41 |
mmorgan |
Also, we're on 3.6, so have the feature added in bug 1749475 |
| 14:41 |
pinesol |
Launchpad bug 1749475 in Evergreen "wishlist: Improved email and printing from the OPAC" [Wishlist,Fix released] https://launchpad.net/bugs/1749475 |
| 15:34 |
|
mmorgan1 joined #evergreen |
| 16:01 |
|
mantis left #evergreen |
| 16:22 |
|
dbwells joined #evergreen |
| 16:54 |
|
mmorgan1 joined #evergreen |
| 17:09 |
|
mmorgan joined #evergreen |
| 17:24 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:30 |
|
wsmoak joined #evergreen |
| 00:34 |
|
sandbergja joined #evergreen |
| 00:49 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2021-04/2021-04-13_04:00:03/test.49.html> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 08:21 |
|
rfrasur joined #evergreen |
| 08:37 |
|
mantis joined #evergreen |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:27 |
* mmorgan |
is thinking bug 1923225 is a critical bug, do others agree? |
| 12:27 |
pinesol |
Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Undecided,Confirmed] https://launchpad.net/bugs/1923225 |
| 12:27 |
mmorgan |
Here is a result from a 'concerto' search on abowling's test server: https://eg-master-test.emeralddata.net/eg/opac/record/92?query=concerto;qtype=keyword;locg=1;detail_record_view=0 |
| 12:32 |
jihpringle |
mmorgan: I agree it's critical since it's patron facing |
| 12:37 |
|
sandbergja joined #evergreen |
| 13:19 |
jeffdavis |
I haven't had a chance to investigate but I'm pretty sure the problem is that the display-field version of the ISBN is being run through the "|html" filter (or an equivalent thereof) too many times; avoiding the filter when it's a display field would be the fix |
| 15:10 |
JBoyer |
jeff++ |
| 15:10 |
jeff |
Are we looking at one each for xul and dojo, or combined, or whatever I decide? |
| 15:11 |
Dyrcona |
I'm OK with whatever you decide, jeff. |
| 15:11 |
JBoyer |
I think it may touch enough stuff that having 2 separate branches will cause more trouble merging / testing than it would save by having 2 slightly more focused branches. |
| 15:12 |
JBoyer |
And I just realized there's no english in the second half of that. |
| 15:13 |
Dyrcona |
Some features are going to require implementation in a different toolkit or be removed, so that could warrant multiple bugs/branches, but IDK. |
| 15:13 |
JBoyer |
I think merge conflicts and a general difficulty in getting branches tested means that 1 might be easier for all involved, is what I was trying to say. |
| 15:13 |
abowling |
JBoyer: it might have been a little clunky, but I think you established the point well enough |
| 15:14 |
Dyrcona |
Yeah, that makes sense, but I'm a bit wary of massive branches. |
| 15:14 |
JBoyer |
Dyrcona, I can see there being a separate branch for removing dojo (and xul) from this or that major section, but I don't think we should have this collection of branches to remove dojo and that collection to remove xul, for instance. |
| 15:36 |
gmcharlt |
agreed |
| 15:36 |
JBoyer |
Hurray for removing unnecessary duplicate calls though. |
| 15:36 |
JBoyer |
Any other release updates? |
| 15:37 |
gmcharlt |
a question: has anybody not-me tested the 3.6.2 to 3.7 schema update? |
| 15:37 |
Dyrcona |
gmcharlt: No, I haven't, but I have tried a 3.2.10 to 3.7 schema upgrade. It takes a long time. :) |
| 15:38 |
gmcharlt |
Dyrcona: but succeeded? |
| 15:38 |
Dyrcona |
Yeah, once that one update was removed. |
| 15:38 |
* phasefx |
noticed a qatest failure with geosort, will poke at that |
| 15:38 |
gmcharlt |
which update? |
| 15:39 |
Dyrcona |
I'm trying to remember. Hang on a sec. You dropped it, IIRC. |
| 15:39 |
JBoyer |
phasefx, I'm wondering if its a timeout or something weird about the environment, I ran some local tests and it was fine. |
| 15:39 |
jeffdavis |
gmcharlt: I've done 3.6.2-3.7 beta minus a couple big updates on real data, haven't tried the RC. |
| 15:39 |
JBoyer |
Dyrcona, gmcharlt : The materialized payment by billing type update |
| 15:39 |
Dyrcona |
Yeah, that's it. 1257 was the number. |
| 15:40 |
phasefx |
oof, I've lost my IRC-fu |
| 15:40 |
gmcharlt |
Dyrcona: jeffdavis: thanks. That's making me confident enough that SELECT randomize_marc_tags(); isn't part of the schema update |
| 15:41 |
* JBoyer |
cackles, "I have spelled it auditor.update_auditors(); Ha!" |
| 15:42 |
JBoyer |
I may also have a 3.6.2-ish db to test against tonight. |
| 15:42 |
JBoyer |
but if not it's just concerto, which I suspect would obviously work. |
| 15:43 |
JBoyer |
I think that and the clock takes us to new business. |
| 15:43 |
JBoyer |
#topic New Business |
| 17:02 |
miker |
FTR, the markup embedded in (highlighted) display fields has the intentional effect of properly escaping embedded would-be markup, so that normal CSS can be used to style. if a scheme is invented to allow that via some sort of templating instead of <span>s with @classes, we'll just need to remember that the angular catalog also uses CSS to style highlighting, so we'll need to teach it the same thing. |
| 17:25 |
|
mmorgan left #evergreen |
| 18:01 |
|
sandbergja joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:51 |
jeffdavis |
ugh |
| 18:52 |
jeffdavis |
I thought I fixed these display field/XSS issues |
| 18:53 |
|
jihpringle61 joined #evergreen |
| 04:49 |
|
jweston joined #evergreen |
| 04:49 |
|
gmcharlt joined #evergreen |
| 04:49 |
|
berick joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
rjackson_isl_hom joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 11:15 |
* miker |
mumbles something about queued ingest and making imports faster and authority propagation possible... |
| 11:17 |
Dyrcona |
jeffdavis++ |
| 11:39 |
jeffdavis |
Disabling maintain_symspell_entries_tgr on *_field_entry tables does the trick. Now to try adding that flag... |
| 11:44 |
Dyrcona |
So, I'm writing Perl tests for Lp 1923076. Looks like I have it working for open-ils.actor.user.hold_requests.count. I'll go through miker's list and add tests for the backend calls. |
| 11:44 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] https://launchpad.net/bugs/1923076 |
| 11:46 |
Dyrcona |
Using some the B module to determine if a value is an integer or not. |
| 11:46 |
Dyrcona |
Oops. Bad edit... |
| 11:47 |
jeff |
should we be testing that, or testing the result of the JSON encode? |
| 11:47 |
jeff |
(I don't know) |
| 11:56 |
Dyrcona |
jeff: The responses go through JSON encode in OpenSRF. Look at https://bugs.launchpad.net/evergreen/+bug/1923076/comments/2 and try the srfsh command (adding the missing comma after the authtoken). On an affected, but unpatched system, you'll see the responses are strings. |
| 11:56 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] |
| 11:57 |
Dyrcona |
Meahwhile...It's lunch time for me. |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:38 |
Dyrcona |
So, I think I've come across one that I can't test on concerto, but I'm pretty sure it needs a patch: open-ils.circ.hold.clear_shelf.process |
| 12:51 |
miker |
Dyrcona++ |
| 12:58 |
Dyrcona |
miker: There are a couple that I'm sure don't need fixes, but I'm unsure about this one: Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/storage.pm:401: return scalar(@fm_nodes); |
| 12:59 |
Dyrcona |
I had trouble find a context where it is used, so I moved on. |
| 14:35 |
jeff |
(I don't think we should switch to Cpanel::JSON::XS right now.) |
| 14:36 |
jeff |
But it also supports passing an additional argument to encode_json, so you can write a spec of what your encoded JSON should look like. |
| 14:37 |
Dyrcona |
I think we should ditch Perl, tbh. Seems like every few years we play whack-a-mole with nonsense like this. |
| 14:44 |
Dyrcona |
I'm testing Cpanel::JSON::XS on buster. Looks like all of the necessary changes are limited to 1 file. |
| 14:46 |
Dyrcona |
I still get some numbers that are strings, but the superpage size one is fixed. I'm gonna see if my tests pass. |
| 14:47 |
Dyrcona |
The tests that I have written pass with Cpanel::JSON::XS on the unpatched buster VM. I think switching to Cpanel::JSON::XS is easier than ditching Perl. |
| 14:49 |
Dyrcona |
So, looking at the output of these tests and some other calls, I'd say we have bigger problems than calling scalar on empty arrays and passing the results through JSON::XS. |
| 14:54 |
jeff |
Do you mean that you think Cpanel::JSON::XS fixes more things than we were focusing on? |
| 14:56 |
Dyrcona |
Yes, I do, but it still isn't perfect. I'm updating the bug. |
| 14:57 |
* jeff |
nods |
| 17:00 |
jeff |
arguably, scalar(@empty-lexical) is the only place we've found change in behavior. |
| 17:13 |
jeff |
if we flip every numeric string to a JSON number, we'll probably shoot ourselves in the foot in one or two places. :-) |
| 17:15 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:07 |
|
jvwoolf1 joined #evergreen |
| 00:46 |
|
dbwells_ joined #evergreen |
| 03:05 |
|
dbwells joined #evergreen |
| 05:34 |
|
dbwells joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:25 |
|
rjackson_isl_hom joined #evergreen |
| 07:41 |
|
Dyrcona joined #evergreen |
| 07:42 |
Dyrcona |
typos-- |
| 10:50 |
Dyrcona |
I'm getting a numeric zero. |
| 10:58 |
jeff |
My understanding of why that is: the difference in behavior / characteristics is mostly in the Perl internals, which aren't available to Perl code. Things like Devel::Peek, B::*, and JSON::XS are perl extensions written in C which have access to the Perl API and can inspect the internals. JSON::XS uses this to try and treat simple scalar values correctly, but acknowledges that it's difficult. |
| 11:00 |
Dyrcona |
Yeah, well I was quickly getting into the elephant grass trying to chase a path through the Perl code itself. |
| 11:00 |
jeff |
In order to write a test case for my git bisect last night, I needed to redirect stderr to a string, so that when I called Devel::Peek::Dump() I could examine the output. |
| 11:01 |
Dyrcona |
So, when are we gonna ditch Perl? :P |
| 11:02 |
jeff |
Interesting. I don't think that the new value of scalar(my $lexical) is just any "0" with a string representation. That would be a SV = PV as shown with perl -MDevel::Peek -e '$str = "0"; Dump($str);' |
| 11:03 |
Dyrcona |
Admittedly, I need to get better at reading Devel::Peek output. |
| 11:06 |
* jeff |
nods |
| 11:07 |
jeff |
perlguts documents the various SV types |
| 11:08 |
Dyrcona |
On perl 5.26, it's PV = IV with or without my. |
| 11:09 |
jeff |
I think the first priority is to fix / work around the identified issues, then do a little looking to see if we have any other similar issues, and as/if time allows, gather some test cases and bring them to the attention of Perl hackers to see if this is something that needs any action on their part (fixing a bug, documenting the change in behavior, etc). |
| 11:09 |
Dyrcona |
perl -MDevel::Peek -e '@ar = (); $str = scalar @ar; Dump($str);' |
| 11:10 |
jeff |
There is a lot of elephant grass to go around. :-) |
| 11:11 |
Dyrcona |
And, I meant SV = IV when I typoed, PV = IV above, just for the logs. |
| 15:46 |
Dyrcona |
miker++ |
| 15:48 |
miker |
oh, I should mention, I also excluded all uses where the return value of scalar() was used inline with a numberish operator, like addition or multiplication, which forces numeric context and should be safe (per 0+ working) |
| 15:48 |
miker |
I basically limited the list to where it was not obviously safe |
| 15:59 |
JBoyer |
miker, I'm not so sure about your "I've excluded uses that are only used in truthiness tests..." from lp 1923076 , I got the impression that simply subjecting them to the testing might be enough to twiddle some bits in their storage and make them look string-y enough for JSON::XS. |
| 15:59 |
pinesol |
Launchpad bug 1923076 in Evergreen 3.6 "Incorrect typing when encoding some values as JSON" [Medium,Confirmed] https://launchpad.net/bugs/1923076 |
| 16:00 |
JBoyer |
Though I've mostly been at the edges of this discussion, if that's not what's actually happening that's great. |
| 16:00 |
miker |
JBoyer: oh, I mean like "if (scalar(@foo))" and the like |
| 16:07 |
gmcharlt |
as a general announcement: I'm planning on cutting 3.7-rc on Monday and the 3.7.0 release on Wednesday |
| 16:12 |
|
jvwoolf joined #evergreen |
| 16:26 |
|
akilsdonk_ joined #evergreen |
| 16:27 |
jeff |
miker: and just think, any times where we're testing an empty @lexical in a boolean context, it's ~314% faster because of the optimization present in Perl 5.28! |
| 16:32 |
|
mantis left #evergreen |
| 16:58 |
miker |
jeff++ |
| 17:17 |
|
mmorgan left #evergreen |
| 17:43 |
Dyrcona |
Correct > Fast. |
| 17:43 |
Dyrcona |
Perl-- |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:32 |
|
sandbergja joined #evergreen |
| 21:27 |
|
JBoyer joined #evergreen |
| 22:05 |
jeffdavis |
Lots of symspell-related deadlocks trying to import records in parallel on a 3.7 system |
| 00:00 |
|
sandbergja joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:02 |
|
collum joined #evergreen |
| 08:29 |
|
mantis joined #evergreen |
| 11:51 |
|
jihpringle joined #evergreen |
| 11:56 |
|
dbwells joined #evergreen |
| 12:16 |
|
jamesrf joined #evergreen |
| 12:19 |
Dyrcona |
jeffdavis: Going to back to your thing with holds counts yesterday, it looks like the real culprit is open-ils.actor.user.hold_requests.count. I've only tested it on Perl 5.30 so far, and it returns the holds available count as a string. |
| 12:24 |
Dyrcona |
Seems bizarre that it would do that, though. The total field is returned as a number, and the way they're calculated *should* be functionally equivalent. |
| 12:24 |
Dyrcona |
I have a suspicion of how to fix it, though. |
| 12:25 |
jeffdavis |
I'm happy to test any ideas you might have. :) |
| 12:32 |
Dyrcona |
Hm... eg_db_config through some errors for me on Ubuntu 18.04. I need to check that before I can go on. |
| 12:35 |
Dyrcona |
OK. I have to install some prerequisites. |
| 12:43 |
Dyrcona |
In Perl 5.26 it's a number. That's really bizarre and must be some kind of Perl bug. |
| 12:43 |
|
dbwells joined #evergreen |
| 12:44 |
|
collum joined #evergreen |
| 12:50 |
Dyrcona |
And, it doesn't happen with a little Perl script intended to test the problem. so it's more complicated than it appears at first glance. |
| 12:54 |
Dyrcona |
So, my "fix" resolves it, but I think it's just patching over the real problem, which I suspect is buried in OpenSRF somewhere. I was not able to reproduce the behavior with a simple Perl script. |
| 12:55 |
Dyrcona |
We should have to go adding int() around all of our uses of scalar(@array)... |
| 12:56 |
Dyrcona |
s/should/shouldn't/ |
| 13:13 |
Dyrcona |
Might be it. I'll see if I can find where we use JSON to turn off allow_nonref. |
| 13:14 |
jeffdavis |
Seems like it might only be an issue where ready = 0? For a user with 1 or more holds ready, the result is an int rather than a string. |
| 13:15 |
Dyrcona |
I don't think that's it after reading the documentation, unless there's a bug with that setting. |
| 13:15 |
Dyrcona |
jeffdavis: I only tested with a handful of concerto patrons, none of whom turned out to have holds. |
| 13:16 |
jeff |
also interesting, https://metacpan.org/source/ISHIGAKI/JSON-4.03/Changes#L25 "allow PERL_JSON_PP_USE_B environmental variable to restore old number detection behavior for compatibility" |
| 13:17 |
Dyrcona |
We already turn allow_nonref on. |
| 13:17 |
jeff |
and: |
| 14:54 |
|
mantis joined #evergreen |
| 14:54 |
jeff |
I see a difference with Perl 5.32.1 with JSON::PP 4.04 vs JSON::XS 4.03. I see the documented behavior of scalars with a string context (where there's a PV and FLAGS includes PV/PVOK): the value is quoted. |
| 14:58 |
jeff |
Dyrcona: what version of JSON::XS are you running on your Ubuntu 18.04 system? |
| 15:02 |
Dyrcona |
jeff: This is Ubuntu 20.04 where I'm testing, the one that show the bug. |
| 15:02 |
jeff |
yep, got that. |
| 15:03 |
* jeff |
looks on packages.ubuntu.com |
| 15:03 |
Dyrcona |
Ubuntu 20.04 has 4.02 |
| 15:03 |
Dyrcona |
Ubuntu 18.04 has 3.02. |
| 15:04 |
Dyrcona |
I see the bug when I use srfsh to make the request, but trying to emulate what looks like the problematic code on 20.04 turns up nothing. |
| 15:04 |
Dyrcona |
I updated all packages before testing today. |
| 15:06 |
Dyrcona |
I have 5.32.1 on a FreeBSD server. |
| 15:07 |
pastebot |
"Dyrcona" at 168.25.130.30 pasted "Here's my latest test" (10 lines) at http://paste.evergreen-ils.org/10132 |
| 15:11 |
Dyrcona |
I get identical results on both Ubuntu servers with the above. I don't have Evergreen on the FreeBSD machine, so I won't test it there. |
| 15:12 |
Dyrcona |
Also, don't have JSON::XS on FreeBSD... |
| 15:12 |
Dyrcona |
I could install it, but this isn't a machine that I use for development. |
| 15:13 |
Dyrcona |
Maybe I should switch from ZZ Top to Jefferson Airplane.... :) |
| 15:15 |
mantis |
running 3.5.4 on a test server and images are failing to load in the catalog |
| 15:23 |
Dyrcona |
mantis: All images or just added content/book jackets? |
| 15:25 |
mantis |
content jackets |
| 15:26 |
mantis |
I'm not sure why that happened |
| 15:26 |
Dyrcona |
Did you configure the added content provider in opensrf.xml? |
| 15:26 |
Dyrcona |
I think that's where it goes.... |
| 15:36 |
jeff |
okay, I think I have a simple (yet still relevant) test that demonstrates a difference in behavior between Perl 5.26.3 and Perl 5.32.1, both with JSON::XS 4.03. I'm going to try and narrow down where it changes. |
| 15:38 |
Dyrcona |
jeff: Can you paste the test? I'd like to see it. |
| 15:38 |
mantis |
Dyrcona: thanks I'll take a look at it |
| 15:38 |
mantis |
Dyrcona++ |
| 15:39 |
|
mantis left #evergreen |
| 15:41 |
jeff |
here's the test and output under 5.26.3 and 5.32.1 so far, with some Devel::Peek Dump() output to help see where the flags are: https://gist.github.com/jeff/6ab1d188db2cd21ac1d45cf06544d7d2 |
| 15:42 |
jeff |
I'm installing 5.28 and 5.30 to help identify where the change was introduced. |
| 15:45 |
Dyrcona |
jeff: Interesting. My tests haven't done that. |
| 15:45 |
|
dbwells joined #evergreen |
| 15:48 |
miker |
oh, my, that's terrible if scalar() returns strings now |
| 15:49 |
jeff |
miker: not obvious in that simplified test, but it seems to only be when we have an empty array. |
| 15:50 |
Dyrcona |
Yeah, but I can't make it do that. jeff's test does for me, but my tests don't. |
| 15:53 |
jeff |
5.28.3 does it also. |
| 15:53 |
jeff |
updated gist with new output |
| 15:53 |
|
jihpringle joined #evergreen |
| 16:02 |
miker |
so do we just need to spell it 0+scalar(@bar) then? |
| 16:02 |
jeff |
> A new kind of magic scalar, called a "nonelem" scalar, has been introduced. It is stored in an array to denote a non-existent element, whenever such an element is accessed in a potential lvalue context. |
| 16:02 |
jeff |
but I'm not sold on that being related. |
| 16:04 |
miker |
changing jeff's test to that (cast to number by prepending 0+ ) "fixes" foo for me on 5.28 |
| 16:04 |
Dyrcona |
miker: int(scalar(...)) works, too. |
| 16:05 |
miker |
Dyrcona: yeah, either way ... s/scalar\(/0+scalar(/g in vim is easier though ;) |
| 16:06 |
Dyrcona |
What's weird is I'm not seeing it with the scripts that I pasted earlier. |
| 16:11 |
Dyrcona |
Also, looks like anyone using Debian Buster in production would see this, too. |
| 16:12 |
miker |
Dyrcona: I understand, I meant internal to opensrf perl code, not evergreen application code (looking for Worse Problems :) ) |
| 16:13 |
Dyrcona |
Right. |
| 16:16 |
jeff |
Dyrcona: that is interesting that your tests using OpenSRF libs aren't showing the problematic behavior. I modified one of your recent ones to use JSON::XS directly and it shows the same issue with the same versions (no surprise, since it's almost the same as one of my tests now): https://gist.github.com/jeff/a4fd184305f0a7870258040e3e3ce702 |
| 16:18 |
jeff |
"Various integer-returning ops are now more efficient in scalar/boolean context." |
| 16:18 |
jeff |
(also from perl5280delta) |
| 16:18 |
jeff |
"Converting a single-digit string to a number is now substantially faster." |
| 16:20 |
Dyrcona |
jeff: I didn't get it when I used the JSON::XS object interface, either. |
| 16:23 |
Dyrcona |
So, should we add this to Lp? |
| 16:24 |
miker |
jeff: "... faster, because it doesn't happen" ;) |
| 17:37 |
|
mmorgan left #evergreen |
| 17:46 |
jeffdavis |
Python 3 also makes installing translations "fun" on Ubuntu 20.04. |
| 17:46 |
jeffdavis |
Starting to wonder if we should stick with 18.04 for our upgrade. :( |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
sandbergja joined #evergreen |
| 19:45 |
|
dbwells joined #evergreen |
| 22:09 |
|
sandbergja joined #evergreen |
| 13:00 |
|
sandbergja joined #evergreen |
| 13:06 |
|
jamesrf joined #evergreen |
| 13:32 |
|
jihpringle joined #evergreen |
| 13:49 |
jeffdavis |
On my 3.7 beta test server, initial retrieval for any patron account results in a blank alert message - you get redirected to the Other tab with a STOP sign and the "Press a navigation button above (for example, Check Out) to clear this alert." message, but there is no alert. |
| 13:52 |
jeffdavis |
Test users are active, not expired/deleted/barred, card is active, no alert message, no standing penalties, no holds ready, no invalid addresses. Once the alert is cleared, it does not appear again for that patron. |
| 14:00 |
JBoyer |
jeffdavis, that sounds familiar. I've seen that happen when the number of holds available is formatted as a string rather than a number because 0 is false and "0" is true. |
| 14:00 |
JBoyer |
I thought there was a patch for that (unless this is a new instance of a similar issue) |
| 14:01 |
jeffdavis |
JBoyer++ |
| 14:47 |
|
dbwells joined #evergreen |
| 14:52 |
|
stephengwills joined #evergreen |
| 14:56 |
|
jihpringle joined #evergreen |
| 15:20 |
jeffdavis |
The test server where I'm seeing the issue is running Ubuntu 20.04. I tried installing the same OpenSRF/EG branches on an 18.04 server and cannot replicate the error there. |
| 15:21 |
jeffdavis |
(Perl v5.30.0 vs v5.26.1) |
| 15:22 |
|
jihpringle joined #evergreen |
| 15:29 |
rhamby |
r |
| 15:31 |
JBoyer |
No, I was definitely looking specifically at this ready_holds: "0" issue and more recently than that bug was last updated, but I'm having a hard time finding *where* I was looking at it. :( |
| 16:31 |
Dyrcona |
Oh well, time's up. I'll have a look tomorrow. I suspect it had more to do with Ubuntu 20.04 than the version of Evergreen. |
| 16:57 |
|
jvwoolf left #evergreen |
| 17:32 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2021-04/2021-04-06_16:00:02/test.29.html> |
| 19:36 |
|
sandbergja joined #evergreen |
| 22:01 |
|
sandbergja joined #evergreen |
| 23:04 |
|
jamesrf joined #evergreen |
