From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id KLimN6EGH2R/PAEASxT56A (envelope-from ) for ; Sat, 25 Mar 2023 15:35:13 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id YK+fN6EGH2RFYgAA9RJhRA (envelope-from ) for ; Sat, 25 Mar 2023 15:35:13 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 256FF93F1 for ; Sat, 25 Mar 2023 15:35:13 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=posteo.de header.s=2017 header.b=MxJTIjSN; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (strict)" header.from=posteo.de (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679754913; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ebNW0D2W1o47LaL8FQhIhiQ6rBOTWJAwTMsYVWEhCic=; b=QQmj8XnE0zUnrv6KGja8eUY7MM8wmuq+w6sCkAmclomZX6q7uc72ktwnXEsXHQ92jOumTp e1gG6du2Ik8IpF4h4+b0JWmSL/XssJDoCQYcGsR4z+V8FAM/ioCP+BoEQ/Zgg+6TYJBCjE 0tX3GT3OFAwcTrYGQY32Az2l6De1Mj61xrhClUT/kbF8+OZKf3yT744CAXd24sub/TpoGh mD9O43ocvFuB3NrzskiZkR5KQUey930wzEuyze9oQdQyI8X6IODE2+yd6WnNyfE4dwSuLa bX/o+WxtvWqLSJT77+MMkmk16Tc3J9wOKHyNc+vkyNl6uGelg1Fc53enPuCuqA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679754913; a=rsa-sha256; cv=none; b=Je+zOIb+LxiGCN786BySnHJPIMeX2QAO6uIYD/2BGVVrjyQGosjh/pNvJeiezi60VmL9Sg pVOq90mALKdVlYUKSxN19EFqzjYhIitpbPwTPu02F4vPlf8bWcCj705Q9MZbXNvUG8A2Dg /tIoJX8TVgiZBoe2/SQnXJMSYAlNfhlQ6OnRB+DsEeTh+Jco6ZkhW8oAO33SssKGlqjYwj DGHjrQc4ggDgCDPV54tnZMnXq/BrUI7cmVtjUOHw3sSh08xWDCejGGcJ8kAP1T4/HE3sWL 3ySE5FjU+zw+UKvIND08hYiuonGAo5NUPcOMhw+/Zpn8Arfeh2Lu+5pPMm+WiA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=posteo.de header.s=2017 header.b=MxJTIjSN; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (strict)" header.from=posteo.de (policy=none) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pg4yI-0005h7-Qv; Sat, 25 Mar 2023 10:34:18 -0400 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 1pg4yG-0005dt-Kv for emacs-orgmode@gnu.org; Sat, 25 Mar 2023 10:34:16 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pg4yD-0006j3-Mt for emacs-orgmode@gnu.org; Sat, 25 Mar 2023 10:34:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 787B62401AA for ; Sat, 25 Mar 2023 15:34:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1679754851; bh=adoCnoELkizVqs1GfCmFbTGDFKZ+PXw5bH3cw63oAzk=; h=Date:Subject:To:Cc:From:From; b=MxJTIjSN/acTCyLsrKxMpvW4icP3kMqRNrZ3HKm1Q9MTyjr4Nomy8hv1HkG796acx 64y+97oKm62PkBG0BtGwSYU+EqrcvQEZB/E1LIY3PA94g5iKQRQOiSslcFYQVkrhVk CU/DT+DMF7CMrSRjXk4bCm0+mc1aYIcjOgaIT4CccPRbs/TiApRZesiMSTqCQ18ar5 pGNmZRTv78DVe2ZbDrYTohSHuyp8TnEfNNx/KpBWWM0Xr04W7r5ym9fg26zek3PMqp rcBLEmiRstuZ3WzR9+Ow1uTxbmw6C8BxM7xRHzdPe51OgJ2vcEj7QS2fZUg2Fyp5D/ E/LVMI06IB2gA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PkM5t2Bz0z6tnD; Sat, 25 Mar 2023 15:34:10 +0100 (CET) Content-Type: multipart/mixed; boundary="------------Lpqc0EvJ7iRyY0PddNggLO7e" Message-ID: <3208da46-d61e-98b6-fbbe-85d3e6b77291@posteo.de> Date: Sat, 25 Mar 2023 14:34:09 +0000 MIME-Version: 1.0 Subject: Re: [PATCH] lisp/ob-scheme.el Content-Language: en-US To: Ihor Radchenko Cc: Bruno Barbier , emacs-orgmode@gnu.org, Bastien References: <9eab60bc-9b82-e037-d63b-3d879573ae32@posteo.de> <87v8jceihi.fsf@localhost> <7fc63848-d6d3-80e0-ae78-00967990813d@posteo.de> <64079614.170a0220.5a0d3.0a23@mx.google.com> <97ee254e-72d2-2bdf-e026-78bde076f1f9@posteo.de> <6408e424.5d0a0220.8862a.2a62@mx.google.com> <87v8jaoz3u.fsf@localhost> <21ea836d-8bdf-2d0d-8515-283209f2eb1f@posteo.de> <878rg3y5he.fsf@localhost> <9710552a-601b-8a0c-1c30-4bb2263c2739@posteo.de> <87edphoyls.fsf@localhost> From: Zelphir Kaltstahl In-Reply-To: <87edphoyls.fsf@localhost> Received-SPF: pass client-ip=185.67.36.66; envelope-from=zelphirkaltstahl@posteo.de; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Queue-Id: 256FF93F1 X-Spam-Score: -1.03 X-Migadu-Spam-Score: -1.03 X-Migadu-Scanner: scn0.migadu.com List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-TUID: USyjMPgmwrJY This is a multi-part message in MIME format. --------------Lpqc0EvJ7iRyY0PddNggLO7e Content-Type: multipart/alternative; boundary="------------EVB8oCZvaNA4sUi0sogiDOk4" --------------EVB8oCZvaNA4sUi0sogiDOk4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit >> Not sure it meets all formalities. For example it is not clear to me, whether I >> should add the "TINYCHANGE" at the bottom of my commit message. > You should, unless you have FSF copyright assignment. I am not sure what "have FSF copyright assignment" means. I would not mind assigning copyright of that patch to FSF, but probably the paperwork would be way overblown for such a small change. I will simply add the "TINYCHANGE" then. >> -- >> repositories:https://notabug.org/ZelphirKaltstahl >> From 51b299aa18e882681dd681acb51c9cb1b44f3b4e Mon Sep 17 00:00:00 2001 >> From: Zelphir Kaltstahl >> Date: Sat, 18 Mar 2023 16:06:05 +0100 >> Subject: [PATCH] lisp/ob-scheme.el: > Please provide a short commit summary, not just the changed file. > See how we do it inhttps://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/ Oh, I thought I had one. Not sure how I lost my commit message title. o.o This is the kind of stuff, that causes me to procrastinate so much. I know it is not your fault and I know there need to be some format regulations in place to have a good manageable cooperation when working on a community project. I just want to explain, why I am so slow in following up and initially sending the patch ; ) Not blaming anyone! >> Wrapping binding definitions using `let' can lead to issues with GNU >> Guile and potentially other Scheme dialects. GNU Guile will only get >> to the body of the let at evaluation time, not at macro expansion >> time. If the let form wraps any imports of libraries that define >> macros, then those imported macros are seen too late and their >> corresponding forms inside the body of the let are not >> expanded. Using `define' to define bindings avoids this problem, at >> least in GNU Guile. > Please use double space between sentences. Also, it would be helpful to > provide a link to this thread for more context. (The aim of commit > message is a note for future contributors on the reason the change was > made). Right! I forgot about that one while writing : ) Will do! >> +(defun org-babel-expand-header-arg-vars:scheme (vars) > Please use org-babel-scheme-... function name. It is the usual > Elisp convention to prefix the functions as > library-name-inner-function-name. > > The exception in org-babel is a set of special functions that must have > certain name pattern. Expanding header args is not one of those special > functions. Ah, I was not aware of that. Took all naming inspiration from the org-babel-expand-body:scheme function name and thought my separate function ought to have :scheme suffix : ) Will fix! >> + "Expand :var header arguments given as VARS." >> + (mapconcat >> + (lambda (var) >> + (format "(define %s %S)" (car var) (cdr var))) > Is there any reason why you use %s for variable name? Previously it was > formatted with escapes (using %S). That was me thinking: "The name of the variable should just be itself, not wrapped in double quotes, because in Scheme I cannot create a variable as (define "abc" 123)". But maybe I misunderstood %s and %S. I also do not know, how elisp's `print' treats its arguments. Will use 2 times %S then. Or do you mean, that I should be using `print'? I thought using only `format' is simpler, so I did not bother with `print' and then `format'. If I choose the correct format modifiers, `print' should be unnecessary, right? Or does `print' do some magic behind the scenes, that is not expressable using merely format modifiers? > Also, previous version quoted the variable value with "'". Why didn't > you do it here? I am not sure I understand what you are referring to in the previous version. Do you mean that `print' quoted variable values with a single quote? Do you mean this part of the previous code: (print `(,(car var) ',(cdr var))) ? >> + (concat (org-babel-expand-header-arg-vars:scheme vars) body)) > `mapconcat' you used in `org-babel-expand-header-arg-vars:scheme' does > not add trailing newline, unlike done previously. Am I not adding a newline? I think I do?: ~~~~ ... (mapconcat (lambda (var) (format "(define %S %S)" (car var) (cdr var))) vars "\n") ... ~~~~ Is anything else required? Maybe 2 newlines instead? The previous version had a number of spaces as well, but since `define' is not creating additional indent like `let' should, I leave those away. Thank you for the feedback! I have a question or suggestion: When I save the file in Emacs, my Emacs turns all the tabs in there into spaces. Probably my own custom global config's choice about indentation. Could a general mode line thing be added to avoid that and nail down the current formatting style, so that contributors only need to allow Emacs to run those settings and then not need to care about it? Currently the indentation style seems to be a mix of tabs and spaces. (For example the GNU Guix project does a lot of formatting things in their files, that configure Emacs, so that the formatting will be automatically according to their practices.) Otherwise the diff becomes huge and I have to discard all those tab -> spaces changes again, before I can make a patch. Or I have to edit in fundamental mode, which loses syntax highlighting and is what I have been doing. But even in fundamental-mode Emacs changes some of the indentation from tabs to spaces or spaces to tabs apparently. Maybe I should be editing with emacs -Q or something? But then I don't have magit. This creates quite some friction in the editing process for me. In fundamental mode, I have to discard 4-6 chunks, which I did not even touch, but which were changed in terms of what the indentation consists of. And one more question: Does the name of the patch file matter? Git changed the name and I will attach it as it was created by git. Hope that's alright. Attached: The updated patch. And of course: Let me know if it needs more changes. Regards, Zelphir -- repositories:https://notabug.org/ZelphirKaltstahl --------------EVB8oCZvaNA4sUi0sogiDOk4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Not sure it meets all formalities. For example it is not clear to me, whether I 
should add the "TINYCHANGE" at the bottom of my commit message.

You should, unless you have FSF copyright assignment.
I am not sure what "have FSF copyright assignment" means. I would not mind assigning copyright of that patch to FSF, but probably the paperwork would be way overblown for such a small change. I will simply add the "TINYCHANGE" then. 
-- 
repositories: https://notabug.org/ZelphirKaltstahl
>From 51b299aa18e882681dd681acb51c9cb1b44f3b4e Mon Sep 17 00:00:00 2001
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
Date: Sat, 18 Mar 2023 16:06:05 +0100
Subject: [PATCH] lisp/ob-scheme.el:

Please provide a short commit summary, not just the changed file.
See how we do it in https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/
Oh, I thought I had one. Not sure how I lost my commit message title. o.o

This is the kind of stuff, that causes me to procrastinate so much. I know it is not your fault and I know there need to be some format regulations in place to have a good manageable cooperation when working on a community project. I just want to explain, why I am so slow in following up and initially sending the patch ; ) Not blaming anyone!

Wrapping binding definitions using `let' can lead to issues with GNU
Guile and potentially other Scheme dialects. GNU Guile will only get
to the body of the let at evaluation time, not at macro expansion
time. If the let form wraps any imports of libraries that define
macros, then those imported macros are seen too late and their
corresponding forms inside the body of the let are not
expanded. Using `define' to define bindings avoids this problem, at
least in GNU Guile.

Please use double space between sentences. Also, it would be helpful to
provide a link to this thread for more context. (The aim of commit
message is a note for future contributors on the reason the change was
made).
Right! I forgot about that one while writing : ) Will do! 
+(defun org-babel-expand-header-arg-vars:scheme (vars)

Please use org-babel-scheme-... function name. It is the usual
Elisp convention to prefix the functions as
library-name-inner-function-name.

The exception in org-babel is a set of special functions that must have
certain name pattern. Expanding header args is not one of those special
functions.
Ah, I was not aware of that. Took all naming inspiration from the org-babel-expand-body:scheme function name and thought my separate function ought to have :scheme suffix : ) Will fix! 
+  "Expand :var header arguments given as VARS."
+  (mapconcat
+   (lambda (var)
+     (format "(define %s %S)" (car var) (cdr var)))

Is there any reason why you use %s for variable name? Previously it was
formatted with escapes (using %S).

That was me thinking: "The name of the variable should just be itself, not wrapped in double quotes, because in Scheme I cannot create a variable as (define "abc" 123)". But maybe I misunderstood %s and %S. I also do not know, how elisp's `print' treats its arguments. Will use 2 times %S then.

Or do you mean, that I should be using `print'? I thought using only `format' is simpler, so I did not bother with `print' and then `format'. If I choose the correct format modifiers, `print' should be unnecessary, right? Or does `print' do some magic behind the scenes, that is not expressable using merely format modifiers?

Also, previous version quoted the variable value with "'". Why didn't
you do it here?

I am not sure I understand what you are referring to in the previous version. Do you mean that `print' quoted variable values with a single quote? Do you mean this part of the previous code:

(print `(,(car var) ',(cdr var)))

? 

+	      (concat (org-babel-expand-header-arg-vars:scheme vars) body))

`mapconcat' you used in `org-babel-expand-header-arg-vars:scheme' does
not add trailing newline, unlike done previously.

Am I not adding a newline? I think I do?:

~~~~
...

(mapconcat
   (lambda (var)
     (format "(define %S %S)" (car var) (cdr var)))
   vars
   "\n")

...
~~~~

Is anything else required? Maybe 2 newlines instead? The previous version had a number of spaces as well, but since `define' is not creating additional indent like `let' should, I leave those away.

Thank you for the feedback!

I have a question or suggestion:

When I save the file in Emacs, my Emacs turns all the tabs in there into spaces. Probably my own custom global config's choice about indentation. Could a general mode line thing be added to avoid that and nail down the current formatting style, so that contributors only need to allow Emacs to run those settings and then not need to care about it? Currently the indentation style seems to be a mix of tabs and spaces.

(For example the GNU Guix project does a lot of formatting things in their files, that configure Emacs, so that the formatting will be automatically according to their practices.)

Otherwise the diff becomes huge and I have to discard all those tab -> spaces changes again, before I can make a patch. Or I have to edit in fundamental mode, which loses syntax highlighting and is what I have been doing. But even in fundamental-mode Emacs changes some of the indentation from tabs to spaces or spaces to tabs apparently. Maybe I should be editing with emacs -Q or something? But then I don't have magit. This creates quite some friction in the editing process for me. In fundamental mode, I have to discard 4-6 chunks, which I did not even touch, but which were changed in terms of what the indentation consists of.

And one more question:

Does the name of the patch file matter? Git changed the name and I will attach it as it was created by git. Hope that's alright.

Attached: The updated patch.

And of course: Let me know if it needs more changes.

Regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl
--------------EVB8oCZvaNA4sUi0sogiDOk4-- --------------Lpqc0EvJ7iRyY0PddNggLO7e Content-Type: text/x-patch; charset=UTF-8; name="0001-org-babel-expand-body-scheme-define-header-arg-vars-.patch" Content-Disposition: attachment; filename*0="0001-org-babel-expand-body-scheme-define-header-arg-vars-.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA5OWEzOGU2N2ExNmM3NTQxY2UyZDVkYTJkOGQ0NmU1OTE0ZTU1OWFlIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBaZWxwaGlyIEthbHRzdGFobCA8emVscGhpcmthbHRz dGFobEBwb3N0ZW8uZGU+CkRhdGU6IFNhdCwgMjUgTWFyIDIwMjMgMTU6MjE6MzggKzAxMDAK U3ViamVjdDogW1BBVENIXSBvcmctYmFiZWwtZXhwYW5kLWJvZHk6c2NoZW1lOiBkZWZpbmUg aGVhZGVyIGFyZyB2YXJzIHVzaW5nCiBkZWZpbmUKCiogb2Itc2NoZW1lLmVsIChvcmctYmFi ZWwtZXhwYW5kLWJvZHk6c2NoZW1lLApvcmctYmFiZWwtZXhwYW5kLWhlYWRlci1hcmctdmFy czpzY2hlbWUpOiBDaGFuZ2UgdGhlIHdheSBoZWFkZXIKYXJndW1lbnQgOnZhciB2YXJpYWJs ZXMgYXJlIGV4cGFuZGVkIGZvciBmb3IgU2NoZW1lIHNvdXJjZSBibG9ja3MuICBVc2UKYGRl ZmluZScgaW5zdGVhZCBvZiB3cmFwcGluZyB1c2luZyBgbGV0Jy4KCldyYXBwaW5nIGJpbmRp bmcgZGVmaW5pdGlvbnMgdXNpbmcgYGxldCcgY2FuIGxlYWQgdG8gaXNzdWVzIHdpdGggR05V Ckd1aWxlIGFuZCBwb3RlbnRpYWxseSBvdGhlciBTY2hlbWUgZGlhbGVjdHMuICBHTlUgR3Vp bGUgd2lsbCBvbmx5IGdldAp0byB0aGUgYm9keSBvZiB0aGUgbGV0IGF0IGV2YWx1YXRpb24g dGltZSwgbm90IGF0IG1hY3JvIGV4cGFuc2lvbgp0aW1lLiAgSWYgdGhlIGxldCBmb3JtIHdy YXBzIGFueSBpbXBvcnRzIG9mIGxpYnJhcmllcyB0aGF0IGRlZmluZQptYWNyb3MsIHRoZW4g dGhvc2UgaW1wb3J0ZWQgbWFjcm9zIGFyZSBzZWVuIHRvbyBsYXRlIGFuZCB0aGVpcgpjb3Jy ZXNwb25kaW5nIGZvcm1zIGluc2lkZSB0aGUgYm9keSBvZiB0aGUgbGV0IGFyZSBub3QKZXhw YW5kZWQuICBVc2luZyBgZGVmaW5lJyB0byBkZWZpbmUgYmluZGluZ3MgYXZvaWRzIHRoaXMg cHJvYmxlbSwgYXQKbGVhc3QgaW4gR05VIEd1aWxlLgoKRm9yIG1vcmUgY29udGV4dCBzZWUg dGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGF0OiBodHRwczovL2xpc3RzLmdudS5vcmcv YXJjaGl2ZS9odG1sL2VtYWNzLW9yZ21vZGUvMjAyMy0wMy9tc2cwMDA4Ny5odG1sCi0tLQog bGlzcC9vYi1zY2hlbWUuZWwgfCAxNiArKysrKysrKystLS0tLS0tCiAxIGZpbGUgY2hhbmdl ZCwgOSBpbnNlcnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3Av b2Itc2NoZW1lLmVsIGIvbGlzcC9vYi1zY2hlbWUuZWwKaW5kZXggOWYxMmY0MmNiLi43NDI0 YWI2NTIgMTAwNjQ0Ci0tLSBhL2xpc3Avb2Itc2NoZW1lLmVsCisrKyBiL2xpc3Avb2Itc2No ZW1lLmVsCkBAIC03OSw2ICs3OSwxNCBAQAogKGRlZnZhciBvcmctYmFiZWwtZGVmYXVsdC1o ZWFkZXItYXJnczpzY2hlbWUgJygpCiAgICJEZWZhdWx0IGhlYWRlciBhcmd1bWVudHMgZm9y IHNjaGVtZSBjb2RlIGJsb2Nrcy4iKQogCisoZGVmdW4gb3JnLWJhYmVsLXNjaGVtZS1leHBh bmQtaGVhZGVyLWFyZy12YXJzICh2YXJzKQorICAiRXhwYW5kIDp2YXIgaGVhZGVyIGFyZ3Vt ZW50cyBnaXZlbiBhcyBWQVJTLiIKKyAgKG1hcGNvbmNhdAorICAgKGxhbWJkYSAodmFyKQor ICAgICAoZm9ybWF0ICIoZGVmaW5lICVTICVTKSIgKGNhciB2YXIpIChjZHIgdmFyKSkpCisg ICB2YXJzCisgICAiXG4iKSkKKwogKGRlZnVuIG9yZy1iYWJlbC1leHBhbmQtYm9keTpzY2hl bWUgKGJvZHkgcGFyYW1zKQogICAiRXhwYW5kIEJPRFkgYWNjb3JkaW5nIHRvIFBBUkFNUywg cmV0dXJuIHRoZSBleHBhbmRlZCBib2R5LiIKICAgKGxldCAoKHZhcnMgKG9yZy1iYWJlbC0t Z2V0LXZhcnMgcGFyYW1zKSkKQEAgLTg2LDEzICs5NCw3IEBACiAJKHBvc3RwZW5kcyAoY2Ry IChhc3NxIDplcGlsb2d1ZSBwYXJhbXMpKSkpCiAgICAgKGNvbmNhdCAoYW5kIHByZXBlbmRz IChjb25jYXQgcHJlcGVuZHMgIlxuIikpCiAJICAgIChpZiAobnVsbCB2YXJzKSBib2R5Ci0J ICAgICAgKGZvcm1hdCAiKGxldCAoJXMpXG4lc1xuKSIKLQkJICAgICAgKG1hcGNvbmNhdAot CQkgICAgICAgKGxhbWJkYSAodmFyKQotCQkJIChmb3JtYXQgIiVTIiAocHJpbnQgYCgsKGNh ciB2YXIpICcsKGNkciB2YXIpKSkpKQotCQkgICAgICAgdmFycwotCQkgICAgICAgIlxuICAg ICAgIikKLQkJICAgICAgYm9keSkpCisJICAgICAgKGNvbmNhdCAob3JnLWJhYmVsLXNjaGVt ZS1leHBhbmQtaGVhZGVyLWFyZy12YXJzIHZhcnMpIGJvZHkpKQogCSAgICAoYW5kIHBvc3Rw ZW5kcyAoY29uY2F0ICJcbiIgcG9zdHBlbmRzKSkpKSkKIAogCi0tIAoyLjI1LjEKCg== --------------Lpqc0EvJ7iRyY0PddNggLO7e--