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 1kxUSj-0000SX-2i for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Jan 2021 12:32:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kxUSh-0003Co-82 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Jan 2021 12:32:19 +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 1kxUSg-0003Ak-Oz for pgsql-hackers@lists.postgresql.org; Thu, 07 Jan 2021 12:32:19 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxUSZ-0001vs-M8 for pgsql-hackers@postgresql.org; Thu, 07 Jan 2021 12:32:17 +0000 Received: from hnk.local (p2390043-ipbf1028funabasi.chiba.ocn.ne.jp [118.7.248.43]) by oss.nttdata.com (Postfix) with ESMTPSA id AEAEA622D2; Thu, 7 Jan 2021 21:32:06 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion To: Shinya11.Kato@nttdata.com, sawada.mshk@gmail.com Cc: pgsql-hackers@postgresql.org References: <7559e8ee8a0644c8aad79837092143c7@MP-MSGSS-MBX001.msg.nttdata.co.jp> <0eab839e-5827-e517-4abf-00b3e581cd45@oss.nttdata.com> <697532b0-0a83-7046-1a58-b1ee0f66ac9a@oss.nttdata.com> <7bf2e1700a7345f79c04fd513675467a@MP-MSGSS-MBX001.msg.nttdata.co.jp> <80b6a07a-9249-bf08-6add-bdda1ccb0659@oss.nttdata.com> <0b48b5dab6a8431aaed016931666cbc1@MP-MSGSS-MBX001.msg.nttdata.co.jp> From: Fujii Masao Message-ID: Date: Thu, 7 Jan 2021 21:32:05 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <0b48b5dab6a8431aaed016931666cbc1@MP-MSGSS-MBX001.msg.nttdata.co.jp> Content-Type: multipart/mixed; boundary="------------D1D2177013A4E6FC1189DF45" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------D1D2177013A4E6FC1189DF45 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2021/01/07 17:28, Shinya11.Kato@nttdata.com wrote: >> On Thu, Jan 7, 2021 at 1:30 PM Fujii Masao wrote: >>> >>> On 2021/01/07 12:42, Masahiko Sawada wrote: >>>> On Thu, Jan 7, 2021 at 10:59 AM Fujii Masao wrote: >>>>> >>>>> On 2021/01/07 10:01, Masahiko Sawada wrote: >>>>>> On Wed, Jan 6, 2021 at 3:37 PM wrote: >>>>>>> >>>>>>>> +#define Query_for_list_of_cursors \ >>>>>>>> +" SELECT name FROM pg_cursors"\ >>>>>>>> >>>>>>>> This query should be the following? >>>>>>>> >>>>>>>> " SELECT pg_catalog.quote_ident(name) "\ >>>>>>>> " FROM pg_catalog.pg_cursors "\ >>>>>>>> " WHERE substring(pg_catalog.quote_ident(name),1,%d)='%s'" >>>>>>>> >>>>>>>> +/* CLOSE */ >>>>>>>> + else if (Matches("CLOSE")) >>>>>>>> + COMPLETE_WITH_QUERY(Query_for_list_of_cursors >>>>>>>> + " UNION ALL SELECT 'ALL'"); >>>>>>>> >>>>>>>> "UNION ALL" should be "UNION"? >>>>>>> >>>>>>> Thank you for your advice, and I corrected them. >>>>>>> >>>>>>>>> + COMPLETE_WITH_QUERY(Query_for_list_of_cursors >>>>>>>>> + " UNION SELECT 'ABSOLUTE'" >>>>>>>>> + " UNION SELECT 'BACKWARD'" >>>>>>>>> + " UNION SELECT 'FORWARD'" >>>>>>>>> + " UNION SELECT 'RELATIVE'" >>>>>>>>> + " UNION SELECT 'ALL'" >>>>>>>>> + " UNION SELECT 'NEXT'" >>>>>>>>> + " UNION SELECT 'PRIOR'" >>>>>>>>> + " UNION SELECT 'FIRST'" >>>>>>>>> + " UNION SELECT 'LAST'" >>>>>>>>> + " UNION SELECT 'FROM'" >>>>>>>>> + " UNION SELECT 'IN'"); >>>>>>>>> >>>>>>>>> This change makes psql unexpectedly output "FROM" and "IN" just after "FETCH". >>>>>>>> >>>>>>>> I think "FROM" and "IN" can be placed just after "FETCH". According to >>>>>>>> the documentation, the direction can be empty. For instance, we can do >>>>>>>> like: >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>>> I've attached the patch improving the tab completion for DECLARE as an >>>>>>>> example. What do you think? >>>>>>>> >>>>>>>> BTW according to the documentation, the options of DECLARE statement >>>>>>>> (BINARY, INSENSITIVE, SCROLL, and NO SCROLL) are order-sensitive. >>>>>>>> >>>>>>>> DECLARE name [ BINARY ] [ INSENSITIVE ] [ [ NO ] SCROLL ] >>>>>>>> CURSOR [ { WITH | WITHOUT } HOLD ] FOR query >>>>>>>> >>>>>>>> But I realized that these options are actually order-insensitive. For >>>>>>>> instance, we can declare a cursor like: >>>>>>>> >>>>>>>> =# declare abc scroll binary cursor for select * from pg_class; >>>>>>>> DECLARE CURSOR >>>>>>>> >>>>>>>> The both parser code and documentation has been unchanged from 2003. >>>>>>>> Is it a documentation bug? >>>>>>> >>>>>>> Thank you for your patch, and it is good. >>>>>>> I cannot find the description "(BINARY, INSENSITIVE, SCROLL, and NO SCROLL) are order-sensitive." >>>>>>> I saw "The key words BINARY, INSENSITIVE, and SCROLL can appear in any order." , according to the documentation. >>>>>> >>>>>> Thanks, you're right. I missed that sentence. I still don't think the >>>>>> syntax of DECLARE statement in the documentation doesn't match its >>>>>> implementation but I agree that it's order-insensitive. >>>>>> >>>>>>> I made a new patch, but the amount of codes was large due to order-insensitive. >>>>>> >>>>>> Thank you for updating the patch! >>>>>> >>>>>> Yeah, I'm also afraid a bit that conditions will exponentially >>>>>> increase when a new option is added to DECLARE statement in the >>>>>> future. Looking at the parser code for DECLARE statement, we can put >>>>>> the same options multiple times (that's also why I don't think it >>>>>> matches). For instance, >>>>>> >>>>>> postgres(1:44758)=# begin; >>>>>> BEGIN >>>>>> postgres(1:44758)=# declare test binary binary binary cursor for >>>>>> select * from pg_class; >>>>>> DECLARE CURSOR >>>>>> >>>>>> So how about simplify the above code as follows? >>>>>> >>>>>> @@ -3005,8 +3014,23 @@ psql_completion(const char *text, int start, int end) >>>>>> else if (Matches("DECLARE", MatchAny)) >>>>>> COMPLETE_WITH("BINARY", "INSENSITIVE", "SCROLL", "NO SCROLL", >>>>>> "CURSOR"); >>>>>> + /* >>>>>> + * Complete DECLARE with one of BINARY, INSENSITIVE, SCROLL, >>>>>> + * NO SCROLL, and CURSOR. The tail doesn't match any keywords for >>>>>> + * DECLARE, assume we want options. >>>>>> + */ >>>>>> + else if (HeadMatches("DECLARE", MatchAny, "*") && >>>>>> + TailMatches(MatchAnyExcept("CURSOR|WITH|WITHOUT|HOLD|FOR"))) >>>>>> + COMPLETE_WITH("BINARY", "INSENSITIVE", "SCROLL", "NO SCROLL", >>>>>> + "CURSOR"); >>>>> >>>>> This change seems to cause "DECLARE ... CURSOR FOR SELECT " to >>>>> unexpectedly output BINARY, INSENSITIVE, etc. >>>> >>>> Indeed. Is the following not complete but much better? >>> >>> Yes, I think that's better. >>> >>>> >>>> @@ -3002,11 +3011,18 @@ psql_completion(const char *text, int start, int end) >>>> " UNION SELECT 'ALL'"); >>>> >>>> /* DECLARE */ >>>> - else if (Matches("DECLARE", MatchAny)) >>>> - COMPLETE_WITH("BINARY", "INSENSITIVE", "SCROLL", "NO SCROLL", >>>> - "CURSOR"); >>>> + /* >>>> + * Complete DECLARE with one of BINARY, INSENSITIVE, SCROLL, >>>> + * NO SCROLL, and CURSOR. If the tail is any one of options, assume we >>>> + * still want options. >>>> + */ >>>> + else if (Matches("DECLARE", MatchAny) || >>>> + TailMatches("BINARY|INSENSITIVE|SCROLL|NO")) >>>> + COMPLETE_WITH("BINARY", "INSENSITIVE", "SCROLL", "NO SCROLL", "CURSOR"); >>> >>> This change seems to cause "DECLARE ... NO " to unexpectedly output >>> "NO SCROLL". Also this change seems to cause "COPY ... (FORMAT BINARY " >>> to unexpectedly output BINARY, CURSOR, etc. >> >> Oops, I missed the HeadMatches(). Thank you for pointing this out. >> >> I've attached the updated patch including Kato-san's changes. I >> think the tab completion support for DECLARE added by this patch >> works better. Thanks! + /* Complete with more options */ + else if (HeadMatches("DECLARE", MatchAny, "BINARY|INSENSITIVE|SCROLL|NO") && + TailMatches("BINARY|INSENSITIVE|SCROLL|NO")) Seems "MatchAny, "BINARY|INSENSITIVE|SCROLL|NO"" is not necessary. Right? If this is true, I'd like to refactor the code a bit. What about the attached patch? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION --------------D1D2177013A4E6FC1189DF45 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="fix_tab_complete_close_fetch_move_v5.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fix_tab_complete_close_fetch_move_v5.patch" ZGlmZiAtLWdpdCBhL3NyYy9iaW4vcHNxbC90YWItY29tcGxldGUuYyBiL3NyYy9iaW4vcHNx bC90YWItY29tcGxldGUuYwppbmRleCA5ZGNhYjBkMmZhLi5hYTk5NGEzYWYwIDEwMDY0NAot LS0gYS9zcmMvYmluL3BzcWwvdGFiLWNvbXBsZXRlLmMKKysrIGIvc3JjL2Jpbi9wc3FsL3Rh Yi1jb21wbGV0ZS5jCkBAIC05NzYsNiArOTc2LDExIEBAIHN0YXRpYyBjb25zdCBTY2hlbWFR dWVyeSBRdWVyeV9mb3JfbGlzdF9vZl9zdGF0aXN0aWNzID0gewogIiAgICAgICBhbmQgcGdf Y2F0YWxvZy5wZ190YWJsZV9pc192aXNpYmxlKGMyLm9pZCkiXAogIiAgICAgICBhbmQgYzIu cmVsaXNwYXJ0aXRpb24gPSAndHJ1ZSciCiAKKyNkZWZpbmUgUXVlcnlfZm9yX2xpc3Rfb2Zf Y3Vyc29ycyBcCisiIFNFTEVDVCBwZ19jYXRhbG9nLnF1b3RlX2lkZW50KG5hbWUpICJcCisi ICAgRlJPTSBwZ19jYXRhbG9nLnBnX2N1cnNvcnMgIlwKKyIgIFdIRVJFIHN1YnN0cmluZyhw Z19jYXRhbG9nLnF1b3RlX2lkZW50KG5hbWUpLDEsJWQpPSclcyciCisKIC8qCiAgKiBUaGVz ZSBvYmplY3QgdHlwZXMgd2VyZSBpbnRyb2R1Y2VkIGxhdGVyIHRoYW4gb3VyIHN1cHBvcnQg Y3V0b2ZmIG9mCiAgKiBzZXJ2ZXIgdmVyc2lvbiA3LjQuICBXZSB1c2UgdGhlIFZlcnNpb25l ZFF1ZXJ5IGluZnJhc3RydWN0dXJlIHNvIHRoYXQKQEAgLTIyODQsNiArMjI4OSwxMCBAQCBw c3FsX2NvbXBsZXRpb24oY29uc3QgY2hhciAqdGV4dCwgaW50IHN0YXJ0LCBpbnQgZW5kKQog CQlDT01QTEVURV9XSVRIX1ZFUlNJT05FRF9TQ0hFTUFfUVVFUlkoUXVlcnlfZm9yX2xpc3Rf b2ZfcHJvY2VkdXJlcywgTlVMTCk7CiAJZWxzZSBpZiAoTWF0Y2hlcygiQ0FMTCIsIE1hdGNo QW55KSkKIAkJQ09NUExFVEVfV0lUSCgiKCIpOworLyogQ0xPU0UgKi8KKwllbHNlIGlmIChN YXRjaGVzKCJDTE9TRSIpKQorCQlDT01QTEVURV9XSVRIX1FVRVJZKFF1ZXJ5X2Zvcl9saXN0 X29mX2N1cnNvcnMKKwkJCQkJCQkiIFVOSU9OIFNFTEVDVCAnQUxMJyIpOwogLyogQ0xVU1RF UiAqLwogCWVsc2UgaWYgKE1hdGNoZXMoIkNMVVNURVIiKSkKIAkJQ09NUExFVEVfV0lUSF9T Q0hFTUFfUVVFUlkoUXVlcnlfZm9yX2xpc3Rfb2ZfY2x1c3RlcmFibGVzLCAiVU5JT04gU0VM RUNUICdWRVJCT1NFJyIpOwpAQCAtMzAwMiwxMSArMzAxMSwzOSBAQCBwc3FsX2NvbXBsZXRp b24oY29uc3QgY2hhciAqdGV4dCwgaW50IHN0YXJ0LCBpbnQgZW5kKQogCQkJCQkJCSIgVU5J T04gU0VMRUNUICdBTEwnIik7CiAKIC8qIERFQ0xBUkUgKi8KKworCS8qCisJICogQ29tcGxl dGUgREVDTEFSRSA8bmFtZT4gd2l0aCBvbmUgb2YgQklOQVJZLCBJTlNFTlNJVElWRSwgU0NS T0xMLCBOTworCSAqIFNDUk9MTCwgYW5kIENVUlNPUi4KKwkgKi8KIAllbHNlIGlmIChNYXRj aGVzKCJERUNMQVJFIiwgTWF0Y2hBbnkpKQogCQlDT01QTEVURV9XSVRIKCJCSU5BUlkiLCAi SU5TRU5TSVRJVkUiLCAiU0NST0xMIiwgIk5PIFNDUk9MTCIsCiAJCQkJCSAgIkNVUlNPUiIp OworCisJLyoKKwkgKiBDb21wbGV0ZSBERUNMQVJFIDxuYW1lPiBbb3B0aW9uc10gd2l0aCBv bmUgb2YgQklOQVJZLCBJTlNFTlNJVElWRSwKKwkgKiBTQ1JPTEwsIE5PIFNDUk9MTCwgYW5k IENVUlNPUi4gSWYgdGhlIHRhaWwgaXMgYW55IG9uZSBvZiBvcHRpb25zLAorCSAqIGFzc3Vt ZSB3ZSBzdGlsbCB3YW50IG9wdGlvbnMuCisJICovCisJZWxzZSBpZiAoSGVhZE1hdGNoZXMo IkRFQ0xBUkUiKSAmJiBUYWlsTWF0Y2hlcygiQklOQVJZfElOU0VOU0lUSVZFfFNDUk9MTCIp KQorCQlDT01QTEVURV9XSVRIKCJCSU5BUlkiLCAiSU5TRU5TSVRJVkUiLCAiU0NST0xMIiwg Ik5PIFNDUk9MTCIsCisJCQkJCSAgIkNVUlNPUiIpOworCS8qIENvbXBsZXRlIERFQ0xBUkUg PG5hbWU+IFtvcHRpb25zXSBOTyB3aXRoIFNDUk9MTCAqLworCWVsc2UgaWYgKEhlYWRNYXRj aGVzKCJERUNMQVJFIikgJiYgVGFpbE1hdGNoZXMoIk5PIikpCisJCUNPTVBMRVRFX1dJVEgo IlNDUk9MTCIpOworCisJLyoKKwkgKiBDb21wbGV0ZSBERUNMQVJFIC4uLiBDVVJTT1Igd2l0 aCBvbmUgb2YgV0lUSCBIT0xELCBXSVRIT1VUIEhPTEQsIGFuZAorCSAqIEZPUgorCSAqLwog CWVsc2UgaWYgKEhlYWRNYXRjaGVzKCJERUNMQVJFIikgJiYgVGFpbE1hdGNoZXMoIkNVUlNP UiIpKQogCQlDT01QTEVURV9XSVRIKCJXSVRIIEhPTEQiLCAiV0lUSE9VVCBIT0xEIiwgIkZP UiIpOworCS8qIENvbXBsZXRlIERFQ0xBUkUgLi4uIENVUlNPUiBXSVRIfFdJVEhPVVQgd2l0 aCBIT0xEICovCisJZWxzZSBpZiAoSGVhZE1hdGNoZXMoIkRFQ0xBUkUiKSAmJiBUYWlsTWF0 Y2hlcygiQ1VSU09SIiwgIldJVEh8V0lUSE9VVCIpKQorCQlDT01QTEVURV9XSVRIKCJIT0xE Iik7CisJLyogQ29tcGxldGUgREVDTEFSRSAuLi4gQ1VSU09SIFdJVEh8V0lUSE9VVCBIT0xE IHdpdGggRk9SICovCisJZWxzZSBpZiAoSGVhZE1hdGNoZXMoIkRFQ0xBUkUiKSAmJiBUYWls TWF0Y2hlcygiQ1VSU09SIiwgIldJVEh8V0lUSE9VVCIsICJIT0xEIikpCisJCUNPTVBMRVRF X1dJVEgoIkZPUiIpOwogCiAvKiBERUxFVEUgLS0tIGNhbiBiZSBpbnNpZGUgRVhQTEFJTiwg UlVMRSwgZXRjICovCiAJLyogLi4uIGRlc3BpdGUgd2hpY2gsIG9ubHkgY29tcGxldGUgREVM RVRFIHdpdGggRlJPTSBhdCBzdGFydCBvZiBsaW5lICovCkBAIC0zMTY3LDE1ICszMjA0LDMx IEBAIHBzcWxfY29tcGxldGlvbihjb25zdCBjaGFyICp0ZXh0LCBpbnQgc3RhcnQsIGludCBl bmQpCiAKIAkvKgogCSAqIENvbXBsZXRlIEZFVENIIHdpdGggb25lIG9mIEFCU09MVVRFLCBC QUNLV0FSRCwgRk9SV0FSRCwgUkVMQVRJVkUsIEFMTCwKLQkgKiBORVhULCBQUklPUiwgRklS U1QsIExBU1QKKwkgKiBORVhULCBQUklPUiwgRklSU1QsIExBU1QsIEZST00sIElOLCBhbmQg YSBsaXN0IG9mIGN1cnNvcnMKIAkgKi8KIAllbHNlIGlmIChNYXRjaGVzKCJGRVRDSHxNT1ZF IikpCi0JCUNPTVBMRVRFX1dJVEgoIkFCU09MVVRFIiwgIkJBQ0tXQVJEIiwgIkZPUldBUkQi LCAiUkVMQVRJVkUiLAotCQkJCQkgICJBTEwiLCAiTkVYVCIsICJQUklPUiIsICJGSVJTVCIs ICJMQVNUIik7CisJCUNPTVBMRVRFX1dJVEhfUVVFUlkoUXVlcnlfZm9yX2xpc3Rfb2ZfY3Vy c29ycworCQkJCQkJCSIgVU5JT04gU0VMRUNUICdBQlNPTFVURSciCisJCQkJCQkJIiBVTklP TiBTRUxFQ1QgJ0JBQ0tXQVJEJyIKKwkJCQkJCQkiIFVOSU9OIFNFTEVDVCAnRk9SV0FSRCci CisJCQkJCQkJIiBVTklPTiBTRUxFQ1QgJ1JFTEFUSVZFJyIKKwkJCQkJCQkiIFVOSU9OIFNF TEVDVCAnQUxMJyIKKwkJCQkJCQkiIFVOSU9OIFNFTEVDVCAnTkVYVCciCisJCQkJCQkJIiBV TklPTiBTRUxFQ1QgJ1BSSU9SJyIKKwkJCQkJCQkiIFVOSU9OIFNFTEVDVCAnRklSU1QnIgor CQkJCQkJCSIgVU5JT04gU0VMRUNUICdMQVNUJyIKKwkJCQkJCQkiIFVOSU9OIFNFTEVDVCAn RlJPTSciCisJCQkJCQkJIiBVTklPTiBTRUxFQ1QgJ0lOJyIpOwogCi0JLyogQ29tcGxldGUg RkVUQ0ggQkFDS1dBUkQgb3IgRk9SV0FSRCB3aXRoIG9uZSBvZiBBTEwsIEZST00sIElOICov CisJLyoKKwkgKiBDb21wbGV0ZSBGRVRDSCBCQUNLV0FSRCBvciBGT1JXQVJEIHdpdGggb25l IG9mIEFMTCwgRlJPTSwgSU4sIGFuZCBhCisJICogbGlzdCBvZiBjdXJzb3JzCisJICovCiAJ ZWxzZSBpZiAoTWF0Y2hlcygiRkVUQ0h8TU9WRSIsICJCQUNLV0FSRHxGT1JXQVJEIikpCi0J CUNPTVBMRVRFX1dJVEgoIkFMTCIsICJGUk9NIiwgIklOIik7CisJCUNPTVBMRVRFX1dJVEhf UVVFUlkoUXVlcnlfZm9yX2xpc3Rfb2ZfY3Vyc29ycworCQkJCQkJCSIgVU5JT04gU0VMRUNU ICdBTEwnIgorCQkJCQkJCSIgVU5JT04gU0VMRUNUICdGUk9NJyIKKwkJCQkJCQkiIFVOSU9O IFNFTEVDVCAnSU4nIik7CiAKIAkvKgogCSAqIENvbXBsZXRlIEZFVENIIDxkaXJlY3Rpb24+ IHdpdGggIkZST00iIG9yICJJTiIuIFRoZXNlIGFyZSBlcXVpdmFsZW50LApAQCAtMzE4NSw3 ICszMjM4LDEzIEBAIHBzcWxfY29tcGxldGlvbihjb25zdCBjaGFyICp0ZXh0LCBpbnQgc3Rh cnQsIGludCBlbmQpCiAJZWxzZSBpZiAoTWF0Y2hlcygiRkVUQ0h8TU9WRSIsICJBQlNPTFVU RXxCQUNLV0FSRHxGT1JXQVJEfFJFTEFUSVZFIiwKIAkJCQkJIE1hdGNoQW55RXhjZXB0KCJG Uk9NfElOIikpIHx8CiAJCQkgTWF0Y2hlcygiRkVUQ0h8TU9WRSIsICJBTEx8TkVYVHxQUklP UnxGSVJTVHxMQVNUIikpCi0JCUNPTVBMRVRFX1dJVEgoIkZST00iLCAiSU4iKTsKKwkJQ09N UExFVEVfV0lUSF9RVUVSWShRdWVyeV9mb3JfbGlzdF9vZl9jdXJzb3JzCisJCQkJCQkJIiBV TklPTiBTRUxFQ1QgJ0ZST00nIgorCQkJCQkJCSIgVU5JT04gU0VMRUNUICdJTiciKTsKKwkv KiBDb21wbGV0ZSBGRVRDSCA8ZGlyZWN0aW9uPiAiRlJPTSIgb3IgIklOIiB3aXRoIGEgbGlz dCBvZiBjdXJzb3JzICovCisJZWxzZSBpZiAoSGVhZE1hdGNoZXMoIkZFVENIfE1PVkUiKSAm JgorCQkJIFRhaWxNYXRjaGVzKCJGUk9NfElOIikpCisJCUNPTVBMRVRFX1dJVEhfUVVFUlko UXVlcnlfZm9yX2xpc3Rfb2ZfY3Vyc29ycyk7CiAKIC8qIEZPUkVJR04gREFUQSBXUkFQUEVS ICovCiAJLyogYXBwbGllcyBpbiBBTFRFUi9EUk9QIEZEVyBhbmQgaW4gQ1JFQVRFIFNFUlZF UiAqLwo= --------------D1D2177013A4E6FC1189DF45--