Re: request on pathname-name and pathname-type
Raymond Toy <[email protected]> Thu, 20 Nov 2025 06:02:16 -0800
| Newsgroups | gmane.lisp.gcl.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------1osiVsy2RvpGHQSbZBc6IsX0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 11/19/25 6:55 PM, Matthias Buelow wrote:
> Hi,
>
> I think the main problem here is that Unix-type systems don't really have a
> "file type" in the pathname and therefore the function cannot be implemented in
> a naive way like this. For example, what is a .tar.gz file? A gzip file? No,
> it is really a compressed archive and should be treated as such. File managers
> often have some sort of table that maps filename suffixes to MIME types, plus
> perhaps some other hardcoded logic, but I think that would be outside of the
> scope of this function.
>
> IMHO there is no proper way to resolve this in a convincing way, I think the
> method gcl has chosen is a legitimate variant and I can't see a reason why it
> should use just the smallest suffix (the .tar.gz being a counterexample).
On the other hand, I tried |(pathname "foo.xyz.lisp")| with ccl, clisp,
cmucl, ecl, and sbcl. They all said the name was "foo.xyz" and the type
is "lisp".
It would certainly be nice if gcl was consistent with these other lisps,
at least for this case.
I know there are other weird cases where each lisp implementation
produces wildly different pathname objects. But for this relatively
simple case of foo.xyz.lisp, it would be nice to be consistent.
> Best regards
>
> Matthias
>
>
> Am Wed, Nov 19, 2025 at 04:16:34PM -0500 schrieb Camm Maguire:
>> Greetings, and thanks so much for the feedback.
>>
>> It does seem one other user requested this as well. I do not think our
>> behavior violates the spec, but it does vary from other popular
>> implementations.
>>
>> In short, the first '.' terminates the name in GCL. This was convenient
>> in our implementation of pathnames using the regex (e.g. regular
>> expression) engine which has been in GCL for ages. As these follow a
>> left to right algorithm (longest match if I recall), it makes sense to
>> define a terminating character sequence.
>>
>> If interested you can peruse lsp/gcl_make_pathname.lsp, where you will find
>>
>> (defconstant +physical-pathname-defaults+ '(("" "" "" "")
>> ("" "" "" "")
>> ("" "(/?([^/]+/)*)" "" "" "" "([^/]+/)" "/" "/")
>> ("" "([^/.]*)" "" ".")
>> ("." "(\\.[^/]*)?" "" "")
>> ("" "" "" "")))
>>
>> and an analog for logical pathnames that govern the parsing. I can
>> describe the role of each string in the group if interested.
>>
>> I will try to look at the already implemented regex engine to see if a
>> negative look-ahead could be supported.
>>
>> Take care,
>>
>>
>> Matt Kaufmann<[email protected]> writes:
>>
>>> Hi Camm,
>>>
>>> Here's a request: Could you arrange that for any file with a name of the
>>> form "<name>.lisp", then its pathname-name is "<name>" and its
>>> pathname-type is "lisp"? This is not always the case, at least in my
>>> version of GCL 2.7.1, when "<name>" contains a dot (i.e., character
>>> #\.).
>>>
>>> Below I explain further what I'm seeing and why this is a problem for
>>> ACL2. (Probably one can imagine a similar problem for other systems.)
>>>
>>> Here is behavior I'm seeing in GCL 2.7.1, which causes a problem for
>>> ACL2 as explained below.
>>>
>>>> (pathname-name (pathname "foo.xyz.lisp"))
>>> "foo"
>>>
>>>> (pathname-name "foo.xyz.lisp")
>>> "foo"
>>>
>>>> (pathname-type (pathname "foo.xyz.lisp"))
>>> "xyz.lisp"
>>>
>>>> (pathname-type "foo.xyz.lisp")
>>> "xyz.lisp"
>>>
>>> I'd prefer to see the behavior shown in the following example, i.e.,
>>> returning a pathname-type of "lisp".
>>>
>>>> (pathname-name "foo-xyz.lisp")
>>> "foo-xyz"
>>>
>>>> (pathname-type "foo-xyz.lisp")
>>> "lisp"
>>>
>>> I'm not sure this behavior is in error, by the way -- just surprising
>>> (to me) and, in the case of ACL2, inconvenient. Here's what I found
>>> in the CL HyperSPec.
>>>
>>> https://www.lispworks.com/documentation/HyperSpec/Body/19_bae.htm
>>>
>>> 19.2.1.5 The Pathname Type Component
>>>
>>> Corresponds to the ``filetype'' or ``extension'' concept in many
>>> host file systems. This says what kind of file this is. This
>>> component is always a string, nil, :wild, or :unspecific.
>>>
>>> To me, it is natural to view "foo.xyz.lisp" as a lisp file, hence with
>>> extension "lisp" to say that the "kind of file" is a lisp file.
>>>
>>> This gets in the way for ACL2 in the case of the following two books.
>>>
>>> books/projects/aleo/vm/circuits/axe/blake2s1round.old.lisp
>>> books/projects/aleo/vm/circuits/axe/blake2s1round.lisp
>>>
>>> When we do certifications in parallel (i.e., with -j greater than 1),
>>> compilation can be attempted in parallel. The two books above can
>>> thus lead to the following calls done by two GCL processes in
>>> parallel.
>>>
>>> (COMPILE-FILE
>>> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/[email protected]"
>>> :OUTPUT-FILE
>>> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.o")
>>>
>>> (COMPILE-FILE
>>> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.lsp"
>>> :OUTPUT-FILE
>>> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.o")
>>>
>>> Both of these compilations attempt to create the same file,
>>> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.data".
>>> I suspect that if pathname-name were changed as described above, then
>>> the first compile-file call above would instead create
>>> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.data".
>>>
>>> Thanks,
>>> Matt
>>>
>> --
>> Camm Maguire [email protected]
>> ==========================================================================
>> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>>
​
--------------1osiVsy2RvpGHQSbZBc6IsX0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
<title></title>
<meta charset=3D"utf-8">
</head>
<body>
<div class=3D"markdown-here-wrapper">
<p style=3D"margin-bottom: 19.2px; margin-top: 0px;">On 11/19/25
6:55 PM, Matthias Buelow wrote:</p>
<blockquote type=3D"cite"
style=3D"border-block-color: rgb(119, 119, 119); border-bottom-color: rgb=
(119, 119, 119); border-inline-color: rgb(114, 159, 207) rgb(119, 119, 11=
9); border-inline-start: 2px solid rgb(114, 159, 207); border-left: 2px s=
olid rgb(114, 159, 207); border-right-color: rgb(119, 119, 119); border-t=
op-color: rgb(119, 119, 119); color: rgb(119, 119, 119); column-rule-colo=
r: rgb(119, 119, 119); margin: 19.2px 0px; outline-color: rgb(119, 119, 1=
19); padding-inline: 16px; padding-left: 16px; padding-right: 16px; quote=
s: none; text-decoration-color: rgb(119, 119, 119); text-emphasis-color: =
rgb(119, 119, 119);">
<div class=3D"external-content" id=3D"extcontent-0"
style=3D"border-block-color: rgb(119, 119, 119); border-bottom-color: rgb=
(119, 119, 119); border-inline-color: rgb(119, 119, 119); border-left-col=
or: rgb(119, 119, 119); border-right-color: rgb(119, 119, 119); border-to=
p-color: rgb(119, 119, 119); color: rgb(119, 119, 119); column-rule-color=
: rgb(119, 119, 119); outline-color: rgb(119, 119, 119); quotes: none; te=
xt-decoration-color: rgb(119, 119, 119); text-emphasis-color: rgb(119, 11=
9, 119);">
<pre wrap=3D"" class=3D"moz-quote-pre">Hi,
I think the main problem here is that Unix-type systems don't really have=
a
"file type" in the pathname and therefore the function cannot be implemen=
ted in
a naive way like this. For example, what is a .tar.gz file? A gzip file? =
No,
it is really a compressed archive and should be treated as such. File man=
agers
often have some sort of table that maps filename suffixes to MIME types, =
plus
perhaps some other hardcoded logic, but I think that would be outside of =
the
scope of this function.
IMHO there is no proper way to resolve this in a convincing way, I think =
the
method gcl has chosen is a legitimate variant and I can't see a reason wh=
y it
should use just the smallest suffix (the .tar.gz being a counterexample).=
</pre>
</div>
</blockquote>
<p style=3D"margin-bottom: 19.2px; margin-top: 0px;">On the other
hand, I tried <code
style=3D"background-color: rgba(175, 184, 193, 0.2); border-bottom-left-r=
adius: 3px; border-bottom-right-radius: 3px; border-end-end-radius: 3px; =
border-end-start-radius: 3px; border-start-end-radius: 3px; border-start-=
start-radius: 3px; border-top-left-radius: 3px; border-top-right-radius: =
3px; font-family: Consolas, Inconsolata, Courier, monospace; font-size: 1=
6px; font-weight: 550; margin-left: 2.4px; margin-right: 2.4px; padding-i=
nline: 4.8px; padding-left: 4.8px; padding-right: 4.8px; white-space-coll=
apse: preserve;">(pathname "foo.xyz.lisp")</code>
with ccl, clisp, cmucl, ecl, and sbcl. They all said the name
was "foo.xyz" and the type is "lisp". </p>
<p style=3D"margin-bottom: 19.2px; margin-top: 0px;">It would
certainly be nice if gcl was consistent with these other lisps,
at least for this case. </p>
<p style=3D"margin-bottom: 19.2px; margin-top: 0px;">I know there
are other weird cases where each lisp implementation produces
wildly different pathname objects. But for this relatively
simple case of foo.xyz.lisp, it would be nice to be consistent.</=
p>
<blockquote type=3D"cite"
style=3D"border-block-color: rgb(119, 119, 119); border-bottom-color: rgb=
(119, 119, 119); border-inline-color: rgb(114, 159, 207) rgb(119, 119, 11=
9); border-inline-start: 2px solid rgb(114, 159, 207); border-left: 2px s=
olid rgb(114, 159, 207); border-right-color: rgb(119, 119, 119); border-t=
op-color: rgb(119, 119, 119); color: rgb(119, 119, 119); column-rule-colo=
r: rgb(119, 119, 119); margin: 19.2px 0px; outline-color: rgb(119, 119, 1=
19); padding-inline: 16px; padding-left: 16px; padding-right: 16px; quote=
s: none; text-decoration-color: rgb(119, 119, 119); text-emphasis-color: =
rgb(119, 119, 119);">
<div class=3D"external-content" id=3D"extcontent-1"
style=3D"border-block-color: rgb(119, 119, 119); border-bottom-color: rgb=
(119, 119, 119); border-inline-color: rgb(119, 119, 119); border-left-col=
or: rgb(119, 119, 119); border-right-color: rgb(119, 119, 119); border-to=
p-color: rgb(119, 119, 119); color: rgb(119, 119, 119); column-rule-color=
: rgb(119, 119, 119); outline-color: rgb(119, 119, 119); quotes: none; te=
xt-decoration-color: rgb(119, 119, 119); text-emphasis-color: rgb(119, 11=
9, 119);">
<pre wrap=3D"" class=3D"moz-quote-pre">Best regards
Matthias
Am Wed, Nov 19, 2025 at 04:16:34PM -0500 schrieb Camm Maguire:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">Greetings, and thanks =
so much for the feedback.
It does seem one other user requested this as well. I do not think our
behavior violates the spec, but it does vary from other popular
implementations.
In short, the first '.' terminates the name in GCL. This was convenient
in our implementation of pathnames using the regex (e.g. regular
expression) engine which has been in GCL for ages. As these follow a
left to right algorithm (longest match if I recall), it makes sense to
define a terminating character sequence.
If interested you can peruse lsp/gcl_make_pathname.lsp, where you will fi=
nd
(defconstant +physical-pathname-defaults+ '(("" "" "" "")
("" "" "" "")
("" "(/?([^/]+/)*)" "" "" "" "([^/]+/)" "/" "/")
("" "([^/.]*)" "" ".")
("." "(\\.[^/]*)?" "" "")
("" "" "" "")))
and an analog for logical pathnames that govern the parsing. I can
describe the role of each string in the group if interested.
I will try to look at the already implemented regex engine to see if a
negative look-ahead could be supported.
Take care,
Matt Kaufmann <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:matthew.j=
[email protected]"><[email protected]></a> writes:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">Hi Camm,
Here's a request: Could you arrange that for any file with a name of the
form "<name>.lisp", then its pathname-name is "<name>" and it=
s
pathname-type is "lisp"? This is not always the case, at least in my
version of GCL 2.7.1, when "<name>" contains a dot (i.e., character=
#\.).
Below I explain further what I'm seeing and why this is a problem for
ACL2. (Probably one can imagine a similar problem for other systems.)
Here is behavior I'm seeing in GCL 2.7.1, which causes a problem for
ACL2 as explained below.
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">(pathname-name (pa=
thname "foo.xyz.lisp"))
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">"foo"
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">(pathname-name "fo=
o.xyz.lisp")
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">"foo"
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">(pathname-type (pa=
thname "foo.xyz.lisp"))
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">"xyz.lisp"
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">(pathname-type "fo=
o.xyz.lisp")
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">"xyz.lisp"
</pre>
<pre wrap=3D"" class=3D"moz-quote-pre">I'd prefer to see th=
e behavior shown in the following example, i.e.,
returning a pathname-type of "lisp".
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">(pathname-name "fo=
o-xyz.lisp")
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">"foo-xyz"
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">(pathname-type "fo=
o-xyz.lisp")
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">"lisp"
</pre>
<pre wrap=3D"" class=3D"moz-quote-pre">I'm not sure this be=
havior is in error, by the way -- just surprising
(to me) and, in the case of ACL2, inconvenient. Here's what I found
in the CL HyperSPec.
<a class=3D"moz-txt-link-freetext" href=3D"https://www.lispworks.com/docu=
mentation/HyperSpec/Body/19_bae.htm">https://www.lispworks.com/documentat=
ion/HyperSpec/Body/19_bae.htm</a>
19.2.1.5 The Pathname Type Component
Corresponds to the ``filetype'' or ``extension'' concept in many
host file systems. This says what kind of file this is. This
component is always a string, nil, :wild, or :unspecific.
To me, it is natural to view "foo.xyz.lisp" as a lisp file, hence with
extension "lisp" to say that the "kind of file" is a lisp file.
This gets in the way for ACL2 in the case of the following two books.
books/projects/aleo/vm/circuits/axe/blake2s1round.old.lisp
books/projects/aleo/vm/circuits/axe/blake2s1round.lisp
When we do certifications in parallel (i.e., with -j greater than 1),
compilation can be attempted in parallel. The two books above can
thus lead to the following calls done by two GCL processes in
parallel.
(COMPILE-FILE
"<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.=
[email protected]"
:OUTPUT-FILE
"<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.=
old.o")
(COMPILE-FILE
"<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.=
lsp"
:OUTPUT-FILE
"<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.=
o")
Both of these compilations attempt to create the same file,
"<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.d=
ata".
I suspect that if pathname-name were changed as described above, then
the first compile-file call above would instead create
"<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.o=
ld.data".
Thanks,
Matt
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">--=20
Camm Maguire <a class=3D"moz-txt-link-abbreviated" href=3D"m=
ailto:[email protected]">[email protected]</a>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
"The earth is but one country, and mankind its citizens." -- Baha'u'lla=
h
</pre>
</blockquote>
</div>
</blockquote>
</div>
<div class=3D"mdhr-raw"
style=3D"height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-s=
ize:0;padding:0;margin:0;"
aria-hidden=3D"true"
title=3D"MDH:PHA+PGJyPjwvcD48ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDEx=
LzE5LzI1IDY6NTUgUE0sIE1hdHRoaWFzIEJ1ZWxvdyB3cm90ZTo8YnI+PC9kaXY+PGJsb2Nrc=
XVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmFSNkRGMFZ3dTNOMFVLVmNAeXVnZ290aC5ta2=
J1ZWxvdy5kZSI+PHByZSB3cmFwPSIiIGNsYXNzPSJtb3otcXVvdGUtcHJlIj5IaSwKCkkgdGh=
pbmsgdGhlIG1haW4gcHJvYmxlbSBoZXJlIGlzIHRoYXQgVW5peC10eXBlIHN5c3RlbXMgZG9u=
J3QgcmVhbGx5IGhhdmUgYQoiZmlsZSB0eXBlIiBpbiB0aGUgcGF0aG5hbWUgYW5kIHRoZXJlZ=
m9yZSB0aGUgZnVuY3Rpb24gY2Fubm90IGJlIGltcGxlbWVudGVkIGluCmEgbmFpdmUgd2F5IG=
xpa2UgdGhpcy4gRm9yIGV4YW1wbGUsIHdoYXQgaXMgYSAudGFyLmd6IGZpbGU/IEEgZ3ppcCB=
maWxlPyBObywKaXQgaXMgcmVhbGx5IGEgY29tcHJlc3NlZCBhcmNoaXZlIGFuZCBzaG91bGQg=
YmUgdHJlYXRlZCBhcyBzdWNoLiBGaWxlIG1hbmFnZXJzCm9mdGVuIGhhdmUgc29tZSBzb3J0I=
G9mIHRhYmxlIHRoYXQgbWFwcyBmaWxlbmFtZSBzdWZmaXhlcyB0byBNSU1FIHR5cGVzLCBwbH=
VzCnBlcmhhcHMgc29tZSBvdGhlciBoYXJkY29kZWQgbG9naWMsIGJ1dCBJIHRoaW5rIHRoYXQ=
gd291bGQgYmUgb3V0c2lkZSBvZiB0aGUKc2NvcGUgb2YgdGhpcyBmdW5jdGlvbi4KCklNSE8g=
dGhlcmUgaXMgbm8gcHJvcGVyIHdheSB0byByZXNvbHZlIHRoaXMgaW4gYSBjb252aW5jaW5nI=
HdheSwgSSB0aGluayB0aGUKbWV0aG9kIGdjbCBoYXMgY2hvc2VuIGlzIGEgbGVnaXRpbWF0ZS=
B2YXJpYW50IGFuZCBJIGNhbid0IHNlZSBhIHJlYXNvbiB3aHkgaXQKc2hvdWxkIHVzZSBqdXN=
0IHRoZSBzbWFsbGVzdCBzdWZmaXggKHRoZSAudGFyLmd6IGJlaW5nIGEgY291bnRlcmV4YW1w=
bGUpLjwvcHJlPjwvYmxvY2txdW90ZT48cD5PbiB0aGUgb3RoZXIgaGFuZCwgSSB0cmllZCBgK=
HBhdGhuYW1lICJmb28ueHl6Lmxpc3AiKWAgd2l0aCBjY2wsIGNsaXNwLCBjbXVjbCwgZWNsLC=
BhbmQgc2JjbC4mbmJzcDsgVGhleSBhbGwgc2FpZCB0aGUgbmFtZSB3YXMgImZvby54eXoiIGF=
uZCB0aGUgdHlwZSBpcyAibGlzcCIuJm5ic3A7Jm5ic3A7PC9wPjxwPkl0IHdvdWxkIGNlcnRh=
aW5seSBiZSBuaWNlIGlmIGdjbCB3YXMgY29uc2lzdGVudCB3aXRoIHRoZXNlIG90aGVyIGxpc=
3BzLCBhdCBsZWFzdCBmb3IgdGhpcyBjYXNlLiZuYnNwOyZuYnNwOzwvcD48cD5JIGtub3cgdG=
hlcmUgYXJlIG90aGVyIHdlaXJkIGNhc2VzIHdoZXJlIGVhY2ggbGlzcCBpbXBsZW1lbnRhdGl=
vbiBwcm9kdWNlcyB3aWxkbHkgZGlmZmVyZW50IHBhdGhuYW1lIG9iamVjdHMuJm5ic3A7IEJ1=
dCBmb3IgdGhpcyByZWxhdGl2ZWx5IHNpbXBsZSBjYXNlIG9mIGZvby54eXoubGlzcCwgaXQgd=
291bGQgYmUgbmljZSB0byBiZSBjb25zaXN0ZW50LjwvcD48YmxvY2txdW90ZSB0eXBlPSJjaX=
RlIiBjaXRlPSJtaWQ6YVI2REYwVnd1M04wVUtWY0B5dWdnb3RoLm1rYnVlbG93LmRlIj48cHJ=
lIHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUiPgoKQmVzdCByZWdhcmRzCgpNYXR0aGlh=
cwoKCkFtIFdlZCwgTm92IDE5LCAyMDI1IGF0IDA0OjE2OjM0UE0gLTA1MDAgc2NocmllYiBDY=
W1tIE1hZ3VpcmU6CjwvcHJlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIi=
BjbGFzcz0ibW96LXF1b3RlLXByZSI+R3JlZXRpbmdzLCBhbmQgdGhhbmtzIHNvIG11Y2ggZm9=
yIHRoZSBmZWVkYmFjay4KCkl0IGRvZXMgc2VlbSBvbmUgb3RoZXIgdXNlciByZXF1ZXN0ZWQg=
dGhpcyBhcyB3ZWxsLiAgSSBkbyBub3QgdGhpbmsgb3VyCmJlaGF2aW9yIHZpb2xhdGVzIHRoZ=
SBzcGVjLCBidXQgaXQgZG9lcyB2YXJ5IGZyb20gb3RoZXIgcG9wdWxhcgppbXBsZW1lbnRhdG=
lvbnMuCgpJbiBzaG9ydCwgdGhlIGZpcnN0ICcuJyB0ZXJtaW5hdGVzIHRoZSBuYW1lIGluIEd=
DTC4gIFRoaXMgd2FzIGNvbnZlbmllbnQKaW4gb3VyIGltcGxlbWVudGF0aW9uIG9mIHBhdGhu=
YW1lcyB1c2luZyB0aGUgcmVnZXggKGUuZy4gcmVndWxhcgpleHByZXNzaW9uKSBlbmdpbmUgd=
2hpY2ggaGFzIGJlZW4gaW4gR0NMIGZvciBhZ2VzLiAgQXMgdGhlc2UgZm9sbG93IGEKbGVmdC=
B0byByaWdodCBhbGdvcml0aG0gKGxvbmdlc3QgbWF0Y2ggaWYgSSByZWNhbGwpLCBpdCBtYWt=
lcyBzZW5zZSB0bwpkZWZpbmUgYSB0ZXJtaW5hdGluZyBjaGFyYWN0ZXIgc2VxdWVuY2UuCgpJ=
ZiBpbnRlcmVzdGVkIHlvdSBjYW4gcGVydXNlIGxzcC9nY2xfbWFrZV9wYXRobmFtZS5sc3AsI=
HdoZXJlIHlvdSB3aWxsIGZpbmQKCihkZWZjb25zdGFudCArcGh5c2ljYWwtcGF0aG5hbWUtZG=
VmYXVsdHMrICcoKCIiICIiICIiICIiKQoJCQkJCSAgICAoIiIgIiIgIiIgIiIpCgkJCQkJICA=
gICgiIiAiKC8/KFteL10rLykqKSIgIiIgIiIgIiIgIihbXi9dKy8pIiAiLyIgIi8iKQoJCQkJ=
CSAgICAoIiIgIihbXi8uXSopIiAiIiAiLiIpCgkJCQkJICAgICgiLiIgIihcXC5bXi9dKik/I=
iAiIiAiIikKCQkJCQkgICAgKCIiICIiICIiICIiKSkpCgphbmQgYW4gYW5hbG9nIGZvciBsb2=
dpY2FsIHBhdGhuYW1lcyB0aGF0IGdvdmVybiB0aGUgcGFyc2luZy4gIEkgY2FuCmRlc2NyaWJ=
lIHRoZSByb2xlIG9mIGVhY2ggc3RyaW5nIGluIHRoZSBncm91cCBpZiBpbnRlcmVzdGVkLgoK=
SSB3aWxsIHRyeSB0byBsb29rIGF0IHRoZSBhbHJlYWR5IGltcGxlbWVudGVkIHJlZ2V4IGVuZ=
2luZSB0byBzZWUgaWYgYQpuZWdhdGl2ZSBsb29rLWFoZWFkIGNvdWxkIGJlIHN1cHBvcnRlZC=
4KClRha2UgY2FyZSwKCgpNYXR0IEthdWZtYW5uICZsdDttYXR0aGV3Lmoua2F1Zm1hbm5AZ21=
haWwuY29tJmd0OyB3cml0ZXM6Cgo8L3ByZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48cHJl=
IHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUiPkhpIENhbW0sCgpIZXJlJ3MgYSByZXF1Z=
XN0OiBDb3VsZCB5b3UgYXJyYW5nZSB0aGF0IGZvciBhbnkgZmlsZSB3aXRoIGEgbmFtZSBvZi=
B0aGUKZm9ybSAiJmx0O25hbWUmZ3Q7Lmxpc3AiLCB0aGVuIGl0cyBwYXRobmFtZS1uYW1lIGl=
zICImbHQ7bmFtZSZndDsiIGFuZCBpdHMKcGF0aG5hbWUtdHlwZSBpcyAibGlzcCI/ICBUaGlz=
IGlzIG5vdCBhbHdheXMgdGhlIGNhc2UsIGF0IGxlYXN0IGluIG15CnZlcnNpb24gb2YgR0NMI=
DIuNy4xLCB3aGVuICImbHQ7bmFtZSZndDsiIGNvbnRhaW5zIGEgZG90IChpLmUuLCBjaGFyYW=
N0ZXIKI1wuKS4KCkJlbG93IEkgZXhwbGFpbiBmdXJ0aGVyIHdoYXQgSSdtIHNlZWluZyBhbmQ=
gd2h5IHRoaXMgaXMgYSBwcm9ibGVtIGZvcgpBQ0wyLiAgKFByb2JhYmx5IG9uZSBjYW4gaW1h=
Z2luZSBhIHNpbWlsYXIgcHJvYmxlbSBmb3Igb3RoZXIgc3lzdGVtcy4pCgpIZXJlIGlzIGJla=
GF2aW9yIEknbSBzZWVpbmcgaW4gR0NMIDIuNy4xLCB3aGljaCBjYXVzZXMgYSBwcm9ibGVtIG=
ZvcgpBQ0wyIGFzIGV4cGxhaW5lZCBiZWxvdy4KCjwvcHJlPjxibG9ja3F1b3RlIHR5cGU9ImN=
pdGUiPjxwcmUgd3JhcD0iIiBjbGFzcz0ibW96LXF1b3RlLXByZSI+KHBhdGhuYW1lLW5hbWUg=
KHBhdGhuYW1lICJmb28ueHl6Lmxpc3AiKSkKPC9wcmU+PC9ibG9ja3F1b3RlPjxwcmUgd3Jhc=
D0iIiBjbGFzcz0ibW96LXF1b3RlLXByZSI+CiJmb28iCgo8L3ByZT48YmxvY2txdW90ZSB0eX=
BlPSJjaXRlIj48cHJlIHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUiPihwYXRobmFtZS1=
uYW1lICJmb28ueHl6Lmxpc3AiKQo8L3ByZT48L2Jsb2NrcXVvdGU+PHByZSB3cmFwPSIiIGNs=
YXNzPSJtb3otcXVvdGUtcHJlIj4KImZvbyIKCjwvcHJlPjxibG9ja3F1b3RlIHR5cGU9ImNpd=
GUiPjxwcmUgd3JhcD0iIiBjbGFzcz0ibW96LXF1b3RlLXByZSI+KHBhdGhuYW1lLXR5cGUgKH=
BhdGhuYW1lICJmb28ueHl6Lmxpc3AiKSkKPC9wcmU+PC9ibG9ja3F1b3RlPjxwcmUgd3JhcD0=
iIiBjbGFzcz0ibW96LXF1b3RlLXByZSI+CiJ4eXoubGlzcCIKCjwvcHJlPjxibG9ja3F1b3Rl=
IHR5cGU9ImNpdGUiPjxwcmUgd3JhcD0iIiBjbGFzcz0ibW96LXF1b3RlLXByZSI+KHBhdGhuY=
W1lLXR5cGUgImZvby54eXoubGlzcCIpCjwvcHJlPjwvYmxvY2txdW90ZT48cHJlIHdyYXA9Ii=
IgY2xhc3M9Im1vei1xdW90ZS1wcmUiPgoieHl6Lmxpc3AiCgo8L3ByZT48YmxvY2txdW90ZSB=
0eXBlPSJjaXRlIj48cHJlIHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUiPgo8L3ByZT48=
L2Jsb2NrcXVvdGU+PHByZSB3cmFwPSIiIGNsYXNzPSJtb3otcXVvdGUtcHJlIj4KSSdkIHByZ=
WZlciB0byBzZWUgdGhlIGJlaGF2aW9yIHNob3duIGluIHRoZSBmb2xsb3dpbmcgZXhhbXBsZS=
wgaS5lLiwKcmV0dXJuaW5nIGEgcGF0aG5hbWUtdHlwZSBvZiAibGlzcCIuCgo8L3ByZT48Ymx=
vY2txdW90ZSB0eXBlPSJjaXRlIj48cHJlIHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUi=
PihwYXRobmFtZS1uYW1lICJmb28teHl6Lmxpc3AiKQo8L3ByZT48L2Jsb2NrcXVvdGU+PHByZ=
SB3cmFwPSIiIGNsYXNzPSJtb3otcXVvdGUtcHJlIj4KImZvby14eXoiCgo8L3ByZT48YmxvY2=
txdW90ZSB0eXBlPSJjaXRlIj48cHJlIHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUiPih=
wYXRobmFtZS10eXBlICJmb28teHl6Lmxpc3AiKQo8L3ByZT48L2Jsb2NrcXVvdGU+PHByZSB3=
cmFwPSIiIGNsYXNzPSJtb3otcXVvdGUtcHJlIj4KImxpc3AiCgo8L3ByZT48YmxvY2txdW90Z=
SB0eXBlPSJjaXRlIj48cHJlIHdyYXA9IiIgY2xhc3M9Im1vei1xdW90ZS1wcmUiPgo8L3ByZT=
48L2Jsb2NrcXVvdGU+PHByZSB3cmFwPSIiIGNsYXNzPSJtb3otcXVvdGUtcHJlIj4KSSdtIG5=
vdCBzdXJlIHRoaXMgYmVoYXZpb3IgaXMgaW4gZXJyb3IsIGJ5IHRoZSB3YXkgLS0ganVzdCBz=
dXJwcmlzaW5nCih0byBtZSkgYW5kLCBpbiB0aGUgY2FzZSBvZiBBQ0wyLCBpbmNvbnZlbmllb=
nQuICBIZXJlJ3Mgd2hhdCBJIGZvdW5kCmluIHRoZSBDTCBIeXBlclNQZWMuCgpodHRwczovL3=
d3dy5saXNwd29ya3MuY29tL2RvY3VtZW50YXRpb24vSHlwZXJTcGVjL0JvZHkvMTlfYmFlLmh=
0bQoKICAxOS4yLjEuNSBUaGUgUGF0aG5hbWUgVHlwZSBDb21wb25lbnQKCiAgQ29ycmVzcG9u=
ZHMgdG8gdGhlIGBgZmlsZXR5cGUnJyBvciBgYGV4dGVuc2lvbicnIGNvbmNlcHQgaW4gbWFue=
QogIGhvc3QgZmlsZSBzeXN0ZW1zLiBUaGlzIHNheXMgd2hhdCBraW5kIG9mIGZpbGUgdGhpcy=
Bpcy4gVGhpcwogIGNvbXBvbmVudCBpcyBhbHdheXMgYSBzdHJpbmcsIG5pbCwgOndpbGQsIG9=
yIDp1bnNwZWNpZmljLgoKVG8gbWUsIGl0IGlzIG5hdHVyYWwgdG8gdmlldyAiZm9vLnh5ei5s=
aXNwIiBhcyBhIGxpc3AgZmlsZSwgaGVuY2Ugd2l0aApleHRlbnNpb24gImxpc3AiIHRvIHNhe=
SB0aGF0IHRoZSAia2luZCBvZiBmaWxlIiBpcyBhIGxpc3AgZmlsZS4KClRoaXMgZ2V0cyBpbi=
B0aGUgd2F5IGZvciBBQ0wyIGluIHRoZSBjYXNlIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGJvb2t=
zLgoKYm9va3MvcHJvamVjdHMvYWxlby92bS9jaXJjdWl0cy9heGUvYmxha2UyczFyb3VuZC5v=
bGQubGlzcApib29rcy9wcm9qZWN0cy9hbGVvL3ZtL2NpcmN1aXRzL2F4ZS9ibGFrZTJzMXJvd=
W5kLmxpc3AKCldoZW4gd2UgZG8gY2VydGlmaWNhdGlvbnMgaW4gcGFyYWxsZWwgKGkuZS4sIH=
dpdGggLWogZ3JlYXRlciB0aGFuIDEpLApjb21waWxhdGlvbiBjYW4gYmUgYXR0ZW1wdGVkIGl=
uIHBhcmFsbGVsLiAgVGhlIHR3byBib29rcyBhYm92ZSBjYW4KdGh1cyBsZWFkIHRvIHRoZSBm=
b2xsb3dpbmcgY2FsbHMgZG9uZSBieSB0d28gR0NMIHByb2Nlc3NlcyBpbgpwYXJhbGxlbC4KC=
ihDT01QSUxFLUZJTEUKICImbHQ7cGF0aF90b19hY2wyJmd0Oy9ib29rcy9wcm9qZWN0cy9hbG=
VvL3ZtL2NpcmN1aXRzL2F4ZS9ibGFrZTJzMXJvdW5kLm9sZEBleHBhbnNpb24ubHNwIgogOk9=
VVFBVVC1GSUxFCiAiJmx0O3BhdGhfdG9fYWNsMiZndDsvYm9va3MvcHJvamVjdHMvYWxlby92=
bS9jaXJjdWl0cy9heGUvYmxha2UyczFyb3VuZC5vbGQubyIpCgooQ09NUElMRS1GSUxFCiAiJ=
mx0O3BhdGhfdG9fYWNsMiZndDsvYm9va3MvcHJvamVjdHMvYWxlby92bS9jaXJjdWl0cy9heG=
UvYmxha2UyczFyb3VuZC5sc3AiCiA6T1VUUFVULUZJTEUKICImbHQ7cGF0aF90b19hY2wyJmd=
0Oy9ib29rcy9wcm9qZWN0cy9hbGVvL3ZtL2NpcmN1aXRzL2F4ZS9ibGFrZTJzMXJvdW5kLm8i=
KQoKQm90aCBvZiB0aGVzZSBjb21waWxhdGlvbnMgYXR0ZW1wdCB0byBjcmVhdGUgdGhlIHNhb=
WUgZmlsZSwKIiZsdDtwYXRoX3RvX2FjbDImZ3Q7L2Jvb2tzL3Byb2plY3RzL2FsZW8vdm0vY2=
lyY3VpdHMvYXhlL2JsYWtlMnMxcm91bmQuZGF0YSIuCkkgc3VzcGVjdCB0aGF0IGlmIHBhdGh=
uYW1lLW5hbWUgd2VyZSBjaGFuZ2VkIGFzIGRlc2NyaWJlZCBhYm92ZSwgdGhlbgp0aGUgZmly=
c3QgY29tcGlsZS1maWxlIGNhbGwgYWJvdmUgd291bGQgaW5zdGVhZCBjcmVhdGUKIiZsdDtwY=
XRoX3RvX2FjbDImZ3Q7L2Jvb2tzL3Byb2plY3RzL2FsZW8vdm0vY2lyY3VpdHMvYXhlL2JsYW=
tlMnMxcm91bmQub2xkLmRhdGEiLgoKVGhhbmtzLApNYXR0Cgo8L3ByZT48L2Jsb2NrcXVvdGU=
+PHByZSB3cmFwPSIiIGNsYXNzPSJtb3otcXVvdGUtcHJlIj4KLS0gCkNhbW0gTWFndWlyZQkJ=
CSAgICAgCQkgICAgY2FtbUBtYWd1aXJlZmFtaWx5Lm9yZwo9PT09PT09PT09PT09PT09PT09P=
T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ=
oiVGhlIGVhcnRoIGlzIGJ1dCBvbmUgY291bnRyeSwgYW5kIG1hbmtpbmQgaXRzIGNpdGl6ZW5=
zLiIgIC0tICBCYWhhJ3UnbGxhaAoKPC9wcmU+PC9ibG9ja3F1b3RlPjxwcmUgd3JhcD0iIiBj=
bGFzcz0ibW96LXF1b3RlLXByZSI+CjwvcHJlPjwvYmxvY2txdW90ZT48dWwgY2xhc3M9ImRyb=
3Bkb3duLW1lbnUgdGV4dGNvbXBsZXRlLWRyb3Bkb3duIiBzdHlsZT0iZGlzcGxheTogbm9uZT=
sgcG9zaXRpb246IGFic29sdXRlOyB6LWluZGV4OiAxMDAwOyIgY29udGVudGVkaXRhYmxlPSJ=
mYWxzZSIgcG9wb3Zlcj0iYXV0byI+PC91bD4=3D">&#8203;</div>
</body>
</html>
--------------1osiVsy2RvpGHQSbZBc6IsX0--