From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#35771: [PATCH] Customization type of recentf-max-saved-items Date: Sat, 18 May 2019 16:10:46 -0700 (PDT) Message-ID: <11926b48-89a8-47f9-bce9-f71ad6aa2a57@default> References: <87pnohb79x.fsf@gmail.com> <42941bba-e6b4-4a46-b56f-97ffcfc2117f@default> <87woipupuy.fsf@tcd.ie> <87r28vwvh4.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="__1558221048002289683abhmp0017.oracle.com" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="207541"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Dario Gjorgjevski , 35771@debbugs.gnu.org To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 19 01:13:24 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hS8W3-000rsV-Gw for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 May 2019 01:13:23 +0200 Original-Received: from localhost ([127.0.0.1]:39634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hS8W2-0004NV-1m for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 May 2019 19:13:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hS8Vo-0004NN-AD for bug-gnu-emacs@gnu.org; Sat, 18 May 2019 19:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hS8Uk-0004eL-SU for bug-gnu-emacs@gnu.org; Sat, 18 May 2019 19:12:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47905) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hS8Uk-0004eD-KH for bug-gnu-emacs@gnu.org; Sat, 18 May 2019 19:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hS8Uk-0003vF-En for bug-gnu-emacs@gnu.org; Sat, 18 May 2019 19:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 May 2019 23:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35771 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35771-submit@debbugs.gnu.org id=B35771.155822106914988 (code B ref 35771); Sat, 18 May 2019 23:12:02 +0000 Original-Received: (at 35771) by debbugs.gnu.org; 18 May 2019 23:11:09 +0000 Original-Received: from localhost ([127.0.0.1]:33209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hS8Tt-0003tf-6a for submit@debbugs.gnu.org; Sat, 18 May 2019 19:11:09 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:41246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hS8Tp-0003t6-SY for 35771@debbugs.gnu.org; Sat, 18 May 2019 19:11:08 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4IN9Cem148440; Sat, 18 May 2019 23:10:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type; s=corp-2018-07-02; bh=zV3Q/lznqkxQQ9iX3q5hvdNk/XUlfFffpawkT8idWAE=; b=tWYeK0No7KwBKO6bTCgLiSWIJXQQlqGYDKer3axqiVvcBG0yLUhj4gHaB63xaHL7K+d/ bdPhyrlnp0YsFdbMWLmtSZZFMNhTqb64TJ3Vp0E/zubOH5uc0nAPW8hlP2PUvM5Ju2w2 3KkjikekgW82JaDusgojsoWcjJ8l6iVlkZCgszy9tNcPFKTBhVvPLy6bAv8ZYMPYwAUQ R1SyblgQRvQJLgjgy+vyuFOXKaHt0Fnm8Na7mF9UiH5ChpitBwG/TxGZ2glP2uEWLbwu JJCNHITlK69fhT5OyFkAuM3yK30dc1jQXMkcrQWJDXjGjz/2U1w3Gt8NejXTV4jhsUAi KA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2sj9ft1uyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 May 2019 23:10:57 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4IN9XYl182854; Sat, 18 May 2019 23:10:56 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2sj839ypx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 May 2019 23:10:56 +0000 Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x4INAmYZ023381; Sat, 18 May 2019 23:10:50 GMT In-Reply-To: <87r28vwvh4.fsf@tcd.ie> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4849.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9261 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905180167 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9261 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905180167 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159514 Archived-At: --__1558221048002289683abhmp0017.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > >> I don't know whether this has been discussed before, but it seems more > >> suited for emacs-devel or its own bug report, rather than the current > >> one. > > > > Well, it certainly also applies to this bug report, I think, > > which is purportedly about the "Customization _type_ of > > recentf-max-saved-items". >=20 > Sure, but it applies also to all other user options of a similar nature, Irrelevant here. This is no different from suggesting clearer or more correct doc-string wording or fixing an off-by-one error. It pertains to _this_ bug. Whether there might be other, similar bugs is irrelevant to whether it should be taken into account for fixing this one. > and concerns a potential change in general Elisp conventions, What potential change would that be? Is there some existing Elisp convention that says :type should be mistyped or should be the loosest possible type in preference to the most accurate type? Does some convention recommend omitting :type altogether, to keep things simple? > so I would rather it were discussed on its own > and with other people included, and any conclusions > reported as wishlists and/or documented. Don't know what you're aiming for. There's no reason not to fix this bugged occurrence just because you also see the possibility that similar problems can exist elsewhere. I already provided simple code to fix this one. What's the problem? Why not help users now by letting Customize properly support the allowable/ expected set of values for this option? > > see, again, the Subject line - why not fix it right? >=20 > This bug report is about fixing the custom :type to include nil as an > accepted value, which the submitted patch fixes in a way suitable for > inclusion in emacs-26. I would rather we dealt with one issue at a > time. Then please fix it properly in a second step, if you prefer. There's no need for you (or me) to file another report to get the customization type fixed as it should be for this option. > in this case there is nothing wrong with using the integer type. Nothing wrong with using `number' either, in that case. Nothing wrong with using `sexp' either, in that case. If you don't want to specify the type then don't specify the type - anything at all will do: nothing wrong, as you say. To me that flies in the face of why we even have :type. But hey - we _don't_ have :type! It's optional. Who needs pesky old :type? Do as you like, including doing nothing. > > Use of `restricted-sexp' should be encouraged when it's > > _needed_, and that's when the type is not currently as > > restrictive as it should be AND there is no simpler way > > to define the more accurate type. > > > > That's the point. What we have today is not people > > avoiding/discouraging use of `restricted-sexp' in > > favor of just-as-useful, just-as-accurate, but simpler > > :type specs. We have people not using `restricted-sexp' > > out of ignorance of it, or perhaps out of laziness. > > (That's my guess, until convinced otherwise.) >=20 > FWIW, I am neither ignorant of it, nor too lazy to use it; rather, in my > limited experience, I have yet to author or review a case where it is > truly "needed", this report included. Tautology, if you define "truly needed" by never needed at all, which seems to be your point of view. But if that's not really your view, what would you say is "needed" in the attached cases (from my code)? `sexp'? Something more than `sexp', but avoiding `restricted-sexp' (what)? Would you submit a bug report for each case, to add new simple types to avoid use of `restricted-sexp'? When do you think `restricted-sexp' should be used? It sounds like the answer is "never". Since Lisp does not have typed variables (it does have typed values, of course), I suppose you'd just rely on the doc string as sole help for users trying to customize the value. Is that it? > Existing precedent says the integer type is fine even when dealing with > nonnegative sizes. If you prefer to use a more accurate natnum type in > these cases, which I sympathise with, then please submit a feature > request for this, if one does not already exist. I think it is wrong to > start using restricted-sexp to emulate a natnum type in an ad hoc way. With that point of view the `sexp' type is fine when dealing with _any_ defcustom. It will surely help avoid the danger of "overspecifying". Go for it. IMO "existing precedent" when it comes to defcustom is sometimes not so great. Just like some developers don't spend enough attention on doc strings, so some don't spend enough attention on defcustom types. (This bug report is a case in point, no?) That's one reason users give up on using Customize: it's too often not so helpful (no completion when completion could help, for example). We've fixed some such oversights in the past, but there are likely more. Emacs developers themselves have been clear now and then that they mostly don't use Customize, and that shows in the lack of love and attention they give defcustoms sometimes. Emacs can help users more. > > As for "not everyone uses Customize" - that's irrelevant > > here. This is about those who do use it, obviously. > > It's about the :type spec of a defcustom. >=20 > It is not irrelevant. First, authors cannot rely on the custom :type > alone to tell users what qualifies as an expected value;=20 That has nothing to do with "not everyone uses Customize". Even if everyone did use Customize you would not be able to rely on :type alone to tell users what values are acceptable. And no one has said that one can, or should be able to, rely on :type alone. Totally a red herring. You may not see it as irrelevant, but I do. > the docstring must also contain this information. You make it sound like having to describe the type of the option is an unfortunate _extra_ thing that authors have to do. It's not. A doc string is a normal part of defun, defvar, defconst, defmacro, etc. (Just because `interactive' might control input values, that doesn't mean that we don't need to also document them in the doc string. Code controlling things properly doesn't obviate the need for user help. Nothing replaces doc strings.) Having to describe the accepted value types in the doc string is a red herring - unrelated to the separate need to specify a proper :type. In one case you're talking directly to the user. In the other case you're communicating to Customize (which in turn talks to the user in its own way). > This encourages writing better docstrings=20 What? What encourages writing better doc strings? Not having good :type values? By that logic `sexp' will be ideal as :type, _really_ encouraging good doc strings. Just don't use :type at all - get great doc. > and is how users may know not to set recentf-max-saved-items > to a negative number, regardless of whether its custom :type is integer > or natnum. Emacs customisations have worked fine like this until now. Again, if your argument is that doc strings alone suffice and are the best way or the only good way to specify the type, then :type 'sexp is called for in all cases (or just don't use :type ever, which amounts to the same thing). > Second, application code must work correctly regardless of the custom > :type. Again, irrelevant. Of course it must work correctly. Doc strings are needed anyway. And code must work correctly anyway. So what? How does either of those requirements suggest that we don't need to tell Customize what the :type is? > Since Elisp is not a strongly typed language, the programmer can > only assume that the user has understood the docstring and hasn't set > the user option to a silly value. Why do you think defcustom has a :type at all? Was adding that just misguided "overspecifying" by some overeager implementor? > > More accurate defcustoms, using more appropriate :type > > specs, and sometimes using :set etc., is something we > > should encourage. Customize and defcustoms could use > > more love by Emacs developers, not less. >=20 > As long as "more love" means smarter, not more, use, then I agree. It means using :type to specify the relevant/good values; :set to specify any special behavior needed each time it is set; :init to specify any special behavior needed when it's initialized; correct and complete doc strings to help users understand what the option is for - what the option does/means; and so on. That you _can_ get away with specifying a minimal :type is not a reason to do so. That Lisp variables are untyped is not a reason not to specify and document the expected/allowed values. > > Using an accurate :type spec doesn't limit/hurt users. > > It helps them. Likewise, using a widget edit field > > that provides completion when appropriate etc. >=20 > Agreed. A good start. > >> FWIW, my vote is against both trying to overspecify custom types, and > >> using restricted-sexp for such simple examples. > > > > "Overspecify"? "Trying to overspecify"? Please elaborate. > > The value should be a natural number (or perhaps a positive > > integer), no? How is specifying that exactly overspecifying? > > Specifying `integer' is underspecifying. You have that > > exactly backward. >=20 > No, I'm voting against the general notion of trying to specify more than > is necessary, just because we can. Define "necessary". Lisp variables being untyped, and especially given a doc string that specifies the type (expected/allowed values), wanting to be strictly and minimally "necessary", which I guess is what you espouse, calls for :type 'sexp in all cases (i.e., never use :type at all). No danger, if you do that, of accidentally writing the wrong expression for :type and introducing a bug. No need for anything more complex, no "overspecifying", since the doc string does all that's needed. Go for it. Oh, and since not everyone uses Customize, no real need to use defcustom at all - just use defvar in all cases. No danger of a miscoded :set, no confusing users with the Customize UI - LOTS of nasty problems evacuated. Go for it. > > I don't object to adding a `natnum' :type - I suggested it. > > But I also don't have a problem with expressing the same > > thing even if we don't have such a type. I think it's silly > > to _not_ specify such behavior, and to just use `integer' (or > > `sexp') simply because we don't have a `natnum'. That makes > > no sense to me. >=20 > Then please submit a report for that, if one does not already exist. Just use :type 'sexp (or just omit :type). Easier for everyone. KISS, as you say. --__1558221048002289683abhmp0017.oracle.com Content-Type: application/octet-stream; name="foo.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="foo.el" KGRlZmN1c3RvbSBiYXIgKCkKICAiTGlzdCBvZiBjdXN0b20gdGhlbWVzIGZvci4uLiIKICA6dHlw ZSAnKHJlcGVhdCAocmVzdHJpY3RlZC1zZXhwCiAgICAgICAgICAgICAgICAgIDptYXRjaC1hbHRl cm5hdGl2ZXMKICAgICAgICAgICAgICAgICAgKChsYW1iZGEgKHN5bWIpIChtZW1xIHN5bWIgKGN1 c3RvbS1hdmFpbGFibGUtdGhlbWVzKSkpKSkpCiAgOmdyb3VwICdmb29iYXIpCgooZGVmY3VzdG9t IGZvbyAoKQogICIuLi4KVGhlIG9wdGlvbiB2YWx1ZSBpcyBhIGxpc3QuICBFYWNoIGVsZW1lbnQg ZGVmaW5lcyBhIHN1Ym1lbnUgb3IgYSBtZW51Cml0ZW0uICBBIG51bGwgZWxlbWVudCAoYG5pbCcp IGlzIGlnbm9yZWQuCgpTZXZlcmFsIGFsdGVybmF0aXZlIGVudHJ5IGZvcm1hdHMgYXJlIGF2YWls YWJsZS4gIFdoZW4gY3VzdG9taXppbmcsCmNob29zZSBhbiBhbHRlcm5hdGl2ZSBpbiB0aGUgQ3Vz dG9taXplIGBWYWx1ZSBNZW51Jy4KCkluIHRoaXMgZGVzY3JpcHRpb246CiBTWU1CT0wgICAgICBp cyBhIHN5bWJvbCBpZGVudGlmeWluZyB0aGUgbWVudSBlbnRyeS4KIGBtZW51LWl0ZW0nIGlzIGp1 c3QgdGhhdCB0ZXh0LCBsaXRlcmFsbHkuCiBOQU1FICAgICAgICBpcyBhIHN0cmluZyBuYW1pbmcg dGhlIG1lbnUgaXRlbSBvciBzdWJtZW51LgogQ09NTUFORCAgICAgaXMgdGhlIGNvbW1hbmQgdG8g YmUgaW52b2tlZCBieSBhbiBpdGVtLgogTUVOVS1LRVlNQVAgaXMgYSBtZW51IGtleW1hcCBvciBh IHZhciB3aG9zZSB2YWx1ZSBpcyBhIG1lbnUga2V5bWFwLgogS0VZV09SRFMgICAgaXMgYSBwcm9w ZXJ0eSBsaXN0IG9mIG1lbnUga2V5d29yZHMgKGA6ZW5hYmxlJywKICAgICAgICAgICAgIGA6dmlz aWJsZScsIGA6ZmlsdGVyJywgYDprZXlzJywgZXRjLikuCgoxLiBTaW5nbGUgbWVudSBpdGVtLiAg Rm9yIGEgc2VsZWN0YWJsZSBpdGVtLCB1c2UKICAgKFNZTUJPTCBtZW51LWl0ZW0gTkFNRSBDT01N QU5EIC4gS0VZV09SRFMpLiAgRm9yIGEgbm9uLXNlbGVjdGFibGUKICAgaXRlbSBzdWNoIGFzIGEg c2VwYXJhdG9yLCB1c2UgKFNZTUJPTCBOQU1FKSBvcgogICAoU1lNQk9MIG1lbnUtaXRlbSBOQU1F IG5pbCAuIEtFWVdPUkRTKS4KCjIuIEl0ZW1zIHRha2VuIGZyb20gYSBtZW51LWtleW1hcCB2YXJp YWJsZSwgc3VjaCBhcwogICBgbWVudS1iYXItZWRpdC1tZW51Jy4gIEp1c3QgdXNlIHRoZSBuYW1l IG9mIHRoZSB2YXJpYWJsZSAoYQogICBzeW1ib2wpLiAgVGhlIGl0ZW1zIGFwcGVhciBhdCB0aGUg dG9wIGxldmVsIG9mIHRoZSBwb3B1cCBtZW51LCBub3QKICAgaW4gYSBzdWJtZW51LgoKMy4gU3Vi bWVudS4gIFVzZSAoU1lNQk9MIG1lbnUtaXRlbSBOQU1FIE1FTlUtS0VZTUFQIC4gS0VZV09SRFMp IG9yCiAgIChTWU1CT0wgTkFNRSAuIE1FTlUtS0VZTUFQKS4gIFJlbWVtYmVyIHRoYXQgTUVOVS1L RVlNQVAgY2FuIGFsc28gYmUKICAgYSB2YXJpYWJsZSAoc3ltYm9sKSB3aG9zZSB2YWx1ZSBpcyBh IG1lbnUga2V5bWFwLgoKQWxsIG9mIHRoZXNlIGFyZSBzdGFuZGFyZCBtZW51IGVsZW1lbnRzLCB3 aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlIHVzZQpvZiBhIGtleW1hcCB2YXJpYWJsZSB0byByZXBy ZXNlbnQgaXRzIHZhbHVlLgoKU2VlIGFsc286CiAqIChlbGlzcCkgRm9ybWF0IG9mIEtleW1hcHMK ICogKGVsaXNwKSBDbGFzc2lmeWluZyBFdmVudHMKICogKGVsaXNwKSBFeHRlbmRlZCBNZW51IEl0 ZW1zCgpFeGFtcGxlIHN1Ym1lbnUgZWxlbWVudDoKICh0b3RvIG1lbnUtaXRlbSBcIlRvdG9cIiBt ZW51LWJhci10b3RvLW1lbnUpCgpFeGFtcGxlIHNlbGVjdGFibGUgbWVudS1pdGVtIGVsZW1lbnQ6 CiAoZm9vIG1lbnUtaXRlbSBcIkZvb1wiICAgZm9vLWNvbW1hbmQKICAgICAgIDp2aXNpYmxlIChu b3QgYnVmZmVyLXJlYWQtb25seSkpIgogIDp0eXBlICAnKHJlcGVhdAogICAgICAgICAgIChjaG9p Y2UKICAgICAgICAgICAgOzsgVGhlc2UgY291bGQgYmUgY29tYmluZWQsIGJ1dCBpdCdzIGJldHRl ciBmb3IgdXNlcnMgdG8gc2VlIHNlcGFyYXRlIGNob2ljZXMuCiAgICAgICAgICAgIChyZXN0cmlj dGVkLXNleHAKICAgICAgICAgICAgIDp0YWcgIlN1Ym1lbnUgKFNZTUJPTCBtZW51LWl0ZW0gTkFN RSBNRU5VLUtFWU1BUCAuIEtFWVdPUkRTKSBvciAoU1lNQk9MIE5BTUUgLiBNRU5VLUtFWU1BUCki CiAgICAgICAgICAgICA6bWF0Y2gtYWx0ZXJuYXRpdmVzCiAgICAgICAgICAgICAoKGxhbWJkYSAo eCkKICAgICAgICAgICAgICAgIChhbmQgKGNvbnNwIHgpIChzeW1ib2xwIChjYXIgeCkpCiAgICAg ICAgICAgICAgICAgICAgIChvciAoYW5kIChzdHJpbmdwIChjYWRyIHgpKSAoY2RkciB4KSkgOyAo U1lNQk9MIE5BTUUgLiBNRU5VLUtFWU1BUCkKICAgICAgICAgICAgICAgICAgICAgICAgIDs7IChT WU1CT0wgbWVudS1pdGVtIE5BTUUgTUVOVS1LRVlNQVAgLiBLRVlXT1JEUykKICAgICAgICAgICAg ICAgICAgICAgICAgIChhbmQgKGVxICdtZW51LWl0ZW0gKGNhZHIgeCkpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChzdHJpbmdwIChjYXIgKGNkZHIgeCkpKQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAob3IgKGtleW1hcHAgKGNhciAoY2RyIChjZGRyIHgpKSkpIDsgQ2FuIGJl IGEga2V5bWFwIHZhci4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChhbmQgKHN5 bWJvbHAgKGNhciAoY2RyIChjZGRyIHgpKSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChib3VuZHAgKGNhciAoY2RyIChjZGRyIHgpKSkpCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChrZXltYXBwIChzeW1ib2wtdmFsdWUgKGNhciAoY2RyIChj ZGRyIHgpKSkpKSkpKSkpKQogICAgICAgICAgICAgICduaWwpKQogICAgICAgICAgICAocmVzdHJp Y3RlZC1zZXhwCiAgICAgICAgICAgICA6dGFnICJJdGVtcyBmcm9tIGEga2V5bWFwIHZhcmlhYmxl J3MgdmFsdWUuIgogICAgICAgICAgICAgOm1hdGNoLWFsdGVybmF0aXZlcyAoKGxhbWJkYSAoeCkg KGFuZCAoc3ltYm9scCB4KSAgKGtleW1hcHAgKHN5bWJvbC12YWx1ZSB4KSkpKQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJ25pbCkpCiAgICAgICAgICAgIChyZXN0cmljdGVkLXNl eHAKICAgICAgICAgICAgIDp0YWcgIlNlbGVjdGFibGUgaXRlbSAoU1lNQk9MIG1lbnUtaXRlbSBO QU1FIENPTU1BTkQgLiBLRVlXT1JEUykiCiAgICAgICAgICAgICA6bWF0Y2gtYWx0ZXJuYXRpdmVz ICgobGFtYmRhICh4KSAoYW5kIChjb25zcCB4KSAgKHN5bWJvbHAgKGNhciB4KSkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcSAnbWVudS1pdGVtIChjYWRy IHgpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmlu Z3AgKGNhciAoY2RkciB4KSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoY29tbWFuZHAgKGNhciAoY2RyIChjZGRyIHgpKSkpKSkKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICduaWwpKQogICAgICAgICAgICAocmVzdHJpY3RlZC1zZXhwCiAg ICAgICAgICAgICA6dGFnICJOb24tc2VsZWN0YWJsZSBpdGVtIChTWU1CT0wgTkFNRSkgb3IgKFNZ TUJPTCBtZW51LWl0ZW0gTkFNRSBuaWwgLiBLRVlXT1JEUykiCiAgICAgICAgICAgICA6bWF0Y2gt YWx0ZXJuYXRpdmVzICgobGFtYmRhICh4KSAoYW5kIChjb25zcCB4KSAgKHN5bWJvbHAgKGNhciB4 KSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChvciAoYW5k IChzdHJpbmdwIChjYWRyIHgpKSAgKG51bGwgKGNhZGRyIHgpKSkKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoYW5kIChlcSAnbWVudS1pdGVtIChjYWRy IHgpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKHN0cmluZ3AgKGNhciAoY2RkciB4KSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAobnVsbCAoY2FyIChjZHIgKGNkZHIgeCkpKSkpKSkp CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnbmlsKSkpKQogIDpncm91cCAnZm9v YmFyKQo= --__1558221048002289683abhmp0017.oracle.com--