From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call Date: Sat, 31 Aug 2024 17:54:05 -0700 Message-ID: References: <4e44df18-207c-c7ca-0588-7285f3008dfb@yandex.ru> <358bbd65-9375-04c8-f0a2-24a4383f142e@yandex.ru> <2b4a91e1-bad1-382f-dd64-abf171efb404@yandex.ru> <60e207e0-7378-ad9f-3ef0-99df1c139939@yandex.ru> <902440c7-706a-20e1-55af-4e12e8cdda2c@yandex.ru> <1191195d-1528-dc2a-64e0-15426e4b5608@yandex.ru> <75342f40-d576-e1c6-3d63-692b80e78bfe@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000eb2fac0621044239" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37781"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60321@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 01 02:56:28 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1skYtI-0009h6-Gh for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Sep 2024 02:56:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1skYsy-0006em-OM; Sat, 31 Aug 2024 20:56:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1skYsu-0006e7-VU for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 20:56:05 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1skYsu-0002PT-0a for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 20:56:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:References:In-Reply-To:Mime-Version:To:Subject; bh=S6mGws4g2xMRXK9tS4tJW/AZ0jGGkGSHZ6wiATjYpiM=; b=FXLE5MGMMKwhfdKxh5EG8t0SFuYScx4kYuwndetbWIZEbRXkBTvmtTjF3eOla31uXYyh5W+6hUxW9/JI6AYfGoLCQjsgCMD3kmc2pDsUQNLWR1vek8yL8r3e+DEm/D3xQZA5JyL8savjVQvg6MjszeSTkwZmdpko+/EA2gQ2I0IO7uOqbKDrAbfsqXGRQgtnXoHAxM2XXDAqsngUrXwnhY6Osmx3fMCmBqHniJ3EkszOkephTkAC40sbJwDGpHAACF+bLcSR02u4oS99g8DQI8FWQhuxKh9HjLaxLU9bWssHg9oQwpQmydM3ParFQIjnw0ScJXd0OSqoIpN9FMYBqw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1skYtq-0002mz-HH for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 20:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Sep 2024 00:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60321 X-GNU-PR-Package: emacs Original-Received: via spool by 60321-submit@debbugs.gnu.org id=B60321.172515217510658 (code B ref 60321); Sun, 01 Sep 2024 00:57:02 +0000 Original-Received: (at 60321) by debbugs.gnu.org; 1 Sep 2024 00:56:15 +0000 Original-Received: from localhost ([127.0.0.1]:58851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skYt4-0002lq-QJ for submit@debbugs.gnu.org; Sat, 31 Aug 2024 20:56:15 -0400 Original-Received: from mail-lj1-f169.google.com ([209.85.208.169]:51525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skYt1-0002lZ-Vv for 60321@debbugs.gnu.org; Sat, 31 Aug 2024 20:56:13 -0400 Original-Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2f50966c469so34302591fa.3 for <60321@debbugs.gnu.org>; Sat, 31 Aug 2024 17:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725152047; x=1725756847; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cYepKd2G3hCcgUksE9VAqowxaMCOmUXjSGGOxG3o7Jo=; b=GkRN7uxa2yx58yKcOrI9mlTuaU3Qf8yz0lNDIoJqqEqU4SUt2XSiU3q9GzK2L8hnwm afiAlTvbMRT1CXwd7GqaWA6ydOziGvjo7iT19MUTm7Mtvj1WxG+nkgP5AtJ1PjT6bKKj /6bnUruAT6Qq+1VG+wmFPNPto1REEoJ0L3sWzPcomYShzDYamz3cN6fBsVqBY186x6ZE n/T3AIjsv2DoIFuwXyPZdGB7WFX7dEgTkmDLmN/X1va05JjCbgAKzdaqbx10oOLt2gYr 9SuMEg68HaWvKZfTeABq/pNOBA970k/OtC4b8lZACb+gED9egxjW8Xz79vsgVKRtMpMS /54g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725152047; x=1725756847; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cYepKd2G3hCcgUksE9VAqowxaMCOmUXjSGGOxG3o7Jo=; b=gYdK5+a8p+Xr0hf+2yheLVDckxZmv079tcrbzKxhowIA+aZ1gGyOioOy+AmOanewd1 6oUgSW5WVg/IjK+jWIvUEBJ9TNVcny9GaBLpNgb37NKGa/R30JjjXqMPJqO4VtyE29cZ BpK5o9aA6a8jTtqFHx6MVL4OG8AxPYfPZtByEsyCEyiji1ti9DSq8nldtBirmZQIfh54 tUod+zXkLwC8pLOXvD+KGhJthr77fXYDpL2Z5nwQtLxdHIEL8YA4eDMwjaUlkNgpOVlp IpTp74h48lZ2DCHCNSOyWWQ4eNVtH4iOKR2VGzDzD1EMAzXXjhJEV3OlM/hZzVtlRvzZ fa6Q== X-Gm-Message-State: AOJu0Yyyqk7RJ+RllCxXmm7OP0+D7DNCA4BF/auoJXJYD7DdFfwfHdbX L63ABe51E595dH/K0f0vLPgnSj1vbBed5FrBw7xr0o1V2nlRIomosCwbmSyfJa1n50mwCdTH9c3 q3RZahRPsOURiBn3fjRCFedMj2UE= X-Google-Smtp-Source: AGHT+IE3vrJyzW3q5WnOy+56BEO869626MUDKYxnn0zEUms7cQy6SzSqgDfBKam15I2i3deExVQcYok/Gtkgw1NSVIc= X-Received: by 2002:a05:651c:221f:b0:2ef:2f9e:dd1b with SMTP id 38308e7fff4ca-2f6290400c5mr20801171fa.14.1725152046551; Sat, 31 Aug 2024 17:54:06 -0700 (PDT) Original-Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 31 Aug 2024 17:54:05 -0700 X-Superhuman-Draft-ID: draft004d1b0b67d5cb9c In-Reply-To: X-Mailer: Superhuman Desktop (2024-08-30T19:05:53Z) X-Superhuman-ID: m0iuz15s.7750ee11-3d61-4365-933f-bd4e4dd1aeb4 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291036 Archived-At: --000000000000eb2fac0621044239 Content-Type: multipart/alternative; boundary="000000000000eb2fa90621044237" --000000000000eb2fa90621044237 Content-Type: text/plain; charset="UTF-8" Updated patch with more precise variables in the new test. Aaron On Sat, Aug 31, 2024 at 7:41 PM, Aaron Jensen wrote: > I made an attempt at this (attached). It introduces a new variable: > > ruby-bracketed-args-indent > > It is set to t by default and the behavior will be as it was before this > patch. > > If it is something other than t, it will cause enable indentation like > this: > > update({ > key => value, > other_key: > }, { > key => value, > other_key: > }) > > update([ > 1, > 2 > ], [ > 3, > 4 > ]) > > It does not handle cases such as: > > some_method({ > key: :value > }, > other_argument) > > It will indent other_argument to be aligned with the (. This could be > elaborated further, but I contend that if people are formatting their code > this way that they likely have rather idiosyncratic formatting requirements > and they would be best left to do what they want manually. > > Thanks, > > > Aaron > > > On Mon, Dec 26, 2022 at 8:38 PM, Aaron Jensen > wrote: > > On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov wrote: > > Vim's choice looks saner to my eye. Probably comes down to the choice of > indentation algorithm, though. > > Agreed, though it's hard to pick which is more sane when all the options > start with insanity. > > If I had to type it as above, I would probably indent it like this: > > and_in_a_method_call({ > no: :difference > }, > foo, > bar) > > But I can't imagine that would be easy to implement at all, so I wouldn't > bother. > > The indentation logic itself might be not that difficult to write, but the > fact that the expression will have to be reindented as soon as the method > call grows a second argument (after the user types the comma?), makes it a > hard sell usability-wise. > > Right, I think that's just more of the same thing... We are looking at > ways of writing code that are out of the realm of reason. It's a challenge > to define behavior when the behavior could very well be undefined. But, if > we must define it, then what are our guiding principles? Not having to > reindent preceding lines when adding a new line may be a very reasonable > one. In that case, the only two options I could think of would be: > > and_in_a_method_call({ > no: :difference > }, > foo, > bar) > > or > > and_in_a_method_call({ > no: :difference > }, > foo, > bar) > > The difference being if we decide to dedent upon the last closing > indent-requiring-token or the first. > > I think a reasonable rule of thumb for a human might be: "If you open N > indents on one line, you must close N indents on one line". Any time you > stray away from this, behavior becomes... not ideal. > > Aaron > > --000000000000eb2fa90621044237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Updated patch with = more precise variables in the new test.


Aaron


On Sat, Aug 31, 2024 at 7:41 PM, Aaron Jensen <= aaronjensen@gmail.com> wrote:
I made an attempt at this (attached). It introduces a new varia= ble:

ruby-bracketed-args-indent

It is set to t by default and the behavior will be as it was before this= patch.

If it is something other than t, it will caus= e enable indentation like this:

update({
=C2=A0 key =3D> value,
=C2=A0 other_key:
}, {
=C2=A0 key =3D> value,
=C2=A0 other_key:
})
=

update([
=C2=A0 1,
=C2=A0 2
], [
=C2=A0 3,
])

It does not handle cases such as:

some_metho= d({
=C2=A0 key: :value
},
other_argument)

It will indent other_argument to= be aligned with=C2=A0the (. This could be elaborated further, but I conten= d that if people are formatting their code this way that they likely have r= ather idiosyncratic formatting=C2=A0requirements and they would be best lef= t to do what they want manually.

Thanks,=C2=A0=


Aaron


On Mon, Dec 26, = 2022 at 8:38 PM, Aaron Jensen <aaronjensen@= gmail.com> wrote:

On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

Vim's choice looks saner to my eye. Probably comes down to the choice o= f indentation algorithm, though.

Agreed, though it's hard to pick which is more sane when all the options start with insanity.

If I had to type it as above, I would probably indent it like this:

and_in_a_method_call({
no: :difference
},
foo,
bar)

But I can't imagine that would be easy to implement at all, so I wouldn't bother.

The indentation logic itself might be not that difficult to write, but the fact that the expression will have to be reindented as soon as the method call grows a second argument (after the user types the comma?), makes it a hard sell usability-wise.

Right, I think that's just more of the same thing... We are looking at ways of writing code that are out of the realm of reason. It's a challenge to define behavior when the behavior could very well be undefined. But, if we must define it, then what are our guiding principles? Not having to reindent preceding lines when adding a new line may be a very reasonable one. In that case, the only two options I could think of would be:

and_in_a_method_call({
no: :difference
},
foo,
bar)

or

and_in_a_method_call({
no: :difference
},
foo,
bar)

The difference being if we decide to dedent upon the last closing indent-requiring-token or the first.

I think a reasonable rule of thumb for a human might be: "If you open N indents on one line, you must close N indents on one line". Any time you stray away from this, behavior becomes... not ideal.

Aaron


--000000000000eb2fa90621044237-- --000000000000eb2fac0621044239 Content-Type: application/octet-stream; name="0001-Add-ruby-bracketed-argument-indentation-option.patch" Content-Disposition: attachment; filename="0001-Add-ruby-bracketed-argument-indentation-option.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: 66b3f9adc71b171d_0.1 RnJvbSAxYjU4MjZkZGE0ZmY4ZDAxNGQzN2Y5MGIyMjU2OWUzNzZkYjg1Mjk2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBYXJvbiBKZW5zZW4gPGFhcm9uamVuc2VuQGdtYWlsLmNvbT4K RGF0ZTogU2F0LCAzMSBBdWcgMjAyNCAxOTozMToyMCAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIEFk ZCBydWJ5IGJyYWNrZXRlZCBhcmd1bWVudCBpbmRlbnRhdGlvbiBvcHRpb24KCiogbGlzcC9wcm9n bW9kZXMvcnVieS1tb2RlLmVsIChydWJ5LWJyYWNrZXRlZC1hcmdzLWluZGVudCksCihydWJ5LXNt aWUtcnVsZXMpOiBOZXcgb3B0aW9uCiogdGVzdC9saXNwL3Byb2dtb2Rlcy9ydWJ5LW1vZGUtcmVz b3VyY2VzL3J1YnktYnJhY2tldGVkLWFyZ3MtaW5kZW50LnJiOgoqIHRlc3QvbGlzcC9wcm9nbW9k ZXMvcnVieS1tb2RlLXRlc3RzLmVsCiAgKCJydWJ5LXBhcmVubGVzcy1jYWxsLWFyZ3VtZW50cy1p bmRlbnQucmIiKTogTmV3IHRlc3QgY2FzZQotLS0KIGxpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5l bCAgICAgICAgICAgICAgICAgICB8IDIzICsrKysrKysrKysrKysKIC4uLi9ydWJ5LWJyYWNrZXRl ZC1hcmdzLWluZGVudC5yYiAgICAgICAgICAgICB8IDMyICsrKysrKysrKysrKysrKysrKysKIHRl c3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXRlc3RzLmVsICAgICAgICB8ICAxICsKIDMgZmls ZXMgY2hhbmdlZCwgNTYgaW5zZXJ0aW9ucygrKQogY3JlYXRlIG1vZGUgMTAwNjQ0IHRlc3QvbGlz cC9wcm9nbW9kZXMvcnVieS1tb2RlLXJlc291cmNlcy9ydWJ5LWJyYWNrZXRlZC1hcmdzLWluZGVu dC5yYgoKZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5lbCBiL2xpc3AvcHJv Z21vZGVzL3J1YnktbW9kZS5lbAppbmRleCAzYmNmYTllZTdkZi4uODVjZGNlMzk5MzcgMTAwNjQ0 Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9y dWJ5LW1vZGUuZWwKQEAgLTQ3Miw2ICs0NzIsMjYgQEAgcnVieS1wYXJlbmxlc3MtY2FsbC1hcmd1 bWVudHMtaW5kZW50CiAgIDpzYWZlICdib29sZWFucAogICA6dmVyc2lvbiAiMjkuMSIpCiAKKyhk ZWZjdXN0b20gcnVieS1icmFja2V0ZWQtYXJncy1pbmRlbnQgdAorICAiTm9uLW5pbCB0byBhbGln biB0aGUgY29udGVudHMgb2YgYnJhY2tldGVkIGFyZ3VtZW50cyB3aXRoIHRoZSBicmFja2V0cy4K KworRXhhbXBsZToKKworICBxdXgoeworICAgICAgIGZvbyA9PiBiYXIKKyAgICAgfSkKKworU2V0 IGl0IHRvIG5pbCB0byBhbGlnbiB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzdGF0ZW1lbnQ6CisK KyAgcXV4KHsKKyAgICBmb28gPT4gYmFyCisgIH0pCisKK09ubHkgaGFzIGVmZmVjdCB3aGVuIGBy dWJ5LXVzZS1zbWllJyBpcyB0LiIKKyAgOnR5cGUgJ2Jvb2xlYW4KKyAgOnNhZmUgJ2Jvb2xlYW5w CisgIDp2ZXJzaW9uICIzMS4xIikKKwogKGRlZmN1c3RvbSBydWJ5LWRlZXAtYXJnbGlzdCB0CiAg ICJEZWVwIGluZGVudCBsaXN0cyBpbiBwYXJlbnRoZXNpcyB3aGVuIG5vbi1uaWwuCiBBbHNvIGln bm9yZXMgc3BhY2VzIGFmdGVyIHBhcmVudGhlc2lzIHdoZW4gYHNwYWNlJy4KQEAgLTgyNiw2ICs4 NDYsOSBAQCBydWJ5LXNtaWUtcnVsZXMKICAgICAgICkpCiAgICAgKGAoOmJlZm9yZSAuICwob3Ig IigiICJbIiAieyIpKQogICAgICAoY29uZAorICAgICAgKChhbmQgKG5vdCAoZXEgcnVieS1icmFj a2V0ZWQtYXJncy1pbmRlbnQgdCkpCisgICAgICAgICAgICAoc21pZS1ydWxlLXByZXYtcCAiLCIg IigiICJbIikpCisgICAgICAgKGNvbnMgJ2NvbHVtbiAoY3VycmVudC1pbmRlbnRhdGlvbikpKQog ICAgICAgKChhbmQgKGVxdWFsIHRva2VuICJ7IikKICAgICAgICAgICAgIChub3QgKHNtaWUtcnVs ZS1wcmV2LXAgIigiICJ7IiAiWyIgIiwiICI9PiIgIj0iICJyZXR1cm4iICI7IiAiZG8iKSkKICAg ICAgICAgICAgIChzYXZlLWV4Y3Vyc2lvbgpkaWZmIC0tZ2l0IGEvdGVzdC9saXNwL3Byb2dtb2Rl cy9ydWJ5LW1vZGUtcmVzb3VyY2VzL3J1YnktYnJhY2tldGVkLWFyZ3MtaW5kZW50LnJiIGIvdGVz dC9saXNwL3Byb2dtb2Rlcy9ydWJ5LW1vZGUtcmVzb3VyY2VzL3J1YnktYnJhY2tldGVkLWFyZ3Mt aW5kZW50LnJiCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwLi5hYzdhNzM0 NjNiZgotLS0gL2Rldi9udWxsCisrKyBiL3Rlc3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXJl c291cmNlcy9ydWJ5LWJyYWNrZXRlZC1hcmdzLWluZGVudC5yYgpAQCAtMCwwICsxLDMyIEBACit1 cGRhdGUoeworICBrZXkgPT4gdmFsdWUsCisgIG90aGVyX2tleToKK30sIHsKKyAga2V5ID0+IHZh bHVlLAorICBvdGhlcl9rZXk6Cit9KQorCit1cGRhdGUoWworICAxLAorICAyCitdLCBbCisgIDMs CisgIDQKK10pCisKK3VwZGF0ZShbeworICBrZXk6ICJ2YWx1ZSIKK30sIHsKKyAga2V5OiAidmFs dWUiCit9XSkKKwordXBkYXRlKGFyZzEsIHsKKyAgZm9vOiAiYmFyIgorfSwgWworICAxLAorICAy CitdLCBhcmcyKQorCisjIExvY2FsIFZhcmlhYmxlczoKKyMgcnVieS1icmFja2V0ZWQtYXJncy1p bmRlbnQ6IG5pbAorIyBFbmQ6CmRpZmYgLS1naXQgYS90ZXN0L2xpc3AvcHJvZ21vZGVzL3J1Ynkt bW9kZS10ZXN0cy5lbCBiL3Rlc3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXRlc3RzLmVsCmlu ZGV4IDJiODUwNmE3YWRjLi5jOWNkZTc5MWJhYSAxMDA2NDQKLS0tIGEvdGVzdC9saXNwL3Byb2dt b2Rlcy9ydWJ5LW1vZGUtdGVzdHMuZWwKKysrIGIvdGVzdC9saXNwL3Byb2dtb2Rlcy9ydWJ5LW1v ZGUtdGVzdHMuZWwKQEAgLTk5Miw2ICs5OTIsNyBAQCAicnVieS1ibG9jay1pbmRlbnQucmIiCiAo cnVieS1kZWZ0ZXN0LWluZGVudCAicnVieS1tZXRob2QtY2FsbC1pbmRlbnQucmIiKQogKHJ1Ynkt ZGVmdGVzdC1pbmRlbnQgInJ1YnktbWV0aG9kLXBhcmFtcy1pbmRlbnQucmIiKQogKHJ1YnktZGVm dGVzdC1pbmRlbnQgInJ1YnktcGFyZW5sZXNzLWNhbGwtYXJndW1lbnRzLWluZGVudC5yYiIpCiso cnVieS1kZWZ0ZXN0LWluZGVudCAicnVieS1icmFja2V0ZWQtYXJncy1pbmRlbnQucmIiKQogCiAo ZXJ0LWRlZnRlc3QgcnVieS0tdGVzdC1jaGFpbmVkLWluZGVudGF0aW9uICgpCiAgICh3aXRoLXRl bXAtYnVmZmVyCi0tIAoyLjQyLjEKCg== --000000000000eb2fac0621044239--