Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyUea-0008Kq-Un for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 07:29:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lyUeX-0003R1-S0 for pgadmin-hackers@arkaria.postgresql.org; Wed, 30 Jun 2021 07:28:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyUeX-0003Qs-6I for pgadmin-hackers@lists.postgresql.org; Wed, 30 Jun 2021 07:28:57 +0000 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lyUeP-0005zf-Gv for pgadmin-hackers@postgresql.org; Wed, 30 Jun 2021 07:28:55 +0000 Received: by mail-il1-x134.google.com with SMTP id b5so1935562ilc.12 for ; Wed, 30 Jun 2021 00:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qOt0Bf+0Wx2NnCLkw14uGuTVYvTZUv7jehfmRirXxM0=; b=IaHnCSLC4cfGsMcLjTKAKzHyLCHEBs+V4xK4eM4ao+KAcZm0wgURYhiD+x1UWbKvzX hPS7e5mlTBvNM6kdhlfxyX1p7oNYnfSl+nxfCFpgTcG1Byzw8CMYUrIp/KMMnL+F3jcO trmp2ruGTurghSpyqNjtrzGFoZvI7KjK9I4y47T9xWMLg9zhhsuwiBvCKkr9BiYVwJSw pLi8izFXZWqP72c2e/k3RCy4iQMbR63FlSbZ5lg1SlKsEeqBZUsjfLs3mfReI6Jaa/JD 3LytUBR370r2rGINEI3+wQNwQJ2Pnhmd0b24FDxBb9oSlg10ZORNg2kKD8ArT2Ojy2nx S+eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qOt0Bf+0Wx2NnCLkw14uGuTVYvTZUv7jehfmRirXxM0=; b=nlsHypDGlqkjioCZsQV3Zzo+uqewonltqV15ggIIYgZO4j5sGgIEMbysF8RiGUnpeC toRnmcAuI55JP04lxBcVOEai7ZKdXeTLo2B4+dwIvyQAoI4GVrSkRKSdGRPkF4AWH/vs Af7lOzNUvqdXtFGxBTQ5sADzMlx1ebE6za76MKHjWXRVT7HDIMmicirXt8v7dUD7kyMv pWhgQo13C+NZDzPZQYd/8o2woe4oCQbjkVyOmzxOZ3W52Bosww22D6laSyW9mHQQL6nV IRRmOc2qqV30nXwZdgc1Z8WmKLR57YeETBBRihHamo2Im/gRBxg+QtTaOY5t9JDJEUUT H5Mw== X-Gm-Message-State: AOAM530LT8Vs4cy14B+n4e4eUqe21q0YkyBDgtiilc5ZOrxuwLHqA96h /9t5odqzOIzSTaOtsX9+m11Bp7qcAf7pneyoSL5bF7yEyLIxig6kiU3jr7Ek7y4rEGlWd+fMUPg Hk3OiuYz8fOGxa+fDWLuKSRJwOoWbRvFag8a6/WneboeqDgzjc3rH0KxlLoXiQgzqObPzH1maKf KVh7Awn7kqojIR2WRFgnP4JBUyyfNCqCkZ5H3i7AKriJZ59xFoy1sTS/UvhQ== X-Google-Smtp-Source: ABdhPJw6Fr97Lr+7bXZOI4vMbD+96q4jJfUbXnTQWTExGKPVQYLaKVN2Fy5OfbE/3ntxsRU+Hsc6uiYWAqmf2GJ1OEc= X-Received: by 2002:a05:6e02:13b0:: with SMTP id h16mr9459984ilo.271.1625038127985; Wed, 30 Jun 2021 00:28:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Shirsat Date: Wed, 30 Jun 2021 12:58:11 +0530 Message-ID: Subject: Re: [patch][pgAdmin] Fix for pgadmin4-linux-qa #1651 failure To: Dave Page Cc: Aditya Toshniwal , pgadmin-hackers Content-Type: multipart/mixed; boundary="0000000000005dbe0f05c5f6aceb" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005dbe0f05c5f6aceb Content-Type: multipart/alternative; boundary="0000000000005dbe0d05c5f6ace9" --0000000000005dbe0d05c5f6ace9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, Please find the attached patch for resolving this issue wrt above suggestion. Let me know if anyone has any queries. On Tue, Jun 29, 2021 at 9:20 PM Rahul Shirsat < rahul.shirsat@enterprisedb.com> wrote: > Hi Dave / Aditya, > > For a time being, Let's make a call to gettext conditional instead of > passing dynamic parameters for this scenario at least. With this, we won'= t > be touching the *.po files and translations will do its task smoothly. > I have already checked for the string with weird unprintable characters, > and there were none. > > e.g. > Instead of - *title =3D gettext('%s objects?', obj.label);* > > *if (drop) {* > * title =3D gettext('Drop objects?');* > *}* > *else {* > *title =3D gettext('Reassign objects?');* > *}* > > I have tried the above code and it looks good to me. > > Please suggest. > > On Tue, Jun 29, 2021 at 7:31 PM Dave Page wrote: > >> >> >> On Tue, Jun 29, 2021 at 2:55 PM Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> wrote: >> >>> Hi, >>> >>> On Tue, Jun 29, 2021 at 7:14 PM Dave Page wrote: >>> >>>> >>>> >>>> On Tue, Jun 29, 2021 at 2:41 PM Aditya Toshniwal < >>>> aditya.toshniwal@enterprisedb.com> wrote: >>>> >>>>> Dave, >>>>> >>>>> Somehow, the new text strings are added to PO with incorrect >>>>> translations. That is causing the issue. >>>>> Either they should be empty or fixed. >>>>> >>>> >>>> Then the source problem should be fixed. There's no point at all in >>>> putting fixes directly in the PO files as they'll be overwritten prior= to >>>> release anyway. >>>> >>> The translations submitted by translators are updated in the PO file >>> right ? And then they're compiled to MO ? >>> >> >> Right. >> >> >>> It's the same like Rahul will be submitting the translations. Please >>> correct me if I'm wrong. >>> >> >> That depends if he's changed the original message or the translated >> message. It's impossible to see without reading megabytes of text. >> >> And in any case, he's updated translations that haven't been touched in >> ages - why would they suddenly have broken? (hint: if the upstream messa= ge >> has changed, it'll be marked as fuzzy or untranslated - in other words, >> gettext knows how to handle that). >> >> >>> >>>> >>>>> >>>>> On Tue, Jun 29, 2021 at 7:01 PM Dave Page wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> Please send the patch without updates to the po files. Those get >>>>>> updated as part of the release process. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On Tue, Jun 29, 2021 at 2:00 PM Rahul Shirsat < >>>>>> rahul.shirsat@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> >>>>>>> Thanks Aditya for pointing out the issue. Please find the attached >>>>>>> patch which contains all the .po files corrected with %s. >>>>>>> >>>>>>> Regards, >>>>>>> Rahul Shirsat. >>>>>>> >>>>>>> On Tue, Jun 29, 2021 at 4:31 PM Aditya Toshniwal < >>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Hi Rahul, >>>>>>>> >>>>>>>> I did "make msg-extract" and "make msg-update" and looking at the >>>>>>>> PO files I think it is not updated correctly. >>>>>>>> For instance, the below message has msgstr without %s. I corrected >>>>>>>> it and the error was gone. >>>>>>>> >>>>>>>> #: pgadmin/browser/server_groups/servers/roles/static/js/role.js:7= 66 >>>>>>>> #, fuzzy, python-format >>>>>>>> msgid "%s Objects" >>>>>>>> msgstr "Obiekty" >>>>>>>> >>>>>>>> The one below had 2 %s in msgstr and I corrected it to fix the >>>>>>>> error. >>>>>>>> >>>>>>>> #: pgadmin/browser/server_groups/servers/roles/static/js/role.js:7= 67 >>>>>>>> #, fuzzy, python-format >>>>>>>> msgid "Are you sure you wish to %s all the objects owned by the >>>>>>>> selected role?" >>>>>>>> msgstr "Czy na pewno skasowa=C4=87 %s \"%s\" i wszystkie obiekty z= ale=C5=BCne >>>>>>>> od niego?" >>>>>>>> >>>>>>>> >>>>>>>> You have to update the .po files to match the total %s and send th= e >>>>>>>> patch. >>>>>>>> >>>>>>>> On Tue, Jun 29, 2021 at 1:56 PM Dave Page >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> On Tue, Jun 29, 2021 at 4:38 AM Rahul Shirsat < >>>>>>>>> rahul.shirsat@enterprisedb.com> wrote: >>>>>>>>> >>>>>>>>>> I feel gettext sometimes won't escape the characters as it shoul= d >>>>>>>>>> be. >>>>>>>>>> >>>>>>>>>> I now tried to escape those using some utils. >>>>>>>>>> >>>>>>>>> >>>>>>>>> That won't work either. The string being passed to gettext() >>>>>>>>> *must* be in the gettext call. >>>>>>>>> >>>>>>>>> When gettext extracts strings to create/update the catalogs, it >>>>>>>>> will search the code for all gettext calls, and then extract a st= ring >>>>>>>>> constant from the first argument. You cannot have variables, func= tion calls >>>>>>>>> or expressions in there. It *must* be a string constant. >>>>>>>>> >>>>>>>>> Keep in mind that msgextract is scanning the source code; it's no= t >>>>>>>>> executing it. There are many examples in the code, e.g. (from nod= e.js): >>>>>>>>> >>>>>>>>> title =3D gettext('Drop %s?', obj.label); >>>>>>>>> >>>>>>>>> I don't see anything obviously wrong with the existing code. Are >>>>>>>>> you sure there are no weird unprintable characters in there? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please find the updated patch. >>>>>>>>>> >>>>>>>>>> On Mon, Jun 28, 2021 at 9:33 PM Dave Page >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> On Mon, Jun 28, 2021 at 4:57 PM Rahul Shirsat < >>>>>>>>>>> rahul.shirsat@enterprisedb.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Hackers, >>>>>>>>>>>> >>>>>>>>>>>> Please find the attached patch for fixation of jenkins failure= . >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That won't work - you can't include variables (or string >>>>>>>>>>> building operations) in the first argument to gettext calls, as= there won't >>>>>>>>>>> be any way to extract a complete message into the catalogs. The= way it's >>>>>>>>>>> being done at the moment is correct (I don't know why it's fail= ing, but >>>>>>>>>>> it's the correct way to structure the gettext calls). >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dave Page >>>>>>>>>>> Blog: https://pgsnake.blogspot.com >>>>>>>>>>> Twitter: @pgsnake >>>>>>>>>>> >>>>>>>>>>> EDB: https://www.enterprisedb.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Rahul Shirsat* >>>>>>>>>> Senior Software Engineer | EnterpriseDB Corporation. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dave Page >>>>>>>>> Blog: https://pgsnake.blogspot.com >>>>>>>>> Twitter: @pgsnake >>>>>>>>> >>>>>>>>> EDB: https://www.enterprisedb.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks, >>>>>>>> Aditya Toshniwal >>>>>>>> pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com* >>>>>>>> >>>>>>>> "Don't Complain about Heat, Plant a TREE" >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Rahul Shirsat* >>>>>>> Senior Software Engineer | EnterpriseDB Corporation. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dave Page >>>>>> Blog: https://pgsnake.blogspot.com >>>>>> Twitter: @pgsnake >>>>>> >>>>>> EDB: https://www.enterprisedb.com >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Aditya Toshniwal >>>>> pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com* >>>>> >>>>> "Don't Complain about Heat, Plant a TREE" >>>>> >>>> >>>> >>>> -- >>>> Dave Page >>>> Blog: https://pgsnake.blogspot.com >>>> Twitter: @pgsnake >>>> >>>> EDB: https://www.enterprisedb.com >>>> >>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com* >>> >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > *Rahul Shirsat* > Senior Software Engineer | EnterpriseDB Corporation. > --=20 *Rahul Shirsat* Senior Software Engineer | EnterpriseDB Corporation. --0000000000005dbe0d05c5f6ace9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Please find the attached = patch for resolving=C2=A0this issue wrt above suggestion.

Let me know if anyone has any queries.

On Tue, Jun 29, 2021 at 9:20 = PM Rahul Shirsat <rahu= l.shirsat@enterprisedb.com> wrote:
Hi Dave / Aditya,

=
For a time being, Let's make a call to gettext conditional instead= of passing dynamic parameters for this scenario at least. With this, we wo= n't be touching the *.po files and translations will do its task smooth= ly.
I have already checked for the string with weird unprintable = characters, and there were none.

e.g.=C2=A0
<= div>Instead of -=C2=A0=C2=A0title =3D gettext('%s objects?', obj= .label);

if (drop) {
<= b>=C2=A0 =C2=A0title =3D gettext('Drop objects?');
}
else {
=C2=A0 =C2=A0= title =3D gettext('Reassign objects?');
}

I have tried the above code and it looks good t= o me.

Please suggest.

On Tue, Jun 29, 2021 at= 7:31 PM Dave Page <dpage@pgadmin.org> wrote:


On Tue, Jun 29, 2= 021 at 2:55 PM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> w= rote:
Hi,=

On Tue, Jun 29, 2021 at 7:14 PM Dave Page <dpage@pgadmin.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


On Tue, Jun 29, 2021 at 2:41 PM Aditya Toshniwal <aditya.tosh= niwal@enterprisedb.com> wrote:
Dave,

Somehow, the new text strin= gs are added to PO with incorrect translations. That is causing the issue.<= /div>
Either they should be em= pty or fixed.

Then the source p= roblem should be fixed. There's no point at all in putting fixes direct= ly in the PO files as they'll be overwritten prior to release anyway.
The translations submitted by translators are= updated in the PO file right ? And then they're compiled to MO ?

Right.
=C2=A0=
It's the same like Rahul will be submitting t= he translations. Please correct me if I'm wrong.

That depends if he's changed the ori= ginal message or the translated message. It's impossible to see without= reading megabytes of text.

And in any case, he= 9;s updated translations that haven't been touched in ages - why would = they suddenly have broken? (hint: if the upstream message has changed, it&#= 39;ll be marked as fuzzy or untranslated - in other words, gettext knows ho= w to handle that).
=C2=A0
=C2=A0

=
On Tue, Ju= n 29, 2021 at 7:01 PM Dave Page <dpage@pgadmin.org> wrote:
Hi

Ple= ase send the patch without updates to the po files. Those get updated as pa= rt of the release process.

Thanks.

=
On Tue, Ju= n 29, 2021 at 2:00 PM Rahul Shirsat <rahul.shirsat@enterprisedb.com> wro= te:
Hi Hackers,

Thanks Aditya for pointi= ng out the issue. Please=C2=A0find the attached patch which contains all th= e .po files corrected with %s.

Regards,
= Rahul Shirsat.

On Tue, Jun 29, 2021 at 4:31 PM Aditya Toshniwal <aditya= .toshniwal@enterprisedb.com> wrote:
Hi Rahul,

=
I=C2=A0did "ma= ke msg-extract" and "make msg-update" and looking a= t the PO files I think it is not updated correctly.
For instance, the be= low message has msgstr without %s. I corrected it and the error was gone.
#: pgadmin/browser/server_groups/servers/roles/static/js/role.js:766<= br>#, fuzzy, python-format
msgid "%s Objects"
msgstr "= Obiekty"

The one below had 2 %s in msgstr and I corrected it to= fix the error.

#: pgadmin/browser/server_groups/servers/roles/stati= c/js/role.js:767
#, fuzzy, python-format
msgid "Are you sure you= wish to %s all the objects owned by the selected role?"
msgstr &qu= ot;Czy na pewno skasowa=C4=87 %s \"%s\" i wszystkie obiekty zale= =C5=BCne od niego?"


You have to update the .po files to mat= ch the total %s and send the patch.

On Tue, Jun 29, 2021 at 1:56 PM D= ave Page <dpage@p= gadmin.org> wrote:
Hi

On Tue, Jun 29, 2021 at= 4:38 AM Rahul Shirsat <rahul.shirsat@enterprisedb.com> wrote:
=
I feel g= ettext sometimes won't escape the characters as it should be.

<= /div>
I now tried to escape those using some utils.

That won't work either. The string being passe= d to gettext() *must* be in the gettext call.

When= gettext extracts strings to create/update the catalogs, it will search the= code for all gettext calls, and then extract a string constant from the fi= rst argument. You cannot have variables, function calls or expressions in t= here. It *must* be a string constant.=C2=A0

Keep i= n mind that msgextract is scanning the source code; it's not executing = it. There are many examples in the code, e.g. (from node.js):
title =3D gettext('Drop %s?', obj.label);

I don't see anything obviously wrong with the existing = code. Are you sure there are no weird unprintable characters in there?
=C2=A0

Please=C2=A0find the updated patch.

On M= on, Jun 28, 2021 at 9:33 PM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Mon, Jun = 28, 2021 at 4:57 PM Rahul Shirsat <rahul.shirsat@enterprisedb.com> wrote= :
Hi Hackers,

Please find the attached patch for fixati= on of jenkins failure.

That won= 't work - you can't include variables (or string building operation= s) in the first argument=C2=A0to gettext calls, as there won't be any w= ay to extract a complete message into the catalogs. The way it's being = done at the moment is correct (I don't know why it's failing, but i= t's the correct way to structure the gettext calls).
=C2=A0
--
=


--
Rahul Shirsat
Senior Software Engin= eer=C2=A0|=C2=A0EnterpriseDB=C2=A0Corporation.


--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake<= br>
EDB: http= s://www.enterprisedb.com



--
Thanks,
Aditya Toshniwal=
pgAdmin hacker=C2=A0| Sr. Software Engineer | edbpostgres.com
&quo= t;Don't Complain about Heat, Plant a TREE"


--
Rahul Shirsat
Senior Software Engin= eer=C2=A0|=C2=A0EnterpriseDB=C2=A0Corporation.


--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake<= br>
EDB: http= s://www.enterprisedb.com



--
Thanks,
Aditya Toshniwal=
pgAdmin hacker=C2=A0| Sr. Software Engineer | edbpostgres.com
&quo= t;Don't Complain about Heat, Plant a TREE"


--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake<= br>
EDB: http= s://www.enterprisedb.com



--
Thanks,
Aditya Toshniwal=
pgAdmin hacker=C2=A0| Sr. Software Engineer | edbpostgres.com
&quo= t;Don't Complain about Heat, Plant a TREE"


--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake<= br>
EDB: http= s://www.enterprisedb.com



--
Rahul Shirsat
Senior Software Engin= eer=C2=A0|=C2=A0EnterpriseDB=C2=A0Corporation.


--
Rahul Shirsat
Senior Software Engineer=C2=A0|=C2=A0EnterpriseDB=C2=A0Corporation.=
--0000000000005dbe0d05c5f6ace9-- --0000000000005dbe0f05c5f6aceb Content-Type: application/octet-stream; name="jenkins_failure_fix_v4.patch" Content-Disposition: attachment; filename="jenkins_failure_fix_v4.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kqj5pdzc0 ZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL2Jyb3dzZXIvc2VydmVyX2dyb3Vwcy9zZXJ2ZXJzL3Jv bGVzL3N0YXRpYy9qcy9yb2xlLmpzIGIvd2ViL3BnYWRtaW4vYnJvd3Nlci9zZXJ2ZXJfZ3JvdXBz L3NlcnZlcnMvcm9sZXMvc3RhdGljL2pzL3JvbGUuanMKaW5kZXggNTU3ZTQ0YjdhLi43NWI1YWNj OWMgMTAwNjQ0Ci0tLSBhL3dlYi9wZ2FkbWluL2Jyb3dzZXIvc2VydmVyX2dyb3Vwcy9zZXJ2ZXJz L3JvbGVzL3N0YXRpYy9qcy9yb2xlLmpzCisrKyBiL3dlYi9wZ2FkbWluL2Jyb3dzZXIvc2VydmVy X2dyb3Vwcy9zZXJ2ZXJzL3JvbGVzL3N0YXRpYy9qcy9yb2xlLmpzCkBAIC03NjAsMzEgKzc2MCwz NyBAQCBkZWZpbmUoJ3BnYWRtaW4ubm9kZS5yb2xlJywgWwogCiAgICAgICAgICAgICAgICAgICBs ZXQgcm9sZVJlYXNzaWduRGF0YSA9IHRoaXMudmlldy5tb2RlbC50b0pTT04oKSwKICAgICAgICAg ICAgICAgICAgICAgcm9sZU9wID0gcm9sZVJlYXNzaWduRGF0YS5yb2xlX29wLAotICAgICAgICAg ICAgICAgICAgICBjb25maXJtQm94VGl0bGUgPSB1dGlscy50aXRsZWl6ZShyb2xlT3ApOwotCi0g ICAgICAgICAgICAgICAgICBhbGVydGlmeS5jb25maXJtKAotICAgICAgICAgICAgICAgICAgICBn ZXR0ZXh0KCclcyBPYmplY3RzJywgY29uZmlybUJveFRpdGxlKSwKLSAgICAgICAgICAgICAgICAg ICAgZ2V0dGV4dCgnQXJlIHlvdSBzdXJlIHlvdSB3aXNoIHRvICVzIGFsbCB0aGUgb2JqZWN0cyBv d25lZCBieSB0aGUgc2VsZWN0ZWQgcm9sZT8nLCByb2xlT3ApLAotICAgICAgICAgICAgICAgICAg ICBmdW5jdGlvbigpIHsKLSAgICAgICAgICAgICAgICAgICAgICBheGlvcy5wb3N0KAotICAgICAg ICAgICAgICAgICAgICAgICAgZmluYWxVcmwsCi0gICAgICAgICAgICAgICAgICAgICAgICByb2xl UmVhc3NpZ25EYXRhCi0gICAgICAgICAgICAgICAgICAgICAgKS50aGVuKGZ1bmN0aW9uIChyZXNw b25zZSkgewotICAgICAgICAgICAgICAgICAgICAgICAgaWYocmVzcG9uc2UuZGF0YSkKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgYWxlcnRpZnkuc3VjY2VzcyhyZXNwb25zZS5kYXRhLmluZm8p OwotICAgICAgICAgICAgICAgICAgICAgIH0pLmNhdGNoKGZ1bmN0aW9uIChlcnJvcikgewotICAg ICAgICAgICAgICAgICAgICAgICAgdHJ5IHsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c3QgZXJyID0gZXJyb3IucmVzcG9uc2UuZGF0YTsKLSAgICAgICAgICAgICAgICAgICAgICAgICAg YWxlcnRpZnkuYWxlcnQoCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2V0dGV4dCgnUm9s ZSByZWFzc2lnbi9kcm9wIGZhaWxlZC4nKSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBl cnIuZXJyb3Jtc2cKLSAgICAgICAgICAgICAgICAgICAgICAgICAgKTsKLSAgICAgICAgICAgICAg ICAgICAgICAgIH0gY2F0Y2ggKGUpIHsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc29s ZS53YXJuKGUuc3RhY2sgfHwgZSk7Ci0gICAgICAgICAgICAgICAgICAgICAgICB9Ci0gICAgICAg ICAgICAgICAgICAgICAgfSk7Ci0gICAgICAgICAgICAgICAgICAgIH0sCi0gICAgICAgICAgICAg ICAgICAgIGZ1bmN0aW9uKCkgeyByZXR1cm4gdHJ1ZTsgfQorICAgICAgICAgICAgICAgICAgICB0 aXRsZSwgbXNnOworCisgICAgICAgICAgICAgICAgICBpZihyb2xlT3AgPT0gJ3JlYXNzaWduJykg eworICAgICAgICAgICAgICAgICAgICB0aXRsZSA9IGdldHRleHQoJ1JlYXNzaWduIE9iamVjdHMn KTsKKyAgICAgICAgICAgICAgICAgICAgbXNnID0gZ2V0dGV4dCgnQXJlIHlvdSBzdXJlIHlvdSB3 aXNoIHRvIHJlYXNzaWduIGFsbCB0aGUgb2JqZWN0cyBvd25lZCBieSB0aGUgc2VsZWN0ZWQgcm9s ZT8nKTsKKyAgICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICAgIGVsc2UgeworICAg ICAgICAgICAgICAgICAgICB0aXRsZSA9IGdldHRleHQoJ0Ryb3AgT2JqZWN0cycpOworICAgICAg ICAgICAgICAgICAgICBtc2cgPSBnZXR0ZXh0KCdBcmUgeW91IHN1cmUgeW91IHdpc2ggdG8gZHJv cCBhbGwgdGhlIG9iamVjdHMgb3duZWQgYnkgdGhlIHNlbGVjdGVkIHJvbGU/Jyk7CisgICAgICAg ICAgICAgICAgICB9CisKKyAgICAgICAgICAgICAgICAgIGFsZXJ0aWZ5LmNvbmZpcm0odGl0bGUs IG1zZywgZnVuY3Rpb24oKSB7CisgICAgICAgICAgICAgICAgICAgIGF4aW9zLnBvc3QoCisgICAg ICAgICAgICAgICAgICAgICAgZmluYWxVcmwsCisgICAgICAgICAgICAgICAgICAgICAgcm9sZVJl YXNzaWduRGF0YQorICAgICAgICAgICAgICAgICAgICApLnRoZW4oZnVuY3Rpb24gKHJlc3BvbnNl KSB7CisgICAgICAgICAgICAgICAgICAgICAgaWYocmVzcG9uc2UuZGF0YSkKKyAgICAgICAgICAg ICAgICAgICAgICAgIGFsZXJ0aWZ5LnN1Y2Nlc3MocmVzcG9uc2UuZGF0YS5pbmZvKTsKKyAgICAg ICAgICAgICAgICAgICAgfSkuY2F0Y2goZnVuY3Rpb24gKGVycm9yKSB7CisgICAgICAgICAgICAg ICAgICAgICAgdHJ5IHsKKyAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGVyciA9IGVycm9y LnJlc3BvbnNlLmRhdGE7CisgICAgICAgICAgICAgICAgICAgICAgICBhbGVydGlmeS5hbGVydCgK KyAgICAgICAgICAgICAgICAgICAgICAgICAgZ2V0dGV4dCgnUm9sZSByZWFzc2lnbi9kcm9wIGZh aWxlZC4nKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgZXJyLmVycm9ybXNnCisgICAgICAg ICAgICAgICAgICAgICAgICApOworICAgICAgICAgICAgICAgICAgICAgIH0gY2F0Y2ggKGUpIHsK KyAgICAgICAgICAgICAgICAgICAgICAgIGNvbnNvbGUud2FybihlLnN0YWNrIHx8IGUpOworICAg ICAgICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICAgICAgfSk7CisgICAgICAgICAg ICAgICAgICB9LAorICAgICAgICAgICAgICAgICAgZnVuY3Rpb24oKSB7IHJldHVybiB0cnVlOyB9 CiAgICAgICAgICAgICAgICAgICApLnNldCgnbGFiZWxzJywgewogICAgICAgICAgICAgICAgICAg ICBvazogZ2V0dGV4dCgnWWVzJyksCiAgICAgICAgICAgICAgICAgICAgIGNhbmNlbDogZ2V0dGV4 dCgnTm8nKSwK --0000000000005dbe0f05c5f6aceb--