Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Re: Time to translate: string freeze to prepare April release
(Fridolin SOMERS)
2. Deleting entries from language_descriptions
(dcook@prosentient.com.au)
3. Re: Optimizing Starman startup (Renvoize, Martin)


----------------------------------------------------------------------

Message: 1
Date: Thu, 22 Apr 2021 13:45:26 +0200
From: Fridolin SOMERS <fridolin.somers@biblibre.com>
To: koha-translate@lists.koha-community.org, koha-devel
    <koha-devel@lists.koha-community.org>, "koha@lists.katipo.co.nz"
    <koha@lists.katipo.co.nz>
Subject: Re: [Koha-devel] Time to translate: string freeze to prepare
    April release
Message-ID: <50c07728-11c2-b430-7a11-8a52bee2d5aa@biblibre.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

Sorry I pushed a few commits that impact strings after the 15th.

So today Pootle has been updated, have a look.

Release is planned on monday 26th, end of the day.

Best regards,

Le 19/04/2021 à 15:06, Fridolin SOMERS a écrit :
> Hi,
>
> String freeze is into effect.
> The 20.11.x maintenance branch is preparing for 20.11.05 release.
> The release is scheduled for around the 26rd.
>
> This means it's the right time to head over to the translation platform:
> https://translate.koha-community.org/projects/
>
> Happy translating 🌎🌍🌏
>

--
Fridolin SOMERS <fridolin.somers@biblibre.com>
Software and system maintainer 🦄
BibLibre, France


------------------------------

Message: 2
Date: Fri, 23 Apr 2021 12:38:03 +1000
From: <dcook@prosentient.com.au>
To: <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Deleting entries from language_descriptions
Message-ID: <011901d737e9$af443730$0dcca590$@prosentient.com.au>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,



I was looking at how to add languages to the Languages drop down in the OPAC
advanced search and went down an unpleasant C4::Languages rabbithole…



But looking at language_descriptions, I’m wondering if perhaps we could
delete the following data, as I imagine it’s very outdated and unused:



MySQL [koha_kohadev]> select * from language_descriptions;

+----------+----------+------+---------------------------------------+-----+

| subtag | type | lang | description | id |

+----------+----------+------+---------------------------------------+-----+

| opac | i | en | OPAC | 1 |

| opac | i | fr | OPAC | 2 |

| opac | i | de | OPAC | 3 |

| intranet | i | en | Staff Client | 4 |

| intranet | i | fr | Client personnel | 5 |

| intranet | i | de | Dienstoberfläche | 6 |

| prog | t | en | Prog | 7 |

| prog | t | fr | Prog | 8 |

| prog | t | de | Prog | 9 |



At the moment, it looks like adding a language requires manual SQL queries
to language_subtag_registry, language_descriptions, and
language_rfc4646_to_iso639. It’s a shame there is no native interface for
updating it. I imagine a plugin could work out well for it, although I think
for the library in mind they’ll probably just do a manual insert, as it’s
not worth the development cost…



David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia



Office: 02 9212 0899

Online: 02 8005 0595



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210423/bbd559fe/attachment-0001.htm>

------------------------------

Message: 3
Date: Fri, 23 Apr 2021 08:24:22 +0100
From: "Renvoize, Martin" <martin.renvoize@ptfs-europe.com>
To: David Cook <dcook@prosentient.com.au>
Cc: Koha Devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Optimizing Starman startup
Message-ID:
    <CAB7SL8Dt4d9ap63AVTTWSZy9Bzzi-dUV_FgaUwYW+0u1tQBrkg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Jan's code is certainly challenging to read and understand at times I
agree.. I used to contribute to the plugin a number of years ago now.. but
the project that gave me time to play with that has since been sold on so
I'm not involved at the level I used to be.. he uses lots of Perl foo which
often takes me a long time to wrap my head around.

As for the refs, I think we split our spec up too much in all honesty..
even the swagger spec suggest we went too far.. I think I might have been
unclear when I first pushed for a split from one massive file. We
could/should certainly reduce that somewhat.. it'll be interesting to see
if it makes much difference.. that could be a fairly quick win.

On Thu, 22 Apr 2021, 12:32 am , <dcook@prosentient.com.au> wrote:

> Hi Ere,
>
> I think you're right about the refs. While they get resolved by the
> OpenAPI plugin, you probably have to resolve them before trying to
> dynamically inject the routes from plugins.
>
> Jan Thorsen (the author of Mojolicious::Plugin::OpenAPI and
> JSON::Validator) thinks that the ref resolution is actually what's taking
> so long. I looked it up and I think we have over 400 different references
> in the main OpenAPI spec alone. I haven't profiled it but something to
> think about.
>
> At some point, I'm going to have a play with newer versions of the
> modules. I'm gong to look at Ubuntu 20.04 and newer Debian versions to see
> what I can get away with in terms of newness. Needs more investigation, but
> I am really hoping that this is an issue that can be solved by just
> upgrading the OS.
>
> I find Jan's code to be unnecessarily opaque (could use more descriptive
> comments and function naming) but... I'll investigate. Probably not right
> away as I have a bunch of other priorities that I have to address but...
> this is on my mind.
>
> Starman startup time is probably the thing about Koha annoying me the most
> right now and probably the most practical thing I can improve at the
> moment...
>
> David Cook
> Software Engineer
> Prosentient Systems
> Suite 7.03
> 6a Glen St
> Milsons Point NSW 2061
> Australia
>
> Office: 02 9212 0899
> Online: 02 8005 0595
>
> -----Original Message-----
> From: Ere Maijala <ere.maijala@helsinki.fi>
> Sent: Wednesday, 21 April 2021 6:31 PM
> To: dcook@prosentient.com.au; koha-devel@lists.koha-community.org
> Subject: Re: [Koha-devel] Optimizing Starman startup
>
> Hi David,
>
> I wish I'd remember all the details, but my memory fails me. I think not
> using JSON had something to do with how the refs are resolved. That may or
> may not have been the reason, but if everything works with JSON module, I
> can't think of a reason not to use it.
>
> Thanks for taking a look!
>
> --Ere
>
> dcook@prosentient.com.au kirjoitti 21.4.2021 klo 3.28:
> > Hi Ere,
> >
> > Thanks for your reply. 24700 looks much better. I'll look at backporting
> it locally.
> >
> > Although I'm looking at JSON::Validator::OpenAPI::Mojolicious at
> https://metacpan.org/pod/release/JHTHORSEN/Mojolicious-Plugin-OpenAPI-2.19/lib/JSON/Validator/OpenAPI/Mojolicious.pm
> and it says "Do not use this module directly. Use
> Mojolicious::Plugin::OpenAPI instead." I notice that you're using the
> "bundle" method. Do we really need that there? Why don't we just load the
> JSON using the JSON module, merge with the plugin spec files, and then pass
> it to the OpenAPI plugin? Shouldn't the plugin take care of the $ref
> replacement?
> >
> > Hmm... I didn't realize until now that the OpenAPI plugin was doing a
> validate behind the scenes. That's tricky.
> >
> > At a glance, we might be able to pre-load the app into the Starman
> > master process pre-fork. There are warnings about doing that with open
> > database connections, so we'd need to review plack.psgi, but a quick
> > glance suggests it might be OK. (Alternatively, I have wondered about
> > running the REST API as a separate process apart from Starman using
> > hypnotoad. According to
> > https://docs.mojolicious.org/Mojolicious/Guides/Cookbook,
> > Mojo::Server::Prefork preloads the application in the manager/master
> > process, and Hypnotoad is based off that, so that would help.)
> >
> > It does seem like changes to the OpenAPI plugin would be needed for
> caching.
> >
> > I'm going to try backporting your change and try pre-loading and see how
> far that gets me.
> >
> > David Cook
> > Software Engineer
> > Prosentient Systems
> > Suite 7.03
> > 6a Glen St
> > Milsons Point NSW 2061
> > Australia
> >
> > Office: 02 9212 0899
> > Online: 02 8005 0595
> >
> > -----Original Message-----
> > From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On
> > Behalf Of Ere Maijala
> > Sent: Tuesday, 20 April 2021 4:48 PM
> > To: koha-devel@lists.koha-community.org
> > Subject: Re: [Koha-devel] Optimizing Starman startup
> >
> > Hi,
> >
> > I did some work on improving it here:
> >
> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24700
> >
> > That shaved a good bit of time from it, but it's still a heavy
> > operation, and it would make sense to
> >
> > 1.) avoid doing it too often
> >
> > 2.) cache the results and avoid doing it if results are cached
> >
> > If you could address the first one, that'd go a long way. I'm afraid the
> second one would require changes to the OpenAPI plugin to support caching.
> >
> > --Ere
> >
> > dcook@prosentient.com.au kirjoitti 20.4.2021 klo 6.15:
> >> Hi all,
> >>
> >> Do you despair when you see the following periodically in “top” when
> >> a starman worker is recreated ?
> >>
> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
> >> COMMAND
> >>
> >> 9529 my-koha 20 0 460108 197212 17172 R 100.0 0.4 0:03.41
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> Or the following in top when you install koha-common package or
> >> restart the koha-common service?
> >>
> >> 11101 1-koha 20 0 447232 193320 16076 R 10.6 0.4 0:09.09
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11168 1-koha 20 0 447240 193264 16056 R 10.6 0.4 0:08.72
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11306 2-koha 20 0 447220 193148 16000 R 10.6 0.4 0:08.07
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11543 2-koha 20 0 447232 193036 15828 R 10.6 0.4 0:07.07
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11784 3-koha 20 0 441536 189664 16172 R 10.6 0.4 0:06.04
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11830 3-koha 20 0 439548 187212 15748 R 10.6 0.4 0:05.82
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11831 4-koha 20 0 438620 186344 15748 R 10.6 0.4 0:05.81
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> 11853 4-koha 20 0 437680 185672 16000 R 10.6 0.4 0:05.79
> >> /usr/share/koha/api/v1/app.pl
> >>
> >> Well, I still have a lot of investigation left to do, but I notice 1
> >> place that a lot of time taken is here (per worker):
> >>
> >> my $validator = JSON::Validator::OpenAPI::Mojolicious->new;
> >>
> >> $validator->load_and_validate_schema(
> >>
> >> $self->home->rel_file("api/v1/swagger/swagger.json"),
> >>
> >> {
> >>
> >> allow_invalid_ref => 1,
> >>
> >> }
> >>
> >> );
> >>
> >> push @{$self->routes->namespaces}, 'Koha::Plugin';
> >>
> >> my $spec = $validator->schema->data;
> >>
> >> $self->plugin(
> >>
> >> 'Koha::REST::Plugin::PluginRoutes' => {
> >>
> >> spec => $spec,
> >>
> >> validator => $validator
> >>
> >> }
> >>
> >> );
> >>
> >> $self->plugin(
> >>
> >> OpenAPI => {
> >>
> >> spec => $spec,
> >>
> >> route =>
> >> $self->routes->under('/api/v1')->to('Auth#under'),
> >>
> >> allow_invalid_ref =>
> >>
> >> 1, # required by our spec because $ref directly
> >> under
> >>
> >> # Paths-, Parameters-, Definitions- &
> >> Info-object
> >>
> >> # is not allowed by the OpenAPI specification.
> >>
> >> }
> >>
> >> );
> >>
> >> Anyone have ideas for improving this? Do we have to validate the
> >> schema every time? Can we move the schema validation into a different
> >> module and preload it into Starman using the -M flag so that it’s
> >> done
> >> 1 time per Starman master instance rather than 1 time per Starman
> worker instance?
> >>
> >> I find “/usr/share/koha/api/v1/app.pl” to be the bane of deployments,
> >> as it puts a massive load on a server, when you have multiple Koha
> >> instances on the server.
> >>
> >> David Cook
> >>
> >> Software Engineer
> >>
> >> Prosentient Systems
> >>
> >> Suite 7.03
> >>
> >> 6a Glen St
> >>
> >> Milsons Point NSW 2061
> >>
> >> Australia
> >>
> >> Office: 02 9212 0899
> >>
> >> Online: 02 8005 0595
> >>
> >>
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel@lists.koha-community.org
> >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >> website : https://www.koha-community.org/ git :
> >> https://git.koha-community.org/ bugs :
> >> https://bugs.koha-community.org/
> >>
> >
> > --
> > Ere Maijala
> > Kansalliskirjasto / The National Library of Finland
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel@lists.koha-community.org
> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : https://www.koha-community.org/ git :
> > https://git.koha-community.org/ bugs :
> > https://bugs.koha-community.org/
> >
> >
>
> --
> Ere Maijala
> Kansalliskirjasto / The National Library of Finland
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210423/8d85623d/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/


------------------------------

End of Koha-devel Digest, Vol 185, Issue 22
*******************************************