bug#22032: 24.3; VC doesn't handle hg hidden revisions

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Glenn Hutchings]

In the *vc-change-log* buffer, pressing '=' should display the diff 
twixt the current and previous revisions. This fails when (1) the HG 
backend is being used, and (2) the mercurial change history contains 
hidden revisions.

Hidden revisions are a fairly recent mercurial feature. By default, 
they're not displayed; hg needs a "--hidden" argument to consider them. 
This makes the changeset numbers non-consecutive. Here's an example:

changeset: 2:8ba76001308a
tag: tip
user: Glenn Hutchings <zondo42@gmail.com>
date: Fri Nov 27 11:11:06 2015 +0000
summary: Add a line.

changeset: 0:db414dd2e5c1
user: Glenn Hutchings <zondo42@gmail.com>
date: Fri Nov 27 11:10:31 2015 +0000
summary: Add file.

The lisp function to find the previous rev number 
(vc-hg-previous-revision) just decrements the current rev by 1. In the 
example above, doing a diff on changeset 2 would try to use the hidden 
revision 1 and then mercurial gives an error to the effect of "rev 1 is 
hidden" (sorry, don't have the exact text to hand). Possible fix: 
actually move to the previous rev in the buffer, and get the rev number 
from that.

To repeat it: get a mercurial repo with hidden changeset (as above) and 
try the command with latest mercurial.

In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7)
of 2014-03-07 on lamiak, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description: Linux Mint 17.2 Rafaela

Configured using:
`configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
'--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
'--localstatedir=/var/lib' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp' 

'--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
'--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
value of $LANG: en_GB
locale-coding-system: iso-latin-1-unix
default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Loading 00debian-vars...done
Loading /etc/emacs/site-start.d/50a2ps.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Error while loading 50dictionaries-common: Symbol's value as variable is 
void: debian-aspell-only-dictionary-alist
Loading /etc/emacs/site-start.d/50ledger.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/usr/share/emacs24/site-lisp/cmake-data/cmake-mode hides 
/usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs/24.3/site-lisp/debian-startup hides 
/usr/share/emacs/site-lisp/debian-startup

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

On 11/27/2015 01:36 PM, Glenn Hutchings wrote:
> In the *vc-change-log* buffer, pressing '=' should display the diff
> twixt the current and previous revisions. This fails when (1) the HG
> backend is being used, and (2) the mercurial change history contains
> hidden revisions.

Could you link to some relevant documentation? The closest I've been 
able to find mentions "secret changesets".

> Hidden revisions are a fairly recent mercurial feature. By default,
> they're not displayed; hg needs a "--hidden" argument to consider them.

Is there a reason why we wouldn't want to use that argument and just 
always display them?

> The lisp function to find the previous rev number
> (vc-hg-previous-revision) just decrements the current rev by 1. In the
> example above, doing a diff on changeset 2 would try to use the hidden
> revision 1 and then mercurial gives an error to the effect of "rev 1 is
> hidden" (sorry, don't have the exact text to hand).

Would calling 'hg diff --hidden' help?

> Possible fix:
> actually move to the previous rev in the buffer, and get the rev number
> from that.

Unfortunately, vc-hg-previous-revision is not always called from the 
vc-log buffer. E.g. it's also called from the vc-annotate buffer. So 
we'd need a more reliable way to detect the previous revision. Such as 
an Hg command line invocation, probably.

> To repeat it: get a mercurial repo with hidden changeset (as above) and
> try the command with latest mercurial.

A publicly available example would be nice.

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

Hi Glenn,

Please keep the bug address in Cc. I'm reproducing the entirety of your 
email here for posterity.

On 11/28/2015 05:07 PM, Glenn Hutchings wrote:

> Thanks for the quick response.  I've been doing a bit more digging for
> info about this, and think I've figured out exactly how I got into the
> situation.  There's an experimental set of features called Changeset
> Evolution <https://www.mercurial-scm.org/wiki/ChangesetEvolution> that
> modifies the way mercurial rewrites history: instead of stripping a
> changeset, it marks it 'obsolete'.  Looks like these features were
> introduced at version 2.9, but by default none of them are used by the
> core mercurial commands.  But a recent extension called Evolve
> <https://www.mercurial-scm.org/wiki/EvolveExtension> does use it.  If
> you enable that extension, and then perform a "commit --amend", instead
> of updating the head changeset, it creates a new one and makes the
> previous one obsolete (and 'hidden' by default in the change log).
>
> Long story short: the gap in rev numbers only occurs if you enable the
> 'evolve' extension (or another which uses the changeset-evolution
> features) and use a history-modifying command.  I recently tried the
> extension out, which is when I came across the bug.

I see.

>> Is there a reason why we wouldn't want to use that argument and just
>> always display them?
>>
>
> Well, the hidden revs are really only used internally, and shouldn't be
> seen by users.
>
>> Would calling 'hg diff --hidden' help?
>>
>
> Unfortunately not -- that would only do a diff between the current rev
> and the internal hidden one.  Not what the user really wants.

That makes sense.

> I managed to come up with this, using mercurial's 'revset' feature:
>
>     hg id --hidden -n -r 'first(X:0 and not hidden())'

Thanks. Please try this definition and see if it resolves the problem:

(defun vc-hg-previous-revision (_file rev)
   (let ((newrev (1- (string-to-number rev))))
     (when (>= newrev 0)
       (with-temp-buffer
         (vc-hg-command t 0 nil
                        "id" "--hidden" "-n" "-r"
                        (format "first(%d:0 and not hidden())" newrev))
         ;; Trim the trailing newline.
         (buffer-substring (point-min) (1- (point-max)))))))

> This says to look at all non-hidden revs from X down to zero, choose the
> first one, and print its numeric rev number.  If the current rev is X+1,
> that gives the first previous non-hidden rev.  But I'm sure there must
> be a better way, without having to examine all previous changesets.

If you anticipated that we'd have to make one process call per revision, 
then I think the above definition does better.

> Given the experimental nature of all this evolution stuff, I'm inclined
> to think that it's not all that urgent a problem to resolve right now.
> But if it ever becomes part of core mercurial, it's something to bear in
> mind.

Indeed, it seems there's no hurry. On the other hand, I don't expect 
much harm from installing the new vc-hg-previous-revision definition 
either: it works fine with the version of Mercurial installed on my 
machine (3.4), although in all cases I've tried it basically returned 
the revision passed to it as X.

If it would cause earlier versions of Mercurial to error out, however, 
that would be a reason to hold off on it.

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Glenn Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On 11/28/15 18:09, Dmitry Gutov wrote:
> Please try this definition and see if it resolves the problem:
>
> (defun vc-hg-previous-revision (_file rev)
>   (let ((newrev (1- (string-to-number rev))))
>     (when (>= newrev 0)
>       (with-temp-buffer
>         (vc-hg-command t 0 nil
>                        "id" "--hidden" "-n" "-r"
>                        (format "first(%d:0 and not hidden())" newrev))
>         ;; Trim the trailing newline.
>         (buffer-substring (point-min) (1- (point-max)))))))
>
>> This says to look at all non-hidden revs from X down to zero, choose the
>> first one, and print its numeric rev number.  If the current rev is X+1,
>> that gives the first previous non-hidden rev.  But I'm sure there must
>> be a better way, without having to examine all previous changesets.
>
> If you anticipated that we'd have to make one process call per 
> revision, then I think the above definition does better.
I tried this, and it works fine.  But I discovered another problem for 
VC with the changeset evolution features: if a repository has any 
changesets that are marked 'obsolete', and any mercurial command is 
issued by a user who hasn't enabled the extension, a warning message is 
printed to stderr:

    obsolete feature not enabled but <N> markers found!

If VC grabs this output as part of the mercurial response, and uses it 
in subsequent commands, it (unsurprisingly) fails:

    hg: parse error at 9: invalid token

Looking at mercurial sources, there's no way to suppress this warning.  
I guess one workaround would be to have vc-hg-command skip over it if 
it's there.

Glenn

[-- Attachment #2: Type: text/html, Size: 2477 bytes --]

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

On 12/13/2015 12:54 PM, Glenn Hutchings wrote:
> if a repository has any
> changesets that are marked 'obsolete', and any mercurial command is
> issued by a user who hasn't enabled the extension, a warning message is
> printed to stderr:
>
>     obsolete feature not enabled but <N> markers found!

That's a pretty unhelpful message. Does it also happen if you remove the 
"--hidden" flag from the proposed definition?

Actually, do we even need the "not hidden()" check in the spec, if the 
command is called without "--hidden"?

> Looking at mercurial sources, there's no way to suppress this warning.
> I guess one workaround would be to have vc-hg-command skip over it if
> it's there.

I think we'd rather avoid applying the patch until the extension becomes 
standard.

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

Please keep the bug address in Cc.

On 12/15/2015 07:59 AM, Glenn Hutchings wrote:

> Alas, omitting "--hidden" causes Mercurial to give an error when passed
> a hidden changeset ID.

That's too bad.

But if the revision spec allows open intervals though, we could pass the 
current (non-hidden) revision to it. Maybe something like

(defun vc-hg-previous-revision (_file rev)
   (with-temp-buffer
     (vc-hg-command t 0 nil
                    "id" "--hidden" "-n" "-r"
                    (format "second(%s:0 and not hidden())" rev))
     ;; Trim the trailing newline.
     (buffer-substring (point-min) (1- (point-max)))))

?

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Andy Moreton]

On Sat 28 Nov 2015, Dmitry Gutov wrote:

> Hi Glenn,
>
> Please keep the bug address in Cc. I'm reproducing the entirety of your email
> here for posterity.
>
> On 11/28/2015 05:07 PM, Glenn Hutchings wrote:
>
>> Thanks for the quick response.  I've been doing a bit more digging for
>> info about this, and think I've figured out exactly how I got into the
>> situation.  There's an experimental set of features called Changeset
>> Evolution <https://www.mercurial-scm.org/wiki/ChangesetEvolution> that
>> modifies the way mercurial rewrites history: instead of stripping a
>> changeset, it marks it 'obsolete'.  Looks like these features were
>> introduced at version 2.9, but by default none of them are used by the
>> core mercurial commands.  But a recent extension called Evolve
>> <https://www.mercurial-scm.org/wiki/EvolveExtension> does use it.  If
>> you enable that extension, and then perform a "commit --amend", instead
>> of updating the head changeset, it creates a new one and makes the
>> previous one obsolete (and 'hidden' by default in the change log).
>>
>> Long story short: the gap in rev numbers only occurs if you enable the
>> 'evolve' extension (or another which uses the changeset-evolution
>> features) and use a history-modifying command.  I recently tried the
>> extension out, which is when I came across the bug.
>
> I see.
>
>>> Is there a reason why we wouldn't want to use that argument and just
>>> always display them?
>>>
>>
>> Well, the hidden revs are really only used internally, and shouldn't be
>> seen by users.
>>
>>> Would calling 'hg diff --hidden' help?
>>>
>>
>> Unfortunately not -- that would only do a diff between the current rev
>> and the internal hidden one.  Not what the user really wants.
>
> That makes sense.

This problem with revision IDs also accurs if the repo contains named
branches. in that case the numerically previous revision may be on a
different branch, resulting in a meaningless diff that is slow to
compute.

For example (from a non-public repo with named branches), where rev
59951 and rev 59950 are on different named branches:
  $ hg diff -r59951 -r59950 | wc -l
  88188
  $ hg diff -r59951 -r59951^ | wc -l
  70
  $ hg id -n -r59951^
  59925

The first example diffs agaist the previous revision ID (which is on a
different branch), and produces large and useless diff output. The second
example diffs against the (first) parent, and is what is actually wanted.

>> I managed to come up with this, using mercurial's 'revset' feature:
>>
>>     hg id --hidden -n -r 'first(X:0 and not hidden())'
>
> Thanks. Please try this definition and see if it resolves the problem:
>
> (defun vc-hg-previous-revision (_file rev)
>   (let ((newrev (1- (string-to-number rev))))
>     (when (>= newrev 0)
>       (with-temp-buffer
>         (vc-hg-command t 0 nil
>                        "id" "--hidden" "-n" "-r"
>                        (format "first(%d:0 and not hidden())" newrev))
>         ;; Trim the trailing newline.
>         (buffer-substring (point-min) (1- (point-max)))))))
>
>> This says to look at all non-hidden revs from X down to zero, choose the
>> first one, and print its numeric rev number.  If the current rev is X+1,
>> that gives the first previous non-hidden rev.  But I'm sure there must
>> be a better way, without having to examine all previous changesets.
>
> If you anticipated that we'd have to make one process call per revision, then
> I think the above definition does better.

To also work with named branches, something like this (untested) would be better:
    (format "last(ancestors(%d) and not hidden())" newrev)

>> Given the experimental nature of all this evolution stuff, I'm inclined
>> to think that it's not all that urgent a problem to resolve right now.
>> But if it ever becomes part of core mercurial, it's something to bear in
>> mind.
>
> Indeed, it seems there's no hurry. On the other hand, I don't expect much harm
> from installing the new vc-hg-previous-revision definition either: it works
> fine with the version of Mercurial installed on my machine (3.4), although in
> all cases I've tried it basically returned the revision passed to it as X.
>
> If it would cause earlier versions of Mercurial to error out, however, that
> would be a reason to hold off on it.

Indeed - even after the evolution stuff has matured further, there will
still be a large population of machines that are running older versions
of Mercurial, and will not understand the "hidden()" predicate.

    AndyM

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

On 12/16/2015 01:53 AM, Andy Moreton wrote:

> This problem with revision IDs also accurs if the repo contains named
> branches. in that case the numerically previous revision may be on a
> different branch, resulting in a meaningless diff that is slow to
> compute.

So it's a bug in the current implementation, even without hidden revisions?

I'll try to remember this next time someone tells me about 
user-friendliness of numeric revisions. :)

> For example (from a non-public repo with named branches), where rev
> 59951 and rev 59950 are on different named branches:
>    $ hg diff -r59951 -r59950 | wc -l
>    88188
>    $ hg diff -r59951 -r59951^ | wc -l
>    70
>    $ hg id -n -r59951^
>    59925
>
> The first example diffs agaist the previous revision ID (which is on a
> different branch), and produces large and useless diff output. The second
> example diffs against the (first) parent, and is what is actually wanted.

If there's a direct counterpart to 'git rev-parse 59951^', it would be 
handy here.

> To also work with named branches, something like this (untested) would be better:
>      (format "last(ancestors(%d) and not hidden())" newrev)

So, what if we don't pass "--hidden" to this command? Will `ancestors' 
error out upon encountering a hidden revision, or will they skip to the 
first visible one?

In the latter case, there's no need to check 'not hidden()', and the 
compatibility problem can be solved like that.

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Andy Moreton]

On Wed 16 Dec 2015, Dmitry Gutov wrote:

> On 12/16/2015 01:53 AM, Andy Moreton wrote:
>
>> This problem with revision IDs also accurs if the repo contains named
>> branches. in that case the numerically previous revision may be on a
>> different branch, resulting in a meaningless diff that is slow to
>> compute.
>
> So it's a bug in the current implementation, even without hidden revisions?

Yes.

> I'll try to remember this next time someone tells me about user-friendliness
> of numeric revisions. :)
>
>> For example (from a non-public repo with named branches), where rev
>> 59951 and rev 59950 are on different named branches:
>>    $ hg diff -r59951 -r59950 | wc -l
>>    88188
>>    $ hg diff -r59951 -r59951^ | wc -l
>>    70
>>    $ hg id -n -r59951^
>>    59925
>>
>> The first example diffs agaist the previous revision ID (which is on a
>> different branch), and produces large and useless diff output. The second
>> example diffs against the (first) parent, and is what is actually wanted.
>
> If there's a direct counterpart to 'git rev-parse 59951^', it would be handy
> here.

You mean like the "hg id" line in the example above ?

>> To also work with named branches, something like this (untested) would be better:
>>      (format "last(ancestors(%d) and not hidden())" newrev)
>
> So, what if we don't pass "--hidden" to this command? Will `ancestors' error
> out upon encountering a hidden revision, or will they skip to the first
> visible one?

No idea - I haven't used this new feature, or spent the time to
construct a test repo with hidden revisions to find out.

> In the latter case, there's no need to check 'not hidden()', and the
> compatibility problem can be solved like that.

Perhaps - but it needs to be tested to find out.

    AndyM

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

On 12/16/2015 05:02 AM, Andy Moreton wrote:

>> If there's a direct counterpart to 'git rev-parse 59951^', it would be handy
>> here.
>
> You mean like the "hg id" line in the example above ?

Um, yes. Thanks for the explanation, I've pushed the new definition of 
vc-hg-previous-revision that uses 'hg id -n -r 123^' to emacs-25.

It seems to work fine, if a little surprising for merge commits when 
vc-hg-log-graph is nil (which it is by default). Also, calling Hg is not 
free, and adds ~120 ms on my machine.

Glenn, could you if it solves the hidden revision problem as well?

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Glenn Hutchings]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On 12/18/15 05:02, Dmitry Gutov wrote:
> On 12/16/2015 05:02 AM, Andy Moreton wrote:
>
>>> If there's a direct counterpart to 'git rev-parse 59951^', it would 
>>> be handy
>>> here.
>>
>> You mean like the "hg id" line in the example above ?
>
> Um, yes. Thanks for the explanation, I've pushed the new definition of 
> vc-hg-previous-revision that uses 'hg id -n -r 123^' to emacs-25.
>
> It seems to work fine, if a little surprising for merge commits when 
> vc-hg-log-graph is nil (which it is by default). Also, calling Hg is 
> not free, and adds ~120 ms on my machine.
>
> Glenn, could you if it solves the hidden revision problem as well?

Yes, it does.  I've created a test script which recreates the problem 
(and solution) quite nicely.  Attached is the script, and its output.

Glenn

[-- Attachment #2: script.sh --]
[-- Type: application/x-shellscript, Size: 1178 bytes --]

[-- Attachment #3: script.txt --]
[-- Type: text/plain, Size: 1621 bytes --]

+ repo=repo
+ file=repo/readme.txt
+ hg=hg -R repo
+ rm -rf repo
+ hg init repo
+ cat
+ cat
+ hg -R repo add repo/readme.txt
+ hg -R repo ci -m Birth.
+ cat
+ hg -R repo ci -m Life.
+ cat
+ hg -R repo ci -m Death. --amend
+ hg -R repo glog
@  changeset:   3:6beb1647b809
|  tag:         tip
|  parent:      0:9134909c2dbf
|  user:        Glenn Hutchings <zondo42@gmail.com>
|  date:        Tue Dec 22 20:11:10 2015 +0000
|  summary:     Death.
|
o  changeset:   0:9134909c2dbf
   user:        Glenn Hutchings <zondo42@gmail.com>
   date:        Tue Dec 22 20:11:10 2015 +0000
   summary:     Birth.

+ hg -R repo --hidden glog
@  changeset:   3:6beb1647b809
|  tag:         tip
|  parent:      0:9134909c2dbf
|  user:        Glenn Hutchings <zondo42@gmail.com>
|  date:        Tue Dec 22 20:11:10 2015 +0000
|  summary:     Death.
|
| x  changeset:   2:9964f5fac22b
| |  user:        Glenn Hutchings <zondo42@gmail.com>
| |  date:        Tue Dec 22 20:11:10 2015 +0000
| |  summary:     temporary amend commit for 16e951eccb81
| |
| x  changeset:   1:16e951eccb81
|/   user:        Glenn Hutchings <zondo42@gmail.com>
|    date:        Tue Dec 22 20:11:10 2015 +0000
|    summary:     Life.
|
o  changeset:   0:9134909c2dbf
   user:        Glenn Hutchings <zondo42@gmail.com>
   date:        Tue Dec 22 20:11:10 2015 +0000
   summary:     Birth.

+ hg -R repo id -n -r tip
+ tip=3
+ expr 3 - 1
+ hg -R repo id -n -r 2
abort: hidden revision '2'!
(use --hidden to access hidden revisions)
+ hg -R repo id -n -r 3^
0
+ hg -R repo --config extensions.evolve=! id -n -r 3^
obsolete feature not enabled but 2 markers found!
0

bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Dmitry Gutov]

Version: 25.1

On 12/22/2015 10:17 PM, Glenn Hutchings wrote:

> Yes, it does.  I've created a test script which recreates the problem
> (and solution) quite nicely.  Attached is the script, and its output.

Great! Thanks for checking, and for the neat script.

Closing.