From wagner at elego.de  Thu Jul  2 17:40:06 2015
From: wagner at elego.de (Olaf Wagner)
Date: Thu, 02 Jul 2015 15:40:06 -0000
Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
 (0x100), expected 0x110
In-Reply-To: <55687266.3090400@marino.st>
References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>
 <55673AA4.8050100@marino.st>
 <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>
 <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>
 <556817A1.2090206@marino.st>
 <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>
 <55682D1A.2030504@marino.st>
 <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>
 <55683689.2090709@marino.st>
 <20150529122732.1396eb079ff9b404bcb21e40@elego.de>
 <5568421D.3050209@marino.st>
 <20150529155833.8454664b88391d93708e8f85@elego.de>
 <55687266.3090400@marino.st>
Message-ID: <20150529170707.ca3550f7aeda21e7853be995@elego.de>

On Fri, 29 May 2015 16:06:30 +0200
John Marino <adacore at marino.st> wrote:

> On 5/29/2015 15:58, Olaf Wagner wrote:
> > On Fri, 29 May 2015 12:40:29 +0200
> > John Marino <adacore at marino.st> wrote:
> > I unpacked your port and tried the first step.
> > But my system seems to be too old:
> > 
> > % make fetch 
> > ===>  modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later.
> > *** Error code 1
> 
> This means at best your machine is FreeBSD 8.x.  The last FreeBSD 8, 8.4
> (a long-term support version) expires in 4 weeks.  So you should update. :)
> 
> 
> > Stop in /src/ports/lang/modula3.
> > 
> > Why would it only run on FreeBSD 9?
> > I actually _have_ a  working cm3 installation on this system ;-)
> 
> The port doesn't consider installed CM3.  It has to do with how ports
> are now built in "clean" jails where nothing is installed.
> 
> You *could* package your working CM3 as a bootstrap compiler [1] but I
> would think your time would be better spent with FreeBSD Update:
> https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
> 
> John
> 
> 
> [1] Just look in work/bootstrap and emulate if you want to do this.

If I understand the makefile correctly, I should use the bootstrap
modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz, but I cannot find that:

% wget --no-check-certificate http://downloads.dragonlace.net/m3/modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz
--2015-05-29 17:04:08--  http://downloads.dragonlace.net/m3/modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz
Resolving downloads.dragonlace.net... 208.69.230.148
Connecting to downloads.dragonlace.net|208.69.230.148|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-05-29 17:04:08 ERROR 404: Not Found.

I can download the other bootstrap file, but that would be for
Dragonfly, not for FreeBSD, correct?
Some stupid mistake?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150702/667cf61e/attachment.sig>

From wagner at elegosoft.com  Thu Jul  2 17:40:07 2015
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 02 Jul 2015 15:40:07 -0000
Subject: [M3devel] Thread tests, was: Re:  the need for cooperative suspend
In-Reply-To: <20150606165023.78AEC1A2066@async.async.caltech.edu>
References: <COL130-W74C829AA2D11E60BB5A735E6D40@phx.gbl>
 <20150502155713.29DCC1A2062@async.async.caltech.edu>
 <B843CEEA-CE8E-4E35-A2EA-ECCC795E3BA2@purdue.edu>
 <20150606165023.78AEC1A2066@async.async.caltech.edu>
Message-ID: <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>

On Sat, 06 Jun 2015 09:50:23 -0700
mika at async.caltech.edu wrote:

> Can the thread tester survive with the most paranoid options on OS X?
> I don't believe it until I've seen it (based on what we went through for
> Linux, I would say I'm just being prudent).
> 
> Run it with:
> 
> "-iters 100000 -n 20 -tests ALL"
> 
> I remember the thread tester died on FreeBSD last time I tried, and
> there have been no relevant checkins since that I know of.
> 
> Here's what happens when I run it on my FreeBSD.  CM3 is not up to date,
> in case someone fixed something I'm not aware of, so don't draw too
> many conclusions until someone has tried it on a fresh install:
> 
> ..........laziest thread is 1433608799/9/1 (tests: read 10/6/6 nxread 26/6/4 tryexcept 67/53/38 fork 1433608799/2/2 forktoomuch 1433608799/9/3 alloc 1433608799/37/1 creat 10/7/7 lock 1433608799/68/38)
> 
> 
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
> ***
> 
> Abort
> (79)pluto:/tmp>
> 
> Anyone who's interested in trying their own favorite Modula-3 installation,
> this is easy to do:
> 
> cm3/m3-libs/m3core/tests/thread/AMD64_FREEBSD/threadtest -iters 100000 -n 20 -tests ALL

For those interested:

I have run the tests with the options above on my FreeBSD 8 system
(yes, I know, that's unsupported now ;-).

time ./AMD64_FREEBSD/threadtest  -iters 100000 -n 20 -tests ALL 2>&1 | egrep -v "appears starved or deadlocked" | tee threadtest.log

It ran several hours during the night; system load was nearly 20.
top -H showed all the threads. The log does not show any runtime error 
(attached).

I also tried this on my Mac with OS/X 10.9.5, but I had to kill it
after an hour because it used up all the resources and I had to work.
Less aggressive tests didn't show any failure there, too.

So I guess the pthreads runtime has indeed improved.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threadtest.log
Type: application/octet-stream
Size: 106496 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150702/b3ed946e/attachment.obj>

From mika at async.caltech.edu  Thu Jul  2 19:35:49 2015
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Thu, 02 Jul 2015 10:35:49 -0700
Subject: [M3devel] Thread tests,
	was: Re:  the need for cooperative suspend
In-Reply-To: <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>
References: <COL130-W74C829AA2D11E60BB5A735E6D40@phx.gbl>
 <20150502155713.29DCC1A2062@async.async.caltech.edu>
 <B843CEEA-CE8E-4E35-A2EA-ECCC795E3BA2@purdue.edu>
 <20150606165023.78AEC1A2066@async.async.caltech.edu>
 <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>
Message-ID: <20150702173549.ADF471A206A@async.async.caltech.edu>


Great news!!!

If anyone finds problems in pthreads on a system where the thread tester
works I would be very interested, first of course because of the bad
news that the system is broken but secondly because I would also want
to enhance the tester so that the bugs don't get by it.

I think if pthreads works well in CM3, that's a big step forward in
the range of applications the system can be used for.

    Mika

Olaf Wagner writes:
>This is a multi-part message in MIME format.
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: 8bit
>
>On Sat, 06 Jun 2015 09:50:23 -0700
>mika at async.caltech.edu wrote:
>
>> Can the thread tester survive with the most paranoid options on OS X?
>> I don't believe it until I've seen it (based on what we went through for
>> Linux, I would say I'm just being prudent).
>> 
>> Run it with:
>> 
>> "-iters 100000 -n 20 -tests ALL"
>> 
>> I remember the thread tester died on FreeBSD last time I tried, and
>> there have been no relevant checkins since that I know of.
>> 
>> Here's what happens when I run it on my FreeBSD.  CM3 is not up to date,
>> in case someone fixed something I'm not aware of, so don't draw too
>> many conclusions until someone has tried it on a fresh install:
>> 
>> ..........laziest thread is 1433608799/9/1 (tests: read 10/6/6 nxread 26/6/4 tryexcept 67/53/38 fork 1433608799/2/2
> forktoomuch 1433608799/9/3 alloc 1433608799/37/1 creat 10/7/7 lock 1433608799/68/38)
>> 
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>> 
>> Abort
>> (79)pluto:/tmp>
>> 
>> Anyone who's interested in trying their own favorite Modula-3 installation,
>> this is easy to do:
>> 
>> cm3/m3-libs/m3core/tests/thread/AMD64_FREEBSD/threadtest -iters 100000 -n 20 -tests ALL
>
>For those interested:
>
>I have run the tests with the options above on my FreeBSD 8 system
>(yes, I know, that's unsupported now ;-).
>
>time ./AMD64_FREEBSD/threadtest  -iters 100000 -n 20 -tests ALL 2>&1 | egrep -v "appears starved or deadlocked" | tee
> threadtest.log
>
>It ran several hours during the night; system load was nearly 20.
>top -H showed all the threads. The log does not show any runtime error 
>(attached).
>
>I also tried this on my Mac with OS/X 10.9.5, but I had to kill it
>after an hour because it used up all the resources and I had to work.
>Less aggressive tests didn't show any failure there, too.
>
>So I guess the pthreads runtime has indeed improved.
>
>Olaf
>-- 
>Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
>               Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany
>phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin
>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn
>Content-Type: application/octet-stream;
> name="threadtest.log"
>Content-Disposition: attachment;
> filename="threadtest.log"
>Content-Transfer-Encoding: base64
>
>V3JpdGluZyBmaWxlLi4uZG9uZQpDcmVhdGluZyByZWFkIHRocmVhZHMuLi5kb25lCkNyZWF0aW5n
>IG54cmVhZCB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyB0cnlleGNlcHQgdGhyZWFkcy4uLmRvbmUK
>Q3JlYXRpbmcgZm9yayB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyBmb3JrdG9vbXVjaCB0aHJlYWRz
>Li4uZG9uZQpDcmVhdGluZyBhbGxvYyB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyBjcmVhdCB0aHJl
>YWRzLi4uZG9uZQpDcmVhdGluZyBsb2NrIHRocmVhZHMuLi5kb25lCnJ1bm5pbmcuLi5wcmludGlu
>ZyBvbGRlc3QvbWVkaWFuIGFnZS9uZXdlc3QKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTAyMTQvMTQzMzcxMDIxNC8wICh0ZXN0czogcmVhZCAxNDMzNzEwMjE0LzE0MzM3MTAyMTQv
>MTQzMzcxMDIxNCBueHJlYWQgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgdHJ5ZXhj
>ZXB0IDEvMC8wIGZvcmsgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgZm9ya3Rvb211
>Y2ggMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgYWxsb2MgMTQzMzcxMDIxNC8xNDMz
>NzEwMjE0LzE0MzM3MTAyMTQgY3JlYXQgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQg
>bG9jayAxNDMzNzEwMjE0LzE0MzM3MTAyMTQvMTQzMzcxMDIxNCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEwMjg2
>LzE0MzM3MTAyODYvMTYgbnhyZWFkIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IHRy
>eWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGZvcmt0
>b29tdWNoIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGFsbG9jIDE0MzM3MTAyODYv
>Ny8xIGNyZWF0IDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGxvY2sgMTQzMzcxMDI4
>Ni8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwMzEyLzE0MzM3MTAzMTIv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMDMxMi8xNDMzNzEwMzEyLzEzIG54cmVhZCAxNDMzNzEwMzEy
>LzE0MzM3MTAzMTIvMTQzMzcxMDMxMiB0cnlleGNlcHQgMTMvMS8xIGZvcmsgMTQzMzcxMDMxMi8x
>NDMzNzEwMzEyLzE0MzM3MTAzMTIgZm9ya3Rvb211Y2ggMTQzMzcxMDMxMi8xNDMzNzEwMzEyLzE0
>MzM3MTAzMTIgYWxsb2MgMzMvMTIvNSBjcmVhdCAxNDMzNzEwMzEyLzE0MzM3MTAzMTIvMTQzMzcx
>MDMxMiBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMDM1Ny8x
>NDMzNzEwMzU3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTAzNTcvMTQzMzcxMDM1Ny8xIG54cmVhZCAx
>NDMzNzEwMzU3LzE0MzM3MTAzNTcvMTQzMzcxMDM1NyB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMz
>NzEwMzU3LzE0MzM3MTAzNTcvMTQzMzcxMDM1NyBmb3JrdG9vbXVjaCAxNDMzNzEwMzU3LzE0MzM3
>MTAzNTcvMTQzMzcxMDM1NyBhbGxvYyA1Ny8xOS8xIGNyZWF0IDE0MzM3MTAzNTcvMTQzMzcxMDM1
>Ny8xNDMzNzEwMzU3IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzEwMzgwLzE0MzM3MTAzODAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMDM4MC8xNDMzNzEwMzgwLzEg
>bnhyZWFkIDE0MzM3MTAzODAvMTQzMzcxMDM4MC8xNDMzNzEwMzgwIHRyeWV4Y2VwdCAyNi84LzAg
>Zm9yayAxNDMzNzEwMzgwLzE0MzM3MTAzODAvMTQzMzcxMDM4MCBmb3JrdG9vbXVjaCAxNDMzNzEw
>MzgwLzE0MzM3MTAzODAvMTQzMzcxMDM4MCBhbGxvYyA4MC85LzEgY3JlYXQgMTQzMzcxMDM4MC8x
>NDMzNzEwMzgwLzE0MzM3MTAzODAgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MTA0MTQvMTQzMzcxMDQxNC8wICh0ZXN0czogcmVhZCAxNDMzNzEwNDE0LzE0MzM3
>MTA0MTQvMjEgbnhyZWFkIDE0MzM3MTA0MTQvMTQzMzcxMDQxNC8xNDMzNzEwNDE0IHRyeWV4Y2Vw
>dCAxNi8yLzEgZm9yayAxNDMzNzEwNDE0LzE0MzM3MTA0MTQvMTQzMzcxMDQxNCBmb3JrdG9vbXVj
>aCAxNDMzNzEwNDE0LzE0MzM3MTA0MTQvMTQzMzcxMDQxNCBhbGxvYyAzOC80LzQgY3JlYXQgMTQz
>MzcxMDQxNC8xNDMzNzEwNDE0LzE0MzM3MTA0MTQgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEw
>NDQyLzE0MzM3MTA0NDIvMjIgbnhyZWFkIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQy
>IHRyeWV4Y2VwdCA1LzIvMSBmb3JrIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyIGZv
>cmt0b29tdWNoIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyIGFsbG9jIDMyLzE1LzYg
>Y3JlYXQgMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyLzE0MzM3MTA0NDIgbG9jayA2LzYvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA0NzkvMTQzMzcxMDQ3OS8wICh0ZXN0czogcmVh
>ZCAxNDMzNzEwNDc5LzE0MzM3MTA0NzkvNSBueHJlYWQgMTQzMzcxMDQ3OS8xNDMzNzEwNDc5LzE5
>IHRyeWV4Y2VwdCA1LzIvMSBmb3JrIDE0MzM3MTA0NzkvMTQzMzcxMDQ3OS8xOCBmb3JrdG9vbXVj
>aCAxNDMzNzEwNDc5LzE0MzM3MTA0NzkvMTQzMzcxMDQ3OSBhbGxvYyAzNy84LzUgY3JlYXQgMTQz
>MzcxMDQ3OS8xNDMzNzEwNDc5LzE0MzM3MTA0NzkgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTA1MDQvMTQzMzcxMDUwNC8wICh0ZXN0czogcmVhZCAxNDMzNzEw
>NTA0LzE0MzM3MTA1MDQvMzAgbnhyZWFkIDE0MzM3MTA1MDQvMTQzMzcxMDUwNC80NCB0cnlleGNl
>cHQgNC8xLzAgZm9yayAxNDMzNzEwNTA0LzE0MzM3MTA1MDQvNDMgZm9ya3Rvb211Y2ggMTQzMzcx
>MDUwNC8xNDMzNzEwNTA0LzE0MzM3MTA1MDQgYWxsb2MgNTcvOC8yIGNyZWF0IDE0MzM3MTA1MDQv
>MTQzMzcxMDUwNC8xNDMzNzEwNTA0IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzEwNTQ1LzE0MzM3MTA1NDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMDU0NS8xNDMz
>NzEwNTQ1LzcxIG54cmVhZCAxNDMzNzEwNTQ1LzE0MzM3MTA1NDUvODUgdHJ5ZXhjZXB0IDQvMC8w
>IGZvcmsgMTQzMzcxMDU0NS8xNDMzNzEwNTQ1Lzg0IGZvcmt0b29tdWNoIDE0MzM3MTA1NDUvMTQz
>MzcxMDU0NS8xNDMzNzEwNTQ1IGFsbG9jIDQ5LzgvMyBjcmVhdCAxNDMzNzEwNTQ1LzE0MzM3MTA1
>NDUvMTQzMzcxMDU0NSBsb2NrIDIvMi8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMDU3Mi8xNDMzNzEwNTcyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA1NzIvMTQzMzcxMDU3Mi85
>OCBueHJlYWQgMTQzMzcxMDU3Mi8xNDMzNzEwNTcyLzExMiB0cnlleGNlcHQgOC8zLzAgZm9yayAx
>NDMzNzEwNTcyLzE0MzM3MTA1NzIvMTExIGZvcmt0b29tdWNoIDE0MzM3MTA1NzIvMTQzMzcxMDU3
>Mi8xNDMzNzEwNTcyIGFsbG9jIDQxLzE1LzEgY3JlYXQgMTQzMzcxMDU3Mi8xNDMzNzEwNTcyLzE0
>MzM3MTA1NzIgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA1
>OTkvMTQzMzcxMDU5OS8wICh0ZXN0czogcmVhZCAxNDMzNzEwNTk5LzE0MzM3MTA1OTkvMTMgbnhy
>ZWFkIDE0MzM3MTA1OTkvMTQzMzcxMDU5OS8xMzkgdHJ5ZXhjZXB0IDM1LzEvMSBmb3JrIDE0MzM3
>MTA1OTkvMTQzMzcxMDU5OS8xMzggZm9ya3Rvb211Y2ggMTQzMzcxMDU5OS8xNDMzNzEwNTk5LzE0
>MzM3MTA1OTkgYWxsb2MgNTIvMTMvNCBjcmVhdCAxNDMzNzEwNTk5LzE0MzM3MTA1OTkvMTQzMzcx
>MDU5OSBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMDYzMC8x
>NDMzNzEwNjMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA2MzAvMTQzMzcxMDYzMC8xMiBueHJlYWQg
>MTQzMzcxMDYzMC8xNDMzNzEwNjMwLzE3MCB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzEwNjMw
>LzE0MzM3MTA2MzAvMTY5IGZvcmt0b29tdWNoIDE0MzM3MTA2MzAvMTQzMzcxMDYzMC8xNDMzNzEw
>NjMwIGFsbG9jIDMxLzEyLzUgY3JlYXQgMTQzMzcxMDYzMC8xNDMzNzEwNjMwLzE0MzM3MTA2MzAg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA2NTkvMTQzMzcx
>MDY1OS8wICh0ZXN0czogcmVhZCAxNDMzNzEwNjU5LzE0MzM3MTA2NTkvNiBueHJlYWQgMTQzMzcx
>MDY1OS8xNDMzNzEwNjU5LzE5OSB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzEwNjU5LzE0MzM3
>MTA2NTkvNiBmb3JrdG9vbXVjaCAxNDMzNzEwNjU5LzE0MzM3MTA2NTkvMTQzMzcxMDY1OSBhbGxv
>YyAzNC8xMS82IGNyZWF0IDE0MzM3MTA2NTkvMTQzMzcxMDY1OS8xNDMzNzEwNjU5IGxvY2sgNC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwNjc4LzIxNy8wICh0ZXN0czog
>cmVhZCAxNDMzNzEwNjc4LzE0MzM3MTA2NzgvMjUgbnhyZWFkIDE0MzM3MTA2NzgvMTQzMzcxMDY3
>OC8yMTggdHJ5ZXhjZXB0IDE1LzMvMCBmb3JrIDE0MzM3MTA2NzgvMTQzMzcxMDY3OC8yNSBmb3Jr
>dG9vbXVjaCAxNDMzNzEwNjc4LzE0MzM3MTA2NzgvMTQzMzcxMDY3OCBhbGxvYyAzMC81LzEgY3Jl
>YXQgMTQzMzcxMDY3OC8xLzEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTA3MjIvMjYxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA3MjIvMTQzMzcxMDcyMi81IG54
>cmVhZCAxNDMzNzEwNzIyLzE0MzM3MTA3MjIvMjYyIHRyeWV4Y2VwdCAxOS8yLzAgZm9yayAxNDMz
>NzEwNzIyLzE0MzM3MTA3MjIvMTcgZm9ya3Rvb211Y2ggMTQzMzcxMDcyMi8xNDMzNzEwNzIyLzE0
>MzM3MTA3MjIgYWxsb2MgNDkvMS8xIGNyZWF0IDE0MzM3MTA3MjIvNDUvNDUgbG9jayAxLzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA3NjcvMzA2LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MTA3NjcvMTQzMzcxMDc2Ny81MCBueHJlYWQgMTQzMzcxMDc2Ny8xNDMzNzEwNzY3LzMw
>NyB0cnlleGNlcHQgMTUvMi8xIGZvcmsgMTQzMzcxMDc2Ny8xNDMzNzEwNzY3LzYyIGZvcmt0b29t
>dWNoIDE0MzM3MTA3NjcvMTQzMzcxMDc2Ny8xNDMzNzEwNzY3IGFsbG9jIDU2LzgvMyBjcmVhdCAx
>NDMzNzEwNzY3LzkwLzkwIGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEwNzk5LzE0Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEwNzk5LzE0MzM3MTA3OTkvMTUgbnhy
>ZWFkIDE0MzM3MTA3OTkvMTQzMzcxMDc5OS8zMzkgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQzMzcx
>MDc5OS8xNDMzNzEwNzk5LzE5IGZvcmt0b29tdWNoIDE0MzM3MTA3OTkvMTQzMzcxMDc5OS8xNDMz
>NzEwNzk5IGFsbG9jIDEwLzYvNiBjcmVhdCAxNDMzNzEwNzk5LzEyMi8xMjIgbG9jayAwLzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA4MjEvMTY4LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MTA4MjEvMTQzMzcxMDgyMS8zNyBueHJlYWQgMTQzMzcxMDgyMS8xNDMzNzEwODIxLzM2
>MSB0cnlleGNlcHQgMTYvMi8xIGZvcmsgMTQzMzcxMDgyMS8xNDMzNzEwODIxLzQxIGZvcmt0b29t
>dWNoIDE0MzM3MTA4MjEvMTQzMzcxMDgyMS8xNDMzNzEwODIxIGFsbG9jIDMyLzE0LzAgY3JlYXQg
>MTQzMzcxMDgyMS8xNDQvMTQ0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzEwODU5LzIwNi8wICh0ZXN0czogcmVhZCAxNDMzNzEwODU5LzE0MzM3MTA4NTkvMjgg
>bnhyZWFkIDE0MzM3MTA4NTkvMTQzMzcxMDg1OS8zOTkgdHJ5ZXhjZXB0IDM2LzMvMCBmb3JrIDE0
>MzM3MTA4NTkvMTQzMzcxMDg1OS83OSBmb3JrdG9vbXVjaCAxNDMzNzEwODU5LzE0MzM3MTA4NTkv
>MTQzMzcxMDg1OSBhbGxvYyA1Mi84LzIgY3JlYXQgMTQzMzcxMDg1OS8xODIvMTgyIGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwODg0LzIzMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEwODg0LzE0MzM3MTA4ODQvMjIgbnhyZWFkIDE0MzM3MTA4ODQvMTQzMzcxMDg4
>NC80MjQgdHJ5ZXhjZXB0IDQ0LzIvMCBmb3JrIDE0MzM3MTA4ODQvMTQzMzcxMDg4NC8xMDQgZm9y
>a3Rvb211Y2ggMTQzMzcxMDg4NC8xNDMzNzEwODg0LzE0MzM3MTA4ODQgYWxsb2MgNzcvMTcvMSBj
>cmVhdCAxNDMzNzEwODg0LzIwNy8yMDcgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTA5MDcvMjU0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTA5MDcvMTQzMzcxMDkw
>Ny8xOSBueHJlYWQgMTQzMzcxMDkwNy8xNDMzNzEwOTA3LzQ0NyB0cnlleGNlcHQgNjcvMS8wIGZv
>cmsgMTQzMzcxMDkwNy8xNDMzNzEwOTA3LzEyNyBmb3JrdG9vbXVjaCAxNDMzNzEwOTA3LzE0MzM3
>MTA5MDcvMTQzMzcxMDkwNyBhbGxvYyAxMDAvMjQvMiBjcmVhdCAxNDMzNzEwOTA3LzIzMC8yMzAg
>bG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA5NzYvMjk5LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTA5NzYvMTQzMzcxMDk3Ni85IG54cmVhZCAxNDMzNzEwOTc2LzE0
>MzM3MTA5NzYvNTE2IHRyeWV4Y2VwdCA0My8yLzEgZm9yayAxNDMzNzEwOTc2LzE0MzM3MTA5NzYv
>MTk2IGZvcmt0b29tdWNoIDE0MzM3MTA5NzYvMTQzMzcxMDk3Ni8xNDMzNzEwOTc2IGFsbG9jIDgz
>LzQvMCBjcmVhdCAyOTkvMjk5LzI3IGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzEwOTk5LzMyMi8wICh0ZXN0czogcmVhZCAxNDMzNzEwOTk5LzE0MzM3MTA5OTkv
>MiBueHJlYWQgMTQzMzcxMDk5OS8xNDMzNzEwOTk5LzUzOSB0cnlleGNlcHQgMy8wLzAgZm9yayAx
>NDMzNzEwOTk5LzE0MzM3MTA5OTkvMTIgZm9ya3Rvb211Y2ggMTQzMzcxMDk5OS8xNDMzNzEwOTk5
>LzE0MzM3MTA5OTkgYWxsb2MgMjcvNy8yIGNyZWF0IDMyMi8zMjIvNTAgbG9jayAxLzEvMSkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTEwNDQvMzY3LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTEwNDQvMTQzMzcxMTA0NC8xIG54cmVhZCAxNDMzNzExMDQ0LzE0MzM3MTEwNDQvNTg0IHRy
>eWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTEwNDQvMTQzMzcxMTA0NC81NyBmb3JrdG9vbXVjaCAx
>NDMzNzExMDQ0LzE0MzM3MTEwNDQvMTQzMzcxMTA0NCBhbGxvYyA1OC83LzEgY3JlYXQgMzY3LzM2
>Ny85NSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTA3OS80
>MDIvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTA3OS8xNDMzNzExMDc5LzIyIG54cmVhZCAxNDMzNzEx
>MDc5LzE0MzM3MTEwNzkvNjE5IHRyeWV4Y2VwdCA5LzIvMiBmb3JrIDE0MzM3MTEwNzkvMTQzMzcx
>MTA3OS85MiBmb3JrdG9vbXVjaCAxNDMzNzExMDc5LzE0MzM3MTEwNzkvMTQzMzcxMTA3OSBhbGxv
>YyAzMS8xMC84IGNyZWF0IDQwMi80MDIvMTMwIGxvY2sgNy82LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzExMTEzLzQzNi8wICh0ZXN0czogcmVhZCAxNDMzNzExMTEzLzE0MzM3
>MTExMTMvMjUgbnhyZWFkIDE0MzM3MTExMTMvMTQzMzcxMTExMy82NTMgdHJ5ZXhjZXB0IDQvMy8w
>IGZvcmsgMTQzMzcxMTExMy8xNDMzNzExMTEzLzEyNiBmb3JrdG9vbXVjaCAxNDMzNzExMTEzLzE0
>MzM3MTExMTMvMTQzMzcxMTExMyBhbGxvYyA0NC8xMS8xIGNyZWF0IDQzNi80MzYvMTY0IGxvY2sg
>MS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExMTUzLzQyLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTExNTMvMTQzMzcxMTE1My8xMCBueHJlYWQgMTQzMzcxMTE1My8xNDMzNzEx
>MTUzLzY5MyB0cnlleGNlcHQgNDIvMi8xIGZvcmsgMTQzMzcxMTE1My8xNDMzNzExMTUzLzE2NiBm
>b3JrdG9vbXVjaCAxNDMzNzExMTUzLzE0MzM3MTExNTMvMTQzMzcxMTE1MyBhbGxvYyA1MS8xOC80
>IGNyZWF0IDIwNC8xMC8xMCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxMTE4Ny80NC8wICh0ZXN0czogcmVhZCAxNDMzNzExMTg3LzE0MzM3MTExODcvMTYgbnhy
>ZWFkIDE0MzM3MTExODcvMTQzMzcxMTE4Ny83MjcgdHJ5ZXhjZXB0IDE3LzAvMCBmb3JrIDE0MzM3
>MTExODcvMTQzMzcxMTE4Ny8yMDAgZm9ya3Rvb211Y2ggMTQzMzcxMTE4Ny8xNDMzNzExMTg3LzE0
>MzM3MTExODcgYWxsb2MgMzQvNS8zIGNyZWF0IDIzOC80NC80NCBsb2NrIDEvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTIyOS84Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEx
>MjI5LzE0MzM3MTEyMjkvNTggbnhyZWFkIDE0MzM3MTEyMjkvMTQzMzcxMTIyOS83NjkgdHJ5ZXhj
>ZXB0IDUvMi8xIGZvcmsgMTQzMzcxMTIyOS8xNDMzNzExMjI5LzI0MiBmb3JrdG9vbXVjaCAxNDMz
>NzExMjI5LzE0MzM3MTEyMjkvMTQzMzcxMTIyOSBhbGxvYyAyMS8xMS81IGNyZWF0IDI4MC84Ni84
>NiBsb2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTI1NS8xMTIv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMTI1NS8xNDMzNzExMjU1LzIxIG54cmVhZCAxNDMzNzExMjU1
>LzE0MzM3MTEyNTUvNzk1IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTEyNTUvMTQzMzcxMTI1
>NS8yMCBmb3JrdG9vbXVjaCAxNDMzNzExMjU1LzE0MzM3MTEyNTUvMTQzMzcxMTI1NSBhbGxvYyAz
>MS81LzEgY3JlYXQgMzA2LzExMi8xMTIgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTEyODEvMTM4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTEyODEvMTQzMzcxMTI4
>MS80NyBueHJlYWQgMTQzMzcxMTI4MS8xNDMzNzExMjgxLzgyMSB0cnlleGNlcHQgMTcvMy8xIGZv
>cmsgMTQzMzcxMTI4MS8xNDMzNzExMjgxLzQ2IGZvcmt0b29tdWNoIDE0MzM3MTEyODEvMTQzMzcx
>MTI4MS8xNDMzNzExMjgxIGFsbG9jIDMxLzcvMyBjcmVhdCAzMzIvMTM4LzEzOCBsb2NrIDMvMy8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTMxMC8xNjcvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMTMxMC8xNDMzNzExMzEwLzE2IG54cmVhZCAxNDMzNzExMzEwLzE0MzM3MTEzMTAv
>ODUwIHRyeWV4Y2VwdCAxMS8yLzEgZm9yayAxNDMzNzExMzEwLzE0MzM3MTEzMTAvNzUgZm9ya3Rv
>b211Y2ggMTQzMzcxMTMxMC8xNDMzNzExMzEwLzE0MzM3MTEzMTAgYWxsb2MgMzkvMTAvMyBjcmVh
>dCAzNjEvMTY3LzE2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMTM0MS8xOTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTM0MS8xNDMzNzExMzQxLzI2IG54cmVh
>ZCAxNDMzNzExMzQxLzE0MzM3MTEzNDEvODgxIHRyeWV4Y2VwdCAxNS8yLzIgZm9yayAxNDMzNzEx
>MzQxLzE0MzM3MTEzNDEvMTA2IGZvcmt0b29tdWNoIDE0MzM3MTEzNDEvMTQzMzcxMTM0MS8xNDMz
>NzExMzQxIGFsbG9jIDQxLzE0LzYgY3JlYXQgMzkyLzE5OC8xOTggbG9jayA1LzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTEzNjgvMjI1LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTEzNjgvMTQzMzcxMTM2OC81MyBueHJlYWQgMTQzMzcxMTM2OC8xNDMzNzExMzY4LzkwOCB0cnll
>eGNlcHQgNC8zLzAgZm9yayAxNDMzNzExMzY4LzE0MzM3MTEzNjgvMTMzIGZvcmt0b29tdWNoIDE0
>MzM3MTEzNjgvMTQzMzcxMTM2OC8xNDMzNzExMzY4IGFsbG9jIDQ3LzcvMSBjcmVhdCA0MTkvMjI1
>LzIyNSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTM5My8y
>NTAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTM5My8xNDMzNzExMzkzLzE0IG54cmVhZCAxNDMzNzEx
>MzkzLzE0MzM3MTEzOTMvOTMzIHRyeWV4Y2VwdCA4LzEvMSBmb3JrIDE0MzM3MTEzOTMvMTQzMzcx
>MTM5My8xNTggZm9ya3Rvb211Y2ggMTQzMzcxMTM5My8xNDMzNzExMzkzLzE0MzM3MTEzOTMgYWxs
>b2MgMzIvMTQvNyBjcmVhdCA0NDQvMjUwLzI1MCBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTQyMC8yNzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTQyMC8xNDMz
>NzExNDIwLzYgbnhyZWFkIDE0MzM3MTE0MjAvMTQzMzcxMTQyMC85NjAgdHJ5ZXhjZXB0IDUvMi8x
>IGZvcmsgMTQzMzcxMTQyMC8xNDMzNzExNDIwLzE4NSBmb3JrdG9vbXVjaCAxNDMzNzExNDIwLzE0
>MzM3MTE0MjAvMTQzMzcxMTQyMCBhbGxvYyAyNy8xNy82IGNyZWF0IDQ3MS8yNzcvMjc3IGxvY2sg
>Ni82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNDQ3LzMwNC8wICh0ZXN0
>czogcmVhZCAxNDMzNzExNDQ3LzE0MzM3MTE0NDcvMjAgbnhyZWFkIDE0MzM3MTE0NDcvMTQzMzcx
>MTQ0Ny85ODcgdHJ5ZXhjZXB0IDgvMi8yIGZvcmsgMTQzMzcxMTQ0Ny8xNDMzNzExNDQ3LzE5IGZv
>cmt0b29tdWNoIDE0MzM3MTE0NDcvMTQzMzcxMTQ0Ny8xNDMzNzExNDQ3IGFsbG9jIDQ0LzExLzcg
>Y3JlYXQgNDk4LzMwNC8zMDQgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTE0NzIvMzI5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTE0NzIvMTQzMzcxMTQ3Mi82IG54
>cmVhZCAxNDMzNzExNDcyLzE0MzM3MTE0NzIvMTAxMiB0cnlleGNlcHQgNS8yLzIgZm9yayAxNDMz
>NzExNDcyLzE0MzM3MTE0NzIvNDQgZm9ya3Rvb211Y2ggMTQzMzcxMTQ3Mi8xNDMzNzExNDcyLzE0
>MzM3MTE0NzIgYWxsb2MgNDEvMTEvMCBjcmVhdCA1MjMvMzI5LzMyOSBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTUwMi8zNTkvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMTUwMi8xNDMzNzExNTAyLzIgbnhyZWFkIDE0MzM3MTE1MDIvMTQzMzcxMTUwMi8xMDQyIHRy
>eWV4Y2VwdCAyNC8xLzAgZm9yayAxNDMzNzExNTAyLzE0MzM3MTE1MDIvNzQgZm9ya3Rvb211Y2gg
>MTQzMzcxMTUwMi8xNDMzNzExNTAyLzE0MzM3MTE1MDIgYWxsb2MgNzEvNS8yIGNyZWF0IDU1My8z
>NTkvMzU5IGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNTI3
>LzM4NC8wICh0ZXN0czogcmVhZCAxNDMzNzExNTI3LzE0MzM3MTE1MjcvOCBueHJlYWQgMTQzMzcx
>MTUyNy8xNDMzNzExNTI3LzEwNjcgdHJ5ZXhjZXB0IDE4LzIvMCBmb3JrIDE0MzM3MTE1MjcvMTQz
>MzcxMTUyNy83IGZvcmt0b29tdWNoIDE0MzM3MTE1MjcvMTQzMzcxMTUyNy8xNDMzNzExNTI3IGFs
>bG9jIDM1LzgvMSBjcmVhdCA1NzgvMzg0LzM4NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTU1OC80MTUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTU1OC8xNDMz
>NzExNTU4LzcgbnhyZWFkIDE0MzM3MTE1NTgvMTQzMzcxMTU1OC8xMDk4IHRyeWV4Y2VwdCAyNS8y
>LzIgZm9yayAxNDMzNzExNTU4LzE0MzM3MTE1NTgvNyBmb3JrdG9vbXVjaCAxNDMzNzExNTU4LzE0
>MzM3MTE1NTgvMTQzMzcxMTU1OCBhbGxvYyAzOS8xMS83IGNyZWF0IDYwOS80MTUvNDE1IGxvY2sg
>Ny83LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNTgxLzQzOC8wICh0ZXN0
>czogcmVhZCAxNDMzNzExNTgxLzE0MzM3MTE1ODEvMzAgbnhyZWFkIDE0MzM3MTE1ODEvMTQzMzcx
>MTU4MS8xMTIxIHRyeWV4Y2VwdCA0LzMvMCBmb3JrIDE0MzM3MTE1ODEvMTQzMzcxMTU4MS8zMCBm
>b3JrdG9vbXVjaCAxNDMzNzExNTgxLzE0MzM3MTE1ODEvMTQzMzcxMTU4MSBhbGxvYyAzNC8xLzEg
>Y3JlYXQgNjMyLzQzOC80MzggbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTE2MDUvNDYyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE2MDUvMTQzMzcxMTYwNS8yIG54
>cmVhZCAxNDMzNzExNjA1LzE0MzM3MTE2MDUvMTE0NSB0cnlleGNlcHQgNC8wLzAgZm9yayAxNDMz
>NzExNjA1LzE0MzM3MTE2MDUvMiBmb3JrdG9vbXVjaCAxNDMzNzExNjA1LzE0MzM3MTE2MDUvMTQz
>MzcxMTYwNSBhbGxvYyAzMS8yLzIgY3JlYXQgNjU2LzQ2Mi80NjIgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTE2NDAvNDk3LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTE2NDAvMTQzMzcxMTY0MC81IG54cmVhZCAxNDMzNzExNjQwLzE0MzM3MTE2NDAvMTE4MCB0cnll
>eGNlcHQgNC8xLzEgZm9yayAxNDMzNzExNjQwLzE0MzM3MTE2NDAvMzcgZm9ya3Rvb211Y2ggMTQz
>MzcxMTY0MC8xNDMzNzExNjQwLzE0MzM3MTE2NDAgYWxsb2MgNDMvMTEvNSBjcmVhdCA2OTEvNDk3
>LzQ5NyBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTY3Mi81
>MjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTY3Mi8xNDMzNzExNjcyLzE2IG54cmVhZCAxNDMzNzEx
>NjcyLzE0MzM3MTE2NzIvMTIxMiB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzExNjcyLzE0MzM3
>MTE2NzIvNjkgZm9ya3Rvb211Y2ggMTQzMzcxMTY3Mi8xNDMzNzExNjcyLzE0MzM3MTE2NzIgYWxs
>b2MgMjIvMTEvMCBjcmVhdCA3MjMvNTI5LzUyOSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTcxMy81NzAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTcxMy8xNDMz
>NzExNzEzLzIwIG54cmVhZCAxNDMzNzExNzEzLzE0MzM3MTE3MTMvMTI1MyB0cnlleGNlcHQgNC8y
>LzEgZm9yayAxNDMzNzExNzEzLzE0MzM3MTE3MTMvMTEwIGZvcmt0b29tdWNoIDE0MzM3MTE3MTMv
>MTQzMzcxMTcxMy8xNDMzNzExNzEzIGFsbG9jIDUyLzUvNSBjcmVhdCA3NjQvNTcwLzU3MCBsb2Nr
>IDUvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTc0Ni82MDMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxMTc0Ni8xNDMzNzExNzQ2LzUzIG54cmVhZCAxNDMzNzExNzQ2LzE0MzM3
>MTE3NDYvMTI4NiB0cnlleGNlcHQgMjAvMi8xIGZvcmsgMTQzMzcxMTc0Ni8xNDMzNzExNzQ2LzE0
>MyBmb3JrdG9vbXVjaCAxNDMzNzExNzQ2LzE0MzM3MTE3NDYvMTQzMzcxMTc0NiBhbGxvYyAzMy81
>LzIgY3JlYXQgNzk3LzYwMy82MDMgbG9jayAyLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MTE3NzMvNjMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE3NzMvMTQzMzcxMTc3My8x
>OCBueHJlYWQgMTQzMzcxMTc3My8xNDMzNzExNzczLzEzMTMgdHJ5ZXhjZXB0IDI4LzAvMCBmb3Jr
>IDE0MzM3MTE3NzMvMTQzMzcxMTc3My8xNzAgZm9ya3Rvb211Y2ggMTQzMzcxMTc3My8xNDMzNzEx
>NzczLzE0MzM3MTE3NzMgYWxsb2MgMzIvMTgvMiBjcmVhdCA4MjQvNjMwLzYzMCBsb2NrIDIvMi8x
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTc5Ny82NTQvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMTc5Ny8xNDMzNzExNzk3LzggbnhyZWFkIDE0MzM3MTE3OTcvMTQzMzcxMTc5Ny8x
>MzM3IHRyeWV4Y2VwdCA0MC8yLzEgZm9yayAxNDMzNzExNzk3LzE0MzM3MTE3OTcvMTk0IGZvcmt0
>b29tdWNoIDE0MzM3MTE3OTcvMTQzMzcxMTc5Ny8xNDMzNzExNzk3IGFsbG9jIDQ2LzE3LzMgY3Jl
>YXQgODQ4LzY1NC82NTQgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTE4MzQvNjkxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE4MzQvMTQzMzcxMTgzNC8xMiBueHJl
>YWQgMTQzMzcxMTgzNC8xNDMzNzExODM0LzEzNzQgdHJ5ZXhjZXB0IDMxLzIvMCBmb3JrIDE0MzM3
>MTE4MzQvMTQzMzcxMTgzNC8yMzEgZm9ya3Rvb211Y2ggMTQzMzcxMTgzNC8xNDMzNzExODM0LzE0
>MzM3MTE4MzQgYWxsb2MgNDAvNC8wIGNyZWF0IDg4NS82OTEvNjkxIGxvY2sgMS8xLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExODg4Lzc0NS8wICh0ZXN0czogcmVhZCAxNDMz
>NzExODg4LzE0MzM3MTE4ODgvMjYgbnhyZWFkIDE0MzM3MTE4ODgvMTQzMzcxMTg4OC8xNDI4IHRy
>eWV4Y2VwdCA5LzIvMSBmb3JrIDE0MzM3MTE4ODgvMTQzMzcxMTg4OC8yODUgZm9ya3Rvb211Y2gg
>MTQzMzcxMTg4OC8xNDMzNzExODg4LzE0MzM3MTE4ODggYWxsb2MgMjYvMTIvNyBjcmVhdCA5Mzkv
>NzQ1Lzc0NSBsb2NrIDcvNy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTky
>My82MS8wICh0ZXN0czogcmVhZCAxNDMzNzExOTIzLzE0MzM3MTE5MjMvNjEgbnhyZWFkIDE0MzM3
>MTE5MjMvMTQzMzcxMTkyMy8xNDYzIHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzExOTIzLzE0
>MzM3MTE5MjMvMzIwIGZvcmt0b29tdWNoIDE0MzM3MTE5MjMvMTQzMzcxMTkyMy8xNDMzNzExOTIz
>IGFsbG9jIDI1LzcvMCBjcmVhdCAyOC8yOC8yOCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTk1NS82MC8wICh0ZXN0czogcmVhZCAxNDMzNzExOTU1LzE0MzM3
>MTE5NTUvOCBueHJlYWQgMTQzMzcxMTk1NS8xNDMzNzExOTU1LzE0OTUgdHJ5ZXhjZXB0IDIzLzMv
>MSBmb3JrIDE0MzM3MTE5NTUvMTQzMzcxMTk1NS8zNTIgZm9ya3Rvb211Y2ggMTQzMzcxMTk1NS8x
>NDMzNzExOTU1LzE0MzM3MTE5NTUgYWxsb2MgMzIvOC8zIGNyZWF0IDYwLzYwLzYwIGxvY2sgMy8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExOTk2LzEwMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzExOTk2LzE0MzM3MTE5OTYvMSBueHJlYWQgMTQzMzcxMTk5Ni8xNDMzNzExOTk2
>LzE1MzYgdHJ5ZXhjZXB0IDYyLzIvMCBmb3JrIDE0MzM3MTE5OTYvMTQzMzcxMTk5Ni8zOTMgZm9y
>a3Rvb211Y2ggMTQzMzcxMTk5Ni8xNDMzNzExOTk2LzE0MzM3MTE5OTYgYWxsb2MgNDEvNC8xIGNy
>ZWF0IDEwMS8xMDEvMTAxIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEyMDMyLzEzNy8wICh0ZXN0czogcmVhZCAxNDMzNzEyMDMyLzE0MzM3MTIwMzIvMjAgbnhy
>ZWFkIDE0MzM3MTIwMzIvMTQzMzcxMjAzMi8xNTcyIHRyeWV4Y2VwdCA2LzIvMSBmb3JrIDE0MzM3
>MTIwMzIvMTQzMzcxMjAzMi80MjkgZm9ya3Rvb211Y2ggMTQzMzcxMjAzMi8xNDMzNzEyMDMyLzE0
>MzM3MTIwMzIgYWxsb2MgMzcvMTYvMCBjcmVhdCAxMzcvMTM3LzEzNyBsb2NrIDQvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjA2My8xNjgvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMjA2My8xNDMzNzEyMDYzLzE1IG54cmVhZCAxNDMzNzEyMDYzLzE0MzM3MTIwNjMvMTYwMyB0
>cnlleGNlcHQgMjUvMy8xIGZvcmsgMTQzMzcxMjA2My8xNDMzNzEyMDYzLzQ2MCBmb3JrdG9vbXVj
>aCAxNDMzNzEyMDYzLzE0MzM3MTIwNjMvMTQzMzcxMjA2MyBhbGxvYyA0MC8xMC81IGNyZWF0IDE2
>OC8xNjgvMTY4IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEy
>MDk1LzIwMC8wICh0ZXN0czogcmVhZCAxNDMzNzEyMDk1LzE0MzM3MTIwOTUvNSBueHJlYWQgMTQz
>MzcxMjA5NS8xNDMzNzEyMDk1LzE2MzUgdHJ5ZXhjZXB0IDI3LzEvMCBmb3JrIDE0MzM3MTIwOTUv
>MTQzMzcxMjA5NS80OTIgZm9ya3Rvb211Y2ggMTQzMzcxMjA5NS8xNDMzNzEyMDk1LzE0MzM3MTIw
>OTUgYWxsb2MgNTgvMTAvMiBjcmVhdCAyMDAvMjAwLzIwMCBsb2NrIDEvMS8xKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjEyNC8yMjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjEy
>NC8xNDMzNzEyMTI0LzEgbnhyZWFkIDE0MzM3MTIxMjQvMTQzMzcxMjEyNC8xNjY0IHRyeWV4Y2Vw
>dCA4LzMvMCBmb3JrIDE0MzM3MTIxMjQvMTQzMzcxMjEyNC81MjEgZm9ya3Rvb211Y2ggMTQzMzcx
>MjEyNC8xNDMzNzEyMTI0LzE0MzM3MTIxMjQgYWxsb2MgMzkvNi8xIGNyZWF0IDIyOS8yMjkvMjI5
>IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyMTY1LzI3MC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzEyMTY1LzE0MzM3MTIxNjUvMjMgbnhyZWFkIDE0MzM3MTIxNjUv
>MTQzMzcxMjE2NS8xNzA1IHRyeWV4Y2VwdCA1LzIvMiBmb3JrIDE0MzM3MTIxNjUvMTQzMzcxMjE2
>NS81NjIgZm9ya3Rvb211Y2ggMTQzMzcxMjE2NS8xNDMzNzEyMTY1LzE0MzM3MTIxNjUgYWxsb2Mg
>NTIvNS81IGNyZWF0IDI3MC8yNzAvMjcwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzEyMTg3LzI5Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEyMTg3LzE0MzM3MTIx
>ODcvOSBueHJlYWQgMTQzMzcxMjE4Ny8xNDMzNzEyMTg3LzE3MjcgdHJ5ZXhjZXB0IDE4LzIvMCBm
>b3JrIDE0MzM3MTIxODcvMTQzMzcxMjE4Ny81ODQgZm9ya3Rvb211Y2ggMTQzMzcxMjE4Ny8xNDMz
>NzEyMTg3LzE0MzM3MTIxODcgYWxsb2MgNzQvNS8xIGNyZWF0IDI5Mi8yOTIvMjkyIGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyMjE2LzMyMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEyMjE2LzE0MzM3MTIyMTYvOCBueHJlYWQgMTQzMzcxMjIxNi8xNDMzNzEyMjE2
>LzE3NTYgdHJ5ZXhjZXB0IDkvMS8xIGZvcmsgMTQzMzcxMjIxNi8xNDMzNzEyMjE2LzYxMyBmb3Jr
>dG9vbXVjaCAxNDMzNzEyMjE2LzE0MzM3MTIyMTYvMTQzMzcxMjIxNiBhbGxvYyA1MS8yMS80IGNy
>ZWF0IDMyMS8zMjEvMzIxIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEyMjQ1LzM1MC8wICh0ZXN0czogcmVhZCAxNDMzNzEyMjQ1LzE0MzM3MTIyNDUvMTUgbnhy
>ZWFkIDE0MzM3MTIyNDUvMTQzMzcxMjI0NS8xNzg1IHRyeWV4Y2VwdCAzOC8yLzEgZm9yayAxNDMz
>NzEyMjQ1LzE0MzM3MTIyNDUvNjQyIGZvcmt0b29tdWNoIDE0MzM3MTIyNDUvMTQzMzcxMjI0NS8x
>NDMzNzEyMjQ1IGFsbG9jIDczLzgvNCBjcmVhdCAzNTAvMzUwLzM1MCBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjI3MC8zNzUvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMjI3MC8xNDMzNzEyMjcwLzYgbnhyZWFkIDE0MzM3MTIyNzAvMTQzMzcxMjI3MC8xODEwIHRy
>eWV4Y2VwdCAyMi8yLzEgZm9yayAxNDMzNzEyMjcwLzE0MzM3MTIyNzAvNjY3IGZvcmt0b29tdWNo
>IDE0MzM3MTIyNzAvMTQzMzcxMjI3MC8xNDMzNzEyMjcwIGFsbG9jIDU0LzkvNiBjcmVhdCAzNzUv
>Mzc1LzM3NSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjMw
>MC80MDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjMwMC8xNDMzNzEyMzAwLzEzIG54cmVhZCAxNDMz
>NzEyMzAwLzE0MzM3MTIzMDAvMTg0MCB0cnlleGNlcHQgNTIvMi8xIGZvcmsgMTQzMzcxMjMwMC8x
>NDMzNzEyMzAwLzY5NyBmb3JrdG9vbXVjaCAxNDMzNzEyMzAwLzE0MzM3MTIzMDAvMTQzMzcxMjMw
>MCBhbGxvYyAxOC8zLzMgY3JlYXQgNDA1LzQwNS80MDUgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTIzNDIvNDQ3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTIzNDIv
>MTQzMzcxMjM0Mi8xNiBueHJlYWQgMTQzMzcxMjM0Mi8xNDMzNzEyMzQyLzE4ODIgdHJ5ZXhjZXB0
>IDEzLzIvMSBmb3JrIDE0MzM3MTIzNDIvMTQzMzcxMjM0Mi83MzkgZm9ya3Rvb211Y2ggMTQzMzcx
>MjM0Mi8xNDMzNzEyMzQyLzE0MzM3MTIzNDIgYWxsb2MgNjAvMjAvNSBjcmVhdCA0NDcvNDQ3LzQ0
>NyBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjM3Mi80Nzcv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMjM3Mi8xNDMzNzEyMzcyLzMgbnhyZWFkIDE0MzM3MTIzNzIv
>MTQzMzcxMjM3Mi8xOTEyIHRyeWV4Y2VwdCAyLzIvMCBmb3JrIDE0MzM3MTIzNzIvMTQzMzcxMjM3
>Mi83NjkgZm9ya3Rvb211Y2ggMTQzMzcxMjM3Mi8xNDMzNzEyMzcyLzE0MzM3MTIzNzIgYWxsb2Mg
>MzAvOC8zIGNyZWF0IDQ3Ny80NzcvNDc3IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzEyNDM0LzUzOS8wICh0ZXN0czogcmVhZCAxNDMzNzEyNDM0LzE0MzM3MTI0
>MzQvMTcgbnhyZWFkIDE0MzM3MTI0MzQvMTQzMzcxMjQzNC8xOTc0IHRyeWV4Y2VwdCAxNi8yLzEg
>Zm9yayAxNDMzNzEyNDM0LzE0MzM3MTI0MzQvODMxIGZvcmt0b29tdWNoIDE0MzM3MTI0MzQvMTQz
>MzcxMjQzNC8xNDMzNzEyNDM0IGFsbG9jIDMzLzUvNSBjcmVhdCA1MzkvNTM5LzUzOSBsb2NrIDQv
>NC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjQ1Ny81NjIvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxMjQ1Ny8xNDMzNzEyNDU3LzMgbnhyZWFkIDE0MzM3MTI0NTcvMTQzMzcxMjQ1
>Ny8xOTk3IHRyeWV4Y2VwdCAxMy8yLzAgZm9yayAxNDMzNzEyNDU3LzE0MzM3MTI0NTcvODU0IGZv
>cmt0b29tdWNoIDE0MzM3MTI0NTcvMTQzMzcxMjQ1Ny8xNDMzNzEyNDU3IGFsbG9jIDI4LzMvMSBj
>cmVhdCA1NjIvNTYyLzU2MiBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxMjUwMC82MDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjUwMC8xNDMzNzEyNTAwLzE1IG54
>cmVhZCAxNDMzNzEyNTAwLzE0MzM3MTI1MDAvMjA0MCB0cnlleGNlcHQgNTMvMi8wIGZvcmsgMTQz
>MzcxMjUwMC8xNDMzNzEyNTAwLzg5NyBmb3JrdG9vbXVjaCAxNDMzNzEyNTAwLzE0MzM3MTI1MDAv
>MTQzMzcxMjUwMCBhbGxvYyA0NC8xNS8xIGNyZWF0IDYwNS82MDUvNjA1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyNTI4LzYzMy8wICh0ZXN0czogcmVhZCAx
>NDMzNzEyNTI4LzE0MzM3MTI1MjgvOCBueHJlYWQgMTQzMzcxMjUyOC8xNDMzNzEyNTI4LzIwNjgg
>dHJ5ZXhjZXB0IDQwLzIvMSBmb3JrIDE0MzM3MTI1MjgvMTQzMzcxMjUyOC85MjUgZm9ya3Rvb211
>Y2ggMTQzMzcxMjUyOC8xNDMzNzEyNTI4LzE0MzM3MTI1MjggYWxsb2MgNTAvOC80IGNyZWF0IDYz
>My82MzMvNjMzIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEy
>NTUwLzY1NS8wICh0ZXN0czogcmVhZCAxNDMzNzEyNTUwLzE0MzM3MTI1NTAvMjIgbnhyZWFkIDE0
>MzM3MTI1NTAvMTQzMzcxMjU1MC8yMDkwIHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzEyNTUw
>LzE0MzM3MTI1NTAvOTQ3IGZvcmt0b29tdWNoIDE0MzM3MTI1NTAvMTQzMzcxMjU1MC8xNDMzNzEy
>NTUwIGFsbG9jIDY1LzEwLzQgY3JlYXQgNjU1LzY1NS82NTUgbG9jayA0LzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI1NzcvNjgyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTI1
>NzcvMTQzMzcxMjU3Ny8xNiBueHJlYWQgMTQzMzcxMjU3Ny8xNDMzNzEyNTc3LzIxMTcgdHJ5ZXhj
>ZXB0IDgvMS8xIGZvcmsgMTQzMzcxMjU3Ny8xNDMzNzEyNTc3Lzk3NCBmb3JrdG9vbXVjaCAxNDMz
>NzEyNTc3LzE0MzM3MTI1NzcvMTQzMzcxMjU3NyBhbGxvYyAzNy8yMS8wIGNyZWF0IDY4Mi82ODIv
>NjgyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyNjAzLzcw
>OC8wICh0ZXN0czogcmVhZCAxNDMzNzEyNjAzLzE0MzM3MTI2MDMvMTAgbnhyZWFkIDE0MzM3MTI2
>MDMvMTQzMzcxMjYwMy8yMTQzIHRyeWV4Y2VwdCAxNi8zLzAgZm9yayAxNDMzNzEyNjAzLzE0MzM3
>MTI2MDMvMTAwMCBmb3JrdG9vbXVjaCAxNDMzNzEyNjAzLzE0MzM3MTI2MDMvMTQzMzcxMjYwMyBh
>bGxvYyAzNi8xNS8xMCBjcmVhdCA3MDgvNzA4LzcwOCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjYzMS83MzYvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjYzMS8x
>NDMzNzEyNjMxLzEgbnhyZWFkIDE0MzM3MTI2MzEvMTQzMzcxMjYzMS8yMTcxIHRyeWV4Y2VwdCAz
>OC8xLzAgZm9yayAxNDMzNzEyNjMxLzE0MzM3MTI2MzEvMTAyOCBmb3JrdG9vbXVjaCAxNDMzNzEy
>NjMxLzE0MzM3MTI2MzEvMTQzMzcxMjYzMSBhbGxvYyA2NC83LzEgY3JlYXQgNzM2LzczNi83MzYg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI2NTkvNzY0LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTI2NTkvMTQzMzcxMjY1OS8yOSBueHJlYWQgMTQzMzcxMjY1OS8x
>NDMzNzEyNjU5LzIxOTkgdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcxMjY1OS8xNDMzNzEyNjU5
>LzI0IGZvcmt0b29tdWNoIDE0MzM3MTI2NTkvMTQzMzcxMjY1OS8xNDMzNzEyNjU5IGFsbG9jIDI5
>LzMvMSBjcmVhdCA3NjQvNzY0Lzc2NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxMjY5Mi83OTcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjY5Mi8xNDMzNzEyNjky
>LzYyIG54cmVhZCAxNDMzNzEyNjkyLzE0MzM3MTI2OTIvMjIzMiB0cnlleGNlcHQgMzUvNy8wIGZv
>cmsgMTQzMzcxMjY5Mi8xNDMzNzEyNjkyLzU3IGZvcmt0b29tdWNoIDE0MzM3MTI2OTIvMTQzMzcx
>MjY5Mi8xNDMzNzEyNjkyIGFsbG9jIDM2LzYvMSBjcmVhdCA3OTcvNzk3Lzc5NyBsb2NrIDEvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjcxNy84MjIvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMjcxNy8xNDMzNzEyNzE3Lzg3IG54cmVhZCAxNDMzNzEyNzE3LzE0MzM3MTI3MTcv
>MjI1NyB0cnlleGNlcHQgMzcvMi8xIGZvcmsgMTQzMzcxMjcxNy8xNDMzNzEyNzE3LzgyIGZvcmt0
>b29tdWNoIDE0MzM3MTI3MTcvMTQzMzcxMjcxNy8xNDMzNzEyNzE3IGFsbG9jIDQ3LzYvMiBjcmVh
>dCA4MjIvODIyLzgyMiBsb2NrIDIvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMjc0Mi84NDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjc0Mi8xNDMzNzEyNzQyLzIgbnhyZWFk
>IDE0MzM3MTI3NDIvMTQzMzcxMjc0Mi8yMjgyIHRyeWV4Y2VwdCAyNi8xLzAgZm9yayAxNDMzNzEy
>NzQyLzE0MzM3MTI3NDIvMTA3IGZvcmt0b29tdWNoIDE0MzM3MTI3NDIvMTQzMzcxMjc0Mi8xNDMz
>NzEyNzQyIGFsbG9jIDcyLzcvMiBjcmVhdCA4NDcvODQ3Lzg0NyBsb2NrIDEvMS8xKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjc3My84NzgvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>Mjc3My8xNDMzNzEyNzczLzcgbnhyZWFkIDE0MzM3MTI3NzMvMTQzMzcxMjc3My8yMzEzIHRyeWV4
>Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzEyNzczLzE0MzM3MTI3NzMvMTM4IGZvcmt0b29tdWNoIDE0
>MzM3MTI3NzMvMTQzMzcxMjc3My8xNDMzNzEyNzczIGFsbG9jIDM4LzE0LzQgY3JlYXQgODc4Lzg3
>OC84NzggbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI3OTgv
>OTAzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTI3OTgvMTQzMzcxMjc5OC8xIG54cmVhZCAxNDMzNzEy
>Nzk4LzE0MzM3MTI3OTgvMjMzOCB0cnlleGNlcHQgMTMvMy8wIGZvcmsgMTQzMzcxMjc5OC8xNDMz
>NzEyNzk4LzEyIGZvcmt0b29tdWNoIDE0MzM3MTI3OTgvMTQzMzcxMjc5OC8xNDMzNzEyNzk4IGFs
>bG9jIDUzLzQvMSBjcmVhdCA5MDMvOTAzLzkwMyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMjgzNC85MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjgzNC8xMDUw
>LzkgbnhyZWFkIDE0MzM3MTI4MzQvMTQzMzcxMjgzNC8yMzc0IHRyeWV4Y2VwdCAyMy8yLzEgZm9y
>ayAxNDMzNzEyODM0LzE0MzM3MTI4MzQvNDggZm9ya3Rvb211Y2ggMTQzMzcxMjgzNC8xNDMzNzEy
>ODM0LzE0MzM3MTI4MzQgYWxsb2MgNDgvMTcvNSBjcmVhdCA5MzkvOTM5LzkzOSBsb2NrIDUvNS8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjg3NS85ODAvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMjg3NS8xMDkxLzIyIG54cmVhZCAxNDMzNzEyODc1LzE0MzM3MTI4NzUvMjQxNSB0
>cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzEyODc1LzE0MzM3MTI4NzUvODkgZm9ya3Rvb211Y2gg
>MTQzMzcxMjg3NS8xNDMzNzEyODc1LzE0MzM3MTI4NzUgYWxsb2MgNDEvNi8xIGNyZWF0IDk4MC85
>ODAvOTgwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyOTA4
>LzEwMTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjkwOC8xMTI0LzU1IG54cmVhZCAxNDMzNzEyOTA4
>LzE0MzM3MTI5MDgvMjQ0OCB0cnlleGNlcHQgMy8yLzEgZm9yayAxNDMzNzEyOTA4LzE0MzM3MTI5
>MDgvMTIyIGZvcmt0b29tdWNoIDE0MzM3MTI5MDgvMTQzMzcxMjkwOC8xNDMzNzEyOTA4IGFsbG9j
>IDU5LzEyLzYgY3JlYXQgMTAxMy8xMDEzLzEwMTMgbG9jayA0LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTI5MjkvMTAzNC8wICh0ZXN0czogcmVhZCAxNDMzNzEyOTI5LzEx
>NDUvNSBueHJlYWQgMTQzMzcxMjkyOS8xNDMzNzEyOTI5LzI0NjkgdHJ5ZXhjZXB0IDUvMi8xIGZv
>cmsgMTQzMzcxMjkyOS8xNDMzNzEyOTI5LzE0MyBmb3JrdG9vbXVjaCAxNDMzNzEyOTI5LzE0MzM3
>MTI5MjkvMTQzMzcxMjkyOSBhbGxvYyA0NC8xMS81IGNyZWF0IDEwMzQvMTAzNC8xMDM0IGxvY2sg
>MC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyOTU1LzEwNjAvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxMjk1NS8xMTcxLzI2IG54cmVhZCAxNDMzNzEyOTU1LzE0MzM3MTI5NTUv
>MjQ5NSB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzEyOTU1LzE0MzM3MTI5NTUvMTY5IGZvcmt0
>b29tdWNoIDE0MzM3MTI5NTUvMTQzMzcxMjk1NS8xNDMzNzEyOTU1IGFsbG9jIDM3LzEyLzQgY3Jl
>YXQgMTA2MC8xMDYwLzEwNjAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTI5NzcvMTA4Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEyOTc3LzExOTMvNDggbnhyZWFk
>IDE0MzM3MTI5NzcvMTQzMzcxMjk3Ny8yNTE3IHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzEy
>OTc3LzE0MzM3MTI5NzcvMTkxIGZvcmt0b29tdWNoIDE0MzM3MTI5NzcvMTQzMzcxMjk3Ny8xNDMz
>NzEyOTc3IGFsbG9jIDI2LzUvNSBjcmVhdCAxMDgyLzEwODIvMTA4MiBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjk5Ni8xMTAxLzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTI5OTYvMTIxMi8xOSBueHJlYWQgMTQzMzcxMjk5Ni8xNDMzNzEyOTk2LzI1MzYgdHJ5ZXhj
>ZXB0IDIwLzIvMiBmb3JrIDE0MzM3MTI5OTYvMTQzMzcxMjk5Ni8yMTAgZm9ya3Rvb211Y2ggMTQz
>MzcxMjk5Ni8xNDMzNzEyOTk2LzE0MzM3MTI5OTYgYWxsb2MgNDUvMTEvMCBjcmVhdCAxMTAxLzEx
>MDEvMTEwMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzAx
>Ni8xMTIxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTMwMTYvMTIzMi82IG54cmVhZCAxNDMzNzEzMDE2
>LzE0MzM3MTMwMTYvMjU1NiB0cnlleGNlcHQgMzgvMC8wIGZvcmsgMTQzMzcxMzAxNi8xNDMzNzEz
>MDE2LzIzMCBmb3JrdG9vbXVjaCAxNDMzNzEzMDE2LzE0MzM3MTMwMTYvMTQzMzcxMzAxNiBhbGxv
>YyAyMC82LzIgY3JlYXQgMTEyMS8xMTIxLzExMjEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTMwMzcvMTE0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEzMDM3LzEy
>NTMvNyBueHJlYWQgMTQzMzcxMzAzNy8xNDMzNzEzMDM3LzI1NzcgdHJ5ZXhjZXB0IDE3LzEvMSBm
>b3JrIDE0MzM3MTMwMzcvMTQzMzcxMzAzNy8yNTEgZm9ya3Rvb211Y2ggMTQzMzcxMzAzNy8xNDMz
>NzEzMDM3LzE0MzM3MTMwMzcgYWxsb2MgMjcvMTgvMyBjcmVhdCAxMTQyLzExNDIvMTE0MiBsb2Nr
>IDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzA2MS8xMTY2LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTMwNjEvMTI3Ny82IG54cmVhZCAxNDMzNzEzMDYxLzE0MzM3MTMwNjEv
>MjYwMSB0cnlleGNlcHQgMTMvMS8xIGZvcmsgMTQzMzcxMzA2MS8xNDMzNzEzMDYxLzI3NSBmb3Jr
>dG9vbXVjaCAxNDMzNzEzMDYxLzE0MzM3MTMwNjEvMTQzMzcxMzA2MSBhbGxvYyA1MS8xNS8wIGNy
>ZWF0IDExNjYvMTE2Ni8xMTY2IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzEzMDgxLzExODYvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzA4MS8xMjk3LzkgbnhyZWFk
>IDE0MzM3MTMwODEvMTQzMzcxMzA4MS8yNjIxIHRyeWV4Y2VwdCAxNC85LzAgZm9yayAxNDMzNzEz
>MDgxLzE0MzM3MTMwODEvMjk1IGZvcmt0b29tdWNoIDE0MzM3MTMwODEvMTQzMzcxMzA4MS8xNDMz
>NzEzMDgxIGFsbG9jIDMyLzExLzAgY3JlYXQgMTE4Ni8xMTg2LzExODYgbG9jayAwLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTMxMDYvMTIxMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzEzMTA2LzEzMjIvNCBueHJlYWQgMTQzMzcxMzEwNi8xNDMzNzEzMTA2LzI2NDYgdHJ5ZXhj
>ZXB0IDI3LzEvMSBmb3JrIDE0MzM3MTMxMDYvMTQzMzcxMzEwNi8zMjAgZm9ya3Rvb211Y2ggMTQz
>MzcxMzEwNi8xNDMzNzEzMTA2LzE0MzM3MTMxMDYgYWxsb2MgMzYvOS80IGNyZWF0IDEyMTEvMTIx
>MS8xMjExIGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzMTM0
>LzEyMzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzEzNC8xMzUwLzMyIG54cmVhZCAxNDMzNzEzMTM0
>LzE0MzM3MTMxMzQvMjY3NCB0cnlleGNlcHQgMTYvMC8wIGZvcmsgMTQzMzcxMzEzNC8xNDMzNzEz
>MTM0LzM0OCBmb3JrdG9vbXVjaCAxNDMzNzEzMTM0LzE0MzM3MTMxMzQvMTQzMzcxMzEzNCBhbGxv
>YyAyOC81LzIgY3JlYXQgMTIzOS8xMjM5LzEyMzkgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTMxOTIvMzM5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTMxOTIvMTQw
>OC81IG54cmVhZCAxNDMzNzEzMTkyLzE0MzM3MTMxOTIvMjczMiB0cnlleGNlcHQgNC8yLzEgZm9y
>ayAxNDMzNzEzMTkyLzE0MzM3MTMxOTIvNSBmb3JrdG9vbXVjaCAxNDMzNzEzMTkyLzE0MzM3MTMx
>OTIvMTQzMzcxMzE5MiBhbGxvYyA0Mi8xMC8wIGNyZWF0IDEyOTcvMTI5Ny8xMyBsb2NrIDQvMy8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzIxNi8zNjMvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMzIxNi8xNDMyLzkgbnhyZWFkIDE0MzM3MTMyMTYvMTQzMzcxMzIxNi8yNzU2IHRy
>eWV4Y2VwdCAzLzIvMSBmb3JrIDE0MzM3MTMyMTYvMTQzMzcxMzIxNi8yOSBmb3JrdG9vbXVjaCAx
>NDMzNzEzMjE2LzE0MzM3MTMyMTYvMTQzMzcxMzIxNiBhbGxvYyAzNy8xNC83IGNyZWF0IDEzMjEv
>MTMyMS8zNyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzI0
>My8zOTAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzI0My8xNDU5LzYgbnhyZWFkIDE0MzM3MTMyNDMv
>MTQzMzcxMzI0My8yNzgzIHRyeWV4Y2VwdCAyMS8yLzEgZm9yayAxNDMzNzEzMjQzLzE0MzM3MTMy
>NDMvNTYgZm9ya3Rvb211Y2ggMTQzMzcxMzI0My8xNDMzNzEzMjQzLzE0MzM3MTMyNDMgYWxsb2Mg
>MzQvMjAvNiBjcmVhdCAxMzQ4LzEzNDgvNjQgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTMyNzEvNDE4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTMyNzEvMTQ4Ny81
>IG54cmVhZCAxNDMzNzEzMjcxLzE0MzM3MTMyNzEvMjgxMSB0cnlleGNlcHQgMTAvMi8xIGZvcmsg
>MTQzMzcxMzI3MS8xNDMzNzEzMjcxLzg0IGZvcmt0b29tdWNoIDE0MzM3MTMyNzEvMTQzMzcxMzI3
>MS8xNDMzNzEzMjcxIGFsbG9jIDM0LzE4LzUgY3JlYXQgMTM3Ni8xMzc2LzkyIGxvY2sgNC80LzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzMzE4LzIyNy8wICh0ZXN0czogcmVh
>ZCAxNDMzNzEzMzE4LzQ2NS8xOSBueHJlYWQgMTQzMzcxMzMxOC8xNDMzNzEzMzE4LzI4NTggdHJ5
>ZXhjZXB0IDEzLzMvMCBmb3JrIDE0MzM3MTMzMTgvMTQzMzcxMzMxOC8xOCBmb3JrdG9vbXVjaCAx
>NDMzNzEzMzE4LzE0MzM3MTMzMTgvMTQzMzcxMzMxOCBhbGxvYyAyOC8xLzEgY3JlYXQgMTQyMy8x
>NDIzLzEzOSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzM1
>MC8yNTkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzM1MC8yNTkvMTcgbnhyZWFkIDE0MzM3MTMzNTAv
>MTQzMzcxMzM1MC8yODkwIHRyeWV4Y2VwdCAxOC8yLzAgZm9yayAxNDMzNzEzMzUwLzE0MzM3MTMz
>NTAvNTAgZm9ya3Rvb211Y2ggMTQzMzcxMzM1MC8xNDMzNzEzMzUwLzE0MzM3MTMzNTAgYWxsb2Mg
>MzMvMS8xIGNyZWF0IDE0NTUvMTQ1NS8xNzEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTM0NTAvMjgyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTM0NTAvMzU5LzE1
>IG54cmVhZCAxNDMzNzEzNDUwLzE0MzM3MTM0NTAvMjk5MCB0cnlleGNlcHQgMTIvMi8xIGZvcmsg
>MTQzMzcxMzQ1MC8xNDMzNzEzNDUwLzE1MCBmb3JrdG9vbXVjaCAxNDMzNzEzNDUwLzE0MzM3MTM0
>NTAvMTQzMzcxMzQ1MCBhbGxvYyA0Ni8yNS8wIGNyZWF0IDE1NTUvMTU1NS8yNzEgbG9jayA0LzQv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM0OTMvMzI1LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTM0OTMvNDAyLzE0IG54cmVhZCAxNDMzNzEzNDkzLzE0MzM3MTM0OTMvMzAzMyB0
>cnlleGNlcHQgNDAvMS8xIGZvcmsgMTQzMzcxMzQ5My8xNDMzNzEzNDkzLzE5MyBmb3JrdG9vbXVj
>aCAxNDMzNzEzNDkzLzE0MzM3MTM0OTMvMTQzMzcxMzQ5MyBhbGxvYyAxNC81LzAgY3JlYXQgMTU5
>OC8xNTk4LzMxNCBsb2NrIDUvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>MzUyMC8zNTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzUyMC80MjkvMSBueHJlYWQgMTQzMzcxMzUy
>MC8xNDMzNzEzNTIwLzMwNjAgdHJ5ZXhjZXB0IDIvMi8wIGZvcmsgMTQzMzcxMzUyMC8xNDMzNzEz
>NTIwLzIyMCBmb3JrdG9vbXVjaCAxNDMzNzEzNTIwLzE0MzM3MTM1MjAvMTQzMzcxMzUyMCBhbGxv
>YyAzNi8yLzEgY3JlYXQgMTYyNS8xNjI1LzM0MSBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzU2NS8zOTcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzU2NS80NzQv
>MSBueHJlYWQgMTQzMzcxMzU2NS8xNDMzNzEzNTY1LzMxMDUgdHJ5ZXhjZXB0IDgvMS8wIGZvcmsg
>MTQzMzcxMzU2NS8xNDMzNzEzNTY1LzI2NSBmb3JrdG9vbXVjaCAxNDMzNzEzNTY1LzE0MzM3MTM1
>NjUvMTQzMzcxMzU2NSBhbGxvYyA0Ny83LzEgY3JlYXQgMTY3MC8xNjcwLzM4NiBsb2NrIDEvMS8x
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzU4OC80MjAvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMzU4OC80OTcvMjEgbnhyZWFkIDE0MzM3MTM1ODgvMTQzMzcxMzU4OC8zMTI4IHRy
>eWV4Y2VwdCAzMS8wLzAgZm9yayAxNDMzNzEzNTg4LzE0MzM3MTM1ODgvMjg4IGZvcmt0b29tdWNo
>IDE0MzM3MTM1ODgvMTQzMzcxMzU4OC8xNDMzNzEzNTg4IGFsbG9jIDIxLzYvMSBjcmVhdCAxNjkz
>LzE2OTMvNDA5IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEz
>NjIwLzQ1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEzNjIwLzUyOS8xMCBueHJlYWQgMTQzMzcxMzYy
>MC8xNDMzNzEzNjIwLzMxNjAgdHJ5ZXhjZXB0IDMvMi8xIGZvcmsgMTQzMzcxMzYyMC8xNDMzNzEz
>NjIwLzE3IGZvcmt0b29tdWNoIDE0MzM3MTM2MjAvMTQzMzcxMzYyMC8xNDMzNzEzNjIwIGFsbG9j
>IDI1LzEwLzMgY3JlYXQgMTcyNS8xNzI1LzQ0MSBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzY2Ny80OTkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzY2Ny81NzYv
>MTcgbnhyZWFkIDE0MzM3MTM2NjcvMTQzMzcxMzY2Ny8zMjA3IHRyeWV4Y2VwdCA0LzIvMSBmb3Jr
>IDE0MzM3MTM2NjcvMTQzMzcxMzY2Ny82NCBmb3JrdG9vbXVjaCAxNDMzNzEzNjY3LzE0MzM3MTM2
>NjcvMTQzMzcxMzY2NyBhbGxvYyA0Mi8xMS81IGNyZWF0IDE3NzIvMTc3Mi80ODggbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM3MTMvNTQ1LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTM3MTMvNjIyLzIgbnhyZWFkIDE0MzM3MTM3MTMvMTQzMzcxMzcxMy8zMjUzIHRy
>eWV4Y2VwdCAzLzEvMCBmb3JrIDE0MzM3MTM3MTMvMTQzMzcxMzcxMy8xMTAgZm9ya3Rvb211Y2gg
>MTQzMzcxMzcxMy8xNDMzNzEzNzEzLzE0MzM3MTM3MTMgYWxsb2MgMjIvOC8yIGNyZWF0IDE4MTgv
>MTgxOC81MzQgbG9jayAyLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM3
>NDYvNTc4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTM3NDYvNjU1LzE0IG54cmVhZCAxNDMzNzEzNzQ2
>LzE0MzM3MTM3NDYvMzI4NiB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzEzNzQ2LzE0MzM3MTM3
>NDYvMTQzIGZvcmt0b29tdWNoIDE0MzM3MTM3NDYvMTQzMzcxMzc0Ni8xNDMzNzEzNzQ2IGFsbG9j
>IDM1LzEwLzUgY3JlYXQgMTg1MS8xODUxLzU2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzc5NS82MjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzc5NS83MDQv
>MTYgbnhyZWFkIDE0MzM3MTM3OTUvMTQzMzcxMzc5NS8zMzM1IHRyeWV4Y2VwdCA1LzIvMSBmb3Jr
>IDE0MzM3MTM3OTUvMTQzMzcxMzc5NS8xOTIgZm9ya3Rvb211Y2ggMTQzMzcxMzc5NS8xNDMzNzEz
>Nzk1LzE0MzM3MTM3OTUgYWxsb2MgMzMvMTEvNiBjcmVhdCAxOTAwLzE5MDAvNjE2IGxvY2sgNi82
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzODI3LzY1OS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEzODI3LzczNi8xNCBueHJlYWQgMTQzMzcxMzgyNy8xNDMzNzEzODI3LzMzNjcg
>dHJ5ZXhjZXB0IDQvMy8wIGZvcmsgMTQzMzcxMzgyNy8xNDMzNzEzODI3LzIyNCBmb3JrdG9vbXVj
>aCAxNDMzNzEzODI3LzE0MzM3MTM4MjcvMTQzMzcxMzgyNyBhbGxvYyA0My8xLzEgY3JlYXQgMTkz
>Mi8xOTMyLzY0OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>Mzg2MS82OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzg2MS83NzAvMjEgbnhyZWFkIDE0MzM3MTM4
>NjEvMTQzMzcxMzg2MS8zNDAxIHRyeWV4Y2VwdCA0LzAvMCBmb3JrIDE0MzM3MTM4NjEvMTQzMzcx
>Mzg2MS8yNTggZm9ya3Rvb211Y2ggMTQzMzcxMzg2MS8xNDMzNzEzODYxLzE0MzM3MTM4NjEgYWxs
>b2MgNzcvOC8yIGNyZWF0IDE5NjYvMTk2Ni82ODIgbG9jayAyLzIvMSkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTM4OTEvNzIzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTM4OTEvODAw
>LzUxIG54cmVhZCAxNDMzNzEzODkxLzE0MzM3MTM4OTEvMzQzMSB0cnlleGNlcHQgNC8yLzEgZm9y
>ayAxNDMzNzEzODkxLzE0MzM3MTM4OTEvMjg4IGZvcmt0b29tdWNoIDE0MzM3MTM4OTEvMTQzMzcx
>Mzg5MS8xNDMzNzEzODkxIGFsbG9jIDI2LzEwLzUgY3JlYXQgMTk5Ni8xOTk2LzcxMiBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzkxOS83NTEvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxMzkxOS84MjgvMjIgbnhyZWFkIDE0MzM3MTM5MTkvMTQzMzcxMzkxOS8zNDU5
>IHRyeWV4Y2VwdCAyMi8yLzEgZm9yayAxNDMzNzEzOTE5LzE0MzM3MTM5MTkvMzE2IGZvcmt0b29t
>dWNoIDE0MzM3MTM5MTkvMTQzMzcxMzkxOS8xNDMzNzEzOTE5IGFsbG9jIDM4LzE0LzYgY3JlYXQg
>MjAyNC8yMDI0Lzc0MCBsb2NrIDYvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMzkzNy83NjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzkzNy84NDYvMTggbnhyZWFkIDE0MzM3
>MTM5MzcvMTQzMzcxMzkzNy8zNDc3IHRyeWV4Y2VwdCA0MC8wLzAgZm9yayAxNDMzNzEzOTM3LzE0
>MzM3MTM5MzcvMzM0IGZvcmt0b29tdWNoIDE0MzM3MTM5MzcvMTQzMzcxMzkzNy8xNDMzNzEzOTM3
>IGFsbG9jIDI3LzgvMyBjcmVhdCAyMDQyLzIwNDIvNzU4IGxvY2sgMi8yLzIpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzEzOTY2Lzc5OC8wICh0ZXN0czogcmVhZCAxNDMzNzEzOTY2
>Lzg3NS85IG54cmVhZCAxNDMzNzEzOTY2LzE0MzM3MTM5NjYvMzUwNiB0cnlleGNlcHQgMTQvMS8x
>IGZvcmsgMTQzMzcxMzk2Ni8xNDMzNzEzOTY2LzM2MyBmb3JrdG9vbXVjaCAxNDMzNzEzOTY2LzE0
>MzM3MTM5NjYvMTQzMzcxMzk2NiBhbGxvYyA0Mi8xNi80IGNyZWF0IDIwNzEvMjA3MS83ODcgbG9j
>ayA0LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM5OTEvODIzLzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTM5OTEvOTAwLzExIG54cmVhZCAxNDMzNzEzOTkxLzE0MzM3MTM5OTEv
>MzUzMSB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzEzOTkxLzE0MzM3MTM5OTEvMTAgZm9ya3Rv
>b211Y2ggMTQzMzcxMzk5MS8xNDMzNzEzOTkxLzE0MzM3MTM5OTEgYWxsb2MgNDEvMTEvNSBjcmVh
>dCAyMDk2LzIwOTYvMTEgbG9jayA0LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQwMTkvODUxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQwMTkvOTI4LzEwIG54cmVhZCAxNDMz
>NzE0MDE5LzE0MzM3MTQwMTkvMzU1OSB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzE0MDE5LzE0
>MzM3MTQwMTkvMTAgZm9ya3Rvb211Y2ggMTQzMzcxNDAxOS8xNDMzNzE0MDE5LzE0MzM3MTQwMTkg
>YWxsb2MgMzkvMTAvNSBjcmVhdCAyMTI0LzIxMjQvMzkgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTQwNDUvODY2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQwNDUv
>OTU0LzE0IG54cmVhZCAxNDMzNzE0MDQ1LzE0MzM3MTQwNDUvMzU4NSB0cnlleGNlcHQgNC8yLzEg
>Zm9yayAxNDMzNzE0MDQ1LzE0MzM3MTQwNDUvMzYgZm9ya3Rvb211Y2ggMTQzMzcxNDA0NS8xNDMz
>NzE0MDQ1LzE0MzM3MTQwNDUgYWxsb2MgMjYvOS81IGNyZWF0IDIxNTAvMjE1MC8yNiBsb2NrIDUv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDA3MS83MzgvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxNDA3MS85ODAvNDAgbnhyZWFkIDE0MzM3MTQwNzEvMTQzMzcxNDA3MS8zNjEx
>IHRyeWV4Y2VwdCAxOC8yLzAgZm9yayAxNDMzNzE0MDcxLzE0MzM3MTQwNzEvNjIgZm9ya3Rvb211
>Y2ggMTQzMzcxNDA3MS8xNDMzNzE0MDcxLzE0MzM3MTQwNzEgYWxsb2MgMzEvMTIvMSBjcmVhdCAy
>MTc2LzkwMy84IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0
>MTAwLzc2Ny8wICh0ZXN0czogcmVhZCAxNDMzNzE0MTAwLzEwMDkvMTEgbnhyZWFkIDE0MzM3MTQx
>MDAvMTQzMzcxNDEwMC8zNjQwIHRyeWV4Y2VwdCAzNC8yLzEgZm9yayAxNDMzNzE0MTAwLzE0MzM3
>MTQxMDAvMjUgZm9ya3Rvb211Y2ggMTQzMzcxNDEwMC8xNDMzNzE0MTAwLzE0MzM3MTQxMDAgYWxs
>b2MgMzAvOC80IGNyZWF0IDIyMDUvOTMyLzM3IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE0MTIwLzE0MC8wICh0ZXN0czogcmVhZCAxNDMzNzE0MTIwLzEwMjkv
>MTEgbnhyZWFkIDE0MzM3MTQxMjAvMTQzMzcxNDEyMC8zNjYwIHRyeWV4Y2VwdCAxOC8yLzEgZm9y
>ayAxNDMzNzE0MTIwLzE0MzM3MTQxMjAvNDUgZm9ya3Rvb211Y2ggMTQzMzcxNDEyMC8xNDMzNzE0
>MTIwLzE0MzM3MTQxMjAgYWxsb2MgMzEvMjQvNiBjcmVhdCAyMjI1LzE0MC8xMSBsb2NrIDYvNi8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDE0OS8xNjkvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNDE0OS8xMDU4LzE1IG54cmVhZCAxNDMzNzE0MTQ5LzE0MzM3MTQxNDkvMzY4OSB0
>cnlleGNlcHQgMTQvMi8xIGZvcmsgMTQzMzcxNDE0OS8xNDMzNzE0MTQ5Lzc0IGZvcmt0b29tdWNo
>IDE0MzM3MTQxNDkvMTQzMzcxNDE0OS8xNDMzNzE0MTQ5IGFsbG9jIDQ5LzIwLzcgY3JlYXQgMjI1
>NC8xNjkvNDAgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQx
>NzkvNzYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDE3OS8xMDg4LzEgbnhyZWFkIDE0MzM3MTQxNzkv
>MTQzMzcxNDE3OS8zNzE5IHRyeWV4Y2VwdCA4LzEvMCBmb3JrIDE0MzM3MTQxNzkvMTQzMzcxNDE3
>OS8xMDQgZm9ya3Rvb211Y2ggMTQzMzcxNDE3OS8xNDMzNzE0MTc5LzE0MzM3MTQxNzkgYWxsb2Mg
>MjUvNy8xIGNyZWF0IDE2MC8xOS8xOSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxNDIxNy8xMTQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDIxNy8xMTI2LzE1IG54
>cmVhZCAxNDMzNzE0MjE3LzE0MzM3MTQyMTcvMzc1NyB0cnlleGNlcHQgOS8xLzAgZm9yayAxNDMz
>NzE0MjE3LzE0MzM3MTQyMTcvMTQyIGZvcmt0b29tdWNoIDE0MzM3MTQyMTcvMTQzMzcxNDIxNy8x
>NDMzNzE0MjE3IGFsbG9jIDM5LzkvMiBjcmVhdCAxOTgvNTcvNTcgbG9jayAxLzEvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQyNTMvMTQ0LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTQyNTMvMTE2Mi82IG54cmVhZCAxNDMzNzE0MjUzLzE0MzM3MTQyNTMvMzc5MyB0cnlleGNlcHQg
>Ni8yLzEgZm9yayAxNDMzNzE0MjUzLzE0MzM3MTQyNTMvMTc4IGZvcmt0b29tdWNoIDE0MzM3MTQy
>NTMvMTQzMzcxNDI1My8xNDMzNzE0MjUzIGFsbG9jIDM4LzEyLzYgY3JlYXQgMjM0LzkzLzkzIGxv
>Y2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0MzY5LzI2MC8wICh0
>ZXN0czogcmVhZCAxNDMzNzE0MzY5LzEyNzgvMTUgbnhyZWFkIDE0MzM3MTQzNjkvMTQzMzcxNDM2
>OS8zOTA5IHRyeWV4Y2VwdCAxMy8yLzEgZm9yayAxNDMzNzE0MzY5LzE0MzM3MTQzNjkvMjk0IGZv
>cmt0b29tdWNoIDE0MzM3MTQzNjkvMTQzMzcxNDM2OS8xNDMzNzE0MzY5IGFsbG9jIDQ3LzE1LzUg
>Y3JlYXQgMzUwLzIwOS8yMDkgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTQzOTAvMjgxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQzOTAvMTI5OS8zIG54cmVhZCAx
>NDMzNzE0MzkwLzE0MzM3MTQzOTAvMzkzMCB0cnlleGNlcHQgMzQvMi8wIGZvcmsgMTQzMzcxNDM5
>MC8xNDMzNzE0MzkwLzMxNSBmb3JrdG9vbXVjaCAxNDMzNzE0MzkwLzE0MzM3MTQzOTAvMTQzMzcx
>NDM5MCBhbGxvYyAyNi8zLzEgY3JlYXQgMzcxLzIzMC8yMzAgbG9jayAwLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ0MzEvMzIyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ0
>MzEvMTM0MC8yMCBueHJlYWQgMTQzMzcxNDQzMS8xNDMzNzE0NDMxLzM5NzEgdHJ5ZXhjZXB0IDQz
>LzIvMSBmb3JrIDE0MzM3MTQ0MzEvMTQzMzcxNDQzMS8zNTYgZm9ya3Rvb211Y2ggMTQzMzcxNDQz
>MS8xNDMzNzE0NDMxLzE0MzM3MTQ0MzEgYWxsb2MgNDQvMTAvNSBjcmVhdCA0MTIvMjcxLzI3MSBs
>b2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDQ1Ni8zNDcvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxNDQ1Ni8xMzY1LzEyIG54cmVhZCAxNDMzNzE0NDU2LzE0MzM3MTQ0
>NTYvMzk5NiB0cnlleGNlcHQgNDEvMi8wIGZvcmsgMTQzMzcxNDQ1Ni8xNDMzNzE0NDU2LzM4MSBm
>b3JrdG9vbXVjaCAxNDMzNzE0NDU2LzE0MzM3MTQ0NTYvMTQzMzcxNDQ1NiBhbGxvYyAzMC84LzEg
>Y3JlYXQgNDM3LzI5Ni8yOTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTQ0NzYvMzY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ0NzYvMTM4NS81IG54cmVhZCAx
>NDMzNzE0NDc2LzE0MzM3MTQ0NzYvNDAxNiB0cnlleGNlcHQgMTYvMy8xIGZvcmsgMTQzMzcxNDQ3
>Ni8xNDMzNzE0NDc2LzQwMSBmb3JrdG9vbXVjaCAxNDMzNzE0NDc2LzE0MzM3MTQ0NzYvMTQzMzcx
>NDQ3NiBhbGxvYyAyOC85LzUgY3JlYXQgNDU3LzMxNi8zMTYgbG9jayA0LzQvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ1MTEvNDAyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ1
>MTEvMTQyMC8xOSBueHJlYWQgMTQzMzcxNDUxMS8xNDMzNzE0NTExLzQwNTEgdHJ5ZXhjZXB0IDIw
>LzEvMSBmb3JrIDE0MzM3MTQ1MTEvMTQzMzcxNDUxMS80MzYgZm9ya3Rvb211Y2ggMTQzMzcxNDUx
>MS8xNDMzNzE0NTExLzE0MzM3MTQ1MTEgYWxsb2MgNDQvOC8wIGNyZWF0IDQ5Mi8zNTEvMzUxIGxv
>Y2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0NTU0LzQ0NS8wICh0
>ZXN0czogcmVhZCAxNDMzNzE0NTU0LzE0NjMvMSBueHJlYWQgMTQzMzcxNDU1NC8xNDMzNzE0NTU0
>LzQwOTQgdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcxNDU1NC8xNDMzNzE0NTU0LzQ3OSBmb3Jr
>dG9vbXVjaCAxNDMzNzE0NTU0LzE0MzM3MTQ1NTQvMTQzMzcxNDU1NCBhbGxvYyA1Ni83LzEgY3Jl
>YXQgNTM1LzM5NC8zOTQgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQ1OTAvNDgxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ1OTAvMTQ5OS81IG54cmVhZCAxNDMz
>NzE0NTkwLzE0MzM3MTQ1OTAvNDEzMCB0cnlleGNlcHQgMTcvMS8xIGZvcmsgMTQzMzcxNDU5MC8x
>NDMzNzE0NTkwLzUxNSBmb3JrdG9vbXVjaCAxNDMzNzE0NTkwLzE0MzM3MTQ1OTAvMTQzMzcxNDU5
>MCBhbGxvYyAyNy8xNi8wIGNyZWF0IDU3MS80MzAvNDMwIGxvY2sgMy8zLzApCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzE0NjIyLzUxMy8wICh0ZXN0czogcmVhZCAxNDMzNzE0NjIy
>LzE1MzEvNiBueHJlYWQgMTQzMzcxNDYyMi8xNDMzNzE0NjIyLzQxNjIgdHJ5ZXhjZXB0IDE3LzMv
>MiBmb3JrIDE0MzM3MTQ2MjIvMTQzMzcxNDYyMi81NDcgZm9ya3Rvb211Y2ggMTQzMzcxNDYyMi8x
>NDMzNzE0NjIyLzE0MzM3MTQ2MjIgYWxsb2MgNDgvMTYvNiBjcmVhdCA2MDMvNDYyLzQ2MiBsb2Nr
>IDYvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDY0OS81NDAvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNDY0OS8xNTU4LzE0IG54cmVhZCAxNDMzNzE0NjQ5LzE0MzM3MTQ2NDkv
>NDE4OSB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE0NjQ5LzE0MzM3MTQ2NDkvNTc0IGZvcmt0
>b29tdWNoIDE0MzM3MTQ2NDkvMTQzMzcxNDY0OS8xNDMzNzE0NjQ5IGFsbG9jIDc1LzE0LzYgY3Jl
>YXQgNjMwLzQ4OS80ODkgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQ2NzgvNTY5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ2NzgvMTU4Ny8xIG54cmVhZCAxNDMz
>NzE0Njc4LzE0MzM3MTQ2NzgvNDIxOCB0cnlleGNlcHQgNS8zLzAgZm9yayAxNDMzNzE0Njc4LzE0
>MzM3MTQ2NzgvNjAzIGZvcmt0b29tdWNoIDE0MzM3MTQ2NzgvMTQzMzcxNDY3OC8xNDMzNzE0Njc4
>IGFsbG9jIDE4LzEvMSBjcmVhdCA2NTkvNTE4LzUxOCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDc2Ny82NTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDc2Ny8x
>NDY4LzEgbnhyZWFkIDE0MzM3MTQ3NjcvMTQzMzcxNDc2Ny80MzA3IHRyeWV4Y2VwdCA0LzIvMCBm
>b3JrIDE0MzM3MTQ3NjcvMTQzMzcxNDc2Ny82OTIgZm9ya3Rvb211Y2ggMTQzMzcxNDc2Ny8xNDMz
>NzE0NzY3LzE0MzM3MTQ3NjcgYWxsb2MgNDQvMy8xIGNyZWF0IDc0OC82MDcvNjA3IGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0ODA2LzY5Ny8wICh0ZXN0czog
>cmVhZCAxNDMzNzE0ODA2LzE1MDcvMjggbnhyZWFkIDE0MzM3MTQ4MDYvMTQzMzcxNDgwNi80MzQ2
>IHRyeWV4Y2VwdCAzNC8xLzEgZm9yayAxNDMzNzE0ODA2LzE0MzM3MTQ4MDYvNzMxIGZvcmt0b29t
>dWNoIDE0MzM3MTQ4MDYvMTQzMzcxNDgwNi8xNDMzNzE0ODA2IGFsbG9jIDQyLzEzLzQgY3JlYXQg
>Nzg3LzY0Ni82NDYgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTQ4MjcvNjY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ4MjcvMTQ5NC8xNSBueHJlYWQgMTQzMzcx
>NDgyNy8xNDMzNzE0ODI3LzQzNjcgdHJ5ZXhjZXB0IDQzLzMvMSBmb3JrIDE0MzM3MTQ4MjcvMTQz
>MzcxNDgyNy83NTIgZm9ya3Rvb211Y2ggMTQzMzcxNDgyNy8xNDMzNzE0ODI3LzE0MzM3MTQ4Mjcg
>YWxsb2MgNDkvMTEvNCBjcmVhdCA4MDgvNjY3LzY2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDg1My82OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDg1My8x
>NTIwLzEzIG54cmVhZCAxNDMzNzE0ODUzLzE0MzM3MTQ4NTMvNDM5MyB0cnlleGNlcHQgMzUvMi8w
>IGZvcmsgMTQzMzcxNDg1My8xNDMzNzE0ODUzLzc3OCBmb3JrdG9vbXVjaCAxNDMzNzE0ODUzLzE0
>MzM3MTQ4NTMvMTQzMzcxNDg1MyBhbGxvYyA3NS81LzEgY3JlYXQgODM0LzY5My82OTMgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ4OTUvNzM1LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTQ4OTUvMTU2Mi8xNSBueHJlYWQgMTQzMzcxNDg5NS8xNDMzNzE0ODk1LzQ0
>MzUgdHJ5ZXhjZXB0IDM4LzIvMSBmb3JrIDE0MzM3MTQ4OTUvMTQzMzcxNDg5NS84MjAgZm9ya3Rv
>b211Y2ggMTQzMzcxNDg5NS8xNDMzNzE0ODk1LzE0MzM3MTQ4OTUgYWxsb2MgNDMvMTUvNCBjcmVh
>dCA4NzYvNzM1LzczNSBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNDkzNy83NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDkzNy8xNjA0LzEgbnhyZWFkIDE0MzM3
>MTQ5MzcvMTQzMzcxNDkzNy80NDc3IHRyeWV4Y2VwdCA1NC8zLzAgZm9yayAxNDMzNzE0OTM3LzE0
>MzM3MTQ5MzcvODYyIGZvcmt0b29tdWNoIDE0MzM3MTQ5MzcvMTQzMzcxNDkzNy8xNDMzNzE0OTM3
>IGFsbG9jIDQ2LzEwLzEgY3JlYXQgOTE4Lzc3Ny83NzcgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTQ5NzYvODE2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ5NzYv
>MTY0My82IG54cmVhZCAxNDMzNzE0OTc2LzE0MzM3MTQ5NzYvNDUxNiB0cnlleGNlcHQgNS8yLzEg
>Zm9yayAxNDMzNzE0OTc2LzE0MzM3MTQ5NzYvOTAxIGZvcmt0b29tdWNoIDE0MzM3MTQ5NzYvMTQz
>MzcxNDk3Ni8xNDMzNzE0OTc2IGFsbG9jIDg1LzIxLzAgY3JlYXQgOTU3LzgxNi84MTYgbG9jayA1
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTUwMDAvODQwLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTUwMDAvMTY2Ny81IG54cmVhZCAxNDMzNzE1MDAwLzE0MzM3MTUwMDAvNDU0
>MCB0cnlleGNlcHQgMjAvMi8xIGZvcmsgMTQzMzcxNTAwMC8xNDMzNzE1MDAwLzkyNSBmb3JrdG9v
>bXVjaCAxNDMzNzE1MDAwLzE0MzM3MTUwMDAvMTQzMzcxNTAwMCBhbGxvYyA0MS85LzAgY3JlYXQg
>OTgxLzg0MC84NDAgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTUwMjcvODY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUwMjcvMTY5NC8xIG54cmVhZCAxNDMzNzE1
>MDI3LzE0MzM3MTUwMjcvNDU2NyB0cnlleGNlcHQgNDUvMC8wIGZvcmsgMTQzMzcxNTAyNy8xNDMz
>NzE1MDI3Lzk1MiBmb3JrdG9vbXVjaCAxNDMzNzE1MDI3LzE0MzM3MTUwMjcvMTQzMzcxNTAyNyBh
>bGxvYyA0Ni8xMC8xIGNyZWF0IDEwMDgvODY3Lzg2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTA1Mi84OTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTA1Mi8x
>NzE5LzUgbnhyZWFkIDE0MzM3MTUwNTIvMTQzMzcxNTA1Mi80NTkyIHRyeWV4Y2VwdCAzLzIvMCBm
>b3JrIDE0MzM3MTUwNTIvMTQzMzcxNTA1Mi85NzcgZm9ya3Rvb211Y2ggMTQzMzcxNTA1Mi8xNDMz
>NzE1MDUyLzE0MzM3MTUwNTIgYWxsb2MgMjIvMS8xIGNyZWF0IDEwMzMvODkyLzg5MiBsb2NrIDEv
>MS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTA4NS85MjUvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxNTA4NS8xNzUyLzIgbnhyZWFkIDE0MzM3MTUwODUvMTQzMzcxNTA4NS80NjI1
>IHRyeWV4Y2VwdCAxMC8xLzEgZm9yayAxNDMzNzE1MDg1LzE0MzM3MTUwODUvMTAxMCBmb3JrdG9v
>bXVjaCAxNDMzNzE1MDg1LzE0MzM3MTUwODUvMTQzMzcxNTA4NSBhbGxvYyA0My8xMS8yIGNyZWF0
>IDEwNjYvOTI1LzkyNSBsb2NrIDIvMi8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNTEyNy85NjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTEyNy8xNzk0LzM4IG54cmVhZCAxNDMz
>NzE1MTI3LzE0MzM3MTUxMjcvNDY2NyB0cnlleGNlcHQgNTIvNC8wIGZvcmsgMTQzMzcxNTEyNy8x
>NDMzNzE1MTI3LzEwNTIgZm9ya3Rvb211Y2ggMTQzMzcxNTEyNy8xNDMzNzE1MTI3LzE0MzM3MTUx
>MjcgYWxsb2MgMjcvOC8zIGNyZWF0IDExMDgvOTY3Lzk2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTE2Ny8xMDA3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUx
>NjcvMTgzNC8xMSBueHJlYWQgMTQzMzcxNTE2Ny8xNDMzNzE1MTY3LzQ3MDcgdHJ5ZXhjZXB0IDU2
>LzUvMSBmb3JrIDE0MzM3MTUxNjcvMTQzMzcxNTE2Ny8xMDkyIGZvcmt0b29tdWNoIDE0MzM3MTUx
>NjcvMTQzMzcxNTE2Ny8xNDMzNzE1MTY3IGFsbG9jIDU5LzEzLzQgY3JlYXQgMTE0OC8xMDA3LzEw
>MDcgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTUyMzYvMTA3
>Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE1MjM2LzE5MDMvMyBueHJlYWQgMTQzMzcxNTIzNi8xNDMz
>NzE1MjM2LzQ3NzYgdHJ5ZXhjZXB0IDUwLzIvMSBmb3JrIDE0MzM3MTUyMzYvMTQzMzcxNTIzNi8x
>NyBmb3JrdG9vbXVjaCAxNDMzNzE1MjM2LzE0MzM3MTUyMzYvMTQzMzcxNTIzNiBhbGxvYyA1Mi85
>LzMgY3JlYXQgMTIxNy8xMDc2LzEwNzYgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTUyNTgvMTA5OC8wICh0ZXN0czogcmVhZCAxNDMzNzE1MjU4LzE5MjUvOCBu
>eHJlYWQgMTQzMzcxNTI1OC8xNDMzNzE1MjU4LzQ3OTggdHJ5ZXhjZXB0IDMwLzMvMCBmb3JrIDE0
>MzM3MTUyNTgvMTQzMzcxNTI1OC8yMSBmb3JrdG9vbXVjaCAxNDMzNzE1MjU4LzE0MzM3MTUyNTgv
>MTQzMzcxNTI1OCBhbGxvYyA0OS8xMi8yIGNyZWF0IDEyMzkvMTA5OC8xMDk4IGxvY2sgMS8xLzEp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1Mjk2LzExMzYvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNTI5Ni8xOTYzLzEyIG54cmVhZCAxNDMzNzE1Mjk2LzE0MzM3MTUyOTYvNDgzNiB0
>cnlleGNlcHQgNi8yLzIgZm9yayAxNDMzNzE1Mjk2LzE0MzM3MTUyOTYvNTkgZm9ya3Rvb211Y2gg
>MTQzMzcxNTI5Ni8xNDMzNzE1Mjk2LzE0MzM3MTUyOTYgYWxsb2MgNDYvNy83IGNyZWF0IDEyNzcv
>MTEzNi8xMTM2IGxvY2sgNy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1
>MzI2LzExNjYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTMyNi8xOTkzLzE5IG54cmVhZCAxNDMzNzE1
>MzI2LzE0MzM3MTUzMjYvNDg2NiB0cnlleGNlcHQgNy8yLzEgZm9yayAxNDMzNzE1MzI2LzE0MzM3
>MTUzMjYvODkgZm9ya3Rvb211Y2ggMTQzMzcxNTMyNi8xNDMzNzE1MzI2LzE0MzM3MTUzMjYgYWxs
>b2MgMzcvMTAvNiBjcmVhdCAxMzA3LzExNjYvMTE2NiBsb2NrIDYvNi8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTM0OS8xMTg5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUzNDkv
>MjAxNi8yMyBueHJlYWQgMTQzMzcxNTM0OS8xNDMzNzE1MzQ5LzQ4ODkgdHJ5ZXhjZXB0IDMwLzEv
>MSBmb3JrIDE0MzM3MTUzNDkvMTQzMzcxNTM0OS8xMTIgZm9ya3Rvb211Y2ggMTQzMzcxNTM0OS8x
>NDMzNzE1MzQ5LzE0MzM3MTUzNDkgYWxsb2MgMjkvMTAvNSBjcmVhdCAxMzMwLzExODkvMTE4OSBs
>b2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTM4NS8xMjI1LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTUzODUvMjA1Mi83IG54cmVhZCAxNDMzNzE1Mzg1LzE0MzM3MTUz
>ODUvNDkyNSB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzE1Mzg1LzE0MzM3MTUzODUvMTQ4IGZv
>cmt0b29tdWNoIDE0MzM3MTUzODUvMTQzMzcxNTM4NS8xNDMzNzE1Mzg1IGFsbG9jIDM2LzcvNyBj
>cmVhdCAxMzY2LzEyMjUvMTIyNSBsb2NrIDcvNy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxNTQxMS8xMjUxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTU0MTEvMjA3OC8xIG54cmVh
>ZCAxNDMzNzE1NDExLzE0MzM3MTU0MTEvNDk1MSB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE1
>NDExLzE0MzM3MTU0MTEvMTc0IGZvcmt0b29tdWNoIDE0MzM3MTU0MTEvMTQzMzcxNTQxMS8xNDMz
>NzE1NDExIGFsbG9jIDM4LzkvMSBjcmVhdCAxMzkyLzEyNTEvMTI1MSBsb2NrIDEvMS8xKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTQ0Ni8xMjg2LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTU0NDYvMjExMy8xIG54cmVhZCAxNDMzNzE1NDQ2LzE0MzM3MTU0NDYvNDk4NiB0cnlleGNl
>cHQgNC8wLzAgZm9yayAxNDMzNzE1NDQ2LzE0MzM3MTU0NDYvMjA5IGZvcmt0b29tdWNoIDE0MzM3
>MTU0NDYvMTQzMzcxNTQ0Ni8xNDMzNzE1NDQ2IGFsbG9jIDM2LzE1LzEgY3JlYXQgMTQyNy8xMjg2
>LzEyODYgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTU0NzAv
>MTMxMC8wICh0ZXN0czogcmVhZCAxNDMzNzE1NDcwLzIxMzcvNCBueHJlYWQgMTQzMzcxNTQ3MC8x
>NDMzNzE1NDcwLzUwMTAgdHJ5ZXhjZXB0IDIxLzIvMSBmb3JrIDE0MzM3MTU0NzAvMTQzMzcxNTQ3
>MC8yMzMgZm9ya3Rvb211Y2ggMTQzMzcxNTQ3MC8xNDMzNzE1NDcwLzE0MzM3MTU0NzAgYWxsb2Mg
>MjUvNy8wIGNyZWF0IDE0NTEvMTMxMC8xMzEwIGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE1NDk4LzEzMzgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTQ5OC8yMTY1
>LzIzIG54cmVhZCAxNDMzNzE1NDk4LzE0MzM3MTU0OTgvNTAzOCB0cnlleGNlcHQgMjQvMi8xIGZv
>cmsgMTQzMzcxNTQ5OC8xNDMzNzE1NDk4LzI2MSBmb3JrdG9vbXVjaCAxNDMzNzE1NDk4LzE0MzM3
>MTU0OTgvMTQzMzcxNTQ5OCBhbGxvYyAzNS8xNi80IGNyZWF0IDE0NzkvMTMzOC8xMzM4IGxvY2sg
>NC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NTM0LzEzNzQvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNTUzNC8yMjAxLzEgbnhyZWFkIDE0MzM3MTU1MzQvMTQzMzcxNTUzNC81
>MDc0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTU1MzQvMTQzMzcxNTUzNC8yOTcgZm9ya3Rv
>b211Y2ggMTQzMzcxNTUzNC8xNDMzNzE1NTM0LzE0MzM3MTU1MzQgYWxsb2MgNTIvNi8xIGNyZWF0
>IDE1MTUvMTM3NC8xMzc0IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE1NTU2LzEzOTYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTU1Ni8yMjIzLzEwIG54cmVhZCAx
>NDMzNzE1NTU2LzE0MzM3MTU1NTYvNTA5NiB0cnlleGNlcHQgMjAvMS8wIGZvcmsgMTQzMzcxNTU1
>Ni8xNDMzNzE1NTU2LzMxOSBmb3JrdG9vbXVjaCAxNDMzNzE1NTU2LzE0MzM3MTU1NTYvMTQzMzcx
>NTU1NiBhbGxvYyAyOC8xMC8yIGNyZWF0IDE1MzcvMTM5Ni8xMzk2IGxvY2sgMi8yLzIpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NTgwLzE0MjAvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNTU4MC8yMjQ3LzkgbnhyZWFkIDE0MzM3MTU1ODAvMTQzMzcxNTU4MC8xIHRyeWV4Y2VwdCAx
>NC8yLzAgZm9yayAxNDMzNzE1NTgwLzE0MzM3MTU1ODAvMzQzIGZvcmt0b29tdWNoIDE0MzM3MTU1
>ODAvMTQzMzcxNTU4MC8xNDMzNzE1NTgwIGFsbG9jIDI2LzkvMSBjcmVhdCAxNTYxLzE0MjAvMTQy
>MCBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTY0MC8xNDgw
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTU2NDAvMjMwNy8yIG54cmVhZCAxNDMzNzE1NjQwLzE0MzM3
>MTU2NDAvNjEgdHJ5ZXhjZXB0IDYvMy8wIGZvcmsgMTQzMzcxNTY0MC8xNDMzNzE1NjQwLzQwMyBm
>b3JrdG9vbXVjaCAxNDMzNzE1NjQwLzE0MzM3MTU2NDAvMTQzMzcxNTY0MCBhbGxvYyAyMi8xMC8y
>IGNyZWF0IDE2MjEvMTQ4MC8xNDgwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzE1NjgwLzE1MjAvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTY4MC8yMzQ3LzEzIG54
>cmVhZCAxNDMzNzE1NjgwLzE0MzM3MTU2ODAvMTAxIHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3
>MTU2ODAvMTQzMzcxNTY4MC80NDMgZm9ya3Rvb211Y2ggMTQzMzcxNTY4MC8xNDMzNzE1NjgwLzE0
>MzM3MTU2ODAgYWxsb2MgMjYvNy8yIGNyZWF0IDE2NjEvMTUyMC8xNTIwIGxvY2sgMi8yLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NzQ0LzE1ODQvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNTc0NC8yNDExLzEyIG54cmVhZCAxNDMzNzE1NzQ0LzE0MzM3MTU3NDQvMTY1IHRyeWV4
>Y2VwdCA2LzMvMCBmb3JrIDE0MzM3MTU3NDQvMTQzMzcxNTc0NC81MDcgZm9ya3Rvb211Y2ggMTQz
>MzcxNTc0NC8xNDMzNzE1NzQ0LzE0MzM3MTU3NDQgYWxsb2MgMjgvNy81IGNyZWF0IDE3MjUvMTU4
>NC8xNTg0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1Nzk5
>LzE2MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTc5OS8yNDY2LzM3IG54cmVhZCAxNDMzNzE1Nzk5
>LzE0MzM3MTU3OTkvMjIwIHRyeWV4Y2VwdCAzMC8yLzEgZm9yayAxNDMzNzE1Nzk5LzE0MzM3MTU3
>OTkvNTYyIGZvcmt0b29tdWNoIDE0MzM3MTU3OTkvMTQzMzcxNTc5OS8xNDMzNzE1Nzk5IGFsbG9j
>IDUyLzIwLzAgY3JlYXQgMTc4MC8xNjM5LzE2MzkgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTU4MzAvMTY3MC8wICh0ZXN0czogcmVhZCAxNDMzNzE1ODMwLzI0
>OTcvNSBueHJlYWQgMTQzMzcxNTgzMC8xNDMzNzE1ODMwLzI1MSB0cnlleGNlcHQgNS8yLzAgZm9y
>ayAxNDMzNzE1ODMwLzE0MzM3MTU4MzAvNTkzIGZvcmt0b29tdWNoIDE0MzM3MTU4MzAvMTQzMzcx
>NTgzMC8xNDMzNzE1ODMwIGFsbG9jIDQxLzExLzEgY3JlYXQgMTgxMS8xNjcwLzE2NzAgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTU4ODMvMTcyMy8wICh0ZXN0
>czogcmVhZCAxNDMzNzE1ODgzLzI1NTAvMTEgbnhyZWFkIDE0MzM3MTU4ODMvMTQzMzcxNTg4My8z
>MDQgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQzMzcxNTg4My8xNDMzNzE1ODgzLzY0NiBmb3JrdG9v
>bXVjaCAxNDMzNzE1ODgzLzE0MzM3MTU4ODMvMTQzMzcxNTg4MyBhbGxvYyA0Mi8xNy82IGNyZWF0
>IDE4NjQvMTcyMy8xNzIzIGxvY2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE1OTEzLzE3NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTkxMy8yNTgwLzEwIG54cmVhZCAx
>NDMzNzE1OTEzLzE0MzM3MTU5MTMvMzM0IHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0MzM3MTU5MTMv
>MTQzMzcxNTkxMy82NzYgZm9ya3Rvb211Y2ggMTQzMzcxNTkxMy8xNDMzNzE1OTEzLzE0MzM3MTU5
>MTMgYWxsb2MgMjAvMTAvNyBjcmVhdCAxODk0LzE3NTMvMTc1MyBsb2NrIDYvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTkzNy8xNzc3LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTU5MzcvMjYwNC8yNCBueHJlYWQgMTQzMzcxNTkzNy8xNDMzNzE1OTM3LzM1OCB0cnlleGNlcHQg
>MTAvMi8xIGZvcmsgMTQzMzcxNTkzNy8xNDMzNzE1OTM3LzcwMCBmb3JrdG9vbXVjaCAxNDMzNzE1
>OTM3LzE0MzM3MTU5MzcvMTQzMzcxNTkzNyBhbGxvYyAzOS8yNC85IGNyZWF0IDE5MTgvMTc3Ny8x
>Nzc3IGxvY2sgOS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1OTYzLzE4
>MDMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTk2My8yNjMwLzEyIG54cmVhZCAxNDMzNzE1OTYzLzE0
>MzM3MTU5NjMvMzg0IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MTU5NjMvMTQzMzcxNTk2My83
>MjYgZm9ya3Rvb211Y2ggMTQzMzcxNTk2My8xNDMzNzE1OTYzLzE0MzM3MTU5NjMgYWxsb2MgNjAv
>MTgvMyBjcmVhdCAxOTQ0LzE4MDMvMTgwMyBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxNTk5Ny8xODM3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTU5OTcvMjY2NC8x
>IG54cmVhZCAxNDMzNzE1OTk3LzE0MzM3MTU5OTcvNDE4IHRyeWV4Y2VwdCAzNS8yLzAgZm9yayAx
>NDMzNzE1OTk3LzE0MzM3MTU5OTcvNzYwIGZvcmt0b29tdWNoIDE0MzM3MTU5OTcvMTQzMzcxNTk5
>Ny8xNDMzNzE1OTk3IGFsbG9jIDM0LzEwLzEgY3JlYXQgMTk3OC8xODM3LzE4MzcgbG9jayAxLzEv
>MSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYwMjcvMTg2Ny8wICh0ZXN0czog
>cmVhZCAxNDMzNzE2MDI3LzI2OTQvNyBueHJlYWQgMTQzMzcxNjAyNy8xNDMzNzE2MDI3LzQ0OCB0
>cnlleGNlcHQgOC8yLzAgZm9yayAxNDMzNzE2MDI3LzE0MzM3MTYwMjcvNzkwIGZvcmt0b29tdWNo
>IDE0MzM3MTYwMjcvMTQzMzcxNjAyNy8xNDMzNzE2MDI3IGFsbG9jIDQ1LzEyLzEgY3JlYXQgMjAw
>OC8xODY3LzE4NjcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTYwNTYvMTg5Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE2MDU2LzI3MjMvNSBueHJlYWQgMTQzMzcx
>NjA1Ni8xNDMzNzE2MDU2LzQ3NyB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzE2MDU2LzE0MzM3
>MTYwNTYvODE5IGZvcmt0b29tdWNoIDE0MzM3MTYwNTYvMTQzMzcxNjA1Ni8xNDMzNzE2MDU2IGFs
>bG9jIDUxLzEwLzUgY3JlYXQgMjAzNy8xODk2LzE4OTYgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTYwODkvMTkyOS8wICh0ZXN0czogcmVhZCAxNDMzNzE2MDg5
>LzI3NTYvMjcgbnhyZWFkIDE0MzM3MTYwODkvMTQzMzcxNjA4OS81MTAgdHJ5ZXhjZXB0IDE5LzEv
>MSBmb3JrIDE0MzM3MTYwODkvMTQzMzcxNjA4OS84NTIgZm9ya3Rvb211Y2ggMTQzMzcxNjA4OS8x
>NDMzNzE2MDg5LzE0MzM3MTYwODkgYWxsb2MgNDMvMTgvMCBjcmVhdCAyMDcwLzE5MjkvMTkyOSBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjEwOS8xOTQ5LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTYxMDkvMjc3Ni80NyBueHJlYWQgMTQzMzcxNjEwOS8xNDMzNzE2
>MTA5LzUzMCB0cnlleGNlcHQgMzkvMC8wIGZvcmsgMTQzMzcxNjEwOS8xNDMzNzE2MTA5Lzg3MiBm
>b3JrdG9vbXVjaCAxNDMzNzE2MTA5LzE0MzM3MTYxMDkvMTQzMzcxNjEwOSBhbGxvYyAyMC8xMy8y
>IGNyZWF0IDIwOTAvMTk0OS8xOTQ5IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzE2MTMyLzE5NzIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjEzMi8yNzk5LzEgbnhy
>ZWFkIDE0MzM3MTYxMzIvMTQzMzcxNjEzMi81NTMgdHJ5ZXhjZXB0IDMvMi8wIGZvcmsgMTQzMzcx
>NjEzMi8xNDMzNzE2MTMyLzg5NSBmb3JrdG9vbXVjaCAxNDMzNzE2MTMyLzE0MzM3MTYxMzIvMTQz
>MzcxNjEzMiBhbGxvYyAyMC82LzEgY3JlYXQgMjExMy8xOTcyLzE5NzIgbG9jayAxLzEvMSkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYxNjEvMjAwMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzE2MTYxLzI4MjgvOSBueHJlYWQgMTQzMzcxNjE2MS8xNDMzNzE2MTYxLzU4MiB0cnlleGNl
>cHQgNS8yLzEgZm9yayAxNDMzNzE2MTYxLzE0MzM3MTYxNjEvOTI0IGZvcmt0b29tdWNoIDE0MzM3
>MTYxNjEvMTQzMzcxNjE2MS8xNDMzNzE2MTYxIGFsbG9jIDM1LzE0LzYgY3JlYXQgMjE0Mi8yMDAx
>LzIwMDEgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYxODcv
>MjAyNy8wICh0ZXN0czogcmVhZCAxNDMzNzE2MTg3LzI4NTQvNSBueHJlYWQgMTQzMzcxNjE4Ny8x
>NDMzNzE2MTg3LzYwOCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE2MTg3LzE0MzM3MTYxODcv
>OTUwIGZvcmt0b29tdWNoIDE0MzM3MTYxODcvMTQzMzcxNjE4Ny8xNDMzNzE2MTg3IGFsbG9jIDQ1
>LzEvMSBjcmVhdCAyMTY4LzIwMjcvMjAyNyBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxNjIyMS8yMDYxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTYyMjEvMjg4OC8z
>IG54cmVhZCAxNDMzNzE2MjIxLzE0MzM3MTYyMjEvNjQyIHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0
>MzM3MTYyMjEvMTQzMzcxNjIyMS85ODQgZm9ya3Rvb211Y2ggMTQzMzcxNjIyMS8xNDMzNzE2MjIx
>LzE0MzM3MTYyMjEgYWxsb2MgNzkvOS8zIGNyZWF0IDIyMDIvMjA2MS8yMDYxIGxvY2sgMy8zLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2MjQ1LzIwODUvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNjI0NS8yOTEyLzEgbnhyZWFkIDE0MzM3MTYyNDUvMTQzMzcxNjI0NS82NjYgdHJ5
>ZXhjZXB0IDI1LzIvMCBmb3JrIDE0MzM3MTYyNDUvMTQzMzcxNjI0NS8xMDA4IGZvcmt0b29tdWNo
>IDE0MzM3MTYyNDUvMTQzMzcxNjI0NS8xNDMzNzE2MjQ1IGFsbG9jIDUzLzE0LzEgY3JlYXQgMjIy
>Ni8yMDg1LzIwODUgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTYyODMvMjEyMy8wICh0ZXN0czogcmVhZCAxNDMzNzE2MjgzLzI5NTAvMjIgbnhyZWFkIDE0MzM3
>MTYyODMvMTQzMzcxNjI4My83MDQgdHJ5ZXhjZXB0IDQ5LzMvMCBmb3JrIDE0MzM3MTYyODMvMTQz
>MzcxNjI4My8xMDQ2IGZvcmt0b29tdWNoIDE0MzM3MTYyODMvMTQzMzcxNjI4My8xNDMzNzE2Mjgz
>IGFsbG9jIDMxLzkvMSBjcmVhdCAyMjY0LzIxMjMvMjEyMyBsb2NrIDEvMS8xKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjMxMi8yMTUyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTYz
>MTIvMjk3OS81MSBueHJlYWQgMTQzMzcxNjMxMi8xNDMzNzE2MzEyLzczMyB0cnlleGNlcHQgMjMv
>MS8xIGZvcmsgMTQzMzcxNjMxMi8xNDMzNzE2MzEyLzEyIGZvcmt0b29tdWNoIDE0MzM3MTYzMTIv
>MTQzMzcxNjMxMi8xNDMzNzE2MzEyIGFsbG9jIDM4LzkvNCBjcmVhdCAyMjkzLzIxNTIvMjE1MiBs
>b2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjM0MS8yMTgxLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTYzNDEvMzAwOC81IG54cmVhZCAxNDMzNzE2MzQxLzE0MzM3MTYz
>NDEvNzYyIHRyeWV4Y2VwdCA0LzIvMiBmb3JrIDE0MzM3MTYzNDEvMTQzMzcxNjM0MS8yNyBmb3Jr
>dG9vbXVjaCAxNDMzNzE2MzQxLzE0MzM3MTYzNDEvMTQzMzcxNjM0MSBhbGxvYyA0Mi8xMS81IGNy
>ZWF0IDIzMjIvMjE4MS8xMSBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxNjM3Ni8yMjE2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTYzNzYvMzA0My8yNCBueHJlYWQg
>MTQzMzcxNjM3Ni8xNDMzNzE2Mzc2Lzc5NyB0cnlleGNlcHQgNS8yLzIgZm9yayAxNDMzNzE2Mzc2
>LzE0MzM3MTYzNzYvNjIgZm9ya3Rvb211Y2ggMTQzMzcxNjM3Ni8xNDMzNzE2Mzc2LzE0MzM3MTYz
>NzYgYWxsb2MgNzcvMTEvNiBjcmVhdCAyMzU3LzIyMTYvNDYgbG9jayA1LzUvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY0MDYvMjI0Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE2
>NDA2LzMwNzMvNSBueHJlYWQgMTQzMzcxNjQwNi8xNDMzNzE2NDA2LzgyNyB0cnlleGNlcHQgNC8y
>LzIgZm9yayAxNDMzNzE2NDA2LzE0MzM3MTY0MDYvOTIgZm9ya3Rvb211Y2ggMTQzMzcxNjQwNi8x
>NDMzNzE2NDA2LzE0MzM3MTY0MDYgYWxsb2MgMTA3LzEwLzUgY3JlYXQgMjM4Ny8yMjQ2Lzc2IGxv
>Y2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NDI5LzIyNjkvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxNjQyOS8zMDk2LzIgbnhyZWFkIDE0MzM3MTY0MjkvMTQzMzcxNjQy
>OS84NTAgdHJ5ZXhjZXB0IDIvMi8xIGZvcmsgMTQzMzcxNjQyOS8xNDMzNzE2NDI5LzExNSBmb3Jr
>dG9vbXVjaCAxNDMzNzE2NDI5LzE0MzM3MTY0MjkvMTQzMzcxNjQyOSBhbGxvYyA0MS83LzIgY3Jl
>YXQgMjQxMC8yMjY5Lzk5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE2NDczLzIzMTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjQ3My8zMTQwLzM1IG54cmVhZCAx
>NDMzNzE2NDczLzE0MzM3MTY0NzMvODk0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTY0NzMv
>MTQzMzcxNjQ3My8xNTkgZm9ya3Rvb211Y2ggMTQzMzcxNjQ3My8xNDMzNzE2NDczLzE0MzM3MTY0
>NzMgYWxsb2MgNzcvMTIvMSBjcmVhdCAyNDU0LzIzMTMvMTQzIGxvY2sgMS8xLzEpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NTAwLzIzNDAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>NjUwMC8zMTY3LzQgbnhyZWFkIDE0MzM3MTY1MDAvMTQzMzcxNjUwMC85MjEgdHJ5ZXhjZXB0IDcv
>NS8xIGZvcmsgMTQzMzcxNjUwMC8xNDMzNzE2NTAwLzE4NiBmb3JrdG9vbXVjaCAxNDMzNzE2NTAw
>LzE0MzM3MTY1MDAvMTQzMzcxNjUwMCBhbGxvYyAyMy82LzAgY3JlYXQgMjQ4MS8yMzQwLzE3MCBs
>b2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjUyNi8yMzY2LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTY1MjYvMTc2OC8xIG54cmVhZCAxNDMzNzE2NTI2LzE0MzM3MTY1
>MjYvOTQ3IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAxNDMzNzE2NTI2LzE0MzM3MTY1MjYvMjEyIGZv
>cmt0b29tdWNoIDE0MzM3MTY1MjYvMTQzMzcxNjUyNi8xNDMzNzE2NTI2IGFsbG9jIDMyLzIxLzEg
>Y3JlYXQgMjUwNy8yMzY2LzE5NiBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxNjU2OS8yNDA5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY1NjkvMTgxMS8xOCBueHJl
>YWQgMTQzMzcxNjU2OS8xNDMzNzE2NTY5Lzk5MCB0cnlleGNlcHQgMTkvMTAvMSBmb3JrIDE0MzM3
>MTY1NjkvMTQzMzcxNjU2OS8yNTUgZm9ya3Rvb211Y2ggMTQzMzcxNjU2OS8xNDMzNzE2NTY5LzE0
>MzM3MTY1NjkgYWxsb2MgMzQvMTYvNCBjcmVhdCAyNTUwLzI0MDkvMjM5IGxvY2sgNC80LzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NTkwLzI0MzAvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNjU5MC8xODMyLzIwIG54cmVhZCAxNDMzNzE2NTkwLzE0MzM3MTY1OTAvMTAxMSB0cnll
>eGNlcHQgNDAvNC8xIGZvcmsgMTQzMzcxNjU5MC8xNDMzNzE2NTkwLzI3NiBmb3JrdG9vbXVjaCAx
>NDMzNzE2NTkwLzE0MzM3MTY1OTAvMTQzMzcxNjU5MCBhbGxvYyA0NS8yMC8zIGNyZWF0IDI1NzEv
>MjQzMC8yNjAgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY2
>MDgvMjQ0OC8wICh0ZXN0czogcmVhZCAxNDMzNzE2NjA4LzE4NTAvMTggbnhyZWFkIDE0MzM3MTY2
>MDgvMTQzMzcxNjYwOC8xMDI5IHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzE2NjA4LzE0MzM3
>MTY2MDgvMjk0IGZvcmt0b29tdWNoIDE0MzM3MTY2MDgvMTQzMzcxNjYwOC8xNDMzNzE2NjA4IGFs
>bG9jIDUwLzE3LzUgY3JlYXQgMjU4OS8yNDQ4LzI3OCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjYzOC8yNDc4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY2Mzgv
>MTg4MC82IG54cmVhZCAxNDMzNzE2NjM4LzE0MzM3MTY2MzgvMTA1OSB0cnlleGNlcHQgMy8yLzAg
>Zm9yayAxNDMzNzE2NjM4LzE0MzM3MTY2MzgvMzI0IGZvcmt0b29tdWNoIDE0MzM3MTY2MzgvMTQz
>MzcxNjYzOC8xNDMzNzE2NjM4IGFsbG9jIDQ3LzYvMSBjcmVhdCAyNjE5LzI0NzgvMzA4IGxvY2sg
>MC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2Njc2LzI1MTYvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNjY3Ni8xOTE4LzkgbnhyZWFkIDE0MzM3MTY2NzYvMTQzMzcxNjY3Ni8x
>MDk3IHRyeWV4Y2VwdCAyLzEvMSBmb3JrIDE0MzM3MTY2NzYvMTQzMzcxNjY3Ni8zNjIgZm9ya3Rv
>b211Y2ggMTQzMzcxNjY3Ni8xNDMzNzE2Njc2LzE0MzM3MTY2NzYgYWxsb2MgMjkvMi8yIGNyZWF0
>IDI2NTcvMjUxNi8zNDYgbG9jayAyLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTY3MDMvMjU0My8wICh0ZXN0czogcmVhZCAxNDMzNzE2NzAzLzE5NDUvMjEgbnhyZWFkIDE0
>MzM3MTY3MDMvMTQzMzcxNjcwMy8xMTI0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTY3MDMv
>MTQzMzcxNjcwMy8zODkgZm9ya3Rvb211Y2ggMTQzMzcxNjcwMy8xNDMzNzE2NzAzLzE0MzM3MTY3
>MDMgYWxsb2MgNDUvMy8yIGNyZWF0IDI2ODQvMjU0My8zNzMgbG9jayAyLzIvMSkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY3MzIvMjU3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE2
>NzMyLzE5NzQvNCBueHJlYWQgMTQzMzcxNjczMi8xNDMzNzE2NzMyLzExNTMgdHJ5ZXhjZXB0IDEy
>LzEvMSBmb3JrIDE0MzM3MTY3MzIvMTQzMzcxNjczMi80MTggZm9ya3Rvb211Y2ggMTQzMzcxNjcz
>Mi8xNDMzNzE2NzMyLzE0MzM3MTY3MzIgYWxsb2MgNzQvMTMvNCBjcmVhdCAyNzEzLzI1NzIvNDAy
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NzYxLzI2MDEv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxNjc2MS8yMDAzLzE3IG54cmVhZCAxNDMzNzE2NzYxLzE0MzM3
>MTY3NjEvMTE4MiB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE2NzYxLzE0MzM3MTY3NjEvNDQ3
>IGZvcmt0b29tdWNoIDE0MzM3MTY3NjEvMTQzMzcxNjc2MS8xNDMzNzE2NzYxIGFsbG9jIDEwMy82
>LzEgY3JlYXQgMjc0Mi8yNjAxLzQzMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxNjc4NS8yNjI1LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY3ODUvMjAyNy83IG54
>cmVhZCAxNDMzNzE2Nzg1LzE0MzM3MTY3ODUvMTIwNiB0cnlleGNlcHQgOC8yLzAgZm9yayAxNDMz
>NzE2Nzg1LzE0MzM3MTY3ODUvNDcxIGZvcmt0b29tdWNoIDE0MzM3MTY3ODUvMTQzMzcxNjc4NS8x
>NDMzNzE2Nzg1IGFsbG9jIDg1LzkvMSBjcmVhdCAyNzY2LzI2MjUvNDU1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2ODEwLzI2NTAvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNjgxMC8yMDUyLzYgbnhyZWFkIDE0MzM3MTY4MTAvMTQzMzcxNjgxMC8xMjMxIHRyeWV4
>Y2VwdCAzMy8yLzEgZm9yayAxNDMzNzE2ODEwLzE0MzM3MTY4MTAvNDk2IGZvcmt0b29tdWNoIDE0
>MzM3MTY4MTAvMTQzMzcxNjgxMC8xNDMzNzE2ODEwIGFsbG9jIDM0LzIxLzYgY3JlYXQgMjc5MS8y
>NjUwLzQ4MCBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjgz
>NS8yNjc1LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY4MzUvMjA3Ny8yMSBueHJlYWQgMTQzMzcxNjgz
>NS8xNDMzNzE2ODM1LzEyNTYgdHJ5ZXhjZXB0IDQ0LzIvMSBmb3JrIDE0MzM3MTY4MzUvMTQzMzcx
>NjgzNS81MjEgZm9ya3Rvb211Y2ggMTQzMzcxNjgzNS8xNDMzNzE2ODM1LzE0MzM3MTY4MzUgYWxs
>b2MgNDYvMTcvMCBjcmVhdCAyODE2LzI2NzUvNTA1IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE2ODU4LzI2OTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjg1OC8y
>MTAwLzE0IG54cmVhZCAxNDMzNzE2ODU4LzE0MzM3MTY4NTgvMTI3OSB0cnlleGNlcHQgNTUvMi8w
>IGZvcmsgMTQzMzcxNjg1OC8xNDMzNzE2ODU4LzU0NCBmb3JrdG9vbXVjaCAxNDMzNzE2ODU4LzE0
>MzM3MTY4NTgvMTQzMzcxNjg1OCBhbGxvYyA0MC82LzEgY3JlYXQgMjgzOS8yNjk4LzUyOCBsb2Nr
>IDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjg4MC8yNzIwLzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTY4ODAvMjEyMi8zNiBueHJlYWQgMTQzMzcxNjg4MC8xNDMzNzE2ODgw
>LzEzMDEgdHJ5ZXhjZXB0IDEzLzEvMCBmb3JrIDE0MzM3MTY4ODAvMTQzMzcxNjg4MC81NjYgZm9y
>a3Rvb211Y2ggMTQzMzcxNjg4MC8xNDMzNzE2ODgwLzE0MzM3MTY4ODAgYWxsb2MgMzYvMTIvMiBj
>cmVhdCAyODYxLzI3MjAvNTUwIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE2OTEyLzI3NTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjkxMi8yMTU0LzcgbnhyZWFk
>IDE0MzM3MTY5MTIvMTQzMzcxNjkxMi8xMzMzIHRyeWV4Y2VwdCA0NS8zLzAgZm9yayAxNDMzNzE2
>OTEyLzE0MzM3MTY5MTIvNTk4IGZvcmt0b29tdWNoIDE0MzM3MTY5MTIvMTQzMzcxNjkxMi8xNDMz
>NzE2OTEyIGFsbG9jIDE1LzcvMSBjcmVhdCAyODkzLzI3NTIvNTgyIGxvY2sgMS8xLzEpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2OTU3LzI3OTcvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNjk1Ny8yMTk5LzE0IG54cmVhZCAxNDMzNzE2OTU3LzE0MzM3MTY5NTcvMTM3OCB0cnlleGNl
>cHQgMzMvMi8xIGZvcmsgMTQzMzcxNjk1Ny8xNDMzNzE2OTU3LzY0MyBmb3JrdG9vbXVjaCAxNDMz
>NzE2OTU3LzE0MzM3MTY5NTcvMTQzMzcxNjk1NyBhbGxvYyAyNi8xNC8wIGNyZWF0IDI5MzgvMjc5
>Ny82MjcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY5OTAv
>MjgzMC8wICh0ZXN0czogcmVhZCAxNDMzNzE2OTkwLzIyMzIvNDcgbnhyZWFkIDE0MzM3MTY5OTAv
>MTQzMzcxNjk5MC8xNDExIHRyeWV4Y2VwdCA0LzAvMCBmb3JrIDE0MzM3MTY5OTAvMTQzMzcxNjk5
>MC82NzYgZm9ya3Rvb211Y2ggMTQzMzcxNjk5MC8xNDMzNzE2OTkwLzE0MzM3MTY5OTAgYWxsb2Mg
>MzcvNy8yIGNyZWF0IDI5NzEvMjgzMC82NjAgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTcwMjQvMjg2NC8wICh0ZXN0czogcmVhZCAxNDMzNzE3MDI0LzIyNjYv
>NSBueHJlYWQgMTQzMzcxNzAyNC8xNDMzNzE3MDI0LzE0NDUgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsg
>MTQzMzcxNzAyNC8xNDMzNzE3MDI0LzcxMCBmb3JrdG9vbXVjaCAxNDMzNzE3MDI0LzE0MzM3MTcw
>MjQvMTQzMzcxNzAyNCBhbGxvYyAzNi8xMC81IGNyZWF0IDMwMDUvMjg2NC82OTQgbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcwNjAvMjkwMC8wICh0ZXN0czog
>cmVhZCAxNDMzNzE3MDYwLzU1MC8xMyBueHJlYWQgMTQzMzcxNzA2MC8xNDMzNzE3MDYwLzE0ODEg
>dHJ5ZXhjZXB0IDE0LzIvMCBmb3JrIDE0MzM3MTcwNjAvMTQzMzcxNzA2MC83NDYgZm9ya3Rvb211
>Y2ggMTQzMzcxNzA2MC8xNDMzNzE3MDYwLzE0MzM3MTcwNjAgYWxsb2MgNTgvMTMvMSBjcmVhdCAz
>MDQxLzI5MDAvNzMwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzE3MDk0LzI5MzQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzA5NC81ODQvOCBueHJlYWQgMTQzMzcx
>NzA5NC8xNDMzNzE3MDk0LzE1MTUgdHJ5ZXhjZXB0IDQ4LzIvMSBmb3JrIDE0MzM3MTcwOTQvMTQz
>MzcxNzA5NC83ODAgZm9ya3Rvb211Y2ggMTQzMzcxNzA5NC8xNDMzNzE3MDk0LzE0MzM3MTcwOTQg
>YWxsb2MgNjEvNC80IGNyZWF0IDMwNzUvMjkzNC83NjQgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTcxMTIvMjk1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE3MTEy
>LzYwMi82IG54cmVhZCAxNDMzNzE3MTEyLzE0MzM3MTcxMTIvMTUzMyB0cnlleGNlcHQgNTQvMi8x
>IGZvcmsgMTQzMzcxNzExMi8xNDMzNzE3MTEyLzc5OCBmb3JrdG9vbXVjaCAxNDMzNzE3MTEyLzE0
>MzM3MTcxMTIvMTQzMzcxNzExMiBhbGxvYyA3OS8xMi8yIGNyZWF0IDMwOTMvMjk1Mi83ODIgbG9j
>ayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcxMzUvMjk3NS8wICh0
>ZXN0czogcmVhZCAxNDMzNzE3MTM1LzYyNS8xNyBueHJlYWQgMTQzMzcxNzEzNS8xNDMzNzE3MTM1
>LzE1NTYgdHJ5ZXhjZXB0IDExLzMvMCBmb3JrIDE0MzM3MTcxMzUvMTQzMzcxNzEzNS84MjEgZm9y
>a3Rvb211Y2ggMTQzMzcxNzEzNS8xNDMzNzE3MTM1LzE0MzM3MTcxMzUgYWxsb2MgNDEvMTAvMSBj
>cmVhdCAzMTE2LzI5NzUvODA1IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3MTYxLzMwMDEvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzE2MS82NTEvMjIgbnhyZWFk
>IDE0MzM3MTcxNjEvMTQzMzcxNzE2MS8xNTgyIHRyeWV4Y2VwdCA1LzEvMCBmb3JrIDE0MzM3MTcx
>NjEvMTQzMzcxNzE2MS84NDcgZm9ya3Rvb211Y2ggMTQzMzcxNzE2MS8xNDMzNzE3MTYxLzE0MzM3
>MTcxNjEgYWxsb2MgMzYvMTEvMiBjcmVhdCAzMTQyLzMwMDEvODMxIGxvY2sgMS8xLzEpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3MTg2LzMwMjYvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNzE4Ni82NzYvNCBueHJlYWQgMTQzMzcxNzE4Ni8xNDMzNzE3MTg2LzE2MDcgdHJ5ZXhjZXB0
>IDE5LzIvMCBmb3JrIDE0MzM3MTcxODYvMTQzMzcxNzE4Ni84NzIgZm9ya3Rvb211Y2ggMTQzMzcx
>NzE4Ni8xNDMzNzE3MTg2LzE0MzM3MTcxODYgYWxsb2MgNTQvNC8xIGNyZWF0IDMxNjcvMzAyNi84
>NTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcyMTUvMzA1
>NS8wICh0ZXN0czogcmVhZCAxNDMzNzE3MjE1LzcwNS8yMCBueHJlYWQgMTQzMzcxNzIxNS8xNDMz
>NzE3MjE1LzE2MzYgdHJ5ZXhjZXB0IDI3LzIvMSBmb3JrIDE0MzM3MTcyMTUvMTQzMzcxNzIxNS85
>MDEgZm9ya3Rvb211Y2ggMTQzMzcxNzIxNS8xNDMzNzE3MjE1LzE0MzM3MTcyMTUgYWxsb2MgNDYv
>MTMvMCBjcmVhdCAzMTk2LzMwNTUvODg1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE3MjQ5LzMwODkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzI0OS83MzkvNiBu
>eHJlYWQgMTQzMzcxNzI0OS8xNDMzNzE3MjQ5LzE2NzAgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQz
>MzcxNzI0OS8xNDMzNzE3MjQ5LzkzNSBmb3JrdG9vbXVjaCAxNDMzNzE3MjQ5LzE0MzM3MTcyNDkv
>MTQzMzcxNzI0OSBhbGxvYyAzOC8xMS82IGNyZWF0IDMyMzAvMzA4OS85MTkgbG9jayA2LzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcyODAvMzEyMC8wICh0ZXN0czogcmVh
>ZCAxNDMzNzE3MjgwLzc3MC8xNSBueHJlYWQgMTQzMzcxNzI4MC8xNDMzNzE3MjgwLzE3MDEgdHJ5
>ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcxNzI4MC8xNDMzNzE3MjgwLzk2NiBmb3JrdG9vbXVjaCAx
>NDMzNzE3MjgwLzE0MzM3MTcyODAvMTQzMzcxNzI4MCBhbGxvYyA0OC8xMC80IGNyZWF0IDMyNjEv
>MzEyMC85NTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcz
>MzIvMzE3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE3MzMyLzgyMi85IG54cmVhZCAxNDMzNzE3MzMy
>LzE0MzM3MTczMzIvMTc1MyB0cnlleGNlcHQgMjgvMS8wIGZvcmsgMTQzMzcxNzMzMi8xNDMzNzE3
>MzMyLzEwMTggZm9ya3Rvb211Y2ggMTQzMzcxNzMzMi8xNDMzNzE3MzMyLzE0MzM3MTczMzIgYWxs
>b2MgMzcvOS8yIGNyZWF0IDMzMTMvMzE3Mi8xMDAyIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE3MzY3LzMyMDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzM2Ny84
>NTYvNiBueHJlYWQgMTQzMzcxNzM2Ny8xNDMzNzE3MzY3LzE3ODggdHJ5ZXhjZXB0IDE5LzMvMiBm
>b3JrIDE0MzM3MTczNjcvMTQzMzcxNzM2Ny8xMDUzIGZvcmt0b29tdWNoIDE0MzM3MTczNjcvMTQz
>MzcxNzM2Ny8xNDMzNzE3MzY3IGFsbG9jIDE3LzYvMyBjcmVhdCAzMzQ4LzMyMDcvMTAzNyBsb2Nr
>IDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzQwOC8zMjQ4LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTc0MDgvODk3LzcgbnhyZWFkIDE0MzM3MTc0MDgvMTQzMzcxNzQwOC8x
>ODI5IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAxNDMzNzE3NDA4LzE0MzM3MTc0MDgvMTA5NCBmb3Jr
>dG9vbXVjaCAxNDMzNzE3NDA4LzE0MzM3MTc0MDgvMTQzMzcxNzQwOCBhbGxvYyA1NC8xMy8xIGNy
>ZWF0IDMzODkvMzI0OC8xMDc4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3NDM1LzMyNzUvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzQzNS8yOTYvNSBueHJlYWQg
>MTQzMzcxNzQzNS8xNDMzNzE3NDM1LzE4NTYgdHJ5ZXhjZXB0IDE4LzIvMSBmb3JrIDE0MzM3MTc0
>MzUvMTQzMzcxNzQzNS8xMTIxIGZvcmt0b29tdWNoIDE0MzM3MTc0MzUvMTQzMzcxNzQzNS8xNDMz
>NzE3NDM1IGFsbG9jIDgxLzUvNSBjcmVhdCAzNDE2LzMyNzUvMTEwNSBsb2NrIDUvNS8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzQ2Ny8zMzA3LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTc0NjcvMzI4LzE0IG54cmVhZCAxNDMzNzE3NDY3LzE0MzM3MTc0NjcvMTg4OCB0cnlleGNl
>cHQgMjkvMi8yIGZvcmsgMTQzMzcxNzQ2Ny8xNDMzNzE3NDY3LzExNTMgZm9ya3Rvb211Y2ggMTQz
>MzcxNzQ2Ny8xNDMzNzE3NDY3LzE0MzM3MTc0NjcgYWxsb2MgMTEzLzExLzMgY3JlYXQgMzQ0OC8z
>MzA3LzExMzcgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc0
>OTYvMzMzNi8wICh0ZXN0czogcmVhZCAxNDMzNzE3NDk2LzM1Ny8yMCBueHJlYWQgMTQzMzcxNzQ5
>Ni8xNDMzNzE3NDk2LzE5MTcgdHJ5ZXhjZXB0IDQ1LzIvMSBmb3JrIDE0MzM3MTc0OTYvMTQzMzcx
>NzQ5Ni8xMTgyIGZvcmt0b29tdWNoIDE0MzM3MTc0OTYvMTQzMzcxNzQ5Ni8xNDMzNzE3NDk2IGFs
>bG9jIDQ4LzkvNSBjcmVhdCAzNDc3LzMzMzYvMTE2NiBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzU0My8zMzgzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTc1NDMv
>NDA0LzEgbnhyZWFkIDE0MzM3MTc1NDMvMTQzMzcxNzU0My8xOTY0IHRyeWV4Y2VwdCAzNC8zLzAg
>Zm9yayAxNDMzNzE3NTQzLzE0MzM3MTc1NDMvMTIyOSBmb3JrdG9vbXVjaCAxNDMzNzE3NTQzLzE0
>MzM3MTc1NDMvMTQzMzcxNzU0MyBhbGxvYyA2MS8xLzEgY3JlYXQgMzUyNC8zMzgzLzEyMTMgbG9j
>ayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc1NjgvMzQwOC8wICh0
>ZXN0czogcmVhZCAxNDMzNzE3NTY4LzQyOS82IG54cmVhZCAxNDMzNzE3NTY4LzE0MzM3MTc1Njgv
>MTk4OSB0cnlleGNlcHQgMTIvMi8wIGZvcmsgMTQzMzcxNzU2OC8xNDMzNzE3NTY4LzEyNTQgZm9y
>a3Rvb211Y2ggMTQzMzcxNzU2OC8xNDMzNzE3NTY4LzE0MzM3MTc1NjggYWxsb2MgMjYvNi8xIGNy
>ZWF0IDM1NDkvMzQwOC8xMjM4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3NTk5LzM0MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzU5OS80NjAvNSBueHJlYWQg
>MTQzMzcxNzU5OS8xNDMzNzE3NTk5LzIwMjAgdHJ5ZXhjZXB0IDQvMS8xIGZvcmsgMTQzMzcxNzU5
>OS8xNDMzNzE3NTk5LzEyODUgZm9ya3Rvb211Y2ggMTQzMzcxNzU5OS8xNDMzNzE3NTk5LzE0MzM3
>MTc1OTkgYWxsb2MgMjcvMTEvNSBjcmVhdCAzNTgwLzM0MzkvMTI2OSBsb2NrIDMvMy8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzYzNS8zNDc1LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTc2MzUvNDk2LzM2IG54cmVhZCAxNDMzNzE3NjM1LzE0MzM3MTc2MzUvMjA1NiB0cnlleGNl
>cHQgNS8yLzEgZm9yayAxNDMzNzE3NjM1LzE0MzM3MTc2MzUvMTMyMSBmb3JrdG9vbXVjaCAxNDMz
>NzE3NjM1LzE0MzM3MTc2MzUvMTQzMzcxNzYzNSBhbGxvYyAzNi8xMC82IGNyZWF0IDM2MTYvMzQ3
>NS8xMzA1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3NjY3
>LzM1MDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzY2Ny81MjgvNSBueHJlYWQgMTQzMzcxNzY2Ny8x
>NDMzNzE3NjY3LzIwODggdHJ5ZXhjZXB0IDQvMi8yIGZvcmsgMTQzMzcxNzY2Ny8xNDMzNzE3NjY3
>LzEzNTMgZm9ya3Rvb211Y2ggMTQzMzcxNzY2Ny8xNDMzNzE3NjY3LzE0MzM3MTc2NjcgYWxsb2Mg
>NDIvNS81IGNyZWF0IDM2NDgvMzUwNy8xMzM3IGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE3Njk0LzM1MzQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzY5NC81NTUv
>MjMgbnhyZWFkIDE0MzM3MTc2OTQvMTQzMzcxNzY5NC8yMTE1IHRyeWV4Y2VwdCAzLzIvMCBmb3Jr
>IDE0MzM3MTc2OTQvMTQzMzcxNzY5NC8xMzgwIGZvcmt0b29tdWNoIDE0MzM3MTc2OTQvMTQzMzcx
>NzY5NC8xNDMzNzE3Njk0IGFsbG9jIDMyLzYvMSBjcmVhdCAzNjc1LzM1MzQvMTM2NCBsb2NrIDEv
>MS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzczMy8zNTczLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTc3MzMvNTk0LzkgbnhyZWFkIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8yMTU0
>IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8xNDE5IGZvcmt0b29t
>dWNoIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8xNDMzNzE3NzMzIGFsbG9jIDI0LzEzLzMgY3JlYXQg
>MzcxNC8zNTczLzE0MDMgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTc3NjcvMzYwNy8wICh0ZXN0czogcmVhZCAxNDMzNzE3NzY3LzYyOC8yIG54cmVhZCAxNDMz
>NzE3NzY3LzE0MzM3MTc3NjcvMjE4OCB0cnlleGNlcHQgMS8xLzEgZm9yayAxNDMzNzE3NzY3LzE0
>MzM3MTc3NjcvMTQ1MyBmb3JrdG9vbXVjaCAxNDMzNzE3NzY3LzE0MzM3MTc3NjcvMTQzMzcxNzc2
>NyBhbGxvYyA1OC8xMS8yIGNyZWF0IDM3NDgvMzYwNy8xNDM3IGxvY2sgMi8yLzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3NzkwLzM2MzAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>Nzc5MC82NTEvMSBueHJlYWQgMTQzMzcxNzc5MC8xNDMzNzE3NzkwLzIyMTEgdHJ5ZXhjZXB0IDQv
>Mi8wIGZvcmsgMTQzMzcxNzc5MC8xNDMzNzE3NzkwLzE0NzYgZm9ya3Rvb211Y2ggMTQzMzcxNzc5
>MC8xNDMzNzE3NzkwLzE0MzM3MTc3OTAgYWxsb2MgMzQvMTQvMiBjcmVhdCAzNzcxLzM2MzAvMTQ2
>MCBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzgzNy8zNjc3
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc4MzcvNDM3LzUgbnhyZWFkIDE0MzM3MTc4MzcvMTQzMzcx
>NzgzNy8yMjU4IHRyeWV4Y2VwdCAyMS8yLzEgZm9yayAxNDMzNzE3ODM3LzE0MzM3MTc4MzcvMTUy
>MyBmb3JrdG9vbXVjaCAxNDMzNzE3ODM3LzE0MzM3MTc4MzcvMTQzMzcxNzgzNyBhbGxvYyAyNS81
>LzAgY3JlYXQgMzgxOC8zNjc3LzE1MDcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTc4NzIvMzcxMi8wICh0ZXN0czogcmVhZCAxNDMzNzE3ODcyLzQ3Mi8xNiBu
>eHJlYWQgMTQzMzcxNzg3Mi8xNDMzNzE3ODcyLzIyOTMgdHJ5ZXhjZXB0IDIzLzIvMSBmb3JrIDE0
>MzM3MTc4NzIvMTQzMzcxNzg3Mi8xNTU4IGZvcmt0b29tdWNoIDE0MzM3MTc4NzIvMTQzMzcxNzg3
>Mi8xNDMzNzE3ODcyIGFsbG9jIDYwLzIyLzYgY3JlYXQgMzg1My8zNzEyLzE1NDIgbG9jayA0LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc5MDkvMzc0OS8wICh0ZXN0czog
>cmVhZCAxNDMzNzE3OTA5LzUwOS8xOSBueHJlYWQgMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzIzMzAg
>dHJ5ZXhjZXB0IDMvMS8wIGZvcmsgMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzE1OTUgZm9ya3Rvb211
>Y2ggMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzE0MzM3MTc5MDkgYWxsb2MgNDMvMTMvMSBjcmVhdCAz
>ODkwLzM3NDkvMTU3OSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNzk0OS8zNzg5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc5NDkvNTQ5LzEwIG54cmVhZCAxNDMz
>NzE3OTQ5LzE0MzM3MTc5NDkvMjM3MCB0cnlleGNlcHQgMy8yLzIgZm9yayAxNDMzNzE3OTQ5LzE0
>MzM3MTc5NDkvMTYzNSBmb3JrdG9vbXVjaCAxNDMzNzE3OTQ5LzE0MzM3MTc5NDkvMTQzMzcxNzk0
>OSBhbGxvYyAxNS82LzYgY3JlYXQgMzkzMC8zNzg5LzE2MTkgbG9jayA2LzYvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc5NjEvMzgwMS8wICh0ZXN0czogcmVhZCAxNDMzNzE3
>OTYxLzU2MS8xMiBueHJlYWQgMTQzMzcxNzk2MS8xNDMzNzE3OTYxLzIzODIgdHJ5ZXhjZXB0IDkv
>My8wIGZvcmsgMTQzMzcxNzk2MS8xNDMzNzE3OTYxLzE2NDcgZm9ya3Rvb211Y2ggMTQzMzcxNzk2
>MS8xNDMzNzE3OTYxLzE0MzM3MTc5NjEgYWxsb2MgMjcvMTIvNyBjcmVhdCAzOTQyLzM4MDEvMTYz
>MSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzk5Ni8zODM2
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc5OTYvNTk2LzEgbnhyZWFkIDE0MzM3MTc5OTYvMTQzMzcx
>Nzk5Ni8yNDE3IHRyeWV4Y2VwdCA0LzMvMCBmb3JrIDE0MzM3MTc5OTYvMTQzMzcxNzk5Ni8xNjgy
>IGZvcmt0b29tdWNoIDE0MzM3MTc5OTYvMTQzMzcxNzk5Ni8xNDMzNzE3OTk2IGFsbG9jIDUzLzEy
>LzEgY3JlYXQgMzk3Ny8zODM2LzE2NjYgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTgwNTEvMzg5MS8wICh0ZXN0czogcmVhZCAxNDMzNzE4MDUxLzY1MS8yMCBu
>eHJlYWQgMTQzMzcxODA1MS8xNDMzNzE4MDUxLzI0NzIgdHJ5ZXhjZXB0IDE3LzIvMSBmb3JrIDE0
>MzM3MTgwNTEvMTQzMzcxODA1MS8xNzM3IGZvcmt0b29tdWNoIDE0MzM3MTgwNTEvMTQzMzcxODA1
>MS8xNDMzNzE4MDUxIGFsbG9jIDI2LzkvMyBjcmVhdCA0MDMyLzM4OTEvMTcyMSBsb2NrIDIvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODA4Ni8zOTI2LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTgwODYvNjg2LzIzIG54cmVhZCAxNDMzNzE4MDg2LzE0MzM3MTgwODYvMjUwNyB0
>cnlleGNlcHQgNTIvMi8xIGZvcmsgMTQzMzcxODA4Ni8xNDMzNzE4MDg2LzE3NzIgZm9ya3Rvb211
>Y2ggMTQzMzcxODA4Ni8xNDMzNzE4MDg2LzE0MzM3MTgwODYgYWxsb2MgMzgvOS80IGNyZWF0IDQw
>NjcvMzkyNi8xNzU2IGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzE4MTEzLzM5NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODExMy83MTMvMTggbnhyZWFkIDE0MzM3
>MTgxMTMvMTQzMzcxODExMy8yNTM0IHRyeWV4Y2VwdCAyNS8yLzEgZm9yayAxNDMzNzE4MTEzLzE0
>MzM3MTgxMTMvMTc5OSBmb3JrdG9vbXVjaCAxNDMzNzE4MTEzLzE0MzM3MTgxMTMvMTQzMzcxODEx
>MyBhbGxvYyA1OS8xMC81IGNyZWF0IDQwOTQvMzk1My8xNzgzIGxvY2sgNS81LzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MTUwLzM5OTAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>ODE1MC83NTAvMSBueHJlYWQgMTQzMzcxODE1MC8xNDMzNzE4MTUwLzI1NzEgdHJ5ZXhjZXB0IDkv
>Mi8wIGZvcmsgMTQzMzcxODE1MC8xNDMzNzE4MTUwLzE4MzYgZm9ya3Rvb211Y2ggMTQzMzcxODE1
>MC8xNDMzNzE4MTUwLzE0MzM3MTgxNTAgYWxsb2MgMzcvMy8xIGNyZWF0IDQxMzEvMzk5MC8xODIw
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MTgxLzQwMjEv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxODE4MS83ODEvMjMgbnhyZWFkIDE0MzM3MTgxODEvMTQzMzcx
>ODE4MS8yNjAyIHRyeWV4Y2VwdCAzMy8xMC8yIGZvcmsgMTQzMzcxODE4MS8xNDMzNzE4MTgxLzE4
>NjcgZm9ya3Rvb211Y2ggMTQzMzcxODE4MS8xNDMzNzE4MTgxLzE0MzM3MTgxODEgYWxsb2MgMzQv
>MTIvMCBjcmVhdCA0MTYyLzQwMjEvMTg1MSBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxODIyNy80MDY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTgyMjcvODI3LzEg
>bnhyZWFkIDE0MzM3MTgyMjcvMTQzMzcxODIyNy8yNjQ4IHRyeWV4Y2VwdCA0Mi8yLzAgZm9yayAx
>NDMzNzE4MjI3LzE0MzM3MTgyMjcvMTkxMyBmb3JrdG9vbXVjaCAxNDMzNzE4MjI3LzE0MzM3MTgy
>MjcvMTQzMzcxODIyNyBhbGxvYyA0NC8xMi8wIGNyZWF0IDQyMDgvNDA2Ny8xODk3IGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MjU3LzQwOTcvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxODI1Ny84NTcvMTMgbnhyZWFkIDE0MzM3MTgyNTcvMTQzMzcxODI1Ny8yNjc4
>IHRyeWV4Y2VwdCAyMi8yLzAgZm9yayAxNDMzNzE4MjU3LzE0MzM3MTgyNTcvMTk0MyBmb3JrdG9v
>bXVjaCAxNDMzNzE4MjU3LzE0MzM3MTgyNTcvMTQzMzcxODI1NyBhbGxvYyA3NC8zLzEgY3JlYXQg
>NDIzOC80MDk3LzE5MjcgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTgzMDIvNDE0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE4MzAyLzkwMi84IG54cmVhZCAxNDMz
>NzE4MzAyLzE0MzM3MTgzMDIvMjcyMyB0cnlleGNlcHQgMjQvMy8wIGZvcmsgMTQzMzcxODMwMi8x
>NDMzNzE4MzAyLzE5ODggZm9ya3Rvb211Y2ggMTQzMzcxODMwMi8xNDMzNzE4MzAyLzE0MzM3MTgz
>MDIgYWxsb2MgMzcvNC8xIGNyZWF0IDQyODMvNDE0Mi8xOTcyIGxvY2sgMS8xLzEpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MzIyLzQxNjIvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>ODMyMi85MjIvMTcgbnhyZWFkIDE0MzM3MTgzMjIvMTQzMzcxODMyMi8yNzQzIHRyeWV4Y2VwdCAy
>My8xLzAgZm9yayAxNDMzNzE4MzIyLzE0MzM3MTgzMjIvMjAwOCBmb3JrdG9vbXVjaCAxNDMzNzE4
>MzIyLzE0MzM3MTgzMjIvMTQzMzcxODMyMiBhbGxvYyAzOS8xNy8xIGNyZWF0IDQzMDMvNDE2Mi8x
>OTkyIGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MzY4LzMx
>OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODM2OC85NTQvNCBueHJlYWQgMTQzMzcxODM2OC8xNDMz
>NzE4MzY4LzI3ODkgdHJ5ZXhjZXB0IDQyLzIvMSBmb3JrIDE0MzM3MTgzNjgvMTQzMzcxODM2OC8y
>MDU0IGZvcmt0b29tdWNoIDE0MzM3MTgzNjgvMTQzMzcxODM2OC8xNDMzNzE4MzY4IGFsbG9jIDI2
>LzcvMCBjcmVhdCA0MzQ5LzQyMDgvMjAzOCBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxODQwMi8zMjI3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg0MDIvOTg4LzIy
>IG54cmVhZCAxNDMzNzE4NDAyLzE0MzM3MTg0MDIvMjgyMyB0cnlleGNlcHQgMTMvMy8wIGZvcmsg
>MTQzMzcxODQwMi8xNDMzNzE4NDAyLzIwODggZm9ya3Rvb211Y2ggMTQzMzcxODQwMi8xNDMzNzE4
>NDAyLzE0MzM3MTg0MDIgYWxsb2MgMzgvNi8yIGNyZWF0IDQzODMvNDI0Mi8yMDcyIGxvY2sgMi8y
>LzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NDIyLzMyNDcvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxODQyMi8xMDA4LzQgbnhyZWFkIDE0MzM3MTg0MjIvMTQzMzcxODQyMi8yODQz
>IHRyeWV4Y2VwdCAzMy8zLzAgZm9yayAxNDMzNzE4NDIyLzE0MzM3MTg0MjIvMjEwOCBmb3JrdG9v
>bXVjaCAxNDMzNzE4NDIyLzE0MzM3MTg0MjIvMTQzMzcxODQyMiBhbGxvYyA1MC8xMC8yIGNyZWF0
>IDQ0MDMvNDI2Mi8yMDkyIGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE4NDU2LzMyODEvMCAodGVzdHM6IHJlYWQgMTQzMzcxODQ1Ni8xMDQyLzExIG54cmVhZCAx
>NDMzNzE4NDU2LzE0MzM3MTg0NTYvMjg3NyB0cnlleGNlcHQgMy8xLzEgZm9yayAxNDMzNzE4NDU2
>LzE0MzM3MTg0NTYvMjE0MiBmb3JrdG9vbXVjaCAxNDMzNzE4NDU2LzE0MzM3MTg0NTYvMTQzMzcx
>ODQ1NiBhbGxvYyAzOC8xNS80IGNyZWF0IDQ0MzcvNDI5Ni8yMTI2IGxvY2sgNC80LzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NDkwLzMzMTUvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxODQ5MC8xMDc2LzEgbnhyZWFkIDE0MzM3MTg0OTAvMTQzMzcxODQ5MC8yOTExIHRyeWV4Y2Vw
>dCA0LzIvMCBmb3JrIDE0MzM3MTg0OTAvMTQzMzcxODQ5MC8yMTc2IGZvcmt0b29tdWNoIDE0MzM3
>MTg0OTAvMTQzMzcxODQ5MC8xNDMzNzE4NDkwIGFsbG9jIDM4LzcvMSBjcmVhdCA0NDcxLzQzMzAv
>MjE2MCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODUyMS8z
>MzQ2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg1MjEvMTEwNy83IG54cmVhZCAxNDMzNzE4NTIxLzE0
>MzM3MTg1MjEvMjk0MiB0cnlleGNlcHQgNi8xLzAgZm9yayAxNDMzNzE4NTIxLzE0MzM3MTg1MjEv
>MjIwNyBmb3JrdG9vbXVjaCAxNDMzNzE4NTIxLzE0MzM3MTg1MjEvMTQzMzcxODUyMSBhbGxvYyAy
>Mi83LzMgY3JlYXQgNDUwMi80MzYxLzIxOTEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTg1NTAvMzM3NS8wICh0ZXN0czogcmVhZCAxNDMzNzE4NTUwLzExMzYv
>NyBueHJlYWQgMTQzMzcxODU1MC8xNDMzNzE4NTUwLzI5NzEgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsg
>MTQzMzcxODU1MC8xNDMzNzE4NTUwLzIyMzYgZm9ya3Rvb211Y2ggMTQzMzcxODU1MC8xNDMzNzE4
>NTUwLzE0MzM3MTg1NTAgYWxsb2MgNTEvMTQvNyBjcmVhdCA0NTMxLzQzOTAvMjIyMCBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODU4My8zNDA4LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTg1ODMvMTE2OS81IG54cmVhZCAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMzAw
>NCB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMjI2OSBmb3JrdG9v
>bXVjaCAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMTQzMzcxODU4MyBhbGxvYyA3NC81LzAgY3JlYXQg
>NDU2NC80NDIzLzIyNTMgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTg2MDkvMzQzNC8wICh0ZXN0czogcmVhZCAxNDMzNzE4NjA5LzExOTUvNyBueHJlYWQgMTQz
>MzcxODYwOS8xNDMzNzE4NjA5LzMwMzAgdHJ5ZXhjZXB0IDE1LzEvMSBmb3JrIDE0MzM3MTg2MDkv
>MTQzMzcxODYwOS8yMjk1IGZvcmt0b29tdWNoIDE0MzM3MTg2MDkvMTQzMzcxODYwOS8xNDMzNzE4
>NjA5IGFsbG9jIDEwMC83LzIgY3JlYXQgNDU5MC80NDQ5LzIyNzkgbG9jayAyLzIvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg2NDEvMzQ2Ni8wICh0ZXN0czogcmVhZCAxNDMz
>NzE4NjQxLzEyMjcvNyBueHJlYWQgMTQzMzcxODY0MS8xNDMzNzE4NjQxLzMwNjIgdHJ5ZXhjZXB0
>IDMzLzEvMSBmb3JrIDE0MzM3MTg2NDEvMTQzMzcxODY0MS8yMzI3IGZvcmt0b29tdWNoIDE0MzM3
>MTg2NDEvMTQzMzcxODY0MS8xNDMzNzE4NjQxIGFsbG9jIDM0LzcvMCBjcmVhdCA0NjIyLzQ0ODEv
>MjMxMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODY3OS8z
>NTA0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg2NzkvMTI2NS81IG54cmVhZCAxNDMzNzE4Njc5LzE0
>MzM3MTg2NzkvMzEwMCB0cnlleGNlcHQgNi8xLzEgZm9yayAxNDMzNzE4Njc5LzE0MzM3MTg2Nzkv
>MjM2NSBmb3JrdG9vbXVjaCAxNDMzNzE4Njc5LzE0MzM3MTg2NzkvMTQzMzcxODY3OSBhbGxvYyA0
>NS8xNi81IGNyZWF0IDQ2NjAvNDUxOS8yMzQ5IGxvY2sgNC80LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE4NzEyLzM1MzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxODcxMi8xMjk4
>LzM4IG54cmVhZCAxNDMzNzE4NzEyLzE0MzM3MTg3MTIvMzEzMyB0cnlleGNlcHQgMjEvMi8xIGZv
>cmsgMTQzMzcxODcxMi8xNDMzNzE4NzEyLzIzOTggZm9ya3Rvb211Y2ggMTQzMzcxODcxMi8xNDMz
>NzE4NzEyLzE0MzM3MTg3MTIgYWxsb2MgNTIvOS81IGNyZWF0IDQ2OTMvNDU1Mi8yMzgyIGxvY2sg
>NS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NzM4LzM1NjMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxODczOC8xMzI0LzcgbnhyZWFkIDE0MzM3MTg3MzgvMTQzMzcxODczOC8z
>MTU5IHRyeWV4Y2VwdCAyNy8yLzIgZm9yayAxNDMzNzE4NzM4LzE0MzM3MTg3MzgvMjQyNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE4NzM4LzE0MzM3MTg3MzgvMTQzMzcxODczOCBhbGxvYyA2OS8xOS83IGNy
>ZWF0IDQ3MTkvNDU3OC8yNDA4IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE4NzY4LzM1OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODc2OC8xMzU0LzE1IG54cmVh
>ZCAxNDMzNzE4NzY4LzE0MzM3MTg3NjgvMzE4OSB0cnlleGNlcHQgNi8zLzEgZm9yayAxNDMzNzE4
>NzY4LzE0MzM3MTg3NjgvMjQ1NCBmb3JrdG9vbXVjaCAxNDMzNzE4NzY4LzE0MzM3MTg3NjgvMTQz
>MzcxODc2OCBhbGxvYyA0OS84LzUgY3JlYXQgNDc0OS80NjA4LzI0MzggbG9jayAwLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg3OTYvMzYyMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzE4Nzk2LzEzODIvMTIgbnhyZWFkIDE0MzM3MTg3OTYvMTQzMzcxODc5Ni8zMjE3IHRyeWV4
>Y2VwdCAzNC8zLzEgZm9yayAxNDMzNzE4Nzk2LzE0MzM3MTg3OTYvMjQ4MiBmb3JrdG9vbXVjaCAx
>NDMzNzE4Nzk2LzE0MzM3MTg3OTYvMTQzMzcxODc5NiBhbGxvYyAzMy8xOS81IGNyZWF0IDQ3Nzcv
>NDYzNi8yNDY2IGxvY2sgMTAvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>ODg0OS8zNjc0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg4NDkvMTQzNS80NSBueHJlYWQgMTQzMzcx
>ODg0OS8xNDMzNzE4ODQ5LzMyNzAgdHJ5ZXhjZXB0IDIwLzIvMSBmb3JrIDE0MzM3MTg4NDkvMTQz
>MzcxODg0OS8yNTM1IGZvcmt0b29tdWNoIDE0MzM3MTg4NDkvMTQzMzcxODg0OS8xNDMzNzE4ODQ5
>IGFsbG9jIDQwLzEwLzQgY3JlYXQgNDgzMC80Njg5LzI1MTkgbG9jayA0LzQvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg4OTEvMzcxNi8wICh0ZXN0czogcmVhZCAxNDMzNzE4
>ODkxLzE0NzcvMSBueHJlYWQgMTQzMzcxODg5MS8xNDMzNzE4ODkxLzMzMTIgdHJ5ZXhjZXB0IDMx
>LzIvMCBmb3JrIDE0MzM3MTg4OTEvMTQzMzcxODg5MS8yNTc3IGZvcmt0b29tdWNoIDE0MzM3MTg4
>OTEvMTQzMzcxODg5MS8xNDMzNzE4ODkxIGFsbG9jIDQyLzExLzEgY3JlYXQgNDg3Mi80NzMxLzI1
>NjEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg5NDkvMzc3
>NC8wICh0ZXN0czogcmVhZCAxNDMzNzE4OTQ5LzE1MzUvOCBueHJlYWQgMTQzMzcxODk0OS8xNDMz
>NzE4OTQ5LzMzNzAgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcxODk0OS8xNDMzNzE4OTQ5LzI2
>MzUgZm9ya3Rvb211Y2ggMTQzMzcxODk0OS8xNDMzNzE4OTQ5LzE0MzM3MTg5NDkgYWxsb2MgMjgv
>Mi8yIGNyZWF0IDQ5MzAvNDc4OS8yNjE5IGxvY2sgMi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE5MDAyLzM4MjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTAwMi8xNTg4LzE5
>IG54cmVhZCAxNDMzNzE5MDAyLzE0MzM3MTkwMDIvMzQyMyB0cnlleGNlcHQgMjgvMS8wIGZvcmsg
>MTQzMzcxOTAwMi8xNDMzNzE5MDAyLzI2ODggZm9ya3Rvb211Y2ggMTQzMzcxOTAwMi8xNDMzNzE5
>MDAyLzE0MzM3MTkwMDIgYWxsb2MgNTUvMTEvMiBjcmVhdCA0OTgzLzQ4NDIvMjY3MiBsb2NrIDEv
>MS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTAzMy8zODU4LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTkwMzMvMTYxOS81IG54cmVhZCAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMzQ1
>NCB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMjcxOSBmb3JrdG9v
>bXVjaCAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMTQzMzcxOTAzMyBhbGxvYyAyNy8xMS8wIGNyZWF0
>IDUwMTQvNDg3My8yNzAzIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE5MDYzLzM4ODgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTA2My8xNjQ5LzYgbnhyZWFkIDE0
>MzM3MTkwNjMvMTQzMzcxOTA2My8zNDg0IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MTkwNjMv
>MTQzMzcxOTA2My8yNzQ5IGZvcmt0b29tdWNoIDE0MzM3MTkwNjMvMTQzMzcxOTA2My8xNDMzNzE5
>MDYzIGFsbG9jIDMwLzYvMSBjcmVhdCA1MDQ0LzQ5MDMvMjczMyBsb2NrIDAvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTEwNi8zOTMxLzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTkxMDYvMTY5Mi80OSBueHJlYWQgMTQzMzcxOTEwNi8xNDMzNzE5MTA2LzM1MjcgdHJ5ZXhjZXB0
>IDcvMS8wIGZvcmsgMTQzMzcxOTEwNi8xNDMzNzE5MTA2LzI3OTIgZm9ya3Rvb211Y2ggMTQzMzcx
>OTEwNi8xNDMzNzE5MTA2LzE0MzM3MTkxMDYgYWxsb2MgNTQvMS8xIGNyZWF0IDUwODcvNDk0Ni8y
>Nzc2IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MTQ2LzM5
>NzEvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTE0Ni8xNzMyLzEzIG54cmVhZCAxNDMzNzE5MTQ2LzE0
>MzM3MTkxNDYvMzU2NyB0cnlleGNlcHQgMTMvMi8xIGZvcmsgMTQzMzcxOTE0Ni8xNDMzNzE5MTQ2
>LzI4MzIgZm9ya3Rvb211Y2ggMTQzMzcxOTE0Ni8xNDMzNzE5MTQ2LzE0MzM3MTkxNDYgYWxsb2Mg
>NDEvMTMvNSBjcmVhdCA1MTI3LzQ5ODYvMjgxNiBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxOTE4Mi80MDA3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTkxODIvMTc2
>OC85IG54cmVhZCAxNDMzNzE5MTgyLzE0MzM3MTkxODIvMzYwMyB0cnlleGNlcHQgOC83LzEgZm9y
>ayAxNDMzNzE5MTgyLzE0MzM3MTkxODIvMjg2OCBmb3JrdG9vbXVjaCAxNDMzNzE5MTgyLzE0MzM3
>MTkxODIvMTQzMzcxOTE4MiBhbGxvYyA0OS85LzIgY3JlYXQgNTE2My81MDIyLzI4NTIgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTkyMTgvNDA0My8wICh0ZXN0
>czogcmVhZCAxNDMzNzE5MjE4LzE4MDQvMTkgbnhyZWFkIDE0MzM3MTkyMTgvMTQzMzcxOTIxOC8z
>NjM5IHRyeWV4Y2VwdCAyMi81LzEgZm9yayAxNDMzNzE5MjE4LzE0MzM3MTkyMTgvMjkwNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE5MjE4LzE0MzM3MTkyMTgvMTQzMzcxOTIxOCBhbGxvYyA2OC8xMS8zIGNy
>ZWF0IDUxOTkvNTA1OC8yODg4IGxvY2sgNC8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE5MjQ1LzQwNzAvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTI0NS8xODMxLzE2IG54cmVh
>ZCAxNDMzNzE5MjQ1LzE0MzM3MTkyNDUvMzY2NiB0cnlleGNlcHQgNDgvMi8wIGZvcmsgMTQzMzcx
>OTI0NS8xNDMzNzE5MjQ1LzI5MzEgZm9ya3Rvb211Y2ggMTQzMzcxOTI0NS8xNDMzNzE5MjQ1LzE0
>MzM3MTkyNDUgYWxsb2MgNDIvOS8xIGNyZWF0IDUyMjYvNTA4NS8yOTE1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MjczLzQwOTgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTI3My8xODU5LzMgbnhyZWFkIDE0MzM3MTkyNzMvMTQzMzcxOTI3My8zNjk0IHRyeWV4
>Y2VwdCA3LzIvMSBmb3JrIDE0MzM3MTkyNzMvMTQzMzcxOTI3My8yOTU5IGZvcmt0b29tdWNoIDE0
>MzM3MTkyNzMvMTQzMzcxOTI3My8xNDMzNzE5MjczIGFsbG9jIDU1LzgvMCBjcmVhdCA1MjU0LzUx
>MTMvMjk0MyBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTI5
>NS80MTIwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTkyOTUvMTg4MS82IG54cmVhZCAxNDMzNzE5Mjk1
>LzE0MzM3MTkyOTUvMzcxNiB0cnlleGNlcHQgMTUvMi8wIGZvcmsgMTQzMzcxOTI5NS8xNDMzNzE5
>Mjk1LzI5ODEgZm9ya3Rvb211Y2ggMTQzMzcxOTI5NS8xNDMzNzE5Mjk1LzE0MzM3MTkyOTUgYWxs
>b2MgMjIvNi8xIGNyZWF0IDUyNzYvNTEzNS8yOTY1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE5MzQ4LzQxNzMvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTM0OC8x
>OTM0LzQ5IG54cmVhZCAxNDMzNzE5MzQ4LzE0MzM3MTkzNDgvMzc2OSB0cnlleGNlcHQgNi8yLzIg
>Zm9yayAxNDMzNzE5MzQ4LzE0MzM3MTkzNDgvMzAzNCBmb3JrdG9vbXVjaCAxNDMzNzE5MzQ4LzE0
>MzM3MTkzNDgvMTQzMzcxOTM0OCBhbGxvYyA2Mi8xNS83IGNyZWF0IDUzMjkvNTE4OC8zMDE4IGxv
>Y2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MzcxLzQxOTYvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxOTM3MS8xOTU3LzggbnhyZWFkIDE0MzM3MTkzNzEvMTQzMzcxOTM3
>MS8zNzkyIHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTkzNzEvMTQzMzcxOTM3MS8zMDU3IGZv
>cmt0b29tdWNoIDE0MzM3MTkzNzEvMTQzMzcxOTM3MS8xNDMzNzE5MzcxIGFsbG9jIDYxLzgvMSBj
>cmVhdCA1MzUyLzUyMTEvMzA0MSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxOTQwMy80MjI4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk0MDMvMTk4OS84IG54cmVh
>ZCAxNDMzNzE5NDAzLzE0MzM3MTk0MDMvMzgyNCB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE5
>NDAzLzE0MzM3MTk0MDMvMzA4OSBmb3JrdG9vbXVjaCAxNDMzNzE5NDAzLzE0MzM3MTk0MDMvMTQz
>MzcxOTQwMyBhbGxvYyA4OC8xNy84IGNyZWF0IDUzODQvNTI0My8zMDczIGxvY2sgNi8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NDMyLzQyNTcvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTQzMi8yMDE4LzggbnhyZWFkIDE0MzM3MTk0MzIvMTQzMzcxOTQzMi8zODUzIHRyeWV4
>Y2VwdCA0LzIvMCBmb3JrIDE0MzM3MTk0MzIvMTQzMzcxOTQzMi8zMTE4IGZvcmt0b29tdWNoIDE0
>MzM3MTk0MzIvMTQzMzcxOTQzMi8xNDMzNzE5NDMyIGFsbG9jIDM3LzEvMSBjcmVhdCA1NDEzLzUy
>NzIvMzEwMiBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTQ2
>OS80Mjk0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk0NjkvMjA1NS8xIG54cmVhZCAxNDMzNzE5NDY5
>LzE0MzM3MTk0NjkvMzg5MCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE5NDY5LzE0MzM3MTk0
>NjkvMzE1NSBmb3JrdG9vbXVjaCAxNDMzNzE5NDY5LzE0MzM3MTk0NjkvMTQzMzcxOTQ2OSBhbGxv
>YyA1MC8xLzEgY3JlYXQgNTQ1MC81MzA5LzMxMzkgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTk1MTMvNDMzOC8wICh0ZXN0czogcmVhZCAxNDMzNzE5NTEzLzIw
>OTkvMTcgbnhyZWFkIDE0MzM3MTk1MTMvMTQzMzcxOTUxMy8zOTM0IHRyeWV4Y2VwdCAzLzMvMCBm
>b3JrIDE0MzM3MTk1MTMvMTQzMzcxOTUxMy8zMTk5IGZvcmt0b29tdWNoIDE0MzM3MTk1MTMvMTQz
>MzcxOTUxMy8xNDMzNzE5NTEzIGFsbG9jIDIyLzYvMSBjcmVhdCA1NDk0LzUzNTMvMzE4MyBsb2Nr
>IDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTU0MS80MzY2LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTk1NDEvMjEyNy8zIG54cmVhZCAxNDMzNzE5NTQxLzE0MzM3MTk1NDEv
>Mzk2MiB0cnlleGNlcHQgMTEvOC8yIGZvcmsgMTQzMzcxOTU0MS8xNDMzNzE5NTQxLzMyMjcgZm9y
>a3Rvb211Y2ggMTQzMzcxOTU0MS8xNDMzNzE5NTQxLzE0MzM3MTk1NDEgYWxsb2MgMzQvMTAvMCBj
>cmVhdCA1NTIyLzUzODEvMzIxMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxOTU2Mi80Mzg3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk1NjIvMjE0OC8yNCBueHJl
>YWQgMTQzMzcxOTU2Mi8xNDMzNzE5NTYyLzM5ODMgdHJ5ZXhjZXB0IDI5LzMvMCBmb3JrIDE0MzM3
>MTk1NjIvMTQzMzcxOTU2Mi8zMjQ4IGZvcmt0b29tdWNoIDE0MzM3MTk1NjIvMTQzMzcxOTU2Mi8x
>NDMzNzE5NTYyIGFsbG9jIDMxLzE1LzEgY3JlYXQgNTU0My81NDAyLzMyMzIgbG9jayAxLzEvMSkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTk1OTgvNDQyMy8wICh0ZXN0czogcmVh
>ZCAxNDMzNzE5NTk4LzIxODQvMjMgbnhyZWFkIDE0MzM3MTk1OTgvMTQzMzcxOTU5OC80MDE5IHRy
>eWV4Y2VwdCA3LzMvMiBmb3JrIDE0MzM3MTk1OTgvMTQzMzcxOTU5OC8zMjg0IGZvcmt0b29tdWNo
>IDE0MzM3MTk1OTgvMTQzMzcxOTU5OC8xNDMzNzE5NTk4IGFsbG9jIDUxLzI3LzYgY3JlYXQgNTU3
>OS81NDM4LzMyNjggbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTk2MjkvNDQ1NC8wICh0ZXN0czogcmVhZCAxNDMzNzE5NjI5LzIyMTUvMTEgbnhyZWFkIDE0MzM3
>MTk2MjkvMTQzMzcxOTYyOS80MDUwIHRyeWV4Y2VwdCAzMy8yLzIgZm9yayAxNDMzNzE5NjI5LzE0
>MzM3MTk2MjkvMzMxNSBmb3JrdG9vbXVjaCAxNDMzNzE5NjI5LzE0MzM3MTk2MjkvMTQzMzcxOTYy
>OSBhbGxvYyA2OC8xNi82IGNyZWF0IDU2MTAvNTQ2OS8zMjk5IGxvY2sgMC8wLzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NjUyLzQ0NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>OTY1Mi8yMjM4LzcgbnhyZWFkIDE0MzM3MTk2NTIvMTQzMzcxOTY1Mi80MDczIHRyeWV4Y2VwdCAx
>NS8zLzIgZm9yayAxNDMzNzE5NjUyLzE0MzM3MTk2NTIvMzMzOCBmb3JrdG9vbXVjaCAxNDMzNzE5
>NjUyLzE0MzM3MTk2NTIvMTQzMzcxOTY1MiBhbGxvYyAyMy8xNy83IGNyZWF0IDU2MzMvNTQ5Mi8z
>MzIyIGxvY2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NjkzLzQ1
>MTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTY5My8yMjc5LzUgbnhyZWFkIDE0MzM3MTk2OTMvMTQz
>MzcxOTY5My80MTE0IHRyeWV4Y2VwdCA1Ni8yLzEgZm9yayAxNDMzNzE5NjkzLzE0MzM3MTk2OTMv
>MzM3OSBmb3JrdG9vbXVjaCAxNDMzNzE5NjkzLzE0MzM3MTk2OTMvMTQzMzcxOTY5MyBhbGxvYyAz
>MC8xNC81IGNyZWF0IDU2NzQvNTUzMy8zMzYzIGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE5NzE2LzQ1NDEvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTcxNi8yMzAy
>LzE5IG54cmVhZCAxNDMzNzE5NzE2LzE0MzM3MTk3MTYvNDEzNyB0cnlleGNlcHQgMjAvMy8wIGZv
>cmsgMTQzMzcxOTcxNi8xNDMzNzE5NzE2LzM0MDIgZm9ya3Rvb211Y2ggMTQzMzcxOTcxNi8xNDMz
>NzE5NzE2LzE0MzM3MTk3MTYgYWxsb2MgNTMvOC8wIGNyZWF0IDU2OTcvNTU1Ni8zMzg2IGxvY2sg
>MS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NzQ4LzQ1NzMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxOTc0OC8yMzM0LzQgbnhyZWFkIDE0MzM3MTk3NDgvMTQzMzcxOTc0OC80
>MTY5IHRyeWV4Y2VwdCA1Mi8xLzEgZm9yayAxNDMzNzE5NzQ4LzE0MzM3MTk3NDgvMzQzNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE5NzQ4LzE0MzM3MTk3NDgvMTQzMzcxOTc0OCBhbGxvYyA1NS8xNS80IGNy
>ZWF0IDU3MjkvNTU4OC8zNDE4IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE5NzgzLzQ2MDgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTc4My8yMzY5LzkgbnhyZWFk
>IDE0MzM3MTk3ODMvMTQzMzcxOTc4My80MjA0IHRyeWV4Y2VwdCA4My8yLzAgZm9yayAxNDMzNzE5
>NzgzLzE0MzM3MTk3ODMvMzQ2OSBmb3JrdG9vbXVjaCAxNDMzNzE5NzgzLzE0MzM3MTk3ODMvMTQz
>MzcxOTc4MyBhbGxvYyA0Mi8xNi8xIGNyZWF0IDU3NjQvNTYyMy8zNDUzIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5ODEzLzQ2MzgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTgxMy8yMzk5LzUgbnhyZWFkIDE0MzM3MTk4MTMvMTQzMzcxOTgxMy80MjM0IHRyeWV4
>Y2VwdCAxMTMvMC8wIGZvcmsgMTQzMzcxOTgxMy8xNDMzNzE5ODEzLzM0OTkgZm9ya3Rvb211Y2gg
>MTQzMzcxOTgxMy8xNDMzNzE5ODEzLzE0MzM3MTk4MTMgYWxsb2MgNTYvMTYvMiBjcmVhdCA1Nzk0
>LzU2NTMvMzQ4MyBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>OTg0Ny80NjcyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTk4NDcvMjQzMy82IG54cmVhZCAxNDMzNzE5
>ODQ3LzE0MzM3MTk4NDcvNDI2OCB0cnlleGNlcHQgMjcvMS8wIGZvcmsgMTQzMzcxOTg0Ny8xNDMz
>NzE5ODQ3LzM1MzMgZm9ya3Rvb211Y2ggMTQzMzcxOTg0Ny8xNDMzNzE5ODQ3LzE0MzM3MTk4NDcg
>YWxsb2MgNDUvNi8yIGNyZWF0IDU4MjgvNTY4Ny8zNTE3IGxvY2sgMi8yLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzE5ODg4LzQ3MTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTg4
>OC8yNDc0LzI3IG54cmVhZCAxNDMzNzE5ODg4LzE0MzM3MTk4ODgvNDMwOSB0cnlleGNlcHQgMTMv
>Mi8yIGZvcmsgMTQzMzcxOTg4OC8xNDMzNzE5ODg4LzM1NzQgZm9ya3Rvb211Y2ggMTQzMzcxOTg4
>OC8xNDMzNzE5ODg4LzE0MzM3MTk4ODggYWxsb2MgNDcvMTcvMCBjcmVhdCA1ODY5LzU3MjgvMzU1
>OCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTkxOS80NzQ0
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk5MTkvMjUwNS82IG54cmVhZCAxNDMzNzE5OTE5LzE0MzM3
>MTk5MTkvNDM0MCB0cnlleGNlcHQgNDQvMi8xIGZvcmsgMTQzMzcxOTkxOS8xNDMzNzE5OTE5LzM2
>MDUgZm9ya3Rvb211Y2ggMTQzMzcxOTkxOS8xNDMzNzE5OTE5LzE0MzM3MTk5MTkgYWxsb2MgNDMv
>Ni8wIGNyZWF0IDU5MDAvNTc1OS8zNTg5IGxvY2sgNi82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE5OTM5LzQ3NjQvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTkzOS8yNTI1LzEx
>IG54cmVhZCAxNDMzNzE5OTM5LzE0MzM3MTk5MzkvNDM2MCB0cnlleGNlcHQgMjEvMi8xIGZvcmsg
>MTQzMzcxOTkzOS8xNDMzNzE5OTM5LzM2MjUgZm9ya3Rvb211Y2ggMTQzMzcxOTkzOS8xNDMzNzE5
>OTM5LzE0MzM3MTk5MzkgYWxsb2MgMzcvMTEvNSBjcmVhdCA1OTIwLzU3NzkvMzYwOSBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTk2OS80Nzk0LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTk5NjkvMjU1NS85IG54cmVhZCAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvNDM5
>MCB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvMzY1NSBmb3JrdG9v
>bXVjaCAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvMTQzMzcxOTk2OSBhbGxvYyA0MS85LzUgY3JlYXQg
>NTk1MC81ODA5LzM2MzkgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTk5ODQvNDgwOS8wICh0ZXN0czogcmVhZCAxNDMzNzE5OTg0LzI1NzAvMTUgbnhyZWFkIDE0
>MzM3MTk5ODQvMTQzMzcxOTk4NC80NDA1IHRyeWV4Y2VwdCA3LzcvMCBmb3JrIDE0MzM3MTk5ODQv
>MTQzMzcxOTk4NC8zNjcwIGZvcmt0b29tdWNoIDE0MzM3MTk5ODQvMTQzMzcxOTk4NC8xNDMzNzE5
>OTg0IGFsbG9jIDQ1LzIwLzggY3JlYXQgNTk2NS81ODI0LzM2NTQgbG9jayAxLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjAwMTYvNDg0MS8wICh0ZXN0czogcmVhZCAxNDMz
>NzIwMDE2LzI2MDIvMSBueHJlYWQgMTQzMzcyMDAxNi8xNDMzNzIwMDE2LzQ0MzcgdHJ5ZXhjZXB0
>IDE4LzMvMCBmb3JrIDE0MzM3MjAwMTYvMTQzMzcyMDAxNi8zNzAyIGZvcmt0b29tdWNoIDE0MzM3
>MjAwMTYvMTQzMzcyMDAxNi8xNDMzNzIwMDE2IGFsbG9jIDU2LzkvMSBjcmVhdCA1OTk3LzU4NTYv
>MzY4NiBsb2NrIDEvMS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDA1Mi80
>ODc3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjAwNTIvMjYzOC8xMCBueHJlYWQgMTQzMzcyMDA1Mi8x
>NDMzNzIwMDUyLzQ0NzMgdHJ5ZXhjZXB0IDUzLzIvMSBmb3JrIDE0MzM3MjAwNTIvMTQzMzcyMDA1
>Mi8zNzM4IGZvcmt0b29tdWNoIDE0MzM3MjAwNTIvMTQzMzcyMDA1Mi8xNDMzNzIwMDUyIGFsbG9j
>IDQ1LzE4LzYgY3JlYXQgNjAzMy81ODkyLzM3MjIgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjAwNzYvNDkwMS8wICh0ZXN0czogcmVhZCAxNDMzNzIwMDc2LzI2
>NjIvMTEgbnhyZWFkIDE0MzM3MjAwNzYvMTQzMzcyMDA3Ni80NDk3IHRyeWV4Y2VwdCAxMi8xLzAg
>Zm9yayAxNDMzNzIwMDc2LzE0MzM3MjAwNzYvMzc2MiBmb3JrdG9vbXVjaCAxNDMzNzIwMDc2LzE0
>MzM3MjAwNzYvMTQzMzcyMDA3NiBhbGxvYyA1NS8xLzEgY3JlYXQgNjA1Ny81OTE2LzM3NDYgbG9j
>ayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjAxMDgvNDkzMy8wICh0
>ZXN0czogcmVhZCAxNDMzNzIwMTA4LzI2OTQvNSBueHJlYWQgMTQzMzcyMDEwOC8xNDMzNzIwMTA4
>LzQ1MjkgdHJ5ZXhjZXB0IDE2LzIvMCBmb3JrIDE0MzM3MjAxMDgvMTQzMzcyMDEwOC8zNzk0IGZv
>cmt0b29tdWNoIDE0MzM3MjAxMDgvMTQzMzcyMDEwOC8xNDMzNzIwMTA4IGFsbG9jIDMzLzkvMSBj
>cmVhdCA2MDg5LzU5NDgvMzc3OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMDE0My80OTY4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjAxNDMvMjcyOS8yNCBueHJl
>YWQgMTQzMzcyMDE0My8xNDMzNzIwMTQzLzQ1NjQgdHJ5ZXhjZXB0IDkvMi8wIGZvcmsgMTQzMzcy
>MDE0My8xNDMzNzIwMTQzLzM4MjkgZm9ya3Rvb211Y2ggMTQzMzcyMDE0My8xNDMzNzIwMTQzLzE0
>MzM3MjAxNDMgYWxsb2MgNTYvMTAvMSBjcmVhdCA2MTI0LzU5ODMvMzgxMyBsb2NrIDAvMC8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDE4NS81MDEwLzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjAxODUvMTk0MS84IG54cmVhZCAxNDMzNzIwMTg1LzE0MzM3MjAxODUvNDYwNiB0cnll
>eGNlcHQgMjIvMC8wIGZvcmsgMTQzMzcyMDE4NS8xNDMzNzIwMTg1LzM4NzEgZm9ya3Rvb211Y2gg
>MTQzMzcyMDE4NS8xNDMzNzIwMTg1LzE0MzM3MjAxODUgYWxsb2MgMzkvMTMvMyBjcmVhdCA2MTY2
>LzYwMjUvMzg1NSBsb2NrIDMvMi8yKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcy
>MDIxOC81MDQzLzAgKHRlc3RzOiByZWFkIDE0MzM3MjAyMTgvMTk3NC8xMiBueHJlYWQgMTQzMzcy
>MDIxOC8xNDMzNzIwMjE4LzQ2MzkgdHJ5ZXhjZXB0IDQvMi8wIGZvcmsgMTQzMzcyMDIxOC8xNDMz
>NzIwMjE4LzM5MDQgZm9ya3Rvb211Y2ggMTQzMzcyMDIxOC8xNDMzNzIwMjE4LzE0MzM3MjAyMTgg
>YWxsb2MgMTgvNy8xIGNyZWF0IDYxOTkvNjA1OC8zODg4IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIwMjYzLzUwODgvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDI2
>My8yMDE5LzQgbnhyZWFkIDE0MzM3MjAyNjMvMTQzMzcyMDI2My80Njg0IHRyeWV4Y2VwdCAxMy8y
>LzEgZm9yayAxNDMzNzIwMjYzLzE0MzM3MjAyNjMvMzk0OSBmb3JrdG9vbXVjaCAxNDMzNzIwMjYz
>LzE0MzM3MjAyNjMvMTQzMzcyMDI2MyBhbGxvYyA1Ny8xNC80IGNyZWF0IDYyNDQvNjEwMy8zOTMz
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwMzA1LzUxMzAv
>MCAodGVzdHM6IHJlYWQgMTQzMzcyMDMwNS8yMDYxLzExIG54cmVhZCAxNDMzNzIwMzA1LzE0MzM3
>MjAzMDUvNDcyNiB0cnlleGNlcHQgNS81LzAgZm9yayAxNDMzNzIwMzA1LzE0MzM3MjAzMDUvMzk5
>MSBmb3JrdG9vbXVjaCAxNDMzNzIwMzA1LzE0MzM3MjAzMDUvMTQzMzcyMDMwNSBhbGxvYyAzMi8x
>Ni81IGNyZWF0IDYyODYvNjE0NS8zOTc1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIwMzM1LzUxNjAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDMzNS8yMDkxLzIg
>bnhyZWFkIDE0MzM3MjAzMzUvMTQzMzcyMDMzNS80NzU2IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAx
>NDMzNzIwMzM1LzE0MzM3MjAzMzUvNDAyMSBmb3JrdG9vbXVjaCAxNDMzNzIwMzM1LzE0MzM3MjAz
>MzUvMTQzMzcyMDMzNSBhbGxvYyA0MS8xMC8yIGNyZWF0IDYzMTYvNjE3NS80MDA1IGxvY2sgMi8x
>LzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNDE1LzUxOTYvMCAodGVzdHM6
>IHJlYWQgMTQzMzcyMDQxNS8yMDUxLzE2IG54cmVhZCAxNDMzNzIwNDE1LzE0MzM3MjA0MTUvNDgz
>NiB0cnlleGNlcHQgMTgvMi8yIGZvcmsgMTQzMzcyMDQxNS8xNDMzNzIwNDE1LzQxMDEgZm9ya3Rv
>b211Y2ggMTQzMzcyMDQxNS8xNDMzNzIwNDE1LzE0MzM3MjA0MTUgYWxsb2MgNDkvMjUvNCBjcmVh
>dCA2Mzk2LzYyNTUvNDA4NSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMDQ0NS81MjA4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA0NDUvMTQyOC80IG54cmVhZCAx
>NDMzNzIwNDQ1LzE0MzM3MjA0NDUvNDg2NiB0cnlleGNlcHQgNDMvMi8xIGZvcmsgMTQzMzcyMDQ0
>NS8xNDMzNzIwNDQ1LzQxMzEgZm9ya3Rvb211Y2ggMTQzMzcyMDQ0NS8xNDMzNzIwNDQ1LzE0MzM3
>MjA0NDUgYWxsb2MgMzAvOC80IGNyZWF0IDY0MjYvNjI4NS80MTE1IGxvY2sgMC8wLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNDczLzUyMzYvMCAodGVzdHM6IHJlYWQgMTQz
>MzcyMDQ3My8xNDU2LzE2IG54cmVhZCAxNDMzNzIwNDczLzE0MzM3MjA0NzMvNDg5NCB0cnlleGNl
>cHQgNDIvMS8wIGZvcmsgMTQzMzcyMDQ3My8xNDMzNzIwNDczLzQxNTkgZm9ya3Rvb211Y2ggMTQz
>MzcyMDQ3My8xNDMzNzIwNDczLzE0MzM3MjA0NzMgYWxsb2MgNTgvMTYvMSBjcmVhdCA2NDU0LzYz
>MTMvNDE0MyBsb2NrIDEvMS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDUw
>OC81MjcxLzAgKHRlc3RzOiByZWFkIDE0MzM3MjA1MDgvMTQ5MS8xIG54cmVhZCAxNDMzNzIwNTA4
>LzE0MzM3MjA1MDgvNDkyOSB0cnlleGNlcHQgMTkvMi8wIGZvcmsgMTQzMzcyMDUwOC8xNDMzNzIw
>NTA4LzQxOTQgZm9ya3Rvb211Y2ggMTQzMzcyMDUwOC8xNDMzNzIwNTA4LzE0MzM3MjA1MDggYWxs
>b2MgNjcvMTMvMSBjcmVhdCA2NDg5LzYzNDgvNDE3OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDU1Ni81MzE5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA1NTYv
>MTUzOS8xIG54cmVhZCAxNDMzNzIwNTU2LzE0MzM3MjA1NTYvNDk3NyB0cnlleGNlcHQgMTgvMi8w
>IGZvcmsgMTQzMzcyMDU1Ni8xNDMzNzIwNTU2LzQyNDIgZm9ya3Rvb211Y2ggMTQzMzcyMDU1Ni8x
>NDMzNzIwNTU2LzE0MzM3MjA1NTYgYWxsb2MgMjYvNC8xIGNyZWF0IDY1MzcvNjM5Ni80MjI2IGxv
>Y2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNTg0LzUzNDcvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMDU4NC8xNTY3LzcgbnhyZWFkIDE0MzM3MjA1ODQvMTQzMzcyMDU4
>NC81MDA1IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MjA1ODQvMTQzMzcyMDU4NC80MjcwIGZv
>cmt0b29tdWNoIDE0MzM3MjA1ODQvMTQzMzcyMDU4NC8xNDMzNzIwNTg0IGFsbG9jIDMyLzcvMSBj
>cmVhdCA2NTY1LzY0MjQvNDI1NCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMDY0NS81NDA4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA2NDUvMTYyOC82IG54cmVh
>ZCAxNDMzNzIwNjQ1LzE0MzM3MjA2NDUvNTA2NiB0cnlleGNlcHQgMTQvMi8xIGZvcmsgMTQzMzcy
>MDY0NS8xNDMzNzIwNjQ1LzQzMzEgZm9ya3Rvb211Y2ggMTQzMzcyMDY0NS8xNDMzNzIwNjQ1LzE0
>MzM3MjA2NDUgYWxsb2MgNDAvMTMvNiBjcmVhdCA2NjI2LzY0ODUvNDMxNSBsb2NrIDUvNS8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDY4MC81NDQzLzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjA2ODAvMTY2My8zNSBueHJlYWQgMTQzMzcyMDY4MC8xNDMzNzIwNjgwLzUxMDEgdHJ5
>ZXhjZXB0IDEvMS8xIGZvcmsgMTQzMzcyMDY4MC8xNDMzNzIwNjgwLzQzNjYgZm9ya3Rvb211Y2gg
>MTQzMzcyMDY4MC8xNDMzNzIwNjgwLzE0MzM3MjA2ODAgYWxsb2MgNzUvMTMvMiBjcmVhdCA2NjYx
>LzY1MjAvNDM1MCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcy
>MDcxNC81NDc3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA3MTQvMTY5Ny8xMiBueHJlYWQgMTQzMzcy
>MDcxNC8xNDMzNzIwNzE0LzUxMzUgdHJ5ZXhjZXB0IDQvMi8wIGZvcmsgMTQzMzcyMDcxNC8xNDMz
>NzIwNzE0LzQ0MDAgZm9ya3Rvb211Y2ggMTQzMzcyMDcxNC8xNDMzNzIwNzE0LzE0MzM3MjA3MTQg
>YWxsb2MgMzQvMS8xIGNyZWF0IDY2OTUvNjU1NC80Mzg0IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNzQxLzU1MDQvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDc0
>MS8xNzI0LzIgbnhyZWFkIDE0MzM3MjA3NDEvMTQzMzcyMDc0MS81MTYyIHRyeWV4Y2VwdCA0LzAv
>MCBmb3JrIDE0MzM3MjA3NDEvMTQzMzcyMDc0MS80NDI3IGZvcmt0b29tdWNoIDE0MzM3MjA3NDEv
>MTQzMzcyMDc0MS8xNDMzNzIwNzQxIGFsbG9jIDM5LzIvMiBjcmVhdCA2NzIyLzY1ODEvNDQxMSBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDc2NS81NTI4LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjA3NjUvMTc0OC81IG54cmVhZCAxNDMzNzIwNzY1LzE0MzM3MjA3
>NjUvNTE4NiB0cnlleGNlcHQgNC8wLzAgZm9yayAxNDMzNzIwNzY1LzE0MzM3MjA3NjUvNDQ1MSBm
>b3JrdG9vbXVjaCAxNDMzNzIwNzY1LzE0MzM3MjA3NjUvMTQzMzcyMDc2NSBhbGxvYyAzNy8xNS8z
>IGNyZWF0IDY3NDYvNjYwNS80NDM1IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIwNzkwLzU1NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDc5MC8xNzczLzIyIG54
>cmVhZCAxNDMzNzIwNzkwLzE0MzM3MjA3OTAvNTIxMSB0cnlleGNlcHQgNS8xLzAgZm9yayAxNDMz
>NzIwNzkwLzE0MzM3MjA3OTAvNDQ3NiBmb3JrdG9vbXVjaCAxNDMzNzIwNzkwLzE0MzM3MjA3OTAv
>MTQzMzcyMDc5MCBhbGxvYyAzMC8xMS8yIGNyZWF0IDY3NzEvNjYzMC80NDYwIGxvY2sgMS8xLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwODI1LzU1ODgvMCAodGVzdHM6IHJl
>YWQgMTQzMzcyMDgyNS8xODA4LzI0IG54cmVhZCAxNDMzNzIwODI1LzE0MzM3MjA4MjUvNTI0NiB0
>cnlleGNlcHQgNS8xLzEgZm9yayAxNDMzNzIwODI1LzE0MzM3MjA4MjUvNDUxMSBmb3JrdG9vbXVj
>aCAxNDMzNzIwODI1LzE0MzM3MjA4MjUvMTQzMzcyMDgyNSBhbGxvYyA0Ni8xNS82IGNyZWF0IDY4
>MDYvNjY2NS80NDk1IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIwODUzLzU2MTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDg1My8xODM2LzEgbnhyZWFkIDE0MzM3
>MjA4NTMvMTQzMzcyMDg1My81Mjc0IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjA4NTMvMTQz
>MzcyMDg1My80NTM5IGZvcmt0b29tdWNoIDE0MzM3MjA4NTMvMTQzMzcyMDg1My8xNDMzNzIwODUz
>IGFsbG9jIDE2LzYvMSBjcmVhdCA2ODM0LzY2OTMvNDUyMyBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDg4Mi81NjQ1LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA4
>ODIvMTg2NS8xIG54cmVhZCAxNDMzNzIwODgyLzE0MzM3MjA4ODIvNTMwMyB0cnlleGNlcHQgMy8y
>LzAgZm9yayAxNDMzNzIwODgyLzE0MzM3MjA4ODIvNDU2OCBmb3JrdG9vbXVjaCAxNDMzNzIwODgy
>LzE0MzM3MjA4ODIvMTQzMzcyMDg4MiBhbGxvYyAzMC82LzEgY3JlYXQgNjg2My82NzIyLzQ1NTIg
>bG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjA5MjEvNTY4NC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIwOTIxLzE5MDQvMSBueHJlYWQgMTQzMzcyMDkyMS8xNDMzNzIw
>OTIxLzUzNDIgdHJ5ZXhjZXB0IDE0LzIvMCBmb3JrIDE0MzM3MjA5MjEvMTQzMzcyMDkyMS80NjA3
>IGZvcmt0b29tdWNoIDE0MzM3MjA5MjEvMTQzMzcyMDkyMS8xNDMzNzIwOTIxIGFsbG9jIDQ1LzE3
>LzEgY3JlYXQgNjkwMi82NzYxLzQ1OTEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MjA5NDYvNTcwOS8wICh0ZXN0czogcmVhZCAxNDMzNzIwOTQ2LzE5MjkvMTEg
>bnhyZWFkIDE0MzM3MjA5NDYvMTQzMzcyMDk0Ni81MzY3IHRyeWV4Y2VwdCAzOS8zLzAgZm9yayAx
>NDMzNzIwOTQ2LzE0MzM3MjA5NDYvNDYzMiBmb3JrdG9vbXVjaCAxNDMzNzIwOTQ2LzE0MzM3MjA5
>NDYvMTQzMzcyMDk0NiBhbGxvYyAyNi8xLzEgY3JlYXQgNjkyNy82Nzg2LzQ2MTYgbG9jayAxLzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjA5NzUvNTczOC8wICh0ZXN0czog
>cmVhZCAxNDMzNzIwOTc1LzE5NTgvMjYgbnhyZWFkIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS81Mzk2
>IHRyeWV4Y2VwdCA0LzIvMCBmb3JrIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS80NjYxIGZvcmt0b29t
>dWNoIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS8xNDMzNzIwOTc1IGFsbG9jIDI2LzEwLzEgY3JlYXQg
>Njk1Ni82ODE1LzQ2NDUgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjA5OTQvNTc1Ny8wICh0ZXN0czogcmVhZCAxNDMzNzIwOTk0LzE5NzcvMTYgbnhyZWFkIDE0
>MzM3MjA5OTQvMTQzMzcyMDk5NC81NDE1IHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzIwOTk0
>LzE0MzM3MjA5OTQvNDY4MCBmb3JrdG9vbXVjaCAxNDMzNzIwOTk0LzE0MzM3MjA5OTQvMTQzMzcy
>MDk5NCBhbGxvYyAzNC8xMC8yIGNyZWF0IDY5NzUvNjgzNC80NjY0IGxvY2sgMy8zLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxMDE2LzU3NzkvMCAodGVzdHM6IHJlYWQgMTQz
>MzcyMTAxNi8xOTk5LzIgbnhyZWFkIDE0MzM3MjEwMTYvMTQzMzcyMTAxNi81NDM3IHRyeWV4Y2Vw
>dCA0LzQvMCBmb3JrIDE0MzM3MjEwMTYvMTQzMzcyMTAxNi80NzAyIGZvcmt0b29tdWNoIDE0MzM3
>MjEwMTYvMTQzMzcyMTAxNi8xNDMzNzIxMDE2IGFsbG9jIDU2LzEwLzIgY3JlYXQgNjk5Ny82ODU2
>LzQ2ODYgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEwODAv
>NTg0My8wICh0ZXN0czogcmVhZCAxNDMzNzIxMDgwLzc0Ny8yIG54cmVhZCAxNDMzNzIxMDgwLzE0
>MzM3MjEwODAvNTUwMSB0cnlleGNlcHQgMy8xLzAgZm9yayAxNDMzNzIxMDgwLzE0MzM3MjEwODAv
>NDc2NiBmb3JrdG9vbXVjaCAxNDMzNzIxMDgwLzE0MzM3MjEwODAvMTQzMzcyMTA4MCBhbGxvYyA0
>Ni8zLzIgY3JlYXQgNzA2MS82OTIwLzQ3NTAgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MjExMDYvNTg2OS8wICh0ZXN0czogcmVhZCAxNDMzNzIxMTA2Lzc3My8x
>NyBueHJlYWQgMTQzMzcyMTEwNi8xNDMzNzIxMTA2LzU1MjcgdHJ5ZXhjZXB0IDE4LzEvMSBmb3Jr
>IDE0MzM3MjExMDYvMTQzMzcyMTEwNi80NzkyIGZvcmt0b29tdWNoIDE0MzM3MjExMDYvMTQzMzcy
>MTEwNi8xNDMzNzIxMTA2IGFsbG9jIDQ3LzEzLzAgY3JlYXQgNzA4Ny82OTQ2LzQ3NzYgbG9jayAy
>LzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjExNDEvNTkwNC8wICh0ZXN0
>czogcmVhZCAxNDMzNzIxMTQxLzgwOC8xNyBueHJlYWQgMTQzMzcyMTE0MS8xNDMzNzIxMTQxLzU1
>NjIgdHJ5ZXhjZXB0IDI2LzAvMCBmb3JrIDE0MzM3MjExNDEvMTQzMzcyMTE0MS80ODI3IGZvcmt0
>b29tdWNoIDE0MzM3MjExNDEvMTQzMzcyMTE0MS8xNDMzNzIxMTQxIGFsbG9jIDU2LzExLzEgY3Jl
>YXQgNzEyMi82OTgxLzQ4MTEgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MjExNzQvNTkzNy8wICh0ZXN0czogcmVhZCAxNDMzNzIxMTc0Lzg0MS8xMCBueHJlYWQg
>MTQzMzcyMTE3NC8xNDMzNzIxMTc0LzU1OTUgdHJ5ZXhjZXB0IDEyLzIvMSBmb3JrIDE0MzM3MjEx
>NzQvMTQzMzcyMTE3NC80ODYwIGZvcmt0b29tdWNoIDE0MzM3MjExNzQvMTQzMzcyMTE3NC8xNDMz
>NzIxMTc0IGFsbG9jIDYwLzIwLzAgY3JlYXQgNzE1NS83MDE0LzQ4NDQgbG9jayAzLzMvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEyMDIvNTk2NS8wICh0ZXN0czogcmVhZCAx
>NDMzNzIxMjAyLzg2OS8zOCBueHJlYWQgMTQzMzcyMTIwMi8xNDMzNzIxMjAyLzU2MjMgdHJ5ZXhj
>ZXB0IDM2LzMvMCBmb3JrIDE0MzM3MjEyMDIvMTQzMzcyMTIwMi80ODg4IGZvcmt0b29tdWNoIDE0
>MzM3MjEyMDIvMTQzMzcyMTIwMi8xNDMzNzIxMjAyIGFsbG9jIDU4LzIwLzIgY3JlYXQgNzE4My83
>MDQyLzQ4NzIgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEy
>MzAvNTk5My8wICh0ZXN0czogcmVhZCAxNDMzNzIxMjMwLzg5Ny8xNSBueHJlYWQgMTQzMzcyMTIz
>MC8xNDMzNzIxMjMwLzU2NTEgdHJ5ZXhjZXB0IDMxLzIvMCBmb3JrIDE0MzM3MjEyMzAvMTQzMzcy
>MTIzMC80OTE2IGZvcmt0b29tdWNoIDE0MzM3MjEyMzAvMTQzMzcyMTIzMC8xNDMzNzIxMjMwIGFs
>bG9jIDg2LzE1LzEgY3JlYXQgNzIxMS83MDcwLzQ5MDAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MjEyNTYvNjAxOS8wICh0ZXN0czogcmVhZCAxNDMzNzIxMjU2
>LzkyMy81IG54cmVhZCAxNDMzNzIxMjU2LzE0MzM3MjEyNTYvNTY3NyB0cnlleGNlcHQgMTQvMi8x
>IGZvcmsgMTQzMzcyMTI1Ni8xNDMzNzIxMjU2LzQ5NDIgZm9ya3Rvb211Y2ggMTQzMzcyMTI1Ni8x
>NDMzNzIxMjU2LzE0MzM3MjEyNTYgYWxsb2MgNDUvMTMvNSBjcmVhdCA3MjM3LzcwOTYvNDkyNiBs
>b2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTI4MC82MDQzLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjEyODAvOTQ3LzEgbnhyZWFkIDE0MzM3MjEyODAvMTQzMzcyMTI4
>MC8xIHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjEyODAvMTQzMzcyMTI4MC80OTY2IGZvcmt0
>b29tdWNoIDE0MzM3MjEyODAvMTQzMzcyMTI4MC8xNDMzNzIxMjgwIGFsbG9jIDUxLzEvMSBjcmVh
>dCA3MjYxLzcxMjAvNDk1MCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMTMwNC82MDY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjEzMDQvOTcxLzI1IG54cmVhZCAx
>NDMzNzIxMzA0LzE0MzM3MjEzMDQvMTQgdHJ5ZXhjZXB0IDQvMC8wIGZvcmsgMTQzMzcyMTMwNC8x
>NDMzNzIxMzA0LzQ5OTAgZm9ya3Rvb211Y2ggMTQzMzcyMTMwNC8xNDMzNzIxMzA0LzE0MzM3MjEz
>MDQgYWxsb2MgMjUvNC8yIGNyZWF0IDcyODUvNzE0NC80OTc0IGxvY2sgNC8yLzIpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxMzM4LzYxMDEvMCAodGVzdHM6IHJlYWQgMTQzMzcy
>MTMzOC8xMDA1LzU5IG54cmVhZCAxNDMzNzIxMzM4LzE0MzM3MjEzMzgvNDggdHJ5ZXhjZXB0IDMw
>LzIvMCBmb3JrIDE0MzM3MjEzMzgvMTQzMzcyMTMzOC81MDI0IGZvcmt0b29tdWNoIDE0MzM3MjEz
>MzgvMTQzMzcyMTMzOC8xNDMzNzIxMzM4IGFsbG9jIDQzLzExLzAgY3JlYXQgNzMxOS83MTc4LzUw
>MDggbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEzODMvNjE0
>Ni8wICh0ZXN0czogcmVhZCAxNDMzNzIxMzgzLzEwNTAvNCBueHJlYWQgMTQzMzcyMTM4My8xNDMz
>NzIxMzgzLzkzIHRyeWV4Y2VwdCAxNC8yLzEgZm9yayAxNDMzNzIxMzgzLzE0MzM3MjEzODMvNTA2
>OSBmb3JrdG9vbXVjaCAxNDMzNzIxMzgzLzE0MzM3MjEzODMvMTQzMzcyMTM4MyBhbGxvYyA0NS8x
>Ny80IGNyZWF0IDczNjQvNzIyMy81MDUzIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIxNDE4LzYxODEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTQxOC8xMDg1Lzcg
>bnhyZWFkIDE0MzM3MjE0MTgvMTQzMzcyMTQxOC8xMjggdHJ5ZXhjZXB0IDIyLzEvMCBmb3JrIDE0
>MzM3MjE0MTgvMTQzMzcyMTQxOC81MTA0IGZvcmt0b29tdWNoIDE0MzM3MjE0MTgvMTQzMzcyMTQx
>OC8xNDMzNzIxNDE4IGFsbG9jIDc2LzI0LzMgY3JlYXQgNzM5OS83MjU4LzUwODggbG9jayAxLzEv
>MSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE0NTQvNjIxNy8wICh0ZXN0czog
>cmVhZCAxNDMzNzIxNDU0LzExMjEvMTEgbnhyZWFkIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC8xNjQg
>dHJ5ZXhjZXB0IDI3LzIvMCBmb3JrIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC81MTQwIGZvcmt0b29t
>dWNoIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC8xNDMzNzIxNDU0IGFsbG9jIDQzLzExLzEgY3JlYXQg
>NzQzNS83Mjk0LzUxMjQgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjE0ODkvNjI1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIxNDg5LzExNTYvMiBueHJlYWQgMTQz
>MzcyMTQ4OS8xNDMzNzIxNDg5LzE5OSB0cnlleGNlcHQgNjIvMS8xIGZvcmsgMTQzMzcyMTQ4OS8x
>NDMzNzIxNDg5LzUxNzUgZm9ya3Rvb211Y2ggMTQzMzcyMTQ4OS8xNDMzNzIxNDg5LzE0MzM3MjE0
>ODkgYWxsb2MgNDYvMTEvMiBjcmVhdCA3NDcwLzczMjkvNTE1OSBsb2NrIDIvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTUyMy82Mjg2LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MjE1MjMvMTE5MC8yNCBueHJlYWQgMTQzMzcyMTUyMy8xNDMzNzIxNTIzLzIzMyB0cnlleGNlcHQg
>NC8yLzEgZm9yayAxNDMzNzIxNTIzLzE0MzM3MjE1MjMvNTIwOSBmb3JrdG9vbXVjaCAxNDMzNzIx
>NTIzLzE0MzM3MjE1MjMvMTQzMzcyMTUyMyBhbGxvYyAyMC8xMC8wIGNyZWF0IDc1MDQvNzM2My81
>MTkzIGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxNTQ3LzYz
>MTAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTU0Ny8xMjE0LzQ4IG54cmVhZCAxNDMzNzIxNTQ3LzE0
>MzM3MjE1NDcvMjU3IHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0MzM3MjE1NDcvMTQzMzcyMTU0Ny81
>MjMzIGZvcmt0b29tdWNoIDE0MzM3MjE1NDcvMTQzMzcyMTU0Ny8xNDMzNzIxNTQ3IGFsbG9jIDQ0
>LzE5LzUgY3JlYXQgNzUyOC83Mzg3LzUyMTcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MjE1NjkvNjMzMi8wICh0ZXN0czogcmVhZCAxNDMzNzIxNTY5LzEyMzYv
>OSBueHJlYWQgMTQzMzcyMTU2OS8xNDMzNzIxNTY5LzI3OSB0cnlleGNlcHQgMi8yLzAgZm9yayAx
>NDMzNzIxNTY5LzE0MzM3MjE1NjkvNTI1NSBmb3JrdG9vbXVjaCAxNDMzNzIxNTY5LzE0MzM3MjE1
>NjkvMTQzMzcyMTU2OSBhbGxvYyAxNy85LzEgY3JlYXQgNzU1MC83NDA5LzUyMzkgbG9jayAwLzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE2MDIvNjM2NS8wICh0ZXN0czog
>cmVhZCAxNDMzNzIxNjAyLzEyNjkvMSBueHJlYWQgMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzMxMiB0
>cnlleGNlcHQgMjcvMi8wIGZvcmsgMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzUyODggZm9ya3Rvb211
>Y2ggMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzE0MzM3MjE2MDIgYWxsb2MgNTAvNS8xIGNyZWF0IDc1
>ODMvNzQ0Mi81MjcyIGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIxNjMzLzYzOTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTYzMy8xMzAwLzE1IG54cmVhZCAxNDMz
>NzIxNjMzLzE0MzM3MjE2MzMvMzQzIHRyeWV4Y2VwdCA0MS8yLzAgZm9yayAxNDMzNzIxNjMzLzE0
>MzM3MjE2MzMvNTMxOSBmb3JrdG9vbXVjaCAxNDMzNzIxNjMzLzE0MzM3MjE2MzMvMTQzMzcyMTYz
>MyBhbGxvYyA1MS81LzEgY3JlYXQgNzYxNC83NDczLzUzMDMgbG9jayAwLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE2NzkvNjQ0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIx
>Njc5LzEzNDYvMjAgbnhyZWFkIDE0MzM3MjE2NzkvMTQzMzcyMTY3OS8zODkgdHJ5ZXhjZXB0IDE1
>LzEvMSBmb3JrIDE0MzM3MjE2NzkvMTQzMzcyMTY3OS81MzY1IGZvcmt0b29tdWNoIDE0MzM3MjE2
>NzkvMTQzMzcyMTY3OS8xNDMzNzIxNjc5IGFsbG9jIDcwLzkvNCBjcmVhdCA3NjYwLzc1MTkvNTM0
>OSBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTcxOC82NDgx
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MjE3MTgvMTMzMS8xIG54cmVhZCAxNDMzNzIxNzE4LzE0MzM3
>MjE3MTgvNDI4IHRyeWV4Y2VwdCAxMS8zLzAgZm9yayAxNDMzNzIxNzE4LzE0MzM3MjE3MTgvNTQw
>NCBmb3JrdG9vbXVjaCAxNDMzNzIxNzE4LzE0MzM3MjE3MTgvMTQzMzcyMTcxOCBhbGxvYyA0OC8x
>Ny8xIGNyZWF0IDc2OTkvNzU1OC81Mzg4IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIxNzU2LzU0NTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTc1Ni83NDIvOCBu
>eHJlYWQgMTQzMzcyMTc1Ni8xNDMzNzIxNzU2LzQ2NiB0cnlleGNlcHQgMTYvMC8wIGZvcmsgMTQz
>MzcyMTc1Ni8xNDMzNzIxNzU2LzU0NDIgZm9ya3Rvb211Y2ggMTQzMzcyMTc1Ni8xNDMzNzIxNzU2
>LzE0MzM3MjE3NTYgYWxsb2MgNTUvOC8xIGNyZWF0IDc3MzcvNzU5Ni81NDI2IGxvY2sgMS8xLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxNzg4LzU0ODgvMCAodGVzdHM6IHJl
>YWQgMTQzMzcyMTc4OC83NzQvMTAgbnhyZWFkIDE0MzM3MjE3ODgvMTQzMzcyMTc4OC80OTggdHJ5
>ZXhjZXB0IDgvMi8wIGZvcmsgMTQzMzcyMTc4OC8xNDMzNzIxNzg4LzU0NzQgZm9ya3Rvb211Y2gg
>MTQzMzcyMTc4OC8xNDMzNzIxNzg4LzE0MzM3MjE3ODggYWxsb2MgMjgvMS8xIGNyZWF0IDc3Njkv
>NzYyOC81NDU4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIx
>ODIyLzU1MjIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTgyMi83NjgvMTQgbnhyZWFkIDE0MzM3MjE4
>MjIvMTQzMzcyMTgyMi81MzIgdHJ5ZXhjZXB0IDIyLzIvMSBmb3JrIDE0MzM3MjE4MjIvMTQzMzcy
>MTgyMi81NTA4IGZvcmt0b29tdWNoIDE0MzM3MjE4MjIvMTQzMzcyMTgyMi8xNDMzNzIxODIyIGFs
>bG9jIDM1LzgvNCBjcmVhdCA3ODAzLzc2NjIvNTQ5MiBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTg4Ny81NTg3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjE4ODcv
>MjA4LzE5IG54cmVhZCAxNDMzNzIxODg3LzE0MzM3MjE4ODcvNTk3IHRyeWV4Y2VwdCAyOS8yLzAg
>Zm9yayAxNDMzNzIxODg3LzE0MzM3MjE4ODcvNTU3MyBmb3JrdG9vbXVjaCAxNDMzNzIxODg3LzE0
>MzM3MjE4ODcvMTQzMzcyMTg4NyBhbGxvYyA3OS8xMC8xIGNyZWF0IDc4NjgvNzcyNy81NTU3IGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxOTEyLzU2MTIvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMTkxMi8yMzMvMTIgbnhyZWFkIDE0MzM3MjE5MTIvMTQzMzcyMTkx
>Mi82MjIgdHJ5ZXhjZXB0IDQwLzEvMSBmb3JrIDE0MzM3MjE5MTIvMTQzMzcyMTkxMi81NTk4IGZv
>cmt0b29tdWNoIDE0MzM3MjE5MTIvMTQzMzcyMTkxMi8xNDMzNzIxOTEyIGFsbG9jIDM5LzEyLzAg
>Y3JlYXQgNzg5My83NzUyLzU1ODIgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MjE5NTIvNTY1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIxOTUyLzI3My8xMiBueHJl
>YWQgMTQzMzcyMTk1Mi8xNDMzNzIxOTUyLzY2MiB0cnlleGNlcHQgNi8xLzEgZm9yayAxNDMzNzIx
>OTUyLzE0MzM3MjE5NTIvNTYzOCBmb3JrdG9vbXVjaCAxNDMzNzIxOTUyLzE0MzM3MjE5NTIvMTQz
>MzcyMTk1MiBhbGxvYyA3OS8xMi81IGNyZWF0IDc5MzMvNzc5Mi81NjIyIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxOTc4LzU2NzgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMTk3OC8yOTkvNiBueHJlYWQgMTQzMzcyMTk3OC8xNDMzNzIxOTc4LzY4OCB0cnlleGNl
>cHQgNy8zLzEgZm9yayAxNDMzNzIxOTc4LzE0MzM3MjE5NzgvNTY2NCBmb3JrdG9vbXVjaCAxNDMz
>NzIxOTc4LzE0MzM3MjE5NzgvMTQzMzcyMTk3OCBhbGxvYyAxMDUvMTYvNiBjcmVhdCA3OTU5Lzc4
>MTgvNTY0OCBsb2NrIDYvNi8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjAw
>OS81NzA5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjIwMDkvMzMwLzI0IG54cmVhZCAxNDMzNzIyMDA5
>LzE0MzM3MjIwMDkvNzE5IHRyeWV4Y2VwdCAzOC8yLzEgZm9yayAxNDMzNzIyMDA5LzE0MzM3MjIw
>MDkvNTY5NSBmb3JrdG9vbXVjaCAxNDMzNzIyMDA5LzE0MzM3MjIwMDkvMTQzMzcyMjAwOSBhbGxv
>YyAyMC84LzUgY3JlYXQgNzk5MC83ODQ5LzU2NzkgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjIwMzYvNTczNi8wICh0ZXN0czogcmVhZCAxNDMzNzIyMDM2LzM1
>Ny8xIG54cmVhZCAxNDMzNzIyMDM2LzE0MzM3MjIwMzYvNzQ2IHRyeWV4Y2VwdCAyOS8wLzAgZm9y
>ayAxNDMzNzIyMDM2LzE0MzM3MjIwMzYvNTcyMiBmb3JrdG9vbXVjaCAxNDMzNzIyMDM2LzE0MzM3
>MjIwMzYvMTQzMzcyMjAzNiBhbGxvYyAzNS8xMS8xIGNyZWF0IDgwMTcvNzg3Ni81NzA2IGxvY2sg
>MS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMDYxLzU3NjEvMCAodGVz
>dHM6IHJlYWQgMTQzMzcyMjA2MS8zODIvMTkgbnhyZWFkIDE0MzM3MjIwNjEvMTQzMzcyMjA2MS83
>NzEgdHJ5ZXhjZXB0IDYvMS8wIGZvcmsgMTQzMzcyMjA2MS8xNDMzNzIyMDYxLzU3NDcgZm9ya3Rv
>b211Y2ggMTQzMzcyMjA2MS8xNDMzNzIyMDYxLzE0MzM3MjIwNjEgYWxsb2MgNjAvMjIvMyBjcmVh
>dCA4MDQyLzc5MDEvNTczMSBsb2NrIDMvMi8yKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMjEwNi81ODA2LzAgKHRlc3RzOiByZWFkIDE0MzM3MjIxMDYvNDI3LzI4IG54cmVhZCAx
>NDMzNzIyMTA2LzE0MzM3MjIxMDYvODE2IHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzIyMTA2
>LzE0MzM3MjIxMDYvNTc5MiBmb3JrdG9vbXVjaCAxNDMzNzIyMTA2LzE0MzM3MjIxMDYvMTQzMzcy
>MjEwNiBhbGxvYyA0MC82LzYgY3JlYXQgODA4Ny83OTQ2LzU3NzYgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIxMjkvNTgyOS8wICh0ZXN0czogcmVhZCAxNDMz
>NzIyMTI5LzQ1MC8xNCBueHJlYWQgMTQzMzcyMjEyOS8xNDMzNzIyMTI5LzgzOSB0cnlleGNlcHQg
>MTUvMS8wIGZvcmsgMTQzMzcyMjEyOS8xNDMzNzIyMTI5LzU4MTUgZm9ya3Rvb211Y2ggMTQzMzcy
>MjEyOS8xNDMzNzIyMTI5LzE0MzM3MjIxMjkgYWxsb2MgMjkvOC8xIGNyZWF0IDgxMTAvNzk2OS81
>Nzk5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMTUyLzU4
>NTIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjE1Mi80NzMvNCBueHJlYWQgMTQzMzcyMjE1Mi8xNDMz
>NzIyMTUyLzg2MiB0cnlleGNlcHQgMzMvMi8wIGZvcmsgMTQzMzcyMjE1Mi8xNDMzNzIyMTUyLzU4
>MzggZm9ya3Rvb211Y2ggMTQzMzcyMjE1Mi8xNDMzNzIyMTUyLzE0MzM3MjIxNTIgYWxsb2MgMzcv
>OC8xIGNyZWF0IDgxMzMvNzk5Mi81ODIyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIyMTcwLzU4NzAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjE3MC80OTEvMyBu
>eHJlYWQgMTQzMzcyMjE3MC8xNDMzNzIyMTcwLzg4MCB0cnlleGNlcHQgMTMvMS8wIGZvcmsgMTQz
>MzcyMjE3MC8xNDMzNzIyMTcwLzU4NTYgZm9ya3Rvb211Y2ggMTQzMzcyMjE3MC8xNDMzNzIyMTcw
>LzE0MzM3MjIxNzAgYWxsb2MgNTUvMTkvMyBjcmVhdCA4MTUxLzgwMTAvNTg0MCBsb2NrIDIvMi8y
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjE5NC81ODk0LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MjIxOTQvNTE1LzI3IG54cmVhZCAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvOTA0IHRy
>eWV4Y2VwdCAzNC8yLzEgZm9yayAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvNTg4MCBmb3JrdG9vbXVj
>aCAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvMTQzMzcyMjE5NCBhbGxvYyA3OS8xNi82IGNyZWF0IDgx
>NzUvODAzNC81ODY0IGxvY2sgNi82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIyMjM2LzU5MzYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjIzNi81NTcvMTEgbnhyZWFkIDE0MzM3
>MjIyMzYvMTQzMzcyMjIzNi85NDYgdHJ5ZXhjZXB0IDcwLzIvMSBmb3JrIDE0MzM3MjIyMzYvMTQz
>MzcyMjIzNi81OTIyIGZvcmt0b29tdWNoIDE0MzM3MjIyMzYvMTQzMzcyMjIzNi8xNDMzNzIyMjM2
>IGFsbG9jIDU4LzE1LzUgY3JlYXQgODIxNy84MDc2LzU5MDYgbG9jayA1LzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIyNzIvNTk3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIy
>MjcyLzU5My81IG54cmVhZCAxNDMzNzIyMjcyLzE0MzM3MjIyNzIvOTgyIHRyeWV4Y2VwdCA1LzEv
>MSBmb3JrIDE0MzM3MjIyNzIvMTQzMzcyMjI3Mi81OTU4IGZvcmt0b29tdWNoIDE0MzM3MjIyNzIv
>MTQzMzcyMjI3Mi8xNDMzNzIyMjcyIGFsbG9jIDI2LzExLzUgY3JlYXQgODI1My84MTEyLzU5NDIg
>bG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIzMDAvNjAwMC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIyMzAwLzYyMS8yOCBueHJlYWQgMTQzMzcyMjMwMC8xNDMzNzIy
>MzAwLzEwMTAgdHJ5ZXhjZXB0IDMvMS8wIGZvcmsgMTQzMzcyMjMwMC8xNDMzNzIyMzAwLzU5ODYg
>Zm9ya3Rvb211Y2ggMTQzMzcyMjMwMC8xNDMzNzIyMzAwLzE0MzM3MjIzMDAgYWxsb2MgMjgvNi8x
>IGNyZWF0IDgyODEvODE0MC81OTcwIGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIyMzMxLzYwMzEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjMzMS82NTIvMSBueHJl
>YWQgMTQzMzcyMjMzMS8xNDMzNzIyMzMxLzEwNDEgdHJ5ZXhjZXB0IDMvMi8wIGZvcmsgMTQzMzcy
>MjMzMS8xNDMzNzIyMzMxLzYwMTcgZm9ya3Rvb211Y2ggMTQzMzcyMjMzMS8xNDMzNzIyMzMxLzE0
>MzM3MjIzMzEgYWxsb2MgMTcvMS8xIGNyZWF0IDgzMTIvODE3MS82MDAxIGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMzY3LzYwNjcvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMjM2Ny82ODgvMTQgbnhyZWFkIDE0MzM3MjIzNjcvMTQzMzcyMjM2Ny8xMDc3IHRyeWV4
>Y2VwdCAyMC8yLzAgZm9yayAxNDMzNzIyMzY3LzE0MzM3MjIzNjcvNjA1MyBmb3JrdG9vbXVjaCAx
>NDMzNzIyMzY3LzE0MzM3MjIzNjcvMTQzMzcyMjM2NyBhbGxvYyAzNy8xOS8xIGNyZWF0IDgzNDgv
>ODIwNy82MDM3IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIy
>NDAzLzYxMDMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjQwMy83MjQvNTAgbnhyZWFkIDE0MzM3MjI0
>MDMvMTQzMzcyMjQwMy8xMTEzIHRyeWV4Y2VwdCAxNC8yLzIgZm9yayAxNDMzNzIyNDAzLzE0MzM3
>MjI0MDMvNjA4OSBmb3JrdG9vbXVjaCAxNDMzNzIyNDAzLzE0MzM3MjI0MDMvMTQzMzcyMjQwMyBh
>bGxvYyAzMi82LzYgY3JlYXQgODM4NC84MjQzLzYwNzMgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MjI0MzEvNjEzMS8wICh0ZXN0czogcmVhZCAxNDMzNzIyNDMx
>Lzc1Mi8xOCBueHJlYWQgMTQzMzcyMjQzMS8xNDMzNzIyNDMxLzExNDEgdHJ5ZXhjZXB0IDYvMi8x
>IGZvcmsgMTQzMzcyMjQzMS8xNDMzNzIyNDMxLzYxMTcgZm9ya3Rvb211Y2ggMTQzMzcyMjQzMS8x
>NDMzNzIyNDMxLzE0MzM3MjI0MzEgYWxsb2MgMzQvNS81IGNyZWF0IDg0MTIvODI3MS82MTAxIGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyNDU4LzYxNTgvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMjQ1OC83NzkvNSBueHJlYWQgMTQzMzcyMjQ1OC8xNDMzNzIyNDU4
>LzExNjggdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcyMjQ1OC8xNDMzNzIyNDU4LzYxNDQgZm9y
>a3Rvb211Y2ggMTQzMzcyMjQ1OC8xNDMzNzIyNDU4LzE0MzM3MjI0NTggYWxsb2MgMzIvMTIvMSBj
>cmVhdCA4NDM5LzgyOTgvNjEyOCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMjQ5NC82MTk0LzAgKHRlc3RzOiByZWFkIDE0MzM3MjI0OTQvODE1LzIgbnhyZWFk
>IDE0MzM3MjI0OTQvMTQzMzcyMjQ5NC8xMjA0IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MjI0
>OTQvMTQzMzcyMjQ5NC82MTgwIGZvcmt0b29tdWNoIDE0MzM3MjI0OTQvMTQzMzcyMjQ5NC8xNDMz
>NzIyNDk0IGFsbG9jIDYzLzEyLzIgY3JlYXQgODQ3NS84MzM0LzYxNjQgbG9jayAxLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI1NDAvNjI0MC8wICh0ZXN0czogcmVhZCAx
>NDMzNzIyNTQwLzg2MS82IG54cmVhZCAxNDMzNzIyNTQwLzE0MzM3MjI1NDAvMTI1MCB0cnlleGNl
>cHQgMi8yLzAgZm9yayAxNDMzNzIyNTQwLzE0MzM3MjI1NDAvNjIyNiBmb3JrdG9vbXVjaCAxNDMz
>NzIyNTQwLzE0MzM3MjI1NDAvMTQzMzcyMjU0MCBhbGxvYyAxMC8xLzEgY3JlYXQgODUyMS84Mzgw
>LzYyMTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI1ODUv
>NjI4NS8wICh0ZXN0czogcmVhZCAxNDMzNzIyNTg1LzkwNi83IG54cmVhZCAxNDMzNzIyNTg1LzE0
>MzM3MjI1ODUvMTI5NSB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzIyNTg1LzE0MzM3MjI1ODUv
>NjI3MSBmb3JrdG9vbXVjaCAxNDMzNzIyNTg1LzE0MzM3MjI1ODUvMTQzMzcyMjU4NSBhbGxvYyAz
>OC8xMi83IGNyZWF0IDg1NjYvODQyNS82MjU1IGxvY2sgNy83LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzIyNjEwLzYzMTAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjYxMC85MzEv
>MTAgbnhyZWFkIDE0MzM3MjI2MTAvMTQzMzcyMjYxMC8xMzIwIHRyeWV4Y2VwdCA0LzIvMSBmb3Jr
>IDE0MzM3MjI2MTAvMTQzMzcyMjYxMC82Mjk2IGZvcmt0b29tdWNoIDE0MzM3MjI2MTAvMTQzMzcy
>MjYxMC8xNDMzNzIyNjEwIGFsbG9jIDYzLzE1LzUgY3JlYXQgODU5MS84NDUwLzYyODAgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI2NjkvNjM2OS8wICh0ZXN0
>czogcmVhZCAxNDMzNzIyNjY5Lzk5MC8xIG54cmVhZCAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvMTM3
>OSB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvNjM1NSBmb3JrdG9v
>bXVjaCAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvMTQzMzcyMjY2OSBhbGxvYyA0Ny8xLzEgY3JlYXQg
>ODY1MC84NTA5LzYzMzkgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjI2OTMvNjM5My8wICh0ZXN0czogcmVhZCAxNDMzNzIyNjkzLzEwMTQvMTQgbnhyZWFkIDE0
>MzM3MjI2OTMvMTQzMzcyMjY5My8xNDAzIHRyeWV4Y2VwdCA4LzIvMSBmb3JrIDE0MzM3MjI2OTMv
>MTQzMzcyMjY5My82Mzc5IGZvcmt0b29tdWNoIDE0MzM3MjI2OTMvMTQzMzcyMjY5My8xNDMzNzIy
>NjkzIGFsbG9jIDU2LzE0LzcgY3JlYXQgODY3NC84NTMzLzYzNjMgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI3MTYvNjQxNi8wICh0ZXN0czogcmVhZCAxNDMz
>NzIyNzE2LzEwMzcvMTQgbnhyZWFkIDE0MzM3MjI3MTYvMTQzMzcyMjcxNi8xNDI2IHRyeWV4Y2Vw
>dCAzMS84LzEgZm9yayAxNDMzNzIyNzE2LzE0MzM3MjI3MTYvNjQwMiBmb3JrdG9vbXVjaCAxNDMz
>NzIyNzE2LzE0MzM3MjI3MTYvMTQzMzcyMjcxNiBhbGxvYyAzOC84LzIgY3JlYXQgODY5Ny84NTU2
>LzYzODYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI3Mzcv
>NjQzNy8wICh0ZXN0czogcmVhZCAxNDMzNzIyNzM3LzEwNTgvMzUgbnhyZWFkIDE0MzM3MjI3Mzcv
>MTQzMzcyMjczNy8xNDQ3IHRyeWV4Y2VwdCAzMS8xLzEgZm9yayAxNDMzNzIyNzM3LzE0MzM3MjI3
>MzcvNjQyMyBmb3JrdG9vbXVjaCAxNDMzNzIyNzM3LzE0MzM3MjI3MzcvMTQzMzcyMjczNyBhbGxv
>YyA1OC8yMS80IGNyZWF0IDg3MTgvODU3Ny82NDA3IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIyNzc3LzY0NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjc3Ny8x
>MDk4LzIwIG54cmVhZCAxNDMzNzIyNzc3LzE0MzM3MjI3NzcvMTQ4NyB0cnlleGNlcHQgMjgvMy8x
>IGZvcmsgMTQzMzcyMjc3Ny8xNDMzNzIyNzc3LzY0NjMgZm9ya3Rvb211Y2ggMTQzMzcyMjc3Ny8x
>NDMzNzIyNzc3LzE0MzM3MjI3NzcgYWxsb2MgNjkvMjMvNSBjcmVhdCA4NzU4Lzg2MTcvNjQ0NyBs
>b2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjgwMy82NTAzLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjI4MDMvMTA1NS8yIG54cmVhZCAxNDMzNzIyODAzLzE0MzM3MjI4
>MDMvMTUxMyB0cnlleGNlcHQgNy8zLzAgZm9yayAxNDMzNzIyODAzLzE0MzM3MjI4MDMvNjQ4OSBm
>b3JrdG9vbXVjaCAxNDMzNzIyODAzLzE0MzM3MjI4MDMvMTQzMzcyMjgwMyBhbGxvYyA5NS8yMy8y
>IGNyZWF0IDg3ODQvODY0My82NDczIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIyODMzLzY1MzMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjgzMy8xMDg1LzIgbnhy
>ZWFkIDE0MzM3MjI4MzMvMTQzMzcyMjgzMy8xNTQzIHRyeWV4Y2VwdCA0LzEvMSBmb3JrIDE0MzM3
>MjI4MzMvMTQzMzcyMjgzMy82NTE5IGZvcmt0b29tdWNoIDE0MzM3MjI4MzMvMTQzMzcyMjgzMy8x
>NDMzNzIyODMzIGFsbG9jIDI2LzYvMiBjcmVhdCA4ODE0Lzg2NzMvNjUwMyBsb2NrIDAvMC8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjg1Ni82NTU2LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjI4NTYvMTEwOC8xOSBueHJlYWQgMTQzMzcyMjg1Ni8xNDMzNzIyODU2LzE1NjYgdHJ5
>ZXhjZXB0IDI2LzIvMiBmb3JrIDE0MzM3MjI4NTYvMTQzMzcyMjg1Ni82NTQyIGZvcmt0b29tdWNo
>IDE0MzM3MjI4NTYvMTQzMzcyMjg1Ni8xNDMzNzIyODU2IGFsbG9jIDQ5LzE5LzcgY3JlYXQgODgz
>Ny84Njk2LzY1MjYgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MjI4ODQvNjU4NC8wICh0ZXN0czogcmVhZCAxNDMzNzIyODg0LzExMzYvMjQgbnhyZWFkIDE0MzM3
>MjI4ODQvMTQzMzcyMjg4NC8xNTk0IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MjI4ODQvMTQz
>MzcyMjg4NC82NTcwIGZvcmt0b29tdWNoIDE0MzM3MjI4ODQvMTQzMzcyMjg4NC8xNDMzNzIyODg0
>IGFsbG9jIDM1LzgvMiBjcmVhdCA4ODY1Lzg3MjQvNjU1NCBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjk0NS82NjQ1LzAgKHRlc3RzOiByZWFkIDE0MzM3MjI5
>NDUvMTE5Ny8xIG54cmVhZCAxNDMzNzIyOTQ1LzE0MzM3MjI5NDUvMTY1NSB0cnlleGNlcHQgNS8y
>LzAgZm9yayAxNDMzNzIyOTQ1LzE0MzM3MjI5NDUvNjYzMSBmb3JrdG9vbXVjaCAxNDMzNzIyOTQ1
>LzE0MzM3MjI5NDUvMTQzMzcyMjk0NSBhbGxvYyAzNS85LzEgY3JlYXQgODkyNi84Nzg1LzY2MTUg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI5ODQvNjY4NC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIyOTg0LzEyMzYvMTEgbnhyZWFkIDE0MzM3MjI5ODQvMTQzMzcy
>Mjk4NC8xNjk0IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjI5ODQvMTQzMzcyMjk4NC82Njcw
>IGZvcmt0b29tdWNoIDE0MzM3MjI5ODQvMTQzMzcyMjk4NC8xNDMzNzIyOTg0IGFsbG9jIDU0LzYv
>MSBjcmVhdCA4OTY1Lzg4MjQvNjY1NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcyMzA1Mi82NzUyLzAgKHRlc3RzOiByZWFkIDE0MzM3MjMwNTIvMTMwNC8xOSBu
>eHJlYWQgMTQzMzcyMzA1Mi8xNDMzNzIzMDUyLzE3NjIgdHJ5ZXhjZXB0IDM2LzIvMSBmb3JrIDE0
>MzM3MjMwNTIvMTQzMzcyMzA1Mi82NzM4IGZvcmt0b29tdWNoIDE0MzM3MjMwNTIvMTQzMzcyMzA1
>Mi8xNDMzNzIzMDUyIGFsbG9jIDM3LzE5LzYgY3JlYXQgOTAzMy84ODkyLzY3MjIgbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMwODIvNjc4Mi8wICh0ZXN0czog
>cmVhZCAxNDMzNzIzMDgyLzEzMzQvOSBueHJlYWQgMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzE3OTIg
>dHJ5ZXhjZXB0IDQvMS8wIGZvcmsgMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzY3NjggZm9ya3Rvb211
>Y2ggMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzE0MzM3MjMwODIgYWxsb2MgNjcvOS8yIGNyZWF0IDkw
>NjMvODkyMi82NzUyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIzMTA5LzY4MDkvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzEwOS8xMzYxLzEzIG54cmVhZCAxNDMz
>NzIzMTA5LzE0MzM3MjMxMDkvMTgxOSB0cnlleGNlcHQgNy8yLzEgZm9yayAxNDMzNzIzMTA5LzE0
>MzM3MjMxMDkvNjc5NSBmb3JrdG9vbXVjaCAxNDMzNzIzMTA5LzE0MzM3MjMxMDkvMTQzMzcyMzEw
>OSBhbGxvYyA0MC85LzMgY3JlYXQgOTA5MC84OTQ5LzY3NzkgbG9jayAzLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMxMjYvNjgyNi8wICh0ZXN0czogcmVhZCAxNDMzNzIz
>MTI2LzEzNzgvMTcgbnhyZWFkIDE0MzM3MjMxMjYvMTQzMzcyMzEyNi8xODM2IHRyeWV4Y2VwdCAy
>My8xLzEgZm9yayAxNDMzNzIzMTI2LzE0MzM3MjMxMjYvNjgxMiBmb3JrdG9vbXVjaCAxNDMzNzIz
>MTI2LzE0MzM3MjMxMjYvMTQzMzcyMzEyNiBhbGxvYyA1Ny8xMy80IGNyZWF0IDkxMDcvODk2Ni82
>Nzk2IGxvY2sgMi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzMTU2LzY4
>NTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzE1Ni8xNDA4LzEzIG54cmVhZCAxNDMzNzIzMTU2LzE0
>MzM3MjMxNTYvMTg2NiB0cnlleGNlcHQgMi8yLzAgZm9yayAxNDMzNzIzMTU2LzE0MzM3MjMxNTYv
>Njg0MiBmb3JrdG9vbXVjaCAxNDMzNzIzMTU2LzE0MzM3MjMxNTYvMTQzMzcyMzE1NiBhbGxvYyA1
>Ni8yMi8xIGNyZWF0IDkxMzcvODk5Ni82ODI2IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzIzMjAwLzY5MDAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzIwMC8xNDIy
>LzQgbnhyZWFkIDE0MzM3MjMyMDAvMTQzMzcyMzIwMC8xOTEwIHRyeWV4Y2VwdCAxMy8yLzEgZm9y
>ayAxNDMzNzIzMjAwLzE0MzM3MjMyMDAvNjg4NiBmb3JrdG9vbXVjaCAxNDMzNzIzMjAwLzE0MzM3
>MjMyMDAvMTQzMzcyMzIwMCBhbGxvYyA0MC8xMS8wIGNyZWF0IDkxODEvOTA0MC82ODcwIGxvY2sg
>My8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzMjQxLzY5NDEvMCAodGVz
>dHM6IHJlYWQgMTQzMzcyMzI0MS80NS83IG54cmVhZCAxNDMzNzIzMjQxLzE0MzM3MjMyNDEvMTk1
>MSB0cnlleGNlcHQgMjYvMi8xIGZvcmsgMTQzMzcyMzI0MS8xNDMzNzIzMjQxLzY5MjcgZm9ya3Rv
>b211Y2ggMTQzMzcyMzI0MS8xNDMzNzIzMjQxLzE0MzM3MjMyNDEgYWxsb2MgNDEvMTUvMCBjcmVh
>dCA5MjIyLzkwODEvNjkxMSBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMzI2OS82OTY5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjMyNjkvMzUvNiBueHJlYWQgMTQz
>MzcyMzI2OS8xNDMzNzIzMjY5LzE5NzkgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcyMzI2OS8x
>NDMzNzIzMjY5LzY5NTUgZm9ya3Rvb211Y2ggMTQzMzcyMzI2OS8xNDMzNzIzMjY5LzE0MzM3MjMy
>NjkgYWxsb2MgNDMvMTEvNiBjcmVhdCA5MjUwLzkxMDkvNjkzOSBsb2NrIDQvNC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzI5OC82OTk4LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MjMyOTgvNjQvMTQgbnhyZWFkIDE0MzM3MjMyOTgvMTQzMzcyMzI5OC8yMDA4IHRyeWV4Y2VwdCA4
>LzgvMCBmb3JrIDE0MzM3MjMyOTgvMTQzMzcyMzI5OC82OTg0IGZvcmt0b29tdWNoIDE0MzM3MjMy
>OTgvMTQzMzcyMzI5OC8xNDMzNzIzMjk4IGFsbG9jIDQwLzE0LzkgY3JlYXQgOTI3OS85MTM4LzY5
>NjggbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMzNDAvNzA0
>MC8wICh0ZXN0czogcmVhZCAxNDMzNzIzMzQwLzEwNi8xIG54cmVhZCAxNDMzNzIzMzQwLzE0MzM3
>MjMzNDAvMjA1MCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzMzQwLzE0MzM3MjMzNDAvNzAy
>NiBmb3JrdG9vbXVjaCAxNDMzNzIzMzQwLzE0MzM3MjMzNDAvMTQzMzcyMzM0MCBhbGxvYyAzMS82
>LzEgY3JlYXQgOTMyMS85MTgwLzcwMTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MjMzNjUvNzA2NS8wICh0ZXN0czogcmVhZCAxNDMzNzIzMzY1LzEzMS8yNiBu
>eHJlYWQgMTQzMzcyMzM2NS8xNDMzNzIzMzY1LzIwNzUgdHJ5ZXhjZXB0IDE5LzAvMCBmb3JrIDE0
>MzM3MjMzNjUvMTQzMzcyMzM2NS83MDUxIGZvcmt0b29tdWNoIDE0MzM3MjMzNjUvMTQzMzcyMzM2
>NS8xNDMzNzIzMzY1IGFsbG9jIDMxLzUvMSBjcmVhdCA5MzQ2LzkyMDUvNzAzNSBsb2NrIDEvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzM4Ni83MDg2LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MjMzODYvMTUyLzE4IG54cmVhZCAxNDMzNzIzMzg2LzE0MzM3MjMzODYvMjA5NiB0
>cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzMzg2LzE0MzM3MjMzODYvNzA3MiBmb3JrdG9vbXVj
>aCAxNDMzNzIzMzg2LzE0MzM3MjMzODYvMTQzMzcyMzM4NiBhbGxvYyA1Mi82LzEgY3JlYXQgOTM2
>Ny85MjI2LzcwNTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MjM0MzUvNzEzNS8wICh0ZXN0czogcmVhZCAxNDMzNzIzNDM1LzIwMS8xIG54cmVhZCAxNDMzNzIz
>NDM1LzE0MzM3MjM0MzUvMjE0NSB0cnlleGNlcHQgNC8zLzAgZm9yayAxNDMzNzIzNDM1LzE0MzM3
>MjM0MzUvNzEyMSBmb3JrdG9vbXVjaCAxNDMzNzIzNDM1LzE0MzM3MjM0MzUvMTQzMzcyMzQzNSBh
>bGxvYyA0My8xNC8xIGNyZWF0IDk0MTYvOTI3NS83MTA1IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIzNDYyLzcxNjIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzQ2
>Mi8yMjgvMjMgbnhyZWFkIDE0MzM3MjM0NjIvMTQzMzcyMzQ2Mi8yMTcyIHRyeWV4Y2VwdCAyLzIv
>MiBmb3JrIDE0MzM3MjM0NjIvMTQzMzcyMzQ2Mi83MTQ4IGZvcmt0b29tdWNoIDE0MzM3MjM0NjIv
>MTQzMzcyMzQ2Mi8xNDMzNzIzNDYyIGFsbG9jIDQ1LzcvMCBjcmVhdCA5NDQzLzkzMDIvNzEzMiBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzUxMi83MjEyLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjM1MTIvMjc4LzkgbnhyZWFkIDE0MzM3MjM1MTIvMTQzMzcyMzUx
>Mi8yMjIyIHRyeWV4Y2VwdCA0Mi8yLzEgZm9yayAxNDMzNzIzNTEyLzE0MzM3MjM1MTIvNzE5OCBm
>b3JrdG9vbXVjaCAxNDMzNzIzNTEyLzE0MzM3MjM1MTIvMTQzMzcyMzUxMiBhbGxvYyAyMi85LzQg
>Y3JlYXQgOTQ5My85MzUyLzcxODIgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MjM1NDAvNzI0MC8wICh0ZXN0czogcmVhZCAxNDMzNzIzNTQwLzMwNi82IG54cmVh
>ZCAxNDMzNzIzNTQwLzE0MzM3MjM1NDAvMjI1MCB0cnlleGNlcHQgNDYvMS8wIGZvcmsgMTQzMzcy
>MzU0MC8xNDMzNzIzNTQwLzcyMjYgZm9ya3Rvb211Y2ggMTQzMzcyMzU0MC8xNDMzNzIzNTQwLzE0
>MzM3MjM1NDAgYWxsb2MgNDUvMTAvMiBjcmVhdCA5NTIxLzkzODAvNzIxMCBsb2NrIDIvMi8yKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzU5OC83Mjk4LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjM1OTgvMzY0LzEgbnhyZWFkIDE0MzM3MjM1OTgvMTQzMzcyMzU5OC8yMzA4IHRyeWV4
>Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjM1OTgvMTQzMzcyMzU5OC83Mjg0IGZvcmt0b29tdWNoIDE0
>MzM3MjM1OTgvMTQzMzcyMzU5OC8xNDMzNzIzNTk4IGFsbG9jIDM5LzYvMSBjcmVhdCA5NTc5Lzk0
>MzgvNzI2OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzYy
>MC83MzIwLzAgKHRlc3RzOiByZWFkIDE0MzM3MjM2MjAvMzg2LzYgbnhyZWFkIDE0MzM3MjM2MjAv
>MTQzMzcyMzYyMC8yMzMwIHRyeWV4Y2VwdCA5LzEvMSBmb3JrIDE0MzM3MjM2MjAvMTQzMzcyMzYy
>MC83MzA2IGZvcmt0b29tdWNoIDE0MzM3MjM2MjAvMTQzMzcyMzYyMC8xNDMzNzIzNjIwIGFsbG9j
>IDYxLzE3LzYgY3JlYXQgOTYwMS85NDYwLzcyOTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjM2NTEvNzM1MS8wICh0ZXN0czogcmVhZCAxNDMzNzIzNjUxLzQx
>Ny8xMCBueHJlYWQgMTQzMzcyMzY1MS8xNDMzNzIzNjUxLzIzNjEgdHJ5ZXhjZXB0IDM4LzgvMCBm
>b3JrIDE0MzM3MjM2NTEvMTQzMzcyMzY1MS83MzM3IGZvcmt0b29tdWNoIDE0MzM3MjM2NTEvMTQz
>MzcyMzY1MS8xNDMzNzIzNjUxIGFsbG9jIDY1LzEzLzEgY3JlYXQgOTYzMi85NDkxLzczMjEgbG9j
>ayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM2NzIvNzM3Mi8wICh0
>ZXN0czogcmVhZCAxNDMzNzIzNjcyLzQzOC84IG54cmVhZCAxNDMzNzIzNjcyLzE0MzM3MjM2NzIv
>MjM4MiB0cnlleGNlcHQgMjkvMi8yIGZvcmsgMTQzMzcyMzY3Mi8xNDMzNzIzNjcyLzczNTggZm9y
>a3Rvb211Y2ggMTQzMzcyMzY3Mi8xNDMzNzIzNjcyLzE0MzM3MjM2NzIgYWxsb2MgNzUvMjIvNyBj
>cmVhdCA5NjUzLzk1MTIvNzM0MiBsb2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMzczMC83NDMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MjM3MzAvNDk2LzIxIG54cmVh
>ZCAxNDMzNzIzNzMwLzE0MzM3MjM3MzAvMjQ0MCB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzIz
>NzMwLzE0MzM3MjM3MzAvNzQxNiBmb3JrdG9vbXVjaCAxNDMzNzIzNzMwLzE0MzM3MjM3MzAvMTQz
>MzcyMzczMCBhbGxvYyA1OC8yMS8wIGNyZWF0IDk3MTEvOTU3MC83NDAwIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzNzU4Lzc0NTgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMzc1OC81MjQvMjMgbnhyZWFkIDE0MzM3MjM3NTgvMTQzMzcyMzc1OC8yNDY4IHRyeWV4
>Y2VwdCA3LzIvMiBmb3JrIDE0MzM3MjM3NTgvMTQzMzcyMzc1OC83NDQ0IGZvcmt0b29tdWNoIDE0
>MzM3MjM3NTgvMTQzMzcyMzc1OC8xNDMzNzIzNzU4IGFsbG9jIDI4LzE5LzUgY3JlYXQgOTczOS85
>NTk4Lzc0MjggbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM3
>ODcvNzQ4Ny8wICh0ZXN0czogcmVhZCAxNDMzNzIzNzg3LzU1My8xIG54cmVhZCAxNDMzNzIzNzg3
>LzE0MzM3MjM3ODcvMjQ5NyB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzNzg3LzE0MzM3MjM3
>ODcvNzQ3MyBmb3JrdG9vbXVjaCAxNDMzNzIzNzg3LzE0MzM3MjM3ODcvMTQzMzcyMzc4NyBhbGxv
>YyA0OC8xMC8xIGNyZWF0IDk3NjgvOTYyNy83NDU3IGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIzODIwLzc1MjAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzgyMC81
>ODYvNiBueHJlYWQgMTQzMzcyMzgyMC8xNDMzNzIzODIwLzI1MzAgdHJ5ZXhjZXB0IDMwLzMvMCBm
>b3JrIDE0MzM3MjM4MjAvMTQzMzcyMzgyMC83NTA2IGZvcmt0b29tdWNoIDE0MzM3MjM4MjAvMTQz
>MzcyMzgyMC8xNDMzNzIzODIwIGFsbG9jIDQzLzkvMSBjcmVhdCA5ODAxLzk2NjAvNzQ5MCBsb2Nr
>IDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzg1Ny83NTU3LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MjM4NTcvNjIzLzEzIG54cmVhZCAxNDMzNzIzODU3LzE0MzM3MjM4NTcv
>MjU2NyB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzODU3LzE0MzM3MjM4NTcvNzU0MyBmb3Jr
>dG9vbXVjaCAxNDMzNzIzODU3LzE0MzM3MjM4NTcvMTQzMzcyMzg1NyBhbGxvYyA0Ni8xLzEgY3Jl
>YXQgOTgzOC85Njk3Lzc1MjcgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MjM4ODMvNzU4My8wICh0ZXN0czogcmVhZCAxNDMzNzIzODgzLzY0OS8zOSBueHJlYWQg
>MTQzMzcyMzg4My8xNDMzNzIzODgzLzI1OTMgdHJ5ZXhjZXB0IDEwLzIvMSBmb3JrIDE0MzM3MjM4
>ODMvMTQzMzcyMzg4My83NTY5IGZvcmt0b29tdWNoIDE0MzM3MjM4ODMvMTQzMzcyMzg4My8xNDMz
>NzIzODgzIGFsbG9jIDIyLzExLzAgY3JlYXQgOTg2NC85NzIzLzc1NTMgbG9jayA1LzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM5MDcvNzYwNy8wICh0ZXN0czogcmVhZCAx
>NDMzNzIzOTA3LzY3My8zIG54cmVhZCAxNDMzNzIzOTA3LzE0MzM3MjM5MDcvMjYxNyB0cnlleGNl
>cHQgMzMvMS8xIGZvcmsgMTQzMzcyMzkwNy8xNDMzNzIzOTA3Lzc1OTMgZm9ya3Rvb211Y2ggMTQz
>MzcyMzkwNy8xNDMzNzIzOTA3LzE0MzM3MjM5MDcgYWxsb2MgMzUvMy8zIGNyZWF0IDk4ODgvOTc0
>Ny83NTc3IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzOTI2
>Lzc2MjYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzkyNi82OTIvMTkgbnhyZWFkIDE0MzM3MjM5MjYv
>MTQzMzcyMzkyNi8yNjM2IHRyeWV4Y2VwdCA1Mi8yLzEgZm9yayAxNDMzNzIzOTI2LzE0MzM3MjM5
>MjYvNzYxMiBmb3JrdG9vbXVjaCAxNDMzNzIzOTI2LzE0MzM3MjM5MjYvMTQzMzcyMzkyNiBhbGxv
>YyA1NC8xOS80IGNyZWF0IDk5MDcvOTc2Ni83NTk2IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIzOTUxLzc2NTEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzk1MS83
>MTcvMTEgbnhyZWFkIDE0MzM3MjM5NTEvMTQzMzcyMzk1MS8yNjYxIHRyeWV4Y2VwdCAyNi8zLzEg
>Zm9yayAxNDMzNzIzOTUxLzE0MzM3MjM5NTEvNzYzNyBmb3JrdG9vbXVjaCAxNDMzNzIzOTUxLzE0
>MzM3MjM5NTEvMTQzMzcyMzk1MSBhbGxvYyA1OS8xMS81IGNyZWF0IDk5MzIvOTc5MS83NjIxIGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzOTc0Lzc2NzQvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMzk3NC83NDAvMiBueHJlYWQgMTQzMzcyMzk3NC8xNDMzNzIzOTc0
>LzI2ODQgdHJ5ZXhjZXB0IDUvMy8wIGZvcmsgMTQzMzcyMzk3NC8xNDMzNzIzOTc0Lzc2NjAgZm9y
>a3Rvb211Y2ggMTQzMzcyMzk3NC8xNDMzNzIzOTc0LzE0MzM3MjM5NzQgYWxsb2MgNTIvNC8yIGNy
>ZWF0IDk5NTUvOTgxNC83NjQ0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzI0MDE1Lzc3MTUvMCAodGVzdHM6IHJlYWQgMTQzMzcyNDAxNS83ODEvMSBueHJlYWQg
>MTQzMzcyNDAxNS8xNDMzNzI0MDE1LzI3MjUgdHJ5ZXhjZXB0IDQ0LzMvMCBmb3JrIDE0MzM3MjQw
>MTUvMTQzMzcyNDAxNS83NzAxIGZvcmt0b29tdWNoIDE0MzM3MjQwMTUvMTQzMzcyNDAxNS8xNDMz
>NzI0MDE1IGFsbG9jIDYxLzYvMSBjcmVhdCA5OTk2Lzk4NTUvNzY4NSBsb2NrIDIvMi8xKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyNDA1MC83NzUwLzAgKHRlc3RzOiByZWFkIDE0
>MzM3MjQwNTAvODE2LzEgbnhyZWFkIDE0MzM3MjQwNTAvMTQzMzcyNDA1MC8yNzYwIHRyeWV4Y2Vw
>dCAzLzIvMCBmb3JrIDE0MzM3MjQwNTAvMTQzMzcyNDA1MC83NzM2IGZvcmt0b29tdWNoIDE0MzM3
>MjQwNTAvMTQzMzcyNDA1MC8xNDMzNzI0MDUwIGFsbG9jIDQ1LzYvMSBjcmVhdCAxMDAzMS85ODkw
>Lzc3MjAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjQwODAv
>Nzc4MC8wICh0ZXN0czogcmVhZCAxNDMzNzI0MDgwLzg0Ni85IG54cmVhZCAxNDMzNzI0MDgwLzE0
>MzM3MjQwODAvMjc5MCB0cnlleGNlcHQgMTIvMC8wIGZvcmsgMTQzMzcyNDA4MC8xNDMzNzI0MDgw
>Lzc3NjYgZm9ya3Rvb211Y2ggMTQzMzcyNDA4MC8xNDMzNzI0MDgwLzE0MzM3MjQwODAgYWxsb2Mg
>MzYvMTUvMiBjcmVhdCAxMDA2MS85OTIwLzc3NTAgbG9jayAyLzIvMikKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjQxMDQvNzgwNC8wICh0ZXN0czogcmVhZCAxNDMzNzI0MTA0Lzg3
>MC8zIG54cmVhZCAxNDMzNzI0MTA0LzE0MzM3MjQxMDQvMjgxNCB0cnlleGNlcHQgMzMvMS8wIGZv
>cmsgMTQzMzcyNDEwNC8xNDMzNzI0MTA0Lzc3OTAgZm9ya3Rvb211Y2ggMTQzMzcyNDEwNC8xNDMz
>NzI0MTA0LzE0MzM3MjQxMDQgYWxsb2MgMzkvMTIvMyBjcmVhdCAxMDA4NS85OTQ0Lzc3NzQgbG9j
>ayAyLzIvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjQxNDkvNzg0OS8wICh0
>ZXN0czogcmVhZCAxNDMzNzI0MTQ5LzkxNS8zNCBueHJlYWQgMTQzMzcyNDE0OS8xNDMzNzI0MTQ5
>LzI4NTkgdHJ5ZXhjZXB0IDQzLzIvMCBmb3JrIDE0MzM3MjQxNDkvMTQzMzcyNDE0OS83ODM1IGZv
>cmt0b29tdWNoIDE0MzM3MjQxNDkvMTQzMzcyNDE0OS8xNDMzNzI0MTQ5IGFsbG9jIDQyLzEyLzEg
>Y3JlYXQgMTAxMzAvOTk4OS83ODE5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzI0MTgwLzc4ODAvMCAodGVzdHM6IHJlYWQgMTQzMzcyNDE4MC85NDYvMSBueHJl
>YWQgMTQzMzcyNDE4MC8xNDMzNzI0MTgwLzI4OTAgdHJ5ZXhjZXB0IDE1LzIvMCBmb3JrIDE0MzM3
>MjQxODAvMTQzMzcyNDE4MC83ODY2IGZvcmt0b29tdWNoIDE0MzM3MjQxODAvMTQzMzcyNDE4MC8x
>NDMzNzI0MTgwIGFsbG9jIDU5LzU=
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn--


From dmuysers at hotmail.com  Sat Jul  4 11:48:08 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 4 Jul 2015 11:48:08 +0200
Subject: [M3devel] Arithmetic Shift
Message-ID: <DUB127-DS2AA4B1C47C4D0A19C4634DD950@phx.gbl>

Why is there no arithmetic right shift operation in Modula-3 ?

Oberon software has a clever way to minimally encode
signed integers independently of their size.

PROCEDURE WriteInt (i: INTEGER) =
  BEGIN
    WHILE x < ?64 OR x > 63 DO
      Write (VAL (i MOD 128 + 128, CHAR));
      i := i DIV 128;
    END;
    Write (VAL (i MOD 128), CHAR));
  END Write;

Unfortunately it is impossible to implement the corresponding
decoder in M3, because it requires an arithmetic right shift
where the sign bit is replicated into the left end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150704/1b90114c/attachment.html>

From dmuysers at hotmail.com  Sat Jul  4 12:31:46 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 4 Jul 2015 12:31:46 +0200
Subject: [M3devel] Arithmetic Shift
In-Reply-To: <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu>
References: <DUB127-DS2AA4B1C47C4D0A19C4634DD950@phx.gbl>
 <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu>
Message-ID: <DUB127-DS3CEC4034F7BA584E67E9EDD950@phx.gbl>

Sure, but then, since the amount of shift is a variable, it will oblige one
to index into a table of such constants, which is rather clumsy, and
possibly (?) poorly optimised by the compiler.

PROCEDURE ReadInt (VAR x: INTEGER) =
  VAR ch: CHAR;  n, y := 0;
  BEGIN
    Read (ch);
    WHILE ch >= 128 DO
      INC (y, Word.LeftShift (ORD (ch) - 128, n));
      INC (n, 7);
      Read (ch)
    END;
    x := arithmetic-shift (Word.LeftShift (ORD (ch), 25), n - 25) + y
  END ReadInt;

From: Antony Hosking 
Sent: Saturday, July 04, 2015 12:11 PM
To: dirk muysers 
Cc: m3devel at elegosoft.com 
Subject: Re: [M3devel] Arithmetic Shift

In this code you use DIV by a constant power of two.  That will turn into an arithmetic right shift. 

  On Jul 4, 2015, at 7:48 PM, dirk muysers <dmuysers at hotmail.com> wrote:

  Why is there no arithmetic right shift operation in Modula-3 ?

  Oberon software has a clever way to minimally encode
  signed integers independently of their size.

  PROCEDURE WriteInt (i: INTEGER) =
    BEGIN
      WHILE x < ?64 OR x > 63 DO
        Write (VAL (i MOD 128 + 128, CHAR));
        i := i DIV 128;
      END;
      Write (VAL (i MOD 128), CHAR));
    END Write;

  Unfortunately it is impossible to implement the corresponding
  decoder in M3, because it requires an arithmetic right shift
  where the sign bit is replicated into the left end.
  _______________________________________________
  M3devel mailing list
  M3devel at elegosoft.com
  https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150704/beadc2c2/attachment.html>

From jay.krell at cornell.edu  Sat Jul 18 10:27:41 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 08:27:41 +0000
Subject: [M3devel] switching to C backend?
Message-ID: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>

Any objection if I start switching targets to the C backend?
In particular, Darwin does not support m3gdb, so debuggability is not a factor.
Thanks, - Jay



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/a1410c75/attachment.html>

From dmuysers at hotmail.com  Sat Jul 18 10:42:14 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 18 Jul 2015 10:42:14 +0200
Subject: [M3devel] switching to C backend?
In-Reply-To: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>
References: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>
Message-ID: <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>

May I remind you Norman Ramsey?s opinion on the subject:



Code generation is my business :-)

Comments on a few options:

  a.. CLR: 

    a.. Pro: industrial support 
    b.. Con: you have to buy into their type system pretty much completely; depending on what you want to do with types, this may not matter 
    c.. Con: Only Windows platform is really prime-time quality
  b.. LLVM:

    a.. Pro: enthusiastic user community with charismatic leader 
    b.. Pro: many interesting performance improvements 
    c.. Con: somewhat complex interface 
    d.. Con: history of holes in the engineering; as LLVM matures expect the holes in the engineering to be plugged by adding to the complexity of the interface
  c.. C--

    a.. Pro: target is an actual written language, not an API; you can easily inspect, debug, and edit your C-- code 
    b.. Pro: design is reasonably mature and reasonably clean 
    c.. Pro: supports accurate garbage collection 
    d.. Pro: most users report it is very easy to use 
    e.. Con: very small development team 
    f.. Con: as of early 2009, supports only three hardware platforms (x86, PPC, ARM) 
    g.. Con: does not ship with a garbage collector 
    h.. Con: future of project is uncertain
  d.. C as target language

    a.. Pro: looks easy 
    b.. Con: nearly impossible to get decent performance 
    c.. Con: will drive you nuts in the long run; ask the long line of people who have tried to compile Haskell, ML, Modula-3, Scheme and more using this technique. At some point every one of these people gave up and built their own native code generator.
Summary: anything except C is a reasonable choice. For the best combination of flexibility, quality, and expected longevity, I'd probably recommend LLVM. But your example code is very close to C--, so that may be an advantage.

Full disclosure: I am affiliated with the C-- project.


From: Jay K 
Sent: Saturday, July 18, 2015 10:27 AM
To: m3devel 
Subject: [M3devel] switching to C backend?

Any objection if I start switching targets to the C backend? 

In particular, Darwin does not support m3gdb, so debuggability is not a factor.

Thanks,
- Jay







--------------------------------------------------------------------------------
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/0900c2cf/attachment.html>

From jay.krell at cornell.edu  Sat Jul 18 10:48:09 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 08:48:09 +0000
Subject: [M3devel] representing word size in IR target-independently?
Message-ID: <COL130-W38AE30909909E4B9AF5E37E6870@phx.gbl>

 Ideally there would be one target-independent IR for, for example: 


 VAR a := BYTESIZE(INTEGER);   VAR b := BITSIZE(INTEGER) = 64;   TYPE T1 = RECORD a,b:INTEGER END;   CONST pt1: REF T1 = NIL;   VAR offset_of_b := LOOPHOLE(INTEGER, ADR(pt1.b));  


 so that it could be translated to target-independent C something like: 

 #if ...almost always true...   typedef ptrdiff_t INTEGER;  #else  ...  #endif   INTEGER a = sizeof(INTEGER);  typedef unsigned char BOOLEAN;   BOOLEAN b = (sizeof(INTEGER) * 8) == 64;   typedef struct { a,b:INTEGER; } T1;  T1* pt1;  // ideal but unlikely:  INTEGER offset_of_b = offsetof(T1, b);  // more likely:   INTEGER offset_of_b;  void module_initializer()  {    offset_of_b = (INTEGER)&pt1->b;  } 
  
Is this feasible?


 Can instances of "INTEGER" somehow be left higher level for resolution  by the backend? Or can they be left "dual", both "resolved" and "symbolic"?  Or would this require too much change?
 
 I would be very reluctantly satisfied if the frontend ran  a certain portion of itself twice, once for each word size, indicating  the start/end of the passes to the backend, so the generated C would  be doubled up with an #if something like: 

#if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || defined(__ppc64__) ...
 ... everything ... 
 #else // 32 bit 
 ... everything ... 
 #endif

The agenda is target-independent C output from the C backend,as a portable redistributable form.This is approximately one of the three problems to solve to achieve that.


Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/68359d67/attachment.html>

From jay.krell at cornell.edu  Sat Jul 18 11:02:03 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 09:02:03 +0000
Subject: [M3devel] switching to C backend?
In-Reply-To: <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>
References: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>,
 <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>
Message-ID: <COL130-W699475F4DD964C1D9FA199E6870@phx.gbl>

 I disagree.  The system is working. This isn't speculation.
  Using his terminology  
  C pros:   - written language (also a con)   - longevity   - does not drive me nuts   - design is very mature    - looks easy and is easy   - huge portability of implementation   - potential portability of object code    - debugability with stock debuggers    - large development teams ("back back end")  - multiple industrial strength "back back ends"   - likely similar compiled performance as anything else   - probably similar compiled performance 

 C cons:   - compiler performance     - debuggability on platforms that have m3gdb support    - cannot always efficiently express things portably,     in particular, portable C has the same inefficient exception      handling; we need to switch to C++ to fix it, or non-portable C      on some platforms (i.e. win32 __try)       
 For garbage collection, I believe C, m3cc, and llvm are currently all equivalent and not good. 
    - Jay



From: dmuysers at hotmail.com
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] switching to C backend?
Date: Sat, 18 Jul 2015 10:42:14 +0200








May I remind you Norman Ramsey?s opinion on the 
subject:

 

Code generation is my business :-)

Comments on a few options:


  
  CLR: 

  
    Pro: industrial support 
    Con: you have to buy into their type system 
    pretty much completely; depending on what you want to do with types, this 
    may not matter 
    Con: Only Windows platform is really 
    prime-time quality
  
  LLVM:

  
    Pro: enthusiastic user community with 
    charismatic leader 
    Pro: many interesting performance 
    improvements 
    Con: somewhat complex interface 
    Con: history of holes in the engineering; 
    as LLVM matures expect the holes in the engineering to be plugged by adding 
    to the complexity of the interface
  
  C--

  
    Pro: target is an actual written language, 
    not an API; you can easily inspect, debug, and edit your C-- code 
    Pro: design is reasonably mature and 
    reasonably clean 
    Pro: supports accurate garbage 
    collection 
    Pro: most users report it is very easy to 
    use 
    Con: very small development team 
    Con: as of early 2009, supports only three 
    hardware platforms (x86, PPC, ARM) 
    Con: does not ship with a garbage 
    collector 
    Con: future of project is 
    uncertain
  
  C as target language

  
    Pro: looks easy 
    Con: nearly impossible to get decent 
    performance 
    Con: will drive you nuts in the long run; 
    ask the long line of people who have tried to compile Haskell, ML, Modula-3, 
    Scheme and more using this technique. At some point every one of these 
    people gave up and built their own native code 
generator.
Summary: anything except C is a 
reasonable choice. For the best combination of flexibility, quality, and 
expected longevity, I'd probably recommend LLVM. But your example code is very 
close to C--, so that may be an advantage.

Full disclosure: I am affiliated with the C-- 
project.



 

From: Jay K 
Sent: Saturday, July 18, 2015 10:27 AM
To: m3devel 
Subject: [M3devel] switching to C backend?
 

Any objection if I start switching targets to the C backend? 
 
In particular, Darwin does not support m3gdb, 
so debuggability is not a factor.
 
Thanks,
- Jay







_______________________________________________
M3devel mailing 
list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/60be99d8/attachment.html>

From jay.krell at cornell.edu  Sat Jul 18 13:05:43 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 11:05:43 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
Message-ID: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>

so..I know there is a much better way to do this, but..


Currently every time we have a TRY, we pay both for a setjmpand a jmpbuf.m3-sys/m3tests/src/p2/p259 demonstrates this, and it is what I thoughtthe code was doing anyway -- m3front doesn't maintain per-functionstate related to TRY.

Ideally we defer to an underlying non-portable highly optimized form.

However, has anyone considered a form that does use setjmp butuses at most one frame per procedure, instead of a frame per TRY?

Oh -- and also, the jmpbuf isn't just a large size, but a pthread_getspecific/pthread_setspecfic.

Or, does anything think we stand a chance of soon transitioning completely away from setjmp/longjmp?

Thanks, - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/44be732c/attachment.html>

From jay.krell at cornell.edu  Sun Jul 19 00:17:03 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 22:17:03 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
Message-ID: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>

I want to eliminate the knowledge of jmpbuf size from the frontend.This is an old goal that I failed at previously.

I believe I need to:
 Extend M3.CheckState to include jmpbuf_count. The various Try*.m3.Check increment it and store its previous value in the statement's state.   And then a few choices.  1)  At the start of a function, call alloca with that count times external variable jmpbuf_size, initialized in C. 
 At each try, multiply its index by external variable jmpbuf_size and add to the start of the buffer and use that.   or  also have an array of n pointers filled in by C and index into that, eliminating the runtime non-const multiplication   and/or
  include that array in the alloca even    having a "composite" not called simply "alloca" but "m3_alloc_jmpbufs",  which backends still have to special case to look kinda the same,  alloca being very special
    and/or
    add to functions themselves a notion of jmpbuf count, still the same  underlying mechanism..
      and/or also add a m3cg primitive "jmpbuf_ref(n)", which gets the address  of the n'th jmpbuf of the current function, i.e. building in the multiplication  by jmpbuf size.
      Note that some of these combinations of proposals imply an m3cg change.  All require at least a minimum of backend cooperation -- at least  recognizing "m3_alloca" as "alloca" or "_alloca" or "builtin_alloca" or such.
  
  Note that hopefully/ideally there is a much higher level way to do this,  whose design currently eludes me,  something that a backend could translate to setjmp/longjmp, or Win32 C __try,  or C++ try, or something. The "lowering" of try/finally in the frontend  is portable but very inefficient.
  
 Another solution is for the function to have an n-array of pointers or merely n locals, initialized to null, and have each TRY dynamically call alloca if the pointer isn't null.

 This reduces stack use for the case of IF...TRY.

 At the cost of extra initialization and the test and branch.

This is currently my favorite proposal so I should restate: have a local pointer for each TRY; initialized to null; at each TRY, if the pointer is null, call alloca(external jmpbuf_size). TRY is already super expensive in code size and speed. This solution adds a pointer per TRY and a test and conditional jmp. Multiplication is avoided. IF...TRY ends up using much less stack than before, if not executed, but most code will pay extra stack, a pointer per TRY. What I was missing before is that I need to extend M3.CheckState to count the jmpbufs and do some of the work at the start of the function, not merely at each TRY -- declare, and more importantly, initialize the pointers.
  Thoughts?
 

 Thanks, - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/6b1c1349/attachment.html>

From hendrik at topoi.pooq.com  Sun Jul 19 01:21:40 2015
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sat, 18 Jul 2015 19:21:40 -0400
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>
Message-ID: <20150718232140.GA7577@topoi.pooq.com>

On Sat, Jul 18, 2015 at 10:17:03PM +0000, Jay K wrote:
> I want to eliminate the knowledge of jmpbuf size from the frontend.This is an old goal that I failed at previously.
> 
> I believe I need to:
>  Extend M3.CheckState to include jmpbuf_count. The various Try*.m3.Check increment it and store its previous value in the statement's state.   And then a few choices.  1)  At the start of a function, call alloca with that count times external variable jmpbuf_size, initialized in C. 
>  At each try, multiply its index by external variable jmpbuf_size and add to the start of the buffer and use that.   or  also have an array of n pointers filled in by C and index into that, eliminating the runtime non-const multiplication   and/or
>   include that array in the alloca even    having a "composite" not called simply "alloca" but "m3_alloc_jmpbufs",  which backends still have to special case to look kinda the same,  alloca being very special
>     and/or
>     add to functions themselves a notion of jmpbuf count, still the same  underlying mechanism..
>       and/or also add a m3cg primitive "jmpbuf_ref(n)", which gets the address  of the n'th jmpbuf of the current function, i.e. building in the multiplication  by jmpbuf size.
>       Note that some of these combinations of proposals imply an m3cg change.  All require at least a minimum of backend cooperation -- at least  recognizing "m3_alloca" as "alloca" or "_alloca" or "builtin_alloca" or such.
>   
>   Note that hopefully/ideally there is a much higher level way to do this,  whose design currently eludes me,  something that a backend could translate to setjmp/longjmp, or Win32 C __try,  or C++ try, or something. The "lowering" of try/finally in the frontend  is portable but very inefficient.
>   
>  Another solution is for the function to have an n-array of pointers or merely n locals, initialized to null, and have each TRY dynamically call alloca if the pointer isn't null.
> 
>  This reduces stack use for the case of IF...TRY.
> 
>  At the cost of extra initialization and the test and branch.
> 
> This is currently my favorite proposal so I should restate: have a local pointer for each TRY; initialized to null; at each TRY, if the pointer is null, call alloca(external jmpbuf_size). TRY is already super expensive in code size and speed. This solution adds a pointer per TRY and a test and conditional jmp. Multiplication is avoided. IF...TRY ends up using much less stack than before, if not executed, but most code will pay extra stack, a pointer per TRY. What I was missing before is that I need to extend M3.CheckState to count the jmpbufs and do some of the work at the start of the function, not merely at each TRY -- declare, and more importantly, initialize the pointers.
>   Thoughts?

Unless things have changed  recently, alloca() is not standard.

see the discussion and links in http://c-faq.com/malloc/alloca.html

That page also contains the sentence

Now that C99 supports variable-length arrays (VLA's), they can be used to more cleanly accomplish most of the tasks which alloca used to be put to.

Not clear at aall if the VLA's can be used for this.

>  
> 
>  Thanks, - Jay
> 
>  		 	   		  

> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel



From jay.krell at cornell.edu  Sun Jul 19 10:23:46 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 08:23:46 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <20150718232140.GA7577@topoi.pooq.com>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>,
 <20150718232140.GA7577@topoi.pooq.com>
Message-ID: <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>

alloca is very portable even if it is not in ANSI C or even Posix.

 gcc has builtin support for it. Win32 provides it, where it is called _alloca.The NT/amd64 ABI specifically accounts for it -- functions that callalloca must have a fixed "frame pointer" in a register other than rsp,so that rsp can be changed by calling alloca.
 clang/LLVM presumably provide it. A lot of code depends on it and it is generally easy to provide.
OpenVMS apparently calls it __ALLOCA.


For more complete portability to the C backend we couldadd an m3cg operation to allocate an array of jmpbufswith a constant count.

It is certainly more portable than C99, and C99 VLAs are kind of more general than I need.That is, I might pass a "variable" to alloca, but it is kind of a constant.

My last/current proposal though does do the allocation dynamically, which thism3cg operation would not provide for.

 - Jay



> Date: Sat, 18 Jul 2015 19:21:40 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?
>> 
> Unless things have changed  recently, alloca() is not standard.
> 
> see the discussion and links in http://c-faq.com/malloc/alloca.html
> 
> That page also contains the sentence
> 
> Now that C99 supports variable-length arrays (VLA's), they can be used to more cleanly accomplish most of the tasks which alloca used to be put to.
> 
> Not clear at aall if the VLA's can be used for this.
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/c9f7ac81/attachment.html>

From estellnb at elstel.org  Sun Jul 19 10:44:15 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 10:44:15 +0200
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>,
 <20150718232140.GA7577@topoi.pooq.com>
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>
Message-ID: <55AB635F.9060809@elstel.org>


Am 2015-07-19 um 10:23 schrieb Jay K:
> alloca is very portable even if it is not in ANSI C or even Posix.
>
>
>  gcc has builtin support for it.
>  Win32 provides it, where it is called _alloca.
> The NT/amd64 ABI specifically accounts for it -- functions that call
> alloca must have a fixed "frame pointer" in a register other than rsp,
> so that rsp can be changed by calling alloca.
>
>  clang/LLVM presumably provide it.
>  A lot of code depends on it and it is generally easy to provide.
>
> OpenVMS apparently calls it __ALLOCA.
>
Basically if you plan to build jumpbuf support into m3cg you could
easily use a few assembly statements as well in order to achieve
what alloca does (independently from the operating system):

   mov %[e/r]sp, PTR VAR
   sub %[e/r]sp, JUMPBUF_SIZE

I am sure that similar workarounds would exist for any arch other
than x86 and AMD64.


>
> For more complete portability to the C backend we could
> add an m3cg operation to allocate an array of jmpbufs
> with a constant count.
Why allocate an array or external buffer of jump bufs?
We used to have a linked list interleaved on the stack.
This is fully sufficient and faster than an independent
memory area.

>
>
> It is certainly more portable than C99, and C99 VLAs are kind of more 
> general than I need.
> That is, I might pass a "variable" to alloca, but it is kind of a 
> constant.

If we have arrived at using something similar as alloca in m3cg why 
shouldn`t we provide
this functionality to the user? i.e. let programmers call such a 
function from high level M3
code in order to alloc variable length bufffers, arrays, etc.

VAR localvar := NEWA(MyType);

This is a functionality which I believe that is really missing in M3!!
When we implemented the algorithm of Strassen (saving some 
multiplications for matrix
mults.) we had to notice that everything goes much slower just because 
of the need for
garbage collection ...


- Elmar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/492899e3/attachment.html>

From jay.krell at cornell.edu  Sun Jul 19 10:56:55 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 08:56:55 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <55AB635F.9060809@elstel.org>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>, <55AB635F.9060809@elstel.org>
Message-ID: <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>

Merely subtracting the stack pointer isn't correct on all systems.At least on NT, stack pages must be touched in order without skipping any,for stack overflow exceptions to work correctly.There is a high water mark, so it isn't necessarily linear.


The array is local.The reason for an array is that each instance of a TRY currentlyuses its own jmpbuf.

So a function with n TRY's wants an array of n jmpbufs.

The elements are then indeed linked/unlinked by PushFrame/PopFrame,which are incredibly unoptimized, vs. for example native NT C or C++exception handling, and presumably other systems.

*Ideally* we'd have just one jmpbuf per function, at most, anda local "scope id" to differentiate where in the function we are,for finally/except to dispatch on.You can think of it is a line number, but there can be multiple per line,and they can be denser/smaller than line numbers.


NEWA: alloca is considered kind of dangerous, in that failureis difficult to recognize, or not portably recognizable and handlable.

However, that is the same as merely deep function calls.

So maybe.And we could smush the portability problem into our runtime.In particular, we could catch the exception on NT, fix up thepage (_resetstkovflw) and call calloc/malloc instead.

I don't know how to handle the situation on other systems though.

My current proposal doesn't use an array, but the most portableproposal would.

If people can do the work/research/testing for recognizing stack exhaustionon a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, NetBSD, NT,possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction in my mind.

But yes, safety and garbage collection are not free.If you want the best possible performance, use C or C++.

 - Jay


Date: Sun, 19 Jul 2015 10:44:15 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:23 schrieb Jay K:

    
    
      
      
        alloca is very portable even if it is not in ANSI C or even
          Posix.
        

        
        

        
         gcc has builtin support for it.
         Win32 provides it, where
            it is called _alloca.
        The NT/amd64 ABI
            specifically accounts for it -- functions that call
        alloca must have a fixed
            "frame pointer" in a register other than rsp,
        so that rsp can be changed
            by calling alloca.
        

          
         clang/LLVM presumably
            provide it.
         A lot of code depends on
            it and it is generally easy to provide.
        

          
        OpenVMS apparently calls it
            __ALLOCA.
        

        
      
    
    Basically if you plan to build jumpbuf support into m3cg you could

    easily use a few assembly statements as well in order to achieve 

    what alloca does (independently from the operating system):

    

      mov %[e/r]sp, PTR VAR

      sub %[e/r]sp, JUMPBUF_SIZE 

    

    I am sure that similar workarounds would exist for any arch other

    than x86 and AMD64.

    

    

    
      
        

        
        For more complete portability to the C backend we could
        add an m3cg operation to allocate an array of jmpbufs
        with a constant count.
      
    
    Why allocate an array or external buffer of jump bufs?

    We used to have a linked list interleaved on the stack.

    This is fully sufficient and faster than an independent 

    memory area.

    

    
      
        

        
        

        
        It is certainly more portable than C99, and C99 VLAs are
          kind of more general than I need.
        That is, I might pass a "variable" to alloca, but it is
          kind of a constant.
      
    
    

    If we have arrived at using something similar as alloca in m3cg why
    shouldn`t we provide

    this functionality to the user? i.e. let programmers call such a
    function from high level M3 

    code in order to alloc variable length bufffers, arrays, etc.

    

    VAR localvar := NEWA(MyType);

    

    This is a functionality which I believe that is really missing in
    M3!!

    When we implemented the algorithm of Strassen (saving some
    multiplications for matrix

    mults.) we had to notice that everything goes much slower just
    because of the need for

    garbage collection ...

    

    

    - Elmar

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/5e3deb52/attachment.html>

From estellnb at elstel.org  Sun Jul 19 10:57:11 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 10:57:11 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
Message-ID: <55AB6667.7010908@elstel.org>


Am 2015-07-18 um 13:05 schrieb Jay K:
>
> However, has anyone considered a form that does use setjmp but
> uses at most one frame per procedure, instead of a frame per TRY?

I don`t think that this will work for the general case.
Consider a try - except in the middle of a code block.
If you leave it, it needs to continue after the END of
the TRY-EXCEPT and not after the END of the
procedure.

What you can do is re-use the same jumpbuf-frame
for a nested try-finally and try - except :

  TRY
     TRY
       ...
      EXCEPT
       ...
      END;
   FINALLY
     ...
   END;

or simply

   TRY
     ....
   EXCEPT
     ....
   FINALLY
    ...
   END;

I can remember having once implemented the latter for PM3.
However I am no more sure about the intrinsics...




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/906c5b3c/attachment.html>

From estellnb at elstel.org  Sun Jul 19 11:10:20 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 11:10:20 +0200
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>,
 <55AB635F.9060809@elstel.org> <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>
Message-ID: <55AB697C.7090109@elstel.org>


Am 2015-07-19 um 10:56 schrieb Jay K:
> Merely subtracting the stack pointer isn't correct on all systems.
> At least on NT, stack pages must be touched in order without skipping any,
> for stack overflow exceptions to work correctly.
> There is a high water mark, so it isn't necessarily linear.

Would that mind if the stack exception was generated somewhat
later when the jumpbuf actually becomes accessed?
I would believe no.

>
> NEWA: alloca is considered kind of dangerous, in that failure
> is difficult to recognize, or not portably recognizable and handlable.

The same stack overflow exception can be generated by any
procedure call so that I do not see why it should be that
dangerous. In the overwhelming majority of cases this should
be handled as gracefully as an extension of the heap on NEW:
simply map a new memory page as long as there is enough
free virtual address space.


>
> If people can do the work/research/testing for recognizing stack 
> exhaustion
> on a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, 
> NetBSD, NT,
> possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction 
> in my mind.
As we are planning a new realease I would believe that your new
alterations would become tested shortly.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/0c600193/attachment.html>

From jay.krell at cornell.edu  Sun Jul 19 11:10:53 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 09:10:53 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB6667.7010908@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
Message-ID: <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>

I'm pretty sure it can work, but you need also a local "dense" volatile integer that describes where in the function you are.  That isn't free, but it is much cheaper than calling setjmp/PushFrame for each try.

Try writing similar C++ for NT/x86 and look at what you get."PushFrame" is highly optimized to build a linked list through fs:0.And even that is only done at most once per function.

Java VM also specifies scope tables with a similar intent.

The key is figuring out the algorithm to assign the scope ids, and computing and interpreting the resulting tables. It is a little tricky.

 - Jay


Date: Sun, 19 Jul 2015 10:57:11 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?


  
    
  
  
    

    Am 2015-07-18 um 13:05 schrieb Jay K:

    
    
      
      
        

        
        However, has anyone considered a form that does use setjmp
          but
        uses at most one frame per procedure, instead of a frame
          per TRY?
      
    
    

    I don`t think that this will work for the general case.

    Consider a try - except in the middle of a code block.

    If you leave it, it needs to continue after the END of

    the TRY-EXCEPT and not after the END of the 

    procedure.

    

    What you can do is re-use the same jumpbuf-frame

    for a nested try-finally and try - except :

    

     TRY

        TRY

          ...

         EXCEPT

          ...

         END;

      FINALLY

        ...

      END;

    

    or simply

    

      TRY

        ....

      EXCEPT

        ....

      FINALLY

       ...

      END;

    

    I can remember having once implemented the latter for PM3.

    However I am no more sure about the intrinsics...

    

    

    

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/c2b31d95/attachment.html>

From jay.krell at cornell.edu  Sun Jul 19 11:18:02 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 09:18:02 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <55AB697C.7090109@elstel.org>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>, <55AB635F.9060809@elstel.org>,
 <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>, <55AB697C.7090109@elstel.org>
Message-ID: <COL130-W2ED3E35017B6A73F03CC0E6860@phx.gbl>

The stack pages must be touched in order.

It cannot be dynamically ordered in such a way that pages are skipped.It is much easier to have a static order than worry about getting a dynamic order correct.

That is, sure, you can do some large subtract all at once,but you must not skip around in the order the pages are touched.

You can defer the exception until the jmpbuf is touched,and you can get away without touching any, but whatever youtouch, must be in order.

The solution is simple though -- actually call _alloca.It gets it right.

Imagine this:
jmpbuf bufs[n];while (1)    switch (srand() % n)    {    case 0: TRY ...  break;    case 1: TRY ...  break;    case 2: TRY ...  break;    case 3: TRY ...  break;    }}

that wouldn't work properly w/o a bit of extra code.

On NT, if you write a function with more than a page of locals,the start of the function calls chkstk, which is another name for alloca,to be sure to touch the page(s).

Because, imagine you have a function with more than a page of locals,that the first thing it does is call another function. The pushing of thereturn address will touch the stack, but possibly skip a page.

If you just have lots of functions with less than a page of locals,the pushing of return addresses to make further calls is what touchesthe pages.

It is easy to see in the generated code.We likely have a bug here in NT/x86 *forever*.It is fixed in the C backend. :)The C compiler knows the rules, and is heavily used, where the NT/x86 backend does/is not.

 - Jay



Date: Sun, 19 Jul 2015 11:10:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:56 schrieb Jay K:

    
    
      
      
        Merely subtracting the stack pointer isn't correct on all
          systems.
        At least on NT, stack pages must be touched in order
          without skipping any,
        for stack overflow exceptions to work correctly.
        There is a high water mark, so it isn't necessarily linear.
      
    
    

    Would that mind if the stack exception was generated somewhat 

    later when the jumpbuf actually becomes accessed?

    I would believe no.

    

    
      
        

        
        NEWA: alloca is considered kind of dangerous, in that
          failure
        is difficult to recognize, or not portably recognizable and
          handlable.
      
    
    

    The same stack overflow exception can be generated by any 

    procedure call so that I do not see why it should be that 

    dangerous. In the overwhelming majority of cases this should

    be handled as gracefully as an extension of the heap on NEW:

    simply map a new memory page as long as there is enough

    free virtual address space.

    

    

    
      
        

        
        If people can do the work/research/testing for recognizing
          stack exhaustion
        on a decent set of systems -- Linux, Solaris, FreeBSD,
          OpenBSD, NetBSD, NT,
        possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain
          traction in my mind.
      
    
    As we are planning a new realease I would believe that your new 

    alterations would become tested shortly.

    

    

    

    

    

    

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/73fe76fe/attachment.html>

From estellnb at elstel.org  Sun Jul 19 11:38:25 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 11:38:25 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
Message-ID: <55AB7011.9070709@elstel.org>


Am 2015-07-19 um 11:10 schrieb Jay K:
> I'm pretty sure it can work, but you need also a local "dense" 
> volatile integer that describes where in the function you are.  That 
> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
> each try.
>
Is it really that much faster? I can remember having implemented my own 
setjump/longjump in assembly some time ago and it should only save you 
one procedure call but generate some additional jumps. However I do not 
know how time costly the new-fashioned register value obfuscation is 
(registers are no more stored as they are but obfuscated for security 
reasons by glibc). Xor-ing by a simple value; does it really cost the 
world? I am not the one who can tell you whether such a venture like 
this would pay off ...


>
> Try writing similar C++ for NT/x86 and look at what you get.
> "PushFrame" is highly optimized to build a linked list through fs:0.
> And even that is only done at most once per function.

Through fs:0 ? It used to be on the ss:[e/r]b in former times.
Since pthreading it may also be fs:0 under Linux because of get/setspecific.
I am not sure what these functions do in detail (something with fs at last).

Nonetheless I would believe that avoiding to call get/setspecific could 
speed
things up noticeably. First there is the function overhead, second we 
need to
touch an independent memory area and last but not least the stack is
always thread local. However I am not sure on how we could place the top
anchor for the linked list of exception frames otherwise. Push an exception
  frame pointer into every local variable area?

>
>
> Java VM also specifies scope tables with a similar intent.

However Java is not known for speed wonders ...


>
>
> The key is figuring out the algorithm to assign the scope ids, and 
> computing and interpreting the resulting tables. It is a little tricky.
>


Am 2015-07-19 um 11:18 schrieb Jay K:
> The stack pages must be touched in order...

Thanks a lot for an elaborate discussion of this!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/bc13a4ff/attachment.html>

From estellnb at elstel.org  Sun Jul 19 12:06:20 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 12:06:20 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB7011.9070709@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl> <55AB7011.9070709@elstel.org>
Message-ID: <55AB769C.2020806@elstel.org>


Am 2015-07-19 um 11:38 schrieb Elmar Stellnberger:
>
> Am 2015-07-19 um 11:10 schrieb Jay K:
>> I'm pretty sure it can work, but you need also a local "dense" 
>> volatile integer that describes where in the function you are.  That 
>> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
>> each try.
>>
> Is it really that much faster? I can remember having implemented my 
> own setjump/longjump in assembly some time ago and it should only save 
> you one procedure call but generate some additional jumps. However I 
> do not know how time costly the new-fashioned register value 
> obfuscation is (registers are no more stored as they are but 
> obfuscated for security reasons by glibc). Xor-ing by a simple value; 
> does it really cost the world? I am not the one who can tell you 
> whether such a venture like this would pay off ...
>
>

You are right. It would be somewhat faster especially on AMD64 where we 
have a lot of registers to rescue ...


>>
>> Try writing similar C++ for NT/x86 and look at what you get.
>> "PushFrame" is highly optimized to build a linked list through fs:0.
>> And even that is only done at most once per function.
>
> Through fs:0 ? It used to be on the ss:[e/r]b in former times.
> Since pthreading it may also be fs:0 under Linux because of 
> get/setspecific.
> I am not sure what these functions do in detail (something with fs at 
> last).
>
> Nonetheless I would believe that avoiding to call get/setspecific 
> could speed
> things up noticeably. First there is the function overhead, second we 
> need to
> touch an independent memory area and last but not least the stack is
> always thread local. However I am not sure on how we could place the top
> anchor for the linked list of exception frames otherwise. Push an 
> exception
>  frame pointer into every local variable area?

However I believe this should also be worth a consideration as soon as 
we talk about m3cg support and speed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/ed02d46b/attachment.html>

From jay.krell at cornell.edu  Sun Jul 19 12:19:13 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 10:19:13 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB769C.2020806@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>, <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
 <55AB7011.9070709@elstel.org>,<55AB769C.2020806@elstel.org>
Message-ID: <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>

NT/x86 is the slow one.Still much faster than Modula-3.

There is a linked list through fs:0.fs:0 is thread local.For code speed, the link/unlink can be inlined.For code size, it can be a small function call.Just like two instructions for function enter and exit.And set a local volatile "as scopes are crossed".

locals used in the except/finallyblock are not likely enregistered across calls.

Compare this with current Modula-3:

 pthread_getspecific (TlsGetValue)  to get the current head  link it in  setjmp 
  And this happens for every TRY, instead of just at most once per function. 
The fs:0 link/unlink is at most once per function.

And all the other NT platforms are faster.

They don't link/unlink anything.They have metadata describing prologs.The runtime can use that to restore nonvolatile registers (includingthe stack) at any point.The codegen is somewhat constrained -- to be describable,but I suspect what you can describe encompasses anythinga compiler would want to do.Leaf functions have no data, and can't change nonvolatile registers,including rsp, and they can't make any calls (which would change rsp).

The tables are found from the return address.The only dynamic data the runtime has to leave aroundis the actual return address. No linked list, no volatile localindicating position in the function.

fs:0 is the NT/x86 location.This is a highly optimized thread local (fiber local actually).I don't know what other ABIs use, if anything -- again, all the otherNT platforms have no linked list, just return addresses and metadata.


Notes:The non-x86 approach is sometimes referred to as "no overhead", as "TRY" doesn't do anything (exceptleave cold data around).X86 exception dispatch is faster than non-x86. The stack is faster to walk, through the fs:0 linked list.The premise is that exception dispatch can be slow.The non exceptional paths are what should be optimized.And again, even NT/x86 is much more optimized than what Modula-3 does.


 - Jay



Date: Sun, 19 Jul 2015 12:06:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?


  
    
  
  
    

    Am 2015-07-19 um 11:38 schrieb Elmar
      Stellnberger:

    
    
      
      

      Am 2015-07-19 um 11:10 schrieb Jay K:

      
      
        
        I'm pretty sure it can work, but you need also a
          local "dense" volatile integer that describes where in the
          function you are.  That isn't free, but it is much cheaper
          than calling setjmp/PushFrame for each try.
          

          
        
      
      Is it really that much faster? I can remember having implemented
      my own setjump/longjump in assembly some time ago and it should
      only save you one procedure call but generate some additional
      jumps. However I do not know how time costly the new-fashioned
      register value obfuscation is (registers are no more stored as
      they are but obfuscated for security reasons by glibc). Xor-ing by
      a simple value; does it really cost the world? I am not the one
      who can tell you whether such a venture like this would pay off
      ...

      

      

    
    

    You are right. It would be somewhat faster especially on AMD64 where
    we have a lot of registers to rescue ...

    

    

    
      
        
          

          
          Try writing similar C++ for NT/x86 and look at what you
            get.
          "PushFrame" is highly optimized to build a linked list
            through fs:0.
          And even that is only done at most once per function.
        
      
      

      Through fs:0 ? It used to be on the ss:[e/r]b in former times.

      Since pthreading it may also be fs:0 under Linux because of
      get/setspecific.

      I am not sure what these functions do in detail (something with fs
      at last).

      

      Nonetheless I would believe that avoiding to call get/setspecific
      could speed

      things up noticeably. First there is the function overhead, second
      we need to

      touch an independent memory area and last but not least the stack
      is 

      always thread local. However I am not sure on how we could place
      the top

      anchor for the linked list of exception frames otherwise. Push an
      exception

       frame pointer into every local variable area?

    
    

    However I believe this should also be worth a consideration as soon
    as we talk about m3cg support and speed.

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/d27e2d99/attachment.html>

From estellnb at elstel.org  Sun Jul 19 14:02:24 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 14:02:24 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>,
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl> <55AB7011.9070709@elstel.org>,
 <55AB769C.2020806@elstel.org> <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
Message-ID: <55AB91D0.80303@elstel.org>


Am 2015-07-19 um 12:19 schrieb Jay K:
> And all the other NT platforms are faster.
> They don't link/unlink anything.
> They have metadata describing prologs.
> The runtime can use that to restore nonvolatile registers (including
> the stack) at any point.

including NT-AMD64 or not? -
but PowerPC, MIPS, Alpha, Itanium and ARM?

interesting. What happens if I have a variable being kept in a register
like register int x? These registers would still need to be saved as
a prolog could never tell us (i.e. we would then again need a linked
list) ...

... and then if we have prologues we would not need to pin down
any word that could refer as a refany to the traced heap in our
locales area but only those which really do (The question is of
course what data is in these prologues and what data is not.).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/59daae07/attachment.html>

From jay.krell at cornell.edu  Sun Jul 19 19:46:36 2015
From: jay.krell at cornell.edu (Jay)
Date: Sun, 19 Jul 2015 10:46:36 -0700
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB91D0.80303@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
 <55AB6667.7010908@elstel.org> <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
 <55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org>
 <COL130-W98F71B1447317E3FAF027E6860@phx.gbl> <55AB91D0.80303@elstel.org>
Message-ID: <F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>

NT/amd64 & likely all NT architectures except x86: The pdata gives function boundaries and the xdata provides information to restore nonvolatile registers, including rsp and return address. Locals may be enregistered across function calls in nonvolatile registers. 


There is no linked list.
There is a reliable stack walker including restoring nonvolatile registers provided by ther operating system (RtlUnwind, RtlVirtualUnwind).


 - Jay

On Jul 19, 2015, at 5:02 AM, Elmar Stellnberger <estellnb at elstel.org> wrote:

> 
> Am 2015-07-19 um 12:19 schrieb Jay K:
>> And all the other NT platforms are faster.
>> They don't link/unlink anything.
>> They have metadata describing prologs.
>> The runtime can use that to restore nonvolatile registers (including
>> the stack) at any point.
> 
> including NT-AMD64 or not? - 
> but PowerPC, MIPS, Alpha, Itanium and ARM?
> 
> interesting. What happens if I have a variable being kept in a register
> like register int x? These registers would still need to be saved as 
> a prolog could never tell us (i.e. we would then again need a linked 
> list) ...
> 
> ... and then if we have prologues we would not need to pin down
> any word that could refer as a refany to the traced heap in our 
> locales area but only those which really do (The question is of
> course what data is in these prologues and what data is not.).
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/60d15479/attachment.html>

From jay.krell at cornell.edu  Mon Jul 20 09:21:18 2015
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 20 Jul 2015 07:21:18 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>,<55AB7011.9070709@elstel.org>
 <55AB769C.2020806@elstel.org>,<COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
 <55AB91D0.80303@elstel.org>,<F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>
Message-ID: <COL130-W47FB963569F6C12D414571E6850@phx.gbl>

ps: translating to C for Win32 or C++ for any targets nets you whatever is the local optimized exception handling runtime, including certainly this stuff on NT.
Sometimes that might merely be a similar setjmp/longjmp based system, but often not.
But we need higher level m3cg operations for exception handling to do this (or some awful reverse induction in the backend..)
 - Jay


From: jay.krell at cornell.edu
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?
Date: Sun, 19 Jul 2015 10:46:36 -0700
To: estellnb at elstel.org

NT/amd64 & likely all NT architectures except x86: The pdata gives function boundaries and the xdata provides information to restore nonvolatile registers, including rsp and return address. Locals may be enregistered across function calls in nonvolatile registers. 

There is no linked list.There is a reliable stack walker including restoring nonvolatile registers provided by ther operating system (RtlUnwind, RtlVirtualUnwind).

 - Jay
On Jul 19, 2015, at 5:02 AM, Elmar Stellnberger <estellnb at elstel.org> wrote:


  
    
  
  
    

    Am 2015-07-19 um 12:19 schrieb Jay K:

    
    
      
      
        And all the other NT platforms are faster.
      
    
    
      
        They don't link/unlink anything.
        They have metadata describing prologs.
        The runtime can use that to restore nonvolatile registers
          (including
        the stack) at any point.
      
    
    

    including NT-AMD64 or not? - 

    but PowerPC, MIPS, Alpha, Itanium and ARM?

    

    interesting. What happens if I have a variable being kept in a
    register

    like register int x? These registers would still need to be saved as
    

    a prolog could never tell us (i.e. we would then again need a linked
    

    list) ...

    

    ... and then if we have prologues we would not need to pin down

    any word that could refer as a refany to the traced heap in our 

    locales area but only those which really do (The question is of

    course what data is in these prologues and what data is not.).

    

    

    

  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150720/8c45a67f/attachment.html>

From rodney_bates at lcwb.coop  Tue Jul 21 18:21:22 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 21 Jul 2015 11:21:22 -0500
Subject: [M3devel] O(1) FIFO wakeup of waiters on both Mutexs and Conditions
Message-ID: <55AE7182.3060709@lcwb.coop>

I just committed and pushed the subject change.  It could probably use more
testing.  It has shown no problems with m3-libs/m3core/tests/thread, for a
few combinations of thread count and iteration count.

I committed the old version as ThreadPThread0.m3, so it can be reverted
quickly, if bugs show up.  Look in the m3makefile to switch by simple
commenting in and out.

New or old version, it will require recompiles and ships of everything
in the closure of a main program to try it.


-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Wed Jul 22 07:42:29 2015
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 22 Jul 2015 05:42:29 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
Message-ID: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>

In the C backend I have a notion of "weak struct types" and "strong struct types".

"Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.

"Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.


Originally I had only weak types.Ideally I have no weak types.I'm down to very few weak types now.I'd like to finish eliminating weak types.


A quick investigation shows weak types come from open arrays and jmpbufs.Open array temporaries from SUBARRAY specifically.


Can we fix this?


We have:m3front/src/types/OpenArrayType.m3:
PROCEDURE DeclareTemp (t: Type.T): CG.Var =  VAR    p    := Reduce (t);    size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;  BEGIN    RETURN CG.Declare_temp (size, Target.Address.align,                            CG.Type.Struct, in_memory := TRUE);  END DeclareTemp;

PROCEDURE Compiler (p: P) =  VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;  BEGIN    Type.Compile (p.element);    CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);  END Compiler;

DeclareTemp is used in SUBARRAY expressions -- truly temporaries,not variables authored by anyone in Modula-3.

Can this be easily fixed?

Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150722/b0e622c2/attachment.html>

From rodney_bates at lcwb.coop  Thu Jul 23 02:30:12 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 22 Jul 2015 19:30:12 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>
Message-ID: <55B03594.20800@lcwb.coop>

I'm not exactly sure what you are asking, but here is some light on what
you are seeing.  These temporaries are exactly the dope the compiler uses
to represent all open array values.  First a pointer to the zeroth
array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
an array of element counts for each open subscript.  For an open array
parameter, this would be the machine representation of the parameter
itself, authored in M3. (but passed by reference.)  For a heap object,
it is stored right before the elements themselves.  For a SUBARRAY
expression, it has to be a temporary.  It also has to be constructed
at the call site, as an anonymous temporary, when passing an entire fixed
array to an open array parameter

So, a good type for it might look like:


RECORD
   Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
END

Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
static limit here in the type of Elements, as it will be enforced dynamically,
using Shape.  But we don't want to just say REF ARRAY OF ElementType either,
as this would mean another open array inside the dope, resulting in infinite
recursion.

On 07/22/2015 12:42 AM, Jay K wrote:
> In the C backend I have a notion of "weak struct types" and "strong struct types".
>
>
> "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>
>
> "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>
>
>
> Originally I had only weak types.
> Ideally I have no weak types.
> I'm down to very few weak types now.
> I'd like to finish eliminating weak types.
>
>
>
> A quick investigation shows weak types come from open arrays and jmpbufs.
> Open array temporaries from SUBARRAY specifically.
>
>
>
> Can we fix this?
>
>
>
> We have:
> m3front/src/types/OpenArrayType.m3:
>
> PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>    VAR
>      p    := Reduce (t);
>      size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>    BEGIN
>      RETURN CG.Declare_temp (size, Target.Address.align,
>                              CG.Type.Struct, in_memory := TRUE);
>    END DeclareTemp;
>
>
> PROCEDURE Compiler (p: P) =
>    VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>    BEGIN
>      Type.Compile (p.element);
>      CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>    END Compiler;
>
>
> DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> not variables authored by anyone in Modula-3.
>
>
> Can this be easily fixed?
>
>
> Thanks,
>   - Jay
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Fri Jul 24 10:57:14 2015
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 24 Jul 2015 08:57:14 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <55B03594.20800@lcwb.coop>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>,
 <55B03594.20800@lcwb.coop>
Message-ID: <COL130-W78229587075BD6B3A94050E6810@phx.gbl>

I model this in C like:

M3C.m3:        print(self, "/*declare_open_array*/typedef struct {");        print(self, element_type.text);        print(self, "* _elts; CARDINAL _size");        IF bit_size > Target.Integer.size * 2 THEN            print(self, "s[");            print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));            print(self, "]");        END;

that is..and this i stinky that I get the struct "size",

size == 2 * sizeof(integer):

struct {T* elementssize_t size;}

else: N = size - sizeof(INTEGER) / sizeof(INTEGER) T ** elements; // where the number of star is N  size_t sizes[N]

It is kind of lame that the frontend just gives the overall sizeand the backend is just left to assume the layout like that.
Really, the frontend should declare a type "pointer to pointer to pointer" withthe right "depth", and then a record with that pointer and a size or fixed size array of sizes.

Again, really ugly how it works now where backend is just given a size and can onlyassume the layout.
I don't know what a "dope vector" is. A value used as an initializer?

It is even worse for subarray. In this case we aren't even told it is an open array, justsome random struct with a size. That is what I first want to fix. It should declare an open array,assuming they do have the same layout, which I think they do.

subarray temporaries and jmpbufs are I believe the only place the frontend passes so littletype information.

For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace themwith #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.



 - Jay


> Date: Wed, 22 Jul 2015 19:30:12 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> 
> I'm not exactly sure what you are asking, but here is some light on what
> you are seeing.  These temporaries are exactly the dope the compiler uses
> to represent all open array values.  First a pointer to the zeroth
> array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
> an array of element counts for each open subscript.  For an open array
> parameter, this would be the machine representation of the parameter
> itself, authored in M3. (but passed by reference.)  For a heap object,
> it is stored right before the elements themselves.  For a SUBARRAY
> expression, it has to be a temporary.  It also has to be constructed
> at the call site, as an anonymous temporary, when passing an entire fixed
> array to an open array parameter
> 
> So, a good type for it might look like:
> 
> 
> RECORD
>    Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
> ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
> END
> 
> Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
> static limit here in the type of Elements, as it will be enforced dynamically,
> using Shape.  But we don't want to just say REF ARRAY OF ElementType either,
> as this would mean another open array inside the dope, resulting in infinite
> recursion.
> 
> On 07/22/2015 12:42 AM, Jay K wrote:
> > In the C backend I have a notion of "weak struct types" and "strong struct types".
> >
> >
> > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
> >
> >
> > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
> >
> >
> >
> > Originally I had only weak types.
> > Ideally I have no weak types.
> > I'm down to very few weak types now.
> > I'd like to finish eliminating weak types.
> >
> >
> >
> > A quick investigation shows weak types come from open arrays and jmpbufs.
> > Open array temporaries from SUBARRAY specifically.
> >
> >
> >
> > Can we fix this?
> >
> >
> >
> > We have:
> > m3front/src/types/OpenArrayType.m3:
> >
> > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
> >    VAR
> >      p    := Reduce (t);
> >      size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >    BEGIN
> >      RETURN CG.Declare_temp (size, Target.Address.align,
> >                              CG.Type.Struct, in_memory := TRUE);
> >    END DeclareTemp;
> >
> >
> > PROCEDURE Compiler (p: P) =
> >    VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >    BEGIN
> >      Type.Compile (p.element);
> >      CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
> >    END Compiler;
> >
> >
> > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> > not variables authored by anyone in Modula-3.
> >
> >
> > Can this be easily fixed?
> >
> >
> > Thanks,
> >   - Jay
> >
> >
> >
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150724/9fc74156/attachment.html>

From rodney_bates at lcwb.coop  Fri Jul 24 16:57:37 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 24 Jul 2015 09:57:37 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W78229587075BD6B3A94050E6810@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>,
 <55B03594.20800@lcwb.coop>
 <COL130-W78229587075BD6B3A94050E6810@phx.gbl>
Message-ID: <55B25261.5010106@lcwb.coop>



On 07/24/2015 03:57 AM, Jay K wrote:
> I model this in C like:
>
>
> M3C.m3:
>          print(self, "/*declare_open_array*/typedef struct {");

Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?

>          print(self, element_type.text);
>          print(self, "* _elts; CARDINAL _size");
>          IF bit_size > Target.Integer.size * 2 THEN
>              print(self, "s[");
>              print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
>              print(self, "]");
>          END;
>
>
> that is..and this i stinky that I get the struct "size",
>
>
> size == 2 * sizeof(integer):
>
>
> struct {
> T* elements
> size_t size;
> }
>
>
> else:
>   N = size - sizeof(INTEGER) / sizeof(INTEGER)
>   T ** elements; // where the number of star is N

I would not do pointer to pointer to pointer ... here.  Just "T* elements", regardless
of the number of open dimensions.  As I understand them, C's language-supported
multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
the language does the multi-subscript address arithmetic, which means the type
system needs to provide a static element size of each dimension.  And that,
except for the innermost, depends on the element count of the next inner
dimension, which is not static here.

So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
is lowered by the front end into explicit address arithmetic into the flattened
array, using the values in the shape.  Something like A[I*Shape[0]+J*Shape[1]+K]

>    size_t sizes[N]
>
>
> It is kind of lame that the frontend just gives the overall size
> and the backend is just left to assume the layout like that.

If you know in M3C that it's an open array, you can infer what the layout is.
But yes, it's kind of lame.  This is just another of the several places we have
seen that the front end has lowered things too far, and you have to
You know it's generated by code in OpenArray.m3, and you know the general dope layout,
and open dimension count, so you can generate an appropriate type.


>
> Really, the frontend should declare a type "pointer to pointer to pointer" with
> the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
>
>
> Again, really ugly how it works now where backend is just given a size and can only
> assume the layout.
>
> I don't know what a "dope vector" is. A value used as an initializer?
>

This is a very old and rather uninformative term for any block of stuff stored at runtime
that describes some source programmer's real data and how to access it.  The only alternative
term I can think of would be "metadata", although that is rather overgeneral, and is usually
used with quite different specific meanings.  But it is data describing data.

>
> It is even worse for subarray. In this case we aren't even told it is an open array, just
> some random struct with a size. That is what I first want to fix. It should declare an open array,
> assuming they do have the same layout, which I think they do.
>

What you really need to know is that it's an open array, of which subarray is a subcategory.
In our implementation, all open array values have the same dope.  E.g., look for the case where
a fixed array actual parameter is passed to an open array formal.

>
> subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
> type information.
>
>
> For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
> with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
>
>
>
>
>   - Jay
>
>
>  > Date: Wed, 22 Jul 2015 19:30:12 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  >
>  > I'm not exactly sure what you are asking, but here is some light on what
>  > you are seeing. These temporaries are exactly the dope the compiler uses
>  > to represent all open array values. First a pointer to the zeroth
>  > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
>  > an array of element counts for each open subscript. For an open array
>  > parameter, this would be the machine representation of the parameter
>  > itself, authored in M3. (but passed by reference.) For a heap object,
>  > it is stored right before the elements themselves. For a SUBARRAY
>  > expression, it has to be a temporary. It also has to be constructed
>  > at the call site, as an anonymous temporary, when passing an entire fixed
>  > array to an open array parameter
>  >
>  > So, a good type for it might look like:
>  >
>  >
>  > RECORD
>  > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
>  > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
>  > END
>  >
>  > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
>  > static limit here in the type of Elements, as it will be enforced dynamically,
>  > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
>  > as this would mean another open array inside the dope, resulting in infinite
>  > recursion.
>  >
>  > On 07/22/2015 12:42 AM, Jay K wrote:
>  > > In the C backend I have a notion of "weak struct types" and "strong struct types".
>  > >
>  > >
>  > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>  > >
>  > >
>  > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>  > >
>  > >
>  > >
>  > > Originally I had only weak types.
>  > > Ideally I have no weak types.
>  > > I'm down to very few weak types now.
>  > > I'd like to finish eliminating weak types.
>  > >
>  > >
>  > >
>  > > A quick investigation shows weak types come from open arrays and jmpbufs.
>  > > Open array temporaries from SUBARRAY specifically.
>  > >
>  > >
>  > >
>  > > Can we fix this?
>  > >
>  > >
>  > >
>  > > We have:
>  > > m3front/src/types/OpenArrayType.m3:
>  > >
>  > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>  > > VAR
>  > > p := Reduce (t);
>  > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > BEGIN
>  > > RETURN CG.Declare_temp (size, Target.Address.align,
>  > > CG.Type.Struct, in_memory := TRUE);
>  > > END DeclareTemp;
>  > >
>  > >
>  > > PROCEDURE Compiler (p: P) =
>  > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > BEGIN
>  > > Type.Compile (p.element);
>  > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>  > > END Compiler;
>  > >
>  > >
>  > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
>  > > not variables authored by anyone in Modula-3.
>  > >
>  > >
>  > > Can this be easily fixed?
>  > >
>  > >
>  > > Thanks,
>  > > - Jay
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > > M3devel mailing list
>  > > M3devel at elegosoft.com
>  > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  > >
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Sat Jul 25 18:39:45 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 25 Jul 2015 11:39:45 -0500
Subject: [M3devel] Strange CM3 IR for FINALLY
Message-ID: <55B3BBD1.7040203@lcwb.coop>

In looking at CM3 IR for TRY-FINALLY, for an unrelated reason, I find the following:

The front end translates the code found between FINALLY and END into a nested procedure.
This is declared as having one parameter of type ADDRESS.  But, in the the direct call
it generates, right before the FINALLY, it passes no actual.  Also, in the simple example
I looked at, the finally procedure does not access its formal.

It also stores the address of the finally procedure in a 5-word record whose address
it passes to RTHooks.PushEFrame and PopEFrame.  RTHooks.i3 treats this as ADDRESS, and
tells us nothing about what it actually points to.

Is there a bug, or does anybody understand what is going on here?
-- 
Rodney Bates
rodney.m.bates at acm.org


From peter.mckinna at gmail.com  Sun Jul 26 03:02:35 2015
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 26 Jul 2015 11:02:35 +1000
Subject: [M3devel] Strange CM3 IR for FINALLY
In-Reply-To: <55B3BBD1.7040203@lcwb.coop>
References: <55B3BBD1.7040203@lcwb.coop>
Message-ID: <CAEy6uxpjkVbMtHwF+=AqfmFs32F3DT0pjMeZqy0QBbbt3DSXXA@mail.gmail.com>

Theres a comment at about line 216 in TryFinStmt.m3 that suggests the
authors were not too sure about this either.

Regards Peter.

On Sun, Jul 26, 2015 at 2:39 AM, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:

> In looking at CM3 IR for TRY-FINALLY, for an unrelated reason, I find the
> following:
>
> The front end translates the code found between FINALLY and END into a
> nested procedure.
> This is declared as having one parameter of type ADDRESS.  But, in the the
> direct call
> it generates, right before the FINALLY, it passes no actual.  Also, in the
> simple example
> I looked at, the finally procedure does not access its formal.
>
> It also stores the address of the finally procedure in a 5-word record
> whose address
> it passes to RTHooks.PushEFrame and PopEFrame.  RTHooks.i3 treats this as
> ADDRESS, and
> tells us nothing about what it actually points to.
>
> Is there a bug, or does anybody understand what is going on here?
> --
> Rodney Bates
> rodney.m.bates at acm.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150726/a27f1a68/attachment.html>

From jay.krell at cornell.edu  Thu Jul 30 02:07:18 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 00:07:18 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <55B25261.5010106@lcwb.coop>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>, ,
 <55B03594.20800@lcwb.coop>, <COL130-W78229587075BD6B3A94050E6810@phx.gbl>,
 <55B25261.5010106@lcwb.coop>
Message-ID: <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>

As part of fixing this, I want M3CG_Ops.i3
declare_temp (s: ByteSize;  a: Alignment;  t: Type;              in_memory: BOOLEAN): Var;

to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, ifthat syntax is allowed, or all existing calls can initially pass M3ID.NoID.

The use in OpenArrayType.DeclareTemp will then be changed to something else.DeclareTemp will look more like OpenArrayType.Compiler.

And, something will be done for jmpbufs, such having them be named and passing that name alongsomewhere. Or giving them a special uid, or even their own special CG.Type?

And then, every use of CG.Type.Struct must come along with a TypeUID.

ok?
The C backend will/should actually be able notice the name of the jmpbuf type and substitutein.. #include <setjmp.h> jmpbuf.
Other backends should  substitute in the alloca use.
Or, it will be an internal parameter to the frontend for it to do the alloca transformation.
But this is getting ahead of things.
First -- change declare_temp to accept a TypeUID ok?


 - Jay


> Date: Fri, 24 Jul 2015 09:57:37 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu; m3devel at elegosoft.com; m3devel at elegosoft.com
> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> 
> 
> 
> On 07/24/2015 03:57 AM, Jay K wrote:
> > I model this in C like:
> >
> >
> > M3C.m3:
> >          print(self, "/*declare_open_array*/typedef struct {");
> 
> Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?
> 
> >          print(self, element_type.text);
> >          print(self, "* _elts; CARDINAL _size");
> >          IF bit_size > Target.Integer.size * 2 THEN
> >              print(self, "s[");
> >              print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
> >              print(self, "]");
> >          END;
> >
> >
> > that is..and this i stinky that I get the struct "size",
> >
> >
> > size == 2 * sizeof(integer):
> >
> >
> > struct {
> > T* elements
> > size_t size;
> > }
> >
> >
> > else:
> >   N = size - sizeof(INTEGER) / sizeof(INTEGER)
> >   T ** elements; // where the number of star is N
> 
> I would not do pointer to pointer to pointer ... here.  Just "T* elements", regardless
> of the number of open dimensions.  As I understand them, C's language-supported
> multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
> the language does the multi-subscript address arithmetic, which means the type
> system needs to provide a static element size of each dimension.  And that,
> except for the innermost, depends on the element count of the next inner
> dimension, which is not static here.
> 
> So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
> is lowered by the front end into explicit address arithmetic into the flattened
> array, using the values in the shape.  Something like A[I*Shape[0]+J*Shape[1]+K]
> 
> >    size_t sizes[N]
> >
> >
> > It is kind of lame that the frontend just gives the overall size
> > and the backend is just left to assume the layout like that.
> 
> If you know in M3C that it's an open array, you can infer what the layout is.
> But yes, it's kind of lame.  This is just another of the several places we have
> seen that the front end has lowered things too far, and you have to
> You know it's generated by code in OpenArray.m3, and you know the general dope layout,
> and open dimension count, so you can generate an appropriate type.
> 
> 
> >
> > Really, the frontend should declare a type "pointer to pointer to pointer" with
> > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
> >
> >
> > Again, really ugly how it works now where backend is just given a size and can only
> > assume the layout.
> >
> > I don't know what a "dope vector" is. A value used as an initializer?
> >
> 
> This is a very old and rather uninformative term for any block of stuff stored at runtime
> that describes some source programmer's real data and how to access it.  The only alternative
> term I can think of would be "metadata", although that is rather overgeneral, and is usually
> used with quite different specific meanings.  But it is data describing data.
> 
> >
> > It is even worse for subarray. In this case we aren't even told it is an open array, just
> > some random struct with a size. That is what I first want to fix. It should declare an open array,
> > assuming they do have the same layout, which I think they do.
> >
> 
> What you really need to know is that it's an open array, of which subarray is a subcategory.
> In our implementation, all open array values have the same dope.  E.g., look for the case where
> a fixed array actual parameter is passed to an open array formal.
> 
> >
> > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
> > type information.
> >
> >
> > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
> > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
> >
> >
> >
> >
> >   - Jay
> >
> >
> >  > Date: Wed, 22 Jul 2015 19:30:12 -0500
> >  > From: rodney_bates at lcwb.coop
> >  > To: m3devel at elegosoft.com
> >  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> >  >
> >  > I'm not exactly sure what you are asking, but here is some light on what
> >  > you are seeing. These temporaries are exactly the dope the compiler uses
> >  > to represent all open array values. First a pointer to the zeroth
> >  > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
> >  > an array of element counts for each open subscript. For an open array
> >  > parameter, this would be the machine representation of the parameter
> >  > itself, authored in M3. (but passed by reference.) For a heap object,
> >  > it is stored right before the elements themselves. For a SUBARRAY
> >  > expression, it has to be a temporary. It also has to be constructed
> >  > at the call site, as an anonymous temporary, when passing an entire fixed
> >  > array to an open array parameter
> >  >
> >  > So, a good type for it might look like:
> >  >
> >  >
> >  > RECORD
> >  > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
> >  > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
> >  > END
> >  >
> >  > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
> >  > static limit here in the type of Elements, as it will be enforced dynamically,
> >  > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
> >  > as this would mean another open array inside the dope, resulting in infinite
> >  > recursion.
> >  >
> >  > On 07/22/2015 12:42 AM, Jay K wrote:
> >  > > In the C backend I have a notion of "weak struct types" and "strong struct types".
> >  > >
> >  > >
> >  > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
> >  > >
> >  > >
> >  > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
> >  > >
> >  > >
> >  > >
> >  > > Originally I had only weak types.
> >  > > Ideally I have no weak types.
> >  > > I'm down to very few weak types now.
> >  > > I'd like to finish eliminating weak types.
> >  > >
> >  > >
> >  > >
> >  > > A quick investigation shows weak types come from open arrays and jmpbufs.
> >  > > Open array temporaries from SUBARRAY specifically.
> >  > >
> >  > >
> >  > >
> >  > > Can we fix this?
> >  > >
> >  > >
> >  > >
> >  > > We have:
> >  > > m3front/src/types/OpenArrayType.m3:
> >  > >
> >  > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
> >  > > VAR
> >  > > p := Reduce (t);
> >  > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >  > > BEGIN
> >  > > RETURN CG.Declare_temp (size, Target.Address.align,
> >  > > CG.Type.Struct, in_memory := TRUE);
> >  > > END DeclareTemp;
> >  > >
> >  > >
> >  > > PROCEDURE Compiler (p: P) =
> >  > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >  > > BEGIN
> >  > > Type.Compile (p.element);
> >  > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
> >  > > END Compiler;
> >  > >
> >  > >
> >  > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> >  > > not variables authored by anyone in Modula-3.
> >  > >
> >  > >
> >  > > Can this be easily fixed?
> >  > >
> >  > >
> >  > > Thanks,
> >  > > - Jay
> >  > >
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > M3devel mailing list
> >  > > M3devel at elegosoft.com
> >  > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >  > >
> >  >
> >  > --
> >  > Rodney Bates
> >  > rodney.m.bates at acm.org
> >  > _______________________________________________
> >  > M3devel mailing list
> >  > M3devel at elegosoft.com
> >  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/7b3133de/attachment.html>

From jay.krell at cornell.edu  Thu Jul 30 02:38:49 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 00:38:49 +0000
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or
 exception handling?
Message-ID: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>

I don't have one precise proposal, but somehow,jmpbuf/setjmp/longjmp should be represented in a higher level in m3cgor maybe "even higher level", exception handling.

There are multiple optimization opportunties and multipleopportunities to move/remove target-dependent code.


In particular m3middle/m3front should not know jmpbuf size.Generated C should not have jmpbuf sizes embedded in it.

gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exceptionhandling, that llvm replicates, that is optimized, like to notsave/restore unused registers.

Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.

In particular, the C backend just wants to know something is a "jmpbuf"so it can #include <setjmp.h> in the generated code and produce ajmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.

Or even better, a C++ backend wants to somehow module Modula-3 exceptionsas C++ exceptions.

Or, possibly, the Win32 C backend could model Modula-3 exceptions using"structured exception handling" -- advantage over C++ exceptions is portabilityto kernel mode.

Thoughts? - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/9ebaac62/attachment.html>

From jay.krell at cornell.edu  Thu Jul 30 06:36:34 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 04:36:34 +0000
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
 or exception handling?
In-Reply-To: <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>,
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
Message-ID: <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>

On the last point -- I'm willing to generate C++ instead of C. Does that help?I think it probably does.

On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS Ithink all support what Win32 support -- not a coincidence..

One thing I'm missing is I don't know really know how exceptions are lowered currently.Like, what does the runtime data look like for the "filtering".I should know better..

I think we can also essentially claim all targets have a stack walker.One way or another -- libunwind, NT RtlUnwindEx, etc.

 - Jay



Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
From: hosking at purdue.edu
Date: Thu, 30 Jul 2015 14:04:14 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu> wrote:I don't have one precise proposal, but somehow,jmpbuf/setjmp/longjmp should be represented in a higher level in m3cgor maybe "even higher level", exception handling.

There are multiple optimization opportunties and multipleopportunities to move/remove target-dependent code.


In particular m3middle/m3front should not know jmpbuf size.Generated C should not have jmpbuf sizes embedded in it.

gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exceptionhandling, that llvm replicates, that is optimized, like to notsave/restore unused registers.

Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.

In particular, the C backend just wants to know something is a "jmpbuf"so it can #include <setjmp.h> in the generated code and produce ajmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.

Or even better, a C++ backend wants to somehow module Modula-3 exceptionsas C++ exceptions.

Or, possibly, the Win32 C backend could model Modula-3 exceptions using"structured exception handling" -- advantage over C++ exceptions is portabilityto kernel mode.

Thoughts? - Jay

_______________________________________________M3devel mailing listM3devel at elegosoft.comhttps://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/4be773ce/attachment.html>

From rodney_bates at lcwb.coop  Thu Jul 30 16:16:58 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 Jul 2015 09:16:58 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>, ,
 <55B03594.20800@lcwb.coop>, <COL130-W78229587075BD6B3A94050E6810@phx.gbl>,
 <55B25261.5010106@lcwb.coop> <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>
Message-ID: <55BA31DA.3020905@lcwb.coop>

I'm all for having a better IR in cm3.  I've had a few serious frustrations from lack of
sufficient information in it.  But, if we touch it at all, I really want to try very hard
to think of and do everything we are likely to want in the foreseeable future.  Any
change is painful.  There are somewhere in the neighborhood of 8 or so files that have
to reflect the change.  Also, it requires atomic update to both the front end and m3cc,
which then creates bootstrap issues that have to be handled very carefully.  Jay, your
recent changes to the build process help.  But I want to avoid changing it more than
once if we can possibly avoid it.  AFAIK, m3cc is the only one that ends up a separate
executable.

And when we do it, change the version number, for better mismatch messages.  Also,
it would be the best time to add a magic number, as Elmar was wanting.

One place I encountered was in trying to get better error messages from m3linker, etc.
We get stuff like (paraphrasing from memory) "Error: missing type _t187630885".  Need
I say more?  In trying to make these helpful, I ran up against lack of information.
I remember being able to make slight improvement in one message, but that was it,
without IR changes.

Then there are also some type info deficiencies for generating debug info.  I am
remembering something about inability to connect a procedure type to procedures
that match it, or something.

On 07/29/2015 07:07 PM, Jay K wrote:
> As part of fixing this, I want M3CG_Ops.i3
>
> declare_temp (s: ByteSize;  a: Alignment;  t: Type;
>                in_memory: BOOLEAN): Var;
>
>
> to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, if
> that syntax is allowed, or all existing calls can initially pass M3ID.NoID.
>
>
> The use in OpenArrayType.DeclareTemp will then be changed to something else.
> DeclareTemp will look more like OpenArrayType.Compiler.
>
>
> And, something will be done for jmpbufs, such having them be named and passing that name along
> somewhere. Or giving them a special uid, or even their own special CG.Type?
>
>
> And then, every use of CG.Type.Struct must come along with a TypeUID.
>
>
> ok?
>
> The C backend will/should actually be able notice the name of the jmpbuf type and substitute
> in.. #include <setjmp.h> jmpbuf.
>
> Other backends should  substitute in the alloca use.
>
> Or, it will be an internal parameter to the frontend for it to do the alloca transformation.
>
> But this is getting ahead of things.
>
> First -- change declare_temp to accept a TypeUID ok?
>
>
>
>   - Jay
>
>
>  > Date: Fri, 24 Jul 2015 09:57:37 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: jay.krell at cornell.edu; m3devel at elegosoft.com; m3devel at elegosoft.com
>  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  >
>  >
>  >
>  > On 07/24/2015 03:57 AM, Jay K wrote:
>  > > I model this in C like:
>  > >
>  > >
>  > > M3C.m3:
>  > > print(self, "/*declare_open_array*/typedef struct {");
>  >
>  > Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?
>  >
>  > > print(self, element_type.text);
>  > > print(self, "* _elts; CARDINAL _size");
>  > > IF bit_size > Target.Integer.size * 2 THEN
>  > > print(self, "s[");
>  > > print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
>  > > print(self, "]");
>  > > END;
>  > >
>  > >
>  > > that is..and this i stinky that I get the struct "size",
>  > >
>  > >
>  > > size == 2 * sizeof(integer):
>  > >
>  > >
>  > > struct {
>  > > T* elements
>  > > size_t size;
>  > > }
>  > >
>  > >
>  > > else:
>  > > N = size - sizeof(INTEGER) / sizeof(INTEGER)
>  > > T ** elements; // where the number of star is N
>  >
>  > I would not do pointer to pointer to pointer ... here. Just "T* elements", regardless
>  > of the number of open dimensions. As I understand them, C's language-supported
>  > multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
>  > the language does the multi-subscript address arithmetic, which means the type
>  > system needs to provide a static element size of each dimension. And that,
>  > except for the innermost, depends on the element count of the next inner
>  > dimension, which is not static here.
>  >
>  > So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
>  > is lowered by the front end into explicit address arithmetic into the flattened
>  > array, using the values in the shape. Something like A[I*Shape[0]+J*Shape[1]+K]
>  >
>  > > size_t sizes[N]
>  > >
>  > >
>  > > It is kind of lame that the frontend just gives the overall size
>  > > and the backend is just left to assume the layout like that.
>  >
>  > If you know in M3C that it's an open array, you can infer what the layout is.
>  > But yes, it's kind of lame. This is just another of the several places we have
>  > seen that the front end has lowered things too far, and you have to
>  > You know it's generated by code in OpenArray.m3, and you know the general dope layout,
>  > and open dimension count, so you can generate an appropriate type.
>  >
>  >
>  > >
>  > > Really, the frontend should declare a type "pointer to pointer to pointer" with
>  > > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
>  > >
>  > >
>  > > Again, really ugly how it works now where backend is just given a size and can only
>  > > assume the layout.
>  > >
>  > > I don't know what a "dope vector" is. A value used as an initializer?
>  > >
>  >
>  > This is a very old and rather uninformative term for any block of stuff stored at runtime
>  > that describes some source programmer's real data and how to access it. The only alternative
>  > term I can think of would be "metadata", although that is rather overgeneral, and is usually
>  > used with quite different specific meanings. But it is data describing data.
>  >
>  > >
>  > > It is even worse for subarray. In this case we aren't even told it is an open array, just
>  > > some random struct with a size. That is what I first want to fix. It should declare an open array,
>  > > assuming they do have the same layout, which I think they do.
>  > >
>  >
>  > What you really need to know is that it's an open array, of which subarray is a subcategory.
>  > In our implementation, all open array values have the same dope. E.g., look for the case where
>  > a fixed array actual parameter is passed to an open array formal.
>  >
>  > >
>  > > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
>  > > type information.
>  > >
>  > >
>  > > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
>  > > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
>  > >
>  > >
>  > >
>  > >
>  > > - Jay
>  > >
>  > >
>  > > > Date: Wed, 22 Jul 2015 19:30:12 -0500
>  > > > From: rodney_bates at lcwb.coop
>  > > > To: m3devel at elegosoft.com
>  > > > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  > > >
>  > > > I'm not exactly sure what you are asking, but here is some light on what
>  > > > you are seeing. These temporaries are exactly the dope the compiler uses
>  > > > to represent all open array values. First a pointer to the zeroth
>  > > > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
>  > > > an array of element counts for each open subscript. For an open array
>  > > > parameter, this would be the machine representation of the parameter
>  > > > itself, authored in M3. (but passed by reference.) For a heap object,
>  > > > it is stored right before the elements themselves. For a SUBARRAY
>  > > > expression, it has to be a temporary. It also has to be constructed
>  > > > at the call site, as an anonymous temporary, when passing an entire fixed
>  > > > array to an open array parameter
>  > > >
>  > > > So, a good type for it might look like:
>  > > >
>  > > >
>  > > > RECORD
>  > > > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
>  > > > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
>  > > > END
>  > > >
>  > > > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
>  > > > static limit here in the type of Elements, as it will be enforced dynamically,
>  > > > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
>  > > > as this would mean another open array inside the dope, resulting in infinite
>  > > > recursion.
>  > > >
>  > > > On 07/22/2015 12:42 AM, Jay K wrote:
>  > > > > In the C backend I have a notion of "weak struct types" and "strong struct types".
>  > > > >
>  > > > >
>  > > > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>  > > > >
>  > > > >
>  > > > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>  > > > >
>  > > > >
>  > > > >
>  > > > > Originally I had only weak types.
>  > > > > Ideally I have no weak types.
>  > > > > I'm down to very few weak types now.
>  > > > > I'd like to finish eliminating weak types.
>  > > > >
>  > > > >
>  > > > >
>  > > > > A quick investigation shows weak types come from open arrays and jmpbufs.
>  > > > > Open array temporaries from SUBARRAY specifically.
>  > > > >
>  > > > >
>  > > > >
>  > > > > Can we fix this?
>  > > > >
>  > > > >
>  > > > >
>  > > > > We have:
>  > > > > m3front/src/types/OpenArrayType.m3:
>  > > > >
>  > > > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>  > > > > VAR
>  > > > > p := Reduce (t);
>  > > > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > > > BEGIN
>  > > > > RETURN CG.Declare_temp (size, Target.Address.align,
>  > > > > CG.Type.Struct, in_memory := TRUE);
>  > > > > END DeclareTemp;
>  > > > >
>  > > > >
>  > > > > PROCEDURE Compiler (p: P) =
>  > > > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > > > BEGIN
>  > > > > Type.Compile (p.element);
>  > > > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>  > > > > END Compiler;
>  > > > >
>  > > > >
>  > > > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
>  > > > > not variables authored by anyone in Modula-3.
>  > > > >
>  > > > >
>  > > > > Can this be easily fixed?
>  > > > >
>  > > > >
>  > > > > Thanks,
>  > > > > - Jay
>  > > > >
>  > > > >
>  > > > >
>  > > > > _______________________________________________
>  > > > > M3devel mailing list
>  > > > > M3devel at elegosoft.com
>  > > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  > > > >
>  > > >
>  > > > --
>  > > > Rodney Bates
>  > > > rodney.m.bates at acm.org
>  > > > _______________________________________________
>  > > > M3devel mailing list
>  > > > M3devel at elegosoft.com
>  > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Thu Jul 30 16:27:25 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 Jul 2015 09:27:25 -0500
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
 or exception handling?
In-Reply-To: <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>,
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
 <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>
Message-ID: <55BA344D.3020407@lcwb.coop>



On 07/29/2015 11:36 PM, Jay K wrote:
> On the last point -- I'm willing to generate C++ instead of C. Does that help?
> I think it probably does.
>
>
> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
> think all support what Win32 support -- not a coincidence..
>
>
> One thing I'm missing is I don't know really know how exceptions are lowered currently.
> Like, what does the runtime data look like for the "filtering".
> I should know better..
>
>
> I think we can also essentially claim all targets have a stack walker.
> One way or another -- libunwind, NT RtlUnwindEx, etc.

Really?  That would be great news.  If it really applies to them all, wouldn't
the jmpbuf problem just go away?

>
>
>   - Jay
>
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
> From: hosking at purdue.edu
> Date: Thu, 30 Jul 2015 14:04:14 +1000
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
> That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
>
>     On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>
>     I don't have one precise proposal, but somehow,
>     jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>     or maybe "even higher level", exception handling.
>
>
>     There are multiple optimization opportunties and multiple
>     opportunities to move/remove target-dependent code.
>
>
>
>     In particular m3middle/m3front should not know jmpbuf size.
>     Generated C should not have jmpbuf sizes embedded in it.
>
>
>     gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>     handling, that llvm replicates, that is optimized, like to not
>     save/restore unused registers.
>
>
>     Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>
>
>     In particular, the C backend just wants to know something is a "jmpbuf"
>     so it can #include <setjmp.h> in the generated code and produce a
>     jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>
>
>     Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>     as C++ exceptions.
>
>
>     Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>     "structured exception handling" -- advantage over C++ exceptions is portability
>     to kernel mode.
>
>
>     Thoughts?
>       - Jay
>
>
>     _______________________________________________
>     M3devel mailing list
>     M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>     https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Thu Jul 30 21:32:42 2015
From: jay.krell at cornell.edu (Jay)
Date: Thu, 30 Jul 2015 12:32:42 -0700
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
	or exception handling?
In-Reply-To: <55BA344D.3020407@lcwb.coop>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
 <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl> <55BA344D.3020407@lcwb.coop>
Message-ID: <5C73404D-582C-46BF-8F45-D6F1615B8769@gmail.com>

I believe libunwind/libgcc_s applies pretty broadly and address all non-NT platforms. I believe NT/non-x86 is documented enough. NT/x86 will take more research.


I also believe generating C++ is a good option, or Win32-specific C.


I do have the alloca+setjmp work finally almost done, slightly more work than I earlier realized & would like to get it in first, then optimize it in the C backend (the C backend specifically should declare a setjmp.h declared jmp_buf w/o alloca), & then look more into the "unwind" options. 


 - Jay

On Jul 30, 2015, at 7:27 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> 
> 
> On 07/29/2015 11:36 PM, Jay K wrote:
>> On the last point -- I'm willing to generate C++ instead of C. Does that help?
>> I think it probably does.
>> 
>> 
>> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
>> think all support what Win32 support -- not a coincidence..
>> 
>> 
>> One thing I'm missing is I don't know really know how exceptions are lowered currently.
>> Like, what does the runtime data look like for the "filtering".
>> I should know better..
>> 
>> 
>> I think we can also essentially claim all targets have a stack walker.
>> One way or another -- libunwind, NT RtlUnwindEx, etc.
> 
> Really?  That would be great news.  If it really applies to them all, wouldn't
> the jmpbuf problem just go away?
> 
>> 
>> 
>>  - Jay
>> 
>> 
>> 
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
> ---
>> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
>> From: hosking at purdue.edu
>> Date: Thu, 30 Jul 2015 14:04:14 +1000
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
>> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
>> That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
>> 
>>    On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>> 
>>    I don't have one precise proposal, but somehow,
>>    jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>>    or maybe "even higher level", exception handling.
>> 
>> 
>>    There are multiple optimization opportunties and multiple
>>    opportunities to move/remove target-dependent code.
>> 
>> 
>> 
>>    In particular m3middle/m3front should not know jmpbuf size.
>>    Generated C should not have jmpbuf sizes embedded in it.
>> 
>> 
>>    gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>>    handling, that llvm replicates, that is optimized, like to not
>>    save/restore unused registers.
>> 
>> 
>>    Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>> 
>> 
>>    In particular, the C backend just wants to know something is a "jmpbuf"
>>    so it can #include <setjmp.h> in the generated code and produce a
>>    jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>> 
>> 
>>    Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>>    as C++ exceptions.
>> 
>> 
>>    Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>>    "structured exception handling" -- advantage over C++ exceptions is portability
>>    to kernel mode.
>> 
>> 
>>    Thoughts?
>>      - Jay
>> 
>> 
>>    _______________________________________________
>>    M3devel mailing list
>>    M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>>    https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>> 
>> 
>> 
>> 
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri Jul 31 22:39:43 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 31 Jul 2015 15:39:43 -0500
Subject: [M3devel] m3core.h broken
Message-ID: <55BBDD0F.4080206@lcwb.coop>

On AMD64_LINUX, with gcc 4.8.1, m3-libs/src/m3core.h suffers many compile errors,
when compiling on m3core and cm3.  reverting line 363 of m3core.h makes them go away.
This is probably not the right way to fix this.


-- 
Rodney Bates
rodney.m.bates at acm.org


From wagner at elego.de  Thu Jul  2 17:40:06 2015
From: wagner at elego.de (Olaf Wagner)
Date: Thu, 02 Jul 2015 15:40:06 -0000
Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
 (0x100), expected 0x110
In-Reply-To: <55687266.3090400@marino.st>
References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>
 <55673AA4.8050100@marino.st>
 <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>
 <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>
 <556817A1.2090206@marino.st>
 <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>
 <55682D1A.2030504@marino.st>
 <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>
 <55683689.2090709@marino.st>
 <20150529122732.1396eb079ff9b404bcb21e40@elego.de>
 <5568421D.3050209@marino.st>
 <20150529155833.8454664b88391d93708e8f85@elego.de>
 <55687266.3090400@marino.st>
Message-ID: <20150529170707.ca3550f7aeda21e7853be995@elego.de>

On Fri, 29 May 2015 16:06:30 +0200
John Marino <adacore at marino.st> wrote:

> On 5/29/2015 15:58, Olaf Wagner wrote:
> > On Fri, 29 May 2015 12:40:29 +0200
> > John Marino <adacore at marino.st> wrote:
> > I unpacked your port and tried the first step.
> > But my system seems to be too old:
> > 
> > % make fetch 
> > ===>  modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later.
> > *** Error code 1
> 
> This means at best your machine is FreeBSD 8.x.  The last FreeBSD 8, 8.4
> (a long-term support version) expires in 4 weeks.  So you should update. :)
> 
> 
> > Stop in /src/ports/lang/modula3.
> > 
> > Why would it only run on FreeBSD 9?
> > I actually _have_ a  working cm3 installation on this system ;-)
> 
> The port doesn't consider installed CM3.  It has to do with how ports
> are now built in "clean" jails where nothing is installed.
> 
> You *could* package your working CM3 as a bootstrap compiler [1] but I
> would think your time would be better spent with FreeBSD Update:
> https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
> 
> John
> 
> 
> [1] Just look in work/bootstrap and emulate if you want to do this.

If I understand the makefile correctly, I should use the bootstrap
modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz, but I cannot find that:

% wget --no-check-certificate http://downloads.dragonlace.net/m3/modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz
--2015-05-29 17:04:08--  http://downloads.dragonlace.net/m3/modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz
Resolving downloads.dragonlace.net... 208.69.230.148
Connecting to downloads.dragonlace.net|208.69.230.148|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-05-29 17:04:08 ERROR 404: Not Found.

I can download the other bootstrap file, but that would be for
Dragonfly, not for FreeBSD, correct?
Some stupid mistake?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150702/667cf61e/attachment-0001.sig>

From wagner at elegosoft.com  Thu Jul  2 17:40:07 2015
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 02 Jul 2015 15:40:07 -0000
Subject: [M3devel] Thread tests, was: Re:  the need for cooperative suspend
In-Reply-To: <20150606165023.78AEC1A2066@async.async.caltech.edu>
References: <COL130-W74C829AA2D11E60BB5A735E6D40@phx.gbl>
 <20150502155713.29DCC1A2062@async.async.caltech.edu>
 <B843CEEA-CE8E-4E35-A2EA-ECCC795E3BA2@purdue.edu>
 <20150606165023.78AEC1A2066@async.async.caltech.edu>
Message-ID: <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>

On Sat, 06 Jun 2015 09:50:23 -0700
mika at async.caltech.edu wrote:

> Can the thread tester survive with the most paranoid options on OS X?
> I don't believe it until I've seen it (based on what we went through for
> Linux, I would say I'm just being prudent).
> 
> Run it with:
> 
> "-iters 100000 -n 20 -tests ALL"
> 
> I remember the thread tester died on FreeBSD last time I tried, and
> there have been no relevant checkins since that I know of.
> 
> Here's what happens when I run it on my FreeBSD.  CM3 is not up to date,
> in case someone fixed something I'm not aware of, so don't draw too
> many conclusions until someone has tried it on a fresh install:
> 
> ..........laziest thread is 1433608799/9/1 (tests: read 10/6/6 nxread 26/6/4 tryexcept 67/53/38 fork 1433608799/2/2 forktoomuch 1433608799/9/3 alloc 1433608799/37/1 creat 10/7/7 lock 1433608799/68/38)
> 
> 
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
> ***
> 
> Abort
> (79)pluto:/tmp>
> 
> Anyone who's interested in trying their own favorite Modula-3 installation,
> this is easy to do:
> 
> cm3/m3-libs/m3core/tests/thread/AMD64_FREEBSD/threadtest -iters 100000 -n 20 -tests ALL

For those interested:

I have run the tests with the options above on my FreeBSD 8 system
(yes, I know, that's unsupported now ;-).

time ./AMD64_FREEBSD/threadtest  -iters 100000 -n 20 -tests ALL 2>&1 | egrep -v "appears starved or deadlocked" | tee threadtest.log

It ran several hours during the night; system load was nearly 20.
top -H showed all the threads. The log does not show any runtime error 
(attached).

I also tried this on my Mac with OS/X 10.9.5, but I had to kill it
after an hour because it used up all the resources and I had to work.
Less aggressive tests didn't show any failure there, too.

So I guess the pthreads runtime has indeed improved.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threadtest.log
Type: application/octet-stream
Size: 106496 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150702/b3ed946e/attachment-0001.obj>

From mika at async.caltech.edu  Thu Jul  2 19:35:49 2015
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Thu, 02 Jul 2015 10:35:49 -0700
Subject: [M3devel] Thread tests,
	was: Re:  the need for cooperative suspend
In-Reply-To: <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>
References: <COL130-W74C829AA2D11E60BB5A735E6D40@phx.gbl>
 <20150502155713.29DCC1A2062@async.async.caltech.edu>
 <B843CEEA-CE8E-4E35-A2EA-ECCC795E3BA2@purdue.edu>
 <20150606165023.78AEC1A2066@async.async.caltech.edu>
 <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>
Message-ID: <20150702173549.ADF471A206A@async.async.caltech.edu>


Great news!!!

If anyone finds problems in pthreads on a system where the thread tester
works I would be very interested, first of course because of the bad
news that the system is broken but secondly because I would also want
to enhance the tester so that the bugs don't get by it.

I think if pthreads works well in CM3, that's a big step forward in
the range of applications the system can be used for.

    Mika

Olaf Wagner writes:
>This is a multi-part message in MIME format.
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: 8bit
>
>On Sat, 06 Jun 2015 09:50:23 -0700
>mika at async.caltech.edu wrote:
>
>> Can the thread tester survive with the most paranoid options on OS X?
>> I don't believe it until I've seen it (based on what we went through for
>> Linux, I would say I'm just being prudent).
>> 
>> Run it with:
>> 
>> "-iters 100000 -n 20 -tests ALL"
>> 
>> I remember the thread tester died on FreeBSD last time I tried, and
>> there have been no relevant checkins since that I know of.
>> 
>> Here's what happens when I run it on my FreeBSD.  CM3 is not up to date,
>> in case someone fixed something I'm not aware of, so don't draw too
>> many conclusions until someone has tried it on a fresh install:
>> 
>> ..........laziest thread is 1433608799/9/1 (tests: read 10/6/6 nxread 26/6/4 tryexcept 67/53/38 fork 1433608799/2/2
> forktoomuch 1433608799/9/3 alloc 1433608799/37/1 creat 10/7/7 lock 1433608799/68/38)
>> 
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>> 
>> Abort
>> (79)pluto:/tmp>
>> 
>> Anyone who's interested in trying their own favorite Modula-3 installation,
>> this is easy to do:
>> 
>> cm3/m3-libs/m3core/tests/thread/AMD64_FREEBSD/threadtest -iters 100000 -n 20 -tests ALL
>
>For those interested:
>
>I have run the tests with the options above on my FreeBSD 8 system
>(yes, I know, that's unsupported now ;-).
>
>time ./AMD64_FREEBSD/threadtest  -iters 100000 -n 20 -tests ALL 2>&1 | egrep -v "appears starved or deadlocked" | tee
> threadtest.log
>
>It ran several hours during the night; system load was nearly 20.
>top -H showed all the threads. The log does not show any runtime error 
>(attached).
>
>I also tried this on my Mac with OS/X 10.9.5, but I had to kill it
>after an hour because it used up all the resources and I had to work.
>Less aggressive tests didn't show any failure there, too.
>
>So I guess the pthreads runtime has indeed improved.
>
>Olaf
>-- 
>Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
>               Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany
>phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin
>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn
>Content-Type: application/octet-stream;
> name="threadtest.log"
>Content-Disposition: attachment;
> filename="threadtest.log"
>Content-Transfer-Encoding: base64
>
>V3JpdGluZyBmaWxlLi4uZG9uZQpDcmVhdGluZyByZWFkIHRocmVhZHMuLi5kb25lCkNyZWF0aW5n
>IG54cmVhZCB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyB0cnlleGNlcHQgdGhyZWFkcy4uLmRvbmUK
>Q3JlYXRpbmcgZm9yayB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyBmb3JrdG9vbXVjaCB0aHJlYWRz
>Li4uZG9uZQpDcmVhdGluZyBhbGxvYyB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyBjcmVhdCB0aHJl
>YWRzLi4uZG9uZQpDcmVhdGluZyBsb2NrIHRocmVhZHMuLi5kb25lCnJ1bm5pbmcuLi5wcmludGlu
>ZyBvbGRlc3QvbWVkaWFuIGFnZS9uZXdlc3QKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTAyMTQvMTQzMzcxMDIxNC8wICh0ZXN0czogcmVhZCAxNDMzNzEwMjE0LzE0MzM3MTAyMTQv
>MTQzMzcxMDIxNCBueHJlYWQgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgdHJ5ZXhj
>ZXB0IDEvMC8wIGZvcmsgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgZm9ya3Rvb211
>Y2ggMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgYWxsb2MgMTQzMzcxMDIxNC8xNDMz
>NzEwMjE0LzE0MzM3MTAyMTQgY3JlYXQgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQg
>bG9jayAxNDMzNzEwMjE0LzE0MzM3MTAyMTQvMTQzMzcxMDIxNCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEwMjg2
>LzE0MzM3MTAyODYvMTYgbnhyZWFkIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IHRy
>eWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGZvcmt0
>b29tdWNoIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGFsbG9jIDE0MzM3MTAyODYv
>Ny8xIGNyZWF0IDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGxvY2sgMTQzMzcxMDI4
>Ni8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwMzEyLzE0MzM3MTAzMTIv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMDMxMi8xNDMzNzEwMzEyLzEzIG54cmVhZCAxNDMzNzEwMzEy
>LzE0MzM3MTAzMTIvMTQzMzcxMDMxMiB0cnlleGNlcHQgMTMvMS8xIGZvcmsgMTQzMzcxMDMxMi8x
>NDMzNzEwMzEyLzE0MzM3MTAzMTIgZm9ya3Rvb211Y2ggMTQzMzcxMDMxMi8xNDMzNzEwMzEyLzE0
>MzM3MTAzMTIgYWxsb2MgMzMvMTIvNSBjcmVhdCAxNDMzNzEwMzEyLzE0MzM3MTAzMTIvMTQzMzcx
>MDMxMiBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMDM1Ny8x
>NDMzNzEwMzU3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTAzNTcvMTQzMzcxMDM1Ny8xIG54cmVhZCAx
>NDMzNzEwMzU3LzE0MzM3MTAzNTcvMTQzMzcxMDM1NyB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMz
>NzEwMzU3LzE0MzM3MTAzNTcvMTQzMzcxMDM1NyBmb3JrdG9vbXVjaCAxNDMzNzEwMzU3LzE0MzM3
>MTAzNTcvMTQzMzcxMDM1NyBhbGxvYyA1Ny8xOS8xIGNyZWF0IDE0MzM3MTAzNTcvMTQzMzcxMDM1
>Ny8xNDMzNzEwMzU3IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzEwMzgwLzE0MzM3MTAzODAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMDM4MC8xNDMzNzEwMzgwLzEg
>bnhyZWFkIDE0MzM3MTAzODAvMTQzMzcxMDM4MC8xNDMzNzEwMzgwIHRyeWV4Y2VwdCAyNi84LzAg
>Zm9yayAxNDMzNzEwMzgwLzE0MzM3MTAzODAvMTQzMzcxMDM4MCBmb3JrdG9vbXVjaCAxNDMzNzEw
>MzgwLzE0MzM3MTAzODAvMTQzMzcxMDM4MCBhbGxvYyA4MC85LzEgY3JlYXQgMTQzMzcxMDM4MC8x
>NDMzNzEwMzgwLzE0MzM3MTAzODAgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MTA0MTQvMTQzMzcxMDQxNC8wICh0ZXN0czogcmVhZCAxNDMzNzEwNDE0LzE0MzM3
>MTA0MTQvMjEgbnhyZWFkIDE0MzM3MTA0MTQvMTQzMzcxMDQxNC8xNDMzNzEwNDE0IHRyeWV4Y2Vw
>dCAxNi8yLzEgZm9yayAxNDMzNzEwNDE0LzE0MzM3MTA0MTQvMTQzMzcxMDQxNCBmb3JrdG9vbXVj
>aCAxNDMzNzEwNDE0LzE0MzM3MTA0MTQvMTQzMzcxMDQxNCBhbGxvYyAzOC80LzQgY3JlYXQgMTQz
>MzcxMDQxNC8xNDMzNzEwNDE0LzE0MzM3MTA0MTQgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEw
>NDQyLzE0MzM3MTA0NDIvMjIgbnhyZWFkIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQy
>IHRyeWV4Y2VwdCA1LzIvMSBmb3JrIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyIGZv
>cmt0b29tdWNoIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyIGFsbG9jIDMyLzE1LzYg
>Y3JlYXQgMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyLzE0MzM3MTA0NDIgbG9jayA2LzYvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA0NzkvMTQzMzcxMDQ3OS8wICh0ZXN0czogcmVh
>ZCAxNDMzNzEwNDc5LzE0MzM3MTA0NzkvNSBueHJlYWQgMTQzMzcxMDQ3OS8xNDMzNzEwNDc5LzE5
>IHRyeWV4Y2VwdCA1LzIvMSBmb3JrIDE0MzM3MTA0NzkvMTQzMzcxMDQ3OS8xOCBmb3JrdG9vbXVj
>aCAxNDMzNzEwNDc5LzE0MzM3MTA0NzkvMTQzMzcxMDQ3OSBhbGxvYyAzNy84LzUgY3JlYXQgMTQz
>MzcxMDQ3OS8xNDMzNzEwNDc5LzE0MzM3MTA0NzkgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTA1MDQvMTQzMzcxMDUwNC8wICh0ZXN0czogcmVhZCAxNDMzNzEw
>NTA0LzE0MzM3MTA1MDQvMzAgbnhyZWFkIDE0MzM3MTA1MDQvMTQzMzcxMDUwNC80NCB0cnlleGNl
>cHQgNC8xLzAgZm9yayAxNDMzNzEwNTA0LzE0MzM3MTA1MDQvNDMgZm9ya3Rvb211Y2ggMTQzMzcx
>MDUwNC8xNDMzNzEwNTA0LzE0MzM3MTA1MDQgYWxsb2MgNTcvOC8yIGNyZWF0IDE0MzM3MTA1MDQv
>MTQzMzcxMDUwNC8xNDMzNzEwNTA0IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzEwNTQ1LzE0MzM3MTA1NDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMDU0NS8xNDMz
>NzEwNTQ1LzcxIG54cmVhZCAxNDMzNzEwNTQ1LzE0MzM3MTA1NDUvODUgdHJ5ZXhjZXB0IDQvMC8w
>IGZvcmsgMTQzMzcxMDU0NS8xNDMzNzEwNTQ1Lzg0IGZvcmt0b29tdWNoIDE0MzM3MTA1NDUvMTQz
>MzcxMDU0NS8xNDMzNzEwNTQ1IGFsbG9jIDQ5LzgvMyBjcmVhdCAxNDMzNzEwNTQ1LzE0MzM3MTA1
>NDUvMTQzMzcxMDU0NSBsb2NrIDIvMi8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMDU3Mi8xNDMzNzEwNTcyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA1NzIvMTQzMzcxMDU3Mi85
>OCBueHJlYWQgMTQzMzcxMDU3Mi8xNDMzNzEwNTcyLzExMiB0cnlleGNlcHQgOC8zLzAgZm9yayAx
>NDMzNzEwNTcyLzE0MzM3MTA1NzIvMTExIGZvcmt0b29tdWNoIDE0MzM3MTA1NzIvMTQzMzcxMDU3
>Mi8xNDMzNzEwNTcyIGFsbG9jIDQxLzE1LzEgY3JlYXQgMTQzMzcxMDU3Mi8xNDMzNzEwNTcyLzE0
>MzM3MTA1NzIgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA1
>OTkvMTQzMzcxMDU5OS8wICh0ZXN0czogcmVhZCAxNDMzNzEwNTk5LzE0MzM3MTA1OTkvMTMgbnhy
>ZWFkIDE0MzM3MTA1OTkvMTQzMzcxMDU5OS8xMzkgdHJ5ZXhjZXB0IDM1LzEvMSBmb3JrIDE0MzM3
>MTA1OTkvMTQzMzcxMDU5OS8xMzggZm9ya3Rvb211Y2ggMTQzMzcxMDU5OS8xNDMzNzEwNTk5LzE0
>MzM3MTA1OTkgYWxsb2MgNTIvMTMvNCBjcmVhdCAxNDMzNzEwNTk5LzE0MzM3MTA1OTkvMTQzMzcx
>MDU5OSBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMDYzMC8x
>NDMzNzEwNjMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA2MzAvMTQzMzcxMDYzMC8xMiBueHJlYWQg
>MTQzMzcxMDYzMC8xNDMzNzEwNjMwLzE3MCB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzEwNjMw
>LzE0MzM3MTA2MzAvMTY5IGZvcmt0b29tdWNoIDE0MzM3MTA2MzAvMTQzMzcxMDYzMC8xNDMzNzEw
>NjMwIGFsbG9jIDMxLzEyLzUgY3JlYXQgMTQzMzcxMDYzMC8xNDMzNzEwNjMwLzE0MzM3MTA2MzAg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA2NTkvMTQzMzcx
>MDY1OS8wICh0ZXN0czogcmVhZCAxNDMzNzEwNjU5LzE0MzM3MTA2NTkvNiBueHJlYWQgMTQzMzcx
>MDY1OS8xNDMzNzEwNjU5LzE5OSB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzEwNjU5LzE0MzM3
>MTA2NTkvNiBmb3JrdG9vbXVjaCAxNDMzNzEwNjU5LzE0MzM3MTA2NTkvMTQzMzcxMDY1OSBhbGxv
>YyAzNC8xMS82IGNyZWF0IDE0MzM3MTA2NTkvMTQzMzcxMDY1OS8xNDMzNzEwNjU5IGxvY2sgNC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwNjc4LzIxNy8wICh0ZXN0czog
>cmVhZCAxNDMzNzEwNjc4LzE0MzM3MTA2NzgvMjUgbnhyZWFkIDE0MzM3MTA2NzgvMTQzMzcxMDY3
>OC8yMTggdHJ5ZXhjZXB0IDE1LzMvMCBmb3JrIDE0MzM3MTA2NzgvMTQzMzcxMDY3OC8yNSBmb3Jr
>dG9vbXVjaCAxNDMzNzEwNjc4LzE0MzM3MTA2NzgvMTQzMzcxMDY3OCBhbGxvYyAzMC81LzEgY3Jl
>YXQgMTQzMzcxMDY3OC8xLzEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTA3MjIvMjYxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA3MjIvMTQzMzcxMDcyMi81IG54
>cmVhZCAxNDMzNzEwNzIyLzE0MzM3MTA3MjIvMjYyIHRyeWV4Y2VwdCAxOS8yLzAgZm9yayAxNDMz
>NzEwNzIyLzE0MzM3MTA3MjIvMTcgZm9ya3Rvb211Y2ggMTQzMzcxMDcyMi8xNDMzNzEwNzIyLzE0
>MzM3MTA3MjIgYWxsb2MgNDkvMS8xIGNyZWF0IDE0MzM3MTA3MjIvNDUvNDUgbG9jayAxLzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA3NjcvMzA2LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MTA3NjcvMTQzMzcxMDc2Ny81MCBueHJlYWQgMTQzMzcxMDc2Ny8xNDMzNzEwNzY3LzMw
>NyB0cnlleGNlcHQgMTUvMi8xIGZvcmsgMTQzMzcxMDc2Ny8xNDMzNzEwNzY3LzYyIGZvcmt0b29t
>dWNoIDE0MzM3MTA3NjcvMTQzMzcxMDc2Ny8xNDMzNzEwNzY3IGFsbG9jIDU2LzgvMyBjcmVhdCAx
>NDMzNzEwNzY3LzkwLzkwIGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEwNzk5LzE0Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEwNzk5LzE0MzM3MTA3OTkvMTUgbnhy
>ZWFkIDE0MzM3MTA3OTkvMTQzMzcxMDc5OS8zMzkgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQzMzcx
>MDc5OS8xNDMzNzEwNzk5LzE5IGZvcmt0b29tdWNoIDE0MzM3MTA3OTkvMTQzMzcxMDc5OS8xNDMz
>NzEwNzk5IGFsbG9jIDEwLzYvNiBjcmVhdCAxNDMzNzEwNzk5LzEyMi8xMjIgbG9jayAwLzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA4MjEvMTY4LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MTA4MjEvMTQzMzcxMDgyMS8zNyBueHJlYWQgMTQzMzcxMDgyMS8xNDMzNzEwODIxLzM2
>MSB0cnlleGNlcHQgMTYvMi8xIGZvcmsgMTQzMzcxMDgyMS8xNDMzNzEwODIxLzQxIGZvcmt0b29t
>dWNoIDE0MzM3MTA4MjEvMTQzMzcxMDgyMS8xNDMzNzEwODIxIGFsbG9jIDMyLzE0LzAgY3JlYXQg
>MTQzMzcxMDgyMS8xNDQvMTQ0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzEwODU5LzIwNi8wICh0ZXN0czogcmVhZCAxNDMzNzEwODU5LzE0MzM3MTA4NTkvMjgg
>bnhyZWFkIDE0MzM3MTA4NTkvMTQzMzcxMDg1OS8zOTkgdHJ5ZXhjZXB0IDM2LzMvMCBmb3JrIDE0
>MzM3MTA4NTkvMTQzMzcxMDg1OS83OSBmb3JrdG9vbXVjaCAxNDMzNzEwODU5LzE0MzM3MTA4NTkv
>MTQzMzcxMDg1OSBhbGxvYyA1Mi84LzIgY3JlYXQgMTQzMzcxMDg1OS8xODIvMTgyIGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwODg0LzIzMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEwODg0LzE0MzM3MTA4ODQvMjIgbnhyZWFkIDE0MzM3MTA4ODQvMTQzMzcxMDg4
>NC80MjQgdHJ5ZXhjZXB0IDQ0LzIvMCBmb3JrIDE0MzM3MTA4ODQvMTQzMzcxMDg4NC8xMDQgZm9y
>a3Rvb211Y2ggMTQzMzcxMDg4NC8xNDMzNzEwODg0LzE0MzM3MTA4ODQgYWxsb2MgNzcvMTcvMSBj
>cmVhdCAxNDMzNzEwODg0LzIwNy8yMDcgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTA5MDcvMjU0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTA5MDcvMTQzMzcxMDkw
>Ny8xOSBueHJlYWQgMTQzMzcxMDkwNy8xNDMzNzEwOTA3LzQ0NyB0cnlleGNlcHQgNjcvMS8wIGZv
>cmsgMTQzMzcxMDkwNy8xNDMzNzEwOTA3LzEyNyBmb3JrdG9vbXVjaCAxNDMzNzEwOTA3LzE0MzM3
>MTA5MDcvMTQzMzcxMDkwNyBhbGxvYyAxMDAvMjQvMiBjcmVhdCAxNDMzNzEwOTA3LzIzMC8yMzAg
>bG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA5NzYvMjk5LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTA5NzYvMTQzMzcxMDk3Ni85IG54cmVhZCAxNDMzNzEwOTc2LzE0
>MzM3MTA5NzYvNTE2IHRyeWV4Y2VwdCA0My8yLzEgZm9yayAxNDMzNzEwOTc2LzE0MzM3MTA5NzYv
>MTk2IGZvcmt0b29tdWNoIDE0MzM3MTA5NzYvMTQzMzcxMDk3Ni8xNDMzNzEwOTc2IGFsbG9jIDgz
>LzQvMCBjcmVhdCAyOTkvMjk5LzI3IGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzEwOTk5LzMyMi8wICh0ZXN0czogcmVhZCAxNDMzNzEwOTk5LzE0MzM3MTA5OTkv
>MiBueHJlYWQgMTQzMzcxMDk5OS8xNDMzNzEwOTk5LzUzOSB0cnlleGNlcHQgMy8wLzAgZm9yayAx
>NDMzNzEwOTk5LzE0MzM3MTA5OTkvMTIgZm9ya3Rvb211Y2ggMTQzMzcxMDk5OS8xNDMzNzEwOTk5
>LzE0MzM3MTA5OTkgYWxsb2MgMjcvNy8yIGNyZWF0IDMyMi8zMjIvNTAgbG9jayAxLzEvMSkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTEwNDQvMzY3LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTEwNDQvMTQzMzcxMTA0NC8xIG54cmVhZCAxNDMzNzExMDQ0LzE0MzM3MTEwNDQvNTg0IHRy
>eWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTEwNDQvMTQzMzcxMTA0NC81NyBmb3JrdG9vbXVjaCAx
>NDMzNzExMDQ0LzE0MzM3MTEwNDQvMTQzMzcxMTA0NCBhbGxvYyA1OC83LzEgY3JlYXQgMzY3LzM2
>Ny85NSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTA3OS80
>MDIvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTA3OS8xNDMzNzExMDc5LzIyIG54cmVhZCAxNDMzNzEx
>MDc5LzE0MzM3MTEwNzkvNjE5IHRyeWV4Y2VwdCA5LzIvMiBmb3JrIDE0MzM3MTEwNzkvMTQzMzcx
>MTA3OS85MiBmb3JrdG9vbXVjaCAxNDMzNzExMDc5LzE0MzM3MTEwNzkvMTQzMzcxMTA3OSBhbGxv
>YyAzMS8xMC84IGNyZWF0IDQwMi80MDIvMTMwIGxvY2sgNy82LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzExMTEzLzQzNi8wICh0ZXN0czogcmVhZCAxNDMzNzExMTEzLzE0MzM3
>MTExMTMvMjUgbnhyZWFkIDE0MzM3MTExMTMvMTQzMzcxMTExMy82NTMgdHJ5ZXhjZXB0IDQvMy8w
>IGZvcmsgMTQzMzcxMTExMy8xNDMzNzExMTEzLzEyNiBmb3JrdG9vbXVjaCAxNDMzNzExMTEzLzE0
>MzM3MTExMTMvMTQzMzcxMTExMyBhbGxvYyA0NC8xMS8xIGNyZWF0IDQzNi80MzYvMTY0IGxvY2sg
>MS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExMTUzLzQyLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTExNTMvMTQzMzcxMTE1My8xMCBueHJlYWQgMTQzMzcxMTE1My8xNDMzNzEx
>MTUzLzY5MyB0cnlleGNlcHQgNDIvMi8xIGZvcmsgMTQzMzcxMTE1My8xNDMzNzExMTUzLzE2NiBm
>b3JrdG9vbXVjaCAxNDMzNzExMTUzLzE0MzM3MTExNTMvMTQzMzcxMTE1MyBhbGxvYyA1MS8xOC80
>IGNyZWF0IDIwNC8xMC8xMCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxMTE4Ny80NC8wICh0ZXN0czogcmVhZCAxNDMzNzExMTg3LzE0MzM3MTExODcvMTYgbnhy
>ZWFkIDE0MzM3MTExODcvMTQzMzcxMTE4Ny83MjcgdHJ5ZXhjZXB0IDE3LzAvMCBmb3JrIDE0MzM3
>MTExODcvMTQzMzcxMTE4Ny8yMDAgZm9ya3Rvb211Y2ggMTQzMzcxMTE4Ny8xNDMzNzExMTg3LzE0
>MzM3MTExODcgYWxsb2MgMzQvNS8zIGNyZWF0IDIzOC80NC80NCBsb2NrIDEvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTIyOS84Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEx
>MjI5LzE0MzM3MTEyMjkvNTggbnhyZWFkIDE0MzM3MTEyMjkvMTQzMzcxMTIyOS83NjkgdHJ5ZXhj
>ZXB0IDUvMi8xIGZvcmsgMTQzMzcxMTIyOS8xNDMzNzExMjI5LzI0MiBmb3JrdG9vbXVjaCAxNDMz
>NzExMjI5LzE0MzM3MTEyMjkvMTQzMzcxMTIyOSBhbGxvYyAyMS8xMS81IGNyZWF0IDI4MC84Ni84
>NiBsb2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTI1NS8xMTIv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMTI1NS8xNDMzNzExMjU1LzIxIG54cmVhZCAxNDMzNzExMjU1
>LzE0MzM3MTEyNTUvNzk1IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTEyNTUvMTQzMzcxMTI1
>NS8yMCBmb3JrdG9vbXVjaCAxNDMzNzExMjU1LzE0MzM3MTEyNTUvMTQzMzcxMTI1NSBhbGxvYyAz
>MS81LzEgY3JlYXQgMzA2LzExMi8xMTIgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTEyODEvMTM4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTEyODEvMTQzMzcxMTI4
>MS80NyBueHJlYWQgMTQzMzcxMTI4MS8xNDMzNzExMjgxLzgyMSB0cnlleGNlcHQgMTcvMy8xIGZv
>cmsgMTQzMzcxMTI4MS8xNDMzNzExMjgxLzQ2IGZvcmt0b29tdWNoIDE0MzM3MTEyODEvMTQzMzcx
>MTI4MS8xNDMzNzExMjgxIGFsbG9jIDMxLzcvMyBjcmVhdCAzMzIvMTM4LzEzOCBsb2NrIDMvMy8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTMxMC8xNjcvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMTMxMC8xNDMzNzExMzEwLzE2IG54cmVhZCAxNDMzNzExMzEwLzE0MzM3MTEzMTAv
>ODUwIHRyeWV4Y2VwdCAxMS8yLzEgZm9yayAxNDMzNzExMzEwLzE0MzM3MTEzMTAvNzUgZm9ya3Rv
>b211Y2ggMTQzMzcxMTMxMC8xNDMzNzExMzEwLzE0MzM3MTEzMTAgYWxsb2MgMzkvMTAvMyBjcmVh
>dCAzNjEvMTY3LzE2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMTM0MS8xOTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTM0MS8xNDMzNzExMzQxLzI2IG54cmVh
>ZCAxNDMzNzExMzQxLzE0MzM3MTEzNDEvODgxIHRyeWV4Y2VwdCAxNS8yLzIgZm9yayAxNDMzNzEx
>MzQxLzE0MzM3MTEzNDEvMTA2IGZvcmt0b29tdWNoIDE0MzM3MTEzNDEvMTQzMzcxMTM0MS8xNDMz
>NzExMzQxIGFsbG9jIDQxLzE0LzYgY3JlYXQgMzkyLzE5OC8xOTggbG9jayA1LzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTEzNjgvMjI1LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTEzNjgvMTQzMzcxMTM2OC81MyBueHJlYWQgMTQzMzcxMTM2OC8xNDMzNzExMzY4LzkwOCB0cnll
>eGNlcHQgNC8zLzAgZm9yayAxNDMzNzExMzY4LzE0MzM3MTEzNjgvMTMzIGZvcmt0b29tdWNoIDE0
>MzM3MTEzNjgvMTQzMzcxMTM2OC8xNDMzNzExMzY4IGFsbG9jIDQ3LzcvMSBjcmVhdCA0MTkvMjI1
>LzIyNSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTM5My8y
>NTAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTM5My8xNDMzNzExMzkzLzE0IG54cmVhZCAxNDMzNzEx
>MzkzLzE0MzM3MTEzOTMvOTMzIHRyeWV4Y2VwdCA4LzEvMSBmb3JrIDE0MzM3MTEzOTMvMTQzMzcx
>MTM5My8xNTggZm9ya3Rvb211Y2ggMTQzMzcxMTM5My8xNDMzNzExMzkzLzE0MzM3MTEzOTMgYWxs
>b2MgMzIvMTQvNyBjcmVhdCA0NDQvMjUwLzI1MCBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTQyMC8yNzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTQyMC8xNDMz
>NzExNDIwLzYgbnhyZWFkIDE0MzM3MTE0MjAvMTQzMzcxMTQyMC85NjAgdHJ5ZXhjZXB0IDUvMi8x
>IGZvcmsgMTQzMzcxMTQyMC8xNDMzNzExNDIwLzE4NSBmb3JrdG9vbXVjaCAxNDMzNzExNDIwLzE0
>MzM3MTE0MjAvMTQzMzcxMTQyMCBhbGxvYyAyNy8xNy82IGNyZWF0IDQ3MS8yNzcvMjc3IGxvY2sg
>Ni82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNDQ3LzMwNC8wICh0ZXN0
>czogcmVhZCAxNDMzNzExNDQ3LzE0MzM3MTE0NDcvMjAgbnhyZWFkIDE0MzM3MTE0NDcvMTQzMzcx
>MTQ0Ny85ODcgdHJ5ZXhjZXB0IDgvMi8yIGZvcmsgMTQzMzcxMTQ0Ny8xNDMzNzExNDQ3LzE5IGZv
>cmt0b29tdWNoIDE0MzM3MTE0NDcvMTQzMzcxMTQ0Ny8xNDMzNzExNDQ3IGFsbG9jIDQ0LzExLzcg
>Y3JlYXQgNDk4LzMwNC8zMDQgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTE0NzIvMzI5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTE0NzIvMTQzMzcxMTQ3Mi82IG54
>cmVhZCAxNDMzNzExNDcyLzE0MzM3MTE0NzIvMTAxMiB0cnlleGNlcHQgNS8yLzIgZm9yayAxNDMz
>NzExNDcyLzE0MzM3MTE0NzIvNDQgZm9ya3Rvb211Y2ggMTQzMzcxMTQ3Mi8xNDMzNzExNDcyLzE0
>MzM3MTE0NzIgYWxsb2MgNDEvMTEvMCBjcmVhdCA1MjMvMzI5LzMyOSBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTUwMi8zNTkvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMTUwMi8xNDMzNzExNTAyLzIgbnhyZWFkIDE0MzM3MTE1MDIvMTQzMzcxMTUwMi8xMDQyIHRy
>eWV4Y2VwdCAyNC8xLzAgZm9yayAxNDMzNzExNTAyLzE0MzM3MTE1MDIvNzQgZm9ya3Rvb211Y2gg
>MTQzMzcxMTUwMi8xNDMzNzExNTAyLzE0MzM3MTE1MDIgYWxsb2MgNzEvNS8yIGNyZWF0IDU1My8z
>NTkvMzU5IGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNTI3
>LzM4NC8wICh0ZXN0czogcmVhZCAxNDMzNzExNTI3LzE0MzM3MTE1MjcvOCBueHJlYWQgMTQzMzcx
>MTUyNy8xNDMzNzExNTI3LzEwNjcgdHJ5ZXhjZXB0IDE4LzIvMCBmb3JrIDE0MzM3MTE1MjcvMTQz
>MzcxMTUyNy83IGZvcmt0b29tdWNoIDE0MzM3MTE1MjcvMTQzMzcxMTUyNy8xNDMzNzExNTI3IGFs
>bG9jIDM1LzgvMSBjcmVhdCA1NzgvMzg0LzM4NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTU1OC80MTUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTU1OC8xNDMz
>NzExNTU4LzcgbnhyZWFkIDE0MzM3MTE1NTgvMTQzMzcxMTU1OC8xMDk4IHRyeWV4Y2VwdCAyNS8y
>LzIgZm9yayAxNDMzNzExNTU4LzE0MzM3MTE1NTgvNyBmb3JrdG9vbXVjaCAxNDMzNzExNTU4LzE0
>MzM3MTE1NTgvMTQzMzcxMTU1OCBhbGxvYyAzOS8xMS83IGNyZWF0IDYwOS80MTUvNDE1IGxvY2sg
>Ny83LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNTgxLzQzOC8wICh0ZXN0
>czogcmVhZCAxNDMzNzExNTgxLzE0MzM3MTE1ODEvMzAgbnhyZWFkIDE0MzM3MTE1ODEvMTQzMzcx
>MTU4MS8xMTIxIHRyeWV4Y2VwdCA0LzMvMCBmb3JrIDE0MzM3MTE1ODEvMTQzMzcxMTU4MS8zMCBm
>b3JrdG9vbXVjaCAxNDMzNzExNTgxLzE0MzM3MTE1ODEvMTQzMzcxMTU4MSBhbGxvYyAzNC8xLzEg
>Y3JlYXQgNjMyLzQzOC80MzggbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTE2MDUvNDYyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE2MDUvMTQzMzcxMTYwNS8yIG54
>cmVhZCAxNDMzNzExNjA1LzE0MzM3MTE2MDUvMTE0NSB0cnlleGNlcHQgNC8wLzAgZm9yayAxNDMz
>NzExNjA1LzE0MzM3MTE2MDUvMiBmb3JrdG9vbXVjaCAxNDMzNzExNjA1LzE0MzM3MTE2MDUvMTQz
>MzcxMTYwNSBhbGxvYyAzMS8yLzIgY3JlYXQgNjU2LzQ2Mi80NjIgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTE2NDAvNDk3LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTE2NDAvMTQzMzcxMTY0MC81IG54cmVhZCAxNDMzNzExNjQwLzE0MzM3MTE2NDAvMTE4MCB0cnll
>eGNlcHQgNC8xLzEgZm9yayAxNDMzNzExNjQwLzE0MzM3MTE2NDAvMzcgZm9ya3Rvb211Y2ggMTQz
>MzcxMTY0MC8xNDMzNzExNjQwLzE0MzM3MTE2NDAgYWxsb2MgNDMvMTEvNSBjcmVhdCA2OTEvNDk3
>LzQ5NyBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTY3Mi81
>MjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTY3Mi8xNDMzNzExNjcyLzE2IG54cmVhZCAxNDMzNzEx
>NjcyLzE0MzM3MTE2NzIvMTIxMiB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzExNjcyLzE0MzM3
>MTE2NzIvNjkgZm9ya3Rvb211Y2ggMTQzMzcxMTY3Mi8xNDMzNzExNjcyLzE0MzM3MTE2NzIgYWxs
>b2MgMjIvMTEvMCBjcmVhdCA3MjMvNTI5LzUyOSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTcxMy81NzAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTcxMy8xNDMz
>NzExNzEzLzIwIG54cmVhZCAxNDMzNzExNzEzLzE0MzM3MTE3MTMvMTI1MyB0cnlleGNlcHQgNC8y
>LzEgZm9yayAxNDMzNzExNzEzLzE0MzM3MTE3MTMvMTEwIGZvcmt0b29tdWNoIDE0MzM3MTE3MTMv
>MTQzMzcxMTcxMy8xNDMzNzExNzEzIGFsbG9jIDUyLzUvNSBjcmVhdCA3NjQvNTcwLzU3MCBsb2Nr
>IDUvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTc0Ni82MDMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxMTc0Ni8xNDMzNzExNzQ2LzUzIG54cmVhZCAxNDMzNzExNzQ2LzE0MzM3
>MTE3NDYvMTI4NiB0cnlleGNlcHQgMjAvMi8xIGZvcmsgMTQzMzcxMTc0Ni8xNDMzNzExNzQ2LzE0
>MyBmb3JrdG9vbXVjaCAxNDMzNzExNzQ2LzE0MzM3MTE3NDYvMTQzMzcxMTc0NiBhbGxvYyAzMy81
>LzIgY3JlYXQgNzk3LzYwMy82MDMgbG9jayAyLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MTE3NzMvNjMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE3NzMvMTQzMzcxMTc3My8x
>OCBueHJlYWQgMTQzMzcxMTc3My8xNDMzNzExNzczLzEzMTMgdHJ5ZXhjZXB0IDI4LzAvMCBmb3Jr
>IDE0MzM3MTE3NzMvMTQzMzcxMTc3My8xNzAgZm9ya3Rvb211Y2ggMTQzMzcxMTc3My8xNDMzNzEx
>NzczLzE0MzM3MTE3NzMgYWxsb2MgMzIvMTgvMiBjcmVhdCA4MjQvNjMwLzYzMCBsb2NrIDIvMi8x
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTc5Ny82NTQvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMTc5Ny8xNDMzNzExNzk3LzggbnhyZWFkIDE0MzM3MTE3OTcvMTQzMzcxMTc5Ny8x
>MzM3IHRyeWV4Y2VwdCA0MC8yLzEgZm9yayAxNDMzNzExNzk3LzE0MzM3MTE3OTcvMTk0IGZvcmt0
>b29tdWNoIDE0MzM3MTE3OTcvMTQzMzcxMTc5Ny8xNDMzNzExNzk3IGFsbG9jIDQ2LzE3LzMgY3Jl
>YXQgODQ4LzY1NC82NTQgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTE4MzQvNjkxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE4MzQvMTQzMzcxMTgzNC8xMiBueHJl
>YWQgMTQzMzcxMTgzNC8xNDMzNzExODM0LzEzNzQgdHJ5ZXhjZXB0IDMxLzIvMCBmb3JrIDE0MzM3
>MTE4MzQvMTQzMzcxMTgzNC8yMzEgZm9ya3Rvb211Y2ggMTQzMzcxMTgzNC8xNDMzNzExODM0LzE0
>MzM3MTE4MzQgYWxsb2MgNDAvNC8wIGNyZWF0IDg4NS82OTEvNjkxIGxvY2sgMS8xLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExODg4Lzc0NS8wICh0ZXN0czogcmVhZCAxNDMz
>NzExODg4LzE0MzM3MTE4ODgvMjYgbnhyZWFkIDE0MzM3MTE4ODgvMTQzMzcxMTg4OC8xNDI4IHRy
>eWV4Y2VwdCA5LzIvMSBmb3JrIDE0MzM3MTE4ODgvMTQzMzcxMTg4OC8yODUgZm9ya3Rvb211Y2gg
>MTQzMzcxMTg4OC8xNDMzNzExODg4LzE0MzM3MTE4ODggYWxsb2MgMjYvMTIvNyBjcmVhdCA5Mzkv
>NzQ1Lzc0NSBsb2NrIDcvNy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTky
>My82MS8wICh0ZXN0czogcmVhZCAxNDMzNzExOTIzLzE0MzM3MTE5MjMvNjEgbnhyZWFkIDE0MzM3
>MTE5MjMvMTQzMzcxMTkyMy8xNDYzIHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzExOTIzLzE0
>MzM3MTE5MjMvMzIwIGZvcmt0b29tdWNoIDE0MzM3MTE5MjMvMTQzMzcxMTkyMy8xNDMzNzExOTIz
>IGFsbG9jIDI1LzcvMCBjcmVhdCAyOC8yOC8yOCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTk1NS82MC8wICh0ZXN0czogcmVhZCAxNDMzNzExOTU1LzE0MzM3
>MTE5NTUvOCBueHJlYWQgMTQzMzcxMTk1NS8xNDMzNzExOTU1LzE0OTUgdHJ5ZXhjZXB0IDIzLzMv
>MSBmb3JrIDE0MzM3MTE5NTUvMTQzMzcxMTk1NS8zNTIgZm9ya3Rvb211Y2ggMTQzMzcxMTk1NS8x
>NDMzNzExOTU1LzE0MzM3MTE5NTUgYWxsb2MgMzIvOC8zIGNyZWF0IDYwLzYwLzYwIGxvY2sgMy8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExOTk2LzEwMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzExOTk2LzE0MzM3MTE5OTYvMSBueHJlYWQgMTQzMzcxMTk5Ni8xNDMzNzExOTk2
>LzE1MzYgdHJ5ZXhjZXB0IDYyLzIvMCBmb3JrIDE0MzM3MTE5OTYvMTQzMzcxMTk5Ni8zOTMgZm9y
>a3Rvb211Y2ggMTQzMzcxMTk5Ni8xNDMzNzExOTk2LzE0MzM3MTE5OTYgYWxsb2MgNDEvNC8xIGNy
>ZWF0IDEwMS8xMDEvMTAxIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEyMDMyLzEzNy8wICh0ZXN0czogcmVhZCAxNDMzNzEyMDMyLzE0MzM3MTIwMzIvMjAgbnhy
>ZWFkIDE0MzM3MTIwMzIvMTQzMzcxMjAzMi8xNTcyIHRyeWV4Y2VwdCA2LzIvMSBmb3JrIDE0MzM3
>MTIwMzIvMTQzMzcxMjAzMi80MjkgZm9ya3Rvb211Y2ggMTQzMzcxMjAzMi8xNDMzNzEyMDMyLzE0
>MzM3MTIwMzIgYWxsb2MgMzcvMTYvMCBjcmVhdCAxMzcvMTM3LzEzNyBsb2NrIDQvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjA2My8xNjgvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMjA2My8xNDMzNzEyMDYzLzE1IG54cmVhZCAxNDMzNzEyMDYzLzE0MzM3MTIwNjMvMTYwMyB0
>cnlleGNlcHQgMjUvMy8xIGZvcmsgMTQzMzcxMjA2My8xNDMzNzEyMDYzLzQ2MCBmb3JrdG9vbXVj
>aCAxNDMzNzEyMDYzLzE0MzM3MTIwNjMvMTQzMzcxMjA2MyBhbGxvYyA0MC8xMC81IGNyZWF0IDE2
>OC8xNjgvMTY4IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEy
>MDk1LzIwMC8wICh0ZXN0czogcmVhZCAxNDMzNzEyMDk1LzE0MzM3MTIwOTUvNSBueHJlYWQgMTQz
>MzcxMjA5NS8xNDMzNzEyMDk1LzE2MzUgdHJ5ZXhjZXB0IDI3LzEvMCBmb3JrIDE0MzM3MTIwOTUv
>MTQzMzcxMjA5NS80OTIgZm9ya3Rvb211Y2ggMTQzMzcxMjA5NS8xNDMzNzEyMDk1LzE0MzM3MTIw
>OTUgYWxsb2MgNTgvMTAvMiBjcmVhdCAyMDAvMjAwLzIwMCBsb2NrIDEvMS8xKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjEyNC8yMjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjEy
>NC8xNDMzNzEyMTI0LzEgbnhyZWFkIDE0MzM3MTIxMjQvMTQzMzcxMjEyNC8xNjY0IHRyeWV4Y2Vw
>dCA4LzMvMCBmb3JrIDE0MzM3MTIxMjQvMTQzMzcxMjEyNC81MjEgZm9ya3Rvb211Y2ggMTQzMzcx
>MjEyNC8xNDMzNzEyMTI0LzE0MzM3MTIxMjQgYWxsb2MgMzkvNi8xIGNyZWF0IDIyOS8yMjkvMjI5
>IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyMTY1LzI3MC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzEyMTY1LzE0MzM3MTIxNjUvMjMgbnhyZWFkIDE0MzM3MTIxNjUv
>MTQzMzcxMjE2NS8xNzA1IHRyeWV4Y2VwdCA1LzIvMiBmb3JrIDE0MzM3MTIxNjUvMTQzMzcxMjE2
>NS81NjIgZm9ya3Rvb211Y2ggMTQzMzcxMjE2NS8xNDMzNzEyMTY1LzE0MzM3MTIxNjUgYWxsb2Mg
>NTIvNS81IGNyZWF0IDI3MC8yNzAvMjcwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzEyMTg3LzI5Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEyMTg3LzE0MzM3MTIx
>ODcvOSBueHJlYWQgMTQzMzcxMjE4Ny8xNDMzNzEyMTg3LzE3MjcgdHJ5ZXhjZXB0IDE4LzIvMCBm
>b3JrIDE0MzM3MTIxODcvMTQzMzcxMjE4Ny81ODQgZm9ya3Rvb211Y2ggMTQzMzcxMjE4Ny8xNDMz
>NzEyMTg3LzE0MzM3MTIxODcgYWxsb2MgNzQvNS8xIGNyZWF0IDI5Mi8yOTIvMjkyIGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyMjE2LzMyMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEyMjE2LzE0MzM3MTIyMTYvOCBueHJlYWQgMTQzMzcxMjIxNi8xNDMzNzEyMjE2
>LzE3NTYgdHJ5ZXhjZXB0IDkvMS8xIGZvcmsgMTQzMzcxMjIxNi8xNDMzNzEyMjE2LzYxMyBmb3Jr
>dG9vbXVjaCAxNDMzNzEyMjE2LzE0MzM3MTIyMTYvMTQzMzcxMjIxNiBhbGxvYyA1MS8yMS80IGNy
>ZWF0IDMyMS8zMjEvMzIxIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEyMjQ1LzM1MC8wICh0ZXN0czogcmVhZCAxNDMzNzEyMjQ1LzE0MzM3MTIyNDUvMTUgbnhy
>ZWFkIDE0MzM3MTIyNDUvMTQzMzcxMjI0NS8xNzg1IHRyeWV4Y2VwdCAzOC8yLzEgZm9yayAxNDMz
>NzEyMjQ1LzE0MzM3MTIyNDUvNjQyIGZvcmt0b29tdWNoIDE0MzM3MTIyNDUvMTQzMzcxMjI0NS8x
>NDMzNzEyMjQ1IGFsbG9jIDczLzgvNCBjcmVhdCAzNTAvMzUwLzM1MCBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjI3MC8zNzUvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMjI3MC8xNDMzNzEyMjcwLzYgbnhyZWFkIDE0MzM3MTIyNzAvMTQzMzcxMjI3MC8xODEwIHRy
>eWV4Y2VwdCAyMi8yLzEgZm9yayAxNDMzNzEyMjcwLzE0MzM3MTIyNzAvNjY3IGZvcmt0b29tdWNo
>IDE0MzM3MTIyNzAvMTQzMzcxMjI3MC8xNDMzNzEyMjcwIGFsbG9jIDU0LzkvNiBjcmVhdCAzNzUv
>Mzc1LzM3NSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjMw
>MC80MDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjMwMC8xNDMzNzEyMzAwLzEzIG54cmVhZCAxNDMz
>NzEyMzAwLzE0MzM3MTIzMDAvMTg0MCB0cnlleGNlcHQgNTIvMi8xIGZvcmsgMTQzMzcxMjMwMC8x
>NDMzNzEyMzAwLzY5NyBmb3JrdG9vbXVjaCAxNDMzNzEyMzAwLzE0MzM3MTIzMDAvMTQzMzcxMjMw
>MCBhbGxvYyAxOC8zLzMgY3JlYXQgNDA1LzQwNS80MDUgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTIzNDIvNDQ3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTIzNDIv
>MTQzMzcxMjM0Mi8xNiBueHJlYWQgMTQzMzcxMjM0Mi8xNDMzNzEyMzQyLzE4ODIgdHJ5ZXhjZXB0
>IDEzLzIvMSBmb3JrIDE0MzM3MTIzNDIvMTQzMzcxMjM0Mi83MzkgZm9ya3Rvb211Y2ggMTQzMzcx
>MjM0Mi8xNDMzNzEyMzQyLzE0MzM3MTIzNDIgYWxsb2MgNjAvMjAvNSBjcmVhdCA0NDcvNDQ3LzQ0
>NyBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjM3Mi80Nzcv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMjM3Mi8xNDMzNzEyMzcyLzMgbnhyZWFkIDE0MzM3MTIzNzIv
>MTQzMzcxMjM3Mi8xOTEyIHRyeWV4Y2VwdCAyLzIvMCBmb3JrIDE0MzM3MTIzNzIvMTQzMzcxMjM3
>Mi83NjkgZm9ya3Rvb211Y2ggMTQzMzcxMjM3Mi8xNDMzNzEyMzcyLzE0MzM3MTIzNzIgYWxsb2Mg
>MzAvOC8zIGNyZWF0IDQ3Ny80NzcvNDc3IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzEyNDM0LzUzOS8wICh0ZXN0czogcmVhZCAxNDMzNzEyNDM0LzE0MzM3MTI0
>MzQvMTcgbnhyZWFkIDE0MzM3MTI0MzQvMTQzMzcxMjQzNC8xOTc0IHRyeWV4Y2VwdCAxNi8yLzEg
>Zm9yayAxNDMzNzEyNDM0LzE0MzM3MTI0MzQvODMxIGZvcmt0b29tdWNoIDE0MzM3MTI0MzQvMTQz
>MzcxMjQzNC8xNDMzNzEyNDM0IGFsbG9jIDMzLzUvNSBjcmVhdCA1MzkvNTM5LzUzOSBsb2NrIDQv
>NC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjQ1Ny81NjIvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxMjQ1Ny8xNDMzNzEyNDU3LzMgbnhyZWFkIDE0MzM3MTI0NTcvMTQzMzcxMjQ1
>Ny8xOTk3IHRyeWV4Y2VwdCAxMy8yLzAgZm9yayAxNDMzNzEyNDU3LzE0MzM3MTI0NTcvODU0IGZv
>cmt0b29tdWNoIDE0MzM3MTI0NTcvMTQzMzcxMjQ1Ny8xNDMzNzEyNDU3IGFsbG9jIDI4LzMvMSBj
>cmVhdCA1NjIvNTYyLzU2MiBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxMjUwMC82MDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjUwMC8xNDMzNzEyNTAwLzE1IG54
>cmVhZCAxNDMzNzEyNTAwLzE0MzM3MTI1MDAvMjA0MCB0cnlleGNlcHQgNTMvMi8wIGZvcmsgMTQz
>MzcxMjUwMC8xNDMzNzEyNTAwLzg5NyBmb3JrdG9vbXVjaCAxNDMzNzEyNTAwLzE0MzM3MTI1MDAv
>MTQzMzcxMjUwMCBhbGxvYyA0NC8xNS8xIGNyZWF0IDYwNS82MDUvNjA1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyNTI4LzYzMy8wICh0ZXN0czogcmVhZCAx
>NDMzNzEyNTI4LzE0MzM3MTI1MjgvOCBueHJlYWQgMTQzMzcxMjUyOC8xNDMzNzEyNTI4LzIwNjgg
>dHJ5ZXhjZXB0IDQwLzIvMSBmb3JrIDE0MzM3MTI1MjgvMTQzMzcxMjUyOC85MjUgZm9ya3Rvb211
>Y2ggMTQzMzcxMjUyOC8xNDMzNzEyNTI4LzE0MzM3MTI1MjggYWxsb2MgNTAvOC80IGNyZWF0IDYz
>My82MzMvNjMzIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEy
>NTUwLzY1NS8wICh0ZXN0czogcmVhZCAxNDMzNzEyNTUwLzE0MzM3MTI1NTAvMjIgbnhyZWFkIDE0
>MzM3MTI1NTAvMTQzMzcxMjU1MC8yMDkwIHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzEyNTUw
>LzE0MzM3MTI1NTAvOTQ3IGZvcmt0b29tdWNoIDE0MzM3MTI1NTAvMTQzMzcxMjU1MC8xNDMzNzEy
>NTUwIGFsbG9jIDY1LzEwLzQgY3JlYXQgNjU1LzY1NS82NTUgbG9jayA0LzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI1NzcvNjgyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTI1
>NzcvMTQzMzcxMjU3Ny8xNiBueHJlYWQgMTQzMzcxMjU3Ny8xNDMzNzEyNTc3LzIxMTcgdHJ5ZXhj
>ZXB0IDgvMS8xIGZvcmsgMTQzMzcxMjU3Ny8xNDMzNzEyNTc3Lzk3NCBmb3JrdG9vbXVjaCAxNDMz
>NzEyNTc3LzE0MzM3MTI1NzcvMTQzMzcxMjU3NyBhbGxvYyAzNy8yMS8wIGNyZWF0IDY4Mi82ODIv
>NjgyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyNjAzLzcw
>OC8wICh0ZXN0czogcmVhZCAxNDMzNzEyNjAzLzE0MzM3MTI2MDMvMTAgbnhyZWFkIDE0MzM3MTI2
>MDMvMTQzMzcxMjYwMy8yMTQzIHRyeWV4Y2VwdCAxNi8zLzAgZm9yayAxNDMzNzEyNjAzLzE0MzM3
>MTI2MDMvMTAwMCBmb3JrdG9vbXVjaCAxNDMzNzEyNjAzLzE0MzM3MTI2MDMvMTQzMzcxMjYwMyBh
>bGxvYyAzNi8xNS8xMCBjcmVhdCA3MDgvNzA4LzcwOCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjYzMS83MzYvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjYzMS8x
>NDMzNzEyNjMxLzEgbnhyZWFkIDE0MzM3MTI2MzEvMTQzMzcxMjYzMS8yMTcxIHRyeWV4Y2VwdCAz
>OC8xLzAgZm9yayAxNDMzNzEyNjMxLzE0MzM3MTI2MzEvMTAyOCBmb3JrdG9vbXVjaCAxNDMzNzEy
>NjMxLzE0MzM3MTI2MzEvMTQzMzcxMjYzMSBhbGxvYyA2NC83LzEgY3JlYXQgNzM2LzczNi83MzYg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI2NTkvNzY0LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTI2NTkvMTQzMzcxMjY1OS8yOSBueHJlYWQgMTQzMzcxMjY1OS8x
>NDMzNzEyNjU5LzIxOTkgdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcxMjY1OS8xNDMzNzEyNjU5
>LzI0IGZvcmt0b29tdWNoIDE0MzM3MTI2NTkvMTQzMzcxMjY1OS8xNDMzNzEyNjU5IGFsbG9jIDI5
>LzMvMSBjcmVhdCA3NjQvNzY0Lzc2NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxMjY5Mi83OTcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjY5Mi8xNDMzNzEyNjky
>LzYyIG54cmVhZCAxNDMzNzEyNjkyLzE0MzM3MTI2OTIvMjIzMiB0cnlleGNlcHQgMzUvNy8wIGZv
>cmsgMTQzMzcxMjY5Mi8xNDMzNzEyNjkyLzU3IGZvcmt0b29tdWNoIDE0MzM3MTI2OTIvMTQzMzcx
>MjY5Mi8xNDMzNzEyNjkyIGFsbG9jIDM2LzYvMSBjcmVhdCA3OTcvNzk3Lzc5NyBsb2NrIDEvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjcxNy84MjIvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMjcxNy8xNDMzNzEyNzE3Lzg3IG54cmVhZCAxNDMzNzEyNzE3LzE0MzM3MTI3MTcv
>MjI1NyB0cnlleGNlcHQgMzcvMi8xIGZvcmsgMTQzMzcxMjcxNy8xNDMzNzEyNzE3LzgyIGZvcmt0
>b29tdWNoIDE0MzM3MTI3MTcvMTQzMzcxMjcxNy8xNDMzNzEyNzE3IGFsbG9jIDQ3LzYvMiBjcmVh
>dCA4MjIvODIyLzgyMiBsb2NrIDIvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMjc0Mi84NDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjc0Mi8xNDMzNzEyNzQyLzIgbnhyZWFk
>IDE0MzM3MTI3NDIvMTQzMzcxMjc0Mi8yMjgyIHRyeWV4Y2VwdCAyNi8xLzAgZm9yayAxNDMzNzEy
>NzQyLzE0MzM3MTI3NDIvMTA3IGZvcmt0b29tdWNoIDE0MzM3MTI3NDIvMTQzMzcxMjc0Mi8xNDMz
>NzEyNzQyIGFsbG9jIDcyLzcvMiBjcmVhdCA4NDcvODQ3Lzg0NyBsb2NrIDEvMS8xKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjc3My84NzgvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>Mjc3My8xNDMzNzEyNzczLzcgbnhyZWFkIDE0MzM3MTI3NzMvMTQzMzcxMjc3My8yMzEzIHRyeWV4
>Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzEyNzczLzE0MzM3MTI3NzMvMTM4IGZvcmt0b29tdWNoIDE0
>MzM3MTI3NzMvMTQzMzcxMjc3My8xNDMzNzEyNzczIGFsbG9jIDM4LzE0LzQgY3JlYXQgODc4Lzg3
>OC84NzggbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI3OTgv
>OTAzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTI3OTgvMTQzMzcxMjc5OC8xIG54cmVhZCAxNDMzNzEy
>Nzk4LzE0MzM3MTI3OTgvMjMzOCB0cnlleGNlcHQgMTMvMy8wIGZvcmsgMTQzMzcxMjc5OC8xNDMz
>NzEyNzk4LzEyIGZvcmt0b29tdWNoIDE0MzM3MTI3OTgvMTQzMzcxMjc5OC8xNDMzNzEyNzk4IGFs
>bG9jIDUzLzQvMSBjcmVhdCA5MDMvOTAzLzkwMyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMjgzNC85MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjgzNC8xMDUw
>LzkgbnhyZWFkIDE0MzM3MTI4MzQvMTQzMzcxMjgzNC8yMzc0IHRyeWV4Y2VwdCAyMy8yLzEgZm9y
>ayAxNDMzNzEyODM0LzE0MzM3MTI4MzQvNDggZm9ya3Rvb211Y2ggMTQzMzcxMjgzNC8xNDMzNzEy
>ODM0LzE0MzM3MTI4MzQgYWxsb2MgNDgvMTcvNSBjcmVhdCA5MzkvOTM5LzkzOSBsb2NrIDUvNS8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjg3NS85ODAvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMjg3NS8xMDkxLzIyIG54cmVhZCAxNDMzNzEyODc1LzE0MzM3MTI4NzUvMjQxNSB0
>cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzEyODc1LzE0MzM3MTI4NzUvODkgZm9ya3Rvb211Y2gg
>MTQzMzcxMjg3NS8xNDMzNzEyODc1LzE0MzM3MTI4NzUgYWxsb2MgNDEvNi8xIGNyZWF0IDk4MC85
>ODAvOTgwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyOTA4
>LzEwMTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjkwOC8xMTI0LzU1IG54cmVhZCAxNDMzNzEyOTA4
>LzE0MzM3MTI5MDgvMjQ0OCB0cnlleGNlcHQgMy8yLzEgZm9yayAxNDMzNzEyOTA4LzE0MzM3MTI5
>MDgvMTIyIGZvcmt0b29tdWNoIDE0MzM3MTI5MDgvMTQzMzcxMjkwOC8xNDMzNzEyOTA4IGFsbG9j
>IDU5LzEyLzYgY3JlYXQgMTAxMy8xMDEzLzEwMTMgbG9jayA0LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTI5MjkvMTAzNC8wICh0ZXN0czogcmVhZCAxNDMzNzEyOTI5LzEx
>NDUvNSBueHJlYWQgMTQzMzcxMjkyOS8xNDMzNzEyOTI5LzI0NjkgdHJ5ZXhjZXB0IDUvMi8xIGZv
>cmsgMTQzMzcxMjkyOS8xNDMzNzEyOTI5LzE0MyBmb3JrdG9vbXVjaCAxNDMzNzEyOTI5LzE0MzM3
>MTI5MjkvMTQzMzcxMjkyOSBhbGxvYyA0NC8xMS81IGNyZWF0IDEwMzQvMTAzNC8xMDM0IGxvY2sg
>MC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyOTU1LzEwNjAvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxMjk1NS8xMTcxLzI2IG54cmVhZCAxNDMzNzEyOTU1LzE0MzM3MTI5NTUv
>MjQ5NSB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzEyOTU1LzE0MzM3MTI5NTUvMTY5IGZvcmt0
>b29tdWNoIDE0MzM3MTI5NTUvMTQzMzcxMjk1NS8xNDMzNzEyOTU1IGFsbG9jIDM3LzEyLzQgY3Jl
>YXQgMTA2MC8xMDYwLzEwNjAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTI5NzcvMTA4Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEyOTc3LzExOTMvNDggbnhyZWFk
>IDE0MzM3MTI5NzcvMTQzMzcxMjk3Ny8yNTE3IHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzEy
>OTc3LzE0MzM3MTI5NzcvMTkxIGZvcmt0b29tdWNoIDE0MzM3MTI5NzcvMTQzMzcxMjk3Ny8xNDMz
>NzEyOTc3IGFsbG9jIDI2LzUvNSBjcmVhdCAxMDgyLzEwODIvMTA4MiBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjk5Ni8xMTAxLzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTI5OTYvMTIxMi8xOSBueHJlYWQgMTQzMzcxMjk5Ni8xNDMzNzEyOTk2LzI1MzYgdHJ5ZXhj
>ZXB0IDIwLzIvMiBmb3JrIDE0MzM3MTI5OTYvMTQzMzcxMjk5Ni8yMTAgZm9ya3Rvb211Y2ggMTQz
>MzcxMjk5Ni8xNDMzNzEyOTk2LzE0MzM3MTI5OTYgYWxsb2MgNDUvMTEvMCBjcmVhdCAxMTAxLzEx
>MDEvMTEwMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzAx
>Ni8xMTIxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTMwMTYvMTIzMi82IG54cmVhZCAxNDMzNzEzMDE2
>LzE0MzM3MTMwMTYvMjU1NiB0cnlleGNlcHQgMzgvMC8wIGZvcmsgMTQzMzcxMzAxNi8xNDMzNzEz
>MDE2LzIzMCBmb3JrdG9vbXVjaCAxNDMzNzEzMDE2LzE0MzM3MTMwMTYvMTQzMzcxMzAxNiBhbGxv
>YyAyMC82LzIgY3JlYXQgMTEyMS8xMTIxLzExMjEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTMwMzcvMTE0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEzMDM3LzEy
>NTMvNyBueHJlYWQgMTQzMzcxMzAzNy8xNDMzNzEzMDM3LzI1NzcgdHJ5ZXhjZXB0IDE3LzEvMSBm
>b3JrIDE0MzM3MTMwMzcvMTQzMzcxMzAzNy8yNTEgZm9ya3Rvb211Y2ggMTQzMzcxMzAzNy8xNDMz
>NzEzMDM3LzE0MzM3MTMwMzcgYWxsb2MgMjcvMTgvMyBjcmVhdCAxMTQyLzExNDIvMTE0MiBsb2Nr
>IDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzA2MS8xMTY2LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTMwNjEvMTI3Ny82IG54cmVhZCAxNDMzNzEzMDYxLzE0MzM3MTMwNjEv
>MjYwMSB0cnlleGNlcHQgMTMvMS8xIGZvcmsgMTQzMzcxMzA2MS8xNDMzNzEzMDYxLzI3NSBmb3Jr
>dG9vbXVjaCAxNDMzNzEzMDYxLzE0MzM3MTMwNjEvMTQzMzcxMzA2MSBhbGxvYyA1MS8xNS8wIGNy
>ZWF0IDExNjYvMTE2Ni8xMTY2IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzEzMDgxLzExODYvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzA4MS8xMjk3LzkgbnhyZWFk
>IDE0MzM3MTMwODEvMTQzMzcxMzA4MS8yNjIxIHRyeWV4Y2VwdCAxNC85LzAgZm9yayAxNDMzNzEz
>MDgxLzE0MzM3MTMwODEvMjk1IGZvcmt0b29tdWNoIDE0MzM3MTMwODEvMTQzMzcxMzA4MS8xNDMz
>NzEzMDgxIGFsbG9jIDMyLzExLzAgY3JlYXQgMTE4Ni8xMTg2LzExODYgbG9jayAwLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTMxMDYvMTIxMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzEzMTA2LzEzMjIvNCBueHJlYWQgMTQzMzcxMzEwNi8xNDMzNzEzMTA2LzI2NDYgdHJ5ZXhj
>ZXB0IDI3LzEvMSBmb3JrIDE0MzM3MTMxMDYvMTQzMzcxMzEwNi8zMjAgZm9ya3Rvb211Y2ggMTQz
>MzcxMzEwNi8xNDMzNzEzMTA2LzE0MzM3MTMxMDYgYWxsb2MgMzYvOS80IGNyZWF0IDEyMTEvMTIx
>MS8xMjExIGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzMTM0
>LzEyMzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzEzNC8xMzUwLzMyIG54cmVhZCAxNDMzNzEzMTM0
>LzE0MzM3MTMxMzQvMjY3NCB0cnlleGNlcHQgMTYvMC8wIGZvcmsgMTQzMzcxMzEzNC8xNDMzNzEz
>MTM0LzM0OCBmb3JrdG9vbXVjaCAxNDMzNzEzMTM0LzE0MzM3MTMxMzQvMTQzMzcxMzEzNCBhbGxv
>YyAyOC81LzIgY3JlYXQgMTIzOS8xMjM5LzEyMzkgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTMxOTIvMzM5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTMxOTIvMTQw
>OC81IG54cmVhZCAxNDMzNzEzMTkyLzE0MzM3MTMxOTIvMjczMiB0cnlleGNlcHQgNC8yLzEgZm9y
>ayAxNDMzNzEzMTkyLzE0MzM3MTMxOTIvNSBmb3JrdG9vbXVjaCAxNDMzNzEzMTkyLzE0MzM3MTMx
>OTIvMTQzMzcxMzE5MiBhbGxvYyA0Mi8xMC8wIGNyZWF0IDEyOTcvMTI5Ny8xMyBsb2NrIDQvMy8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzIxNi8zNjMvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMzIxNi8xNDMyLzkgbnhyZWFkIDE0MzM3MTMyMTYvMTQzMzcxMzIxNi8yNzU2IHRy
>eWV4Y2VwdCAzLzIvMSBmb3JrIDE0MzM3MTMyMTYvMTQzMzcxMzIxNi8yOSBmb3JrdG9vbXVjaCAx
>NDMzNzEzMjE2LzE0MzM3MTMyMTYvMTQzMzcxMzIxNiBhbGxvYyAzNy8xNC83IGNyZWF0IDEzMjEv
>MTMyMS8zNyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzI0
>My8zOTAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzI0My8xNDU5LzYgbnhyZWFkIDE0MzM3MTMyNDMv
>MTQzMzcxMzI0My8yNzgzIHRyeWV4Y2VwdCAyMS8yLzEgZm9yayAxNDMzNzEzMjQzLzE0MzM3MTMy
>NDMvNTYgZm9ya3Rvb211Y2ggMTQzMzcxMzI0My8xNDMzNzEzMjQzLzE0MzM3MTMyNDMgYWxsb2Mg
>MzQvMjAvNiBjcmVhdCAxMzQ4LzEzNDgvNjQgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTMyNzEvNDE4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTMyNzEvMTQ4Ny81
>IG54cmVhZCAxNDMzNzEzMjcxLzE0MzM3MTMyNzEvMjgxMSB0cnlleGNlcHQgMTAvMi8xIGZvcmsg
>MTQzMzcxMzI3MS8xNDMzNzEzMjcxLzg0IGZvcmt0b29tdWNoIDE0MzM3MTMyNzEvMTQzMzcxMzI3
>MS8xNDMzNzEzMjcxIGFsbG9jIDM0LzE4LzUgY3JlYXQgMTM3Ni8xMzc2LzkyIGxvY2sgNC80LzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzMzE4LzIyNy8wICh0ZXN0czogcmVh
>ZCAxNDMzNzEzMzE4LzQ2NS8xOSBueHJlYWQgMTQzMzcxMzMxOC8xNDMzNzEzMzE4LzI4NTggdHJ5
>ZXhjZXB0IDEzLzMvMCBmb3JrIDE0MzM3MTMzMTgvMTQzMzcxMzMxOC8xOCBmb3JrdG9vbXVjaCAx
>NDMzNzEzMzE4LzE0MzM3MTMzMTgvMTQzMzcxMzMxOCBhbGxvYyAyOC8xLzEgY3JlYXQgMTQyMy8x
>NDIzLzEzOSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzM1
>MC8yNTkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzM1MC8yNTkvMTcgbnhyZWFkIDE0MzM3MTMzNTAv
>MTQzMzcxMzM1MC8yODkwIHRyeWV4Y2VwdCAxOC8yLzAgZm9yayAxNDMzNzEzMzUwLzE0MzM3MTMz
>NTAvNTAgZm9ya3Rvb211Y2ggMTQzMzcxMzM1MC8xNDMzNzEzMzUwLzE0MzM3MTMzNTAgYWxsb2Mg
>MzMvMS8xIGNyZWF0IDE0NTUvMTQ1NS8xNzEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTM0NTAvMjgyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTM0NTAvMzU5LzE1
>IG54cmVhZCAxNDMzNzEzNDUwLzE0MzM3MTM0NTAvMjk5MCB0cnlleGNlcHQgMTIvMi8xIGZvcmsg
>MTQzMzcxMzQ1MC8xNDMzNzEzNDUwLzE1MCBmb3JrdG9vbXVjaCAxNDMzNzEzNDUwLzE0MzM3MTM0
>NTAvMTQzMzcxMzQ1MCBhbGxvYyA0Ni8yNS8wIGNyZWF0IDE1NTUvMTU1NS8yNzEgbG9jayA0LzQv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM0OTMvMzI1LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTM0OTMvNDAyLzE0IG54cmVhZCAxNDMzNzEzNDkzLzE0MzM3MTM0OTMvMzAzMyB0
>cnlleGNlcHQgNDAvMS8xIGZvcmsgMTQzMzcxMzQ5My8xNDMzNzEzNDkzLzE5MyBmb3JrdG9vbXVj
>aCAxNDMzNzEzNDkzLzE0MzM3MTM0OTMvMTQzMzcxMzQ5MyBhbGxvYyAxNC81LzAgY3JlYXQgMTU5
>OC8xNTk4LzMxNCBsb2NrIDUvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>MzUyMC8zNTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzUyMC80MjkvMSBueHJlYWQgMTQzMzcxMzUy
>MC8xNDMzNzEzNTIwLzMwNjAgdHJ5ZXhjZXB0IDIvMi8wIGZvcmsgMTQzMzcxMzUyMC8xNDMzNzEz
>NTIwLzIyMCBmb3JrdG9vbXVjaCAxNDMzNzEzNTIwLzE0MzM3MTM1MjAvMTQzMzcxMzUyMCBhbGxv
>YyAzNi8yLzEgY3JlYXQgMTYyNS8xNjI1LzM0MSBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzU2NS8zOTcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzU2NS80NzQv
>MSBueHJlYWQgMTQzMzcxMzU2NS8xNDMzNzEzNTY1LzMxMDUgdHJ5ZXhjZXB0IDgvMS8wIGZvcmsg
>MTQzMzcxMzU2NS8xNDMzNzEzNTY1LzI2NSBmb3JrdG9vbXVjaCAxNDMzNzEzNTY1LzE0MzM3MTM1
>NjUvMTQzMzcxMzU2NSBhbGxvYyA0Ny83LzEgY3JlYXQgMTY3MC8xNjcwLzM4NiBsb2NrIDEvMS8x
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzU4OC80MjAvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMzU4OC80OTcvMjEgbnhyZWFkIDE0MzM3MTM1ODgvMTQzMzcxMzU4OC8zMTI4IHRy
>eWV4Y2VwdCAzMS8wLzAgZm9yayAxNDMzNzEzNTg4LzE0MzM3MTM1ODgvMjg4IGZvcmt0b29tdWNo
>IDE0MzM3MTM1ODgvMTQzMzcxMzU4OC8xNDMzNzEzNTg4IGFsbG9jIDIxLzYvMSBjcmVhdCAxNjkz
>LzE2OTMvNDA5IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEz
>NjIwLzQ1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEzNjIwLzUyOS8xMCBueHJlYWQgMTQzMzcxMzYy
>MC8xNDMzNzEzNjIwLzMxNjAgdHJ5ZXhjZXB0IDMvMi8xIGZvcmsgMTQzMzcxMzYyMC8xNDMzNzEz
>NjIwLzE3IGZvcmt0b29tdWNoIDE0MzM3MTM2MjAvMTQzMzcxMzYyMC8xNDMzNzEzNjIwIGFsbG9j
>IDI1LzEwLzMgY3JlYXQgMTcyNS8xNzI1LzQ0MSBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzY2Ny80OTkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzY2Ny81NzYv
>MTcgbnhyZWFkIDE0MzM3MTM2NjcvMTQzMzcxMzY2Ny8zMjA3IHRyeWV4Y2VwdCA0LzIvMSBmb3Jr
>IDE0MzM3MTM2NjcvMTQzMzcxMzY2Ny82NCBmb3JrdG9vbXVjaCAxNDMzNzEzNjY3LzE0MzM3MTM2
>NjcvMTQzMzcxMzY2NyBhbGxvYyA0Mi8xMS81IGNyZWF0IDE3NzIvMTc3Mi80ODggbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM3MTMvNTQ1LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTM3MTMvNjIyLzIgbnhyZWFkIDE0MzM3MTM3MTMvMTQzMzcxMzcxMy8zMjUzIHRy
>eWV4Y2VwdCAzLzEvMCBmb3JrIDE0MzM3MTM3MTMvMTQzMzcxMzcxMy8xMTAgZm9ya3Rvb211Y2gg
>MTQzMzcxMzcxMy8xNDMzNzEzNzEzLzE0MzM3MTM3MTMgYWxsb2MgMjIvOC8yIGNyZWF0IDE4MTgv
>MTgxOC81MzQgbG9jayAyLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM3
>NDYvNTc4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTM3NDYvNjU1LzE0IG54cmVhZCAxNDMzNzEzNzQ2
>LzE0MzM3MTM3NDYvMzI4NiB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzEzNzQ2LzE0MzM3MTM3
>NDYvMTQzIGZvcmt0b29tdWNoIDE0MzM3MTM3NDYvMTQzMzcxMzc0Ni8xNDMzNzEzNzQ2IGFsbG9j
>IDM1LzEwLzUgY3JlYXQgMTg1MS8xODUxLzU2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzc5NS82MjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzc5NS83MDQv
>MTYgbnhyZWFkIDE0MzM3MTM3OTUvMTQzMzcxMzc5NS8zMzM1IHRyeWV4Y2VwdCA1LzIvMSBmb3Jr
>IDE0MzM3MTM3OTUvMTQzMzcxMzc5NS8xOTIgZm9ya3Rvb211Y2ggMTQzMzcxMzc5NS8xNDMzNzEz
>Nzk1LzE0MzM3MTM3OTUgYWxsb2MgMzMvMTEvNiBjcmVhdCAxOTAwLzE5MDAvNjE2IGxvY2sgNi82
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzODI3LzY1OS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEzODI3LzczNi8xNCBueHJlYWQgMTQzMzcxMzgyNy8xNDMzNzEzODI3LzMzNjcg
>dHJ5ZXhjZXB0IDQvMy8wIGZvcmsgMTQzMzcxMzgyNy8xNDMzNzEzODI3LzIyNCBmb3JrdG9vbXVj
>aCAxNDMzNzEzODI3LzE0MzM3MTM4MjcvMTQzMzcxMzgyNyBhbGxvYyA0My8xLzEgY3JlYXQgMTkz
>Mi8xOTMyLzY0OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>Mzg2MS82OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzg2MS83NzAvMjEgbnhyZWFkIDE0MzM3MTM4
>NjEvMTQzMzcxMzg2MS8zNDAxIHRyeWV4Y2VwdCA0LzAvMCBmb3JrIDE0MzM3MTM4NjEvMTQzMzcx
>Mzg2MS8yNTggZm9ya3Rvb211Y2ggMTQzMzcxMzg2MS8xNDMzNzEzODYxLzE0MzM3MTM4NjEgYWxs
>b2MgNzcvOC8yIGNyZWF0IDE5NjYvMTk2Ni82ODIgbG9jayAyLzIvMSkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTM4OTEvNzIzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTM4OTEvODAw
>LzUxIG54cmVhZCAxNDMzNzEzODkxLzE0MzM3MTM4OTEvMzQzMSB0cnlleGNlcHQgNC8yLzEgZm9y
>ayAxNDMzNzEzODkxLzE0MzM3MTM4OTEvMjg4IGZvcmt0b29tdWNoIDE0MzM3MTM4OTEvMTQzMzcx
>Mzg5MS8xNDMzNzEzODkxIGFsbG9jIDI2LzEwLzUgY3JlYXQgMTk5Ni8xOTk2LzcxMiBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzkxOS83NTEvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxMzkxOS84MjgvMjIgbnhyZWFkIDE0MzM3MTM5MTkvMTQzMzcxMzkxOS8zNDU5
>IHRyeWV4Y2VwdCAyMi8yLzEgZm9yayAxNDMzNzEzOTE5LzE0MzM3MTM5MTkvMzE2IGZvcmt0b29t
>dWNoIDE0MzM3MTM5MTkvMTQzMzcxMzkxOS8xNDMzNzEzOTE5IGFsbG9jIDM4LzE0LzYgY3JlYXQg
>MjAyNC8yMDI0Lzc0MCBsb2NrIDYvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMzkzNy83NjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzkzNy84NDYvMTggbnhyZWFkIDE0MzM3
>MTM5MzcvMTQzMzcxMzkzNy8zNDc3IHRyeWV4Y2VwdCA0MC8wLzAgZm9yayAxNDMzNzEzOTM3LzE0
>MzM3MTM5MzcvMzM0IGZvcmt0b29tdWNoIDE0MzM3MTM5MzcvMTQzMzcxMzkzNy8xNDMzNzEzOTM3
>IGFsbG9jIDI3LzgvMyBjcmVhdCAyMDQyLzIwNDIvNzU4IGxvY2sgMi8yLzIpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzEzOTY2Lzc5OC8wICh0ZXN0czogcmVhZCAxNDMzNzEzOTY2
>Lzg3NS85IG54cmVhZCAxNDMzNzEzOTY2LzE0MzM3MTM5NjYvMzUwNiB0cnlleGNlcHQgMTQvMS8x
>IGZvcmsgMTQzMzcxMzk2Ni8xNDMzNzEzOTY2LzM2MyBmb3JrdG9vbXVjaCAxNDMzNzEzOTY2LzE0
>MzM3MTM5NjYvMTQzMzcxMzk2NiBhbGxvYyA0Mi8xNi80IGNyZWF0IDIwNzEvMjA3MS83ODcgbG9j
>ayA0LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM5OTEvODIzLzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTM5OTEvOTAwLzExIG54cmVhZCAxNDMzNzEzOTkxLzE0MzM3MTM5OTEv
>MzUzMSB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzEzOTkxLzE0MzM3MTM5OTEvMTAgZm9ya3Rv
>b211Y2ggMTQzMzcxMzk5MS8xNDMzNzEzOTkxLzE0MzM3MTM5OTEgYWxsb2MgNDEvMTEvNSBjcmVh
>dCAyMDk2LzIwOTYvMTEgbG9jayA0LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQwMTkvODUxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQwMTkvOTI4LzEwIG54cmVhZCAxNDMz
>NzE0MDE5LzE0MzM3MTQwMTkvMzU1OSB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzE0MDE5LzE0
>MzM3MTQwMTkvMTAgZm9ya3Rvb211Y2ggMTQzMzcxNDAxOS8xNDMzNzE0MDE5LzE0MzM3MTQwMTkg
>YWxsb2MgMzkvMTAvNSBjcmVhdCAyMTI0LzIxMjQvMzkgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTQwNDUvODY2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQwNDUv
>OTU0LzE0IG54cmVhZCAxNDMzNzE0MDQ1LzE0MzM3MTQwNDUvMzU4NSB0cnlleGNlcHQgNC8yLzEg
>Zm9yayAxNDMzNzE0MDQ1LzE0MzM3MTQwNDUvMzYgZm9ya3Rvb211Y2ggMTQzMzcxNDA0NS8xNDMz
>NzE0MDQ1LzE0MzM3MTQwNDUgYWxsb2MgMjYvOS81IGNyZWF0IDIxNTAvMjE1MC8yNiBsb2NrIDUv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDA3MS83MzgvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxNDA3MS85ODAvNDAgbnhyZWFkIDE0MzM3MTQwNzEvMTQzMzcxNDA3MS8zNjEx
>IHRyeWV4Y2VwdCAxOC8yLzAgZm9yayAxNDMzNzE0MDcxLzE0MzM3MTQwNzEvNjIgZm9ya3Rvb211
>Y2ggMTQzMzcxNDA3MS8xNDMzNzE0MDcxLzE0MzM3MTQwNzEgYWxsb2MgMzEvMTIvMSBjcmVhdCAy
>MTc2LzkwMy84IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0
>MTAwLzc2Ny8wICh0ZXN0czogcmVhZCAxNDMzNzE0MTAwLzEwMDkvMTEgbnhyZWFkIDE0MzM3MTQx
>MDAvMTQzMzcxNDEwMC8zNjQwIHRyeWV4Y2VwdCAzNC8yLzEgZm9yayAxNDMzNzE0MTAwLzE0MzM3
>MTQxMDAvMjUgZm9ya3Rvb211Y2ggMTQzMzcxNDEwMC8xNDMzNzE0MTAwLzE0MzM3MTQxMDAgYWxs
>b2MgMzAvOC80IGNyZWF0IDIyMDUvOTMyLzM3IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE0MTIwLzE0MC8wICh0ZXN0czogcmVhZCAxNDMzNzE0MTIwLzEwMjkv
>MTEgbnhyZWFkIDE0MzM3MTQxMjAvMTQzMzcxNDEyMC8zNjYwIHRyeWV4Y2VwdCAxOC8yLzEgZm9y
>ayAxNDMzNzE0MTIwLzE0MzM3MTQxMjAvNDUgZm9ya3Rvb211Y2ggMTQzMzcxNDEyMC8xNDMzNzE0
>MTIwLzE0MzM3MTQxMjAgYWxsb2MgMzEvMjQvNiBjcmVhdCAyMjI1LzE0MC8xMSBsb2NrIDYvNi8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDE0OS8xNjkvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNDE0OS8xMDU4LzE1IG54cmVhZCAxNDMzNzE0MTQ5LzE0MzM3MTQxNDkvMzY4OSB0
>cnlleGNlcHQgMTQvMi8xIGZvcmsgMTQzMzcxNDE0OS8xNDMzNzE0MTQ5Lzc0IGZvcmt0b29tdWNo
>IDE0MzM3MTQxNDkvMTQzMzcxNDE0OS8xNDMzNzE0MTQ5IGFsbG9jIDQ5LzIwLzcgY3JlYXQgMjI1
>NC8xNjkvNDAgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQx
>NzkvNzYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDE3OS8xMDg4LzEgbnhyZWFkIDE0MzM3MTQxNzkv
>MTQzMzcxNDE3OS8zNzE5IHRyeWV4Y2VwdCA4LzEvMCBmb3JrIDE0MzM3MTQxNzkvMTQzMzcxNDE3
>OS8xMDQgZm9ya3Rvb211Y2ggMTQzMzcxNDE3OS8xNDMzNzE0MTc5LzE0MzM3MTQxNzkgYWxsb2Mg
>MjUvNy8xIGNyZWF0IDE2MC8xOS8xOSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxNDIxNy8xMTQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDIxNy8xMTI2LzE1IG54
>cmVhZCAxNDMzNzE0MjE3LzE0MzM3MTQyMTcvMzc1NyB0cnlleGNlcHQgOS8xLzAgZm9yayAxNDMz
>NzE0MjE3LzE0MzM3MTQyMTcvMTQyIGZvcmt0b29tdWNoIDE0MzM3MTQyMTcvMTQzMzcxNDIxNy8x
>NDMzNzE0MjE3IGFsbG9jIDM5LzkvMiBjcmVhdCAxOTgvNTcvNTcgbG9jayAxLzEvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQyNTMvMTQ0LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTQyNTMvMTE2Mi82IG54cmVhZCAxNDMzNzE0MjUzLzE0MzM3MTQyNTMvMzc5MyB0cnlleGNlcHQg
>Ni8yLzEgZm9yayAxNDMzNzE0MjUzLzE0MzM3MTQyNTMvMTc4IGZvcmt0b29tdWNoIDE0MzM3MTQy
>NTMvMTQzMzcxNDI1My8xNDMzNzE0MjUzIGFsbG9jIDM4LzEyLzYgY3JlYXQgMjM0LzkzLzkzIGxv
>Y2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0MzY5LzI2MC8wICh0
>ZXN0czogcmVhZCAxNDMzNzE0MzY5LzEyNzgvMTUgbnhyZWFkIDE0MzM3MTQzNjkvMTQzMzcxNDM2
>OS8zOTA5IHRyeWV4Y2VwdCAxMy8yLzEgZm9yayAxNDMzNzE0MzY5LzE0MzM3MTQzNjkvMjk0IGZv
>cmt0b29tdWNoIDE0MzM3MTQzNjkvMTQzMzcxNDM2OS8xNDMzNzE0MzY5IGFsbG9jIDQ3LzE1LzUg
>Y3JlYXQgMzUwLzIwOS8yMDkgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTQzOTAvMjgxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQzOTAvMTI5OS8zIG54cmVhZCAx
>NDMzNzE0MzkwLzE0MzM3MTQzOTAvMzkzMCB0cnlleGNlcHQgMzQvMi8wIGZvcmsgMTQzMzcxNDM5
>MC8xNDMzNzE0MzkwLzMxNSBmb3JrdG9vbXVjaCAxNDMzNzE0MzkwLzE0MzM3MTQzOTAvMTQzMzcx
>NDM5MCBhbGxvYyAyNi8zLzEgY3JlYXQgMzcxLzIzMC8yMzAgbG9jayAwLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ0MzEvMzIyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ0
>MzEvMTM0MC8yMCBueHJlYWQgMTQzMzcxNDQzMS8xNDMzNzE0NDMxLzM5NzEgdHJ5ZXhjZXB0IDQz
>LzIvMSBmb3JrIDE0MzM3MTQ0MzEvMTQzMzcxNDQzMS8zNTYgZm9ya3Rvb211Y2ggMTQzMzcxNDQz
>MS8xNDMzNzE0NDMxLzE0MzM3MTQ0MzEgYWxsb2MgNDQvMTAvNSBjcmVhdCA0MTIvMjcxLzI3MSBs
>b2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDQ1Ni8zNDcvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxNDQ1Ni8xMzY1LzEyIG54cmVhZCAxNDMzNzE0NDU2LzE0MzM3MTQ0
>NTYvMzk5NiB0cnlleGNlcHQgNDEvMi8wIGZvcmsgMTQzMzcxNDQ1Ni8xNDMzNzE0NDU2LzM4MSBm
>b3JrdG9vbXVjaCAxNDMzNzE0NDU2LzE0MzM3MTQ0NTYvMTQzMzcxNDQ1NiBhbGxvYyAzMC84LzEg
>Y3JlYXQgNDM3LzI5Ni8yOTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTQ0NzYvMzY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ0NzYvMTM4NS81IG54cmVhZCAx
>NDMzNzE0NDc2LzE0MzM3MTQ0NzYvNDAxNiB0cnlleGNlcHQgMTYvMy8xIGZvcmsgMTQzMzcxNDQ3
>Ni8xNDMzNzE0NDc2LzQwMSBmb3JrdG9vbXVjaCAxNDMzNzE0NDc2LzE0MzM3MTQ0NzYvMTQzMzcx
>NDQ3NiBhbGxvYyAyOC85LzUgY3JlYXQgNDU3LzMxNi8zMTYgbG9jayA0LzQvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ1MTEvNDAyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ1
>MTEvMTQyMC8xOSBueHJlYWQgMTQzMzcxNDUxMS8xNDMzNzE0NTExLzQwNTEgdHJ5ZXhjZXB0IDIw
>LzEvMSBmb3JrIDE0MzM3MTQ1MTEvMTQzMzcxNDUxMS80MzYgZm9ya3Rvb211Y2ggMTQzMzcxNDUx
>MS8xNDMzNzE0NTExLzE0MzM3MTQ1MTEgYWxsb2MgNDQvOC8wIGNyZWF0IDQ5Mi8zNTEvMzUxIGxv
>Y2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0NTU0LzQ0NS8wICh0
>ZXN0czogcmVhZCAxNDMzNzE0NTU0LzE0NjMvMSBueHJlYWQgMTQzMzcxNDU1NC8xNDMzNzE0NTU0
>LzQwOTQgdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcxNDU1NC8xNDMzNzE0NTU0LzQ3OSBmb3Jr
>dG9vbXVjaCAxNDMzNzE0NTU0LzE0MzM3MTQ1NTQvMTQzMzcxNDU1NCBhbGxvYyA1Ni83LzEgY3Jl
>YXQgNTM1LzM5NC8zOTQgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQ1OTAvNDgxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ1OTAvMTQ5OS81IG54cmVhZCAxNDMz
>NzE0NTkwLzE0MzM3MTQ1OTAvNDEzMCB0cnlleGNlcHQgMTcvMS8xIGZvcmsgMTQzMzcxNDU5MC8x
>NDMzNzE0NTkwLzUxNSBmb3JrdG9vbXVjaCAxNDMzNzE0NTkwLzE0MzM3MTQ1OTAvMTQzMzcxNDU5
>MCBhbGxvYyAyNy8xNi8wIGNyZWF0IDU3MS80MzAvNDMwIGxvY2sgMy8zLzApCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzE0NjIyLzUxMy8wICh0ZXN0czogcmVhZCAxNDMzNzE0NjIy
>LzE1MzEvNiBueHJlYWQgMTQzMzcxNDYyMi8xNDMzNzE0NjIyLzQxNjIgdHJ5ZXhjZXB0IDE3LzMv
>MiBmb3JrIDE0MzM3MTQ2MjIvMTQzMzcxNDYyMi81NDcgZm9ya3Rvb211Y2ggMTQzMzcxNDYyMi8x
>NDMzNzE0NjIyLzE0MzM3MTQ2MjIgYWxsb2MgNDgvMTYvNiBjcmVhdCA2MDMvNDYyLzQ2MiBsb2Nr
>IDYvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDY0OS81NDAvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNDY0OS8xNTU4LzE0IG54cmVhZCAxNDMzNzE0NjQ5LzE0MzM3MTQ2NDkv
>NDE4OSB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE0NjQ5LzE0MzM3MTQ2NDkvNTc0IGZvcmt0
>b29tdWNoIDE0MzM3MTQ2NDkvMTQzMzcxNDY0OS8xNDMzNzE0NjQ5IGFsbG9jIDc1LzE0LzYgY3Jl
>YXQgNjMwLzQ4OS80ODkgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQ2NzgvNTY5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ2NzgvMTU4Ny8xIG54cmVhZCAxNDMz
>NzE0Njc4LzE0MzM3MTQ2NzgvNDIxOCB0cnlleGNlcHQgNS8zLzAgZm9yayAxNDMzNzE0Njc4LzE0
>MzM3MTQ2NzgvNjAzIGZvcmt0b29tdWNoIDE0MzM3MTQ2NzgvMTQzMzcxNDY3OC8xNDMzNzE0Njc4
>IGFsbG9jIDE4LzEvMSBjcmVhdCA2NTkvNTE4LzUxOCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDc2Ny82NTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDc2Ny8x
>NDY4LzEgbnhyZWFkIDE0MzM3MTQ3NjcvMTQzMzcxNDc2Ny80MzA3IHRyeWV4Y2VwdCA0LzIvMCBm
>b3JrIDE0MzM3MTQ3NjcvMTQzMzcxNDc2Ny82OTIgZm9ya3Rvb211Y2ggMTQzMzcxNDc2Ny8xNDMz
>NzE0NzY3LzE0MzM3MTQ3NjcgYWxsb2MgNDQvMy8xIGNyZWF0IDc0OC82MDcvNjA3IGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0ODA2LzY5Ny8wICh0ZXN0czog
>cmVhZCAxNDMzNzE0ODA2LzE1MDcvMjggbnhyZWFkIDE0MzM3MTQ4MDYvMTQzMzcxNDgwNi80MzQ2
>IHRyeWV4Y2VwdCAzNC8xLzEgZm9yayAxNDMzNzE0ODA2LzE0MzM3MTQ4MDYvNzMxIGZvcmt0b29t
>dWNoIDE0MzM3MTQ4MDYvMTQzMzcxNDgwNi8xNDMzNzE0ODA2IGFsbG9jIDQyLzEzLzQgY3JlYXQg
>Nzg3LzY0Ni82NDYgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTQ4MjcvNjY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ4MjcvMTQ5NC8xNSBueHJlYWQgMTQzMzcx
>NDgyNy8xNDMzNzE0ODI3LzQzNjcgdHJ5ZXhjZXB0IDQzLzMvMSBmb3JrIDE0MzM3MTQ4MjcvMTQz
>MzcxNDgyNy83NTIgZm9ya3Rvb211Y2ggMTQzMzcxNDgyNy8xNDMzNzE0ODI3LzE0MzM3MTQ4Mjcg
>YWxsb2MgNDkvMTEvNCBjcmVhdCA4MDgvNjY3LzY2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDg1My82OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDg1My8x
>NTIwLzEzIG54cmVhZCAxNDMzNzE0ODUzLzE0MzM3MTQ4NTMvNDM5MyB0cnlleGNlcHQgMzUvMi8w
>IGZvcmsgMTQzMzcxNDg1My8xNDMzNzE0ODUzLzc3OCBmb3JrdG9vbXVjaCAxNDMzNzE0ODUzLzE0
>MzM3MTQ4NTMvMTQzMzcxNDg1MyBhbGxvYyA3NS81LzEgY3JlYXQgODM0LzY5My82OTMgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ4OTUvNzM1LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTQ4OTUvMTU2Mi8xNSBueHJlYWQgMTQzMzcxNDg5NS8xNDMzNzE0ODk1LzQ0
>MzUgdHJ5ZXhjZXB0IDM4LzIvMSBmb3JrIDE0MzM3MTQ4OTUvMTQzMzcxNDg5NS84MjAgZm9ya3Rv
>b211Y2ggMTQzMzcxNDg5NS8xNDMzNzE0ODk1LzE0MzM3MTQ4OTUgYWxsb2MgNDMvMTUvNCBjcmVh
>dCA4NzYvNzM1LzczNSBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNDkzNy83NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDkzNy8xNjA0LzEgbnhyZWFkIDE0MzM3
>MTQ5MzcvMTQzMzcxNDkzNy80NDc3IHRyeWV4Y2VwdCA1NC8zLzAgZm9yayAxNDMzNzE0OTM3LzE0
>MzM3MTQ5MzcvODYyIGZvcmt0b29tdWNoIDE0MzM3MTQ5MzcvMTQzMzcxNDkzNy8xNDMzNzE0OTM3
>IGFsbG9jIDQ2LzEwLzEgY3JlYXQgOTE4Lzc3Ny83NzcgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTQ5NzYvODE2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ5NzYv
>MTY0My82IG54cmVhZCAxNDMzNzE0OTc2LzE0MzM3MTQ5NzYvNDUxNiB0cnlleGNlcHQgNS8yLzEg
>Zm9yayAxNDMzNzE0OTc2LzE0MzM3MTQ5NzYvOTAxIGZvcmt0b29tdWNoIDE0MzM3MTQ5NzYvMTQz
>MzcxNDk3Ni8xNDMzNzE0OTc2IGFsbG9jIDg1LzIxLzAgY3JlYXQgOTU3LzgxNi84MTYgbG9jayA1
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTUwMDAvODQwLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTUwMDAvMTY2Ny81IG54cmVhZCAxNDMzNzE1MDAwLzE0MzM3MTUwMDAvNDU0
>MCB0cnlleGNlcHQgMjAvMi8xIGZvcmsgMTQzMzcxNTAwMC8xNDMzNzE1MDAwLzkyNSBmb3JrdG9v
>bXVjaCAxNDMzNzE1MDAwLzE0MzM3MTUwMDAvMTQzMzcxNTAwMCBhbGxvYyA0MS85LzAgY3JlYXQg
>OTgxLzg0MC84NDAgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTUwMjcvODY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUwMjcvMTY5NC8xIG54cmVhZCAxNDMzNzE1
>MDI3LzE0MzM3MTUwMjcvNDU2NyB0cnlleGNlcHQgNDUvMC8wIGZvcmsgMTQzMzcxNTAyNy8xNDMz
>NzE1MDI3Lzk1MiBmb3JrdG9vbXVjaCAxNDMzNzE1MDI3LzE0MzM3MTUwMjcvMTQzMzcxNTAyNyBh
>bGxvYyA0Ni8xMC8xIGNyZWF0IDEwMDgvODY3Lzg2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTA1Mi84OTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTA1Mi8x
>NzE5LzUgbnhyZWFkIDE0MzM3MTUwNTIvMTQzMzcxNTA1Mi80NTkyIHRyeWV4Y2VwdCAzLzIvMCBm
>b3JrIDE0MzM3MTUwNTIvMTQzMzcxNTA1Mi85NzcgZm9ya3Rvb211Y2ggMTQzMzcxNTA1Mi8xNDMz
>NzE1MDUyLzE0MzM3MTUwNTIgYWxsb2MgMjIvMS8xIGNyZWF0IDEwMzMvODkyLzg5MiBsb2NrIDEv
>MS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTA4NS85MjUvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxNTA4NS8xNzUyLzIgbnhyZWFkIDE0MzM3MTUwODUvMTQzMzcxNTA4NS80NjI1
>IHRyeWV4Y2VwdCAxMC8xLzEgZm9yayAxNDMzNzE1MDg1LzE0MzM3MTUwODUvMTAxMCBmb3JrdG9v
>bXVjaCAxNDMzNzE1MDg1LzE0MzM3MTUwODUvMTQzMzcxNTA4NSBhbGxvYyA0My8xMS8yIGNyZWF0
>IDEwNjYvOTI1LzkyNSBsb2NrIDIvMi8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNTEyNy85NjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTEyNy8xNzk0LzM4IG54cmVhZCAxNDMz
>NzE1MTI3LzE0MzM3MTUxMjcvNDY2NyB0cnlleGNlcHQgNTIvNC8wIGZvcmsgMTQzMzcxNTEyNy8x
>NDMzNzE1MTI3LzEwNTIgZm9ya3Rvb211Y2ggMTQzMzcxNTEyNy8xNDMzNzE1MTI3LzE0MzM3MTUx
>MjcgYWxsb2MgMjcvOC8zIGNyZWF0IDExMDgvOTY3Lzk2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTE2Ny8xMDA3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUx
>NjcvMTgzNC8xMSBueHJlYWQgMTQzMzcxNTE2Ny8xNDMzNzE1MTY3LzQ3MDcgdHJ5ZXhjZXB0IDU2
>LzUvMSBmb3JrIDE0MzM3MTUxNjcvMTQzMzcxNTE2Ny8xMDkyIGZvcmt0b29tdWNoIDE0MzM3MTUx
>NjcvMTQzMzcxNTE2Ny8xNDMzNzE1MTY3IGFsbG9jIDU5LzEzLzQgY3JlYXQgMTE0OC8xMDA3LzEw
>MDcgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTUyMzYvMTA3
>Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE1MjM2LzE5MDMvMyBueHJlYWQgMTQzMzcxNTIzNi8xNDMz
>NzE1MjM2LzQ3NzYgdHJ5ZXhjZXB0IDUwLzIvMSBmb3JrIDE0MzM3MTUyMzYvMTQzMzcxNTIzNi8x
>NyBmb3JrdG9vbXVjaCAxNDMzNzE1MjM2LzE0MzM3MTUyMzYvMTQzMzcxNTIzNiBhbGxvYyA1Mi85
>LzMgY3JlYXQgMTIxNy8xMDc2LzEwNzYgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTUyNTgvMTA5OC8wICh0ZXN0czogcmVhZCAxNDMzNzE1MjU4LzE5MjUvOCBu
>eHJlYWQgMTQzMzcxNTI1OC8xNDMzNzE1MjU4LzQ3OTggdHJ5ZXhjZXB0IDMwLzMvMCBmb3JrIDE0
>MzM3MTUyNTgvMTQzMzcxNTI1OC8yMSBmb3JrdG9vbXVjaCAxNDMzNzE1MjU4LzE0MzM3MTUyNTgv
>MTQzMzcxNTI1OCBhbGxvYyA0OS8xMi8yIGNyZWF0IDEyMzkvMTA5OC8xMDk4IGxvY2sgMS8xLzEp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1Mjk2LzExMzYvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNTI5Ni8xOTYzLzEyIG54cmVhZCAxNDMzNzE1Mjk2LzE0MzM3MTUyOTYvNDgzNiB0
>cnlleGNlcHQgNi8yLzIgZm9yayAxNDMzNzE1Mjk2LzE0MzM3MTUyOTYvNTkgZm9ya3Rvb211Y2gg
>MTQzMzcxNTI5Ni8xNDMzNzE1Mjk2LzE0MzM3MTUyOTYgYWxsb2MgNDYvNy83IGNyZWF0IDEyNzcv
>MTEzNi8xMTM2IGxvY2sgNy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1
>MzI2LzExNjYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTMyNi8xOTkzLzE5IG54cmVhZCAxNDMzNzE1
>MzI2LzE0MzM3MTUzMjYvNDg2NiB0cnlleGNlcHQgNy8yLzEgZm9yayAxNDMzNzE1MzI2LzE0MzM3
>MTUzMjYvODkgZm9ya3Rvb211Y2ggMTQzMzcxNTMyNi8xNDMzNzE1MzI2LzE0MzM3MTUzMjYgYWxs
>b2MgMzcvMTAvNiBjcmVhdCAxMzA3LzExNjYvMTE2NiBsb2NrIDYvNi8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTM0OS8xMTg5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUzNDkv
>MjAxNi8yMyBueHJlYWQgMTQzMzcxNTM0OS8xNDMzNzE1MzQ5LzQ4ODkgdHJ5ZXhjZXB0IDMwLzEv
>MSBmb3JrIDE0MzM3MTUzNDkvMTQzMzcxNTM0OS8xMTIgZm9ya3Rvb211Y2ggMTQzMzcxNTM0OS8x
>NDMzNzE1MzQ5LzE0MzM3MTUzNDkgYWxsb2MgMjkvMTAvNSBjcmVhdCAxMzMwLzExODkvMTE4OSBs
>b2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTM4NS8xMjI1LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTUzODUvMjA1Mi83IG54cmVhZCAxNDMzNzE1Mzg1LzE0MzM3MTUz
>ODUvNDkyNSB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzE1Mzg1LzE0MzM3MTUzODUvMTQ4IGZv
>cmt0b29tdWNoIDE0MzM3MTUzODUvMTQzMzcxNTM4NS8xNDMzNzE1Mzg1IGFsbG9jIDM2LzcvNyBj
>cmVhdCAxMzY2LzEyMjUvMTIyNSBsb2NrIDcvNy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxNTQxMS8xMjUxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTU0MTEvMjA3OC8xIG54cmVh
>ZCAxNDMzNzE1NDExLzE0MzM3MTU0MTEvNDk1MSB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE1
>NDExLzE0MzM3MTU0MTEvMTc0IGZvcmt0b29tdWNoIDE0MzM3MTU0MTEvMTQzMzcxNTQxMS8xNDMz
>NzE1NDExIGFsbG9jIDM4LzkvMSBjcmVhdCAxMzkyLzEyNTEvMTI1MSBsb2NrIDEvMS8xKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTQ0Ni8xMjg2LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTU0NDYvMjExMy8xIG54cmVhZCAxNDMzNzE1NDQ2LzE0MzM3MTU0NDYvNDk4NiB0cnlleGNl
>cHQgNC8wLzAgZm9yayAxNDMzNzE1NDQ2LzE0MzM3MTU0NDYvMjA5IGZvcmt0b29tdWNoIDE0MzM3
>MTU0NDYvMTQzMzcxNTQ0Ni8xNDMzNzE1NDQ2IGFsbG9jIDM2LzE1LzEgY3JlYXQgMTQyNy8xMjg2
>LzEyODYgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTU0NzAv
>MTMxMC8wICh0ZXN0czogcmVhZCAxNDMzNzE1NDcwLzIxMzcvNCBueHJlYWQgMTQzMzcxNTQ3MC8x
>NDMzNzE1NDcwLzUwMTAgdHJ5ZXhjZXB0IDIxLzIvMSBmb3JrIDE0MzM3MTU0NzAvMTQzMzcxNTQ3
>MC8yMzMgZm9ya3Rvb211Y2ggMTQzMzcxNTQ3MC8xNDMzNzE1NDcwLzE0MzM3MTU0NzAgYWxsb2Mg
>MjUvNy8wIGNyZWF0IDE0NTEvMTMxMC8xMzEwIGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE1NDk4LzEzMzgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTQ5OC8yMTY1
>LzIzIG54cmVhZCAxNDMzNzE1NDk4LzE0MzM3MTU0OTgvNTAzOCB0cnlleGNlcHQgMjQvMi8xIGZv
>cmsgMTQzMzcxNTQ5OC8xNDMzNzE1NDk4LzI2MSBmb3JrdG9vbXVjaCAxNDMzNzE1NDk4LzE0MzM3
>MTU0OTgvMTQzMzcxNTQ5OCBhbGxvYyAzNS8xNi80IGNyZWF0IDE0NzkvMTMzOC8xMzM4IGxvY2sg
>NC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NTM0LzEzNzQvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNTUzNC8yMjAxLzEgbnhyZWFkIDE0MzM3MTU1MzQvMTQzMzcxNTUzNC81
>MDc0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTU1MzQvMTQzMzcxNTUzNC8yOTcgZm9ya3Rv
>b211Y2ggMTQzMzcxNTUzNC8xNDMzNzE1NTM0LzE0MzM3MTU1MzQgYWxsb2MgNTIvNi8xIGNyZWF0
>IDE1MTUvMTM3NC8xMzc0IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE1NTU2LzEzOTYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTU1Ni8yMjIzLzEwIG54cmVhZCAx
>NDMzNzE1NTU2LzE0MzM3MTU1NTYvNTA5NiB0cnlleGNlcHQgMjAvMS8wIGZvcmsgMTQzMzcxNTU1
>Ni8xNDMzNzE1NTU2LzMxOSBmb3JrdG9vbXVjaCAxNDMzNzE1NTU2LzE0MzM3MTU1NTYvMTQzMzcx
>NTU1NiBhbGxvYyAyOC8xMC8yIGNyZWF0IDE1MzcvMTM5Ni8xMzk2IGxvY2sgMi8yLzIpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NTgwLzE0MjAvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNTU4MC8yMjQ3LzkgbnhyZWFkIDE0MzM3MTU1ODAvMTQzMzcxNTU4MC8xIHRyeWV4Y2VwdCAx
>NC8yLzAgZm9yayAxNDMzNzE1NTgwLzE0MzM3MTU1ODAvMzQzIGZvcmt0b29tdWNoIDE0MzM3MTU1
>ODAvMTQzMzcxNTU4MC8xNDMzNzE1NTgwIGFsbG9jIDI2LzkvMSBjcmVhdCAxNTYxLzE0MjAvMTQy
>MCBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTY0MC8xNDgw
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTU2NDAvMjMwNy8yIG54cmVhZCAxNDMzNzE1NjQwLzE0MzM3
>MTU2NDAvNjEgdHJ5ZXhjZXB0IDYvMy8wIGZvcmsgMTQzMzcxNTY0MC8xNDMzNzE1NjQwLzQwMyBm
>b3JrdG9vbXVjaCAxNDMzNzE1NjQwLzE0MzM3MTU2NDAvMTQzMzcxNTY0MCBhbGxvYyAyMi8xMC8y
>IGNyZWF0IDE2MjEvMTQ4MC8xNDgwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzE1NjgwLzE1MjAvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTY4MC8yMzQ3LzEzIG54
>cmVhZCAxNDMzNzE1NjgwLzE0MzM3MTU2ODAvMTAxIHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3
>MTU2ODAvMTQzMzcxNTY4MC80NDMgZm9ya3Rvb211Y2ggMTQzMzcxNTY4MC8xNDMzNzE1NjgwLzE0
>MzM3MTU2ODAgYWxsb2MgMjYvNy8yIGNyZWF0IDE2NjEvMTUyMC8xNTIwIGxvY2sgMi8yLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NzQ0LzE1ODQvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNTc0NC8yNDExLzEyIG54cmVhZCAxNDMzNzE1NzQ0LzE0MzM3MTU3NDQvMTY1IHRyeWV4
>Y2VwdCA2LzMvMCBmb3JrIDE0MzM3MTU3NDQvMTQzMzcxNTc0NC81MDcgZm9ya3Rvb211Y2ggMTQz
>MzcxNTc0NC8xNDMzNzE1NzQ0LzE0MzM3MTU3NDQgYWxsb2MgMjgvNy81IGNyZWF0IDE3MjUvMTU4
>NC8xNTg0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1Nzk5
>LzE2MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTc5OS8yNDY2LzM3IG54cmVhZCAxNDMzNzE1Nzk5
>LzE0MzM3MTU3OTkvMjIwIHRyeWV4Y2VwdCAzMC8yLzEgZm9yayAxNDMzNzE1Nzk5LzE0MzM3MTU3
>OTkvNTYyIGZvcmt0b29tdWNoIDE0MzM3MTU3OTkvMTQzMzcxNTc5OS8xNDMzNzE1Nzk5IGFsbG9j
>IDUyLzIwLzAgY3JlYXQgMTc4MC8xNjM5LzE2MzkgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTU4MzAvMTY3MC8wICh0ZXN0czogcmVhZCAxNDMzNzE1ODMwLzI0
>OTcvNSBueHJlYWQgMTQzMzcxNTgzMC8xNDMzNzE1ODMwLzI1MSB0cnlleGNlcHQgNS8yLzAgZm9y
>ayAxNDMzNzE1ODMwLzE0MzM3MTU4MzAvNTkzIGZvcmt0b29tdWNoIDE0MzM3MTU4MzAvMTQzMzcx
>NTgzMC8xNDMzNzE1ODMwIGFsbG9jIDQxLzExLzEgY3JlYXQgMTgxMS8xNjcwLzE2NzAgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTU4ODMvMTcyMy8wICh0ZXN0
>czogcmVhZCAxNDMzNzE1ODgzLzI1NTAvMTEgbnhyZWFkIDE0MzM3MTU4ODMvMTQzMzcxNTg4My8z
>MDQgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQzMzcxNTg4My8xNDMzNzE1ODgzLzY0NiBmb3JrdG9v
>bXVjaCAxNDMzNzE1ODgzLzE0MzM3MTU4ODMvMTQzMzcxNTg4MyBhbGxvYyA0Mi8xNy82IGNyZWF0
>IDE4NjQvMTcyMy8xNzIzIGxvY2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE1OTEzLzE3NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTkxMy8yNTgwLzEwIG54cmVhZCAx
>NDMzNzE1OTEzLzE0MzM3MTU5MTMvMzM0IHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0MzM3MTU5MTMv
>MTQzMzcxNTkxMy82NzYgZm9ya3Rvb211Y2ggMTQzMzcxNTkxMy8xNDMzNzE1OTEzLzE0MzM3MTU5
>MTMgYWxsb2MgMjAvMTAvNyBjcmVhdCAxODk0LzE3NTMvMTc1MyBsb2NrIDYvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTkzNy8xNzc3LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTU5MzcvMjYwNC8yNCBueHJlYWQgMTQzMzcxNTkzNy8xNDMzNzE1OTM3LzM1OCB0cnlleGNlcHQg
>MTAvMi8xIGZvcmsgMTQzMzcxNTkzNy8xNDMzNzE1OTM3LzcwMCBmb3JrdG9vbXVjaCAxNDMzNzE1
>OTM3LzE0MzM3MTU5MzcvMTQzMzcxNTkzNyBhbGxvYyAzOS8yNC85IGNyZWF0IDE5MTgvMTc3Ny8x
>Nzc3IGxvY2sgOS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1OTYzLzE4
>MDMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTk2My8yNjMwLzEyIG54cmVhZCAxNDMzNzE1OTYzLzE0
>MzM3MTU5NjMvMzg0IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MTU5NjMvMTQzMzcxNTk2My83
>MjYgZm9ya3Rvb211Y2ggMTQzMzcxNTk2My8xNDMzNzE1OTYzLzE0MzM3MTU5NjMgYWxsb2MgNjAv
>MTgvMyBjcmVhdCAxOTQ0LzE4MDMvMTgwMyBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxNTk5Ny8xODM3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTU5OTcvMjY2NC8x
>IG54cmVhZCAxNDMzNzE1OTk3LzE0MzM3MTU5OTcvNDE4IHRyeWV4Y2VwdCAzNS8yLzAgZm9yayAx
>NDMzNzE1OTk3LzE0MzM3MTU5OTcvNzYwIGZvcmt0b29tdWNoIDE0MzM3MTU5OTcvMTQzMzcxNTk5
>Ny8xNDMzNzE1OTk3IGFsbG9jIDM0LzEwLzEgY3JlYXQgMTk3OC8xODM3LzE4MzcgbG9jayAxLzEv
>MSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYwMjcvMTg2Ny8wICh0ZXN0czog
>cmVhZCAxNDMzNzE2MDI3LzI2OTQvNyBueHJlYWQgMTQzMzcxNjAyNy8xNDMzNzE2MDI3LzQ0OCB0
>cnlleGNlcHQgOC8yLzAgZm9yayAxNDMzNzE2MDI3LzE0MzM3MTYwMjcvNzkwIGZvcmt0b29tdWNo
>IDE0MzM3MTYwMjcvMTQzMzcxNjAyNy8xNDMzNzE2MDI3IGFsbG9jIDQ1LzEyLzEgY3JlYXQgMjAw
>OC8xODY3LzE4NjcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTYwNTYvMTg5Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE2MDU2LzI3MjMvNSBueHJlYWQgMTQzMzcx
>NjA1Ni8xNDMzNzE2MDU2LzQ3NyB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzE2MDU2LzE0MzM3
>MTYwNTYvODE5IGZvcmt0b29tdWNoIDE0MzM3MTYwNTYvMTQzMzcxNjA1Ni8xNDMzNzE2MDU2IGFs
>bG9jIDUxLzEwLzUgY3JlYXQgMjAzNy8xODk2LzE4OTYgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTYwODkvMTkyOS8wICh0ZXN0czogcmVhZCAxNDMzNzE2MDg5
>LzI3NTYvMjcgbnhyZWFkIDE0MzM3MTYwODkvMTQzMzcxNjA4OS81MTAgdHJ5ZXhjZXB0IDE5LzEv
>MSBmb3JrIDE0MzM3MTYwODkvMTQzMzcxNjA4OS84NTIgZm9ya3Rvb211Y2ggMTQzMzcxNjA4OS8x
>NDMzNzE2MDg5LzE0MzM3MTYwODkgYWxsb2MgNDMvMTgvMCBjcmVhdCAyMDcwLzE5MjkvMTkyOSBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjEwOS8xOTQ5LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTYxMDkvMjc3Ni80NyBueHJlYWQgMTQzMzcxNjEwOS8xNDMzNzE2
>MTA5LzUzMCB0cnlleGNlcHQgMzkvMC8wIGZvcmsgMTQzMzcxNjEwOS8xNDMzNzE2MTA5Lzg3MiBm
>b3JrdG9vbXVjaCAxNDMzNzE2MTA5LzE0MzM3MTYxMDkvMTQzMzcxNjEwOSBhbGxvYyAyMC8xMy8y
>IGNyZWF0IDIwOTAvMTk0OS8xOTQ5IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzE2MTMyLzE5NzIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjEzMi8yNzk5LzEgbnhy
>ZWFkIDE0MzM3MTYxMzIvMTQzMzcxNjEzMi81NTMgdHJ5ZXhjZXB0IDMvMi8wIGZvcmsgMTQzMzcx
>NjEzMi8xNDMzNzE2MTMyLzg5NSBmb3JrdG9vbXVjaCAxNDMzNzE2MTMyLzE0MzM3MTYxMzIvMTQz
>MzcxNjEzMiBhbGxvYyAyMC82LzEgY3JlYXQgMjExMy8xOTcyLzE5NzIgbG9jayAxLzEvMSkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYxNjEvMjAwMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzE2MTYxLzI4MjgvOSBueHJlYWQgMTQzMzcxNjE2MS8xNDMzNzE2MTYxLzU4MiB0cnlleGNl
>cHQgNS8yLzEgZm9yayAxNDMzNzE2MTYxLzE0MzM3MTYxNjEvOTI0IGZvcmt0b29tdWNoIDE0MzM3
>MTYxNjEvMTQzMzcxNjE2MS8xNDMzNzE2MTYxIGFsbG9jIDM1LzE0LzYgY3JlYXQgMjE0Mi8yMDAx
>LzIwMDEgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYxODcv
>MjAyNy8wICh0ZXN0czogcmVhZCAxNDMzNzE2MTg3LzI4NTQvNSBueHJlYWQgMTQzMzcxNjE4Ny8x
>NDMzNzE2MTg3LzYwOCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE2MTg3LzE0MzM3MTYxODcv
>OTUwIGZvcmt0b29tdWNoIDE0MzM3MTYxODcvMTQzMzcxNjE4Ny8xNDMzNzE2MTg3IGFsbG9jIDQ1
>LzEvMSBjcmVhdCAyMTY4LzIwMjcvMjAyNyBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxNjIyMS8yMDYxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTYyMjEvMjg4OC8z
>IG54cmVhZCAxNDMzNzE2MjIxLzE0MzM3MTYyMjEvNjQyIHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0
>MzM3MTYyMjEvMTQzMzcxNjIyMS85ODQgZm9ya3Rvb211Y2ggMTQzMzcxNjIyMS8xNDMzNzE2MjIx
>LzE0MzM3MTYyMjEgYWxsb2MgNzkvOS8zIGNyZWF0IDIyMDIvMjA2MS8yMDYxIGxvY2sgMy8zLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2MjQ1LzIwODUvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNjI0NS8yOTEyLzEgbnhyZWFkIDE0MzM3MTYyNDUvMTQzMzcxNjI0NS82NjYgdHJ5
>ZXhjZXB0IDI1LzIvMCBmb3JrIDE0MzM3MTYyNDUvMTQzMzcxNjI0NS8xMDA4IGZvcmt0b29tdWNo
>IDE0MzM3MTYyNDUvMTQzMzcxNjI0NS8xNDMzNzE2MjQ1IGFsbG9jIDUzLzE0LzEgY3JlYXQgMjIy
>Ni8yMDg1LzIwODUgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTYyODMvMjEyMy8wICh0ZXN0czogcmVhZCAxNDMzNzE2MjgzLzI5NTAvMjIgbnhyZWFkIDE0MzM3
>MTYyODMvMTQzMzcxNjI4My83MDQgdHJ5ZXhjZXB0IDQ5LzMvMCBmb3JrIDE0MzM3MTYyODMvMTQz
>MzcxNjI4My8xMDQ2IGZvcmt0b29tdWNoIDE0MzM3MTYyODMvMTQzMzcxNjI4My8xNDMzNzE2Mjgz
>IGFsbG9jIDMxLzkvMSBjcmVhdCAyMjY0LzIxMjMvMjEyMyBsb2NrIDEvMS8xKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjMxMi8yMTUyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTYz
>MTIvMjk3OS81MSBueHJlYWQgMTQzMzcxNjMxMi8xNDMzNzE2MzEyLzczMyB0cnlleGNlcHQgMjMv
>MS8xIGZvcmsgMTQzMzcxNjMxMi8xNDMzNzE2MzEyLzEyIGZvcmt0b29tdWNoIDE0MzM3MTYzMTIv
>MTQzMzcxNjMxMi8xNDMzNzE2MzEyIGFsbG9jIDM4LzkvNCBjcmVhdCAyMjkzLzIxNTIvMjE1MiBs
>b2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjM0MS8yMTgxLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTYzNDEvMzAwOC81IG54cmVhZCAxNDMzNzE2MzQxLzE0MzM3MTYz
>NDEvNzYyIHRyeWV4Y2VwdCA0LzIvMiBmb3JrIDE0MzM3MTYzNDEvMTQzMzcxNjM0MS8yNyBmb3Jr
>dG9vbXVjaCAxNDMzNzE2MzQxLzE0MzM3MTYzNDEvMTQzMzcxNjM0MSBhbGxvYyA0Mi8xMS81IGNy
>ZWF0IDIzMjIvMjE4MS8xMSBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxNjM3Ni8yMjE2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTYzNzYvMzA0My8yNCBueHJlYWQg
>MTQzMzcxNjM3Ni8xNDMzNzE2Mzc2Lzc5NyB0cnlleGNlcHQgNS8yLzIgZm9yayAxNDMzNzE2Mzc2
>LzE0MzM3MTYzNzYvNjIgZm9ya3Rvb211Y2ggMTQzMzcxNjM3Ni8xNDMzNzE2Mzc2LzE0MzM3MTYz
>NzYgYWxsb2MgNzcvMTEvNiBjcmVhdCAyMzU3LzIyMTYvNDYgbG9jayA1LzUvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY0MDYvMjI0Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE2
>NDA2LzMwNzMvNSBueHJlYWQgMTQzMzcxNjQwNi8xNDMzNzE2NDA2LzgyNyB0cnlleGNlcHQgNC8y
>LzIgZm9yayAxNDMzNzE2NDA2LzE0MzM3MTY0MDYvOTIgZm9ya3Rvb211Y2ggMTQzMzcxNjQwNi8x
>NDMzNzE2NDA2LzE0MzM3MTY0MDYgYWxsb2MgMTA3LzEwLzUgY3JlYXQgMjM4Ny8yMjQ2Lzc2IGxv
>Y2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NDI5LzIyNjkvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxNjQyOS8zMDk2LzIgbnhyZWFkIDE0MzM3MTY0MjkvMTQzMzcxNjQy
>OS84NTAgdHJ5ZXhjZXB0IDIvMi8xIGZvcmsgMTQzMzcxNjQyOS8xNDMzNzE2NDI5LzExNSBmb3Jr
>dG9vbXVjaCAxNDMzNzE2NDI5LzE0MzM3MTY0MjkvMTQzMzcxNjQyOSBhbGxvYyA0MS83LzIgY3Jl
>YXQgMjQxMC8yMjY5Lzk5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE2NDczLzIzMTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjQ3My8zMTQwLzM1IG54cmVhZCAx
>NDMzNzE2NDczLzE0MzM3MTY0NzMvODk0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTY0NzMv
>MTQzMzcxNjQ3My8xNTkgZm9ya3Rvb211Y2ggMTQzMzcxNjQ3My8xNDMzNzE2NDczLzE0MzM3MTY0
>NzMgYWxsb2MgNzcvMTIvMSBjcmVhdCAyNDU0LzIzMTMvMTQzIGxvY2sgMS8xLzEpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NTAwLzIzNDAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>NjUwMC8zMTY3LzQgbnhyZWFkIDE0MzM3MTY1MDAvMTQzMzcxNjUwMC85MjEgdHJ5ZXhjZXB0IDcv
>NS8xIGZvcmsgMTQzMzcxNjUwMC8xNDMzNzE2NTAwLzE4NiBmb3JrdG9vbXVjaCAxNDMzNzE2NTAw
>LzE0MzM3MTY1MDAvMTQzMzcxNjUwMCBhbGxvYyAyMy82LzAgY3JlYXQgMjQ4MS8yMzQwLzE3MCBs
>b2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjUyNi8yMzY2LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTY1MjYvMTc2OC8xIG54cmVhZCAxNDMzNzE2NTI2LzE0MzM3MTY1
>MjYvOTQ3IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAxNDMzNzE2NTI2LzE0MzM3MTY1MjYvMjEyIGZv
>cmt0b29tdWNoIDE0MzM3MTY1MjYvMTQzMzcxNjUyNi8xNDMzNzE2NTI2IGFsbG9jIDMyLzIxLzEg
>Y3JlYXQgMjUwNy8yMzY2LzE5NiBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxNjU2OS8yNDA5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY1NjkvMTgxMS8xOCBueHJl
>YWQgMTQzMzcxNjU2OS8xNDMzNzE2NTY5Lzk5MCB0cnlleGNlcHQgMTkvMTAvMSBmb3JrIDE0MzM3
>MTY1NjkvMTQzMzcxNjU2OS8yNTUgZm9ya3Rvb211Y2ggMTQzMzcxNjU2OS8xNDMzNzE2NTY5LzE0
>MzM3MTY1NjkgYWxsb2MgMzQvMTYvNCBjcmVhdCAyNTUwLzI0MDkvMjM5IGxvY2sgNC80LzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NTkwLzI0MzAvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNjU5MC8xODMyLzIwIG54cmVhZCAxNDMzNzE2NTkwLzE0MzM3MTY1OTAvMTAxMSB0cnll
>eGNlcHQgNDAvNC8xIGZvcmsgMTQzMzcxNjU5MC8xNDMzNzE2NTkwLzI3NiBmb3JrdG9vbXVjaCAx
>NDMzNzE2NTkwLzE0MzM3MTY1OTAvMTQzMzcxNjU5MCBhbGxvYyA0NS8yMC8zIGNyZWF0IDI1NzEv
>MjQzMC8yNjAgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY2
>MDgvMjQ0OC8wICh0ZXN0czogcmVhZCAxNDMzNzE2NjA4LzE4NTAvMTggbnhyZWFkIDE0MzM3MTY2
>MDgvMTQzMzcxNjYwOC8xMDI5IHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzE2NjA4LzE0MzM3
>MTY2MDgvMjk0IGZvcmt0b29tdWNoIDE0MzM3MTY2MDgvMTQzMzcxNjYwOC8xNDMzNzE2NjA4IGFs
>bG9jIDUwLzE3LzUgY3JlYXQgMjU4OS8yNDQ4LzI3OCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjYzOC8yNDc4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY2Mzgv
>MTg4MC82IG54cmVhZCAxNDMzNzE2NjM4LzE0MzM3MTY2MzgvMTA1OSB0cnlleGNlcHQgMy8yLzAg
>Zm9yayAxNDMzNzE2NjM4LzE0MzM3MTY2MzgvMzI0IGZvcmt0b29tdWNoIDE0MzM3MTY2MzgvMTQz
>MzcxNjYzOC8xNDMzNzE2NjM4IGFsbG9jIDQ3LzYvMSBjcmVhdCAyNjE5LzI0NzgvMzA4IGxvY2sg
>MC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2Njc2LzI1MTYvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNjY3Ni8xOTE4LzkgbnhyZWFkIDE0MzM3MTY2NzYvMTQzMzcxNjY3Ni8x
>MDk3IHRyeWV4Y2VwdCAyLzEvMSBmb3JrIDE0MzM3MTY2NzYvMTQzMzcxNjY3Ni8zNjIgZm9ya3Rv
>b211Y2ggMTQzMzcxNjY3Ni8xNDMzNzE2Njc2LzE0MzM3MTY2NzYgYWxsb2MgMjkvMi8yIGNyZWF0
>IDI2NTcvMjUxNi8zNDYgbG9jayAyLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTY3MDMvMjU0My8wICh0ZXN0czogcmVhZCAxNDMzNzE2NzAzLzE5NDUvMjEgbnhyZWFkIDE0
>MzM3MTY3MDMvMTQzMzcxNjcwMy8xMTI0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTY3MDMv
>MTQzMzcxNjcwMy8zODkgZm9ya3Rvb211Y2ggMTQzMzcxNjcwMy8xNDMzNzE2NzAzLzE0MzM3MTY3
>MDMgYWxsb2MgNDUvMy8yIGNyZWF0IDI2ODQvMjU0My8zNzMgbG9jayAyLzIvMSkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY3MzIvMjU3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE2
>NzMyLzE5NzQvNCBueHJlYWQgMTQzMzcxNjczMi8xNDMzNzE2NzMyLzExNTMgdHJ5ZXhjZXB0IDEy
>LzEvMSBmb3JrIDE0MzM3MTY3MzIvMTQzMzcxNjczMi80MTggZm9ya3Rvb211Y2ggMTQzMzcxNjcz
>Mi8xNDMzNzE2NzMyLzE0MzM3MTY3MzIgYWxsb2MgNzQvMTMvNCBjcmVhdCAyNzEzLzI1NzIvNDAy
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NzYxLzI2MDEv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxNjc2MS8yMDAzLzE3IG54cmVhZCAxNDMzNzE2NzYxLzE0MzM3
>MTY3NjEvMTE4MiB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE2NzYxLzE0MzM3MTY3NjEvNDQ3
>IGZvcmt0b29tdWNoIDE0MzM3MTY3NjEvMTQzMzcxNjc2MS8xNDMzNzE2NzYxIGFsbG9jIDEwMy82
>LzEgY3JlYXQgMjc0Mi8yNjAxLzQzMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxNjc4NS8yNjI1LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY3ODUvMjAyNy83IG54
>cmVhZCAxNDMzNzE2Nzg1LzE0MzM3MTY3ODUvMTIwNiB0cnlleGNlcHQgOC8yLzAgZm9yayAxNDMz
>NzE2Nzg1LzE0MzM3MTY3ODUvNDcxIGZvcmt0b29tdWNoIDE0MzM3MTY3ODUvMTQzMzcxNjc4NS8x
>NDMzNzE2Nzg1IGFsbG9jIDg1LzkvMSBjcmVhdCAyNzY2LzI2MjUvNDU1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2ODEwLzI2NTAvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNjgxMC8yMDUyLzYgbnhyZWFkIDE0MzM3MTY4MTAvMTQzMzcxNjgxMC8xMjMxIHRyeWV4
>Y2VwdCAzMy8yLzEgZm9yayAxNDMzNzE2ODEwLzE0MzM3MTY4MTAvNDk2IGZvcmt0b29tdWNoIDE0
>MzM3MTY4MTAvMTQzMzcxNjgxMC8xNDMzNzE2ODEwIGFsbG9jIDM0LzIxLzYgY3JlYXQgMjc5MS8y
>NjUwLzQ4MCBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjgz
>NS8yNjc1LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY4MzUvMjA3Ny8yMSBueHJlYWQgMTQzMzcxNjgz
>NS8xNDMzNzE2ODM1LzEyNTYgdHJ5ZXhjZXB0IDQ0LzIvMSBmb3JrIDE0MzM3MTY4MzUvMTQzMzcx
>NjgzNS81MjEgZm9ya3Rvb211Y2ggMTQzMzcxNjgzNS8xNDMzNzE2ODM1LzE0MzM3MTY4MzUgYWxs
>b2MgNDYvMTcvMCBjcmVhdCAyODE2LzI2NzUvNTA1IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE2ODU4LzI2OTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjg1OC8y
>MTAwLzE0IG54cmVhZCAxNDMzNzE2ODU4LzE0MzM3MTY4NTgvMTI3OSB0cnlleGNlcHQgNTUvMi8w
>IGZvcmsgMTQzMzcxNjg1OC8xNDMzNzE2ODU4LzU0NCBmb3JrdG9vbXVjaCAxNDMzNzE2ODU4LzE0
>MzM3MTY4NTgvMTQzMzcxNjg1OCBhbGxvYyA0MC82LzEgY3JlYXQgMjgzOS8yNjk4LzUyOCBsb2Nr
>IDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjg4MC8yNzIwLzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTY4ODAvMjEyMi8zNiBueHJlYWQgMTQzMzcxNjg4MC8xNDMzNzE2ODgw
>LzEzMDEgdHJ5ZXhjZXB0IDEzLzEvMCBmb3JrIDE0MzM3MTY4ODAvMTQzMzcxNjg4MC81NjYgZm9y
>a3Rvb211Y2ggMTQzMzcxNjg4MC8xNDMzNzE2ODgwLzE0MzM3MTY4ODAgYWxsb2MgMzYvMTIvMiBj
>cmVhdCAyODYxLzI3MjAvNTUwIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE2OTEyLzI3NTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjkxMi8yMTU0LzcgbnhyZWFk
>IDE0MzM3MTY5MTIvMTQzMzcxNjkxMi8xMzMzIHRyeWV4Y2VwdCA0NS8zLzAgZm9yayAxNDMzNzE2
>OTEyLzE0MzM3MTY5MTIvNTk4IGZvcmt0b29tdWNoIDE0MzM3MTY5MTIvMTQzMzcxNjkxMi8xNDMz
>NzE2OTEyIGFsbG9jIDE1LzcvMSBjcmVhdCAyODkzLzI3NTIvNTgyIGxvY2sgMS8xLzEpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2OTU3LzI3OTcvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNjk1Ny8yMTk5LzE0IG54cmVhZCAxNDMzNzE2OTU3LzE0MzM3MTY5NTcvMTM3OCB0cnlleGNl
>cHQgMzMvMi8xIGZvcmsgMTQzMzcxNjk1Ny8xNDMzNzE2OTU3LzY0MyBmb3JrdG9vbXVjaCAxNDMz
>NzE2OTU3LzE0MzM3MTY5NTcvMTQzMzcxNjk1NyBhbGxvYyAyNi8xNC8wIGNyZWF0IDI5MzgvMjc5
>Ny82MjcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY5OTAv
>MjgzMC8wICh0ZXN0czogcmVhZCAxNDMzNzE2OTkwLzIyMzIvNDcgbnhyZWFkIDE0MzM3MTY5OTAv
>MTQzMzcxNjk5MC8xNDExIHRyeWV4Y2VwdCA0LzAvMCBmb3JrIDE0MzM3MTY5OTAvMTQzMzcxNjk5
>MC82NzYgZm9ya3Rvb211Y2ggMTQzMzcxNjk5MC8xNDMzNzE2OTkwLzE0MzM3MTY5OTAgYWxsb2Mg
>MzcvNy8yIGNyZWF0IDI5NzEvMjgzMC82NjAgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTcwMjQvMjg2NC8wICh0ZXN0czogcmVhZCAxNDMzNzE3MDI0LzIyNjYv
>NSBueHJlYWQgMTQzMzcxNzAyNC8xNDMzNzE3MDI0LzE0NDUgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsg
>MTQzMzcxNzAyNC8xNDMzNzE3MDI0LzcxMCBmb3JrdG9vbXVjaCAxNDMzNzE3MDI0LzE0MzM3MTcw
>MjQvMTQzMzcxNzAyNCBhbGxvYyAzNi8xMC81IGNyZWF0IDMwMDUvMjg2NC82OTQgbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcwNjAvMjkwMC8wICh0ZXN0czog
>cmVhZCAxNDMzNzE3MDYwLzU1MC8xMyBueHJlYWQgMTQzMzcxNzA2MC8xNDMzNzE3MDYwLzE0ODEg
>dHJ5ZXhjZXB0IDE0LzIvMCBmb3JrIDE0MzM3MTcwNjAvMTQzMzcxNzA2MC83NDYgZm9ya3Rvb211
>Y2ggMTQzMzcxNzA2MC8xNDMzNzE3MDYwLzE0MzM3MTcwNjAgYWxsb2MgNTgvMTMvMSBjcmVhdCAz
>MDQxLzI5MDAvNzMwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzE3MDk0LzI5MzQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzA5NC81ODQvOCBueHJlYWQgMTQzMzcx
>NzA5NC8xNDMzNzE3MDk0LzE1MTUgdHJ5ZXhjZXB0IDQ4LzIvMSBmb3JrIDE0MzM3MTcwOTQvMTQz
>MzcxNzA5NC83ODAgZm9ya3Rvb211Y2ggMTQzMzcxNzA5NC8xNDMzNzE3MDk0LzE0MzM3MTcwOTQg
>YWxsb2MgNjEvNC80IGNyZWF0IDMwNzUvMjkzNC83NjQgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTcxMTIvMjk1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE3MTEy
>LzYwMi82IG54cmVhZCAxNDMzNzE3MTEyLzE0MzM3MTcxMTIvMTUzMyB0cnlleGNlcHQgNTQvMi8x
>IGZvcmsgMTQzMzcxNzExMi8xNDMzNzE3MTEyLzc5OCBmb3JrdG9vbXVjaCAxNDMzNzE3MTEyLzE0
>MzM3MTcxMTIvMTQzMzcxNzExMiBhbGxvYyA3OS8xMi8yIGNyZWF0IDMwOTMvMjk1Mi83ODIgbG9j
>ayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcxMzUvMjk3NS8wICh0
>ZXN0czogcmVhZCAxNDMzNzE3MTM1LzYyNS8xNyBueHJlYWQgMTQzMzcxNzEzNS8xNDMzNzE3MTM1
>LzE1NTYgdHJ5ZXhjZXB0IDExLzMvMCBmb3JrIDE0MzM3MTcxMzUvMTQzMzcxNzEzNS84MjEgZm9y
>a3Rvb211Y2ggMTQzMzcxNzEzNS8xNDMzNzE3MTM1LzE0MzM3MTcxMzUgYWxsb2MgNDEvMTAvMSBj
>cmVhdCAzMTE2LzI5NzUvODA1IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3MTYxLzMwMDEvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzE2MS82NTEvMjIgbnhyZWFk
>IDE0MzM3MTcxNjEvMTQzMzcxNzE2MS8xNTgyIHRyeWV4Y2VwdCA1LzEvMCBmb3JrIDE0MzM3MTcx
>NjEvMTQzMzcxNzE2MS84NDcgZm9ya3Rvb211Y2ggMTQzMzcxNzE2MS8xNDMzNzE3MTYxLzE0MzM3
>MTcxNjEgYWxsb2MgMzYvMTEvMiBjcmVhdCAzMTQyLzMwMDEvODMxIGxvY2sgMS8xLzEpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3MTg2LzMwMjYvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNzE4Ni82NzYvNCBueHJlYWQgMTQzMzcxNzE4Ni8xNDMzNzE3MTg2LzE2MDcgdHJ5ZXhjZXB0
>IDE5LzIvMCBmb3JrIDE0MzM3MTcxODYvMTQzMzcxNzE4Ni84NzIgZm9ya3Rvb211Y2ggMTQzMzcx
>NzE4Ni8xNDMzNzE3MTg2LzE0MzM3MTcxODYgYWxsb2MgNTQvNC8xIGNyZWF0IDMxNjcvMzAyNi84
>NTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcyMTUvMzA1
>NS8wICh0ZXN0czogcmVhZCAxNDMzNzE3MjE1LzcwNS8yMCBueHJlYWQgMTQzMzcxNzIxNS8xNDMz
>NzE3MjE1LzE2MzYgdHJ5ZXhjZXB0IDI3LzIvMSBmb3JrIDE0MzM3MTcyMTUvMTQzMzcxNzIxNS85
>MDEgZm9ya3Rvb211Y2ggMTQzMzcxNzIxNS8xNDMzNzE3MjE1LzE0MzM3MTcyMTUgYWxsb2MgNDYv
>MTMvMCBjcmVhdCAzMTk2LzMwNTUvODg1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE3MjQ5LzMwODkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzI0OS83MzkvNiBu
>eHJlYWQgMTQzMzcxNzI0OS8xNDMzNzE3MjQ5LzE2NzAgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQz
>MzcxNzI0OS8xNDMzNzE3MjQ5LzkzNSBmb3JrdG9vbXVjaCAxNDMzNzE3MjQ5LzE0MzM3MTcyNDkv
>MTQzMzcxNzI0OSBhbGxvYyAzOC8xMS82IGNyZWF0IDMyMzAvMzA4OS85MTkgbG9jayA2LzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcyODAvMzEyMC8wICh0ZXN0czogcmVh
>ZCAxNDMzNzE3MjgwLzc3MC8xNSBueHJlYWQgMTQzMzcxNzI4MC8xNDMzNzE3MjgwLzE3MDEgdHJ5
>ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcxNzI4MC8xNDMzNzE3MjgwLzk2NiBmb3JrdG9vbXVjaCAx
>NDMzNzE3MjgwLzE0MzM3MTcyODAvMTQzMzcxNzI4MCBhbGxvYyA0OC8xMC80IGNyZWF0IDMyNjEv
>MzEyMC85NTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcz
>MzIvMzE3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE3MzMyLzgyMi85IG54cmVhZCAxNDMzNzE3MzMy
>LzE0MzM3MTczMzIvMTc1MyB0cnlleGNlcHQgMjgvMS8wIGZvcmsgMTQzMzcxNzMzMi8xNDMzNzE3
>MzMyLzEwMTggZm9ya3Rvb211Y2ggMTQzMzcxNzMzMi8xNDMzNzE3MzMyLzE0MzM3MTczMzIgYWxs
>b2MgMzcvOS8yIGNyZWF0IDMzMTMvMzE3Mi8xMDAyIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE3MzY3LzMyMDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzM2Ny84
>NTYvNiBueHJlYWQgMTQzMzcxNzM2Ny8xNDMzNzE3MzY3LzE3ODggdHJ5ZXhjZXB0IDE5LzMvMiBm
>b3JrIDE0MzM3MTczNjcvMTQzMzcxNzM2Ny8xMDUzIGZvcmt0b29tdWNoIDE0MzM3MTczNjcvMTQz
>MzcxNzM2Ny8xNDMzNzE3MzY3IGFsbG9jIDE3LzYvMyBjcmVhdCAzMzQ4LzMyMDcvMTAzNyBsb2Nr
>IDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzQwOC8zMjQ4LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTc0MDgvODk3LzcgbnhyZWFkIDE0MzM3MTc0MDgvMTQzMzcxNzQwOC8x
>ODI5IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAxNDMzNzE3NDA4LzE0MzM3MTc0MDgvMTA5NCBmb3Jr
>dG9vbXVjaCAxNDMzNzE3NDA4LzE0MzM3MTc0MDgvMTQzMzcxNzQwOCBhbGxvYyA1NC8xMy8xIGNy
>ZWF0IDMzODkvMzI0OC8xMDc4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3NDM1LzMyNzUvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzQzNS8yOTYvNSBueHJlYWQg
>MTQzMzcxNzQzNS8xNDMzNzE3NDM1LzE4NTYgdHJ5ZXhjZXB0IDE4LzIvMSBmb3JrIDE0MzM3MTc0
>MzUvMTQzMzcxNzQzNS8xMTIxIGZvcmt0b29tdWNoIDE0MzM3MTc0MzUvMTQzMzcxNzQzNS8xNDMz
>NzE3NDM1IGFsbG9jIDgxLzUvNSBjcmVhdCAzNDE2LzMyNzUvMTEwNSBsb2NrIDUvNS8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzQ2Ny8zMzA3LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTc0NjcvMzI4LzE0IG54cmVhZCAxNDMzNzE3NDY3LzE0MzM3MTc0NjcvMTg4OCB0cnlleGNl
>cHQgMjkvMi8yIGZvcmsgMTQzMzcxNzQ2Ny8xNDMzNzE3NDY3LzExNTMgZm9ya3Rvb211Y2ggMTQz
>MzcxNzQ2Ny8xNDMzNzE3NDY3LzE0MzM3MTc0NjcgYWxsb2MgMTEzLzExLzMgY3JlYXQgMzQ0OC8z
>MzA3LzExMzcgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc0
>OTYvMzMzNi8wICh0ZXN0czogcmVhZCAxNDMzNzE3NDk2LzM1Ny8yMCBueHJlYWQgMTQzMzcxNzQ5
>Ni8xNDMzNzE3NDk2LzE5MTcgdHJ5ZXhjZXB0IDQ1LzIvMSBmb3JrIDE0MzM3MTc0OTYvMTQzMzcx
>NzQ5Ni8xMTgyIGZvcmt0b29tdWNoIDE0MzM3MTc0OTYvMTQzMzcxNzQ5Ni8xNDMzNzE3NDk2IGFs
>bG9jIDQ4LzkvNSBjcmVhdCAzNDc3LzMzMzYvMTE2NiBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzU0My8zMzgzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTc1NDMv
>NDA0LzEgbnhyZWFkIDE0MzM3MTc1NDMvMTQzMzcxNzU0My8xOTY0IHRyeWV4Y2VwdCAzNC8zLzAg
>Zm9yayAxNDMzNzE3NTQzLzE0MzM3MTc1NDMvMTIyOSBmb3JrdG9vbXVjaCAxNDMzNzE3NTQzLzE0
>MzM3MTc1NDMvMTQzMzcxNzU0MyBhbGxvYyA2MS8xLzEgY3JlYXQgMzUyNC8zMzgzLzEyMTMgbG9j
>ayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc1NjgvMzQwOC8wICh0
>ZXN0czogcmVhZCAxNDMzNzE3NTY4LzQyOS82IG54cmVhZCAxNDMzNzE3NTY4LzE0MzM3MTc1Njgv
>MTk4OSB0cnlleGNlcHQgMTIvMi8wIGZvcmsgMTQzMzcxNzU2OC8xNDMzNzE3NTY4LzEyNTQgZm9y
>a3Rvb211Y2ggMTQzMzcxNzU2OC8xNDMzNzE3NTY4LzE0MzM3MTc1NjggYWxsb2MgMjYvNi8xIGNy
>ZWF0IDM1NDkvMzQwOC8xMjM4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3NTk5LzM0MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzU5OS80NjAvNSBueHJlYWQg
>MTQzMzcxNzU5OS8xNDMzNzE3NTk5LzIwMjAgdHJ5ZXhjZXB0IDQvMS8xIGZvcmsgMTQzMzcxNzU5
>OS8xNDMzNzE3NTk5LzEyODUgZm9ya3Rvb211Y2ggMTQzMzcxNzU5OS8xNDMzNzE3NTk5LzE0MzM3
>MTc1OTkgYWxsb2MgMjcvMTEvNSBjcmVhdCAzNTgwLzM0MzkvMTI2OSBsb2NrIDMvMy8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzYzNS8zNDc1LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTc2MzUvNDk2LzM2IG54cmVhZCAxNDMzNzE3NjM1LzE0MzM3MTc2MzUvMjA1NiB0cnlleGNl
>cHQgNS8yLzEgZm9yayAxNDMzNzE3NjM1LzE0MzM3MTc2MzUvMTMyMSBmb3JrdG9vbXVjaCAxNDMz
>NzE3NjM1LzE0MzM3MTc2MzUvMTQzMzcxNzYzNSBhbGxvYyAzNi8xMC82IGNyZWF0IDM2MTYvMzQ3
>NS8xMzA1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3NjY3
>LzM1MDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzY2Ny81MjgvNSBueHJlYWQgMTQzMzcxNzY2Ny8x
>NDMzNzE3NjY3LzIwODggdHJ5ZXhjZXB0IDQvMi8yIGZvcmsgMTQzMzcxNzY2Ny8xNDMzNzE3NjY3
>LzEzNTMgZm9ya3Rvb211Y2ggMTQzMzcxNzY2Ny8xNDMzNzE3NjY3LzE0MzM3MTc2NjcgYWxsb2Mg
>NDIvNS81IGNyZWF0IDM2NDgvMzUwNy8xMzM3IGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE3Njk0LzM1MzQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzY5NC81NTUv
>MjMgbnhyZWFkIDE0MzM3MTc2OTQvMTQzMzcxNzY5NC8yMTE1IHRyeWV4Y2VwdCAzLzIvMCBmb3Jr
>IDE0MzM3MTc2OTQvMTQzMzcxNzY5NC8xMzgwIGZvcmt0b29tdWNoIDE0MzM3MTc2OTQvMTQzMzcx
>NzY5NC8xNDMzNzE3Njk0IGFsbG9jIDMyLzYvMSBjcmVhdCAzNjc1LzM1MzQvMTM2NCBsb2NrIDEv
>MS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzczMy8zNTczLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTc3MzMvNTk0LzkgbnhyZWFkIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8yMTU0
>IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8xNDE5IGZvcmt0b29t
>dWNoIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8xNDMzNzE3NzMzIGFsbG9jIDI0LzEzLzMgY3JlYXQg
>MzcxNC8zNTczLzE0MDMgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTc3NjcvMzYwNy8wICh0ZXN0czogcmVhZCAxNDMzNzE3NzY3LzYyOC8yIG54cmVhZCAxNDMz
>NzE3NzY3LzE0MzM3MTc3NjcvMjE4OCB0cnlleGNlcHQgMS8xLzEgZm9yayAxNDMzNzE3NzY3LzE0
>MzM3MTc3NjcvMTQ1MyBmb3JrdG9vbXVjaCAxNDMzNzE3NzY3LzE0MzM3MTc3NjcvMTQzMzcxNzc2
>NyBhbGxvYyA1OC8xMS8yIGNyZWF0IDM3NDgvMzYwNy8xNDM3IGxvY2sgMi8yLzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3NzkwLzM2MzAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>Nzc5MC82NTEvMSBueHJlYWQgMTQzMzcxNzc5MC8xNDMzNzE3NzkwLzIyMTEgdHJ5ZXhjZXB0IDQv
>Mi8wIGZvcmsgMTQzMzcxNzc5MC8xNDMzNzE3NzkwLzE0NzYgZm9ya3Rvb211Y2ggMTQzMzcxNzc5
>MC8xNDMzNzE3NzkwLzE0MzM3MTc3OTAgYWxsb2MgMzQvMTQvMiBjcmVhdCAzNzcxLzM2MzAvMTQ2
>MCBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzgzNy8zNjc3
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc4MzcvNDM3LzUgbnhyZWFkIDE0MzM3MTc4MzcvMTQzMzcx
>NzgzNy8yMjU4IHRyeWV4Y2VwdCAyMS8yLzEgZm9yayAxNDMzNzE3ODM3LzE0MzM3MTc4MzcvMTUy
>MyBmb3JrdG9vbXVjaCAxNDMzNzE3ODM3LzE0MzM3MTc4MzcvMTQzMzcxNzgzNyBhbGxvYyAyNS81
>LzAgY3JlYXQgMzgxOC8zNjc3LzE1MDcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTc4NzIvMzcxMi8wICh0ZXN0czogcmVhZCAxNDMzNzE3ODcyLzQ3Mi8xNiBu
>eHJlYWQgMTQzMzcxNzg3Mi8xNDMzNzE3ODcyLzIyOTMgdHJ5ZXhjZXB0IDIzLzIvMSBmb3JrIDE0
>MzM3MTc4NzIvMTQzMzcxNzg3Mi8xNTU4IGZvcmt0b29tdWNoIDE0MzM3MTc4NzIvMTQzMzcxNzg3
>Mi8xNDMzNzE3ODcyIGFsbG9jIDYwLzIyLzYgY3JlYXQgMzg1My8zNzEyLzE1NDIgbG9jayA0LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc5MDkvMzc0OS8wICh0ZXN0czog
>cmVhZCAxNDMzNzE3OTA5LzUwOS8xOSBueHJlYWQgMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzIzMzAg
>dHJ5ZXhjZXB0IDMvMS8wIGZvcmsgMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzE1OTUgZm9ya3Rvb211
>Y2ggMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzE0MzM3MTc5MDkgYWxsb2MgNDMvMTMvMSBjcmVhdCAz
>ODkwLzM3NDkvMTU3OSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNzk0OS8zNzg5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc5NDkvNTQ5LzEwIG54cmVhZCAxNDMz
>NzE3OTQ5LzE0MzM3MTc5NDkvMjM3MCB0cnlleGNlcHQgMy8yLzIgZm9yayAxNDMzNzE3OTQ5LzE0
>MzM3MTc5NDkvMTYzNSBmb3JrdG9vbXVjaCAxNDMzNzE3OTQ5LzE0MzM3MTc5NDkvMTQzMzcxNzk0
>OSBhbGxvYyAxNS82LzYgY3JlYXQgMzkzMC8zNzg5LzE2MTkgbG9jayA2LzYvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc5NjEvMzgwMS8wICh0ZXN0czogcmVhZCAxNDMzNzE3
>OTYxLzU2MS8xMiBueHJlYWQgMTQzMzcxNzk2MS8xNDMzNzE3OTYxLzIzODIgdHJ5ZXhjZXB0IDkv
>My8wIGZvcmsgMTQzMzcxNzk2MS8xNDMzNzE3OTYxLzE2NDcgZm9ya3Rvb211Y2ggMTQzMzcxNzk2
>MS8xNDMzNzE3OTYxLzE0MzM3MTc5NjEgYWxsb2MgMjcvMTIvNyBjcmVhdCAzOTQyLzM4MDEvMTYz
>MSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzk5Ni8zODM2
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc5OTYvNTk2LzEgbnhyZWFkIDE0MzM3MTc5OTYvMTQzMzcx
>Nzk5Ni8yNDE3IHRyeWV4Y2VwdCA0LzMvMCBmb3JrIDE0MzM3MTc5OTYvMTQzMzcxNzk5Ni8xNjgy
>IGZvcmt0b29tdWNoIDE0MzM3MTc5OTYvMTQzMzcxNzk5Ni8xNDMzNzE3OTk2IGFsbG9jIDUzLzEy
>LzEgY3JlYXQgMzk3Ny8zODM2LzE2NjYgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTgwNTEvMzg5MS8wICh0ZXN0czogcmVhZCAxNDMzNzE4MDUxLzY1MS8yMCBu
>eHJlYWQgMTQzMzcxODA1MS8xNDMzNzE4MDUxLzI0NzIgdHJ5ZXhjZXB0IDE3LzIvMSBmb3JrIDE0
>MzM3MTgwNTEvMTQzMzcxODA1MS8xNzM3IGZvcmt0b29tdWNoIDE0MzM3MTgwNTEvMTQzMzcxODA1
>MS8xNDMzNzE4MDUxIGFsbG9jIDI2LzkvMyBjcmVhdCA0MDMyLzM4OTEvMTcyMSBsb2NrIDIvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODA4Ni8zOTI2LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTgwODYvNjg2LzIzIG54cmVhZCAxNDMzNzE4MDg2LzE0MzM3MTgwODYvMjUwNyB0
>cnlleGNlcHQgNTIvMi8xIGZvcmsgMTQzMzcxODA4Ni8xNDMzNzE4MDg2LzE3NzIgZm9ya3Rvb211
>Y2ggMTQzMzcxODA4Ni8xNDMzNzE4MDg2LzE0MzM3MTgwODYgYWxsb2MgMzgvOS80IGNyZWF0IDQw
>NjcvMzkyNi8xNzU2IGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzE4MTEzLzM5NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODExMy83MTMvMTggbnhyZWFkIDE0MzM3
>MTgxMTMvMTQzMzcxODExMy8yNTM0IHRyeWV4Y2VwdCAyNS8yLzEgZm9yayAxNDMzNzE4MTEzLzE0
>MzM3MTgxMTMvMTc5OSBmb3JrdG9vbXVjaCAxNDMzNzE4MTEzLzE0MzM3MTgxMTMvMTQzMzcxODEx
>MyBhbGxvYyA1OS8xMC81IGNyZWF0IDQwOTQvMzk1My8xNzgzIGxvY2sgNS81LzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MTUwLzM5OTAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>ODE1MC83NTAvMSBueHJlYWQgMTQzMzcxODE1MC8xNDMzNzE4MTUwLzI1NzEgdHJ5ZXhjZXB0IDkv
>Mi8wIGZvcmsgMTQzMzcxODE1MC8xNDMzNzE4MTUwLzE4MzYgZm9ya3Rvb211Y2ggMTQzMzcxODE1
>MC8xNDMzNzE4MTUwLzE0MzM3MTgxNTAgYWxsb2MgMzcvMy8xIGNyZWF0IDQxMzEvMzk5MC8xODIw
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MTgxLzQwMjEv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxODE4MS83ODEvMjMgbnhyZWFkIDE0MzM3MTgxODEvMTQzMzcx
>ODE4MS8yNjAyIHRyeWV4Y2VwdCAzMy8xMC8yIGZvcmsgMTQzMzcxODE4MS8xNDMzNzE4MTgxLzE4
>NjcgZm9ya3Rvb211Y2ggMTQzMzcxODE4MS8xNDMzNzE4MTgxLzE0MzM3MTgxODEgYWxsb2MgMzQv
>MTIvMCBjcmVhdCA0MTYyLzQwMjEvMTg1MSBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxODIyNy80MDY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTgyMjcvODI3LzEg
>bnhyZWFkIDE0MzM3MTgyMjcvMTQzMzcxODIyNy8yNjQ4IHRyeWV4Y2VwdCA0Mi8yLzAgZm9yayAx
>NDMzNzE4MjI3LzE0MzM3MTgyMjcvMTkxMyBmb3JrdG9vbXVjaCAxNDMzNzE4MjI3LzE0MzM3MTgy
>MjcvMTQzMzcxODIyNyBhbGxvYyA0NC8xMi8wIGNyZWF0IDQyMDgvNDA2Ny8xODk3IGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MjU3LzQwOTcvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxODI1Ny84NTcvMTMgbnhyZWFkIDE0MzM3MTgyNTcvMTQzMzcxODI1Ny8yNjc4
>IHRyeWV4Y2VwdCAyMi8yLzAgZm9yayAxNDMzNzE4MjU3LzE0MzM3MTgyNTcvMTk0MyBmb3JrdG9v
>bXVjaCAxNDMzNzE4MjU3LzE0MzM3MTgyNTcvMTQzMzcxODI1NyBhbGxvYyA3NC8zLzEgY3JlYXQg
>NDIzOC80MDk3LzE5MjcgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTgzMDIvNDE0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE4MzAyLzkwMi84IG54cmVhZCAxNDMz
>NzE4MzAyLzE0MzM3MTgzMDIvMjcyMyB0cnlleGNlcHQgMjQvMy8wIGZvcmsgMTQzMzcxODMwMi8x
>NDMzNzE4MzAyLzE5ODggZm9ya3Rvb211Y2ggMTQzMzcxODMwMi8xNDMzNzE4MzAyLzE0MzM3MTgz
>MDIgYWxsb2MgMzcvNC8xIGNyZWF0IDQyODMvNDE0Mi8xOTcyIGxvY2sgMS8xLzEpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MzIyLzQxNjIvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>ODMyMi85MjIvMTcgbnhyZWFkIDE0MzM3MTgzMjIvMTQzMzcxODMyMi8yNzQzIHRyeWV4Y2VwdCAy
>My8xLzAgZm9yayAxNDMzNzE4MzIyLzE0MzM3MTgzMjIvMjAwOCBmb3JrdG9vbXVjaCAxNDMzNzE4
>MzIyLzE0MzM3MTgzMjIvMTQzMzcxODMyMiBhbGxvYyAzOS8xNy8xIGNyZWF0IDQzMDMvNDE2Mi8x
>OTkyIGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MzY4LzMx
>OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODM2OC85NTQvNCBueHJlYWQgMTQzMzcxODM2OC8xNDMz
>NzE4MzY4LzI3ODkgdHJ5ZXhjZXB0IDQyLzIvMSBmb3JrIDE0MzM3MTgzNjgvMTQzMzcxODM2OC8y
>MDU0IGZvcmt0b29tdWNoIDE0MzM3MTgzNjgvMTQzMzcxODM2OC8xNDMzNzE4MzY4IGFsbG9jIDI2
>LzcvMCBjcmVhdCA0MzQ5LzQyMDgvMjAzOCBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxODQwMi8zMjI3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg0MDIvOTg4LzIy
>IG54cmVhZCAxNDMzNzE4NDAyLzE0MzM3MTg0MDIvMjgyMyB0cnlleGNlcHQgMTMvMy8wIGZvcmsg
>MTQzMzcxODQwMi8xNDMzNzE4NDAyLzIwODggZm9ya3Rvb211Y2ggMTQzMzcxODQwMi8xNDMzNzE4
>NDAyLzE0MzM3MTg0MDIgYWxsb2MgMzgvNi8yIGNyZWF0IDQzODMvNDI0Mi8yMDcyIGxvY2sgMi8y
>LzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NDIyLzMyNDcvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxODQyMi8xMDA4LzQgbnhyZWFkIDE0MzM3MTg0MjIvMTQzMzcxODQyMi8yODQz
>IHRyeWV4Y2VwdCAzMy8zLzAgZm9yayAxNDMzNzE4NDIyLzE0MzM3MTg0MjIvMjEwOCBmb3JrdG9v
>bXVjaCAxNDMzNzE4NDIyLzE0MzM3MTg0MjIvMTQzMzcxODQyMiBhbGxvYyA1MC8xMC8yIGNyZWF0
>IDQ0MDMvNDI2Mi8yMDkyIGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE4NDU2LzMyODEvMCAodGVzdHM6IHJlYWQgMTQzMzcxODQ1Ni8xMDQyLzExIG54cmVhZCAx
>NDMzNzE4NDU2LzE0MzM3MTg0NTYvMjg3NyB0cnlleGNlcHQgMy8xLzEgZm9yayAxNDMzNzE4NDU2
>LzE0MzM3MTg0NTYvMjE0MiBmb3JrdG9vbXVjaCAxNDMzNzE4NDU2LzE0MzM3MTg0NTYvMTQzMzcx
>ODQ1NiBhbGxvYyAzOC8xNS80IGNyZWF0IDQ0MzcvNDI5Ni8yMTI2IGxvY2sgNC80LzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NDkwLzMzMTUvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxODQ5MC8xMDc2LzEgbnhyZWFkIDE0MzM3MTg0OTAvMTQzMzcxODQ5MC8yOTExIHRyeWV4Y2Vw
>dCA0LzIvMCBmb3JrIDE0MzM3MTg0OTAvMTQzMzcxODQ5MC8yMTc2IGZvcmt0b29tdWNoIDE0MzM3
>MTg0OTAvMTQzMzcxODQ5MC8xNDMzNzE4NDkwIGFsbG9jIDM4LzcvMSBjcmVhdCA0NDcxLzQzMzAv
>MjE2MCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODUyMS8z
>MzQ2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg1MjEvMTEwNy83IG54cmVhZCAxNDMzNzE4NTIxLzE0
>MzM3MTg1MjEvMjk0MiB0cnlleGNlcHQgNi8xLzAgZm9yayAxNDMzNzE4NTIxLzE0MzM3MTg1MjEv
>MjIwNyBmb3JrdG9vbXVjaCAxNDMzNzE4NTIxLzE0MzM3MTg1MjEvMTQzMzcxODUyMSBhbGxvYyAy
>Mi83LzMgY3JlYXQgNDUwMi80MzYxLzIxOTEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTg1NTAvMzM3NS8wICh0ZXN0czogcmVhZCAxNDMzNzE4NTUwLzExMzYv
>NyBueHJlYWQgMTQzMzcxODU1MC8xNDMzNzE4NTUwLzI5NzEgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsg
>MTQzMzcxODU1MC8xNDMzNzE4NTUwLzIyMzYgZm9ya3Rvb211Y2ggMTQzMzcxODU1MC8xNDMzNzE4
>NTUwLzE0MzM3MTg1NTAgYWxsb2MgNTEvMTQvNyBjcmVhdCA0NTMxLzQzOTAvMjIyMCBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODU4My8zNDA4LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTg1ODMvMTE2OS81IG54cmVhZCAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMzAw
>NCB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMjI2OSBmb3JrdG9v
>bXVjaCAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMTQzMzcxODU4MyBhbGxvYyA3NC81LzAgY3JlYXQg
>NDU2NC80NDIzLzIyNTMgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTg2MDkvMzQzNC8wICh0ZXN0czogcmVhZCAxNDMzNzE4NjA5LzExOTUvNyBueHJlYWQgMTQz
>MzcxODYwOS8xNDMzNzE4NjA5LzMwMzAgdHJ5ZXhjZXB0IDE1LzEvMSBmb3JrIDE0MzM3MTg2MDkv
>MTQzMzcxODYwOS8yMjk1IGZvcmt0b29tdWNoIDE0MzM3MTg2MDkvMTQzMzcxODYwOS8xNDMzNzE4
>NjA5IGFsbG9jIDEwMC83LzIgY3JlYXQgNDU5MC80NDQ5LzIyNzkgbG9jayAyLzIvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg2NDEvMzQ2Ni8wICh0ZXN0czogcmVhZCAxNDMz
>NzE4NjQxLzEyMjcvNyBueHJlYWQgMTQzMzcxODY0MS8xNDMzNzE4NjQxLzMwNjIgdHJ5ZXhjZXB0
>IDMzLzEvMSBmb3JrIDE0MzM3MTg2NDEvMTQzMzcxODY0MS8yMzI3IGZvcmt0b29tdWNoIDE0MzM3
>MTg2NDEvMTQzMzcxODY0MS8xNDMzNzE4NjQxIGFsbG9jIDM0LzcvMCBjcmVhdCA0NjIyLzQ0ODEv
>MjMxMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODY3OS8z
>NTA0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg2NzkvMTI2NS81IG54cmVhZCAxNDMzNzE4Njc5LzE0
>MzM3MTg2NzkvMzEwMCB0cnlleGNlcHQgNi8xLzEgZm9yayAxNDMzNzE4Njc5LzE0MzM3MTg2Nzkv
>MjM2NSBmb3JrdG9vbXVjaCAxNDMzNzE4Njc5LzE0MzM3MTg2NzkvMTQzMzcxODY3OSBhbGxvYyA0
>NS8xNi81IGNyZWF0IDQ2NjAvNDUxOS8yMzQ5IGxvY2sgNC80LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE4NzEyLzM1MzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxODcxMi8xMjk4
>LzM4IG54cmVhZCAxNDMzNzE4NzEyLzE0MzM3MTg3MTIvMzEzMyB0cnlleGNlcHQgMjEvMi8xIGZv
>cmsgMTQzMzcxODcxMi8xNDMzNzE4NzEyLzIzOTggZm9ya3Rvb211Y2ggMTQzMzcxODcxMi8xNDMz
>NzE4NzEyLzE0MzM3MTg3MTIgYWxsb2MgNTIvOS81IGNyZWF0IDQ2OTMvNDU1Mi8yMzgyIGxvY2sg
>NS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NzM4LzM1NjMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxODczOC8xMzI0LzcgbnhyZWFkIDE0MzM3MTg3MzgvMTQzMzcxODczOC8z
>MTU5IHRyeWV4Y2VwdCAyNy8yLzIgZm9yayAxNDMzNzE4NzM4LzE0MzM3MTg3MzgvMjQyNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE4NzM4LzE0MzM3MTg3MzgvMTQzMzcxODczOCBhbGxvYyA2OS8xOS83IGNy
>ZWF0IDQ3MTkvNDU3OC8yNDA4IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE4NzY4LzM1OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODc2OC8xMzU0LzE1IG54cmVh
>ZCAxNDMzNzE4NzY4LzE0MzM3MTg3NjgvMzE4OSB0cnlleGNlcHQgNi8zLzEgZm9yayAxNDMzNzE4
>NzY4LzE0MzM3MTg3NjgvMjQ1NCBmb3JrdG9vbXVjaCAxNDMzNzE4NzY4LzE0MzM3MTg3NjgvMTQz
>MzcxODc2OCBhbGxvYyA0OS84LzUgY3JlYXQgNDc0OS80NjA4LzI0MzggbG9jayAwLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg3OTYvMzYyMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzE4Nzk2LzEzODIvMTIgbnhyZWFkIDE0MzM3MTg3OTYvMTQzMzcxODc5Ni8zMjE3IHRyeWV4
>Y2VwdCAzNC8zLzEgZm9yayAxNDMzNzE4Nzk2LzE0MzM3MTg3OTYvMjQ4MiBmb3JrdG9vbXVjaCAx
>NDMzNzE4Nzk2LzE0MzM3MTg3OTYvMTQzMzcxODc5NiBhbGxvYyAzMy8xOS81IGNyZWF0IDQ3Nzcv
>NDYzNi8yNDY2IGxvY2sgMTAvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>ODg0OS8zNjc0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg4NDkvMTQzNS80NSBueHJlYWQgMTQzMzcx
>ODg0OS8xNDMzNzE4ODQ5LzMyNzAgdHJ5ZXhjZXB0IDIwLzIvMSBmb3JrIDE0MzM3MTg4NDkvMTQz
>MzcxODg0OS8yNTM1IGZvcmt0b29tdWNoIDE0MzM3MTg4NDkvMTQzMzcxODg0OS8xNDMzNzE4ODQ5
>IGFsbG9jIDQwLzEwLzQgY3JlYXQgNDgzMC80Njg5LzI1MTkgbG9jayA0LzQvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg4OTEvMzcxNi8wICh0ZXN0czogcmVhZCAxNDMzNzE4
>ODkxLzE0NzcvMSBueHJlYWQgMTQzMzcxODg5MS8xNDMzNzE4ODkxLzMzMTIgdHJ5ZXhjZXB0IDMx
>LzIvMCBmb3JrIDE0MzM3MTg4OTEvMTQzMzcxODg5MS8yNTc3IGZvcmt0b29tdWNoIDE0MzM3MTg4
>OTEvMTQzMzcxODg5MS8xNDMzNzE4ODkxIGFsbG9jIDQyLzExLzEgY3JlYXQgNDg3Mi80NzMxLzI1
>NjEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg5NDkvMzc3
>NC8wICh0ZXN0czogcmVhZCAxNDMzNzE4OTQ5LzE1MzUvOCBueHJlYWQgMTQzMzcxODk0OS8xNDMz
>NzE4OTQ5LzMzNzAgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcxODk0OS8xNDMzNzE4OTQ5LzI2
>MzUgZm9ya3Rvb211Y2ggMTQzMzcxODk0OS8xNDMzNzE4OTQ5LzE0MzM3MTg5NDkgYWxsb2MgMjgv
>Mi8yIGNyZWF0IDQ5MzAvNDc4OS8yNjE5IGxvY2sgMi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE5MDAyLzM4MjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTAwMi8xNTg4LzE5
>IG54cmVhZCAxNDMzNzE5MDAyLzE0MzM3MTkwMDIvMzQyMyB0cnlleGNlcHQgMjgvMS8wIGZvcmsg
>MTQzMzcxOTAwMi8xNDMzNzE5MDAyLzI2ODggZm9ya3Rvb211Y2ggMTQzMzcxOTAwMi8xNDMzNzE5
>MDAyLzE0MzM3MTkwMDIgYWxsb2MgNTUvMTEvMiBjcmVhdCA0OTgzLzQ4NDIvMjY3MiBsb2NrIDEv
>MS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTAzMy8zODU4LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTkwMzMvMTYxOS81IG54cmVhZCAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMzQ1
>NCB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMjcxOSBmb3JrdG9v
>bXVjaCAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMTQzMzcxOTAzMyBhbGxvYyAyNy8xMS8wIGNyZWF0
>IDUwMTQvNDg3My8yNzAzIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE5MDYzLzM4ODgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTA2My8xNjQ5LzYgbnhyZWFkIDE0
>MzM3MTkwNjMvMTQzMzcxOTA2My8zNDg0IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MTkwNjMv
>MTQzMzcxOTA2My8yNzQ5IGZvcmt0b29tdWNoIDE0MzM3MTkwNjMvMTQzMzcxOTA2My8xNDMzNzE5
>MDYzIGFsbG9jIDMwLzYvMSBjcmVhdCA1MDQ0LzQ5MDMvMjczMyBsb2NrIDAvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTEwNi8zOTMxLzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTkxMDYvMTY5Mi80OSBueHJlYWQgMTQzMzcxOTEwNi8xNDMzNzE5MTA2LzM1MjcgdHJ5ZXhjZXB0
>IDcvMS8wIGZvcmsgMTQzMzcxOTEwNi8xNDMzNzE5MTA2LzI3OTIgZm9ya3Rvb211Y2ggMTQzMzcx
>OTEwNi8xNDMzNzE5MTA2LzE0MzM3MTkxMDYgYWxsb2MgNTQvMS8xIGNyZWF0IDUwODcvNDk0Ni8y
>Nzc2IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MTQ2LzM5
>NzEvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTE0Ni8xNzMyLzEzIG54cmVhZCAxNDMzNzE5MTQ2LzE0
>MzM3MTkxNDYvMzU2NyB0cnlleGNlcHQgMTMvMi8xIGZvcmsgMTQzMzcxOTE0Ni8xNDMzNzE5MTQ2
>LzI4MzIgZm9ya3Rvb211Y2ggMTQzMzcxOTE0Ni8xNDMzNzE5MTQ2LzE0MzM3MTkxNDYgYWxsb2Mg
>NDEvMTMvNSBjcmVhdCA1MTI3LzQ5ODYvMjgxNiBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxOTE4Mi80MDA3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTkxODIvMTc2
>OC85IG54cmVhZCAxNDMzNzE5MTgyLzE0MzM3MTkxODIvMzYwMyB0cnlleGNlcHQgOC83LzEgZm9y
>ayAxNDMzNzE5MTgyLzE0MzM3MTkxODIvMjg2OCBmb3JrdG9vbXVjaCAxNDMzNzE5MTgyLzE0MzM3
>MTkxODIvMTQzMzcxOTE4MiBhbGxvYyA0OS85LzIgY3JlYXQgNTE2My81MDIyLzI4NTIgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTkyMTgvNDA0My8wICh0ZXN0
>czogcmVhZCAxNDMzNzE5MjE4LzE4MDQvMTkgbnhyZWFkIDE0MzM3MTkyMTgvMTQzMzcxOTIxOC8z
>NjM5IHRyeWV4Y2VwdCAyMi81LzEgZm9yayAxNDMzNzE5MjE4LzE0MzM3MTkyMTgvMjkwNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE5MjE4LzE0MzM3MTkyMTgvMTQzMzcxOTIxOCBhbGxvYyA2OC8xMS8zIGNy
>ZWF0IDUxOTkvNTA1OC8yODg4IGxvY2sgNC8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE5MjQ1LzQwNzAvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTI0NS8xODMxLzE2IG54cmVh
>ZCAxNDMzNzE5MjQ1LzE0MzM3MTkyNDUvMzY2NiB0cnlleGNlcHQgNDgvMi8wIGZvcmsgMTQzMzcx
>OTI0NS8xNDMzNzE5MjQ1LzI5MzEgZm9ya3Rvb211Y2ggMTQzMzcxOTI0NS8xNDMzNzE5MjQ1LzE0
>MzM3MTkyNDUgYWxsb2MgNDIvOS8xIGNyZWF0IDUyMjYvNTA4NS8yOTE1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MjczLzQwOTgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTI3My8xODU5LzMgbnhyZWFkIDE0MzM3MTkyNzMvMTQzMzcxOTI3My8zNjk0IHRyeWV4
>Y2VwdCA3LzIvMSBmb3JrIDE0MzM3MTkyNzMvMTQzMzcxOTI3My8yOTU5IGZvcmt0b29tdWNoIDE0
>MzM3MTkyNzMvMTQzMzcxOTI3My8xNDMzNzE5MjczIGFsbG9jIDU1LzgvMCBjcmVhdCA1MjU0LzUx
>MTMvMjk0MyBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTI5
>NS80MTIwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTkyOTUvMTg4MS82IG54cmVhZCAxNDMzNzE5Mjk1
>LzE0MzM3MTkyOTUvMzcxNiB0cnlleGNlcHQgMTUvMi8wIGZvcmsgMTQzMzcxOTI5NS8xNDMzNzE5
>Mjk1LzI5ODEgZm9ya3Rvb211Y2ggMTQzMzcxOTI5NS8xNDMzNzE5Mjk1LzE0MzM3MTkyOTUgYWxs
>b2MgMjIvNi8xIGNyZWF0IDUyNzYvNTEzNS8yOTY1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE5MzQ4LzQxNzMvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTM0OC8x
>OTM0LzQ5IG54cmVhZCAxNDMzNzE5MzQ4LzE0MzM3MTkzNDgvMzc2OSB0cnlleGNlcHQgNi8yLzIg
>Zm9yayAxNDMzNzE5MzQ4LzE0MzM3MTkzNDgvMzAzNCBmb3JrdG9vbXVjaCAxNDMzNzE5MzQ4LzE0
>MzM3MTkzNDgvMTQzMzcxOTM0OCBhbGxvYyA2Mi8xNS83IGNyZWF0IDUzMjkvNTE4OC8zMDE4IGxv
>Y2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MzcxLzQxOTYvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxOTM3MS8xOTU3LzggbnhyZWFkIDE0MzM3MTkzNzEvMTQzMzcxOTM3
>MS8zNzkyIHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTkzNzEvMTQzMzcxOTM3MS8zMDU3IGZv
>cmt0b29tdWNoIDE0MzM3MTkzNzEvMTQzMzcxOTM3MS8xNDMzNzE5MzcxIGFsbG9jIDYxLzgvMSBj
>cmVhdCA1MzUyLzUyMTEvMzA0MSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxOTQwMy80MjI4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk0MDMvMTk4OS84IG54cmVh
>ZCAxNDMzNzE5NDAzLzE0MzM3MTk0MDMvMzgyNCB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE5
>NDAzLzE0MzM3MTk0MDMvMzA4OSBmb3JrdG9vbXVjaCAxNDMzNzE5NDAzLzE0MzM3MTk0MDMvMTQz
>MzcxOTQwMyBhbGxvYyA4OC8xNy84IGNyZWF0IDUzODQvNTI0My8zMDczIGxvY2sgNi8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NDMyLzQyNTcvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTQzMi8yMDE4LzggbnhyZWFkIDE0MzM3MTk0MzIvMTQzMzcxOTQzMi8zODUzIHRyeWV4
>Y2VwdCA0LzIvMCBmb3JrIDE0MzM3MTk0MzIvMTQzMzcxOTQzMi8zMTE4IGZvcmt0b29tdWNoIDE0
>MzM3MTk0MzIvMTQzMzcxOTQzMi8xNDMzNzE5NDMyIGFsbG9jIDM3LzEvMSBjcmVhdCA1NDEzLzUy
>NzIvMzEwMiBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTQ2
>OS80Mjk0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk0NjkvMjA1NS8xIG54cmVhZCAxNDMzNzE5NDY5
>LzE0MzM3MTk0NjkvMzg5MCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE5NDY5LzE0MzM3MTk0
>NjkvMzE1NSBmb3JrdG9vbXVjaCAxNDMzNzE5NDY5LzE0MzM3MTk0NjkvMTQzMzcxOTQ2OSBhbGxv
>YyA1MC8xLzEgY3JlYXQgNTQ1MC81MzA5LzMxMzkgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTk1MTMvNDMzOC8wICh0ZXN0czogcmVhZCAxNDMzNzE5NTEzLzIw
>OTkvMTcgbnhyZWFkIDE0MzM3MTk1MTMvMTQzMzcxOTUxMy8zOTM0IHRyeWV4Y2VwdCAzLzMvMCBm
>b3JrIDE0MzM3MTk1MTMvMTQzMzcxOTUxMy8zMTk5IGZvcmt0b29tdWNoIDE0MzM3MTk1MTMvMTQz
>MzcxOTUxMy8xNDMzNzE5NTEzIGFsbG9jIDIyLzYvMSBjcmVhdCA1NDk0LzUzNTMvMzE4MyBsb2Nr
>IDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTU0MS80MzY2LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTk1NDEvMjEyNy8zIG54cmVhZCAxNDMzNzE5NTQxLzE0MzM3MTk1NDEv
>Mzk2MiB0cnlleGNlcHQgMTEvOC8yIGZvcmsgMTQzMzcxOTU0MS8xNDMzNzE5NTQxLzMyMjcgZm9y
>a3Rvb211Y2ggMTQzMzcxOTU0MS8xNDMzNzE5NTQxLzE0MzM3MTk1NDEgYWxsb2MgMzQvMTAvMCBj
>cmVhdCA1NTIyLzUzODEvMzIxMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxOTU2Mi80Mzg3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk1NjIvMjE0OC8yNCBueHJl
>YWQgMTQzMzcxOTU2Mi8xNDMzNzE5NTYyLzM5ODMgdHJ5ZXhjZXB0IDI5LzMvMCBmb3JrIDE0MzM3
>MTk1NjIvMTQzMzcxOTU2Mi8zMjQ4IGZvcmt0b29tdWNoIDE0MzM3MTk1NjIvMTQzMzcxOTU2Mi8x
>NDMzNzE5NTYyIGFsbG9jIDMxLzE1LzEgY3JlYXQgNTU0My81NDAyLzMyMzIgbG9jayAxLzEvMSkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTk1OTgvNDQyMy8wICh0ZXN0czogcmVh
>ZCAxNDMzNzE5NTk4LzIxODQvMjMgbnhyZWFkIDE0MzM3MTk1OTgvMTQzMzcxOTU5OC80MDE5IHRy
>eWV4Y2VwdCA3LzMvMiBmb3JrIDE0MzM3MTk1OTgvMTQzMzcxOTU5OC8zMjg0IGZvcmt0b29tdWNo
>IDE0MzM3MTk1OTgvMTQzMzcxOTU5OC8xNDMzNzE5NTk4IGFsbG9jIDUxLzI3LzYgY3JlYXQgNTU3
>OS81NDM4LzMyNjggbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTk2MjkvNDQ1NC8wICh0ZXN0czogcmVhZCAxNDMzNzE5NjI5LzIyMTUvMTEgbnhyZWFkIDE0MzM3
>MTk2MjkvMTQzMzcxOTYyOS80MDUwIHRyeWV4Y2VwdCAzMy8yLzIgZm9yayAxNDMzNzE5NjI5LzE0
>MzM3MTk2MjkvMzMxNSBmb3JrdG9vbXVjaCAxNDMzNzE5NjI5LzE0MzM3MTk2MjkvMTQzMzcxOTYy
>OSBhbGxvYyA2OC8xNi82IGNyZWF0IDU2MTAvNTQ2OS8zMjk5IGxvY2sgMC8wLzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NjUyLzQ0NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>OTY1Mi8yMjM4LzcgbnhyZWFkIDE0MzM3MTk2NTIvMTQzMzcxOTY1Mi80MDczIHRyeWV4Y2VwdCAx
>NS8zLzIgZm9yayAxNDMzNzE5NjUyLzE0MzM3MTk2NTIvMzMzOCBmb3JrdG9vbXVjaCAxNDMzNzE5
>NjUyLzE0MzM3MTk2NTIvMTQzMzcxOTY1MiBhbGxvYyAyMy8xNy83IGNyZWF0IDU2MzMvNTQ5Mi8z
>MzIyIGxvY2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NjkzLzQ1
>MTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTY5My8yMjc5LzUgbnhyZWFkIDE0MzM3MTk2OTMvMTQz
>MzcxOTY5My80MTE0IHRyeWV4Y2VwdCA1Ni8yLzEgZm9yayAxNDMzNzE5NjkzLzE0MzM3MTk2OTMv
>MzM3OSBmb3JrdG9vbXVjaCAxNDMzNzE5NjkzLzE0MzM3MTk2OTMvMTQzMzcxOTY5MyBhbGxvYyAz
>MC8xNC81IGNyZWF0IDU2NzQvNTUzMy8zMzYzIGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE5NzE2LzQ1NDEvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTcxNi8yMzAy
>LzE5IG54cmVhZCAxNDMzNzE5NzE2LzE0MzM3MTk3MTYvNDEzNyB0cnlleGNlcHQgMjAvMy8wIGZv
>cmsgMTQzMzcxOTcxNi8xNDMzNzE5NzE2LzM0MDIgZm9ya3Rvb211Y2ggMTQzMzcxOTcxNi8xNDMz
>NzE5NzE2LzE0MzM3MTk3MTYgYWxsb2MgNTMvOC8wIGNyZWF0IDU2OTcvNTU1Ni8zMzg2IGxvY2sg
>MS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NzQ4LzQ1NzMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxOTc0OC8yMzM0LzQgbnhyZWFkIDE0MzM3MTk3NDgvMTQzMzcxOTc0OC80
>MTY5IHRyeWV4Y2VwdCA1Mi8xLzEgZm9yayAxNDMzNzE5NzQ4LzE0MzM3MTk3NDgvMzQzNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE5NzQ4LzE0MzM3MTk3NDgvMTQzMzcxOTc0OCBhbGxvYyA1NS8xNS80IGNy
>ZWF0IDU3MjkvNTU4OC8zNDE4IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE5NzgzLzQ2MDgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTc4My8yMzY5LzkgbnhyZWFk
>IDE0MzM3MTk3ODMvMTQzMzcxOTc4My80MjA0IHRyeWV4Y2VwdCA4My8yLzAgZm9yayAxNDMzNzE5
>NzgzLzE0MzM3MTk3ODMvMzQ2OSBmb3JrdG9vbXVjaCAxNDMzNzE5NzgzLzE0MzM3MTk3ODMvMTQz
>MzcxOTc4MyBhbGxvYyA0Mi8xNi8xIGNyZWF0IDU3NjQvNTYyMy8zNDUzIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5ODEzLzQ2MzgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTgxMy8yMzk5LzUgbnhyZWFkIDE0MzM3MTk4MTMvMTQzMzcxOTgxMy80MjM0IHRyeWV4
>Y2VwdCAxMTMvMC8wIGZvcmsgMTQzMzcxOTgxMy8xNDMzNzE5ODEzLzM0OTkgZm9ya3Rvb211Y2gg
>MTQzMzcxOTgxMy8xNDMzNzE5ODEzLzE0MzM3MTk4MTMgYWxsb2MgNTYvMTYvMiBjcmVhdCA1Nzk0
>LzU2NTMvMzQ4MyBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>OTg0Ny80NjcyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTk4NDcvMjQzMy82IG54cmVhZCAxNDMzNzE5
>ODQ3LzE0MzM3MTk4NDcvNDI2OCB0cnlleGNlcHQgMjcvMS8wIGZvcmsgMTQzMzcxOTg0Ny8xNDMz
>NzE5ODQ3LzM1MzMgZm9ya3Rvb211Y2ggMTQzMzcxOTg0Ny8xNDMzNzE5ODQ3LzE0MzM3MTk4NDcg
>YWxsb2MgNDUvNi8yIGNyZWF0IDU4MjgvNTY4Ny8zNTE3IGxvY2sgMi8yLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzE5ODg4LzQ3MTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTg4
>OC8yNDc0LzI3IG54cmVhZCAxNDMzNzE5ODg4LzE0MzM3MTk4ODgvNDMwOSB0cnlleGNlcHQgMTMv
>Mi8yIGZvcmsgMTQzMzcxOTg4OC8xNDMzNzE5ODg4LzM1NzQgZm9ya3Rvb211Y2ggMTQzMzcxOTg4
>OC8xNDMzNzE5ODg4LzE0MzM3MTk4ODggYWxsb2MgNDcvMTcvMCBjcmVhdCA1ODY5LzU3MjgvMzU1
>OCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTkxOS80NzQ0
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk5MTkvMjUwNS82IG54cmVhZCAxNDMzNzE5OTE5LzE0MzM3
>MTk5MTkvNDM0MCB0cnlleGNlcHQgNDQvMi8xIGZvcmsgMTQzMzcxOTkxOS8xNDMzNzE5OTE5LzM2
>MDUgZm9ya3Rvb211Y2ggMTQzMzcxOTkxOS8xNDMzNzE5OTE5LzE0MzM3MTk5MTkgYWxsb2MgNDMv
>Ni8wIGNyZWF0IDU5MDAvNTc1OS8zNTg5IGxvY2sgNi82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE5OTM5LzQ3NjQvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTkzOS8yNTI1LzEx
>IG54cmVhZCAxNDMzNzE5OTM5LzE0MzM3MTk5MzkvNDM2MCB0cnlleGNlcHQgMjEvMi8xIGZvcmsg
>MTQzMzcxOTkzOS8xNDMzNzE5OTM5LzM2MjUgZm9ya3Rvb211Y2ggMTQzMzcxOTkzOS8xNDMzNzE5
>OTM5LzE0MzM3MTk5MzkgYWxsb2MgMzcvMTEvNSBjcmVhdCA1OTIwLzU3NzkvMzYwOSBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTk2OS80Nzk0LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTk5NjkvMjU1NS85IG54cmVhZCAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvNDM5
>MCB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvMzY1NSBmb3JrdG9v
>bXVjaCAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvMTQzMzcxOTk2OSBhbGxvYyA0MS85LzUgY3JlYXQg
>NTk1MC81ODA5LzM2MzkgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTk5ODQvNDgwOS8wICh0ZXN0czogcmVhZCAxNDMzNzE5OTg0LzI1NzAvMTUgbnhyZWFkIDE0
>MzM3MTk5ODQvMTQzMzcxOTk4NC80NDA1IHRyeWV4Y2VwdCA3LzcvMCBmb3JrIDE0MzM3MTk5ODQv
>MTQzMzcxOTk4NC8zNjcwIGZvcmt0b29tdWNoIDE0MzM3MTk5ODQvMTQzMzcxOTk4NC8xNDMzNzE5
>OTg0IGFsbG9jIDQ1LzIwLzggY3JlYXQgNTk2NS81ODI0LzM2NTQgbG9jayAxLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjAwMTYvNDg0MS8wICh0ZXN0czogcmVhZCAxNDMz
>NzIwMDE2LzI2MDIvMSBueHJlYWQgMTQzMzcyMDAxNi8xNDMzNzIwMDE2LzQ0MzcgdHJ5ZXhjZXB0
>IDE4LzMvMCBmb3JrIDE0MzM3MjAwMTYvMTQzMzcyMDAxNi8zNzAyIGZvcmt0b29tdWNoIDE0MzM3
>MjAwMTYvMTQzMzcyMDAxNi8xNDMzNzIwMDE2IGFsbG9jIDU2LzkvMSBjcmVhdCA1OTk3LzU4NTYv
>MzY4NiBsb2NrIDEvMS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDA1Mi80
>ODc3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjAwNTIvMjYzOC8xMCBueHJlYWQgMTQzMzcyMDA1Mi8x
>NDMzNzIwMDUyLzQ0NzMgdHJ5ZXhjZXB0IDUzLzIvMSBmb3JrIDE0MzM3MjAwNTIvMTQzMzcyMDA1
>Mi8zNzM4IGZvcmt0b29tdWNoIDE0MzM3MjAwNTIvMTQzMzcyMDA1Mi8xNDMzNzIwMDUyIGFsbG9j
>IDQ1LzE4LzYgY3JlYXQgNjAzMy81ODkyLzM3MjIgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjAwNzYvNDkwMS8wICh0ZXN0czogcmVhZCAxNDMzNzIwMDc2LzI2
>NjIvMTEgbnhyZWFkIDE0MzM3MjAwNzYvMTQzMzcyMDA3Ni80NDk3IHRyeWV4Y2VwdCAxMi8xLzAg
>Zm9yayAxNDMzNzIwMDc2LzE0MzM3MjAwNzYvMzc2MiBmb3JrdG9vbXVjaCAxNDMzNzIwMDc2LzE0
>MzM3MjAwNzYvMTQzMzcyMDA3NiBhbGxvYyA1NS8xLzEgY3JlYXQgNjA1Ny81OTE2LzM3NDYgbG9j
>ayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjAxMDgvNDkzMy8wICh0
>ZXN0czogcmVhZCAxNDMzNzIwMTA4LzI2OTQvNSBueHJlYWQgMTQzMzcyMDEwOC8xNDMzNzIwMTA4
>LzQ1MjkgdHJ5ZXhjZXB0IDE2LzIvMCBmb3JrIDE0MzM3MjAxMDgvMTQzMzcyMDEwOC8zNzk0IGZv
>cmt0b29tdWNoIDE0MzM3MjAxMDgvMTQzMzcyMDEwOC8xNDMzNzIwMTA4IGFsbG9jIDMzLzkvMSBj
>cmVhdCA2MDg5LzU5NDgvMzc3OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMDE0My80OTY4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjAxNDMvMjcyOS8yNCBueHJl
>YWQgMTQzMzcyMDE0My8xNDMzNzIwMTQzLzQ1NjQgdHJ5ZXhjZXB0IDkvMi8wIGZvcmsgMTQzMzcy
>MDE0My8xNDMzNzIwMTQzLzM4MjkgZm9ya3Rvb211Y2ggMTQzMzcyMDE0My8xNDMzNzIwMTQzLzE0
>MzM3MjAxNDMgYWxsb2MgNTYvMTAvMSBjcmVhdCA2MTI0LzU5ODMvMzgxMyBsb2NrIDAvMC8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDE4NS81MDEwLzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjAxODUvMTk0MS84IG54cmVhZCAxNDMzNzIwMTg1LzE0MzM3MjAxODUvNDYwNiB0cnll
>eGNlcHQgMjIvMC8wIGZvcmsgMTQzMzcyMDE4NS8xNDMzNzIwMTg1LzM4NzEgZm9ya3Rvb211Y2gg
>MTQzMzcyMDE4NS8xNDMzNzIwMTg1LzE0MzM3MjAxODUgYWxsb2MgMzkvMTMvMyBjcmVhdCA2MTY2
>LzYwMjUvMzg1NSBsb2NrIDMvMi8yKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcy
>MDIxOC81MDQzLzAgKHRlc3RzOiByZWFkIDE0MzM3MjAyMTgvMTk3NC8xMiBueHJlYWQgMTQzMzcy
>MDIxOC8xNDMzNzIwMjE4LzQ2MzkgdHJ5ZXhjZXB0IDQvMi8wIGZvcmsgMTQzMzcyMDIxOC8xNDMz
>NzIwMjE4LzM5MDQgZm9ya3Rvb211Y2ggMTQzMzcyMDIxOC8xNDMzNzIwMjE4LzE0MzM3MjAyMTgg
>YWxsb2MgMTgvNy8xIGNyZWF0IDYxOTkvNjA1OC8zODg4IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIwMjYzLzUwODgvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDI2
>My8yMDE5LzQgbnhyZWFkIDE0MzM3MjAyNjMvMTQzMzcyMDI2My80Njg0IHRyeWV4Y2VwdCAxMy8y
>LzEgZm9yayAxNDMzNzIwMjYzLzE0MzM3MjAyNjMvMzk0OSBmb3JrdG9vbXVjaCAxNDMzNzIwMjYz
>LzE0MzM3MjAyNjMvMTQzMzcyMDI2MyBhbGxvYyA1Ny8xNC80IGNyZWF0IDYyNDQvNjEwMy8zOTMz
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwMzA1LzUxMzAv
>MCAodGVzdHM6IHJlYWQgMTQzMzcyMDMwNS8yMDYxLzExIG54cmVhZCAxNDMzNzIwMzA1LzE0MzM3
>MjAzMDUvNDcyNiB0cnlleGNlcHQgNS81LzAgZm9yayAxNDMzNzIwMzA1LzE0MzM3MjAzMDUvMzk5
>MSBmb3JrdG9vbXVjaCAxNDMzNzIwMzA1LzE0MzM3MjAzMDUvMTQzMzcyMDMwNSBhbGxvYyAzMi8x
>Ni81IGNyZWF0IDYyODYvNjE0NS8zOTc1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIwMzM1LzUxNjAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDMzNS8yMDkxLzIg
>bnhyZWFkIDE0MzM3MjAzMzUvMTQzMzcyMDMzNS80NzU2IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAx
>NDMzNzIwMzM1LzE0MzM3MjAzMzUvNDAyMSBmb3JrdG9vbXVjaCAxNDMzNzIwMzM1LzE0MzM3MjAz
>MzUvMTQzMzcyMDMzNSBhbGxvYyA0MS8xMC8yIGNyZWF0IDYzMTYvNjE3NS80MDA1IGxvY2sgMi8x
>LzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNDE1LzUxOTYvMCAodGVzdHM6
>IHJlYWQgMTQzMzcyMDQxNS8yMDUxLzE2IG54cmVhZCAxNDMzNzIwNDE1LzE0MzM3MjA0MTUvNDgz
>NiB0cnlleGNlcHQgMTgvMi8yIGZvcmsgMTQzMzcyMDQxNS8xNDMzNzIwNDE1LzQxMDEgZm9ya3Rv
>b211Y2ggMTQzMzcyMDQxNS8xNDMzNzIwNDE1LzE0MzM3MjA0MTUgYWxsb2MgNDkvMjUvNCBjcmVh
>dCA2Mzk2LzYyNTUvNDA4NSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMDQ0NS81MjA4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA0NDUvMTQyOC80IG54cmVhZCAx
>NDMzNzIwNDQ1LzE0MzM3MjA0NDUvNDg2NiB0cnlleGNlcHQgNDMvMi8xIGZvcmsgMTQzMzcyMDQ0
>NS8xNDMzNzIwNDQ1LzQxMzEgZm9ya3Rvb211Y2ggMTQzMzcyMDQ0NS8xNDMzNzIwNDQ1LzE0MzM3
>MjA0NDUgYWxsb2MgMzAvOC80IGNyZWF0IDY0MjYvNjI4NS80MTE1IGxvY2sgMC8wLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNDczLzUyMzYvMCAodGVzdHM6IHJlYWQgMTQz
>MzcyMDQ3My8xNDU2LzE2IG54cmVhZCAxNDMzNzIwNDczLzE0MzM3MjA0NzMvNDg5NCB0cnlleGNl
>cHQgNDIvMS8wIGZvcmsgMTQzMzcyMDQ3My8xNDMzNzIwNDczLzQxNTkgZm9ya3Rvb211Y2ggMTQz
>MzcyMDQ3My8xNDMzNzIwNDczLzE0MzM3MjA0NzMgYWxsb2MgNTgvMTYvMSBjcmVhdCA2NDU0LzYz
>MTMvNDE0MyBsb2NrIDEvMS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDUw
>OC81MjcxLzAgKHRlc3RzOiByZWFkIDE0MzM3MjA1MDgvMTQ5MS8xIG54cmVhZCAxNDMzNzIwNTA4
>LzE0MzM3MjA1MDgvNDkyOSB0cnlleGNlcHQgMTkvMi8wIGZvcmsgMTQzMzcyMDUwOC8xNDMzNzIw
>NTA4LzQxOTQgZm9ya3Rvb211Y2ggMTQzMzcyMDUwOC8xNDMzNzIwNTA4LzE0MzM3MjA1MDggYWxs
>b2MgNjcvMTMvMSBjcmVhdCA2NDg5LzYzNDgvNDE3OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDU1Ni81MzE5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA1NTYv
>MTUzOS8xIG54cmVhZCAxNDMzNzIwNTU2LzE0MzM3MjA1NTYvNDk3NyB0cnlleGNlcHQgMTgvMi8w
>IGZvcmsgMTQzMzcyMDU1Ni8xNDMzNzIwNTU2LzQyNDIgZm9ya3Rvb211Y2ggMTQzMzcyMDU1Ni8x
>NDMzNzIwNTU2LzE0MzM3MjA1NTYgYWxsb2MgMjYvNC8xIGNyZWF0IDY1MzcvNjM5Ni80MjI2IGxv
>Y2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNTg0LzUzNDcvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMDU4NC8xNTY3LzcgbnhyZWFkIDE0MzM3MjA1ODQvMTQzMzcyMDU4
>NC81MDA1IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MjA1ODQvMTQzMzcyMDU4NC80MjcwIGZv
>cmt0b29tdWNoIDE0MzM3MjA1ODQvMTQzMzcyMDU4NC8xNDMzNzIwNTg0IGFsbG9jIDMyLzcvMSBj
>cmVhdCA2NTY1LzY0MjQvNDI1NCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMDY0NS81NDA4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA2NDUvMTYyOC82IG54cmVh
>ZCAxNDMzNzIwNjQ1LzE0MzM3MjA2NDUvNTA2NiB0cnlleGNlcHQgMTQvMi8xIGZvcmsgMTQzMzcy
>MDY0NS8xNDMzNzIwNjQ1LzQzMzEgZm9ya3Rvb211Y2ggMTQzMzcyMDY0NS8xNDMzNzIwNjQ1LzE0
>MzM3MjA2NDUgYWxsb2MgNDAvMTMvNiBjcmVhdCA2NjI2LzY0ODUvNDMxNSBsb2NrIDUvNS8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDY4MC81NDQzLzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjA2ODAvMTY2My8zNSBueHJlYWQgMTQzMzcyMDY4MC8xNDMzNzIwNjgwLzUxMDEgdHJ5
>ZXhjZXB0IDEvMS8xIGZvcmsgMTQzMzcyMDY4MC8xNDMzNzIwNjgwLzQzNjYgZm9ya3Rvb211Y2gg
>MTQzMzcyMDY4MC8xNDMzNzIwNjgwLzE0MzM3MjA2ODAgYWxsb2MgNzUvMTMvMiBjcmVhdCA2NjYx
>LzY1MjAvNDM1MCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcy
>MDcxNC81NDc3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA3MTQvMTY5Ny8xMiBueHJlYWQgMTQzMzcy
>MDcxNC8xNDMzNzIwNzE0LzUxMzUgdHJ5ZXhjZXB0IDQvMi8wIGZvcmsgMTQzMzcyMDcxNC8xNDMz
>NzIwNzE0LzQ0MDAgZm9ya3Rvb211Y2ggMTQzMzcyMDcxNC8xNDMzNzIwNzE0LzE0MzM3MjA3MTQg
>YWxsb2MgMzQvMS8xIGNyZWF0IDY2OTUvNjU1NC80Mzg0IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNzQxLzU1MDQvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDc0
>MS8xNzI0LzIgbnhyZWFkIDE0MzM3MjA3NDEvMTQzMzcyMDc0MS81MTYyIHRyeWV4Y2VwdCA0LzAv
>MCBmb3JrIDE0MzM3MjA3NDEvMTQzMzcyMDc0MS80NDI3IGZvcmt0b29tdWNoIDE0MzM3MjA3NDEv
>MTQzMzcyMDc0MS8xNDMzNzIwNzQxIGFsbG9jIDM5LzIvMiBjcmVhdCA2NzIyLzY1ODEvNDQxMSBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDc2NS81NTI4LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjA3NjUvMTc0OC81IG54cmVhZCAxNDMzNzIwNzY1LzE0MzM3MjA3
>NjUvNTE4NiB0cnlleGNlcHQgNC8wLzAgZm9yayAxNDMzNzIwNzY1LzE0MzM3MjA3NjUvNDQ1MSBm
>b3JrdG9vbXVjaCAxNDMzNzIwNzY1LzE0MzM3MjA3NjUvMTQzMzcyMDc2NSBhbGxvYyAzNy8xNS8z
>IGNyZWF0IDY3NDYvNjYwNS80NDM1IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIwNzkwLzU1NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDc5MC8xNzczLzIyIG54
>cmVhZCAxNDMzNzIwNzkwLzE0MzM3MjA3OTAvNTIxMSB0cnlleGNlcHQgNS8xLzAgZm9yayAxNDMz
>NzIwNzkwLzE0MzM3MjA3OTAvNDQ3NiBmb3JrdG9vbXVjaCAxNDMzNzIwNzkwLzE0MzM3MjA3OTAv
>MTQzMzcyMDc5MCBhbGxvYyAzMC8xMS8yIGNyZWF0IDY3NzEvNjYzMC80NDYwIGxvY2sgMS8xLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwODI1LzU1ODgvMCAodGVzdHM6IHJl
>YWQgMTQzMzcyMDgyNS8xODA4LzI0IG54cmVhZCAxNDMzNzIwODI1LzE0MzM3MjA4MjUvNTI0NiB0
>cnlleGNlcHQgNS8xLzEgZm9yayAxNDMzNzIwODI1LzE0MzM3MjA4MjUvNDUxMSBmb3JrdG9vbXVj
>aCAxNDMzNzIwODI1LzE0MzM3MjA4MjUvMTQzMzcyMDgyNSBhbGxvYyA0Ni8xNS82IGNyZWF0IDY4
>MDYvNjY2NS80NDk1IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIwODUzLzU2MTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDg1My8xODM2LzEgbnhyZWFkIDE0MzM3
>MjA4NTMvMTQzMzcyMDg1My81Mjc0IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjA4NTMvMTQz
>MzcyMDg1My80NTM5IGZvcmt0b29tdWNoIDE0MzM3MjA4NTMvMTQzMzcyMDg1My8xNDMzNzIwODUz
>IGFsbG9jIDE2LzYvMSBjcmVhdCA2ODM0LzY2OTMvNDUyMyBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDg4Mi81NjQ1LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA4
>ODIvMTg2NS8xIG54cmVhZCAxNDMzNzIwODgyLzE0MzM3MjA4ODIvNTMwMyB0cnlleGNlcHQgMy8y
>LzAgZm9yayAxNDMzNzIwODgyLzE0MzM3MjA4ODIvNDU2OCBmb3JrdG9vbXVjaCAxNDMzNzIwODgy
>LzE0MzM3MjA4ODIvMTQzMzcyMDg4MiBhbGxvYyAzMC82LzEgY3JlYXQgNjg2My82NzIyLzQ1NTIg
>bG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjA5MjEvNTY4NC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIwOTIxLzE5MDQvMSBueHJlYWQgMTQzMzcyMDkyMS8xNDMzNzIw
>OTIxLzUzNDIgdHJ5ZXhjZXB0IDE0LzIvMCBmb3JrIDE0MzM3MjA5MjEvMTQzMzcyMDkyMS80NjA3
>IGZvcmt0b29tdWNoIDE0MzM3MjA5MjEvMTQzMzcyMDkyMS8xNDMzNzIwOTIxIGFsbG9jIDQ1LzE3
>LzEgY3JlYXQgNjkwMi82NzYxLzQ1OTEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MjA5NDYvNTcwOS8wICh0ZXN0czogcmVhZCAxNDMzNzIwOTQ2LzE5MjkvMTEg
>bnhyZWFkIDE0MzM3MjA5NDYvMTQzMzcyMDk0Ni81MzY3IHRyeWV4Y2VwdCAzOS8zLzAgZm9yayAx
>NDMzNzIwOTQ2LzE0MzM3MjA5NDYvNDYzMiBmb3JrdG9vbXVjaCAxNDMzNzIwOTQ2LzE0MzM3MjA5
>NDYvMTQzMzcyMDk0NiBhbGxvYyAyNi8xLzEgY3JlYXQgNjkyNy82Nzg2LzQ2MTYgbG9jayAxLzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjA5NzUvNTczOC8wICh0ZXN0czog
>cmVhZCAxNDMzNzIwOTc1LzE5NTgvMjYgbnhyZWFkIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS81Mzk2
>IHRyeWV4Y2VwdCA0LzIvMCBmb3JrIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS80NjYxIGZvcmt0b29t
>dWNoIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS8xNDMzNzIwOTc1IGFsbG9jIDI2LzEwLzEgY3JlYXQg
>Njk1Ni82ODE1LzQ2NDUgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjA5OTQvNTc1Ny8wICh0ZXN0czogcmVhZCAxNDMzNzIwOTk0LzE5NzcvMTYgbnhyZWFkIDE0
>MzM3MjA5OTQvMTQzMzcyMDk5NC81NDE1IHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzIwOTk0
>LzE0MzM3MjA5OTQvNDY4MCBmb3JrdG9vbXVjaCAxNDMzNzIwOTk0LzE0MzM3MjA5OTQvMTQzMzcy
>MDk5NCBhbGxvYyAzNC8xMC8yIGNyZWF0IDY5NzUvNjgzNC80NjY0IGxvY2sgMy8zLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxMDE2LzU3NzkvMCAodGVzdHM6IHJlYWQgMTQz
>MzcyMTAxNi8xOTk5LzIgbnhyZWFkIDE0MzM3MjEwMTYvMTQzMzcyMTAxNi81NDM3IHRyeWV4Y2Vw
>dCA0LzQvMCBmb3JrIDE0MzM3MjEwMTYvMTQzMzcyMTAxNi80NzAyIGZvcmt0b29tdWNoIDE0MzM3
>MjEwMTYvMTQzMzcyMTAxNi8xNDMzNzIxMDE2IGFsbG9jIDU2LzEwLzIgY3JlYXQgNjk5Ny82ODU2
>LzQ2ODYgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEwODAv
>NTg0My8wICh0ZXN0czogcmVhZCAxNDMzNzIxMDgwLzc0Ny8yIG54cmVhZCAxNDMzNzIxMDgwLzE0
>MzM3MjEwODAvNTUwMSB0cnlleGNlcHQgMy8xLzAgZm9yayAxNDMzNzIxMDgwLzE0MzM3MjEwODAv
>NDc2NiBmb3JrdG9vbXVjaCAxNDMzNzIxMDgwLzE0MzM3MjEwODAvMTQzMzcyMTA4MCBhbGxvYyA0
>Ni8zLzIgY3JlYXQgNzA2MS82OTIwLzQ3NTAgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MjExMDYvNTg2OS8wICh0ZXN0czogcmVhZCAxNDMzNzIxMTA2Lzc3My8x
>NyBueHJlYWQgMTQzMzcyMTEwNi8xNDMzNzIxMTA2LzU1MjcgdHJ5ZXhjZXB0IDE4LzEvMSBmb3Jr
>IDE0MzM3MjExMDYvMTQzMzcyMTEwNi80NzkyIGZvcmt0b29tdWNoIDE0MzM3MjExMDYvMTQzMzcy
>MTEwNi8xNDMzNzIxMTA2IGFsbG9jIDQ3LzEzLzAgY3JlYXQgNzA4Ny82OTQ2LzQ3NzYgbG9jayAy
>LzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjExNDEvNTkwNC8wICh0ZXN0
>czogcmVhZCAxNDMzNzIxMTQxLzgwOC8xNyBueHJlYWQgMTQzMzcyMTE0MS8xNDMzNzIxMTQxLzU1
>NjIgdHJ5ZXhjZXB0IDI2LzAvMCBmb3JrIDE0MzM3MjExNDEvMTQzMzcyMTE0MS80ODI3IGZvcmt0
>b29tdWNoIDE0MzM3MjExNDEvMTQzMzcyMTE0MS8xNDMzNzIxMTQxIGFsbG9jIDU2LzExLzEgY3Jl
>YXQgNzEyMi82OTgxLzQ4MTEgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MjExNzQvNTkzNy8wICh0ZXN0czogcmVhZCAxNDMzNzIxMTc0Lzg0MS8xMCBueHJlYWQg
>MTQzMzcyMTE3NC8xNDMzNzIxMTc0LzU1OTUgdHJ5ZXhjZXB0IDEyLzIvMSBmb3JrIDE0MzM3MjEx
>NzQvMTQzMzcyMTE3NC80ODYwIGZvcmt0b29tdWNoIDE0MzM3MjExNzQvMTQzMzcyMTE3NC8xNDMz
>NzIxMTc0IGFsbG9jIDYwLzIwLzAgY3JlYXQgNzE1NS83MDE0LzQ4NDQgbG9jayAzLzMvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEyMDIvNTk2NS8wICh0ZXN0czogcmVhZCAx
>NDMzNzIxMjAyLzg2OS8zOCBueHJlYWQgMTQzMzcyMTIwMi8xNDMzNzIxMjAyLzU2MjMgdHJ5ZXhj
>ZXB0IDM2LzMvMCBmb3JrIDE0MzM3MjEyMDIvMTQzMzcyMTIwMi80ODg4IGZvcmt0b29tdWNoIDE0
>MzM3MjEyMDIvMTQzMzcyMTIwMi8xNDMzNzIxMjAyIGFsbG9jIDU4LzIwLzIgY3JlYXQgNzE4My83
>MDQyLzQ4NzIgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEy
>MzAvNTk5My8wICh0ZXN0czogcmVhZCAxNDMzNzIxMjMwLzg5Ny8xNSBueHJlYWQgMTQzMzcyMTIz
>MC8xNDMzNzIxMjMwLzU2NTEgdHJ5ZXhjZXB0IDMxLzIvMCBmb3JrIDE0MzM3MjEyMzAvMTQzMzcy
>MTIzMC80OTE2IGZvcmt0b29tdWNoIDE0MzM3MjEyMzAvMTQzMzcyMTIzMC8xNDMzNzIxMjMwIGFs
>bG9jIDg2LzE1LzEgY3JlYXQgNzIxMS83MDcwLzQ5MDAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MjEyNTYvNjAxOS8wICh0ZXN0czogcmVhZCAxNDMzNzIxMjU2
>LzkyMy81IG54cmVhZCAxNDMzNzIxMjU2LzE0MzM3MjEyNTYvNTY3NyB0cnlleGNlcHQgMTQvMi8x
>IGZvcmsgMTQzMzcyMTI1Ni8xNDMzNzIxMjU2LzQ5NDIgZm9ya3Rvb211Y2ggMTQzMzcyMTI1Ni8x
>NDMzNzIxMjU2LzE0MzM3MjEyNTYgYWxsb2MgNDUvMTMvNSBjcmVhdCA3MjM3LzcwOTYvNDkyNiBs
>b2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTI4MC82MDQzLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjEyODAvOTQ3LzEgbnhyZWFkIDE0MzM3MjEyODAvMTQzMzcyMTI4
>MC8xIHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjEyODAvMTQzMzcyMTI4MC80OTY2IGZvcmt0
>b29tdWNoIDE0MzM3MjEyODAvMTQzMzcyMTI4MC8xNDMzNzIxMjgwIGFsbG9jIDUxLzEvMSBjcmVh
>dCA3MjYxLzcxMjAvNDk1MCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMTMwNC82MDY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjEzMDQvOTcxLzI1IG54cmVhZCAx
>NDMzNzIxMzA0LzE0MzM3MjEzMDQvMTQgdHJ5ZXhjZXB0IDQvMC8wIGZvcmsgMTQzMzcyMTMwNC8x
>NDMzNzIxMzA0LzQ5OTAgZm9ya3Rvb211Y2ggMTQzMzcyMTMwNC8xNDMzNzIxMzA0LzE0MzM3MjEz
>MDQgYWxsb2MgMjUvNC8yIGNyZWF0IDcyODUvNzE0NC80OTc0IGxvY2sgNC8yLzIpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxMzM4LzYxMDEvMCAodGVzdHM6IHJlYWQgMTQzMzcy
>MTMzOC8xMDA1LzU5IG54cmVhZCAxNDMzNzIxMzM4LzE0MzM3MjEzMzgvNDggdHJ5ZXhjZXB0IDMw
>LzIvMCBmb3JrIDE0MzM3MjEzMzgvMTQzMzcyMTMzOC81MDI0IGZvcmt0b29tdWNoIDE0MzM3MjEz
>MzgvMTQzMzcyMTMzOC8xNDMzNzIxMzM4IGFsbG9jIDQzLzExLzAgY3JlYXQgNzMxOS83MTc4LzUw
>MDggbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEzODMvNjE0
>Ni8wICh0ZXN0czogcmVhZCAxNDMzNzIxMzgzLzEwNTAvNCBueHJlYWQgMTQzMzcyMTM4My8xNDMz
>NzIxMzgzLzkzIHRyeWV4Y2VwdCAxNC8yLzEgZm9yayAxNDMzNzIxMzgzLzE0MzM3MjEzODMvNTA2
>OSBmb3JrdG9vbXVjaCAxNDMzNzIxMzgzLzE0MzM3MjEzODMvMTQzMzcyMTM4MyBhbGxvYyA0NS8x
>Ny80IGNyZWF0IDczNjQvNzIyMy81MDUzIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIxNDE4LzYxODEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTQxOC8xMDg1Lzcg
>bnhyZWFkIDE0MzM3MjE0MTgvMTQzMzcyMTQxOC8xMjggdHJ5ZXhjZXB0IDIyLzEvMCBmb3JrIDE0
>MzM3MjE0MTgvMTQzMzcyMTQxOC81MTA0IGZvcmt0b29tdWNoIDE0MzM3MjE0MTgvMTQzMzcyMTQx
>OC8xNDMzNzIxNDE4IGFsbG9jIDc2LzI0LzMgY3JlYXQgNzM5OS83MjU4LzUwODggbG9jayAxLzEv
>MSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE0NTQvNjIxNy8wICh0ZXN0czog
>cmVhZCAxNDMzNzIxNDU0LzExMjEvMTEgbnhyZWFkIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC8xNjQg
>dHJ5ZXhjZXB0IDI3LzIvMCBmb3JrIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC81MTQwIGZvcmt0b29t
>dWNoIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC8xNDMzNzIxNDU0IGFsbG9jIDQzLzExLzEgY3JlYXQg
>NzQzNS83Mjk0LzUxMjQgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjE0ODkvNjI1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIxNDg5LzExNTYvMiBueHJlYWQgMTQz
>MzcyMTQ4OS8xNDMzNzIxNDg5LzE5OSB0cnlleGNlcHQgNjIvMS8xIGZvcmsgMTQzMzcyMTQ4OS8x
>NDMzNzIxNDg5LzUxNzUgZm9ya3Rvb211Y2ggMTQzMzcyMTQ4OS8xNDMzNzIxNDg5LzE0MzM3MjE0
>ODkgYWxsb2MgNDYvMTEvMiBjcmVhdCA3NDcwLzczMjkvNTE1OSBsb2NrIDIvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTUyMy82Mjg2LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MjE1MjMvMTE5MC8yNCBueHJlYWQgMTQzMzcyMTUyMy8xNDMzNzIxNTIzLzIzMyB0cnlleGNlcHQg
>NC8yLzEgZm9yayAxNDMzNzIxNTIzLzE0MzM3MjE1MjMvNTIwOSBmb3JrdG9vbXVjaCAxNDMzNzIx
>NTIzLzE0MzM3MjE1MjMvMTQzMzcyMTUyMyBhbGxvYyAyMC8xMC8wIGNyZWF0IDc1MDQvNzM2My81
>MTkzIGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxNTQ3LzYz
>MTAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTU0Ny8xMjE0LzQ4IG54cmVhZCAxNDMzNzIxNTQ3LzE0
>MzM3MjE1NDcvMjU3IHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0MzM3MjE1NDcvMTQzMzcyMTU0Ny81
>MjMzIGZvcmt0b29tdWNoIDE0MzM3MjE1NDcvMTQzMzcyMTU0Ny8xNDMzNzIxNTQ3IGFsbG9jIDQ0
>LzE5LzUgY3JlYXQgNzUyOC83Mzg3LzUyMTcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MjE1NjkvNjMzMi8wICh0ZXN0czogcmVhZCAxNDMzNzIxNTY5LzEyMzYv
>OSBueHJlYWQgMTQzMzcyMTU2OS8xNDMzNzIxNTY5LzI3OSB0cnlleGNlcHQgMi8yLzAgZm9yayAx
>NDMzNzIxNTY5LzE0MzM3MjE1NjkvNTI1NSBmb3JrdG9vbXVjaCAxNDMzNzIxNTY5LzE0MzM3MjE1
>NjkvMTQzMzcyMTU2OSBhbGxvYyAxNy85LzEgY3JlYXQgNzU1MC83NDA5LzUyMzkgbG9jayAwLzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE2MDIvNjM2NS8wICh0ZXN0czog
>cmVhZCAxNDMzNzIxNjAyLzEyNjkvMSBueHJlYWQgMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzMxMiB0
>cnlleGNlcHQgMjcvMi8wIGZvcmsgMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzUyODggZm9ya3Rvb211
>Y2ggMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzE0MzM3MjE2MDIgYWxsb2MgNTAvNS8xIGNyZWF0IDc1
>ODMvNzQ0Mi81MjcyIGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIxNjMzLzYzOTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTYzMy8xMzAwLzE1IG54cmVhZCAxNDMz
>NzIxNjMzLzE0MzM3MjE2MzMvMzQzIHRyeWV4Y2VwdCA0MS8yLzAgZm9yayAxNDMzNzIxNjMzLzE0
>MzM3MjE2MzMvNTMxOSBmb3JrdG9vbXVjaCAxNDMzNzIxNjMzLzE0MzM3MjE2MzMvMTQzMzcyMTYz
>MyBhbGxvYyA1MS81LzEgY3JlYXQgNzYxNC83NDczLzUzMDMgbG9jayAwLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE2NzkvNjQ0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIx
>Njc5LzEzNDYvMjAgbnhyZWFkIDE0MzM3MjE2NzkvMTQzMzcyMTY3OS8zODkgdHJ5ZXhjZXB0IDE1
>LzEvMSBmb3JrIDE0MzM3MjE2NzkvMTQzMzcyMTY3OS81MzY1IGZvcmt0b29tdWNoIDE0MzM3MjE2
>NzkvMTQzMzcyMTY3OS8xNDMzNzIxNjc5IGFsbG9jIDcwLzkvNCBjcmVhdCA3NjYwLzc1MTkvNTM0
>OSBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTcxOC82NDgx
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MjE3MTgvMTMzMS8xIG54cmVhZCAxNDMzNzIxNzE4LzE0MzM3
>MjE3MTgvNDI4IHRyeWV4Y2VwdCAxMS8zLzAgZm9yayAxNDMzNzIxNzE4LzE0MzM3MjE3MTgvNTQw
>NCBmb3JrdG9vbXVjaCAxNDMzNzIxNzE4LzE0MzM3MjE3MTgvMTQzMzcyMTcxOCBhbGxvYyA0OC8x
>Ny8xIGNyZWF0IDc2OTkvNzU1OC81Mzg4IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIxNzU2LzU0NTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTc1Ni83NDIvOCBu
>eHJlYWQgMTQzMzcyMTc1Ni8xNDMzNzIxNzU2LzQ2NiB0cnlleGNlcHQgMTYvMC8wIGZvcmsgMTQz
>MzcyMTc1Ni8xNDMzNzIxNzU2LzU0NDIgZm9ya3Rvb211Y2ggMTQzMzcyMTc1Ni8xNDMzNzIxNzU2
>LzE0MzM3MjE3NTYgYWxsb2MgNTUvOC8xIGNyZWF0IDc3MzcvNzU5Ni81NDI2IGxvY2sgMS8xLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxNzg4LzU0ODgvMCAodGVzdHM6IHJl
>YWQgMTQzMzcyMTc4OC83NzQvMTAgbnhyZWFkIDE0MzM3MjE3ODgvMTQzMzcyMTc4OC80OTggdHJ5
>ZXhjZXB0IDgvMi8wIGZvcmsgMTQzMzcyMTc4OC8xNDMzNzIxNzg4LzU0NzQgZm9ya3Rvb211Y2gg
>MTQzMzcyMTc4OC8xNDMzNzIxNzg4LzE0MzM3MjE3ODggYWxsb2MgMjgvMS8xIGNyZWF0IDc3Njkv
>NzYyOC81NDU4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIx
>ODIyLzU1MjIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTgyMi83NjgvMTQgbnhyZWFkIDE0MzM3MjE4
>MjIvMTQzMzcyMTgyMi81MzIgdHJ5ZXhjZXB0IDIyLzIvMSBmb3JrIDE0MzM3MjE4MjIvMTQzMzcy
>MTgyMi81NTA4IGZvcmt0b29tdWNoIDE0MzM3MjE4MjIvMTQzMzcyMTgyMi8xNDMzNzIxODIyIGFs
>bG9jIDM1LzgvNCBjcmVhdCA3ODAzLzc2NjIvNTQ5MiBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTg4Ny81NTg3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjE4ODcv
>MjA4LzE5IG54cmVhZCAxNDMzNzIxODg3LzE0MzM3MjE4ODcvNTk3IHRyeWV4Y2VwdCAyOS8yLzAg
>Zm9yayAxNDMzNzIxODg3LzE0MzM3MjE4ODcvNTU3MyBmb3JrdG9vbXVjaCAxNDMzNzIxODg3LzE0
>MzM3MjE4ODcvMTQzMzcyMTg4NyBhbGxvYyA3OS8xMC8xIGNyZWF0IDc4NjgvNzcyNy81NTU3IGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxOTEyLzU2MTIvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMTkxMi8yMzMvMTIgbnhyZWFkIDE0MzM3MjE5MTIvMTQzMzcyMTkx
>Mi82MjIgdHJ5ZXhjZXB0IDQwLzEvMSBmb3JrIDE0MzM3MjE5MTIvMTQzMzcyMTkxMi81NTk4IGZv
>cmt0b29tdWNoIDE0MzM3MjE5MTIvMTQzMzcyMTkxMi8xNDMzNzIxOTEyIGFsbG9jIDM5LzEyLzAg
>Y3JlYXQgNzg5My83NzUyLzU1ODIgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MjE5NTIvNTY1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIxOTUyLzI3My8xMiBueHJl
>YWQgMTQzMzcyMTk1Mi8xNDMzNzIxOTUyLzY2MiB0cnlleGNlcHQgNi8xLzEgZm9yayAxNDMzNzIx
>OTUyLzE0MzM3MjE5NTIvNTYzOCBmb3JrdG9vbXVjaCAxNDMzNzIxOTUyLzE0MzM3MjE5NTIvMTQz
>MzcyMTk1MiBhbGxvYyA3OS8xMi81IGNyZWF0IDc5MzMvNzc5Mi81NjIyIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxOTc4LzU2NzgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMTk3OC8yOTkvNiBueHJlYWQgMTQzMzcyMTk3OC8xNDMzNzIxOTc4LzY4OCB0cnlleGNl
>cHQgNy8zLzEgZm9yayAxNDMzNzIxOTc4LzE0MzM3MjE5NzgvNTY2NCBmb3JrdG9vbXVjaCAxNDMz
>NzIxOTc4LzE0MzM3MjE5NzgvMTQzMzcyMTk3OCBhbGxvYyAxMDUvMTYvNiBjcmVhdCA3OTU5Lzc4
>MTgvNTY0OCBsb2NrIDYvNi8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjAw
>OS81NzA5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjIwMDkvMzMwLzI0IG54cmVhZCAxNDMzNzIyMDA5
>LzE0MzM3MjIwMDkvNzE5IHRyeWV4Y2VwdCAzOC8yLzEgZm9yayAxNDMzNzIyMDA5LzE0MzM3MjIw
>MDkvNTY5NSBmb3JrdG9vbXVjaCAxNDMzNzIyMDA5LzE0MzM3MjIwMDkvMTQzMzcyMjAwOSBhbGxv
>YyAyMC84LzUgY3JlYXQgNzk5MC83ODQ5LzU2NzkgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjIwMzYvNTczNi8wICh0ZXN0czogcmVhZCAxNDMzNzIyMDM2LzM1
>Ny8xIG54cmVhZCAxNDMzNzIyMDM2LzE0MzM3MjIwMzYvNzQ2IHRyeWV4Y2VwdCAyOS8wLzAgZm9y
>ayAxNDMzNzIyMDM2LzE0MzM3MjIwMzYvNTcyMiBmb3JrdG9vbXVjaCAxNDMzNzIyMDM2LzE0MzM3
>MjIwMzYvMTQzMzcyMjAzNiBhbGxvYyAzNS8xMS8xIGNyZWF0IDgwMTcvNzg3Ni81NzA2IGxvY2sg
>MS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMDYxLzU3NjEvMCAodGVz
>dHM6IHJlYWQgMTQzMzcyMjA2MS8zODIvMTkgbnhyZWFkIDE0MzM3MjIwNjEvMTQzMzcyMjA2MS83
>NzEgdHJ5ZXhjZXB0IDYvMS8wIGZvcmsgMTQzMzcyMjA2MS8xNDMzNzIyMDYxLzU3NDcgZm9ya3Rv
>b211Y2ggMTQzMzcyMjA2MS8xNDMzNzIyMDYxLzE0MzM3MjIwNjEgYWxsb2MgNjAvMjIvMyBjcmVh
>dCA4MDQyLzc5MDEvNTczMSBsb2NrIDMvMi8yKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMjEwNi81ODA2LzAgKHRlc3RzOiByZWFkIDE0MzM3MjIxMDYvNDI3LzI4IG54cmVhZCAx
>NDMzNzIyMTA2LzE0MzM3MjIxMDYvODE2IHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzIyMTA2
>LzE0MzM3MjIxMDYvNTc5MiBmb3JrdG9vbXVjaCAxNDMzNzIyMTA2LzE0MzM3MjIxMDYvMTQzMzcy
>MjEwNiBhbGxvYyA0MC82LzYgY3JlYXQgODA4Ny83OTQ2LzU3NzYgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIxMjkvNTgyOS8wICh0ZXN0czogcmVhZCAxNDMz
>NzIyMTI5LzQ1MC8xNCBueHJlYWQgMTQzMzcyMjEyOS8xNDMzNzIyMTI5LzgzOSB0cnlleGNlcHQg
>MTUvMS8wIGZvcmsgMTQzMzcyMjEyOS8xNDMzNzIyMTI5LzU4MTUgZm9ya3Rvb211Y2ggMTQzMzcy
>MjEyOS8xNDMzNzIyMTI5LzE0MzM3MjIxMjkgYWxsb2MgMjkvOC8xIGNyZWF0IDgxMTAvNzk2OS81
>Nzk5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMTUyLzU4
>NTIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjE1Mi80NzMvNCBueHJlYWQgMTQzMzcyMjE1Mi8xNDMz
>NzIyMTUyLzg2MiB0cnlleGNlcHQgMzMvMi8wIGZvcmsgMTQzMzcyMjE1Mi8xNDMzNzIyMTUyLzU4
>MzggZm9ya3Rvb211Y2ggMTQzMzcyMjE1Mi8xNDMzNzIyMTUyLzE0MzM3MjIxNTIgYWxsb2MgMzcv
>OC8xIGNyZWF0IDgxMzMvNzk5Mi81ODIyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIyMTcwLzU4NzAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjE3MC80OTEvMyBu
>eHJlYWQgMTQzMzcyMjE3MC8xNDMzNzIyMTcwLzg4MCB0cnlleGNlcHQgMTMvMS8wIGZvcmsgMTQz
>MzcyMjE3MC8xNDMzNzIyMTcwLzU4NTYgZm9ya3Rvb211Y2ggMTQzMzcyMjE3MC8xNDMzNzIyMTcw
>LzE0MzM3MjIxNzAgYWxsb2MgNTUvMTkvMyBjcmVhdCA4MTUxLzgwMTAvNTg0MCBsb2NrIDIvMi8y
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjE5NC81ODk0LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MjIxOTQvNTE1LzI3IG54cmVhZCAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvOTA0IHRy
>eWV4Y2VwdCAzNC8yLzEgZm9yayAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvNTg4MCBmb3JrdG9vbXVj
>aCAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvMTQzMzcyMjE5NCBhbGxvYyA3OS8xNi82IGNyZWF0IDgx
>NzUvODAzNC81ODY0IGxvY2sgNi82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIyMjM2LzU5MzYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjIzNi81NTcvMTEgbnhyZWFkIDE0MzM3
>MjIyMzYvMTQzMzcyMjIzNi85NDYgdHJ5ZXhjZXB0IDcwLzIvMSBmb3JrIDE0MzM3MjIyMzYvMTQz
>MzcyMjIzNi81OTIyIGZvcmt0b29tdWNoIDE0MzM3MjIyMzYvMTQzMzcyMjIzNi8xNDMzNzIyMjM2
>IGFsbG9jIDU4LzE1LzUgY3JlYXQgODIxNy84MDc2LzU5MDYgbG9jayA1LzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIyNzIvNTk3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIy
>MjcyLzU5My81IG54cmVhZCAxNDMzNzIyMjcyLzE0MzM3MjIyNzIvOTgyIHRyeWV4Y2VwdCA1LzEv
>MSBmb3JrIDE0MzM3MjIyNzIvMTQzMzcyMjI3Mi81OTU4IGZvcmt0b29tdWNoIDE0MzM3MjIyNzIv
>MTQzMzcyMjI3Mi8xNDMzNzIyMjcyIGFsbG9jIDI2LzExLzUgY3JlYXQgODI1My84MTEyLzU5NDIg
>bG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIzMDAvNjAwMC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIyMzAwLzYyMS8yOCBueHJlYWQgMTQzMzcyMjMwMC8xNDMzNzIy
>MzAwLzEwMTAgdHJ5ZXhjZXB0IDMvMS8wIGZvcmsgMTQzMzcyMjMwMC8xNDMzNzIyMzAwLzU5ODYg
>Zm9ya3Rvb211Y2ggMTQzMzcyMjMwMC8xNDMzNzIyMzAwLzE0MzM3MjIzMDAgYWxsb2MgMjgvNi8x
>IGNyZWF0IDgyODEvODE0MC81OTcwIGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIyMzMxLzYwMzEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjMzMS82NTIvMSBueHJl
>YWQgMTQzMzcyMjMzMS8xNDMzNzIyMzMxLzEwNDEgdHJ5ZXhjZXB0IDMvMi8wIGZvcmsgMTQzMzcy
>MjMzMS8xNDMzNzIyMzMxLzYwMTcgZm9ya3Rvb211Y2ggMTQzMzcyMjMzMS8xNDMzNzIyMzMxLzE0
>MzM3MjIzMzEgYWxsb2MgMTcvMS8xIGNyZWF0IDgzMTIvODE3MS82MDAxIGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMzY3LzYwNjcvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMjM2Ny82ODgvMTQgbnhyZWFkIDE0MzM3MjIzNjcvMTQzMzcyMjM2Ny8xMDc3IHRyeWV4
>Y2VwdCAyMC8yLzAgZm9yayAxNDMzNzIyMzY3LzE0MzM3MjIzNjcvNjA1MyBmb3JrdG9vbXVjaCAx
>NDMzNzIyMzY3LzE0MzM3MjIzNjcvMTQzMzcyMjM2NyBhbGxvYyAzNy8xOS8xIGNyZWF0IDgzNDgv
>ODIwNy82MDM3IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIy
>NDAzLzYxMDMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjQwMy83MjQvNTAgbnhyZWFkIDE0MzM3MjI0
>MDMvMTQzMzcyMjQwMy8xMTEzIHRyeWV4Y2VwdCAxNC8yLzIgZm9yayAxNDMzNzIyNDAzLzE0MzM3
>MjI0MDMvNjA4OSBmb3JrdG9vbXVjaCAxNDMzNzIyNDAzLzE0MzM3MjI0MDMvMTQzMzcyMjQwMyBh
>bGxvYyAzMi82LzYgY3JlYXQgODM4NC84MjQzLzYwNzMgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MjI0MzEvNjEzMS8wICh0ZXN0czogcmVhZCAxNDMzNzIyNDMx
>Lzc1Mi8xOCBueHJlYWQgMTQzMzcyMjQzMS8xNDMzNzIyNDMxLzExNDEgdHJ5ZXhjZXB0IDYvMi8x
>IGZvcmsgMTQzMzcyMjQzMS8xNDMzNzIyNDMxLzYxMTcgZm9ya3Rvb211Y2ggMTQzMzcyMjQzMS8x
>NDMzNzIyNDMxLzE0MzM3MjI0MzEgYWxsb2MgMzQvNS81IGNyZWF0IDg0MTIvODI3MS82MTAxIGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyNDU4LzYxNTgvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMjQ1OC83NzkvNSBueHJlYWQgMTQzMzcyMjQ1OC8xNDMzNzIyNDU4
>LzExNjggdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcyMjQ1OC8xNDMzNzIyNDU4LzYxNDQgZm9y
>a3Rvb211Y2ggMTQzMzcyMjQ1OC8xNDMzNzIyNDU4LzE0MzM3MjI0NTggYWxsb2MgMzIvMTIvMSBj
>cmVhdCA4NDM5LzgyOTgvNjEyOCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMjQ5NC82MTk0LzAgKHRlc3RzOiByZWFkIDE0MzM3MjI0OTQvODE1LzIgbnhyZWFk
>IDE0MzM3MjI0OTQvMTQzMzcyMjQ5NC8xMjA0IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MjI0
>OTQvMTQzMzcyMjQ5NC82MTgwIGZvcmt0b29tdWNoIDE0MzM3MjI0OTQvMTQzMzcyMjQ5NC8xNDMz
>NzIyNDk0IGFsbG9jIDYzLzEyLzIgY3JlYXQgODQ3NS84MzM0LzYxNjQgbG9jayAxLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI1NDAvNjI0MC8wICh0ZXN0czogcmVhZCAx
>NDMzNzIyNTQwLzg2MS82IG54cmVhZCAxNDMzNzIyNTQwLzE0MzM3MjI1NDAvMTI1MCB0cnlleGNl
>cHQgMi8yLzAgZm9yayAxNDMzNzIyNTQwLzE0MzM3MjI1NDAvNjIyNiBmb3JrdG9vbXVjaCAxNDMz
>NzIyNTQwLzE0MzM3MjI1NDAvMTQzMzcyMjU0MCBhbGxvYyAxMC8xLzEgY3JlYXQgODUyMS84Mzgw
>LzYyMTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI1ODUv
>NjI4NS8wICh0ZXN0czogcmVhZCAxNDMzNzIyNTg1LzkwNi83IG54cmVhZCAxNDMzNzIyNTg1LzE0
>MzM3MjI1ODUvMTI5NSB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzIyNTg1LzE0MzM3MjI1ODUv
>NjI3MSBmb3JrdG9vbXVjaCAxNDMzNzIyNTg1LzE0MzM3MjI1ODUvMTQzMzcyMjU4NSBhbGxvYyAz
>OC8xMi83IGNyZWF0IDg1NjYvODQyNS82MjU1IGxvY2sgNy83LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzIyNjEwLzYzMTAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjYxMC85MzEv
>MTAgbnhyZWFkIDE0MzM3MjI2MTAvMTQzMzcyMjYxMC8xMzIwIHRyeWV4Y2VwdCA0LzIvMSBmb3Jr
>IDE0MzM3MjI2MTAvMTQzMzcyMjYxMC82Mjk2IGZvcmt0b29tdWNoIDE0MzM3MjI2MTAvMTQzMzcy
>MjYxMC8xNDMzNzIyNjEwIGFsbG9jIDYzLzE1LzUgY3JlYXQgODU5MS84NDUwLzYyODAgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI2NjkvNjM2OS8wICh0ZXN0
>czogcmVhZCAxNDMzNzIyNjY5Lzk5MC8xIG54cmVhZCAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvMTM3
>OSB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvNjM1NSBmb3JrdG9v
>bXVjaCAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvMTQzMzcyMjY2OSBhbGxvYyA0Ny8xLzEgY3JlYXQg
>ODY1MC84NTA5LzYzMzkgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjI2OTMvNjM5My8wICh0ZXN0czogcmVhZCAxNDMzNzIyNjkzLzEwMTQvMTQgbnhyZWFkIDE0
>MzM3MjI2OTMvMTQzMzcyMjY5My8xNDAzIHRyeWV4Y2VwdCA4LzIvMSBmb3JrIDE0MzM3MjI2OTMv
>MTQzMzcyMjY5My82Mzc5IGZvcmt0b29tdWNoIDE0MzM3MjI2OTMvMTQzMzcyMjY5My8xNDMzNzIy
>NjkzIGFsbG9jIDU2LzE0LzcgY3JlYXQgODY3NC84NTMzLzYzNjMgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI3MTYvNjQxNi8wICh0ZXN0czogcmVhZCAxNDMz
>NzIyNzE2LzEwMzcvMTQgbnhyZWFkIDE0MzM3MjI3MTYvMTQzMzcyMjcxNi8xNDI2IHRyeWV4Y2Vw
>dCAzMS84LzEgZm9yayAxNDMzNzIyNzE2LzE0MzM3MjI3MTYvNjQwMiBmb3JrdG9vbXVjaCAxNDMz
>NzIyNzE2LzE0MzM3MjI3MTYvMTQzMzcyMjcxNiBhbGxvYyAzOC84LzIgY3JlYXQgODY5Ny84NTU2
>LzYzODYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI3Mzcv
>NjQzNy8wICh0ZXN0czogcmVhZCAxNDMzNzIyNzM3LzEwNTgvMzUgbnhyZWFkIDE0MzM3MjI3Mzcv
>MTQzMzcyMjczNy8xNDQ3IHRyeWV4Y2VwdCAzMS8xLzEgZm9yayAxNDMzNzIyNzM3LzE0MzM3MjI3
>MzcvNjQyMyBmb3JrdG9vbXVjaCAxNDMzNzIyNzM3LzE0MzM3MjI3MzcvMTQzMzcyMjczNyBhbGxv
>YyA1OC8yMS80IGNyZWF0IDg3MTgvODU3Ny82NDA3IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIyNzc3LzY0NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjc3Ny8x
>MDk4LzIwIG54cmVhZCAxNDMzNzIyNzc3LzE0MzM3MjI3NzcvMTQ4NyB0cnlleGNlcHQgMjgvMy8x
>IGZvcmsgMTQzMzcyMjc3Ny8xNDMzNzIyNzc3LzY0NjMgZm9ya3Rvb211Y2ggMTQzMzcyMjc3Ny8x
>NDMzNzIyNzc3LzE0MzM3MjI3NzcgYWxsb2MgNjkvMjMvNSBjcmVhdCA4NzU4Lzg2MTcvNjQ0NyBs
>b2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjgwMy82NTAzLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjI4MDMvMTA1NS8yIG54cmVhZCAxNDMzNzIyODAzLzE0MzM3MjI4
>MDMvMTUxMyB0cnlleGNlcHQgNy8zLzAgZm9yayAxNDMzNzIyODAzLzE0MzM3MjI4MDMvNjQ4OSBm
>b3JrdG9vbXVjaCAxNDMzNzIyODAzLzE0MzM3MjI4MDMvMTQzMzcyMjgwMyBhbGxvYyA5NS8yMy8y
>IGNyZWF0IDg3ODQvODY0My82NDczIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIyODMzLzY1MzMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjgzMy8xMDg1LzIgbnhy
>ZWFkIDE0MzM3MjI4MzMvMTQzMzcyMjgzMy8xNTQzIHRyeWV4Y2VwdCA0LzEvMSBmb3JrIDE0MzM3
>MjI4MzMvMTQzMzcyMjgzMy82NTE5IGZvcmt0b29tdWNoIDE0MzM3MjI4MzMvMTQzMzcyMjgzMy8x
>NDMzNzIyODMzIGFsbG9jIDI2LzYvMiBjcmVhdCA4ODE0Lzg2NzMvNjUwMyBsb2NrIDAvMC8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjg1Ni82NTU2LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjI4NTYvMTEwOC8xOSBueHJlYWQgMTQzMzcyMjg1Ni8xNDMzNzIyODU2LzE1NjYgdHJ5
>ZXhjZXB0IDI2LzIvMiBmb3JrIDE0MzM3MjI4NTYvMTQzMzcyMjg1Ni82NTQyIGZvcmt0b29tdWNo
>IDE0MzM3MjI4NTYvMTQzMzcyMjg1Ni8xNDMzNzIyODU2IGFsbG9jIDQ5LzE5LzcgY3JlYXQgODgz
>Ny84Njk2LzY1MjYgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MjI4ODQvNjU4NC8wICh0ZXN0czogcmVhZCAxNDMzNzIyODg0LzExMzYvMjQgbnhyZWFkIDE0MzM3
>MjI4ODQvMTQzMzcyMjg4NC8xNTk0IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MjI4ODQvMTQz
>MzcyMjg4NC82NTcwIGZvcmt0b29tdWNoIDE0MzM3MjI4ODQvMTQzMzcyMjg4NC8xNDMzNzIyODg0
>IGFsbG9jIDM1LzgvMiBjcmVhdCA4ODY1Lzg3MjQvNjU1NCBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjk0NS82NjQ1LzAgKHRlc3RzOiByZWFkIDE0MzM3MjI5
>NDUvMTE5Ny8xIG54cmVhZCAxNDMzNzIyOTQ1LzE0MzM3MjI5NDUvMTY1NSB0cnlleGNlcHQgNS8y
>LzAgZm9yayAxNDMzNzIyOTQ1LzE0MzM3MjI5NDUvNjYzMSBmb3JrdG9vbXVjaCAxNDMzNzIyOTQ1
>LzE0MzM3MjI5NDUvMTQzMzcyMjk0NSBhbGxvYyAzNS85LzEgY3JlYXQgODkyNi84Nzg1LzY2MTUg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI5ODQvNjY4NC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIyOTg0LzEyMzYvMTEgbnhyZWFkIDE0MzM3MjI5ODQvMTQzMzcy
>Mjk4NC8xNjk0IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjI5ODQvMTQzMzcyMjk4NC82Njcw
>IGZvcmt0b29tdWNoIDE0MzM3MjI5ODQvMTQzMzcyMjk4NC8xNDMzNzIyOTg0IGFsbG9jIDU0LzYv
>MSBjcmVhdCA4OTY1Lzg4MjQvNjY1NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcyMzA1Mi82NzUyLzAgKHRlc3RzOiByZWFkIDE0MzM3MjMwNTIvMTMwNC8xOSBu
>eHJlYWQgMTQzMzcyMzA1Mi8xNDMzNzIzMDUyLzE3NjIgdHJ5ZXhjZXB0IDM2LzIvMSBmb3JrIDE0
>MzM3MjMwNTIvMTQzMzcyMzA1Mi82NzM4IGZvcmt0b29tdWNoIDE0MzM3MjMwNTIvMTQzMzcyMzA1
>Mi8xNDMzNzIzMDUyIGFsbG9jIDM3LzE5LzYgY3JlYXQgOTAzMy84ODkyLzY3MjIgbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMwODIvNjc4Mi8wICh0ZXN0czog
>cmVhZCAxNDMzNzIzMDgyLzEzMzQvOSBueHJlYWQgMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzE3OTIg
>dHJ5ZXhjZXB0IDQvMS8wIGZvcmsgMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzY3NjggZm9ya3Rvb211
>Y2ggMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzE0MzM3MjMwODIgYWxsb2MgNjcvOS8yIGNyZWF0IDkw
>NjMvODkyMi82NzUyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIzMTA5LzY4MDkvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzEwOS8xMzYxLzEzIG54cmVhZCAxNDMz
>NzIzMTA5LzE0MzM3MjMxMDkvMTgxOSB0cnlleGNlcHQgNy8yLzEgZm9yayAxNDMzNzIzMTA5LzE0
>MzM3MjMxMDkvNjc5NSBmb3JrdG9vbXVjaCAxNDMzNzIzMTA5LzE0MzM3MjMxMDkvMTQzMzcyMzEw
>OSBhbGxvYyA0MC85LzMgY3JlYXQgOTA5MC84OTQ5LzY3NzkgbG9jayAzLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMxMjYvNjgyNi8wICh0ZXN0czogcmVhZCAxNDMzNzIz
>MTI2LzEzNzgvMTcgbnhyZWFkIDE0MzM3MjMxMjYvMTQzMzcyMzEyNi8xODM2IHRyeWV4Y2VwdCAy
>My8xLzEgZm9yayAxNDMzNzIzMTI2LzE0MzM3MjMxMjYvNjgxMiBmb3JrdG9vbXVjaCAxNDMzNzIz
>MTI2LzE0MzM3MjMxMjYvMTQzMzcyMzEyNiBhbGxvYyA1Ny8xMy80IGNyZWF0IDkxMDcvODk2Ni82
>Nzk2IGxvY2sgMi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzMTU2LzY4
>NTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzE1Ni8xNDA4LzEzIG54cmVhZCAxNDMzNzIzMTU2LzE0
>MzM3MjMxNTYvMTg2NiB0cnlleGNlcHQgMi8yLzAgZm9yayAxNDMzNzIzMTU2LzE0MzM3MjMxNTYv
>Njg0MiBmb3JrdG9vbXVjaCAxNDMzNzIzMTU2LzE0MzM3MjMxNTYvMTQzMzcyMzE1NiBhbGxvYyA1
>Ni8yMi8xIGNyZWF0IDkxMzcvODk5Ni82ODI2IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzIzMjAwLzY5MDAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzIwMC8xNDIy
>LzQgbnhyZWFkIDE0MzM3MjMyMDAvMTQzMzcyMzIwMC8xOTEwIHRyeWV4Y2VwdCAxMy8yLzEgZm9y
>ayAxNDMzNzIzMjAwLzE0MzM3MjMyMDAvNjg4NiBmb3JrdG9vbXVjaCAxNDMzNzIzMjAwLzE0MzM3
>MjMyMDAvMTQzMzcyMzIwMCBhbGxvYyA0MC8xMS8wIGNyZWF0IDkxODEvOTA0MC82ODcwIGxvY2sg
>My8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzMjQxLzY5NDEvMCAodGVz
>dHM6IHJlYWQgMTQzMzcyMzI0MS80NS83IG54cmVhZCAxNDMzNzIzMjQxLzE0MzM3MjMyNDEvMTk1
>MSB0cnlleGNlcHQgMjYvMi8xIGZvcmsgMTQzMzcyMzI0MS8xNDMzNzIzMjQxLzY5MjcgZm9ya3Rv
>b211Y2ggMTQzMzcyMzI0MS8xNDMzNzIzMjQxLzE0MzM3MjMyNDEgYWxsb2MgNDEvMTUvMCBjcmVh
>dCA5MjIyLzkwODEvNjkxMSBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMzI2OS82OTY5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjMyNjkvMzUvNiBueHJlYWQgMTQz
>MzcyMzI2OS8xNDMzNzIzMjY5LzE5NzkgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcyMzI2OS8x
>NDMzNzIzMjY5LzY5NTUgZm9ya3Rvb211Y2ggMTQzMzcyMzI2OS8xNDMzNzIzMjY5LzE0MzM3MjMy
>NjkgYWxsb2MgNDMvMTEvNiBjcmVhdCA5MjUwLzkxMDkvNjkzOSBsb2NrIDQvNC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzI5OC82OTk4LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MjMyOTgvNjQvMTQgbnhyZWFkIDE0MzM3MjMyOTgvMTQzMzcyMzI5OC8yMDA4IHRyeWV4Y2VwdCA4
>LzgvMCBmb3JrIDE0MzM3MjMyOTgvMTQzMzcyMzI5OC82OTg0IGZvcmt0b29tdWNoIDE0MzM3MjMy
>OTgvMTQzMzcyMzI5OC8xNDMzNzIzMjk4IGFsbG9jIDQwLzE0LzkgY3JlYXQgOTI3OS85MTM4LzY5
>NjggbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMzNDAvNzA0
>MC8wICh0ZXN0czogcmVhZCAxNDMzNzIzMzQwLzEwNi8xIG54cmVhZCAxNDMzNzIzMzQwLzE0MzM3
>MjMzNDAvMjA1MCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzMzQwLzE0MzM3MjMzNDAvNzAy
>NiBmb3JrdG9vbXVjaCAxNDMzNzIzMzQwLzE0MzM3MjMzNDAvMTQzMzcyMzM0MCBhbGxvYyAzMS82
>LzEgY3JlYXQgOTMyMS85MTgwLzcwMTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MjMzNjUvNzA2NS8wICh0ZXN0czogcmVhZCAxNDMzNzIzMzY1LzEzMS8yNiBu
>eHJlYWQgMTQzMzcyMzM2NS8xNDMzNzIzMzY1LzIwNzUgdHJ5ZXhjZXB0IDE5LzAvMCBmb3JrIDE0
>MzM3MjMzNjUvMTQzMzcyMzM2NS83MDUxIGZvcmt0b29tdWNoIDE0MzM3MjMzNjUvMTQzMzcyMzM2
>NS8xNDMzNzIzMzY1IGFsbG9jIDMxLzUvMSBjcmVhdCA5MzQ2LzkyMDUvNzAzNSBsb2NrIDEvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzM4Ni83MDg2LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MjMzODYvMTUyLzE4IG54cmVhZCAxNDMzNzIzMzg2LzE0MzM3MjMzODYvMjA5NiB0
>cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzMzg2LzE0MzM3MjMzODYvNzA3MiBmb3JrdG9vbXVj
>aCAxNDMzNzIzMzg2LzE0MzM3MjMzODYvMTQzMzcyMzM4NiBhbGxvYyA1Mi82LzEgY3JlYXQgOTM2
>Ny85MjI2LzcwNTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MjM0MzUvNzEzNS8wICh0ZXN0czogcmVhZCAxNDMzNzIzNDM1LzIwMS8xIG54cmVhZCAxNDMzNzIz
>NDM1LzE0MzM3MjM0MzUvMjE0NSB0cnlleGNlcHQgNC8zLzAgZm9yayAxNDMzNzIzNDM1LzE0MzM3
>MjM0MzUvNzEyMSBmb3JrdG9vbXVjaCAxNDMzNzIzNDM1LzE0MzM3MjM0MzUvMTQzMzcyMzQzNSBh
>bGxvYyA0My8xNC8xIGNyZWF0IDk0MTYvOTI3NS83MTA1IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIzNDYyLzcxNjIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzQ2
>Mi8yMjgvMjMgbnhyZWFkIDE0MzM3MjM0NjIvMTQzMzcyMzQ2Mi8yMTcyIHRyeWV4Y2VwdCAyLzIv
>MiBmb3JrIDE0MzM3MjM0NjIvMTQzMzcyMzQ2Mi83MTQ4IGZvcmt0b29tdWNoIDE0MzM3MjM0NjIv
>MTQzMzcyMzQ2Mi8xNDMzNzIzNDYyIGFsbG9jIDQ1LzcvMCBjcmVhdCA5NDQzLzkzMDIvNzEzMiBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzUxMi83MjEyLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjM1MTIvMjc4LzkgbnhyZWFkIDE0MzM3MjM1MTIvMTQzMzcyMzUx
>Mi8yMjIyIHRyeWV4Y2VwdCA0Mi8yLzEgZm9yayAxNDMzNzIzNTEyLzE0MzM3MjM1MTIvNzE5OCBm
>b3JrdG9vbXVjaCAxNDMzNzIzNTEyLzE0MzM3MjM1MTIvMTQzMzcyMzUxMiBhbGxvYyAyMi85LzQg
>Y3JlYXQgOTQ5My85MzUyLzcxODIgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MjM1NDAvNzI0MC8wICh0ZXN0czogcmVhZCAxNDMzNzIzNTQwLzMwNi82IG54cmVh
>ZCAxNDMzNzIzNTQwLzE0MzM3MjM1NDAvMjI1MCB0cnlleGNlcHQgNDYvMS8wIGZvcmsgMTQzMzcy
>MzU0MC8xNDMzNzIzNTQwLzcyMjYgZm9ya3Rvb211Y2ggMTQzMzcyMzU0MC8xNDMzNzIzNTQwLzE0
>MzM3MjM1NDAgYWxsb2MgNDUvMTAvMiBjcmVhdCA5NTIxLzkzODAvNzIxMCBsb2NrIDIvMi8yKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzU5OC83Mjk4LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjM1OTgvMzY0LzEgbnhyZWFkIDE0MzM3MjM1OTgvMTQzMzcyMzU5OC8yMzA4IHRyeWV4
>Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjM1OTgvMTQzMzcyMzU5OC83Mjg0IGZvcmt0b29tdWNoIDE0
>MzM3MjM1OTgvMTQzMzcyMzU5OC8xNDMzNzIzNTk4IGFsbG9jIDM5LzYvMSBjcmVhdCA5NTc5Lzk0
>MzgvNzI2OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzYy
>MC83MzIwLzAgKHRlc3RzOiByZWFkIDE0MzM3MjM2MjAvMzg2LzYgbnhyZWFkIDE0MzM3MjM2MjAv
>MTQzMzcyMzYyMC8yMzMwIHRyeWV4Y2VwdCA5LzEvMSBmb3JrIDE0MzM3MjM2MjAvMTQzMzcyMzYy
>MC83MzA2IGZvcmt0b29tdWNoIDE0MzM3MjM2MjAvMTQzMzcyMzYyMC8xNDMzNzIzNjIwIGFsbG9j
>IDYxLzE3LzYgY3JlYXQgOTYwMS85NDYwLzcyOTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjM2NTEvNzM1MS8wICh0ZXN0czogcmVhZCAxNDMzNzIzNjUxLzQx
>Ny8xMCBueHJlYWQgMTQzMzcyMzY1MS8xNDMzNzIzNjUxLzIzNjEgdHJ5ZXhjZXB0IDM4LzgvMCBm
>b3JrIDE0MzM3MjM2NTEvMTQzMzcyMzY1MS83MzM3IGZvcmt0b29tdWNoIDE0MzM3MjM2NTEvMTQz
>MzcyMzY1MS8xNDMzNzIzNjUxIGFsbG9jIDY1LzEzLzEgY3JlYXQgOTYzMi85NDkxLzczMjEgbG9j
>ayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM2NzIvNzM3Mi8wICh0
>ZXN0czogcmVhZCAxNDMzNzIzNjcyLzQzOC84IG54cmVhZCAxNDMzNzIzNjcyLzE0MzM3MjM2NzIv
>MjM4MiB0cnlleGNlcHQgMjkvMi8yIGZvcmsgMTQzMzcyMzY3Mi8xNDMzNzIzNjcyLzczNTggZm9y
>a3Rvb211Y2ggMTQzMzcyMzY3Mi8xNDMzNzIzNjcyLzE0MzM3MjM2NzIgYWxsb2MgNzUvMjIvNyBj
>cmVhdCA5NjUzLzk1MTIvNzM0MiBsb2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMzczMC83NDMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MjM3MzAvNDk2LzIxIG54cmVh
>ZCAxNDMzNzIzNzMwLzE0MzM3MjM3MzAvMjQ0MCB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzIz
>NzMwLzE0MzM3MjM3MzAvNzQxNiBmb3JrdG9vbXVjaCAxNDMzNzIzNzMwLzE0MzM3MjM3MzAvMTQz
>MzcyMzczMCBhbGxvYyA1OC8yMS8wIGNyZWF0IDk3MTEvOTU3MC83NDAwIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzNzU4Lzc0NTgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMzc1OC81MjQvMjMgbnhyZWFkIDE0MzM3MjM3NTgvMTQzMzcyMzc1OC8yNDY4IHRyeWV4
>Y2VwdCA3LzIvMiBmb3JrIDE0MzM3MjM3NTgvMTQzMzcyMzc1OC83NDQ0IGZvcmt0b29tdWNoIDE0
>MzM3MjM3NTgvMTQzMzcyMzc1OC8xNDMzNzIzNzU4IGFsbG9jIDI4LzE5LzUgY3JlYXQgOTczOS85
>NTk4Lzc0MjggbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM3
>ODcvNzQ4Ny8wICh0ZXN0czogcmVhZCAxNDMzNzIzNzg3LzU1My8xIG54cmVhZCAxNDMzNzIzNzg3
>LzE0MzM3MjM3ODcvMjQ5NyB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzNzg3LzE0MzM3MjM3
>ODcvNzQ3MyBmb3JrdG9vbXVjaCAxNDMzNzIzNzg3LzE0MzM3MjM3ODcvMTQzMzcyMzc4NyBhbGxv
>YyA0OC8xMC8xIGNyZWF0IDk3NjgvOTYyNy83NDU3IGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIzODIwLzc1MjAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzgyMC81
>ODYvNiBueHJlYWQgMTQzMzcyMzgyMC8xNDMzNzIzODIwLzI1MzAgdHJ5ZXhjZXB0IDMwLzMvMCBm
>b3JrIDE0MzM3MjM4MjAvMTQzMzcyMzgyMC83NTA2IGZvcmt0b29tdWNoIDE0MzM3MjM4MjAvMTQz
>MzcyMzgyMC8xNDMzNzIzODIwIGFsbG9jIDQzLzkvMSBjcmVhdCA5ODAxLzk2NjAvNzQ5MCBsb2Nr
>IDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzg1Ny83NTU3LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MjM4NTcvNjIzLzEzIG54cmVhZCAxNDMzNzIzODU3LzE0MzM3MjM4NTcv
>MjU2NyB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzODU3LzE0MzM3MjM4NTcvNzU0MyBmb3Jr
>dG9vbXVjaCAxNDMzNzIzODU3LzE0MzM3MjM4NTcvMTQzMzcyMzg1NyBhbGxvYyA0Ni8xLzEgY3Jl
>YXQgOTgzOC85Njk3Lzc1MjcgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MjM4ODMvNzU4My8wICh0ZXN0czogcmVhZCAxNDMzNzIzODgzLzY0OS8zOSBueHJlYWQg
>MTQzMzcyMzg4My8xNDMzNzIzODgzLzI1OTMgdHJ5ZXhjZXB0IDEwLzIvMSBmb3JrIDE0MzM3MjM4
>ODMvMTQzMzcyMzg4My83NTY5IGZvcmt0b29tdWNoIDE0MzM3MjM4ODMvMTQzMzcyMzg4My8xNDMz
>NzIzODgzIGFsbG9jIDIyLzExLzAgY3JlYXQgOTg2NC85NzIzLzc1NTMgbG9jayA1LzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM5MDcvNzYwNy8wICh0ZXN0czogcmVhZCAx
>NDMzNzIzOTA3LzY3My8zIG54cmVhZCAxNDMzNzIzOTA3LzE0MzM3MjM5MDcvMjYxNyB0cnlleGNl
>cHQgMzMvMS8xIGZvcmsgMTQzMzcyMzkwNy8xNDMzNzIzOTA3Lzc1OTMgZm9ya3Rvb211Y2ggMTQz
>MzcyMzkwNy8xNDMzNzIzOTA3LzE0MzM3MjM5MDcgYWxsb2MgMzUvMy8zIGNyZWF0IDk4ODgvOTc0
>Ny83NTc3IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzOTI2
>Lzc2MjYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzkyNi82OTIvMTkgbnhyZWFkIDE0MzM3MjM5MjYv
>MTQzMzcyMzkyNi8yNjM2IHRyeWV4Y2VwdCA1Mi8yLzEgZm9yayAxNDMzNzIzOTI2LzE0MzM3MjM5
>MjYvNzYxMiBmb3JrdG9vbXVjaCAxNDMzNzIzOTI2LzE0MzM3MjM5MjYvMTQzMzcyMzkyNiBhbGxv
>YyA1NC8xOS80IGNyZWF0IDk5MDcvOTc2Ni83NTk2IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIzOTUxLzc2NTEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzk1MS83
>MTcvMTEgbnhyZWFkIDE0MzM3MjM5NTEvMTQzMzcyMzk1MS8yNjYxIHRyeWV4Y2VwdCAyNi8zLzEg
>Zm9yayAxNDMzNzIzOTUxLzE0MzM3MjM5NTEvNzYzNyBmb3JrdG9vbXVjaCAxNDMzNzIzOTUxLzE0
>MzM3MjM5NTEvMTQzMzcyMzk1MSBhbGxvYyA1OS8xMS81IGNyZWF0IDk5MzIvOTc5MS83NjIxIGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzOTc0Lzc2NzQvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMzk3NC83NDAvMiBueHJlYWQgMTQzMzcyMzk3NC8xNDMzNzIzOTc0
>LzI2ODQgdHJ5ZXhjZXB0IDUvMy8wIGZvcmsgMTQzMzcyMzk3NC8xNDMzNzIzOTc0Lzc2NjAgZm9y
>a3Rvb211Y2ggMTQzMzcyMzk3NC8xNDMzNzIzOTc0LzE0MzM3MjM5NzQgYWxsb2MgNTIvNC8yIGNy
>ZWF0IDk5NTUvOTgxNC83NjQ0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzI0MDE1Lzc3MTUvMCAodGVzdHM6IHJlYWQgMTQzMzcyNDAxNS83ODEvMSBueHJlYWQg
>MTQzMzcyNDAxNS8xNDMzNzI0MDE1LzI3MjUgdHJ5ZXhjZXB0IDQ0LzMvMCBmb3JrIDE0MzM3MjQw
>MTUvMTQzMzcyNDAxNS83NzAxIGZvcmt0b29tdWNoIDE0MzM3MjQwMTUvMTQzMzcyNDAxNS8xNDMz
>NzI0MDE1IGFsbG9jIDYxLzYvMSBjcmVhdCA5OTk2Lzk4NTUvNzY4NSBsb2NrIDIvMi8xKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyNDA1MC83NzUwLzAgKHRlc3RzOiByZWFkIDE0
>MzM3MjQwNTAvODE2LzEgbnhyZWFkIDE0MzM3MjQwNTAvMTQzMzcyNDA1MC8yNzYwIHRyeWV4Y2Vw
>dCAzLzIvMCBmb3JrIDE0MzM3MjQwNTAvMTQzMzcyNDA1MC83NzM2IGZvcmt0b29tdWNoIDE0MzM3
>MjQwNTAvMTQzMzcyNDA1MC8xNDMzNzI0MDUwIGFsbG9jIDQ1LzYvMSBjcmVhdCAxMDAzMS85ODkw
>Lzc3MjAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjQwODAv
>Nzc4MC8wICh0ZXN0czogcmVhZCAxNDMzNzI0MDgwLzg0Ni85IG54cmVhZCAxNDMzNzI0MDgwLzE0
>MzM3MjQwODAvMjc5MCB0cnlleGNlcHQgMTIvMC8wIGZvcmsgMTQzMzcyNDA4MC8xNDMzNzI0MDgw
>Lzc3NjYgZm9ya3Rvb211Y2ggMTQzMzcyNDA4MC8xNDMzNzI0MDgwLzE0MzM3MjQwODAgYWxsb2Mg
>MzYvMTUvMiBjcmVhdCAxMDA2MS85OTIwLzc3NTAgbG9jayAyLzIvMikKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjQxMDQvNzgwNC8wICh0ZXN0czogcmVhZCAxNDMzNzI0MTA0Lzg3
>MC8zIG54cmVhZCAxNDMzNzI0MTA0LzE0MzM3MjQxMDQvMjgxNCB0cnlleGNlcHQgMzMvMS8wIGZv
>cmsgMTQzMzcyNDEwNC8xNDMzNzI0MTA0Lzc3OTAgZm9ya3Rvb211Y2ggMTQzMzcyNDEwNC8xNDMz
>NzI0MTA0LzE0MzM3MjQxMDQgYWxsb2MgMzkvMTIvMyBjcmVhdCAxMDA4NS85OTQ0Lzc3NzQgbG9j
>ayAyLzIvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjQxNDkvNzg0OS8wICh0
>ZXN0czogcmVhZCAxNDMzNzI0MTQ5LzkxNS8zNCBueHJlYWQgMTQzMzcyNDE0OS8xNDMzNzI0MTQ5
>LzI4NTkgdHJ5ZXhjZXB0IDQzLzIvMCBmb3JrIDE0MzM3MjQxNDkvMTQzMzcyNDE0OS83ODM1IGZv
>cmt0b29tdWNoIDE0MzM3MjQxNDkvMTQzMzcyNDE0OS8xNDMzNzI0MTQ5IGFsbG9jIDQyLzEyLzEg
>Y3JlYXQgMTAxMzAvOTk4OS83ODE5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzI0MTgwLzc4ODAvMCAodGVzdHM6IHJlYWQgMTQzMzcyNDE4MC85NDYvMSBueHJl
>YWQgMTQzMzcyNDE4MC8xNDMzNzI0MTgwLzI4OTAgdHJ5ZXhjZXB0IDE1LzIvMCBmb3JrIDE0MzM3
>MjQxODAvMTQzMzcyNDE4MC83ODY2IGZvcmt0b29tdWNoIDE0MzM3MjQxODAvMTQzMzcyNDE4MC8x
>NDMzNzI0MTgwIGFsbG9jIDU5LzU=
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn--


From dmuysers at hotmail.com  Sat Jul  4 11:48:08 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 4 Jul 2015 11:48:08 +0200
Subject: [M3devel] Arithmetic Shift
Message-ID: <DUB127-DS2AA4B1C47C4D0A19C4634DD950@phx.gbl>

Why is there no arithmetic right shift operation in Modula-3 ?

Oberon software has a clever way to minimally encode
signed integers independently of their size.

PROCEDURE WriteInt (i: INTEGER) =
  BEGIN
    WHILE x < ?64 OR x > 63 DO
      Write (VAL (i MOD 128 + 128, CHAR));
      i := i DIV 128;
    END;
    Write (VAL (i MOD 128), CHAR));
  END Write;

Unfortunately it is impossible to implement the corresponding
decoder in M3, because it requires an arithmetic right shift
where the sign bit is replicated into the left end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150704/1b90114c/attachment-0001.html>

From dmuysers at hotmail.com  Sat Jul  4 12:31:46 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 4 Jul 2015 12:31:46 +0200
Subject: [M3devel] Arithmetic Shift
In-Reply-To: <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu>
References: <DUB127-DS2AA4B1C47C4D0A19C4634DD950@phx.gbl>
 <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu>
Message-ID: <DUB127-DS3CEC4034F7BA584E67E9EDD950@phx.gbl>

Sure, but then, since the amount of shift is a variable, it will oblige one
to index into a table of such constants, which is rather clumsy, and
possibly (?) poorly optimised by the compiler.

PROCEDURE ReadInt (VAR x: INTEGER) =
  VAR ch: CHAR;  n, y := 0;
  BEGIN
    Read (ch);
    WHILE ch >= 128 DO
      INC (y, Word.LeftShift (ORD (ch) - 128, n));
      INC (n, 7);
      Read (ch)
    END;
    x := arithmetic-shift (Word.LeftShift (ORD (ch), 25), n - 25) + y
  END ReadInt;

From: Antony Hosking 
Sent: Saturday, July 04, 2015 12:11 PM
To: dirk muysers 
Cc: m3devel at elegosoft.com 
Subject: Re: [M3devel] Arithmetic Shift

In this code you use DIV by a constant power of two.  That will turn into an arithmetic right shift. 

  On Jul 4, 2015, at 7:48 PM, dirk muysers <dmuysers at hotmail.com> wrote:

  Why is there no arithmetic right shift operation in Modula-3 ?

  Oberon software has a clever way to minimally encode
  signed integers independently of their size.

  PROCEDURE WriteInt (i: INTEGER) =
    BEGIN
      WHILE x < ?64 OR x > 63 DO
        Write (VAL (i MOD 128 + 128, CHAR));
        i := i DIV 128;
      END;
      Write (VAL (i MOD 128), CHAR));
    END Write;

  Unfortunately it is impossible to implement the corresponding
  decoder in M3, because it requires an arithmetic right shift
  where the sign bit is replicated into the left end.
  _______________________________________________
  M3devel mailing list
  M3devel at elegosoft.com
  https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150704/beadc2c2/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jul 18 10:27:41 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 08:27:41 +0000
Subject: [M3devel] switching to C backend?
Message-ID: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>

Any objection if I start switching targets to the C backend?
In particular, Darwin does not support m3gdb, so debuggability is not a factor.
Thanks, - Jay



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/a1410c75/attachment-0001.html>

From dmuysers at hotmail.com  Sat Jul 18 10:42:14 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 18 Jul 2015 10:42:14 +0200
Subject: [M3devel] switching to C backend?
In-Reply-To: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>
References: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>
Message-ID: <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>

May I remind you Norman Ramsey?s opinion on the subject:



Code generation is my business :-)

Comments on a few options:

  a.. CLR: 

    a.. Pro: industrial support 
    b.. Con: you have to buy into their type system pretty much completely; depending on what you want to do with types, this may not matter 
    c.. Con: Only Windows platform is really prime-time quality
  b.. LLVM:

    a.. Pro: enthusiastic user community with charismatic leader 
    b.. Pro: many interesting performance improvements 
    c.. Con: somewhat complex interface 
    d.. Con: history of holes in the engineering; as LLVM matures expect the holes in the engineering to be plugged by adding to the complexity of the interface
  c.. C--

    a.. Pro: target is an actual written language, not an API; you can easily inspect, debug, and edit your C-- code 
    b.. Pro: design is reasonably mature and reasonably clean 
    c.. Pro: supports accurate garbage collection 
    d.. Pro: most users report it is very easy to use 
    e.. Con: very small development team 
    f.. Con: as of early 2009, supports only three hardware platforms (x86, PPC, ARM) 
    g.. Con: does not ship with a garbage collector 
    h.. Con: future of project is uncertain
  d.. C as target language

    a.. Pro: looks easy 
    b.. Con: nearly impossible to get decent performance 
    c.. Con: will drive you nuts in the long run; ask the long line of people who have tried to compile Haskell, ML, Modula-3, Scheme and more using this technique. At some point every one of these people gave up and built their own native code generator.
Summary: anything except C is a reasonable choice. For the best combination of flexibility, quality, and expected longevity, I'd probably recommend LLVM. But your example code is very close to C--, so that may be an advantage.

Full disclosure: I am affiliated with the C-- project.


From: Jay K 
Sent: Saturday, July 18, 2015 10:27 AM
To: m3devel 
Subject: [M3devel] switching to C backend?

Any objection if I start switching targets to the C backend? 

In particular, Darwin does not support m3gdb, so debuggability is not a factor.

Thanks,
- Jay







--------------------------------------------------------------------------------
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/0900c2cf/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jul 18 10:48:09 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 08:48:09 +0000
Subject: [M3devel] representing word size in IR target-independently?
Message-ID: <COL130-W38AE30909909E4B9AF5E37E6870@phx.gbl>

 Ideally there would be one target-independent IR for, for example: 


 VAR a := BYTESIZE(INTEGER);   VAR b := BITSIZE(INTEGER) = 64;   TYPE T1 = RECORD a,b:INTEGER END;   CONST pt1: REF T1 = NIL;   VAR offset_of_b := LOOPHOLE(INTEGER, ADR(pt1.b));  


 so that it could be translated to target-independent C something like: 

 #if ...almost always true...   typedef ptrdiff_t INTEGER;  #else  ...  #endif   INTEGER a = sizeof(INTEGER);  typedef unsigned char BOOLEAN;   BOOLEAN b = (sizeof(INTEGER) * 8) == 64;   typedef struct { a,b:INTEGER; } T1;  T1* pt1;  // ideal but unlikely:  INTEGER offset_of_b = offsetof(T1, b);  // more likely:   INTEGER offset_of_b;  void module_initializer()  {    offset_of_b = (INTEGER)&pt1->b;  } 
  
Is this feasible?


 Can instances of "INTEGER" somehow be left higher level for resolution  by the backend? Or can they be left "dual", both "resolved" and "symbolic"?  Or would this require too much change?
 
 I would be very reluctantly satisfied if the frontend ran  a certain portion of itself twice, once for each word size, indicating  the start/end of the passes to the backend, so the generated C would  be doubled up with an #if something like: 

#if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || defined(__ppc64__) ...
 ... everything ... 
 #else // 32 bit 
 ... everything ... 
 #endif

The agenda is target-independent C output from the C backend,as a portable redistributable form.This is approximately one of the three problems to solve to achieve that.


Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/68359d67/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jul 18 11:02:03 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 09:02:03 +0000
Subject: [M3devel] switching to C backend?
In-Reply-To: <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>
References: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>,
 <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>
Message-ID: <COL130-W699475F4DD964C1D9FA199E6870@phx.gbl>

 I disagree.  The system is working. This isn't speculation.
  Using his terminology  
  C pros:   - written language (also a con)   - longevity   - does not drive me nuts   - design is very mature    - looks easy and is easy   - huge portability of implementation   - potential portability of object code    - debugability with stock debuggers    - large development teams ("back back end")  - multiple industrial strength "back back ends"   - likely similar compiled performance as anything else   - probably similar compiled performance 

 C cons:   - compiler performance     - debuggability on platforms that have m3gdb support    - cannot always efficiently express things portably,     in particular, portable C has the same inefficient exception      handling; we need to switch to C++ to fix it, or non-portable C      on some platforms (i.e. win32 __try)       
 For garbage collection, I believe C, m3cc, and llvm are currently all equivalent and not good. 
    - Jay



From: dmuysers at hotmail.com
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] switching to C backend?
Date: Sat, 18 Jul 2015 10:42:14 +0200








May I remind you Norman Ramsey?s opinion on the 
subject:

 

Code generation is my business :-)

Comments on a few options:


  
  CLR: 

  
    Pro: industrial support 
    Con: you have to buy into their type system 
    pretty much completely; depending on what you want to do with types, this 
    may not matter 
    Con: Only Windows platform is really 
    prime-time quality
  
  LLVM:

  
    Pro: enthusiastic user community with 
    charismatic leader 
    Pro: many interesting performance 
    improvements 
    Con: somewhat complex interface 
    Con: history of holes in the engineering; 
    as LLVM matures expect the holes in the engineering to be plugged by adding 
    to the complexity of the interface
  
  C--

  
    Pro: target is an actual written language, 
    not an API; you can easily inspect, debug, and edit your C-- code 
    Pro: design is reasonably mature and 
    reasonably clean 
    Pro: supports accurate garbage 
    collection 
    Pro: most users report it is very easy to 
    use 
    Con: very small development team 
    Con: as of early 2009, supports only three 
    hardware platforms (x86, PPC, ARM) 
    Con: does not ship with a garbage 
    collector 
    Con: future of project is 
    uncertain
  
  C as target language

  
    Pro: looks easy 
    Con: nearly impossible to get decent 
    performance 
    Con: will drive you nuts in the long run; 
    ask the long line of people who have tried to compile Haskell, ML, Modula-3, 
    Scheme and more using this technique. At some point every one of these 
    people gave up and built their own native code 
generator.
Summary: anything except C is a 
reasonable choice. For the best combination of flexibility, quality, and 
expected longevity, I'd probably recommend LLVM. But your example code is very 
close to C--, so that may be an advantage.

Full disclosure: I am affiliated with the C-- 
project.



 

From: Jay K 
Sent: Saturday, July 18, 2015 10:27 AM
To: m3devel 
Subject: [M3devel] switching to C backend?
 

Any objection if I start switching targets to the C backend? 
 
In particular, Darwin does not support m3gdb, 
so debuggability is not a factor.
 
Thanks,
- Jay







_______________________________________________
M3devel mailing 
list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/60be99d8/attachment-0001.html>

From jay.krell at cornell.edu  Sat Jul 18 13:05:43 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 11:05:43 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
Message-ID: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>

so..I know there is a much better way to do this, but..


Currently every time we have a TRY, we pay both for a setjmpand a jmpbuf.m3-sys/m3tests/src/p2/p259 demonstrates this, and it is what I thoughtthe code was doing anyway -- m3front doesn't maintain per-functionstate related to TRY.

Ideally we defer to an underlying non-portable highly optimized form.

However, has anyone considered a form that does use setjmp butuses at most one frame per procedure, instead of a frame per TRY?

Oh -- and also, the jmpbuf isn't just a large size, but a pthread_getspecific/pthread_setspecfic.

Or, does anything think we stand a chance of soon transitioning completely away from setjmp/longjmp?

Thanks, - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/44be732c/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jul 19 00:17:03 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 22:17:03 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
Message-ID: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>

I want to eliminate the knowledge of jmpbuf size from the frontend.This is an old goal that I failed at previously.

I believe I need to:
 Extend M3.CheckState to include jmpbuf_count. The various Try*.m3.Check increment it and store its previous value in the statement's state.   And then a few choices.  1)  At the start of a function, call alloca with that count times external variable jmpbuf_size, initialized in C. 
 At each try, multiply its index by external variable jmpbuf_size and add to the start of the buffer and use that.   or  also have an array of n pointers filled in by C and index into that, eliminating the runtime non-const multiplication   and/or
  include that array in the alloca even    having a "composite" not called simply "alloca" but "m3_alloc_jmpbufs",  which backends still have to special case to look kinda the same,  alloca being very special
    and/or
    add to functions themselves a notion of jmpbuf count, still the same  underlying mechanism..
      and/or also add a m3cg primitive "jmpbuf_ref(n)", which gets the address  of the n'th jmpbuf of the current function, i.e. building in the multiplication  by jmpbuf size.
      Note that some of these combinations of proposals imply an m3cg change.  All require at least a minimum of backend cooperation -- at least  recognizing "m3_alloca" as "alloca" or "_alloca" or "builtin_alloca" or such.
  
  Note that hopefully/ideally there is a much higher level way to do this,  whose design currently eludes me,  something that a backend could translate to setjmp/longjmp, or Win32 C __try,  or C++ try, or something. The "lowering" of try/finally in the frontend  is portable but very inefficient.
  
 Another solution is for the function to have an n-array of pointers or merely n locals, initialized to null, and have each TRY dynamically call alloca if the pointer isn't null.

 This reduces stack use for the case of IF...TRY.

 At the cost of extra initialization and the test and branch.

This is currently my favorite proposal so I should restate: have a local pointer for each TRY; initialized to null; at each TRY, if the pointer is null, call alloca(external jmpbuf_size). TRY is already super expensive in code size and speed. This solution adds a pointer per TRY and a test and conditional jmp. Multiplication is avoided. IF...TRY ends up using much less stack than before, if not executed, but most code will pay extra stack, a pointer per TRY. What I was missing before is that I need to extend M3.CheckState to count the jmpbufs and do some of the work at the start of the function, not merely at each TRY -- declare, and more importantly, initialize the pointers.
  Thoughts?
 

 Thanks, - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/6b1c1349/attachment-0001.html>

From hendrik at topoi.pooq.com  Sun Jul 19 01:21:40 2015
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sat, 18 Jul 2015 19:21:40 -0400
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>
Message-ID: <20150718232140.GA7577@topoi.pooq.com>

On Sat, Jul 18, 2015 at 10:17:03PM +0000, Jay K wrote:
> I want to eliminate the knowledge of jmpbuf size from the frontend.This is an old goal that I failed at previously.
> 
> I believe I need to:
>  Extend M3.CheckState to include jmpbuf_count. The various Try*.m3.Check increment it and store its previous value in the statement's state.   And then a few choices.  1)  At the start of a function, call alloca with that count times external variable jmpbuf_size, initialized in C. 
>  At each try, multiply its index by external variable jmpbuf_size and add to the start of the buffer and use that.   or  also have an array of n pointers filled in by C and index into that, eliminating the runtime non-const multiplication   and/or
>   include that array in the alloca even    having a "composite" not called simply "alloca" but "m3_alloc_jmpbufs",  which backends still have to special case to look kinda the same,  alloca being very special
>     and/or
>     add to functions themselves a notion of jmpbuf count, still the same  underlying mechanism..
>       and/or also add a m3cg primitive "jmpbuf_ref(n)", which gets the address  of the n'th jmpbuf of the current function, i.e. building in the multiplication  by jmpbuf size.
>       Note that some of these combinations of proposals imply an m3cg change.  All require at least a minimum of backend cooperation -- at least  recognizing "m3_alloca" as "alloca" or "_alloca" or "builtin_alloca" or such.
>   
>   Note that hopefully/ideally there is a much higher level way to do this,  whose design currently eludes me,  something that a backend could translate to setjmp/longjmp, or Win32 C __try,  or C++ try, or something. The "lowering" of try/finally in the frontend  is portable but very inefficient.
>   
>  Another solution is for the function to have an n-array of pointers or merely n locals, initialized to null, and have each TRY dynamically call alloca if the pointer isn't null.
> 
>  This reduces stack use for the case of IF...TRY.
> 
>  At the cost of extra initialization and the test and branch.
> 
> This is currently my favorite proposal so I should restate: have a local pointer for each TRY; initialized to null; at each TRY, if the pointer is null, call alloca(external jmpbuf_size). TRY is already super expensive in code size and speed. This solution adds a pointer per TRY and a test and conditional jmp. Multiplication is avoided. IF...TRY ends up using much less stack than before, if not executed, but most code will pay extra stack, a pointer per TRY. What I was missing before is that I need to extend M3.CheckState to count the jmpbufs and do some of the work at the start of the function, not merely at each TRY -- declare, and more importantly, initialize the pointers.
>   Thoughts?

Unless things have changed  recently, alloca() is not standard.

see the discussion and links in http://c-faq.com/malloc/alloca.html

That page also contains the sentence

Now that C99 supports variable-length arrays (VLA's), they can be used to more cleanly accomplish most of the tasks which alloca used to be put to.

Not clear at aall if the VLA's can be used for this.

>  
> 
>  Thanks, - Jay
> 
>  		 	   		  

> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel



From jay.krell at cornell.edu  Sun Jul 19 10:23:46 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 08:23:46 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <20150718232140.GA7577@topoi.pooq.com>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>,
 <20150718232140.GA7577@topoi.pooq.com>
Message-ID: <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>

alloca is very portable even if it is not in ANSI C or even Posix.

 gcc has builtin support for it. Win32 provides it, where it is called _alloca.The NT/amd64 ABI specifically accounts for it -- functions that callalloca must have a fixed "frame pointer" in a register other than rsp,so that rsp can be changed by calling alloca.
 clang/LLVM presumably provide it. A lot of code depends on it and it is generally easy to provide.
OpenVMS apparently calls it __ALLOCA.


For more complete portability to the C backend we couldadd an m3cg operation to allocate an array of jmpbufswith a constant count.

It is certainly more portable than C99, and C99 VLAs are kind of more general than I need.That is, I might pass a "variable" to alloca, but it is kind of a constant.

My last/current proposal though does do the allocation dynamically, which thism3cg operation would not provide for.

 - Jay



> Date: Sat, 18 Jul 2015 19:21:40 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?
>> 
> Unless things have changed  recently, alloca() is not standard.
> 
> see the discussion and links in http://c-faq.com/malloc/alloca.html
> 
> That page also contains the sentence
> 
> Now that C99 supports variable-length arrays (VLA's), they can be used to more cleanly accomplish most of the tasks which alloca used to be put to.
> 
> Not clear at aall if the VLA's can be used for this.
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/c9f7ac81/attachment-0001.html>

From estellnb at elstel.org  Sun Jul 19 10:44:15 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 10:44:15 +0200
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>,
 <20150718232140.GA7577@topoi.pooq.com>
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>
Message-ID: <55AB635F.9060809@elstel.org>


Am 2015-07-19 um 10:23 schrieb Jay K:
> alloca is very portable even if it is not in ANSI C or even Posix.
>
>
>  gcc has builtin support for it.
>  Win32 provides it, where it is called _alloca.
> The NT/amd64 ABI specifically accounts for it -- functions that call
> alloca must have a fixed "frame pointer" in a register other than rsp,
> so that rsp can be changed by calling alloca.
>
>  clang/LLVM presumably provide it.
>  A lot of code depends on it and it is generally easy to provide.
>
> OpenVMS apparently calls it __ALLOCA.
>
Basically if you plan to build jumpbuf support into m3cg you could
easily use a few assembly statements as well in order to achieve
what alloca does (independently from the operating system):

   mov %[e/r]sp, PTR VAR
   sub %[e/r]sp, JUMPBUF_SIZE

I am sure that similar workarounds would exist for any arch other
than x86 and AMD64.


>
> For more complete portability to the C backend we could
> add an m3cg operation to allocate an array of jmpbufs
> with a constant count.
Why allocate an array or external buffer of jump bufs?
We used to have a linked list interleaved on the stack.
This is fully sufficient and faster than an independent
memory area.

>
>
> It is certainly more portable than C99, and C99 VLAs are kind of more 
> general than I need.
> That is, I might pass a "variable" to alloca, but it is kind of a 
> constant.

If we have arrived at using something similar as alloca in m3cg why 
shouldn`t we provide
this functionality to the user? i.e. let programmers call such a 
function from high level M3
code in order to alloc variable length bufffers, arrays, etc.

VAR localvar := NEWA(MyType);

This is a functionality which I believe that is really missing in M3!!
When we implemented the algorithm of Strassen (saving some 
multiplications for matrix
mults.) we had to notice that everything goes much slower just because 
of the need for
garbage collection ...


- Elmar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/492899e3/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jul 19 10:56:55 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 08:56:55 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <55AB635F.9060809@elstel.org>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>, <55AB635F.9060809@elstel.org>
Message-ID: <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>

Merely subtracting the stack pointer isn't correct on all systems.At least on NT, stack pages must be touched in order without skipping any,for stack overflow exceptions to work correctly.There is a high water mark, so it isn't necessarily linear.


The array is local.The reason for an array is that each instance of a TRY currentlyuses its own jmpbuf.

So a function with n TRY's wants an array of n jmpbufs.

The elements are then indeed linked/unlinked by PushFrame/PopFrame,which are incredibly unoptimized, vs. for example native NT C or C++exception handling, and presumably other systems.

*Ideally* we'd have just one jmpbuf per function, at most, anda local "scope id" to differentiate where in the function we are,for finally/except to dispatch on.You can think of it is a line number, but there can be multiple per line,and they can be denser/smaller than line numbers.


NEWA: alloca is considered kind of dangerous, in that failureis difficult to recognize, or not portably recognizable and handlable.

However, that is the same as merely deep function calls.

So maybe.And we could smush the portability problem into our runtime.In particular, we could catch the exception on NT, fix up thepage (_resetstkovflw) and call calloc/malloc instead.

I don't know how to handle the situation on other systems though.

My current proposal doesn't use an array, but the most portableproposal would.

If people can do the work/research/testing for recognizing stack exhaustionon a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, NetBSD, NT,possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction in my mind.

But yes, safety and garbage collection are not free.If you want the best possible performance, use C or C++.

 - Jay


Date: Sun, 19 Jul 2015 10:44:15 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:23 schrieb Jay K:

    
    
      
      
        alloca is very portable even if it is not in ANSI C or even
          Posix.
        

        
        

        
         gcc has builtin support for it.
         Win32 provides it, where
            it is called _alloca.
        The NT/amd64 ABI
            specifically accounts for it -- functions that call
        alloca must have a fixed
            "frame pointer" in a register other than rsp,
        so that rsp can be changed
            by calling alloca.
        

          
         clang/LLVM presumably
            provide it.
         A lot of code depends on
            it and it is generally easy to provide.
        

          
        OpenVMS apparently calls it
            __ALLOCA.
        

        
      
    
    Basically if you plan to build jumpbuf support into m3cg you could

    easily use a few assembly statements as well in order to achieve 

    what alloca does (independently from the operating system):

    

      mov %[e/r]sp, PTR VAR

      sub %[e/r]sp, JUMPBUF_SIZE 

    

    I am sure that similar workarounds would exist for any arch other

    than x86 and AMD64.

    

    

    
      
        

        
        For more complete portability to the C backend we could
        add an m3cg operation to allocate an array of jmpbufs
        with a constant count.
      
    
    Why allocate an array or external buffer of jump bufs?

    We used to have a linked list interleaved on the stack.

    This is fully sufficient and faster than an independent 

    memory area.

    

    
      
        

        
        

        
        It is certainly more portable than C99, and C99 VLAs are
          kind of more general than I need.
        That is, I might pass a "variable" to alloca, but it is
          kind of a constant.
      
    
    

    If we have arrived at using something similar as alloca in m3cg why
    shouldn`t we provide

    this functionality to the user? i.e. let programmers call such a
    function from high level M3 

    code in order to alloc variable length bufffers, arrays, etc.

    

    VAR localvar := NEWA(MyType);

    

    This is a functionality which I believe that is really missing in
    M3!!

    When we implemented the algorithm of Strassen (saving some
    multiplications for matrix

    mults.) we had to notice that everything goes much slower just
    because of the need for

    garbage collection ...

    

    

    - Elmar

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/5e3deb52/attachment-0001.html>

From estellnb at elstel.org  Sun Jul 19 10:57:11 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 10:57:11 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
Message-ID: <55AB6667.7010908@elstel.org>


Am 2015-07-18 um 13:05 schrieb Jay K:
>
> However, has anyone considered a form that does use setjmp but
> uses at most one frame per procedure, instead of a frame per TRY?

I don`t think that this will work for the general case.
Consider a try - except in the middle of a code block.
If you leave it, it needs to continue after the END of
the TRY-EXCEPT and not after the END of the
procedure.

What you can do is re-use the same jumpbuf-frame
for a nested try-finally and try - except :

  TRY
     TRY
       ...
      EXCEPT
       ...
      END;
   FINALLY
     ...
   END;

or simply

   TRY
     ....
   EXCEPT
     ....
   FINALLY
    ...
   END;

I can remember having once implemented the latter for PM3.
However I am no more sure about the intrinsics...




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/906c5b3c/attachment-0001.html>

From estellnb at elstel.org  Sun Jul 19 11:10:20 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 11:10:20 +0200
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>,
 <55AB635F.9060809@elstel.org> <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>
Message-ID: <55AB697C.7090109@elstel.org>


Am 2015-07-19 um 10:56 schrieb Jay K:
> Merely subtracting the stack pointer isn't correct on all systems.
> At least on NT, stack pages must be touched in order without skipping any,
> for stack overflow exceptions to work correctly.
> There is a high water mark, so it isn't necessarily linear.

Would that mind if the stack exception was generated somewhat
later when the jumpbuf actually becomes accessed?
I would believe no.

>
> NEWA: alloca is considered kind of dangerous, in that failure
> is difficult to recognize, or not portably recognizable and handlable.

The same stack overflow exception can be generated by any
procedure call so that I do not see why it should be that
dangerous. In the overwhelming majority of cases this should
be handled as gracefully as an extension of the heap on NEW:
simply map a new memory page as long as there is enough
free virtual address space.


>
> If people can do the work/research/testing for recognizing stack 
> exhaustion
> on a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, 
> NetBSD, NT,
> possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction 
> in my mind.
As we are planning a new realease I would believe that your new
alterations would become tested shortly.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/0c600193/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jul 19 11:10:53 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 09:10:53 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB6667.7010908@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
Message-ID: <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>

I'm pretty sure it can work, but you need also a local "dense" volatile integer that describes where in the function you are.  That isn't free, but it is much cheaper than calling setjmp/PushFrame for each try.

Try writing similar C++ for NT/x86 and look at what you get."PushFrame" is highly optimized to build a linked list through fs:0.And even that is only done at most once per function.

Java VM also specifies scope tables with a similar intent.

The key is figuring out the algorithm to assign the scope ids, and computing and interpreting the resulting tables. It is a little tricky.

 - Jay


Date: Sun, 19 Jul 2015 10:57:11 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?


  
    
  
  
    

    Am 2015-07-18 um 13:05 schrieb Jay K:

    
    
      
      
        

        
        However, has anyone considered a form that does use setjmp
          but
        uses at most one frame per procedure, instead of a frame
          per TRY?
      
    
    

    I don`t think that this will work for the general case.

    Consider a try - except in the middle of a code block.

    If you leave it, it needs to continue after the END of

    the TRY-EXCEPT and not after the END of the 

    procedure.

    

    What you can do is re-use the same jumpbuf-frame

    for a nested try-finally and try - except :

    

     TRY

        TRY

          ...

         EXCEPT

          ...

         END;

      FINALLY

        ...

      END;

    

    or simply

    

      TRY

        ....

      EXCEPT

        ....

      FINALLY

       ...

      END;

    

    I can remember having once implemented the latter for PM3.

    However I am no more sure about the intrinsics...

    

    

    

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/c2b31d95/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jul 19 11:18:02 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 09:18:02 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <55AB697C.7090109@elstel.org>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>, <55AB635F.9060809@elstel.org>,
 <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>, <55AB697C.7090109@elstel.org>
Message-ID: <COL130-W2ED3E35017B6A73F03CC0E6860@phx.gbl>

The stack pages must be touched in order.

It cannot be dynamically ordered in such a way that pages are skipped.It is much easier to have a static order than worry about getting a dynamic order correct.

That is, sure, you can do some large subtract all at once,but you must not skip around in the order the pages are touched.

You can defer the exception until the jmpbuf is touched,and you can get away without touching any, but whatever youtouch, must be in order.

The solution is simple though -- actually call _alloca.It gets it right.

Imagine this:
jmpbuf bufs[n];while (1)    switch (srand() % n)    {    case 0: TRY ...  break;    case 1: TRY ...  break;    case 2: TRY ...  break;    case 3: TRY ...  break;    }}

that wouldn't work properly w/o a bit of extra code.

On NT, if you write a function with more than a page of locals,the start of the function calls chkstk, which is another name for alloca,to be sure to touch the page(s).

Because, imagine you have a function with more than a page of locals,that the first thing it does is call another function. The pushing of thereturn address will touch the stack, but possibly skip a page.

If you just have lots of functions with less than a page of locals,the pushing of return addresses to make further calls is what touchesthe pages.

It is easy to see in the generated code.We likely have a bug here in NT/x86 *forever*.It is fixed in the C backend. :)The C compiler knows the rules, and is heavily used, where the NT/x86 backend does/is not.

 - Jay



Date: Sun, 19 Jul 2015 11:10:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:56 schrieb Jay K:

    
    
      
      
        Merely subtracting the stack pointer isn't correct on all
          systems.
        At least on NT, stack pages must be touched in order
          without skipping any,
        for stack overflow exceptions to work correctly.
        There is a high water mark, so it isn't necessarily linear.
      
    
    

    Would that mind if the stack exception was generated somewhat 

    later when the jumpbuf actually becomes accessed?

    I would believe no.

    

    
      
        

        
        NEWA: alloca is considered kind of dangerous, in that
          failure
        is difficult to recognize, or not portably recognizable and
          handlable.
      
    
    

    The same stack overflow exception can be generated by any 

    procedure call so that I do not see why it should be that 

    dangerous. In the overwhelming majority of cases this should

    be handled as gracefully as an extension of the heap on NEW:

    simply map a new memory page as long as there is enough

    free virtual address space.

    

    

    
      
        

        
        If people can do the work/research/testing for recognizing
          stack exhaustion
        on a decent set of systems -- Linux, Solaris, FreeBSD,
          OpenBSD, NetBSD, NT,
        possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain
          traction in my mind.
      
    
    As we are planning a new realease I would believe that your new 

    alterations would become tested shortly.

    

    

    

    

    

    

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/73fe76fe/attachment-0001.html>

From estellnb at elstel.org  Sun Jul 19 11:38:25 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 11:38:25 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
Message-ID: <55AB7011.9070709@elstel.org>


Am 2015-07-19 um 11:10 schrieb Jay K:
> I'm pretty sure it can work, but you need also a local "dense" 
> volatile integer that describes where in the function you are.  That 
> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
> each try.
>
Is it really that much faster? I can remember having implemented my own 
setjump/longjump in assembly some time ago and it should only save you 
one procedure call but generate some additional jumps. However I do not 
know how time costly the new-fashioned register value obfuscation is 
(registers are no more stored as they are but obfuscated for security 
reasons by glibc). Xor-ing by a simple value; does it really cost the 
world? I am not the one who can tell you whether such a venture like 
this would pay off ...


>
> Try writing similar C++ for NT/x86 and look at what you get.
> "PushFrame" is highly optimized to build a linked list through fs:0.
> And even that is only done at most once per function.

Through fs:0 ? It used to be on the ss:[e/r]b in former times.
Since pthreading it may also be fs:0 under Linux because of get/setspecific.
I am not sure what these functions do in detail (something with fs at last).

Nonetheless I would believe that avoiding to call get/setspecific could 
speed
things up noticeably. First there is the function overhead, second we 
need to
touch an independent memory area and last but not least the stack is
always thread local. However I am not sure on how we could place the top
anchor for the linked list of exception frames otherwise. Push an exception
  frame pointer into every local variable area?

>
>
> Java VM also specifies scope tables with a similar intent.

However Java is not known for speed wonders ...


>
>
> The key is figuring out the algorithm to assign the scope ids, and 
> computing and interpreting the resulting tables. It is a little tricky.
>


Am 2015-07-19 um 11:18 schrieb Jay K:
> The stack pages must be touched in order...

Thanks a lot for an elaborate discussion of this!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/bc13a4ff/attachment-0001.html>

From estellnb at elstel.org  Sun Jul 19 12:06:20 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 12:06:20 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB7011.9070709@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl> <55AB7011.9070709@elstel.org>
Message-ID: <55AB769C.2020806@elstel.org>


Am 2015-07-19 um 11:38 schrieb Elmar Stellnberger:
>
> Am 2015-07-19 um 11:10 schrieb Jay K:
>> I'm pretty sure it can work, but you need also a local "dense" 
>> volatile integer that describes where in the function you are.  That 
>> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
>> each try.
>>
> Is it really that much faster? I can remember having implemented my 
> own setjump/longjump in assembly some time ago and it should only save 
> you one procedure call but generate some additional jumps. However I 
> do not know how time costly the new-fashioned register value 
> obfuscation is (registers are no more stored as they are but 
> obfuscated for security reasons by glibc). Xor-ing by a simple value; 
> does it really cost the world? I am not the one who can tell you 
> whether such a venture like this would pay off ...
>
>

You are right. It would be somewhat faster especially on AMD64 where we 
have a lot of registers to rescue ...


>>
>> Try writing similar C++ for NT/x86 and look at what you get.
>> "PushFrame" is highly optimized to build a linked list through fs:0.
>> And even that is only done at most once per function.
>
> Through fs:0 ? It used to be on the ss:[e/r]b in former times.
> Since pthreading it may also be fs:0 under Linux because of 
> get/setspecific.
> I am not sure what these functions do in detail (something with fs at 
> last).
>
> Nonetheless I would believe that avoiding to call get/setspecific 
> could speed
> things up noticeably. First there is the function overhead, second we 
> need to
> touch an independent memory area and last but not least the stack is
> always thread local. However I am not sure on how we could place the top
> anchor for the linked list of exception frames otherwise. Push an 
> exception
>  frame pointer into every local variable area?

However I believe this should also be worth a consideration as soon as 
we talk about m3cg support and speed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/ed02d46b/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jul 19 12:19:13 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 10:19:13 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB769C.2020806@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>, <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
 <55AB7011.9070709@elstel.org>,<55AB769C.2020806@elstel.org>
Message-ID: <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>

NT/x86 is the slow one.Still much faster than Modula-3.

There is a linked list through fs:0.fs:0 is thread local.For code speed, the link/unlink can be inlined.For code size, it can be a small function call.Just like two instructions for function enter and exit.And set a local volatile "as scopes are crossed".

locals used in the except/finallyblock are not likely enregistered across calls.

Compare this with current Modula-3:

 pthread_getspecific (TlsGetValue)  to get the current head  link it in  setjmp 
  And this happens for every TRY, instead of just at most once per function. 
The fs:0 link/unlink is at most once per function.

And all the other NT platforms are faster.

They don't link/unlink anything.They have metadata describing prologs.The runtime can use that to restore nonvolatile registers (includingthe stack) at any point.The codegen is somewhat constrained -- to be describable,but I suspect what you can describe encompasses anythinga compiler would want to do.Leaf functions have no data, and can't change nonvolatile registers,including rsp, and they can't make any calls (which would change rsp).

The tables are found from the return address.The only dynamic data the runtime has to leave aroundis the actual return address. No linked list, no volatile localindicating position in the function.

fs:0 is the NT/x86 location.This is a highly optimized thread local (fiber local actually).I don't know what other ABIs use, if anything -- again, all the otherNT platforms have no linked list, just return addresses and metadata.


Notes:The non-x86 approach is sometimes referred to as "no overhead", as "TRY" doesn't do anything (exceptleave cold data around).X86 exception dispatch is faster than non-x86. The stack is faster to walk, through the fs:0 linked list.The premise is that exception dispatch can be slow.The non exceptional paths are what should be optimized.And again, even NT/x86 is much more optimized than what Modula-3 does.


 - Jay



Date: Sun, 19 Jul 2015 12:06:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?


  
    
  
  
    

    Am 2015-07-19 um 11:38 schrieb Elmar
      Stellnberger:

    
    
      
      

      Am 2015-07-19 um 11:10 schrieb Jay K:

      
      
        
        I'm pretty sure it can work, but you need also a
          local "dense" volatile integer that describes where in the
          function you are.  That isn't free, but it is much cheaper
          than calling setjmp/PushFrame for each try.
          

          
        
      
      Is it really that much faster? I can remember having implemented
      my own setjump/longjump in assembly some time ago and it should
      only save you one procedure call but generate some additional
      jumps. However I do not know how time costly the new-fashioned
      register value obfuscation is (registers are no more stored as
      they are but obfuscated for security reasons by glibc). Xor-ing by
      a simple value; does it really cost the world? I am not the one
      who can tell you whether such a venture like this would pay off
      ...

      

      

    
    

    You are right. It would be somewhat faster especially on AMD64 where
    we have a lot of registers to rescue ...

    

    

    
      
        
          

          
          Try writing similar C++ for NT/x86 and look at what you
            get.
          "PushFrame" is highly optimized to build a linked list
            through fs:0.
          And even that is only done at most once per function.
        
      
      

      Through fs:0 ? It used to be on the ss:[e/r]b in former times.

      Since pthreading it may also be fs:0 under Linux because of
      get/setspecific.

      I am not sure what these functions do in detail (something with fs
      at last).

      

      Nonetheless I would believe that avoiding to call get/setspecific
      could speed

      things up noticeably. First there is the function overhead, second
      we need to

      touch an independent memory area and last but not least the stack
      is 

      always thread local. However I am not sure on how we could place
      the top

      anchor for the linked list of exception frames otherwise. Push an
      exception

       frame pointer into every local variable area?

    
    

    However I believe this should also be worth a consideration as soon
    as we talk about m3cg support and speed.

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/d27e2d99/attachment-0001.html>

From estellnb at elstel.org  Sun Jul 19 14:02:24 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 14:02:24 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>,
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl> <55AB7011.9070709@elstel.org>,
 <55AB769C.2020806@elstel.org> <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
Message-ID: <55AB91D0.80303@elstel.org>


Am 2015-07-19 um 12:19 schrieb Jay K:
> And all the other NT platforms are faster.
> They don't link/unlink anything.
> They have metadata describing prologs.
> The runtime can use that to restore nonvolatile registers (including
> the stack) at any point.

including NT-AMD64 or not? -
but PowerPC, MIPS, Alpha, Itanium and ARM?

interesting. What happens if I have a variable being kept in a register
like register int x? These registers would still need to be saved as
a prolog could never tell us (i.e. we would then again need a linked
list) ...

... and then if we have prologues we would not need to pin down
any word that could refer as a refany to the traced heap in our
locales area but only those which really do (The question is of
course what data is in these prologues and what data is not.).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/59daae07/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jul 19 19:46:36 2015
From: jay.krell at cornell.edu (Jay)
Date: Sun, 19 Jul 2015 10:46:36 -0700
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB91D0.80303@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
 <55AB6667.7010908@elstel.org> <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
 <55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org>
 <COL130-W98F71B1447317E3FAF027E6860@phx.gbl> <55AB91D0.80303@elstel.org>
Message-ID: <F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>

NT/amd64 & likely all NT architectures except x86: The pdata gives function boundaries and the xdata provides information to restore nonvolatile registers, including rsp and return address. Locals may be enregistered across function calls in nonvolatile registers. 


There is no linked list.
There is a reliable stack walker including restoring nonvolatile registers provided by ther operating system (RtlUnwind, RtlVirtualUnwind).


 - Jay

On Jul 19, 2015, at 5:02 AM, Elmar Stellnberger <estellnb at elstel.org> wrote:

> 
> Am 2015-07-19 um 12:19 schrieb Jay K:
>> And all the other NT platforms are faster.
>> They don't link/unlink anything.
>> They have metadata describing prologs.
>> The runtime can use that to restore nonvolatile registers (including
>> the stack) at any point.
> 
> including NT-AMD64 or not? - 
> but PowerPC, MIPS, Alpha, Itanium and ARM?
> 
> interesting. What happens if I have a variable being kept in a register
> like register int x? These registers would still need to be saved as 
> a prolog could never tell us (i.e. we would then again need a linked 
> list) ...
> 
> ... and then if we have prologues we would not need to pin down
> any word that could refer as a refany to the traced heap in our 
> locales area but only those which really do (The question is of
> course what data is in these prologues and what data is not.).
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/60d15479/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jul 20 09:21:18 2015
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 20 Jul 2015 07:21:18 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>,<55AB7011.9070709@elstel.org>
 <55AB769C.2020806@elstel.org>,<COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
 <55AB91D0.80303@elstel.org>,<F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>
Message-ID: <COL130-W47FB963569F6C12D414571E6850@phx.gbl>

ps: translating to C for Win32 or C++ for any targets nets you whatever is the local optimized exception handling runtime, including certainly this stuff on NT.
Sometimes that might merely be a similar setjmp/longjmp based system, but often not.
But we need higher level m3cg operations for exception handling to do this (or some awful reverse induction in the backend..)
 - Jay


From: jay.krell at cornell.edu
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?
Date: Sun, 19 Jul 2015 10:46:36 -0700
To: estellnb at elstel.org

NT/amd64 & likely all NT architectures except x86: The pdata gives function boundaries and the xdata provides information to restore nonvolatile registers, including rsp and return address. Locals may be enregistered across function calls in nonvolatile registers. 

There is no linked list.There is a reliable stack walker including restoring nonvolatile registers provided by ther operating system (RtlUnwind, RtlVirtualUnwind).

 - Jay
On Jul 19, 2015, at 5:02 AM, Elmar Stellnberger <estellnb at elstel.org> wrote:


  
    
  
  
    

    Am 2015-07-19 um 12:19 schrieb Jay K:

    
    
      
      
        And all the other NT platforms are faster.
      
    
    
      
        They don't link/unlink anything.
        They have metadata describing prologs.
        The runtime can use that to restore nonvolatile registers
          (including
        the stack) at any point.
      
    
    

    including NT-AMD64 or not? - 

    but PowerPC, MIPS, Alpha, Itanium and ARM?

    

    interesting. What happens if I have a variable being kept in a
    register

    like register int x? These registers would still need to be saved as
    

    a prolog could never tell us (i.e. we would then again need a linked
    

    list) ...

    

    ... and then if we have prologues we would not need to pin down

    any word that could refer as a refany to the traced heap in our 

    locales area but only those which really do (The question is of

    course what data is in these prologues and what data is not.).

    

    

    

  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150720/8c45a67f/attachment-0001.html>

From rodney_bates at lcwb.coop  Tue Jul 21 18:21:22 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 21 Jul 2015 11:21:22 -0500
Subject: [M3devel] O(1) FIFO wakeup of waiters on both Mutexs and Conditions
Message-ID: <55AE7182.3060709@lcwb.coop>

I just committed and pushed the subject change.  It could probably use more
testing.  It has shown no problems with m3-libs/m3core/tests/thread, for a
few combinations of thread count and iteration count.

I committed the old version as ThreadPThread0.m3, so it can be reverted
quickly, if bugs show up.  Look in the m3makefile to switch by simple
commenting in and out.

New or old version, it will require recompiles and ships of everything
in the closure of a main program to try it.


-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Wed Jul 22 07:42:29 2015
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 22 Jul 2015 05:42:29 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
Message-ID: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>

In the C backend I have a notion of "weak struct types" and "strong struct types".

"Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.

"Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.


Originally I had only weak types.Ideally I have no weak types.I'm down to very few weak types now.I'd like to finish eliminating weak types.


A quick investigation shows weak types come from open arrays and jmpbufs.Open array temporaries from SUBARRAY specifically.


Can we fix this?


We have:m3front/src/types/OpenArrayType.m3:
PROCEDURE DeclareTemp (t: Type.T): CG.Var =  VAR    p    := Reduce (t);    size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;  BEGIN    RETURN CG.Declare_temp (size, Target.Address.align,                            CG.Type.Struct, in_memory := TRUE);  END DeclareTemp;

PROCEDURE Compiler (p: P) =  VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;  BEGIN    Type.Compile (p.element);    CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);  END Compiler;

DeclareTemp is used in SUBARRAY expressions -- truly temporaries,not variables authored by anyone in Modula-3.

Can this be easily fixed?

Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150722/b0e622c2/attachment-0001.html>

From rodney_bates at lcwb.coop  Thu Jul 23 02:30:12 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 22 Jul 2015 19:30:12 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>
Message-ID: <55B03594.20800@lcwb.coop>

I'm not exactly sure what you are asking, but here is some light on what
you are seeing.  These temporaries are exactly the dope the compiler uses
to represent all open array values.  First a pointer to the zeroth
array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
an array of element counts for each open subscript.  For an open array
parameter, this would be the machine representation of the parameter
itself, authored in M3. (but passed by reference.)  For a heap object,
it is stored right before the elements themselves.  For a SUBARRAY
expression, it has to be a temporary.  It also has to be constructed
at the call site, as an anonymous temporary, when passing an entire fixed
array to an open array parameter

So, a good type for it might look like:


RECORD
   Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
END

Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
static limit here in the type of Elements, as it will be enforced dynamically,
using Shape.  But we don't want to just say REF ARRAY OF ElementType either,
as this would mean another open array inside the dope, resulting in infinite
recursion.

On 07/22/2015 12:42 AM, Jay K wrote:
> In the C backend I have a notion of "weak struct types" and "strong struct types".
>
>
> "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>
>
> "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>
>
>
> Originally I had only weak types.
> Ideally I have no weak types.
> I'm down to very few weak types now.
> I'd like to finish eliminating weak types.
>
>
>
> A quick investigation shows weak types come from open arrays and jmpbufs.
> Open array temporaries from SUBARRAY specifically.
>
>
>
> Can we fix this?
>
>
>
> We have:
> m3front/src/types/OpenArrayType.m3:
>
> PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>    VAR
>      p    := Reduce (t);
>      size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>    BEGIN
>      RETURN CG.Declare_temp (size, Target.Address.align,
>                              CG.Type.Struct, in_memory := TRUE);
>    END DeclareTemp;
>
>
> PROCEDURE Compiler (p: P) =
>    VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>    BEGIN
>      Type.Compile (p.element);
>      CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>    END Compiler;
>
>
> DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> not variables authored by anyone in Modula-3.
>
>
> Can this be easily fixed?
>
>
> Thanks,
>   - Jay
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Fri Jul 24 10:57:14 2015
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 24 Jul 2015 08:57:14 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <55B03594.20800@lcwb.coop>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>,
 <55B03594.20800@lcwb.coop>
Message-ID: <COL130-W78229587075BD6B3A94050E6810@phx.gbl>

I model this in C like:

M3C.m3:        print(self, "/*declare_open_array*/typedef struct {");        print(self, element_type.text);        print(self, "* _elts; CARDINAL _size");        IF bit_size > Target.Integer.size * 2 THEN            print(self, "s[");            print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));            print(self, "]");        END;

that is..and this i stinky that I get the struct "size",

size == 2 * sizeof(integer):

struct {T* elementssize_t size;}

else: N = size - sizeof(INTEGER) / sizeof(INTEGER) T ** elements; // where the number of star is N  size_t sizes[N]

It is kind of lame that the frontend just gives the overall sizeand the backend is just left to assume the layout like that.
Really, the frontend should declare a type "pointer to pointer to pointer" withthe right "depth", and then a record with that pointer and a size or fixed size array of sizes.

Again, really ugly how it works now where backend is just given a size and can onlyassume the layout.
I don't know what a "dope vector" is. A value used as an initializer?

It is even worse for subarray. In this case we aren't even told it is an open array, justsome random struct with a size. That is what I first want to fix. It should declare an open array,assuming they do have the same layout, which I think they do.

subarray temporaries and jmpbufs are I believe the only place the frontend passes so littletype information.

For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace themwith #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.



 - Jay


> Date: Wed, 22 Jul 2015 19:30:12 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> 
> I'm not exactly sure what you are asking, but here is some light on what
> you are seeing.  These temporaries are exactly the dope the compiler uses
> to represent all open array values.  First a pointer to the zeroth
> array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
> an array of element counts for each open subscript.  For an open array
> parameter, this would be the machine representation of the parameter
> itself, authored in M3. (but passed by reference.)  For a heap object,
> it is stored right before the elements themselves.  For a SUBARRAY
> expression, it has to be a temporary.  It also has to be constructed
> at the call site, as an anonymous temporary, when passing an entire fixed
> array to an open array parameter
> 
> So, a good type for it might look like:
> 
> 
> RECORD
>    Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
> ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
> END
> 
> Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
> static limit here in the type of Elements, as it will be enforced dynamically,
> using Shape.  But we don't want to just say REF ARRAY OF ElementType either,
> as this would mean another open array inside the dope, resulting in infinite
> recursion.
> 
> On 07/22/2015 12:42 AM, Jay K wrote:
> > In the C backend I have a notion of "weak struct types" and "strong struct types".
> >
> >
> > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
> >
> >
> > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
> >
> >
> >
> > Originally I had only weak types.
> > Ideally I have no weak types.
> > I'm down to very few weak types now.
> > I'd like to finish eliminating weak types.
> >
> >
> >
> > A quick investigation shows weak types come from open arrays and jmpbufs.
> > Open array temporaries from SUBARRAY specifically.
> >
> >
> >
> > Can we fix this?
> >
> >
> >
> > We have:
> > m3front/src/types/OpenArrayType.m3:
> >
> > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
> >    VAR
> >      p    := Reduce (t);
> >      size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >    BEGIN
> >      RETURN CG.Declare_temp (size, Target.Address.align,
> >                              CG.Type.Struct, in_memory := TRUE);
> >    END DeclareTemp;
> >
> >
> > PROCEDURE Compiler (p: P) =
> >    VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >    BEGIN
> >      Type.Compile (p.element);
> >      CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
> >    END Compiler;
> >
> >
> > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> > not variables authored by anyone in Modula-3.
> >
> >
> > Can this be easily fixed?
> >
> >
> > Thanks,
> >   - Jay
> >
> >
> >
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150724/9fc74156/attachment-0001.html>

From rodney_bates at lcwb.coop  Fri Jul 24 16:57:37 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 24 Jul 2015 09:57:37 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W78229587075BD6B3A94050E6810@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>,
 <55B03594.20800@lcwb.coop>
 <COL130-W78229587075BD6B3A94050E6810@phx.gbl>
Message-ID: <55B25261.5010106@lcwb.coop>



On 07/24/2015 03:57 AM, Jay K wrote:
> I model this in C like:
>
>
> M3C.m3:
>          print(self, "/*declare_open_array*/typedef struct {");

Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?

>          print(self, element_type.text);
>          print(self, "* _elts; CARDINAL _size");
>          IF bit_size > Target.Integer.size * 2 THEN
>              print(self, "s[");
>              print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
>              print(self, "]");
>          END;
>
>
> that is..and this i stinky that I get the struct "size",
>
>
> size == 2 * sizeof(integer):
>
>
> struct {
> T* elements
> size_t size;
> }
>
>
> else:
>   N = size - sizeof(INTEGER) / sizeof(INTEGER)
>   T ** elements; // where the number of star is N

I would not do pointer to pointer to pointer ... here.  Just "T* elements", regardless
of the number of open dimensions.  As I understand them, C's language-supported
multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
the language does the multi-subscript address arithmetic, which means the type
system needs to provide a static element size of each dimension.  And that,
except for the innermost, depends on the element count of the next inner
dimension, which is not static here.

So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
is lowered by the front end into explicit address arithmetic into the flattened
array, using the values in the shape.  Something like A[I*Shape[0]+J*Shape[1]+K]

>    size_t sizes[N]
>
>
> It is kind of lame that the frontend just gives the overall size
> and the backend is just left to assume the layout like that.

If you know in M3C that it's an open array, you can infer what the layout is.
But yes, it's kind of lame.  This is just another of the several places we have
seen that the front end has lowered things too far, and you have to
You know it's generated by code in OpenArray.m3, and you know the general dope layout,
and open dimension count, so you can generate an appropriate type.


>
> Really, the frontend should declare a type "pointer to pointer to pointer" with
> the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
>
>
> Again, really ugly how it works now where backend is just given a size and can only
> assume the layout.
>
> I don't know what a "dope vector" is. A value used as an initializer?
>

This is a very old and rather uninformative term for any block of stuff stored at runtime
that describes some source programmer's real data and how to access it.  The only alternative
term I can think of would be "metadata", although that is rather overgeneral, and is usually
used with quite different specific meanings.  But it is data describing data.

>
> It is even worse for subarray. In this case we aren't even told it is an open array, just
> some random struct with a size. That is what I first want to fix. It should declare an open array,
> assuming they do have the same layout, which I think they do.
>

What you really need to know is that it's an open array, of which subarray is a subcategory.
In our implementation, all open array values have the same dope.  E.g., look for the case where
a fixed array actual parameter is passed to an open array formal.

>
> subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
> type information.
>
>
> For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
> with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
>
>
>
>
>   - Jay
>
>
>  > Date: Wed, 22 Jul 2015 19:30:12 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  >
>  > I'm not exactly sure what you are asking, but here is some light on what
>  > you are seeing. These temporaries are exactly the dope the compiler uses
>  > to represent all open array values. First a pointer to the zeroth
>  > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
>  > an array of element counts for each open subscript. For an open array
>  > parameter, this would be the machine representation of the parameter
>  > itself, authored in M3. (but passed by reference.) For a heap object,
>  > it is stored right before the elements themselves. For a SUBARRAY
>  > expression, it has to be a temporary. It also has to be constructed
>  > at the call site, as an anonymous temporary, when passing an entire fixed
>  > array to an open array parameter
>  >
>  > So, a good type for it might look like:
>  >
>  >
>  > RECORD
>  > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
>  > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
>  > END
>  >
>  > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
>  > static limit here in the type of Elements, as it will be enforced dynamically,
>  > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
>  > as this would mean another open array inside the dope, resulting in infinite
>  > recursion.
>  >
>  > On 07/22/2015 12:42 AM, Jay K wrote:
>  > > In the C backend I have a notion of "weak struct types" and "strong struct types".
>  > >
>  > >
>  > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>  > >
>  > >
>  > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>  > >
>  > >
>  > >
>  > > Originally I had only weak types.
>  > > Ideally I have no weak types.
>  > > I'm down to very few weak types now.
>  > > I'd like to finish eliminating weak types.
>  > >
>  > >
>  > >
>  > > A quick investigation shows weak types come from open arrays and jmpbufs.
>  > > Open array temporaries from SUBARRAY specifically.
>  > >
>  > >
>  > >
>  > > Can we fix this?
>  > >
>  > >
>  > >
>  > > We have:
>  > > m3front/src/types/OpenArrayType.m3:
>  > >
>  > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>  > > VAR
>  > > p := Reduce (t);
>  > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > BEGIN
>  > > RETURN CG.Declare_temp (size, Target.Address.align,
>  > > CG.Type.Struct, in_memory := TRUE);
>  > > END DeclareTemp;
>  > >
>  > >
>  > > PROCEDURE Compiler (p: P) =
>  > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > BEGIN
>  > > Type.Compile (p.element);
>  > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>  > > END Compiler;
>  > >
>  > >
>  > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
>  > > not variables authored by anyone in Modula-3.
>  > >
>  > >
>  > > Can this be easily fixed?
>  > >
>  > >
>  > > Thanks,
>  > > - Jay
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > > M3devel mailing list
>  > > M3devel at elegosoft.com
>  > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  > >
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Sat Jul 25 18:39:45 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 25 Jul 2015 11:39:45 -0500
Subject: [M3devel] Strange CM3 IR for FINALLY
Message-ID: <55B3BBD1.7040203@lcwb.coop>

In looking at CM3 IR for TRY-FINALLY, for an unrelated reason, I find the following:

The front end translates the code found between FINALLY and END into a nested procedure.
This is declared as having one parameter of type ADDRESS.  But, in the the direct call
it generates, right before the FINALLY, it passes no actual.  Also, in the simple example
I looked at, the finally procedure does not access its formal.

It also stores the address of the finally procedure in a 5-word record whose address
it passes to RTHooks.PushEFrame and PopEFrame.  RTHooks.i3 treats this as ADDRESS, and
tells us nothing about what it actually points to.

Is there a bug, or does anybody understand what is going on here?
-- 
Rodney Bates
rodney.m.bates at acm.org


From peter.mckinna at gmail.com  Sun Jul 26 03:02:35 2015
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 26 Jul 2015 11:02:35 +1000
Subject: [M3devel] Strange CM3 IR for FINALLY
In-Reply-To: <55B3BBD1.7040203@lcwb.coop>
References: <55B3BBD1.7040203@lcwb.coop>
Message-ID: <CAEy6uxpjkVbMtHwF+=AqfmFs32F3DT0pjMeZqy0QBbbt3DSXXA@mail.gmail.com>

Theres a comment at about line 216 in TryFinStmt.m3 that suggests the
authors were not too sure about this either.

Regards Peter.

On Sun, Jul 26, 2015 at 2:39 AM, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:

> In looking at CM3 IR for TRY-FINALLY, for an unrelated reason, I find the
> following:
>
> The front end translates the code found between FINALLY and END into a
> nested procedure.
> This is declared as having one parameter of type ADDRESS.  But, in the the
> direct call
> it generates, right before the FINALLY, it passes no actual.  Also, in the
> simple example
> I looked at, the finally procedure does not access its formal.
>
> It also stores the address of the finally procedure in a 5-word record
> whose address
> it passes to RTHooks.PushEFrame and PopEFrame.  RTHooks.i3 treats this as
> ADDRESS, and
> tells us nothing about what it actually points to.
>
> Is there a bug, or does anybody understand what is going on here?
> --
> Rodney Bates
> rodney.m.bates at acm.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150726/a27f1a68/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jul 30 02:07:18 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 00:07:18 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <55B25261.5010106@lcwb.coop>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>, ,
 <55B03594.20800@lcwb.coop>, <COL130-W78229587075BD6B3A94050E6810@phx.gbl>,
 <55B25261.5010106@lcwb.coop>
Message-ID: <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>

As part of fixing this, I want M3CG_Ops.i3
declare_temp (s: ByteSize;  a: Alignment;  t: Type;              in_memory: BOOLEAN): Var;

to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, ifthat syntax is allowed, or all existing calls can initially pass M3ID.NoID.

The use in OpenArrayType.DeclareTemp will then be changed to something else.DeclareTemp will look more like OpenArrayType.Compiler.

And, something will be done for jmpbufs, such having them be named and passing that name alongsomewhere. Or giving them a special uid, or even their own special CG.Type?

And then, every use of CG.Type.Struct must come along with a TypeUID.

ok?
The C backend will/should actually be able notice the name of the jmpbuf type and substitutein.. #include <setjmp.h> jmpbuf.
Other backends should  substitute in the alloca use.
Or, it will be an internal parameter to the frontend for it to do the alloca transformation.
But this is getting ahead of things.
First -- change declare_temp to accept a TypeUID ok?


 - Jay


> Date: Fri, 24 Jul 2015 09:57:37 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu; m3devel at elegosoft.com; m3devel at elegosoft.com
> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> 
> 
> 
> On 07/24/2015 03:57 AM, Jay K wrote:
> > I model this in C like:
> >
> >
> > M3C.m3:
> >          print(self, "/*declare_open_array*/typedef struct {");
> 
> Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?
> 
> >          print(self, element_type.text);
> >          print(self, "* _elts; CARDINAL _size");
> >          IF bit_size > Target.Integer.size * 2 THEN
> >              print(self, "s[");
> >              print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
> >              print(self, "]");
> >          END;
> >
> >
> > that is..and this i stinky that I get the struct "size",
> >
> >
> > size == 2 * sizeof(integer):
> >
> >
> > struct {
> > T* elements
> > size_t size;
> > }
> >
> >
> > else:
> >   N = size - sizeof(INTEGER) / sizeof(INTEGER)
> >   T ** elements; // where the number of star is N
> 
> I would not do pointer to pointer to pointer ... here.  Just "T* elements", regardless
> of the number of open dimensions.  As I understand them, C's language-supported
> multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
> the language does the multi-subscript address arithmetic, which means the type
> system needs to provide a static element size of each dimension.  And that,
> except for the innermost, depends on the element count of the next inner
> dimension, which is not static here.
> 
> So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
> is lowered by the front end into explicit address arithmetic into the flattened
> array, using the values in the shape.  Something like A[I*Shape[0]+J*Shape[1]+K]
> 
> >    size_t sizes[N]
> >
> >
> > It is kind of lame that the frontend just gives the overall size
> > and the backend is just left to assume the layout like that.
> 
> If you know in M3C that it's an open array, you can infer what the layout is.
> But yes, it's kind of lame.  This is just another of the several places we have
> seen that the front end has lowered things too far, and you have to
> You know it's generated by code in OpenArray.m3, and you know the general dope layout,
> and open dimension count, so you can generate an appropriate type.
> 
> 
> >
> > Really, the frontend should declare a type "pointer to pointer to pointer" with
> > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
> >
> >
> > Again, really ugly how it works now where backend is just given a size and can only
> > assume the layout.
> >
> > I don't know what a "dope vector" is. A value used as an initializer?
> >
> 
> This is a very old and rather uninformative term for any block of stuff stored at runtime
> that describes some source programmer's real data and how to access it.  The only alternative
> term I can think of would be "metadata", although that is rather overgeneral, and is usually
> used with quite different specific meanings.  But it is data describing data.
> 
> >
> > It is even worse for subarray. In this case we aren't even told it is an open array, just
> > some random struct with a size. That is what I first want to fix. It should declare an open array,
> > assuming they do have the same layout, which I think they do.
> >
> 
> What you really need to know is that it's an open array, of which subarray is a subcategory.
> In our implementation, all open array values have the same dope.  E.g., look for the case where
> a fixed array actual parameter is passed to an open array formal.
> 
> >
> > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
> > type information.
> >
> >
> > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
> > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
> >
> >
> >
> >
> >   - Jay
> >
> >
> >  > Date: Wed, 22 Jul 2015 19:30:12 -0500
> >  > From: rodney_bates at lcwb.coop
> >  > To: m3devel at elegosoft.com
> >  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> >  >
> >  > I'm not exactly sure what you are asking, but here is some light on what
> >  > you are seeing. These temporaries are exactly the dope the compiler uses
> >  > to represent all open array values. First a pointer to the zeroth
> >  > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
> >  > an array of element counts for each open subscript. For an open array
> >  > parameter, this would be the machine representation of the parameter
> >  > itself, authored in M3. (but passed by reference.) For a heap object,
> >  > it is stored right before the elements themselves. For a SUBARRAY
> >  > expression, it has to be a temporary. It also has to be constructed
> >  > at the call site, as an anonymous temporary, when passing an entire fixed
> >  > array to an open array parameter
> >  >
> >  > So, a good type for it might look like:
> >  >
> >  >
> >  > RECORD
> >  > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
> >  > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
> >  > END
> >  >
> >  > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
> >  > static limit here in the type of Elements, as it will be enforced dynamically,
> >  > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
> >  > as this would mean another open array inside the dope, resulting in infinite
> >  > recursion.
> >  >
> >  > On 07/22/2015 12:42 AM, Jay K wrote:
> >  > > In the C backend I have a notion of "weak struct types" and "strong struct types".
> >  > >
> >  > >
> >  > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
> >  > >
> >  > >
> >  > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
> >  > >
> >  > >
> >  > >
> >  > > Originally I had only weak types.
> >  > > Ideally I have no weak types.
> >  > > I'm down to very few weak types now.
> >  > > I'd like to finish eliminating weak types.
> >  > >
> >  > >
> >  > >
> >  > > A quick investigation shows weak types come from open arrays and jmpbufs.
> >  > > Open array temporaries from SUBARRAY specifically.
> >  > >
> >  > >
> >  > >
> >  > > Can we fix this?
> >  > >
> >  > >
> >  > >
> >  > > We have:
> >  > > m3front/src/types/OpenArrayType.m3:
> >  > >
> >  > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
> >  > > VAR
> >  > > p := Reduce (t);
> >  > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >  > > BEGIN
> >  > > RETURN CG.Declare_temp (size, Target.Address.align,
> >  > > CG.Type.Struct, in_memory := TRUE);
> >  > > END DeclareTemp;
> >  > >
> >  > >
> >  > > PROCEDURE Compiler (p: P) =
> >  > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >  > > BEGIN
> >  > > Type.Compile (p.element);
> >  > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
> >  > > END Compiler;
> >  > >
> >  > >
> >  > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> >  > > not variables authored by anyone in Modula-3.
> >  > >
> >  > >
> >  > > Can this be easily fixed?
> >  > >
> >  > >
> >  > > Thanks,
> >  > > - Jay
> >  > >
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > M3devel mailing list
> >  > > M3devel at elegosoft.com
> >  > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >  > >
> >  >
> >  > --
> >  > Rodney Bates
> >  > rodney.m.bates at acm.org
> >  > _______________________________________________
> >  > M3devel mailing list
> >  > M3devel at elegosoft.com
> >  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/7b3133de/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jul 30 02:38:49 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 00:38:49 +0000
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or
 exception handling?
Message-ID: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>

I don't have one precise proposal, but somehow,jmpbuf/setjmp/longjmp should be represented in a higher level in m3cgor maybe "even higher level", exception handling.

There are multiple optimization opportunties and multipleopportunities to move/remove target-dependent code.


In particular m3middle/m3front should not know jmpbuf size.Generated C should not have jmpbuf sizes embedded in it.

gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exceptionhandling, that llvm replicates, that is optimized, like to notsave/restore unused registers.

Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.

In particular, the C backend just wants to know something is a "jmpbuf"so it can #include <setjmp.h> in the generated code and produce ajmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.

Or even better, a C++ backend wants to somehow module Modula-3 exceptionsas C++ exceptions.

Or, possibly, the Win32 C backend could model Modula-3 exceptions using"structured exception handling" -- advantage over C++ exceptions is portabilityto kernel mode.

Thoughts? - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/9ebaac62/attachment-0001.html>

From jay.krell at cornell.edu  Thu Jul 30 06:36:34 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 04:36:34 +0000
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
 or exception handling?
In-Reply-To: <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>,
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
Message-ID: <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>

On the last point -- I'm willing to generate C++ instead of C. Does that help?I think it probably does.

On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS Ithink all support what Win32 support -- not a coincidence..

One thing I'm missing is I don't know really know how exceptions are lowered currently.Like, what does the runtime data look like for the "filtering".I should know better..

I think we can also essentially claim all targets have a stack walker.One way or another -- libunwind, NT RtlUnwindEx, etc.

 - Jay



Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
From: hosking at purdue.edu
Date: Thu, 30 Jul 2015 14:04:14 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu> wrote:I don't have one precise proposal, but somehow,jmpbuf/setjmp/longjmp should be represented in a higher level in m3cgor maybe "even higher level", exception handling.

There are multiple optimization opportunties and multipleopportunities to move/remove target-dependent code.


In particular m3middle/m3front should not know jmpbuf size.Generated C should not have jmpbuf sizes embedded in it.

gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exceptionhandling, that llvm replicates, that is optimized, like to notsave/restore unused registers.

Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.

In particular, the C backend just wants to know something is a "jmpbuf"so it can #include <setjmp.h> in the generated code and produce ajmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.

Or even better, a C++ backend wants to somehow module Modula-3 exceptionsas C++ exceptions.

Or, possibly, the Win32 C backend could model Modula-3 exceptions using"structured exception handling" -- advantage over C++ exceptions is portabilityto kernel mode.

Thoughts? - Jay

_______________________________________________M3devel mailing listM3devel at elegosoft.comhttps://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/4be773ce/attachment-0001.html>

From rodney_bates at lcwb.coop  Thu Jul 30 16:16:58 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 Jul 2015 09:16:58 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>, ,
 <55B03594.20800@lcwb.coop>, <COL130-W78229587075BD6B3A94050E6810@phx.gbl>,
 <55B25261.5010106@lcwb.coop> <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>
Message-ID: <55BA31DA.3020905@lcwb.coop>

I'm all for having a better IR in cm3.  I've had a few serious frustrations from lack of
sufficient information in it.  But, if we touch it at all, I really want to try very hard
to think of and do everything we are likely to want in the foreseeable future.  Any
change is painful.  There are somewhere in the neighborhood of 8 or so files that have
to reflect the change.  Also, it requires atomic update to both the front end and m3cc,
which then creates bootstrap issues that have to be handled very carefully.  Jay, your
recent changes to the build process help.  But I want to avoid changing it more than
once if we can possibly avoid it.  AFAIK, m3cc is the only one that ends up a separate
executable.

And when we do it, change the version number, for better mismatch messages.  Also,
it would be the best time to add a magic number, as Elmar was wanting.

One place I encountered was in trying to get better error messages from m3linker, etc.
We get stuff like (paraphrasing from memory) "Error: missing type _t187630885".  Need
I say more?  In trying to make these helpful, I ran up against lack of information.
I remember being able to make slight improvement in one message, but that was it,
without IR changes.

Then there are also some type info deficiencies for generating debug info.  I am
remembering something about inability to connect a procedure type to procedures
that match it, or something.

On 07/29/2015 07:07 PM, Jay K wrote:
> As part of fixing this, I want M3CG_Ops.i3
>
> declare_temp (s: ByteSize;  a: Alignment;  t: Type;
>                in_memory: BOOLEAN): Var;
>
>
> to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, if
> that syntax is allowed, or all existing calls can initially pass M3ID.NoID.
>
>
> The use in OpenArrayType.DeclareTemp will then be changed to something else.
> DeclareTemp will look more like OpenArrayType.Compiler.
>
>
> And, something will be done for jmpbufs, such having them be named and passing that name along
> somewhere. Or giving them a special uid, or even their own special CG.Type?
>
>
> And then, every use of CG.Type.Struct must come along with a TypeUID.
>
>
> ok?
>
> The C backend will/should actually be able notice the name of the jmpbuf type and substitute
> in.. #include <setjmp.h> jmpbuf.
>
> Other backends should  substitute in the alloca use.
>
> Or, it will be an internal parameter to the frontend for it to do the alloca transformation.
>
> But this is getting ahead of things.
>
> First -- change declare_temp to accept a TypeUID ok?
>
>
>
>   - Jay
>
>
>  > Date: Fri, 24 Jul 2015 09:57:37 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: jay.krell at cornell.edu; m3devel at elegosoft.com; m3devel at elegosoft.com
>  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  >
>  >
>  >
>  > On 07/24/2015 03:57 AM, Jay K wrote:
>  > > I model this in C like:
>  > >
>  > >
>  > > M3C.m3:
>  > > print(self, "/*declare_open_array*/typedef struct {");
>  >
>  > Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?
>  >
>  > > print(self, element_type.text);
>  > > print(self, "* _elts; CARDINAL _size");
>  > > IF bit_size > Target.Integer.size * 2 THEN
>  > > print(self, "s[");
>  > > print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
>  > > print(self, "]");
>  > > END;
>  > >
>  > >
>  > > that is..and this i stinky that I get the struct "size",
>  > >
>  > >
>  > > size == 2 * sizeof(integer):
>  > >
>  > >
>  > > struct {
>  > > T* elements
>  > > size_t size;
>  > > }
>  > >
>  > >
>  > > else:
>  > > N = size - sizeof(INTEGER) / sizeof(INTEGER)
>  > > T ** elements; // where the number of star is N
>  >
>  > I would not do pointer to pointer to pointer ... here. Just "T* elements", regardless
>  > of the number of open dimensions. As I understand them, C's language-supported
>  > multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
>  > the language does the multi-subscript address arithmetic, which means the type
>  > system needs to provide a static element size of each dimension. And that,
>  > except for the innermost, depends on the element count of the next inner
>  > dimension, which is not static here.
>  >
>  > So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
>  > is lowered by the front end into explicit address arithmetic into the flattened
>  > array, using the values in the shape. Something like A[I*Shape[0]+J*Shape[1]+K]
>  >
>  > > size_t sizes[N]
>  > >
>  > >
>  > > It is kind of lame that the frontend just gives the overall size
>  > > and the backend is just left to assume the layout like that.
>  >
>  > If you know in M3C that it's an open array, you can infer what the layout is.
>  > But yes, it's kind of lame. This is just another of the several places we have
>  > seen that the front end has lowered things too far, and you have to
>  > You know it's generated by code in OpenArray.m3, and you know the general dope layout,
>  > and open dimension count, so you can generate an appropriate type.
>  >
>  >
>  > >
>  > > Really, the frontend should declare a type "pointer to pointer to pointer" with
>  > > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
>  > >
>  > >
>  > > Again, really ugly how it works now where backend is just given a size and can only
>  > > assume the layout.
>  > >
>  > > I don't know what a "dope vector" is. A value used as an initializer?
>  > >
>  >
>  > This is a very old and rather uninformative term for any block of stuff stored at runtime
>  > that describes some source programmer's real data and how to access it. The only alternative
>  > term I can think of would be "metadata", although that is rather overgeneral, and is usually
>  > used with quite different specific meanings. But it is data describing data.
>  >
>  > >
>  > > It is even worse for subarray. In this case we aren't even told it is an open array, just
>  > > some random struct with a size. That is what I first want to fix. It should declare an open array,
>  > > assuming they do have the same layout, which I think they do.
>  > >
>  >
>  > What you really need to know is that it's an open array, of which subarray is a subcategory.
>  > In our implementation, all open array values have the same dope. E.g., look for the case where
>  > a fixed array actual parameter is passed to an open array formal.
>  >
>  > >
>  > > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
>  > > type information.
>  > >
>  > >
>  > > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
>  > > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
>  > >
>  > >
>  > >
>  > >
>  > > - Jay
>  > >
>  > >
>  > > > Date: Wed, 22 Jul 2015 19:30:12 -0500
>  > > > From: rodney_bates at lcwb.coop
>  > > > To: m3devel at elegosoft.com
>  > > > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  > > >
>  > > > I'm not exactly sure what you are asking, but here is some light on what
>  > > > you are seeing. These temporaries are exactly the dope the compiler uses
>  > > > to represent all open array values. First a pointer to the zeroth
>  > > > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
>  > > > an array of element counts for each open subscript. For an open array
>  > > > parameter, this would be the machine representation of the parameter
>  > > > itself, authored in M3. (but passed by reference.) For a heap object,
>  > > > it is stored right before the elements themselves. For a SUBARRAY
>  > > > expression, it has to be a temporary. It also has to be constructed
>  > > > at the call site, as an anonymous temporary, when passing an entire fixed
>  > > > array to an open array parameter
>  > > >
>  > > > So, a good type for it might look like:
>  > > >
>  > > >
>  > > > RECORD
>  > > > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
>  > > > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
>  > > > END
>  > > >
>  > > > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
>  > > > static limit here in the type of Elements, as it will be enforced dynamically,
>  > > > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
>  > > > as this would mean another open array inside the dope, resulting in infinite
>  > > > recursion.
>  > > >
>  > > > On 07/22/2015 12:42 AM, Jay K wrote:
>  > > > > In the C backend I have a notion of "weak struct types" and "strong struct types".
>  > > > >
>  > > > >
>  > > > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>  > > > >
>  > > > >
>  > > > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>  > > > >
>  > > > >
>  > > > >
>  > > > > Originally I had only weak types.
>  > > > > Ideally I have no weak types.
>  > > > > I'm down to very few weak types now.
>  > > > > I'd like to finish eliminating weak types.
>  > > > >
>  > > > >
>  > > > >
>  > > > > A quick investigation shows weak types come from open arrays and jmpbufs.
>  > > > > Open array temporaries from SUBARRAY specifically.
>  > > > >
>  > > > >
>  > > > >
>  > > > > Can we fix this?
>  > > > >
>  > > > >
>  > > > >
>  > > > > We have:
>  > > > > m3front/src/types/OpenArrayType.m3:
>  > > > >
>  > > > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>  > > > > VAR
>  > > > > p := Reduce (t);
>  > > > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > > > BEGIN
>  > > > > RETURN CG.Declare_temp (size, Target.Address.align,
>  > > > > CG.Type.Struct, in_memory := TRUE);
>  > > > > END DeclareTemp;
>  > > > >
>  > > > >
>  > > > > PROCEDURE Compiler (p: P) =
>  > > > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > > > BEGIN
>  > > > > Type.Compile (p.element);
>  > > > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>  > > > > END Compiler;
>  > > > >
>  > > > >
>  > > > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
>  > > > > not variables authored by anyone in Modula-3.
>  > > > >
>  > > > >
>  > > > > Can this be easily fixed?
>  > > > >
>  > > > >
>  > > > > Thanks,
>  > > > > - Jay
>  > > > >
>  > > > >
>  > > > >
>  > > > > _______________________________________________
>  > > > > M3devel mailing list
>  > > > > M3devel at elegosoft.com
>  > > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  > > > >
>  > > >
>  > > > --
>  > > > Rodney Bates
>  > > > rodney.m.bates at acm.org
>  > > > _______________________________________________
>  > > > M3devel mailing list
>  > > > M3devel at elegosoft.com
>  > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Thu Jul 30 16:27:25 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 Jul 2015 09:27:25 -0500
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
 or exception handling?
In-Reply-To: <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>,
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
 <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>
Message-ID: <55BA344D.3020407@lcwb.coop>



On 07/29/2015 11:36 PM, Jay K wrote:
> On the last point -- I'm willing to generate C++ instead of C. Does that help?
> I think it probably does.
>
>
> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
> think all support what Win32 support -- not a coincidence..
>
>
> One thing I'm missing is I don't know really know how exceptions are lowered currently.
> Like, what does the runtime data look like for the "filtering".
> I should know better..
>
>
> I think we can also essentially claim all targets have a stack walker.
> One way or another -- libunwind, NT RtlUnwindEx, etc.

Really?  That would be great news.  If it really applies to them all, wouldn't
the jmpbuf problem just go away?

>
>
>   - Jay
>
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
> From: hosking at purdue.edu
> Date: Thu, 30 Jul 2015 14:04:14 +1000
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
> That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
>
>     On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>
>     I don't have one precise proposal, but somehow,
>     jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>     or maybe "even higher level", exception handling.
>
>
>     There are multiple optimization opportunties and multiple
>     opportunities to move/remove target-dependent code.
>
>
>
>     In particular m3middle/m3front should not know jmpbuf size.
>     Generated C should not have jmpbuf sizes embedded in it.
>
>
>     gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>     handling, that llvm replicates, that is optimized, like to not
>     save/restore unused registers.
>
>
>     Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>
>
>     In particular, the C backend just wants to know something is a "jmpbuf"
>     so it can #include <setjmp.h> in the generated code and produce a
>     jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>
>
>     Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>     as C++ exceptions.
>
>
>     Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>     "structured exception handling" -- advantage over C++ exceptions is portability
>     to kernel mode.
>
>
>     Thoughts?
>       - Jay
>
>
>     _______________________________________________
>     M3devel mailing list
>     M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>     https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Thu Jul 30 21:32:42 2015
From: jay.krell at cornell.edu (Jay)
Date: Thu, 30 Jul 2015 12:32:42 -0700
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
	or exception handling?
In-Reply-To: <55BA344D.3020407@lcwb.coop>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
 <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl> <55BA344D.3020407@lcwb.coop>
Message-ID: <5C73404D-582C-46BF-8F45-D6F1615B8769@gmail.com>

I believe libunwind/libgcc_s applies pretty broadly and address all non-NT platforms. I believe NT/non-x86 is documented enough. NT/x86 will take more research.


I also believe generating C++ is a good option, or Win32-specific C.


I do have the alloca+setjmp work finally almost done, slightly more work than I earlier realized & would like to get it in first, then optimize it in the C backend (the C backend specifically should declare a setjmp.h declared jmp_buf w/o alloca), & then look more into the "unwind" options. 


 - Jay

On Jul 30, 2015, at 7:27 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> 
> 
> On 07/29/2015 11:36 PM, Jay K wrote:
>> On the last point -- I'm willing to generate C++ instead of C. Does that help?
>> I think it probably does.
>> 
>> 
>> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
>> think all support what Win32 support -- not a coincidence..
>> 
>> 
>> One thing I'm missing is I don't know really know how exceptions are lowered currently.
>> Like, what does the runtime data look like for the "filtering".
>> I should know better..
>> 
>> 
>> I think we can also essentially claim all targets have a stack walker.
>> One way or another -- libunwind, NT RtlUnwindEx, etc.
> 
> Really?  That would be great news.  If it really applies to them all, wouldn't
> the jmpbuf problem just go away?
> 
>> 
>> 
>>  - Jay
>> 
>> 
>> 
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
> ---
>> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
>> From: hosking at purdue.edu
>> Date: Thu, 30 Jul 2015 14:04:14 +1000
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
>> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
>> That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
>> 
>>    On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>> 
>>    I don't have one precise proposal, but somehow,
>>    jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>>    or maybe "even higher level", exception handling.
>> 
>> 
>>    There are multiple optimization opportunties and multiple
>>    opportunities to move/remove target-dependent code.
>> 
>> 
>> 
>>    In particular m3middle/m3front should not know jmpbuf size.
>>    Generated C should not have jmpbuf sizes embedded in it.
>> 
>> 
>>    gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>>    handling, that llvm replicates, that is optimized, like to not
>>    save/restore unused registers.
>> 
>> 
>>    Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>> 
>> 
>>    In particular, the C backend just wants to know something is a "jmpbuf"
>>    so it can #include <setjmp.h> in the generated code and produce a
>>    jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>> 
>> 
>>    Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>>    as C++ exceptions.
>> 
>> 
>>    Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>>    "structured exception handling" -- advantage over C++ exceptions is portability
>>    to kernel mode.
>> 
>> 
>>    Thoughts?
>>      - Jay
>> 
>> 
>>    _______________________________________________
>>    M3devel mailing list
>>    M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>>    https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>> 
>> 
>> 
>> 
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri Jul 31 22:39:43 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 31 Jul 2015 15:39:43 -0500
Subject: [M3devel] m3core.h broken
Message-ID: <55BBDD0F.4080206@lcwb.coop>

On AMD64_LINUX, with gcc 4.8.1, m3-libs/src/m3core.h suffers many compile errors,
when compiling on m3core and cm3.  reverting line 363 of m3core.h makes them go away.
This is probably not the right way to fix this.


-- 
Rodney Bates
rodney.m.bates at acm.org


From wagner at elego.de  Thu Jul  2 17:40:06 2015
From: wagner at elego.de (Olaf Wagner)
Date: Thu, 02 Jul 2015 15:40:06 -0000
Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
 (0x100), expected 0x110
In-Reply-To: <55687266.3090400@marino.st>
References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>
 <55673AA4.8050100@marino.st>
 <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>
 <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>
 <556817A1.2090206@marino.st>
 <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>
 <55682D1A.2030504@marino.st>
 <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>
 <55683689.2090709@marino.st>
 <20150529122732.1396eb079ff9b404bcb21e40@elego.de>
 <5568421D.3050209@marino.st>
 <20150529155833.8454664b88391d93708e8f85@elego.de>
 <55687266.3090400@marino.st>
Message-ID: <20150529170707.ca3550f7aeda21e7853be995@elego.de>

On Fri, 29 May 2015 16:06:30 +0200
John Marino <adacore at marino.st> wrote:

> On 5/29/2015 15:58, Olaf Wagner wrote:
> > On Fri, 29 May 2015 12:40:29 +0200
> > John Marino <adacore at marino.st> wrote:
> > I unpacked your port and tried the first step.
> > But my system seems to be too old:
> > 
> > % make fetch 
> > ===>  modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later.
> > *** Error code 1
> 
> This means at best your machine is FreeBSD 8.x.  The last FreeBSD 8, 8.4
> (a long-term support version) expires in 4 weeks.  So you should update. :)
> 
> 
> > Stop in /src/ports/lang/modula3.
> > 
> > Why would it only run on FreeBSD 9?
> > I actually _have_ a  working cm3 installation on this system ;-)
> 
> The port doesn't consider installed CM3.  It has to do with how ports
> are now built in "clean" jails where nothing is installed.
> 
> You *could* package your working CM3 as a bootstrap compiler [1] but I
> would think your time would be better spent with FreeBSD Update:
> https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
> 
> John
> 
> 
> [1] Just look in work/bootstrap and emulate if you want to do this.

If I understand the makefile correctly, I should use the bootstrap
modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz, but I cannot find that:

% wget --no-check-certificate http://downloads.dragonlace.net/m3/modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz
--2015-05-29 17:04:08--  http://downloads.dragonlace.net/m3/modula3-cm3-5.10.0-8c1b86a_GH0.tar.gz
Resolving downloads.dragonlace.net... 208.69.230.148
Connecting to downloads.dragonlace.net|208.69.230.148|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-05-29 17:04:08 ERROR 404: Not Found.

I can download the other bootstrap file, but that would be for
Dragonfly, not for FreeBSD, correct?
Some stupid mistake?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150702/667cf61e/attachment-0002.sig>

From wagner at elegosoft.com  Thu Jul  2 17:40:07 2015
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 02 Jul 2015 15:40:07 -0000
Subject: [M3devel] Thread tests, was: Re:  the need for cooperative suspend
In-Reply-To: <20150606165023.78AEC1A2066@async.async.caltech.edu>
References: <COL130-W74C829AA2D11E60BB5A735E6D40@phx.gbl>
 <20150502155713.29DCC1A2062@async.async.caltech.edu>
 <B843CEEA-CE8E-4E35-A2EA-ECCC795E3BA2@purdue.edu>
 <20150606165023.78AEC1A2066@async.async.caltech.edu>
Message-ID: <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>

On Sat, 06 Jun 2015 09:50:23 -0700
mika at async.caltech.edu wrote:

> Can the thread tester survive with the most paranoid options on OS X?
> I don't believe it until I've seen it (based on what we went through for
> Linux, I would say I'm just being prudent).
> 
> Run it with:
> 
> "-iters 100000 -n 20 -tests ALL"
> 
> I remember the thread tester died on FreeBSD last time I tried, and
> there have been no relevant checkins since that I know of.
> 
> Here's what happens when I run it on my FreeBSD.  CM3 is not up to date,
> in case someone fixed something I'm not aware of, so don't draw too
> many conclusions until someone has tried it on a fresh install:
> 
> ..........laziest thread is 1433608799/9/1 (tests: read 10/6/6 nxread 26/6/4 tryexcept 67/53/38 fork 1433608799/2/2 forktoomuch 1433608799/9/3 alloc 1433608799/37/1 creat 10/7/7 lock 1433608799/68/38)
> 
> 
> ***
> *** runtime error:
> ***    Segmentation violation - possible attempt to dereference NIL
> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
> ***
> 
> Abort
> (79)pluto:/tmp>
> 
> Anyone who's interested in trying their own favorite Modula-3 installation,
> this is easy to do:
> 
> cm3/m3-libs/m3core/tests/thread/AMD64_FREEBSD/threadtest -iters 100000 -n 20 -tests ALL

For those interested:

I have run the tests with the options above on my FreeBSD 8 system
(yes, I know, that's unsupported now ;-).

time ./AMD64_FREEBSD/threadtest  -iters 100000 -n 20 -tests ALL 2>&1 | egrep -v "appears starved or deadlocked" | tee threadtest.log

It ran several hours during the night; system load was nearly 20.
top -H showed all the threads. The log does not show any runtime error 
(attached).

I also tried this on my Mac with OS/X 10.9.5, but I had to kill it
after an hour because it used up all the resources and I had to work.
Less aggressive tests didn't show any failure there, too.

So I guess the pthreads runtime has indeed improved.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threadtest.log
Type: application/octet-stream
Size: 106496 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150702/b3ed946e/attachment-0002.obj>

From mika at async.caltech.edu  Thu Jul  2 19:35:49 2015
From: mika at async.caltech.edu (mika at async.caltech.edu)
Date: Thu, 02 Jul 2015 10:35:49 -0700
Subject: [M3devel] Thread tests,
	was: Re:  the need for cooperative suspend
In-Reply-To: <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>
References: <COL130-W74C829AA2D11E60BB5A735E6D40@phx.gbl>
 <20150502155713.29DCC1A2062@async.async.caltech.edu>
 <B843CEEA-CE8E-4E35-A2EA-ECCC795E3BA2@purdue.edu>
 <20150606165023.78AEC1A2066@async.async.caltech.edu>
 <20150609224448.807c1d3942e02a041be4d043@elegosoft.com>
Message-ID: <20150702173549.ADF471A206A@async.async.caltech.edu>


Great news!!!

If anyone finds problems in pthreads on a system where the thread tester
works I would be very interested, first of course because of the bad
news that the system is broken but secondly because I would also want
to enhance the tester so that the bugs don't get by it.

I think if pthreads works well in CM3, that's a big step forward in
the range of applications the system can be used for.

    Mika

Olaf Wagner writes:
>This is a multi-part message in MIME format.
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn
>Content-Type: text/plain; charset=UTF-8
>Content-Transfer-Encoding: 8bit
>
>On Sat, 06 Jun 2015 09:50:23 -0700
>mika at async.caltech.edu wrote:
>
>> Can the thread tester survive with the most paranoid options on OS X?
>> I don't believe it until I've seen it (based on what we went through for
>> Linux, I would say I'm just being prudent).
>> 
>> Run it with:
>> 
>> "-iters 100000 -n 20 -tests ALL"
>> 
>> I remember the thread tester died on FreeBSD last time I tried, and
>> there have been no relevant checkins since that I know of.
>> 
>> Here's what happens when I run it on my FreeBSD.  CM3 is not up to date,
>> in case someone fixed something I'm not aware of, so don't draw too
>> many conclusions until someone has tried it on a fresh install:
>> 
>> ..........laziest thread is 1433608799/9/1 (tests: read 10/6/6 nxread 26/6/4 tryexcept 67/53/38 fork 1433608799/2/2
> forktoomuch 1433608799/9/3 alloc 1433608799/37/1 creat 10/7/7 lock 1433608799/68/38)
>> 
>> 
>> ***
>> *** runtime error:
>> ***    Segmentation violation - possible attempt to dereference NIL
>> ***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
>> ***
>> 
>> Abort
>> (79)pluto:/tmp>
>> 
>> Anyone who's interested in trying their own favorite Modula-3 installation,
>> this is easy to do:
>> 
>> cm3/m3-libs/m3core/tests/thread/AMD64_FREEBSD/threadtest -iters 100000 -n 20 -tests ALL
>
>For those interested:
>
>I have run the tests with the options above on my FreeBSD 8 system
>(yes, I know, that's unsupported now ;-).
>
>time ./AMD64_FREEBSD/threadtest  -iters 100000 -n 20 -tests ALL 2>&1 | egrep -v "appears starved or deadlocked" | tee
> threadtest.log
>
>It ran several hours during the night; system load was nearly 20.
>top -H showed all the threads. The log does not show any runtime error 
>(attached).
>
>I also tried this on my Mac with OS/X 10.9.5, but I had to kill it
>after an hour because it used up all the resources and I had to work.
>Less aggressive tests didn't show any failure there, too.
>
>So I guess the pthreads runtime has indeed improved.
>
>Olaf
>-- 
>Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
>               Gustav-Meyer-Allee 25 / Geb??ude 12, 13355 Berlin, Germany
>phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>Gesch??ftsf??hrer: Olaf Wagner | Sitz: Berlin
>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn
>Content-Type: application/octet-stream;
> name="threadtest.log"
>Content-Disposition: attachment;
> filename="threadtest.log"
>Content-Transfer-Encoding: base64
>
>V3JpdGluZyBmaWxlLi4uZG9uZQpDcmVhdGluZyByZWFkIHRocmVhZHMuLi5kb25lCkNyZWF0aW5n
>IG54cmVhZCB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyB0cnlleGNlcHQgdGhyZWFkcy4uLmRvbmUK
>Q3JlYXRpbmcgZm9yayB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyBmb3JrdG9vbXVjaCB0aHJlYWRz
>Li4uZG9uZQpDcmVhdGluZyBhbGxvYyB0aHJlYWRzLi4uZG9uZQpDcmVhdGluZyBjcmVhdCB0aHJl
>YWRzLi4uZG9uZQpDcmVhdGluZyBsb2NrIHRocmVhZHMuLi5kb25lCnJ1bm5pbmcuLi5wcmludGlu
>ZyBvbGRlc3QvbWVkaWFuIGFnZS9uZXdlc3QKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTAyMTQvMTQzMzcxMDIxNC8wICh0ZXN0czogcmVhZCAxNDMzNzEwMjE0LzE0MzM3MTAyMTQv
>MTQzMzcxMDIxNCBueHJlYWQgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgdHJ5ZXhj
>ZXB0IDEvMC8wIGZvcmsgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgZm9ya3Rvb211
>Y2ggMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQgYWxsb2MgMTQzMzcxMDIxNC8xNDMz
>NzEwMjE0LzE0MzM3MTAyMTQgY3JlYXQgMTQzMzcxMDIxNC8xNDMzNzEwMjE0LzE0MzM3MTAyMTQg
>bG9jayAxNDMzNzEwMjE0LzE0MzM3MTAyMTQvMTQzMzcxMDIxNCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEwMjg2
>LzE0MzM3MTAyODYvMTYgbnhyZWFkIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IHRy
>eWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGZvcmt0
>b29tdWNoIDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGFsbG9jIDE0MzM3MTAyODYv
>Ny8xIGNyZWF0IDE0MzM3MTAyODYvMTQzMzcxMDI4Ni8xNDMzNzEwMjg2IGxvY2sgMTQzMzcxMDI4
>Ni8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwMzEyLzE0MzM3MTAzMTIv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMDMxMi8xNDMzNzEwMzEyLzEzIG54cmVhZCAxNDMzNzEwMzEy
>LzE0MzM3MTAzMTIvMTQzMzcxMDMxMiB0cnlleGNlcHQgMTMvMS8xIGZvcmsgMTQzMzcxMDMxMi8x
>NDMzNzEwMzEyLzE0MzM3MTAzMTIgZm9ya3Rvb211Y2ggMTQzMzcxMDMxMi8xNDMzNzEwMzEyLzE0
>MzM3MTAzMTIgYWxsb2MgMzMvMTIvNSBjcmVhdCAxNDMzNzEwMzEyLzE0MzM3MTAzMTIvMTQzMzcx
>MDMxMiBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMDM1Ny8x
>NDMzNzEwMzU3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTAzNTcvMTQzMzcxMDM1Ny8xIG54cmVhZCAx
>NDMzNzEwMzU3LzE0MzM3MTAzNTcvMTQzMzcxMDM1NyB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMz
>NzEwMzU3LzE0MzM3MTAzNTcvMTQzMzcxMDM1NyBmb3JrdG9vbXVjaCAxNDMzNzEwMzU3LzE0MzM3
>MTAzNTcvMTQzMzcxMDM1NyBhbGxvYyA1Ny8xOS8xIGNyZWF0IDE0MzM3MTAzNTcvMTQzMzcxMDM1
>Ny8xNDMzNzEwMzU3IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzEwMzgwLzE0MzM3MTAzODAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMDM4MC8xNDMzNzEwMzgwLzEg
>bnhyZWFkIDE0MzM3MTAzODAvMTQzMzcxMDM4MC8xNDMzNzEwMzgwIHRyeWV4Y2VwdCAyNi84LzAg
>Zm9yayAxNDMzNzEwMzgwLzE0MzM3MTAzODAvMTQzMzcxMDM4MCBmb3JrdG9vbXVjaCAxNDMzNzEw
>MzgwLzE0MzM3MTAzODAvMTQzMzcxMDM4MCBhbGxvYyA4MC85LzEgY3JlYXQgMTQzMzcxMDM4MC8x
>NDMzNzEwMzgwLzE0MzM3MTAzODAgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MTA0MTQvMTQzMzcxMDQxNC8wICh0ZXN0czogcmVhZCAxNDMzNzEwNDE0LzE0MzM3
>MTA0MTQvMjEgbnhyZWFkIDE0MzM3MTA0MTQvMTQzMzcxMDQxNC8xNDMzNzEwNDE0IHRyeWV4Y2Vw
>dCAxNi8yLzEgZm9yayAxNDMzNzEwNDE0LzE0MzM3MTA0MTQvMTQzMzcxMDQxNCBmb3JrdG9vbXVj
>aCAxNDMzNzEwNDE0LzE0MzM3MTA0MTQvMTQzMzcxMDQxNCBhbGxvYyAzOC80LzQgY3JlYXQgMTQz
>MzcxMDQxNC8xNDMzNzEwNDE0LzE0MzM3MTA0MTQgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEw
>NDQyLzE0MzM3MTA0NDIvMjIgbnhyZWFkIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQy
>IHRyeWV4Y2VwdCA1LzIvMSBmb3JrIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyIGZv
>cmt0b29tdWNoIDE0MzM3MTA0NDIvMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyIGFsbG9jIDMyLzE1LzYg
>Y3JlYXQgMTQzMzcxMDQ0Mi8xNDMzNzEwNDQyLzE0MzM3MTA0NDIgbG9jayA2LzYvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA0NzkvMTQzMzcxMDQ3OS8wICh0ZXN0czogcmVh
>ZCAxNDMzNzEwNDc5LzE0MzM3MTA0NzkvNSBueHJlYWQgMTQzMzcxMDQ3OS8xNDMzNzEwNDc5LzE5
>IHRyeWV4Y2VwdCA1LzIvMSBmb3JrIDE0MzM3MTA0NzkvMTQzMzcxMDQ3OS8xOCBmb3JrdG9vbXVj
>aCAxNDMzNzEwNDc5LzE0MzM3MTA0NzkvMTQzMzcxMDQ3OSBhbGxvYyAzNy84LzUgY3JlYXQgMTQz
>MzcxMDQ3OS8xNDMzNzEwNDc5LzE0MzM3MTA0NzkgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTA1MDQvMTQzMzcxMDUwNC8wICh0ZXN0czogcmVhZCAxNDMzNzEw
>NTA0LzE0MzM3MTA1MDQvMzAgbnhyZWFkIDE0MzM3MTA1MDQvMTQzMzcxMDUwNC80NCB0cnlleGNl
>cHQgNC8xLzAgZm9yayAxNDMzNzEwNTA0LzE0MzM3MTA1MDQvNDMgZm9ya3Rvb211Y2ggMTQzMzcx
>MDUwNC8xNDMzNzEwNTA0LzE0MzM3MTA1MDQgYWxsb2MgNTcvOC8yIGNyZWF0IDE0MzM3MTA1MDQv
>MTQzMzcxMDUwNC8xNDMzNzEwNTA0IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzEwNTQ1LzE0MzM3MTA1NDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMDU0NS8xNDMz
>NzEwNTQ1LzcxIG54cmVhZCAxNDMzNzEwNTQ1LzE0MzM3MTA1NDUvODUgdHJ5ZXhjZXB0IDQvMC8w
>IGZvcmsgMTQzMzcxMDU0NS8xNDMzNzEwNTQ1Lzg0IGZvcmt0b29tdWNoIDE0MzM3MTA1NDUvMTQz
>MzcxMDU0NS8xNDMzNzEwNTQ1IGFsbG9jIDQ5LzgvMyBjcmVhdCAxNDMzNzEwNTQ1LzE0MzM3MTA1
>NDUvMTQzMzcxMDU0NSBsb2NrIDIvMi8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMDU3Mi8xNDMzNzEwNTcyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA1NzIvMTQzMzcxMDU3Mi85
>OCBueHJlYWQgMTQzMzcxMDU3Mi8xNDMzNzEwNTcyLzExMiB0cnlleGNlcHQgOC8zLzAgZm9yayAx
>NDMzNzEwNTcyLzE0MzM3MTA1NzIvMTExIGZvcmt0b29tdWNoIDE0MzM3MTA1NzIvMTQzMzcxMDU3
>Mi8xNDMzNzEwNTcyIGFsbG9jIDQxLzE1LzEgY3JlYXQgMTQzMzcxMDU3Mi8xNDMzNzEwNTcyLzE0
>MzM3MTA1NzIgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA1
>OTkvMTQzMzcxMDU5OS8wICh0ZXN0czogcmVhZCAxNDMzNzEwNTk5LzE0MzM3MTA1OTkvMTMgbnhy
>ZWFkIDE0MzM3MTA1OTkvMTQzMzcxMDU5OS8xMzkgdHJ5ZXhjZXB0IDM1LzEvMSBmb3JrIDE0MzM3
>MTA1OTkvMTQzMzcxMDU5OS8xMzggZm9ya3Rvb211Y2ggMTQzMzcxMDU5OS8xNDMzNzEwNTk5LzE0
>MzM3MTA1OTkgYWxsb2MgNTIvMTMvNCBjcmVhdCAxNDMzNzEwNTk5LzE0MzM3MTA1OTkvMTQzMzcx
>MDU5OSBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMDYzMC8x
>NDMzNzEwNjMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA2MzAvMTQzMzcxMDYzMC8xMiBueHJlYWQg
>MTQzMzcxMDYzMC8xNDMzNzEwNjMwLzE3MCB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzEwNjMw
>LzE0MzM3MTA2MzAvMTY5IGZvcmt0b29tdWNoIDE0MzM3MTA2MzAvMTQzMzcxMDYzMC8xNDMzNzEw
>NjMwIGFsbG9jIDMxLzEyLzUgY3JlYXQgMTQzMzcxMDYzMC8xNDMzNzEwNjMwLzE0MzM3MTA2MzAg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA2NTkvMTQzMzcx
>MDY1OS8wICh0ZXN0czogcmVhZCAxNDMzNzEwNjU5LzE0MzM3MTA2NTkvNiBueHJlYWQgMTQzMzcx
>MDY1OS8xNDMzNzEwNjU5LzE5OSB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzEwNjU5LzE0MzM3
>MTA2NTkvNiBmb3JrdG9vbXVjaCAxNDMzNzEwNjU5LzE0MzM3MTA2NTkvMTQzMzcxMDY1OSBhbGxv
>YyAzNC8xMS82IGNyZWF0IDE0MzM3MTA2NTkvMTQzMzcxMDY1OS8xNDMzNzEwNjU5IGxvY2sgNC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwNjc4LzIxNy8wICh0ZXN0czog
>cmVhZCAxNDMzNzEwNjc4LzE0MzM3MTA2NzgvMjUgbnhyZWFkIDE0MzM3MTA2NzgvMTQzMzcxMDY3
>OC8yMTggdHJ5ZXhjZXB0IDE1LzMvMCBmb3JrIDE0MzM3MTA2NzgvMTQzMzcxMDY3OC8yNSBmb3Jr
>dG9vbXVjaCAxNDMzNzEwNjc4LzE0MzM3MTA2NzgvMTQzMzcxMDY3OCBhbGxvYyAzMC81LzEgY3Jl
>YXQgMTQzMzcxMDY3OC8xLzEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTA3MjIvMjYxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTA3MjIvMTQzMzcxMDcyMi81IG54
>cmVhZCAxNDMzNzEwNzIyLzE0MzM3MTA3MjIvMjYyIHRyeWV4Y2VwdCAxOS8yLzAgZm9yayAxNDMz
>NzEwNzIyLzE0MzM3MTA3MjIvMTcgZm9ya3Rvb211Y2ggMTQzMzcxMDcyMi8xNDMzNzEwNzIyLzE0
>MzM3MTA3MjIgYWxsb2MgNDkvMS8xIGNyZWF0IDE0MzM3MTA3MjIvNDUvNDUgbG9jayAxLzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA3NjcvMzA2LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MTA3NjcvMTQzMzcxMDc2Ny81MCBueHJlYWQgMTQzMzcxMDc2Ny8xNDMzNzEwNzY3LzMw
>NyB0cnlleGNlcHQgMTUvMi8xIGZvcmsgMTQzMzcxMDc2Ny8xNDMzNzEwNzY3LzYyIGZvcmt0b29t
>dWNoIDE0MzM3MTA3NjcvMTQzMzcxMDc2Ny8xNDMzNzEwNzY3IGFsbG9jIDU2LzgvMyBjcmVhdCAx
>NDMzNzEwNzY3LzkwLzkwIGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEwNzk5LzE0Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEwNzk5LzE0MzM3MTA3OTkvMTUgbnhy
>ZWFkIDE0MzM3MTA3OTkvMTQzMzcxMDc5OS8zMzkgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQzMzcx
>MDc5OS8xNDMzNzEwNzk5LzE5IGZvcmt0b29tdWNoIDE0MzM3MTA3OTkvMTQzMzcxMDc5OS8xNDMz
>NzEwNzk5IGFsbG9jIDEwLzYvNiBjcmVhdCAxNDMzNzEwNzk5LzEyMi8xMjIgbG9jayAwLzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA4MjEvMTY4LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MTA4MjEvMTQzMzcxMDgyMS8zNyBueHJlYWQgMTQzMzcxMDgyMS8xNDMzNzEwODIxLzM2
>MSB0cnlleGNlcHQgMTYvMi8xIGZvcmsgMTQzMzcxMDgyMS8xNDMzNzEwODIxLzQxIGZvcmt0b29t
>dWNoIDE0MzM3MTA4MjEvMTQzMzcxMDgyMS8xNDMzNzEwODIxIGFsbG9jIDMyLzE0LzAgY3JlYXQg
>MTQzMzcxMDgyMS8xNDQvMTQ0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzEwODU5LzIwNi8wICh0ZXN0czogcmVhZCAxNDMzNzEwODU5LzE0MzM3MTA4NTkvMjgg
>bnhyZWFkIDE0MzM3MTA4NTkvMTQzMzcxMDg1OS8zOTkgdHJ5ZXhjZXB0IDM2LzMvMCBmb3JrIDE0
>MzM3MTA4NTkvMTQzMzcxMDg1OS83OSBmb3JrdG9vbXVjaCAxNDMzNzEwODU5LzE0MzM3MTA4NTkv
>MTQzMzcxMDg1OSBhbGxvYyA1Mi84LzIgY3JlYXQgMTQzMzcxMDg1OS8xODIvMTgyIGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEwODg0LzIzMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEwODg0LzE0MzM3MTA4ODQvMjIgbnhyZWFkIDE0MzM3MTA4ODQvMTQzMzcxMDg4
>NC80MjQgdHJ5ZXhjZXB0IDQ0LzIvMCBmb3JrIDE0MzM3MTA4ODQvMTQzMzcxMDg4NC8xMDQgZm9y
>a3Rvb211Y2ggMTQzMzcxMDg4NC8xNDMzNzEwODg0LzE0MzM3MTA4ODQgYWxsb2MgNzcvMTcvMSBj
>cmVhdCAxNDMzNzEwODg0LzIwNy8yMDcgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTA5MDcvMjU0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTA5MDcvMTQzMzcxMDkw
>Ny8xOSBueHJlYWQgMTQzMzcxMDkwNy8xNDMzNzEwOTA3LzQ0NyB0cnlleGNlcHQgNjcvMS8wIGZv
>cmsgMTQzMzcxMDkwNy8xNDMzNzEwOTA3LzEyNyBmb3JrdG9vbXVjaCAxNDMzNzEwOTA3LzE0MzM3
>MTA5MDcvMTQzMzcxMDkwNyBhbGxvYyAxMDAvMjQvMiBjcmVhdCAxNDMzNzEwOTA3LzIzMC8yMzAg
>bG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTA5NzYvMjk5LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTA5NzYvMTQzMzcxMDk3Ni85IG54cmVhZCAxNDMzNzEwOTc2LzE0
>MzM3MTA5NzYvNTE2IHRyeWV4Y2VwdCA0My8yLzEgZm9yayAxNDMzNzEwOTc2LzE0MzM3MTA5NzYv
>MTk2IGZvcmt0b29tdWNoIDE0MzM3MTA5NzYvMTQzMzcxMDk3Ni8xNDMzNzEwOTc2IGFsbG9jIDgz
>LzQvMCBjcmVhdCAyOTkvMjk5LzI3IGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzEwOTk5LzMyMi8wICh0ZXN0czogcmVhZCAxNDMzNzEwOTk5LzE0MzM3MTA5OTkv
>MiBueHJlYWQgMTQzMzcxMDk5OS8xNDMzNzEwOTk5LzUzOSB0cnlleGNlcHQgMy8wLzAgZm9yayAx
>NDMzNzEwOTk5LzE0MzM3MTA5OTkvMTIgZm9ya3Rvb211Y2ggMTQzMzcxMDk5OS8xNDMzNzEwOTk5
>LzE0MzM3MTA5OTkgYWxsb2MgMjcvNy8yIGNyZWF0IDMyMi8zMjIvNTAgbG9jayAxLzEvMSkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTEwNDQvMzY3LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTEwNDQvMTQzMzcxMTA0NC8xIG54cmVhZCAxNDMzNzExMDQ0LzE0MzM3MTEwNDQvNTg0IHRy
>eWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTEwNDQvMTQzMzcxMTA0NC81NyBmb3JrdG9vbXVjaCAx
>NDMzNzExMDQ0LzE0MzM3MTEwNDQvMTQzMzcxMTA0NCBhbGxvYyA1OC83LzEgY3JlYXQgMzY3LzM2
>Ny85NSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTA3OS80
>MDIvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTA3OS8xNDMzNzExMDc5LzIyIG54cmVhZCAxNDMzNzEx
>MDc5LzE0MzM3MTEwNzkvNjE5IHRyeWV4Y2VwdCA5LzIvMiBmb3JrIDE0MzM3MTEwNzkvMTQzMzcx
>MTA3OS85MiBmb3JrdG9vbXVjaCAxNDMzNzExMDc5LzE0MzM3MTEwNzkvMTQzMzcxMTA3OSBhbGxv
>YyAzMS8xMC84IGNyZWF0IDQwMi80MDIvMTMwIGxvY2sgNy82LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzExMTEzLzQzNi8wICh0ZXN0czogcmVhZCAxNDMzNzExMTEzLzE0MzM3
>MTExMTMvMjUgbnhyZWFkIDE0MzM3MTExMTMvMTQzMzcxMTExMy82NTMgdHJ5ZXhjZXB0IDQvMy8w
>IGZvcmsgMTQzMzcxMTExMy8xNDMzNzExMTEzLzEyNiBmb3JrdG9vbXVjaCAxNDMzNzExMTEzLzE0
>MzM3MTExMTMvMTQzMzcxMTExMyBhbGxvYyA0NC8xMS8xIGNyZWF0IDQzNi80MzYvMTY0IGxvY2sg
>MS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExMTUzLzQyLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTExNTMvMTQzMzcxMTE1My8xMCBueHJlYWQgMTQzMzcxMTE1My8xNDMzNzEx
>MTUzLzY5MyB0cnlleGNlcHQgNDIvMi8xIGZvcmsgMTQzMzcxMTE1My8xNDMzNzExMTUzLzE2NiBm
>b3JrdG9vbXVjaCAxNDMzNzExMTUzLzE0MzM3MTExNTMvMTQzMzcxMTE1MyBhbGxvYyA1MS8xOC80
>IGNyZWF0IDIwNC8xMC8xMCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxMTE4Ny80NC8wICh0ZXN0czogcmVhZCAxNDMzNzExMTg3LzE0MzM3MTExODcvMTYgbnhy
>ZWFkIDE0MzM3MTExODcvMTQzMzcxMTE4Ny83MjcgdHJ5ZXhjZXB0IDE3LzAvMCBmb3JrIDE0MzM3
>MTExODcvMTQzMzcxMTE4Ny8yMDAgZm9ya3Rvb211Y2ggMTQzMzcxMTE4Ny8xNDMzNzExMTg3LzE0
>MzM3MTExODcgYWxsb2MgMzQvNS8zIGNyZWF0IDIzOC80NC80NCBsb2NrIDEvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTIyOS84Ni8wICh0ZXN0czogcmVhZCAxNDMzNzEx
>MjI5LzE0MzM3MTEyMjkvNTggbnhyZWFkIDE0MzM3MTEyMjkvMTQzMzcxMTIyOS83NjkgdHJ5ZXhj
>ZXB0IDUvMi8xIGZvcmsgMTQzMzcxMTIyOS8xNDMzNzExMjI5LzI0MiBmb3JrdG9vbXVjaCAxNDMz
>NzExMjI5LzE0MzM3MTEyMjkvMTQzMzcxMTIyOSBhbGxvYyAyMS8xMS81IGNyZWF0IDI4MC84Ni84
>NiBsb2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTI1NS8xMTIv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMTI1NS8xNDMzNzExMjU1LzIxIG54cmVhZCAxNDMzNzExMjU1
>LzE0MzM3MTEyNTUvNzk1IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTEyNTUvMTQzMzcxMTI1
>NS8yMCBmb3JrdG9vbXVjaCAxNDMzNzExMjU1LzE0MzM3MTEyNTUvMTQzMzcxMTI1NSBhbGxvYyAz
>MS81LzEgY3JlYXQgMzA2LzExMi8xMTIgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTEyODEvMTM4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTEyODEvMTQzMzcxMTI4
>MS80NyBueHJlYWQgMTQzMzcxMTI4MS8xNDMzNzExMjgxLzgyMSB0cnlleGNlcHQgMTcvMy8xIGZv
>cmsgMTQzMzcxMTI4MS8xNDMzNzExMjgxLzQ2IGZvcmt0b29tdWNoIDE0MzM3MTEyODEvMTQzMzcx
>MTI4MS8xNDMzNzExMjgxIGFsbG9jIDMxLzcvMyBjcmVhdCAzMzIvMTM4LzEzOCBsb2NrIDMvMy8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTMxMC8xNjcvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMTMxMC8xNDMzNzExMzEwLzE2IG54cmVhZCAxNDMzNzExMzEwLzE0MzM3MTEzMTAv
>ODUwIHRyeWV4Y2VwdCAxMS8yLzEgZm9yayAxNDMzNzExMzEwLzE0MzM3MTEzMTAvNzUgZm9ya3Rv
>b211Y2ggMTQzMzcxMTMxMC8xNDMzNzExMzEwLzE0MzM3MTEzMTAgYWxsb2MgMzkvMTAvMyBjcmVh
>dCAzNjEvMTY3LzE2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMTM0MS8xOTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTM0MS8xNDMzNzExMzQxLzI2IG54cmVh
>ZCAxNDMzNzExMzQxLzE0MzM3MTEzNDEvODgxIHRyeWV4Y2VwdCAxNS8yLzIgZm9yayAxNDMzNzEx
>MzQxLzE0MzM3MTEzNDEvMTA2IGZvcmt0b29tdWNoIDE0MzM3MTEzNDEvMTQzMzcxMTM0MS8xNDMz
>NzExMzQxIGFsbG9jIDQxLzE0LzYgY3JlYXQgMzkyLzE5OC8xOTggbG9jayA1LzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTEzNjgvMjI1LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTEzNjgvMTQzMzcxMTM2OC81MyBueHJlYWQgMTQzMzcxMTM2OC8xNDMzNzExMzY4LzkwOCB0cnll
>eGNlcHQgNC8zLzAgZm9yayAxNDMzNzExMzY4LzE0MzM3MTEzNjgvMTMzIGZvcmt0b29tdWNoIDE0
>MzM3MTEzNjgvMTQzMzcxMTM2OC8xNDMzNzExMzY4IGFsbG9jIDQ3LzcvMSBjcmVhdCA0MTkvMjI1
>LzIyNSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTM5My8y
>NTAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTM5My8xNDMzNzExMzkzLzE0IG54cmVhZCAxNDMzNzEx
>MzkzLzE0MzM3MTEzOTMvOTMzIHRyeWV4Y2VwdCA4LzEvMSBmb3JrIDE0MzM3MTEzOTMvMTQzMzcx
>MTM5My8xNTggZm9ya3Rvb211Y2ggMTQzMzcxMTM5My8xNDMzNzExMzkzLzE0MzM3MTEzOTMgYWxs
>b2MgMzIvMTQvNyBjcmVhdCA0NDQvMjUwLzI1MCBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTQyMC8yNzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTQyMC8xNDMz
>NzExNDIwLzYgbnhyZWFkIDE0MzM3MTE0MjAvMTQzMzcxMTQyMC85NjAgdHJ5ZXhjZXB0IDUvMi8x
>IGZvcmsgMTQzMzcxMTQyMC8xNDMzNzExNDIwLzE4NSBmb3JrdG9vbXVjaCAxNDMzNzExNDIwLzE0
>MzM3MTE0MjAvMTQzMzcxMTQyMCBhbGxvYyAyNy8xNy82IGNyZWF0IDQ3MS8yNzcvMjc3IGxvY2sg
>Ni82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNDQ3LzMwNC8wICh0ZXN0
>czogcmVhZCAxNDMzNzExNDQ3LzE0MzM3MTE0NDcvMjAgbnhyZWFkIDE0MzM3MTE0NDcvMTQzMzcx
>MTQ0Ny85ODcgdHJ5ZXhjZXB0IDgvMi8yIGZvcmsgMTQzMzcxMTQ0Ny8xNDMzNzExNDQ3LzE5IGZv
>cmt0b29tdWNoIDE0MzM3MTE0NDcvMTQzMzcxMTQ0Ny8xNDMzNzExNDQ3IGFsbG9jIDQ0LzExLzcg
>Y3JlYXQgNDk4LzMwNC8zMDQgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTE0NzIvMzI5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTE0NzIvMTQzMzcxMTQ3Mi82IG54
>cmVhZCAxNDMzNzExNDcyLzE0MzM3MTE0NzIvMTAxMiB0cnlleGNlcHQgNS8yLzIgZm9yayAxNDMz
>NzExNDcyLzE0MzM3MTE0NzIvNDQgZm9ya3Rvb211Y2ggMTQzMzcxMTQ3Mi8xNDMzNzExNDcyLzE0
>MzM3MTE0NzIgYWxsb2MgNDEvMTEvMCBjcmVhdCA1MjMvMzI5LzMyOSBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTUwMi8zNTkvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMTUwMi8xNDMzNzExNTAyLzIgbnhyZWFkIDE0MzM3MTE1MDIvMTQzMzcxMTUwMi8xMDQyIHRy
>eWV4Y2VwdCAyNC8xLzAgZm9yayAxNDMzNzExNTAyLzE0MzM3MTE1MDIvNzQgZm9ya3Rvb211Y2gg
>MTQzMzcxMTUwMi8xNDMzNzExNTAyLzE0MzM3MTE1MDIgYWxsb2MgNzEvNS8yIGNyZWF0IDU1My8z
>NTkvMzU5IGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNTI3
>LzM4NC8wICh0ZXN0czogcmVhZCAxNDMzNzExNTI3LzE0MzM3MTE1MjcvOCBueHJlYWQgMTQzMzcx
>MTUyNy8xNDMzNzExNTI3LzEwNjcgdHJ5ZXhjZXB0IDE4LzIvMCBmb3JrIDE0MzM3MTE1MjcvMTQz
>MzcxMTUyNy83IGZvcmt0b29tdWNoIDE0MzM3MTE1MjcvMTQzMzcxMTUyNy8xNDMzNzExNTI3IGFs
>bG9jIDM1LzgvMSBjcmVhdCA1NzgvMzg0LzM4NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTU1OC80MTUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTU1OC8xNDMz
>NzExNTU4LzcgbnhyZWFkIDE0MzM3MTE1NTgvMTQzMzcxMTU1OC8xMDk4IHRyeWV4Y2VwdCAyNS8y
>LzIgZm9yayAxNDMzNzExNTU4LzE0MzM3MTE1NTgvNyBmb3JrdG9vbXVjaCAxNDMzNzExNTU4LzE0
>MzM3MTE1NTgvMTQzMzcxMTU1OCBhbGxvYyAzOS8xMS83IGNyZWF0IDYwOS80MTUvNDE1IGxvY2sg
>Ny83LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExNTgxLzQzOC8wICh0ZXN0
>czogcmVhZCAxNDMzNzExNTgxLzE0MzM3MTE1ODEvMzAgbnhyZWFkIDE0MzM3MTE1ODEvMTQzMzcx
>MTU4MS8xMTIxIHRyeWV4Y2VwdCA0LzMvMCBmb3JrIDE0MzM3MTE1ODEvMTQzMzcxMTU4MS8zMCBm
>b3JrdG9vbXVjaCAxNDMzNzExNTgxLzE0MzM3MTE1ODEvMTQzMzcxMTU4MSBhbGxvYyAzNC8xLzEg
>Y3JlYXQgNjMyLzQzOC80MzggbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTE2MDUvNDYyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE2MDUvMTQzMzcxMTYwNS8yIG54
>cmVhZCAxNDMzNzExNjA1LzE0MzM3MTE2MDUvMTE0NSB0cnlleGNlcHQgNC8wLzAgZm9yayAxNDMz
>NzExNjA1LzE0MzM3MTE2MDUvMiBmb3JrdG9vbXVjaCAxNDMzNzExNjA1LzE0MzM3MTE2MDUvMTQz
>MzcxMTYwNSBhbGxvYyAzMS8yLzIgY3JlYXQgNjU2LzQ2Mi80NjIgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTE2NDAvNDk3LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTE2NDAvMTQzMzcxMTY0MC81IG54cmVhZCAxNDMzNzExNjQwLzE0MzM3MTE2NDAvMTE4MCB0cnll
>eGNlcHQgNC8xLzEgZm9yayAxNDMzNzExNjQwLzE0MzM3MTE2NDAvMzcgZm9ya3Rvb211Y2ggMTQz
>MzcxMTY0MC8xNDMzNzExNjQwLzE0MzM3MTE2NDAgYWxsb2MgNDMvMTEvNSBjcmVhdCA2OTEvNDk3
>LzQ5NyBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTY3Mi81
>MjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTY3Mi8xNDMzNzExNjcyLzE2IG54cmVhZCAxNDMzNzEx
>NjcyLzE0MzM3MTE2NzIvMTIxMiB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzExNjcyLzE0MzM3
>MTE2NzIvNjkgZm9ya3Rvb211Y2ggMTQzMzcxMTY3Mi8xNDMzNzExNjcyLzE0MzM3MTE2NzIgYWxs
>b2MgMjIvMTEvMCBjcmVhdCA3MjMvNTI5LzUyOSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTcxMy81NzAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMTcxMy8xNDMz
>NzExNzEzLzIwIG54cmVhZCAxNDMzNzExNzEzLzE0MzM3MTE3MTMvMTI1MyB0cnlleGNlcHQgNC8y
>LzEgZm9yayAxNDMzNzExNzEzLzE0MzM3MTE3MTMvMTEwIGZvcmt0b29tdWNoIDE0MzM3MTE3MTMv
>MTQzMzcxMTcxMy8xNDMzNzExNzEzIGFsbG9jIDUyLzUvNSBjcmVhdCA3NjQvNTcwLzU3MCBsb2Nr
>IDUvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTc0Ni82MDMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxMTc0Ni8xNDMzNzExNzQ2LzUzIG54cmVhZCAxNDMzNzExNzQ2LzE0MzM3
>MTE3NDYvMTI4NiB0cnlleGNlcHQgMjAvMi8xIGZvcmsgMTQzMzcxMTc0Ni8xNDMzNzExNzQ2LzE0
>MyBmb3JrdG9vbXVjaCAxNDMzNzExNzQ2LzE0MzM3MTE3NDYvMTQzMzcxMTc0NiBhbGxvYyAzMy81
>LzIgY3JlYXQgNzk3LzYwMy82MDMgbG9jayAyLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MTE3NzMvNjMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE3NzMvMTQzMzcxMTc3My8x
>OCBueHJlYWQgMTQzMzcxMTc3My8xNDMzNzExNzczLzEzMTMgdHJ5ZXhjZXB0IDI4LzAvMCBmb3Jr
>IDE0MzM3MTE3NzMvMTQzMzcxMTc3My8xNzAgZm9ya3Rvb211Y2ggMTQzMzcxMTc3My8xNDMzNzEx
>NzczLzE0MzM3MTE3NzMgYWxsb2MgMzIvMTgvMiBjcmVhdCA4MjQvNjMwLzYzMCBsb2NrIDIvMi8x
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTc5Ny82NTQvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMTc5Ny8xNDMzNzExNzk3LzggbnhyZWFkIDE0MzM3MTE3OTcvMTQzMzcxMTc5Ny8x
>MzM3IHRyeWV4Y2VwdCA0MC8yLzEgZm9yayAxNDMzNzExNzk3LzE0MzM3MTE3OTcvMTk0IGZvcmt0
>b29tdWNoIDE0MzM3MTE3OTcvMTQzMzcxMTc5Ny8xNDMzNzExNzk3IGFsbG9jIDQ2LzE3LzMgY3Jl
>YXQgODQ4LzY1NC82NTQgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTE4MzQvNjkxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTE4MzQvMTQzMzcxMTgzNC8xMiBueHJl
>YWQgMTQzMzcxMTgzNC8xNDMzNzExODM0LzEzNzQgdHJ5ZXhjZXB0IDMxLzIvMCBmb3JrIDE0MzM3
>MTE4MzQvMTQzMzcxMTgzNC8yMzEgZm9ya3Rvb211Y2ggMTQzMzcxMTgzNC8xNDMzNzExODM0LzE0
>MzM3MTE4MzQgYWxsb2MgNDAvNC8wIGNyZWF0IDg4NS82OTEvNjkxIGxvY2sgMS8xLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExODg4Lzc0NS8wICh0ZXN0czogcmVhZCAxNDMz
>NzExODg4LzE0MzM3MTE4ODgvMjYgbnhyZWFkIDE0MzM3MTE4ODgvMTQzMzcxMTg4OC8xNDI4IHRy
>eWV4Y2VwdCA5LzIvMSBmb3JrIDE0MzM3MTE4ODgvMTQzMzcxMTg4OC8yODUgZm9ya3Rvb211Y2gg
>MTQzMzcxMTg4OC8xNDMzNzExODg4LzE0MzM3MTE4ODggYWxsb2MgMjYvMTIvNyBjcmVhdCA5Mzkv
>NzQ1Lzc0NSBsb2NrIDcvNy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMTky
>My82MS8wICh0ZXN0czogcmVhZCAxNDMzNzExOTIzLzE0MzM3MTE5MjMvNjEgbnhyZWFkIDE0MzM3
>MTE5MjMvMTQzMzcxMTkyMy8xNDYzIHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzExOTIzLzE0
>MzM3MTE5MjMvMzIwIGZvcmt0b29tdWNoIDE0MzM3MTE5MjMvMTQzMzcxMTkyMy8xNDMzNzExOTIz
>IGFsbG9jIDI1LzcvMCBjcmVhdCAyOC8yOC8yOCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMTk1NS82MC8wICh0ZXN0czogcmVhZCAxNDMzNzExOTU1LzE0MzM3
>MTE5NTUvOCBueHJlYWQgMTQzMzcxMTk1NS8xNDMzNzExOTU1LzE0OTUgdHJ5ZXhjZXB0IDIzLzMv
>MSBmb3JrIDE0MzM3MTE5NTUvMTQzMzcxMTk1NS8zNTIgZm9ya3Rvb211Y2ggMTQzMzcxMTk1NS8x
>NDMzNzExOTU1LzE0MzM3MTE5NTUgYWxsb2MgMzIvOC8zIGNyZWF0IDYwLzYwLzYwIGxvY2sgMy8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzExOTk2LzEwMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzExOTk2LzE0MzM3MTE5OTYvMSBueHJlYWQgMTQzMzcxMTk5Ni8xNDMzNzExOTk2
>LzE1MzYgdHJ5ZXhjZXB0IDYyLzIvMCBmb3JrIDE0MzM3MTE5OTYvMTQzMzcxMTk5Ni8zOTMgZm9y
>a3Rvb211Y2ggMTQzMzcxMTk5Ni8xNDMzNzExOTk2LzE0MzM3MTE5OTYgYWxsb2MgNDEvNC8xIGNy
>ZWF0IDEwMS8xMDEvMTAxIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEyMDMyLzEzNy8wICh0ZXN0czogcmVhZCAxNDMzNzEyMDMyLzE0MzM3MTIwMzIvMjAgbnhy
>ZWFkIDE0MzM3MTIwMzIvMTQzMzcxMjAzMi8xNTcyIHRyeWV4Y2VwdCA2LzIvMSBmb3JrIDE0MzM3
>MTIwMzIvMTQzMzcxMjAzMi80MjkgZm9ya3Rvb211Y2ggMTQzMzcxMjAzMi8xNDMzNzEyMDMyLzE0
>MzM3MTIwMzIgYWxsb2MgMzcvMTYvMCBjcmVhdCAxMzcvMTM3LzEzNyBsb2NrIDQvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjA2My8xNjgvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMjA2My8xNDMzNzEyMDYzLzE1IG54cmVhZCAxNDMzNzEyMDYzLzE0MzM3MTIwNjMvMTYwMyB0
>cnlleGNlcHQgMjUvMy8xIGZvcmsgMTQzMzcxMjA2My8xNDMzNzEyMDYzLzQ2MCBmb3JrdG9vbXVj
>aCAxNDMzNzEyMDYzLzE0MzM3MTIwNjMvMTQzMzcxMjA2MyBhbGxvYyA0MC8xMC81IGNyZWF0IDE2
>OC8xNjgvMTY4IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEy
>MDk1LzIwMC8wICh0ZXN0czogcmVhZCAxNDMzNzEyMDk1LzE0MzM3MTIwOTUvNSBueHJlYWQgMTQz
>MzcxMjA5NS8xNDMzNzEyMDk1LzE2MzUgdHJ5ZXhjZXB0IDI3LzEvMCBmb3JrIDE0MzM3MTIwOTUv
>MTQzMzcxMjA5NS80OTIgZm9ya3Rvb211Y2ggMTQzMzcxMjA5NS8xNDMzNzEyMDk1LzE0MzM3MTIw
>OTUgYWxsb2MgNTgvMTAvMiBjcmVhdCAyMDAvMjAwLzIwMCBsb2NrIDEvMS8xKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjEyNC8yMjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjEy
>NC8xNDMzNzEyMTI0LzEgbnhyZWFkIDE0MzM3MTIxMjQvMTQzMzcxMjEyNC8xNjY0IHRyeWV4Y2Vw
>dCA4LzMvMCBmb3JrIDE0MzM3MTIxMjQvMTQzMzcxMjEyNC81MjEgZm9ya3Rvb211Y2ggMTQzMzcx
>MjEyNC8xNDMzNzEyMTI0LzE0MzM3MTIxMjQgYWxsb2MgMzkvNi8xIGNyZWF0IDIyOS8yMjkvMjI5
>IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyMTY1LzI3MC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzEyMTY1LzE0MzM3MTIxNjUvMjMgbnhyZWFkIDE0MzM3MTIxNjUv
>MTQzMzcxMjE2NS8xNzA1IHRyeWV4Y2VwdCA1LzIvMiBmb3JrIDE0MzM3MTIxNjUvMTQzMzcxMjE2
>NS81NjIgZm9ya3Rvb211Y2ggMTQzMzcxMjE2NS8xNDMzNzEyMTY1LzE0MzM3MTIxNjUgYWxsb2Mg
>NTIvNS81IGNyZWF0IDI3MC8yNzAvMjcwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzEyMTg3LzI5Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEyMTg3LzE0MzM3MTIx
>ODcvOSBueHJlYWQgMTQzMzcxMjE4Ny8xNDMzNzEyMTg3LzE3MjcgdHJ5ZXhjZXB0IDE4LzIvMCBm
>b3JrIDE0MzM3MTIxODcvMTQzMzcxMjE4Ny81ODQgZm9ya3Rvb211Y2ggMTQzMzcxMjE4Ny8xNDMz
>NzEyMTg3LzE0MzM3MTIxODcgYWxsb2MgNzQvNS8xIGNyZWF0IDI5Mi8yOTIvMjkyIGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyMjE2LzMyMS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEyMjE2LzE0MzM3MTIyMTYvOCBueHJlYWQgMTQzMzcxMjIxNi8xNDMzNzEyMjE2
>LzE3NTYgdHJ5ZXhjZXB0IDkvMS8xIGZvcmsgMTQzMzcxMjIxNi8xNDMzNzEyMjE2LzYxMyBmb3Jr
>dG9vbXVjaCAxNDMzNzEyMjE2LzE0MzM3MTIyMTYvMTQzMzcxMjIxNiBhbGxvYyA1MS8yMS80IGNy
>ZWF0IDMyMS8zMjEvMzIxIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzEyMjQ1LzM1MC8wICh0ZXN0czogcmVhZCAxNDMzNzEyMjQ1LzE0MzM3MTIyNDUvMTUgbnhy
>ZWFkIDE0MzM3MTIyNDUvMTQzMzcxMjI0NS8xNzg1IHRyeWV4Y2VwdCAzOC8yLzEgZm9yayAxNDMz
>NzEyMjQ1LzE0MzM3MTIyNDUvNjQyIGZvcmt0b29tdWNoIDE0MzM3MTIyNDUvMTQzMzcxMjI0NS8x
>NDMzNzEyMjQ1IGFsbG9jIDczLzgvNCBjcmVhdCAzNTAvMzUwLzM1MCBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjI3MC8zNzUvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxMjI3MC8xNDMzNzEyMjcwLzYgbnhyZWFkIDE0MzM3MTIyNzAvMTQzMzcxMjI3MC8xODEwIHRy
>eWV4Y2VwdCAyMi8yLzEgZm9yayAxNDMzNzEyMjcwLzE0MzM3MTIyNzAvNjY3IGZvcmt0b29tdWNo
>IDE0MzM3MTIyNzAvMTQzMzcxMjI3MC8xNDMzNzEyMjcwIGFsbG9jIDU0LzkvNiBjcmVhdCAzNzUv
>Mzc1LzM3NSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjMw
>MC80MDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjMwMC8xNDMzNzEyMzAwLzEzIG54cmVhZCAxNDMz
>NzEyMzAwLzE0MzM3MTIzMDAvMTg0MCB0cnlleGNlcHQgNTIvMi8xIGZvcmsgMTQzMzcxMjMwMC8x
>NDMzNzEyMzAwLzY5NyBmb3JrdG9vbXVjaCAxNDMzNzEyMzAwLzE0MzM3MTIzMDAvMTQzMzcxMjMw
>MCBhbGxvYyAxOC8zLzMgY3JlYXQgNDA1LzQwNS80MDUgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTIzNDIvNDQ3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTIzNDIv
>MTQzMzcxMjM0Mi8xNiBueHJlYWQgMTQzMzcxMjM0Mi8xNDMzNzEyMzQyLzE4ODIgdHJ5ZXhjZXB0
>IDEzLzIvMSBmb3JrIDE0MzM3MTIzNDIvMTQzMzcxMjM0Mi83MzkgZm9ya3Rvb211Y2ggMTQzMzcx
>MjM0Mi8xNDMzNzEyMzQyLzE0MzM3MTIzNDIgYWxsb2MgNjAvMjAvNSBjcmVhdCA0NDcvNDQ3LzQ0
>NyBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjM3Mi80Nzcv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxMjM3Mi8xNDMzNzEyMzcyLzMgbnhyZWFkIDE0MzM3MTIzNzIv
>MTQzMzcxMjM3Mi8xOTEyIHRyeWV4Y2VwdCAyLzIvMCBmb3JrIDE0MzM3MTIzNzIvMTQzMzcxMjM3
>Mi83NjkgZm9ya3Rvb211Y2ggMTQzMzcxMjM3Mi8xNDMzNzEyMzcyLzE0MzM3MTIzNzIgYWxsb2Mg
>MzAvOC8zIGNyZWF0IDQ3Ny80NzcvNDc3IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzEyNDM0LzUzOS8wICh0ZXN0czogcmVhZCAxNDMzNzEyNDM0LzE0MzM3MTI0
>MzQvMTcgbnhyZWFkIDE0MzM3MTI0MzQvMTQzMzcxMjQzNC8xOTc0IHRyeWV4Y2VwdCAxNi8yLzEg
>Zm9yayAxNDMzNzEyNDM0LzE0MzM3MTI0MzQvODMxIGZvcmt0b29tdWNoIDE0MzM3MTI0MzQvMTQz
>MzcxMjQzNC8xNDMzNzEyNDM0IGFsbG9jIDMzLzUvNSBjcmVhdCA1MzkvNTM5LzUzOSBsb2NrIDQv
>NC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjQ1Ny81NjIvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxMjQ1Ny8xNDMzNzEyNDU3LzMgbnhyZWFkIDE0MzM3MTI0NTcvMTQzMzcxMjQ1
>Ny8xOTk3IHRyeWV4Y2VwdCAxMy8yLzAgZm9yayAxNDMzNzEyNDU3LzE0MzM3MTI0NTcvODU0IGZv
>cmt0b29tdWNoIDE0MzM3MTI0NTcvMTQzMzcxMjQ1Ny8xNDMzNzEyNDU3IGFsbG9jIDI4LzMvMSBj
>cmVhdCA1NjIvNTYyLzU2MiBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxMjUwMC82MDUvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjUwMC8xNDMzNzEyNTAwLzE1IG54
>cmVhZCAxNDMzNzEyNTAwLzE0MzM3MTI1MDAvMjA0MCB0cnlleGNlcHQgNTMvMi8wIGZvcmsgMTQz
>MzcxMjUwMC8xNDMzNzEyNTAwLzg5NyBmb3JrdG9vbXVjaCAxNDMzNzEyNTAwLzE0MzM3MTI1MDAv
>MTQzMzcxMjUwMCBhbGxvYyA0NC8xNS8xIGNyZWF0IDYwNS82MDUvNjA1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyNTI4LzYzMy8wICh0ZXN0czogcmVhZCAx
>NDMzNzEyNTI4LzE0MzM3MTI1MjgvOCBueHJlYWQgMTQzMzcxMjUyOC8xNDMzNzEyNTI4LzIwNjgg
>dHJ5ZXhjZXB0IDQwLzIvMSBmb3JrIDE0MzM3MTI1MjgvMTQzMzcxMjUyOC85MjUgZm9ya3Rvb211
>Y2ggMTQzMzcxMjUyOC8xNDMzNzEyNTI4LzE0MzM3MTI1MjggYWxsb2MgNTAvOC80IGNyZWF0IDYz
>My82MzMvNjMzIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEy
>NTUwLzY1NS8wICh0ZXN0czogcmVhZCAxNDMzNzEyNTUwLzE0MzM3MTI1NTAvMjIgbnhyZWFkIDE0
>MzM3MTI1NTAvMTQzMzcxMjU1MC8yMDkwIHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzEyNTUw
>LzE0MzM3MTI1NTAvOTQ3IGZvcmt0b29tdWNoIDE0MzM3MTI1NTAvMTQzMzcxMjU1MC8xNDMzNzEy
>NTUwIGFsbG9jIDY1LzEwLzQgY3JlYXQgNjU1LzY1NS82NTUgbG9jayA0LzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI1NzcvNjgyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTI1
>NzcvMTQzMzcxMjU3Ny8xNiBueHJlYWQgMTQzMzcxMjU3Ny8xNDMzNzEyNTc3LzIxMTcgdHJ5ZXhj
>ZXB0IDgvMS8xIGZvcmsgMTQzMzcxMjU3Ny8xNDMzNzEyNTc3Lzk3NCBmb3JrdG9vbXVjaCAxNDMz
>NzEyNTc3LzE0MzM3MTI1NzcvMTQzMzcxMjU3NyBhbGxvYyAzNy8yMS8wIGNyZWF0IDY4Mi82ODIv
>NjgyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyNjAzLzcw
>OC8wICh0ZXN0czogcmVhZCAxNDMzNzEyNjAzLzE0MzM3MTI2MDMvMTAgbnhyZWFkIDE0MzM3MTI2
>MDMvMTQzMzcxMjYwMy8yMTQzIHRyeWV4Y2VwdCAxNi8zLzAgZm9yayAxNDMzNzEyNjAzLzE0MzM3
>MTI2MDMvMTAwMCBmb3JrdG9vbXVjaCAxNDMzNzEyNjAzLzE0MzM3MTI2MDMvMTQzMzcxMjYwMyBh
>bGxvYyAzNi8xNS8xMCBjcmVhdCA3MDgvNzA4LzcwOCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjYzMS83MzYvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjYzMS8x
>NDMzNzEyNjMxLzEgbnhyZWFkIDE0MzM3MTI2MzEvMTQzMzcxMjYzMS8yMTcxIHRyeWV4Y2VwdCAz
>OC8xLzAgZm9yayAxNDMzNzEyNjMxLzE0MzM3MTI2MzEvMTAyOCBmb3JrdG9vbXVjaCAxNDMzNzEy
>NjMxLzE0MzM3MTI2MzEvMTQzMzcxMjYzMSBhbGxvYyA2NC83LzEgY3JlYXQgNzM2LzczNi83MzYg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI2NTkvNzY0LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTI2NTkvMTQzMzcxMjY1OS8yOSBueHJlYWQgMTQzMzcxMjY1OS8x
>NDMzNzEyNjU5LzIxOTkgdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcxMjY1OS8xNDMzNzEyNjU5
>LzI0IGZvcmt0b29tdWNoIDE0MzM3MTI2NTkvMTQzMzcxMjY1OS8xNDMzNzEyNjU5IGFsbG9jIDI5
>LzMvMSBjcmVhdCA3NjQvNzY0Lzc2NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxMjY5Mi83OTcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjY5Mi8xNDMzNzEyNjky
>LzYyIG54cmVhZCAxNDMzNzEyNjkyLzE0MzM3MTI2OTIvMjIzMiB0cnlleGNlcHQgMzUvNy8wIGZv
>cmsgMTQzMzcxMjY5Mi8xNDMzNzEyNjkyLzU3IGZvcmt0b29tdWNoIDE0MzM3MTI2OTIvMTQzMzcx
>MjY5Mi8xNDMzNzEyNjkyIGFsbG9jIDM2LzYvMSBjcmVhdCA3OTcvNzk3Lzc5NyBsb2NrIDEvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjcxNy84MjIvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMjcxNy8xNDMzNzEyNzE3Lzg3IG54cmVhZCAxNDMzNzEyNzE3LzE0MzM3MTI3MTcv
>MjI1NyB0cnlleGNlcHQgMzcvMi8xIGZvcmsgMTQzMzcxMjcxNy8xNDMzNzEyNzE3LzgyIGZvcmt0
>b29tdWNoIDE0MzM3MTI3MTcvMTQzMzcxMjcxNy8xNDMzNzEyNzE3IGFsbG9jIDQ3LzYvMiBjcmVh
>dCA4MjIvODIyLzgyMiBsb2NrIDIvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMjc0Mi84NDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjc0Mi8xNDMzNzEyNzQyLzIgbnhyZWFk
>IDE0MzM3MTI3NDIvMTQzMzcxMjc0Mi8yMjgyIHRyeWV4Y2VwdCAyNi8xLzAgZm9yayAxNDMzNzEy
>NzQyLzE0MzM3MTI3NDIvMTA3IGZvcmt0b29tdWNoIDE0MzM3MTI3NDIvMTQzMzcxMjc0Mi8xNDMz
>NzEyNzQyIGFsbG9jIDcyLzcvMiBjcmVhdCA4NDcvODQ3Lzg0NyBsb2NrIDEvMS8xKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjc3My84NzgvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>Mjc3My8xNDMzNzEyNzczLzcgbnhyZWFkIDE0MzM3MTI3NzMvMTQzMzcxMjc3My8yMzEzIHRyeWV4
>Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzEyNzczLzE0MzM3MTI3NzMvMTM4IGZvcmt0b29tdWNoIDE0
>MzM3MTI3NzMvMTQzMzcxMjc3My8xNDMzNzEyNzczIGFsbG9jIDM4LzE0LzQgY3JlYXQgODc4Lzg3
>OC84NzggbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTI3OTgv
>OTAzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTI3OTgvMTQzMzcxMjc5OC8xIG54cmVhZCAxNDMzNzEy
>Nzk4LzE0MzM3MTI3OTgvMjMzOCB0cnlleGNlcHQgMTMvMy8wIGZvcmsgMTQzMzcxMjc5OC8xNDMz
>NzEyNzk4LzEyIGZvcmt0b29tdWNoIDE0MzM3MTI3OTgvMTQzMzcxMjc5OC8xNDMzNzEyNzk4IGFs
>bG9jIDUzLzQvMSBjcmVhdCA5MDMvOTAzLzkwMyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMjgzNC85MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjgzNC8xMDUw
>LzkgbnhyZWFkIDE0MzM3MTI4MzQvMTQzMzcxMjgzNC8yMzc0IHRyeWV4Y2VwdCAyMy8yLzEgZm9y
>ayAxNDMzNzEyODM0LzE0MzM3MTI4MzQvNDggZm9ya3Rvb211Y2ggMTQzMzcxMjgzNC8xNDMzNzEy
>ODM0LzE0MzM3MTI4MzQgYWxsb2MgNDgvMTcvNSBjcmVhdCA5MzkvOTM5LzkzOSBsb2NrIDUvNS8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjg3NS85ODAvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMjg3NS8xMDkxLzIyIG54cmVhZCAxNDMzNzEyODc1LzE0MzM3MTI4NzUvMjQxNSB0
>cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzEyODc1LzE0MzM3MTI4NzUvODkgZm9ya3Rvb211Y2gg
>MTQzMzcxMjg3NS8xNDMzNzEyODc1LzE0MzM3MTI4NzUgYWxsb2MgNDEvNi8xIGNyZWF0IDk4MC85
>ODAvOTgwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyOTA4
>LzEwMTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxMjkwOC8xMTI0LzU1IG54cmVhZCAxNDMzNzEyOTA4
>LzE0MzM3MTI5MDgvMjQ0OCB0cnlleGNlcHQgMy8yLzEgZm9yayAxNDMzNzEyOTA4LzE0MzM3MTI5
>MDgvMTIyIGZvcmt0b29tdWNoIDE0MzM3MTI5MDgvMTQzMzcxMjkwOC8xNDMzNzEyOTA4IGFsbG9j
>IDU5LzEyLzYgY3JlYXQgMTAxMy8xMDEzLzEwMTMgbG9jayA0LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTI5MjkvMTAzNC8wICh0ZXN0czogcmVhZCAxNDMzNzEyOTI5LzEx
>NDUvNSBueHJlYWQgMTQzMzcxMjkyOS8xNDMzNzEyOTI5LzI0NjkgdHJ5ZXhjZXB0IDUvMi8xIGZv
>cmsgMTQzMzcxMjkyOS8xNDMzNzEyOTI5LzE0MyBmb3JrdG9vbXVjaCAxNDMzNzEyOTI5LzE0MzM3
>MTI5MjkvMTQzMzcxMjkyOSBhbGxvYyA0NC8xMS81IGNyZWF0IDEwMzQvMTAzNC8xMDM0IGxvY2sg
>MC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEyOTU1LzEwNjAvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxMjk1NS8xMTcxLzI2IG54cmVhZCAxNDMzNzEyOTU1LzE0MzM3MTI5NTUv
>MjQ5NSB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzEyOTU1LzE0MzM3MTI5NTUvMTY5IGZvcmt0
>b29tdWNoIDE0MzM3MTI5NTUvMTQzMzcxMjk1NS8xNDMzNzEyOTU1IGFsbG9jIDM3LzEyLzQgY3Jl
>YXQgMTA2MC8xMDYwLzEwNjAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTI5NzcvMTA4Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEyOTc3LzExOTMvNDggbnhyZWFk
>IDE0MzM3MTI5NzcvMTQzMzcxMjk3Ny8yNTE3IHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzEy
>OTc3LzE0MzM3MTI5NzcvMTkxIGZvcmt0b29tdWNoIDE0MzM3MTI5NzcvMTQzMzcxMjk3Ny8xNDMz
>NzEyOTc3IGFsbG9jIDI2LzUvNSBjcmVhdCAxMDgyLzEwODIvMTA4MiBsb2NrIDAvMC8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMjk5Ni8xMTAxLzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTI5OTYvMTIxMi8xOSBueHJlYWQgMTQzMzcxMjk5Ni8xNDMzNzEyOTk2LzI1MzYgdHJ5ZXhj
>ZXB0IDIwLzIvMiBmb3JrIDE0MzM3MTI5OTYvMTQzMzcxMjk5Ni8yMTAgZm9ya3Rvb211Y2ggMTQz
>MzcxMjk5Ni8xNDMzNzEyOTk2LzE0MzM3MTI5OTYgYWxsb2MgNDUvMTEvMCBjcmVhdCAxMTAxLzEx
>MDEvMTEwMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzAx
>Ni8xMTIxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTMwMTYvMTIzMi82IG54cmVhZCAxNDMzNzEzMDE2
>LzE0MzM3MTMwMTYvMjU1NiB0cnlleGNlcHQgMzgvMC8wIGZvcmsgMTQzMzcxMzAxNi8xNDMzNzEz
>MDE2LzIzMCBmb3JrdG9vbXVjaCAxNDMzNzEzMDE2LzE0MzM3MTMwMTYvMTQzMzcxMzAxNiBhbGxv
>YyAyMC82LzIgY3JlYXQgMTEyMS8xMTIxLzExMjEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTMwMzcvMTE0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEzMDM3LzEy
>NTMvNyBueHJlYWQgMTQzMzcxMzAzNy8xNDMzNzEzMDM3LzI1NzcgdHJ5ZXhjZXB0IDE3LzEvMSBm
>b3JrIDE0MzM3MTMwMzcvMTQzMzcxMzAzNy8yNTEgZm9ya3Rvb211Y2ggMTQzMzcxMzAzNy8xNDMz
>NzEzMDM3LzE0MzM3MTMwMzcgYWxsb2MgMjcvMTgvMyBjcmVhdCAxMTQyLzExNDIvMTE0MiBsb2Nr
>IDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzA2MS8xMTY2LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTMwNjEvMTI3Ny82IG54cmVhZCAxNDMzNzEzMDYxLzE0MzM3MTMwNjEv
>MjYwMSB0cnlleGNlcHQgMTMvMS8xIGZvcmsgMTQzMzcxMzA2MS8xNDMzNzEzMDYxLzI3NSBmb3Jr
>dG9vbXVjaCAxNDMzNzEzMDYxLzE0MzM3MTMwNjEvMTQzMzcxMzA2MSBhbGxvYyA1MS8xNS8wIGNy
>ZWF0IDExNjYvMTE2Ni8xMTY2IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzEzMDgxLzExODYvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzA4MS8xMjk3LzkgbnhyZWFk
>IDE0MzM3MTMwODEvMTQzMzcxMzA4MS8yNjIxIHRyeWV4Y2VwdCAxNC85LzAgZm9yayAxNDMzNzEz
>MDgxLzE0MzM3MTMwODEvMjk1IGZvcmt0b29tdWNoIDE0MzM3MTMwODEvMTQzMzcxMzA4MS8xNDMz
>NzEzMDgxIGFsbG9jIDMyLzExLzAgY3JlYXQgMTE4Ni8xMTg2LzExODYgbG9jayAwLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTMxMDYvMTIxMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzEzMTA2LzEzMjIvNCBueHJlYWQgMTQzMzcxMzEwNi8xNDMzNzEzMTA2LzI2NDYgdHJ5ZXhj
>ZXB0IDI3LzEvMSBmb3JrIDE0MzM3MTMxMDYvMTQzMzcxMzEwNi8zMjAgZm9ya3Rvb211Y2ggMTQz
>MzcxMzEwNi8xNDMzNzEzMTA2LzE0MzM3MTMxMDYgYWxsb2MgMzYvOS80IGNyZWF0IDEyMTEvMTIx
>MS8xMjExIGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzMTM0
>LzEyMzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzEzNC8xMzUwLzMyIG54cmVhZCAxNDMzNzEzMTM0
>LzE0MzM3MTMxMzQvMjY3NCB0cnlleGNlcHQgMTYvMC8wIGZvcmsgMTQzMzcxMzEzNC8xNDMzNzEz
>MTM0LzM0OCBmb3JrdG9vbXVjaCAxNDMzNzEzMTM0LzE0MzM3MTMxMzQvMTQzMzcxMzEzNCBhbGxv
>YyAyOC81LzIgY3JlYXQgMTIzOS8xMjM5LzEyMzkgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTMxOTIvMzM5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTMxOTIvMTQw
>OC81IG54cmVhZCAxNDMzNzEzMTkyLzE0MzM3MTMxOTIvMjczMiB0cnlleGNlcHQgNC8yLzEgZm9y
>ayAxNDMzNzEzMTkyLzE0MzM3MTMxOTIvNSBmb3JrdG9vbXVjaCAxNDMzNzEzMTkyLzE0MzM3MTMx
>OTIvMTQzMzcxMzE5MiBhbGxvYyA0Mi8xMC8wIGNyZWF0IDEyOTcvMTI5Ny8xMyBsb2NrIDQvMy8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzIxNi8zNjMvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMzIxNi8xNDMyLzkgbnhyZWFkIDE0MzM3MTMyMTYvMTQzMzcxMzIxNi8yNzU2IHRy
>eWV4Y2VwdCAzLzIvMSBmb3JrIDE0MzM3MTMyMTYvMTQzMzcxMzIxNi8yOSBmb3JrdG9vbXVjaCAx
>NDMzNzEzMjE2LzE0MzM3MTMyMTYvMTQzMzcxMzIxNiBhbGxvYyAzNy8xNC83IGNyZWF0IDEzMjEv
>MTMyMS8zNyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzI0
>My8zOTAvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzI0My8xNDU5LzYgbnhyZWFkIDE0MzM3MTMyNDMv
>MTQzMzcxMzI0My8yNzgzIHRyeWV4Y2VwdCAyMS8yLzEgZm9yayAxNDMzNzEzMjQzLzE0MzM3MTMy
>NDMvNTYgZm9ya3Rvb211Y2ggMTQzMzcxMzI0My8xNDMzNzEzMjQzLzE0MzM3MTMyNDMgYWxsb2Mg
>MzQvMjAvNiBjcmVhdCAxMzQ4LzEzNDgvNjQgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTMyNzEvNDE4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTMyNzEvMTQ4Ny81
>IG54cmVhZCAxNDMzNzEzMjcxLzE0MzM3MTMyNzEvMjgxMSB0cnlleGNlcHQgMTAvMi8xIGZvcmsg
>MTQzMzcxMzI3MS8xNDMzNzEzMjcxLzg0IGZvcmt0b29tdWNoIDE0MzM3MTMyNzEvMTQzMzcxMzI3
>MS8xNDMzNzEzMjcxIGFsbG9jIDM0LzE4LzUgY3JlYXQgMTM3Ni8xMzc2LzkyIGxvY2sgNC80LzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzMzE4LzIyNy8wICh0ZXN0czogcmVh
>ZCAxNDMzNzEzMzE4LzQ2NS8xOSBueHJlYWQgMTQzMzcxMzMxOC8xNDMzNzEzMzE4LzI4NTggdHJ5
>ZXhjZXB0IDEzLzMvMCBmb3JrIDE0MzM3MTMzMTgvMTQzMzcxMzMxOC8xOCBmb3JrdG9vbXVjaCAx
>NDMzNzEzMzE4LzE0MzM3MTMzMTgvMTQzMzcxMzMxOCBhbGxvYyAyOC8xLzEgY3JlYXQgMTQyMy8x
>NDIzLzEzOSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzM1
>MC8yNTkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzM1MC8yNTkvMTcgbnhyZWFkIDE0MzM3MTMzNTAv
>MTQzMzcxMzM1MC8yODkwIHRyeWV4Y2VwdCAxOC8yLzAgZm9yayAxNDMzNzEzMzUwLzE0MzM3MTMz
>NTAvNTAgZm9ya3Rvb211Y2ggMTQzMzcxMzM1MC8xNDMzNzEzMzUwLzE0MzM3MTMzNTAgYWxsb2Mg
>MzMvMS8xIGNyZWF0IDE0NTUvMTQ1NS8xNzEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTM0NTAvMjgyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTM0NTAvMzU5LzE1
>IG54cmVhZCAxNDMzNzEzNDUwLzE0MzM3MTM0NTAvMjk5MCB0cnlleGNlcHQgMTIvMi8xIGZvcmsg
>MTQzMzcxMzQ1MC8xNDMzNzEzNDUwLzE1MCBmb3JrdG9vbXVjaCAxNDMzNzEzNDUwLzE0MzM3MTM0
>NTAvMTQzMzcxMzQ1MCBhbGxvYyA0Ni8yNS8wIGNyZWF0IDE1NTUvMTU1NS8yNzEgbG9jayA0LzQv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM0OTMvMzI1LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTM0OTMvNDAyLzE0IG54cmVhZCAxNDMzNzEzNDkzLzE0MzM3MTM0OTMvMzAzMyB0
>cnlleGNlcHQgNDAvMS8xIGZvcmsgMTQzMzcxMzQ5My8xNDMzNzEzNDkzLzE5MyBmb3JrdG9vbXVj
>aCAxNDMzNzEzNDkzLzE0MzM3MTM0OTMvMTQzMzcxMzQ5MyBhbGxvYyAxNC81LzAgY3JlYXQgMTU5
>OC8xNTk4LzMxNCBsb2NrIDUvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>MzUyMC8zNTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzUyMC80MjkvMSBueHJlYWQgMTQzMzcxMzUy
>MC8xNDMzNzEzNTIwLzMwNjAgdHJ5ZXhjZXB0IDIvMi8wIGZvcmsgMTQzMzcxMzUyMC8xNDMzNzEz
>NTIwLzIyMCBmb3JrdG9vbXVjaCAxNDMzNzEzNTIwLzE0MzM3MTM1MjAvMTQzMzcxMzUyMCBhbGxv
>YyAzNi8yLzEgY3JlYXQgMTYyNS8xNjI1LzM0MSBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzU2NS8zOTcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzU2NS80NzQv
>MSBueHJlYWQgMTQzMzcxMzU2NS8xNDMzNzEzNTY1LzMxMDUgdHJ5ZXhjZXB0IDgvMS8wIGZvcmsg
>MTQzMzcxMzU2NS8xNDMzNzEzNTY1LzI2NSBmb3JrdG9vbXVjaCAxNDMzNzEzNTY1LzE0MzM3MTM1
>NjUvMTQzMzcxMzU2NSBhbGxvYyA0Ny83LzEgY3JlYXQgMTY3MC8xNjcwLzM4NiBsb2NrIDEvMS8x
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzU4OC80MjAvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxMzU4OC80OTcvMjEgbnhyZWFkIDE0MzM3MTM1ODgvMTQzMzcxMzU4OC8zMTI4IHRy
>eWV4Y2VwdCAzMS8wLzAgZm9yayAxNDMzNzEzNTg4LzE0MzM3MTM1ODgvMjg4IGZvcmt0b29tdWNo
>IDE0MzM3MTM1ODgvMTQzMzcxMzU4OC8xNDMzNzEzNTg4IGFsbG9jIDIxLzYvMSBjcmVhdCAxNjkz
>LzE2OTMvNDA5IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEz
>NjIwLzQ1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzEzNjIwLzUyOS8xMCBueHJlYWQgMTQzMzcxMzYy
>MC8xNDMzNzEzNjIwLzMxNjAgdHJ5ZXhjZXB0IDMvMi8xIGZvcmsgMTQzMzcxMzYyMC8xNDMzNzEz
>NjIwLzE3IGZvcmt0b29tdWNoIDE0MzM3MTM2MjAvMTQzMzcxMzYyMC8xNDMzNzEzNjIwIGFsbG9j
>IDI1LzEwLzMgY3JlYXQgMTcyNS8xNzI1LzQ0MSBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzY2Ny80OTkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzY2Ny81NzYv
>MTcgbnhyZWFkIDE0MzM3MTM2NjcvMTQzMzcxMzY2Ny8zMjA3IHRyeWV4Y2VwdCA0LzIvMSBmb3Jr
>IDE0MzM3MTM2NjcvMTQzMzcxMzY2Ny82NCBmb3JrdG9vbXVjaCAxNDMzNzEzNjY3LzE0MzM3MTM2
>NjcvMTQzMzcxMzY2NyBhbGxvYyA0Mi8xMS81IGNyZWF0IDE3NzIvMTc3Mi80ODggbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM3MTMvNTQ1LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTM3MTMvNjIyLzIgbnhyZWFkIDE0MzM3MTM3MTMvMTQzMzcxMzcxMy8zMjUzIHRy
>eWV4Y2VwdCAzLzEvMCBmb3JrIDE0MzM3MTM3MTMvMTQzMzcxMzcxMy8xMTAgZm9ya3Rvb211Y2gg
>MTQzMzcxMzcxMy8xNDMzNzEzNzEzLzE0MzM3MTM3MTMgYWxsb2MgMjIvOC8yIGNyZWF0IDE4MTgv
>MTgxOC81MzQgbG9jayAyLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM3
>NDYvNTc4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTM3NDYvNjU1LzE0IG54cmVhZCAxNDMzNzEzNzQ2
>LzE0MzM3MTM3NDYvMzI4NiB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzEzNzQ2LzE0MzM3MTM3
>NDYvMTQzIGZvcmt0b29tdWNoIDE0MzM3MTM3NDYvMTQzMzcxMzc0Ni8xNDMzNzEzNzQ2IGFsbG9j
>IDM1LzEwLzUgY3JlYXQgMTg1MS8xODUxLzU2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxMzc5NS82MjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzc5NS83MDQv
>MTYgbnhyZWFkIDE0MzM3MTM3OTUvMTQzMzcxMzc5NS8zMzM1IHRyeWV4Y2VwdCA1LzIvMSBmb3Jr
>IDE0MzM3MTM3OTUvMTQzMzcxMzc5NS8xOTIgZm9ya3Rvb211Y2ggMTQzMzcxMzc5NS8xNDMzNzEz
>Nzk1LzE0MzM3MTM3OTUgYWxsb2MgMzMvMTEvNiBjcmVhdCAxOTAwLzE5MDAvNjE2IGxvY2sgNi82
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzEzODI3LzY1OS8wICh0ZXN0czog
>cmVhZCAxNDMzNzEzODI3LzczNi8xNCBueHJlYWQgMTQzMzcxMzgyNy8xNDMzNzEzODI3LzMzNjcg
>dHJ5ZXhjZXB0IDQvMy8wIGZvcmsgMTQzMzcxMzgyNy8xNDMzNzEzODI3LzIyNCBmb3JrdG9vbXVj
>aCAxNDMzNzEzODI3LzE0MzM3MTM4MjcvMTQzMzcxMzgyNyBhbGxvYyA0My8xLzEgY3JlYXQgMTkz
>Mi8xOTMyLzY0OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>Mzg2MS82OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzg2MS83NzAvMjEgbnhyZWFkIDE0MzM3MTM4
>NjEvMTQzMzcxMzg2MS8zNDAxIHRyeWV4Y2VwdCA0LzAvMCBmb3JrIDE0MzM3MTM4NjEvMTQzMzcx
>Mzg2MS8yNTggZm9ya3Rvb211Y2ggMTQzMzcxMzg2MS8xNDMzNzEzODYxLzE0MzM3MTM4NjEgYWxs
>b2MgNzcvOC8yIGNyZWF0IDE5NjYvMTk2Ni82ODIgbG9jayAyLzIvMSkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTM4OTEvNzIzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTM4OTEvODAw
>LzUxIG54cmVhZCAxNDMzNzEzODkxLzE0MzM3MTM4OTEvMzQzMSB0cnlleGNlcHQgNC8yLzEgZm9y
>ayAxNDMzNzEzODkxLzE0MzM3MTM4OTEvMjg4IGZvcmt0b29tdWNoIDE0MzM3MTM4OTEvMTQzMzcx
>Mzg5MS8xNDMzNzEzODkxIGFsbG9jIDI2LzEwLzUgY3JlYXQgMTk5Ni8xOTk2LzcxMiBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxMzkxOS83NTEvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxMzkxOS84MjgvMjIgbnhyZWFkIDE0MzM3MTM5MTkvMTQzMzcxMzkxOS8zNDU5
>IHRyeWV4Y2VwdCAyMi8yLzEgZm9yayAxNDMzNzEzOTE5LzE0MzM3MTM5MTkvMzE2IGZvcmt0b29t
>dWNoIDE0MzM3MTM5MTkvMTQzMzcxMzkxOS8xNDMzNzEzOTE5IGFsbG9jIDM4LzE0LzYgY3JlYXQg
>MjAyNC8yMDI0Lzc0MCBsb2NrIDYvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxMzkzNy83NjkvMCAodGVzdHM6IHJlYWQgMTQzMzcxMzkzNy84NDYvMTggbnhyZWFkIDE0MzM3
>MTM5MzcvMTQzMzcxMzkzNy8zNDc3IHRyeWV4Y2VwdCA0MC8wLzAgZm9yayAxNDMzNzEzOTM3LzE0
>MzM3MTM5MzcvMzM0IGZvcmt0b29tdWNoIDE0MzM3MTM5MzcvMTQzMzcxMzkzNy8xNDMzNzEzOTM3
>IGFsbG9jIDI3LzgvMyBjcmVhdCAyMDQyLzIwNDIvNzU4IGxvY2sgMi8yLzIpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzEzOTY2Lzc5OC8wICh0ZXN0czogcmVhZCAxNDMzNzEzOTY2
>Lzg3NS85IG54cmVhZCAxNDMzNzEzOTY2LzE0MzM3MTM5NjYvMzUwNiB0cnlleGNlcHQgMTQvMS8x
>IGZvcmsgMTQzMzcxMzk2Ni8xNDMzNzEzOTY2LzM2MyBmb3JrdG9vbXVjaCAxNDMzNzEzOTY2LzE0
>MzM3MTM5NjYvMTQzMzcxMzk2NiBhbGxvYyA0Mi8xNi80IGNyZWF0IDIwNzEvMjA3MS83ODcgbG9j
>ayA0LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTM5OTEvODIzLzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTM5OTEvOTAwLzExIG54cmVhZCAxNDMzNzEzOTkxLzE0MzM3MTM5OTEv
>MzUzMSB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzEzOTkxLzE0MzM3MTM5OTEvMTAgZm9ya3Rv
>b211Y2ggMTQzMzcxMzk5MS8xNDMzNzEzOTkxLzE0MzM3MTM5OTEgYWxsb2MgNDEvMTEvNSBjcmVh
>dCAyMDk2LzIwOTYvMTEgbG9jayA0LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQwMTkvODUxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQwMTkvOTI4LzEwIG54cmVhZCAxNDMz
>NzE0MDE5LzE0MzM3MTQwMTkvMzU1OSB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzE0MDE5LzE0
>MzM3MTQwMTkvMTAgZm9ya3Rvb211Y2ggMTQzMzcxNDAxOS8xNDMzNzE0MDE5LzE0MzM3MTQwMTkg
>YWxsb2MgMzkvMTAvNSBjcmVhdCAyMTI0LzIxMjQvMzkgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTQwNDUvODY2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQwNDUv
>OTU0LzE0IG54cmVhZCAxNDMzNzE0MDQ1LzE0MzM3MTQwNDUvMzU4NSB0cnlleGNlcHQgNC8yLzEg
>Zm9yayAxNDMzNzE0MDQ1LzE0MzM3MTQwNDUvMzYgZm9ya3Rvb211Y2ggMTQzMzcxNDA0NS8xNDMz
>NzE0MDQ1LzE0MzM3MTQwNDUgYWxsb2MgMjYvOS81IGNyZWF0IDIxNTAvMjE1MC8yNiBsb2NrIDUv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDA3MS83MzgvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxNDA3MS85ODAvNDAgbnhyZWFkIDE0MzM3MTQwNzEvMTQzMzcxNDA3MS8zNjEx
>IHRyeWV4Y2VwdCAxOC8yLzAgZm9yayAxNDMzNzE0MDcxLzE0MzM3MTQwNzEvNjIgZm9ya3Rvb211
>Y2ggMTQzMzcxNDA3MS8xNDMzNzE0MDcxLzE0MzM3MTQwNzEgYWxsb2MgMzEvMTIvMSBjcmVhdCAy
>MTc2LzkwMy84IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0
>MTAwLzc2Ny8wICh0ZXN0czogcmVhZCAxNDMzNzE0MTAwLzEwMDkvMTEgbnhyZWFkIDE0MzM3MTQx
>MDAvMTQzMzcxNDEwMC8zNjQwIHRyeWV4Y2VwdCAzNC8yLzEgZm9yayAxNDMzNzE0MTAwLzE0MzM3
>MTQxMDAvMjUgZm9ya3Rvb211Y2ggMTQzMzcxNDEwMC8xNDMzNzE0MTAwLzE0MzM3MTQxMDAgYWxs
>b2MgMzAvOC80IGNyZWF0IDIyMDUvOTMyLzM3IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE0MTIwLzE0MC8wICh0ZXN0czogcmVhZCAxNDMzNzE0MTIwLzEwMjkv
>MTEgbnhyZWFkIDE0MzM3MTQxMjAvMTQzMzcxNDEyMC8zNjYwIHRyeWV4Y2VwdCAxOC8yLzEgZm9y
>ayAxNDMzNzE0MTIwLzE0MzM3MTQxMjAvNDUgZm9ya3Rvb211Y2ggMTQzMzcxNDEyMC8xNDMzNzE0
>MTIwLzE0MzM3MTQxMjAgYWxsb2MgMzEvMjQvNiBjcmVhdCAyMjI1LzE0MC8xMSBsb2NrIDYvNi8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDE0OS8xNjkvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNDE0OS8xMDU4LzE1IG54cmVhZCAxNDMzNzE0MTQ5LzE0MzM3MTQxNDkvMzY4OSB0
>cnlleGNlcHQgMTQvMi8xIGZvcmsgMTQzMzcxNDE0OS8xNDMzNzE0MTQ5Lzc0IGZvcmt0b29tdWNo
>IDE0MzM3MTQxNDkvMTQzMzcxNDE0OS8xNDMzNzE0MTQ5IGFsbG9jIDQ5LzIwLzcgY3JlYXQgMjI1
>NC8xNjkvNDAgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQx
>NzkvNzYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDE3OS8xMDg4LzEgbnhyZWFkIDE0MzM3MTQxNzkv
>MTQzMzcxNDE3OS8zNzE5IHRyeWV4Y2VwdCA4LzEvMCBmb3JrIDE0MzM3MTQxNzkvMTQzMzcxNDE3
>OS8xMDQgZm9ya3Rvb211Y2ggMTQzMzcxNDE3OS8xNDMzNzE0MTc5LzE0MzM3MTQxNzkgYWxsb2Mg
>MjUvNy8xIGNyZWF0IDE2MC8xOS8xOSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxNDIxNy8xMTQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDIxNy8xMTI2LzE1IG54
>cmVhZCAxNDMzNzE0MjE3LzE0MzM3MTQyMTcvMzc1NyB0cnlleGNlcHQgOS8xLzAgZm9yayAxNDMz
>NzE0MjE3LzE0MzM3MTQyMTcvMTQyIGZvcmt0b29tdWNoIDE0MzM3MTQyMTcvMTQzMzcxNDIxNy8x
>NDMzNzE0MjE3IGFsbG9jIDM5LzkvMiBjcmVhdCAxOTgvNTcvNTcgbG9jayAxLzEvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQyNTMvMTQ0LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTQyNTMvMTE2Mi82IG54cmVhZCAxNDMzNzE0MjUzLzE0MzM3MTQyNTMvMzc5MyB0cnlleGNlcHQg
>Ni8yLzEgZm9yayAxNDMzNzE0MjUzLzE0MzM3MTQyNTMvMTc4IGZvcmt0b29tdWNoIDE0MzM3MTQy
>NTMvMTQzMzcxNDI1My8xNDMzNzE0MjUzIGFsbG9jIDM4LzEyLzYgY3JlYXQgMjM0LzkzLzkzIGxv
>Y2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0MzY5LzI2MC8wICh0
>ZXN0czogcmVhZCAxNDMzNzE0MzY5LzEyNzgvMTUgbnhyZWFkIDE0MzM3MTQzNjkvMTQzMzcxNDM2
>OS8zOTA5IHRyeWV4Y2VwdCAxMy8yLzEgZm9yayAxNDMzNzE0MzY5LzE0MzM3MTQzNjkvMjk0IGZv
>cmt0b29tdWNoIDE0MzM3MTQzNjkvMTQzMzcxNDM2OS8xNDMzNzE0MzY5IGFsbG9jIDQ3LzE1LzUg
>Y3JlYXQgMzUwLzIwOS8yMDkgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTQzOTAvMjgxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQzOTAvMTI5OS8zIG54cmVhZCAx
>NDMzNzE0MzkwLzE0MzM3MTQzOTAvMzkzMCB0cnlleGNlcHQgMzQvMi8wIGZvcmsgMTQzMzcxNDM5
>MC8xNDMzNzE0MzkwLzMxNSBmb3JrdG9vbXVjaCAxNDMzNzE0MzkwLzE0MzM3MTQzOTAvMTQzMzcx
>NDM5MCBhbGxvYyAyNi8zLzEgY3JlYXQgMzcxLzIzMC8yMzAgbG9jayAwLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ0MzEvMzIyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ0
>MzEvMTM0MC8yMCBueHJlYWQgMTQzMzcxNDQzMS8xNDMzNzE0NDMxLzM5NzEgdHJ5ZXhjZXB0IDQz
>LzIvMSBmb3JrIDE0MzM3MTQ0MzEvMTQzMzcxNDQzMS8zNTYgZm9ya3Rvb211Y2ggMTQzMzcxNDQz
>MS8xNDMzNzE0NDMxLzE0MzM3MTQ0MzEgYWxsb2MgNDQvMTAvNSBjcmVhdCA0MTIvMjcxLzI3MSBs
>b2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDQ1Ni8zNDcvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxNDQ1Ni8xMzY1LzEyIG54cmVhZCAxNDMzNzE0NDU2LzE0MzM3MTQ0
>NTYvMzk5NiB0cnlleGNlcHQgNDEvMi8wIGZvcmsgMTQzMzcxNDQ1Ni8xNDMzNzE0NDU2LzM4MSBm
>b3JrdG9vbXVjaCAxNDMzNzE0NDU2LzE0MzM3MTQ0NTYvMTQzMzcxNDQ1NiBhbGxvYyAzMC84LzEg
>Y3JlYXQgNDM3LzI5Ni8yOTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MTQ0NzYvMzY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ0NzYvMTM4NS81IG54cmVhZCAx
>NDMzNzE0NDc2LzE0MzM3MTQ0NzYvNDAxNiB0cnlleGNlcHQgMTYvMy8xIGZvcmsgMTQzMzcxNDQ3
>Ni8xNDMzNzE0NDc2LzQwMSBmb3JrdG9vbXVjaCAxNDMzNzE0NDc2LzE0MzM3MTQ0NzYvMTQzMzcx
>NDQ3NiBhbGxvYyAyOC85LzUgY3JlYXQgNDU3LzMxNi8zMTYgbG9jayA0LzQvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ1MTEvNDAyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ1
>MTEvMTQyMC8xOSBueHJlYWQgMTQzMzcxNDUxMS8xNDMzNzE0NTExLzQwNTEgdHJ5ZXhjZXB0IDIw
>LzEvMSBmb3JrIDE0MzM3MTQ1MTEvMTQzMzcxNDUxMS80MzYgZm9ya3Rvb211Y2ggMTQzMzcxNDUx
>MS8xNDMzNzE0NTExLzE0MzM3MTQ1MTEgYWxsb2MgNDQvOC8wIGNyZWF0IDQ5Mi8zNTEvMzUxIGxv
>Y2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0NTU0LzQ0NS8wICh0
>ZXN0czogcmVhZCAxNDMzNzE0NTU0LzE0NjMvMSBueHJlYWQgMTQzMzcxNDU1NC8xNDMzNzE0NTU0
>LzQwOTQgdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcxNDU1NC8xNDMzNzE0NTU0LzQ3OSBmb3Jr
>dG9vbXVjaCAxNDMzNzE0NTU0LzE0MzM3MTQ1NTQvMTQzMzcxNDU1NCBhbGxvYyA1Ni83LzEgY3Jl
>YXQgNTM1LzM5NC8zOTQgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQ1OTAvNDgxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ1OTAvMTQ5OS81IG54cmVhZCAxNDMz
>NzE0NTkwLzE0MzM3MTQ1OTAvNDEzMCB0cnlleGNlcHQgMTcvMS8xIGZvcmsgMTQzMzcxNDU5MC8x
>NDMzNzE0NTkwLzUxNSBmb3JrdG9vbXVjaCAxNDMzNzE0NTkwLzE0MzM3MTQ1OTAvMTQzMzcxNDU5
>MCBhbGxvYyAyNy8xNi8wIGNyZWF0IDU3MS80MzAvNDMwIGxvY2sgMy8zLzApCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzE0NjIyLzUxMy8wICh0ZXN0czogcmVhZCAxNDMzNzE0NjIy
>LzE1MzEvNiBueHJlYWQgMTQzMzcxNDYyMi8xNDMzNzE0NjIyLzQxNjIgdHJ5ZXhjZXB0IDE3LzMv
>MiBmb3JrIDE0MzM3MTQ2MjIvMTQzMzcxNDYyMi81NDcgZm9ya3Rvb211Y2ggMTQzMzcxNDYyMi8x
>NDMzNzE0NjIyLzE0MzM3MTQ2MjIgYWxsb2MgNDgvMTYvNiBjcmVhdCA2MDMvNDYyLzQ2MiBsb2Nr
>IDYvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDY0OS81NDAvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNDY0OS8xNTU4LzE0IG54cmVhZCAxNDMzNzE0NjQ5LzE0MzM3MTQ2NDkv
>NDE4OSB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE0NjQ5LzE0MzM3MTQ2NDkvNTc0IGZvcmt0
>b29tdWNoIDE0MzM3MTQ2NDkvMTQzMzcxNDY0OS8xNDMzNzE0NjQ5IGFsbG9jIDc1LzE0LzYgY3Jl
>YXQgNjMwLzQ4OS80ODkgbG9jayA2LzYvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTQ2NzgvNTY5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ2NzgvMTU4Ny8xIG54cmVhZCAxNDMz
>NzE0Njc4LzE0MzM3MTQ2NzgvNDIxOCB0cnlleGNlcHQgNS8zLzAgZm9yayAxNDMzNzE0Njc4LzE0
>MzM3MTQ2NzgvNjAzIGZvcmt0b29tdWNoIDE0MzM3MTQ2NzgvMTQzMzcxNDY3OC8xNDMzNzE0Njc4
>IGFsbG9jIDE4LzEvMSBjcmVhdCA2NTkvNTE4LzUxOCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDc2Ny82NTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDc2Ny8x
>NDY4LzEgbnhyZWFkIDE0MzM3MTQ3NjcvMTQzMzcxNDc2Ny80MzA3IHRyeWV4Y2VwdCA0LzIvMCBm
>b3JrIDE0MzM3MTQ3NjcvMTQzMzcxNDc2Ny82OTIgZm9ya3Rvb211Y2ggMTQzMzcxNDc2Ny8xNDMz
>NzE0NzY3LzE0MzM3MTQ3NjcgYWxsb2MgNDQvMy8xIGNyZWF0IDc0OC82MDcvNjA3IGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE0ODA2LzY5Ny8wICh0ZXN0czog
>cmVhZCAxNDMzNzE0ODA2LzE1MDcvMjggbnhyZWFkIDE0MzM3MTQ4MDYvMTQzMzcxNDgwNi80MzQ2
>IHRyeWV4Y2VwdCAzNC8xLzEgZm9yayAxNDMzNzE0ODA2LzE0MzM3MTQ4MDYvNzMxIGZvcmt0b29t
>dWNoIDE0MzM3MTQ4MDYvMTQzMzcxNDgwNi8xNDMzNzE0ODA2IGFsbG9jIDQyLzEzLzQgY3JlYXQg
>Nzg3LzY0Ni82NDYgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTQ4MjcvNjY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ4MjcvMTQ5NC8xNSBueHJlYWQgMTQzMzcx
>NDgyNy8xNDMzNzE0ODI3LzQzNjcgdHJ5ZXhjZXB0IDQzLzMvMSBmb3JrIDE0MzM3MTQ4MjcvMTQz
>MzcxNDgyNy83NTIgZm9ya3Rvb211Y2ggMTQzMzcxNDgyNy8xNDMzNzE0ODI3LzE0MzM3MTQ4Mjcg
>YWxsb2MgNDkvMTEvNCBjcmVhdCA4MDgvNjY3LzY2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNDg1My82OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDg1My8x
>NTIwLzEzIG54cmVhZCAxNDMzNzE0ODUzLzE0MzM3MTQ4NTMvNDM5MyB0cnlleGNlcHQgMzUvMi8w
>IGZvcmsgMTQzMzcxNDg1My8xNDMzNzE0ODUzLzc3OCBmb3JrdG9vbXVjaCAxNDMzNzE0ODUzLzE0
>MzM3MTQ4NTMvMTQzMzcxNDg1MyBhbGxvYyA3NS81LzEgY3JlYXQgODM0LzY5My82OTMgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTQ4OTUvNzM1LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTQ4OTUvMTU2Mi8xNSBueHJlYWQgMTQzMzcxNDg5NS8xNDMzNzE0ODk1LzQ0
>MzUgdHJ5ZXhjZXB0IDM4LzIvMSBmb3JrIDE0MzM3MTQ4OTUvMTQzMzcxNDg5NS84MjAgZm9ya3Rv
>b211Y2ggMTQzMzcxNDg5NS8xNDMzNzE0ODk1LzE0MzM3MTQ4OTUgYWxsb2MgNDMvMTUvNCBjcmVh
>dCA4NzYvNzM1LzczNSBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNDkzNy83NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNDkzNy8xNjA0LzEgbnhyZWFkIDE0MzM3
>MTQ5MzcvMTQzMzcxNDkzNy80NDc3IHRyeWV4Y2VwdCA1NC8zLzAgZm9yayAxNDMzNzE0OTM3LzE0
>MzM3MTQ5MzcvODYyIGZvcmt0b29tdWNoIDE0MzM3MTQ5MzcvMTQzMzcxNDkzNy8xNDMzNzE0OTM3
>IGFsbG9jIDQ2LzEwLzEgY3JlYXQgOTE4Lzc3Ny83NzcgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTQ5NzYvODE2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTQ5NzYv
>MTY0My82IG54cmVhZCAxNDMzNzE0OTc2LzE0MzM3MTQ5NzYvNDUxNiB0cnlleGNlcHQgNS8yLzEg
>Zm9yayAxNDMzNzE0OTc2LzE0MzM3MTQ5NzYvOTAxIGZvcmt0b29tdWNoIDE0MzM3MTQ5NzYvMTQz
>MzcxNDk3Ni8xNDMzNzE0OTc2IGFsbG9jIDg1LzIxLzAgY3JlYXQgOTU3LzgxNi84MTYgbG9jayA1
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTUwMDAvODQwLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTUwMDAvMTY2Ny81IG54cmVhZCAxNDMzNzE1MDAwLzE0MzM3MTUwMDAvNDU0
>MCB0cnlleGNlcHQgMjAvMi8xIGZvcmsgMTQzMzcxNTAwMC8xNDMzNzE1MDAwLzkyNSBmb3JrdG9v
>bXVjaCAxNDMzNzE1MDAwLzE0MzM3MTUwMDAvMTQzMzcxNTAwMCBhbGxvYyA0MS85LzAgY3JlYXQg
>OTgxLzg0MC84NDAgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTUwMjcvODY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUwMjcvMTY5NC8xIG54cmVhZCAxNDMzNzE1
>MDI3LzE0MzM3MTUwMjcvNDU2NyB0cnlleGNlcHQgNDUvMC8wIGZvcmsgMTQzMzcxNTAyNy8xNDMz
>NzE1MDI3Lzk1MiBmb3JrdG9vbXVjaCAxNDMzNzE1MDI3LzE0MzM3MTUwMjcvMTQzMzcxNTAyNyBh
>bGxvYyA0Ni8xMC8xIGNyZWF0IDEwMDgvODY3Lzg2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTA1Mi84OTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTA1Mi8x
>NzE5LzUgbnhyZWFkIDE0MzM3MTUwNTIvMTQzMzcxNTA1Mi80NTkyIHRyeWV4Y2VwdCAzLzIvMCBm
>b3JrIDE0MzM3MTUwNTIvMTQzMzcxNTA1Mi85NzcgZm9ya3Rvb211Y2ggMTQzMzcxNTA1Mi8xNDMz
>NzE1MDUyLzE0MzM3MTUwNTIgYWxsb2MgMjIvMS8xIGNyZWF0IDEwMzMvODkyLzg5MiBsb2NrIDEv
>MS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTA4NS85MjUvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxNTA4NS8xNzUyLzIgbnhyZWFkIDE0MzM3MTUwODUvMTQzMzcxNTA4NS80NjI1
>IHRyeWV4Y2VwdCAxMC8xLzEgZm9yayAxNDMzNzE1MDg1LzE0MzM3MTUwODUvMTAxMCBmb3JrdG9v
>bXVjaCAxNDMzNzE1MDg1LzE0MzM3MTUwODUvMTQzMzcxNTA4NSBhbGxvYyA0My8xMS8yIGNyZWF0
>IDEwNjYvOTI1LzkyNSBsb2NrIDIvMi8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNTEyNy85NjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTEyNy8xNzk0LzM4IG54cmVhZCAxNDMz
>NzE1MTI3LzE0MzM3MTUxMjcvNDY2NyB0cnlleGNlcHQgNTIvNC8wIGZvcmsgMTQzMzcxNTEyNy8x
>NDMzNzE1MTI3LzEwNTIgZm9ya3Rvb211Y2ggMTQzMzcxNTEyNy8xNDMzNzE1MTI3LzE0MzM3MTUx
>MjcgYWxsb2MgMjcvOC8zIGNyZWF0IDExMDgvOTY3Lzk2NyBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTE2Ny8xMDA3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUx
>NjcvMTgzNC8xMSBueHJlYWQgMTQzMzcxNTE2Ny8xNDMzNzE1MTY3LzQ3MDcgdHJ5ZXhjZXB0IDU2
>LzUvMSBmb3JrIDE0MzM3MTUxNjcvMTQzMzcxNTE2Ny8xMDkyIGZvcmt0b29tdWNoIDE0MzM3MTUx
>NjcvMTQzMzcxNTE2Ny8xNDMzNzE1MTY3IGFsbG9jIDU5LzEzLzQgY3JlYXQgMTE0OC8xMDA3LzEw
>MDcgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTUyMzYvMTA3
>Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE1MjM2LzE5MDMvMyBueHJlYWQgMTQzMzcxNTIzNi8xNDMz
>NzE1MjM2LzQ3NzYgdHJ5ZXhjZXB0IDUwLzIvMSBmb3JrIDE0MzM3MTUyMzYvMTQzMzcxNTIzNi8x
>NyBmb3JrdG9vbXVjaCAxNDMzNzE1MjM2LzE0MzM3MTUyMzYvMTQzMzcxNTIzNiBhbGxvYyA1Mi85
>LzMgY3JlYXQgMTIxNy8xMDc2LzEwNzYgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTUyNTgvMTA5OC8wICh0ZXN0czogcmVhZCAxNDMzNzE1MjU4LzE5MjUvOCBu
>eHJlYWQgMTQzMzcxNTI1OC8xNDMzNzE1MjU4LzQ3OTggdHJ5ZXhjZXB0IDMwLzMvMCBmb3JrIDE0
>MzM3MTUyNTgvMTQzMzcxNTI1OC8yMSBmb3JrdG9vbXVjaCAxNDMzNzE1MjU4LzE0MzM3MTUyNTgv
>MTQzMzcxNTI1OCBhbGxvYyA0OS8xMi8yIGNyZWF0IDEyMzkvMTA5OC8xMDk4IGxvY2sgMS8xLzEp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1Mjk2LzExMzYvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNTI5Ni8xOTYzLzEyIG54cmVhZCAxNDMzNzE1Mjk2LzE0MzM3MTUyOTYvNDgzNiB0
>cnlleGNlcHQgNi8yLzIgZm9yayAxNDMzNzE1Mjk2LzE0MzM3MTUyOTYvNTkgZm9ya3Rvb211Y2gg
>MTQzMzcxNTI5Ni8xNDMzNzE1Mjk2LzE0MzM3MTUyOTYgYWxsb2MgNDYvNy83IGNyZWF0IDEyNzcv
>MTEzNi8xMTM2IGxvY2sgNy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1
>MzI2LzExNjYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTMyNi8xOTkzLzE5IG54cmVhZCAxNDMzNzE1
>MzI2LzE0MzM3MTUzMjYvNDg2NiB0cnlleGNlcHQgNy8yLzEgZm9yayAxNDMzNzE1MzI2LzE0MzM3
>MTUzMjYvODkgZm9ya3Rvb211Y2ggMTQzMzcxNTMyNi8xNDMzNzE1MzI2LzE0MzM3MTUzMjYgYWxs
>b2MgMzcvMTAvNiBjcmVhdCAxMzA3LzExNjYvMTE2NiBsb2NrIDYvNi8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTM0OS8xMTg5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTUzNDkv
>MjAxNi8yMyBueHJlYWQgMTQzMzcxNTM0OS8xNDMzNzE1MzQ5LzQ4ODkgdHJ5ZXhjZXB0IDMwLzEv
>MSBmb3JrIDE0MzM3MTUzNDkvMTQzMzcxNTM0OS8xMTIgZm9ya3Rvb211Y2ggMTQzMzcxNTM0OS8x
>NDMzNzE1MzQ5LzE0MzM3MTUzNDkgYWxsb2MgMjkvMTAvNSBjcmVhdCAxMzMwLzExODkvMTE4OSBs
>b2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTM4NS8xMjI1LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTUzODUvMjA1Mi83IG54cmVhZCAxNDMzNzE1Mzg1LzE0MzM3MTUz
>ODUvNDkyNSB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzE1Mzg1LzE0MzM3MTUzODUvMTQ4IGZv
>cmt0b29tdWNoIDE0MzM3MTUzODUvMTQzMzcxNTM4NS8xNDMzNzE1Mzg1IGFsbG9jIDM2LzcvNyBj
>cmVhdCAxMzY2LzEyMjUvMTIyNSBsb2NrIDcvNy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxNTQxMS8xMjUxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTU0MTEvMjA3OC8xIG54cmVh
>ZCAxNDMzNzE1NDExLzE0MzM3MTU0MTEvNDk1MSB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE1
>NDExLzE0MzM3MTU0MTEvMTc0IGZvcmt0b29tdWNoIDE0MzM3MTU0MTEvMTQzMzcxNTQxMS8xNDMz
>NzE1NDExIGFsbG9jIDM4LzkvMSBjcmVhdCAxMzkyLzEyNTEvMTI1MSBsb2NrIDEvMS8xKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTQ0Ni8xMjg2LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTU0NDYvMjExMy8xIG54cmVhZCAxNDMzNzE1NDQ2LzE0MzM3MTU0NDYvNDk4NiB0cnlleGNl
>cHQgNC8wLzAgZm9yayAxNDMzNzE1NDQ2LzE0MzM3MTU0NDYvMjA5IGZvcmt0b29tdWNoIDE0MzM3
>MTU0NDYvMTQzMzcxNTQ0Ni8xNDMzNzE1NDQ2IGFsbG9jIDM2LzE1LzEgY3JlYXQgMTQyNy8xMjg2
>LzEyODYgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTU0NzAv
>MTMxMC8wICh0ZXN0czogcmVhZCAxNDMzNzE1NDcwLzIxMzcvNCBueHJlYWQgMTQzMzcxNTQ3MC8x
>NDMzNzE1NDcwLzUwMTAgdHJ5ZXhjZXB0IDIxLzIvMSBmb3JrIDE0MzM3MTU0NzAvMTQzMzcxNTQ3
>MC8yMzMgZm9ya3Rvb211Y2ggMTQzMzcxNTQ3MC8xNDMzNzE1NDcwLzE0MzM3MTU0NzAgYWxsb2Mg
>MjUvNy8wIGNyZWF0IDE0NTEvMTMxMC8xMzEwIGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE1NDk4LzEzMzgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTQ5OC8yMTY1
>LzIzIG54cmVhZCAxNDMzNzE1NDk4LzE0MzM3MTU0OTgvNTAzOCB0cnlleGNlcHQgMjQvMi8xIGZv
>cmsgMTQzMzcxNTQ5OC8xNDMzNzE1NDk4LzI2MSBmb3JrdG9vbXVjaCAxNDMzNzE1NDk4LzE0MzM3
>MTU0OTgvMTQzMzcxNTQ5OCBhbGxvYyAzNS8xNi80IGNyZWF0IDE0NzkvMTMzOC8xMzM4IGxvY2sg
>NC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NTM0LzEzNzQvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNTUzNC8yMjAxLzEgbnhyZWFkIDE0MzM3MTU1MzQvMTQzMzcxNTUzNC81
>MDc0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTU1MzQvMTQzMzcxNTUzNC8yOTcgZm9ya3Rv
>b211Y2ggMTQzMzcxNTUzNC8xNDMzNzE1NTM0LzE0MzM3MTU1MzQgYWxsb2MgNTIvNi8xIGNyZWF0
>IDE1MTUvMTM3NC8xMzc0IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE1NTU2LzEzOTYvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTU1Ni8yMjIzLzEwIG54cmVhZCAx
>NDMzNzE1NTU2LzE0MzM3MTU1NTYvNTA5NiB0cnlleGNlcHQgMjAvMS8wIGZvcmsgMTQzMzcxNTU1
>Ni8xNDMzNzE1NTU2LzMxOSBmb3JrdG9vbXVjaCAxNDMzNzE1NTU2LzE0MzM3MTU1NTYvMTQzMzcx
>NTU1NiBhbGxvYyAyOC8xMC8yIGNyZWF0IDE1MzcvMTM5Ni8xMzk2IGxvY2sgMi8yLzIpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NTgwLzE0MjAvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNTU4MC8yMjQ3LzkgbnhyZWFkIDE0MzM3MTU1ODAvMTQzMzcxNTU4MC8xIHRyeWV4Y2VwdCAx
>NC8yLzAgZm9yayAxNDMzNzE1NTgwLzE0MzM3MTU1ODAvMzQzIGZvcmt0b29tdWNoIDE0MzM3MTU1
>ODAvMTQzMzcxNTU4MC8xNDMzNzE1NTgwIGFsbG9jIDI2LzkvMSBjcmVhdCAxNTYxLzE0MjAvMTQy
>MCBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTY0MC8xNDgw
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTU2NDAvMjMwNy8yIG54cmVhZCAxNDMzNzE1NjQwLzE0MzM3
>MTU2NDAvNjEgdHJ5ZXhjZXB0IDYvMy8wIGZvcmsgMTQzMzcxNTY0MC8xNDMzNzE1NjQwLzQwMyBm
>b3JrdG9vbXVjaCAxNDMzNzE1NjQwLzE0MzM3MTU2NDAvMTQzMzcxNTY0MCBhbGxvYyAyMi8xMC8y
>IGNyZWF0IDE2MjEvMTQ4MC8xNDgwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzE1NjgwLzE1MjAvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTY4MC8yMzQ3LzEzIG54
>cmVhZCAxNDMzNzE1NjgwLzE0MzM3MTU2ODAvMTAxIHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3
>MTU2ODAvMTQzMzcxNTY4MC80NDMgZm9ya3Rvb211Y2ggMTQzMzcxNTY4MC8xNDMzNzE1NjgwLzE0
>MzM3MTU2ODAgYWxsb2MgMjYvNy8yIGNyZWF0IDE2NjEvMTUyMC8xNTIwIGxvY2sgMi8yLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1NzQ0LzE1ODQvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNTc0NC8yNDExLzEyIG54cmVhZCAxNDMzNzE1NzQ0LzE0MzM3MTU3NDQvMTY1IHRyeWV4
>Y2VwdCA2LzMvMCBmb3JrIDE0MzM3MTU3NDQvMTQzMzcxNTc0NC81MDcgZm9ya3Rvb211Y2ggMTQz
>MzcxNTc0NC8xNDMzNzE1NzQ0LzE0MzM3MTU3NDQgYWxsb2MgMjgvNy81IGNyZWF0IDE3MjUvMTU4
>NC8xNTg0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1Nzk5
>LzE2MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTc5OS8yNDY2LzM3IG54cmVhZCAxNDMzNzE1Nzk5
>LzE0MzM3MTU3OTkvMjIwIHRyeWV4Y2VwdCAzMC8yLzEgZm9yayAxNDMzNzE1Nzk5LzE0MzM3MTU3
>OTkvNTYyIGZvcmt0b29tdWNoIDE0MzM3MTU3OTkvMTQzMzcxNTc5OS8xNDMzNzE1Nzk5IGFsbG9j
>IDUyLzIwLzAgY3JlYXQgMTc4MC8xNjM5LzE2MzkgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTU4MzAvMTY3MC8wICh0ZXN0czogcmVhZCAxNDMzNzE1ODMwLzI0
>OTcvNSBueHJlYWQgMTQzMzcxNTgzMC8xNDMzNzE1ODMwLzI1MSB0cnlleGNlcHQgNS8yLzAgZm9y
>ayAxNDMzNzE1ODMwLzE0MzM3MTU4MzAvNTkzIGZvcmt0b29tdWNoIDE0MzM3MTU4MzAvMTQzMzcx
>NTgzMC8xNDMzNzE1ODMwIGFsbG9jIDQxLzExLzEgY3JlYXQgMTgxMS8xNjcwLzE2NzAgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTU4ODMvMTcyMy8wICh0ZXN0
>czogcmVhZCAxNDMzNzE1ODgzLzI1NTAvMTEgbnhyZWFkIDE0MzM3MTU4ODMvMTQzMzcxNTg4My8z
>MDQgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQzMzcxNTg4My8xNDMzNzE1ODgzLzY0NiBmb3JrdG9v
>bXVjaCAxNDMzNzE1ODgzLzE0MzM3MTU4ODMvMTQzMzcxNTg4MyBhbGxvYyA0Mi8xNy82IGNyZWF0
>IDE4NjQvMTcyMy8xNzIzIGxvY2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE1OTEzLzE3NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTkxMy8yNTgwLzEwIG54cmVhZCAx
>NDMzNzE1OTEzLzE0MzM3MTU5MTMvMzM0IHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0MzM3MTU5MTMv
>MTQzMzcxNTkxMy82NzYgZm9ya3Rvb211Y2ggMTQzMzcxNTkxMy8xNDMzNzE1OTEzLzE0MzM3MTU5
>MTMgYWxsb2MgMjAvMTAvNyBjcmVhdCAxODk0LzE3NTMvMTc1MyBsb2NrIDYvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNTkzNy8xNzc3LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTU5MzcvMjYwNC8yNCBueHJlYWQgMTQzMzcxNTkzNy8xNDMzNzE1OTM3LzM1OCB0cnlleGNlcHQg
>MTAvMi8xIGZvcmsgMTQzMzcxNTkzNy8xNDMzNzE1OTM3LzcwMCBmb3JrdG9vbXVjaCAxNDMzNzE1
>OTM3LzE0MzM3MTU5MzcvMTQzMzcxNTkzNyBhbGxvYyAzOS8yNC85IGNyZWF0IDE5MTgvMTc3Ny8x
>Nzc3IGxvY2sgOS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE1OTYzLzE4
>MDMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNTk2My8yNjMwLzEyIG54cmVhZCAxNDMzNzE1OTYzLzE0
>MzM3MTU5NjMvMzg0IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MTU5NjMvMTQzMzcxNTk2My83
>MjYgZm9ya3Rvb211Y2ggMTQzMzcxNTk2My8xNDMzNzE1OTYzLzE0MzM3MTU5NjMgYWxsb2MgNjAv
>MTgvMyBjcmVhdCAxOTQ0LzE4MDMvMTgwMyBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxNTk5Ny8xODM3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTU5OTcvMjY2NC8x
>IG54cmVhZCAxNDMzNzE1OTk3LzE0MzM3MTU5OTcvNDE4IHRyeWV4Y2VwdCAzNS8yLzAgZm9yayAx
>NDMzNzE1OTk3LzE0MzM3MTU5OTcvNzYwIGZvcmt0b29tdWNoIDE0MzM3MTU5OTcvMTQzMzcxNTk5
>Ny8xNDMzNzE1OTk3IGFsbG9jIDM0LzEwLzEgY3JlYXQgMTk3OC8xODM3LzE4MzcgbG9jayAxLzEv
>MSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYwMjcvMTg2Ny8wICh0ZXN0czog
>cmVhZCAxNDMzNzE2MDI3LzI2OTQvNyBueHJlYWQgMTQzMzcxNjAyNy8xNDMzNzE2MDI3LzQ0OCB0
>cnlleGNlcHQgOC8yLzAgZm9yayAxNDMzNzE2MDI3LzE0MzM3MTYwMjcvNzkwIGZvcmt0b29tdWNo
>IDE0MzM3MTYwMjcvMTQzMzcxNjAyNy8xNDMzNzE2MDI3IGFsbG9jIDQ1LzEyLzEgY3JlYXQgMjAw
>OC8xODY3LzE4NjcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTYwNTYvMTg5Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE2MDU2LzI3MjMvNSBueHJlYWQgMTQzMzcx
>NjA1Ni8xNDMzNzE2MDU2LzQ3NyB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzE2MDU2LzE0MzM3
>MTYwNTYvODE5IGZvcmt0b29tdWNoIDE0MzM3MTYwNTYvMTQzMzcxNjA1Ni8xNDMzNzE2MDU2IGFs
>bG9jIDUxLzEwLzUgY3JlYXQgMjAzNy8xODk2LzE4OTYgbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTYwODkvMTkyOS8wICh0ZXN0czogcmVhZCAxNDMzNzE2MDg5
>LzI3NTYvMjcgbnhyZWFkIDE0MzM3MTYwODkvMTQzMzcxNjA4OS81MTAgdHJ5ZXhjZXB0IDE5LzEv
>MSBmb3JrIDE0MzM3MTYwODkvMTQzMzcxNjA4OS84NTIgZm9ya3Rvb211Y2ggMTQzMzcxNjA4OS8x
>NDMzNzE2MDg5LzE0MzM3MTYwODkgYWxsb2MgNDMvMTgvMCBjcmVhdCAyMDcwLzE5MjkvMTkyOSBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjEwOS8xOTQ5LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTYxMDkvMjc3Ni80NyBueHJlYWQgMTQzMzcxNjEwOS8xNDMzNzE2
>MTA5LzUzMCB0cnlleGNlcHQgMzkvMC8wIGZvcmsgMTQzMzcxNjEwOS8xNDMzNzE2MTA5Lzg3MiBm
>b3JrdG9vbXVjaCAxNDMzNzE2MTA5LzE0MzM3MTYxMDkvMTQzMzcxNjEwOSBhbGxvYyAyMC8xMy8y
>IGNyZWF0IDIwOTAvMTk0OS8xOTQ5IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzE2MTMyLzE5NzIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjEzMi8yNzk5LzEgbnhy
>ZWFkIDE0MzM3MTYxMzIvMTQzMzcxNjEzMi81NTMgdHJ5ZXhjZXB0IDMvMi8wIGZvcmsgMTQzMzcx
>NjEzMi8xNDMzNzE2MTMyLzg5NSBmb3JrdG9vbXVjaCAxNDMzNzE2MTMyLzE0MzM3MTYxMzIvMTQz
>MzcxNjEzMiBhbGxvYyAyMC82LzEgY3JlYXQgMjExMy8xOTcyLzE5NzIgbG9jayAxLzEvMSkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYxNjEvMjAwMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzE2MTYxLzI4MjgvOSBueHJlYWQgMTQzMzcxNjE2MS8xNDMzNzE2MTYxLzU4MiB0cnlleGNl
>cHQgNS8yLzEgZm9yayAxNDMzNzE2MTYxLzE0MzM3MTYxNjEvOTI0IGZvcmt0b29tdWNoIDE0MzM3
>MTYxNjEvMTQzMzcxNjE2MS8xNDMzNzE2MTYxIGFsbG9jIDM1LzE0LzYgY3JlYXQgMjE0Mi8yMDAx
>LzIwMDEgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTYxODcv
>MjAyNy8wICh0ZXN0czogcmVhZCAxNDMzNzE2MTg3LzI4NTQvNSBueHJlYWQgMTQzMzcxNjE4Ny8x
>NDMzNzE2MTg3LzYwOCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE2MTg3LzE0MzM3MTYxODcv
>OTUwIGZvcmt0b29tdWNoIDE0MzM3MTYxODcvMTQzMzcxNjE4Ny8xNDMzNzE2MTg3IGFsbG9jIDQ1
>LzEvMSBjcmVhdCAyMTY4LzIwMjcvMjAyNyBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxNjIyMS8yMDYxLzAgKHRlc3RzOiByZWFkIDE0MzM3MTYyMjEvMjg4OC8z
>IG54cmVhZCAxNDMzNzE2MjIxLzE0MzM3MTYyMjEvNjQyIHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0
>MzM3MTYyMjEvMTQzMzcxNjIyMS85ODQgZm9ya3Rvb211Y2ggMTQzMzcxNjIyMS8xNDMzNzE2MjIx
>LzE0MzM3MTYyMjEgYWxsb2MgNzkvOS8zIGNyZWF0IDIyMDIvMjA2MS8yMDYxIGxvY2sgMy8zLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2MjQ1LzIwODUvMCAodGVzdHM6IHJl
>YWQgMTQzMzcxNjI0NS8yOTEyLzEgbnhyZWFkIDE0MzM3MTYyNDUvMTQzMzcxNjI0NS82NjYgdHJ5
>ZXhjZXB0IDI1LzIvMCBmb3JrIDE0MzM3MTYyNDUvMTQzMzcxNjI0NS8xMDA4IGZvcmt0b29tdWNo
>IDE0MzM3MTYyNDUvMTQzMzcxNjI0NS8xNDMzNzE2MjQ1IGFsbG9jIDUzLzE0LzEgY3JlYXQgMjIy
>Ni8yMDg1LzIwODUgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTYyODMvMjEyMy8wICh0ZXN0czogcmVhZCAxNDMzNzE2MjgzLzI5NTAvMjIgbnhyZWFkIDE0MzM3
>MTYyODMvMTQzMzcxNjI4My83MDQgdHJ5ZXhjZXB0IDQ5LzMvMCBmb3JrIDE0MzM3MTYyODMvMTQz
>MzcxNjI4My8xMDQ2IGZvcmt0b29tdWNoIDE0MzM3MTYyODMvMTQzMzcxNjI4My8xNDMzNzE2Mjgz
>IGFsbG9jIDMxLzkvMSBjcmVhdCAyMjY0LzIxMjMvMjEyMyBsb2NrIDEvMS8xKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjMxMi8yMTUyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTYz
>MTIvMjk3OS81MSBueHJlYWQgMTQzMzcxNjMxMi8xNDMzNzE2MzEyLzczMyB0cnlleGNlcHQgMjMv
>MS8xIGZvcmsgMTQzMzcxNjMxMi8xNDMzNzE2MzEyLzEyIGZvcmt0b29tdWNoIDE0MzM3MTYzMTIv
>MTQzMzcxNjMxMi8xNDMzNzE2MzEyIGFsbG9jIDM4LzkvNCBjcmVhdCAyMjkzLzIxNTIvMjE1MiBs
>b2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjM0MS8yMTgxLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTYzNDEvMzAwOC81IG54cmVhZCAxNDMzNzE2MzQxLzE0MzM3MTYz
>NDEvNzYyIHRyeWV4Y2VwdCA0LzIvMiBmb3JrIDE0MzM3MTYzNDEvMTQzMzcxNjM0MS8yNyBmb3Jr
>dG9vbXVjaCAxNDMzNzE2MzQxLzE0MzM3MTYzNDEvMTQzMzcxNjM0MSBhbGxvYyA0Mi8xMS81IGNy
>ZWF0IDIzMjIvMjE4MS8xMSBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcxNjM3Ni8yMjE2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTYzNzYvMzA0My8yNCBueHJlYWQg
>MTQzMzcxNjM3Ni8xNDMzNzE2Mzc2Lzc5NyB0cnlleGNlcHQgNS8yLzIgZm9yayAxNDMzNzE2Mzc2
>LzE0MzM3MTYzNzYvNjIgZm9ya3Rvb211Y2ggMTQzMzcxNjM3Ni8xNDMzNzE2Mzc2LzE0MzM3MTYz
>NzYgYWxsb2MgNzcvMTEvNiBjcmVhdCAyMzU3LzIyMTYvNDYgbG9jayA1LzUvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY0MDYvMjI0Ni8wICh0ZXN0czogcmVhZCAxNDMzNzE2
>NDA2LzMwNzMvNSBueHJlYWQgMTQzMzcxNjQwNi8xNDMzNzE2NDA2LzgyNyB0cnlleGNlcHQgNC8y
>LzIgZm9yayAxNDMzNzE2NDA2LzE0MzM3MTY0MDYvOTIgZm9ya3Rvb211Y2ggMTQzMzcxNjQwNi8x
>NDMzNzE2NDA2LzE0MzM3MTY0MDYgYWxsb2MgMTA3LzEwLzUgY3JlYXQgMjM4Ny8yMjQ2Lzc2IGxv
>Y2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NDI5LzIyNjkvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxNjQyOS8zMDk2LzIgbnhyZWFkIDE0MzM3MTY0MjkvMTQzMzcxNjQy
>OS84NTAgdHJ5ZXhjZXB0IDIvMi8xIGZvcmsgMTQzMzcxNjQyOS8xNDMzNzE2NDI5LzExNSBmb3Jr
>dG9vbXVjaCAxNDMzNzE2NDI5LzE0MzM3MTY0MjkvMTQzMzcxNjQyOSBhbGxvYyA0MS83LzIgY3Jl
>YXQgMjQxMC8yMjY5Lzk5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE2NDczLzIzMTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjQ3My8zMTQwLzM1IG54cmVhZCAx
>NDMzNzE2NDczLzE0MzM3MTY0NzMvODk0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTY0NzMv
>MTQzMzcxNjQ3My8xNTkgZm9ya3Rvb211Y2ggMTQzMzcxNjQ3My8xNDMzNzE2NDczLzE0MzM3MTY0
>NzMgYWxsb2MgNzcvMTIvMSBjcmVhdCAyNDU0LzIzMTMvMTQzIGxvY2sgMS8xLzEpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NTAwLzIzNDAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>NjUwMC8zMTY3LzQgbnhyZWFkIDE0MzM3MTY1MDAvMTQzMzcxNjUwMC85MjEgdHJ5ZXhjZXB0IDcv
>NS8xIGZvcmsgMTQzMzcxNjUwMC8xNDMzNzE2NTAwLzE4NiBmb3JrdG9vbXVjaCAxNDMzNzE2NTAw
>LzE0MzM3MTY1MDAvMTQzMzcxNjUwMCBhbGxvYyAyMy82LzAgY3JlYXQgMjQ4MS8yMzQwLzE3MCBs
>b2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjUyNi8yMzY2LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MTY1MjYvMTc2OC8xIG54cmVhZCAxNDMzNzE2NTI2LzE0MzM3MTY1
>MjYvOTQ3IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAxNDMzNzE2NTI2LzE0MzM3MTY1MjYvMjEyIGZv
>cmt0b29tdWNoIDE0MzM3MTY1MjYvMTQzMzcxNjUyNi8xNDMzNzE2NTI2IGFsbG9jIDMyLzIxLzEg
>Y3JlYXQgMjUwNy8yMzY2LzE5NiBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxNjU2OS8yNDA5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY1NjkvMTgxMS8xOCBueHJl
>YWQgMTQzMzcxNjU2OS8xNDMzNzE2NTY5Lzk5MCB0cnlleGNlcHQgMTkvMTAvMSBmb3JrIDE0MzM3
>MTY1NjkvMTQzMzcxNjU2OS8yNTUgZm9ya3Rvb211Y2ggMTQzMzcxNjU2OS8xNDMzNzE2NTY5LzE0
>MzM3MTY1NjkgYWxsb2MgMzQvMTYvNCBjcmVhdCAyNTUwLzI0MDkvMjM5IGxvY2sgNC80LzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NTkwLzI0MzAvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNjU5MC8xODMyLzIwIG54cmVhZCAxNDMzNzE2NTkwLzE0MzM3MTY1OTAvMTAxMSB0cnll
>eGNlcHQgNDAvNC8xIGZvcmsgMTQzMzcxNjU5MC8xNDMzNzE2NTkwLzI3NiBmb3JrdG9vbXVjaCAx
>NDMzNzE2NTkwLzE0MzM3MTY1OTAvMTQzMzcxNjU5MCBhbGxvYyA0NS8yMC8zIGNyZWF0IDI1NzEv
>MjQzMC8yNjAgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY2
>MDgvMjQ0OC8wICh0ZXN0czogcmVhZCAxNDMzNzE2NjA4LzE4NTAvMTggbnhyZWFkIDE0MzM3MTY2
>MDgvMTQzMzcxNjYwOC8xMDI5IHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzE2NjA4LzE0MzM3
>MTY2MDgvMjk0IGZvcmt0b29tdWNoIDE0MzM3MTY2MDgvMTQzMzcxNjYwOC8xNDMzNzE2NjA4IGFs
>bG9jIDUwLzE3LzUgY3JlYXQgMjU4OS8yNDQ4LzI3OCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjYzOC8yNDc4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY2Mzgv
>MTg4MC82IG54cmVhZCAxNDMzNzE2NjM4LzE0MzM3MTY2MzgvMTA1OSB0cnlleGNlcHQgMy8yLzAg
>Zm9yayAxNDMzNzE2NjM4LzE0MzM3MTY2MzgvMzI0IGZvcmt0b29tdWNoIDE0MzM3MTY2MzgvMTQz
>MzcxNjYzOC8xNDMzNzE2NjM4IGFsbG9jIDQ3LzYvMSBjcmVhdCAyNjE5LzI0NzgvMzA4IGxvY2sg
>MC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2Njc2LzI1MTYvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxNjY3Ni8xOTE4LzkgbnhyZWFkIDE0MzM3MTY2NzYvMTQzMzcxNjY3Ni8x
>MDk3IHRyeWV4Y2VwdCAyLzEvMSBmb3JrIDE0MzM3MTY2NzYvMTQzMzcxNjY3Ni8zNjIgZm9ya3Rv
>b211Y2ggMTQzMzcxNjY3Ni8xNDMzNzE2Njc2LzE0MzM3MTY2NzYgYWxsb2MgMjkvMi8yIGNyZWF0
>IDI2NTcvMjUxNi8zNDYgbG9jayAyLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTY3MDMvMjU0My8wICh0ZXN0czogcmVhZCAxNDMzNzE2NzAzLzE5NDUvMjEgbnhyZWFkIDE0
>MzM3MTY3MDMvMTQzMzcxNjcwMy8xMTI0IHRyeWV4Y2VwdCAzLzMvMCBmb3JrIDE0MzM3MTY3MDMv
>MTQzMzcxNjcwMy8zODkgZm9ya3Rvb211Y2ggMTQzMzcxNjcwMy8xNDMzNzE2NzAzLzE0MzM3MTY3
>MDMgYWxsb2MgNDUvMy8yIGNyZWF0IDI2ODQvMjU0My8zNzMgbG9jayAyLzIvMSkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY3MzIvMjU3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE2
>NzMyLzE5NzQvNCBueHJlYWQgMTQzMzcxNjczMi8xNDMzNzE2NzMyLzExNTMgdHJ5ZXhjZXB0IDEy
>LzEvMSBmb3JrIDE0MzM3MTY3MzIvMTQzMzcxNjczMi80MTggZm9ya3Rvb211Y2ggMTQzMzcxNjcz
>Mi8xNDMzNzE2NzMyLzE0MzM3MTY3MzIgYWxsb2MgNzQvMTMvNCBjcmVhdCAyNzEzLzI1NzIvNDAy
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2NzYxLzI2MDEv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxNjc2MS8yMDAzLzE3IG54cmVhZCAxNDMzNzE2NzYxLzE0MzM3
>MTY3NjEvMTE4MiB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE2NzYxLzE0MzM3MTY3NjEvNDQ3
>IGZvcmt0b29tdWNoIDE0MzM3MTY3NjEvMTQzMzcxNjc2MS8xNDMzNzE2NzYxIGFsbG9jIDEwMy82
>LzEgY3JlYXQgMjc0Mi8yNjAxLzQzMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcxNjc4NS8yNjI1LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY3ODUvMjAyNy83IG54
>cmVhZCAxNDMzNzE2Nzg1LzE0MzM3MTY3ODUvMTIwNiB0cnlleGNlcHQgOC8yLzAgZm9yayAxNDMz
>NzE2Nzg1LzE0MzM3MTY3ODUvNDcxIGZvcmt0b29tdWNoIDE0MzM3MTY3ODUvMTQzMzcxNjc4NS8x
>NDMzNzE2Nzg1IGFsbG9jIDg1LzkvMSBjcmVhdCAyNzY2LzI2MjUvNDU1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2ODEwLzI2NTAvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxNjgxMC8yMDUyLzYgbnhyZWFkIDE0MzM3MTY4MTAvMTQzMzcxNjgxMC8xMjMxIHRyeWV4
>Y2VwdCAzMy8yLzEgZm9yayAxNDMzNzE2ODEwLzE0MzM3MTY4MTAvNDk2IGZvcmt0b29tdWNoIDE0
>MzM3MTY4MTAvMTQzMzcxNjgxMC8xNDMzNzE2ODEwIGFsbG9jIDM0LzIxLzYgY3JlYXQgMjc5MS8y
>NjUwLzQ4MCBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjgz
>NS8yNjc1LzAgKHRlc3RzOiByZWFkIDE0MzM3MTY4MzUvMjA3Ny8yMSBueHJlYWQgMTQzMzcxNjgz
>NS8xNDMzNzE2ODM1LzEyNTYgdHJ5ZXhjZXB0IDQ0LzIvMSBmb3JrIDE0MzM3MTY4MzUvMTQzMzcx
>NjgzNS81MjEgZm9ya3Rvb211Y2ggMTQzMzcxNjgzNS8xNDMzNzE2ODM1LzE0MzM3MTY4MzUgYWxs
>b2MgNDYvMTcvMCBjcmVhdCAyODE2LzI2NzUvNTA1IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE2ODU4LzI2OTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjg1OC8y
>MTAwLzE0IG54cmVhZCAxNDMzNzE2ODU4LzE0MzM3MTY4NTgvMTI3OSB0cnlleGNlcHQgNTUvMi8w
>IGZvcmsgMTQzMzcxNjg1OC8xNDMzNzE2ODU4LzU0NCBmb3JrdG9vbXVjaCAxNDMzNzE2ODU4LzE0
>MzM3MTY4NTgvMTQzMzcxNjg1OCBhbGxvYyA0MC82LzEgY3JlYXQgMjgzOS8yNjk4LzUyOCBsb2Nr
>IDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNjg4MC8yNzIwLzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTY4ODAvMjEyMi8zNiBueHJlYWQgMTQzMzcxNjg4MC8xNDMzNzE2ODgw
>LzEzMDEgdHJ5ZXhjZXB0IDEzLzEvMCBmb3JrIDE0MzM3MTY4ODAvMTQzMzcxNjg4MC81NjYgZm9y
>a3Rvb211Y2ggMTQzMzcxNjg4MC8xNDMzNzE2ODgwLzE0MzM3MTY4ODAgYWxsb2MgMzYvMTIvMiBj
>cmVhdCAyODYxLzI3MjAvNTUwIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE2OTEyLzI3NTIvMCAodGVzdHM6IHJlYWQgMTQzMzcxNjkxMi8yMTU0LzcgbnhyZWFk
>IDE0MzM3MTY5MTIvMTQzMzcxNjkxMi8xMzMzIHRyeWV4Y2VwdCA0NS8zLzAgZm9yayAxNDMzNzE2
>OTEyLzE0MzM3MTY5MTIvNTk4IGZvcmt0b29tdWNoIDE0MzM3MTY5MTIvMTQzMzcxNjkxMi8xNDMz
>NzE2OTEyIGFsbG9jIDE1LzcvMSBjcmVhdCAyODkzLzI3NTIvNTgyIGxvY2sgMS8xLzEpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE2OTU3LzI3OTcvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNjk1Ny8yMTk5LzE0IG54cmVhZCAxNDMzNzE2OTU3LzE0MzM3MTY5NTcvMTM3OCB0cnlleGNl
>cHQgMzMvMi8xIGZvcmsgMTQzMzcxNjk1Ny8xNDMzNzE2OTU3LzY0MyBmb3JrdG9vbXVjaCAxNDMz
>NzE2OTU3LzE0MzM3MTY5NTcvMTQzMzcxNjk1NyBhbGxvYyAyNi8xNC8wIGNyZWF0IDI5MzgvMjc5
>Ny82MjcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTY5OTAv
>MjgzMC8wICh0ZXN0czogcmVhZCAxNDMzNzE2OTkwLzIyMzIvNDcgbnhyZWFkIDE0MzM3MTY5OTAv
>MTQzMzcxNjk5MC8xNDExIHRyeWV4Y2VwdCA0LzAvMCBmb3JrIDE0MzM3MTY5OTAvMTQzMzcxNjk5
>MC82NzYgZm9ya3Rvb211Y2ggMTQzMzcxNjk5MC8xNDMzNzE2OTkwLzE0MzM3MTY5OTAgYWxsb2Mg
>MzcvNy8yIGNyZWF0IDI5NzEvMjgzMC82NjAgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTcwMjQvMjg2NC8wICh0ZXN0czogcmVhZCAxNDMzNzE3MDI0LzIyNjYv
>NSBueHJlYWQgMTQzMzcxNzAyNC8xNDMzNzE3MDI0LzE0NDUgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsg
>MTQzMzcxNzAyNC8xNDMzNzE3MDI0LzcxMCBmb3JrdG9vbXVjaCAxNDMzNzE3MDI0LzE0MzM3MTcw
>MjQvMTQzMzcxNzAyNCBhbGxvYyAzNi8xMC81IGNyZWF0IDMwMDUvMjg2NC82OTQgbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcwNjAvMjkwMC8wICh0ZXN0czog
>cmVhZCAxNDMzNzE3MDYwLzU1MC8xMyBueHJlYWQgMTQzMzcxNzA2MC8xNDMzNzE3MDYwLzE0ODEg
>dHJ5ZXhjZXB0IDE0LzIvMCBmb3JrIDE0MzM3MTcwNjAvMTQzMzcxNzA2MC83NDYgZm9ya3Rvb211
>Y2ggMTQzMzcxNzA2MC8xNDMzNzE3MDYwLzE0MzM3MTcwNjAgYWxsb2MgNTgvMTMvMSBjcmVhdCAz
>MDQxLzI5MDAvNzMwIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzE3MDk0LzI5MzQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzA5NC81ODQvOCBueHJlYWQgMTQzMzcx
>NzA5NC8xNDMzNzE3MDk0LzE1MTUgdHJ5ZXhjZXB0IDQ4LzIvMSBmb3JrIDE0MzM3MTcwOTQvMTQz
>MzcxNzA5NC83ODAgZm9ya3Rvb211Y2ggMTQzMzcxNzA5NC8xNDMzNzE3MDk0LzE0MzM3MTcwOTQg
>YWxsb2MgNjEvNC80IGNyZWF0IDMwNzUvMjkzNC83NjQgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MTcxMTIvMjk1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE3MTEy
>LzYwMi82IG54cmVhZCAxNDMzNzE3MTEyLzE0MzM3MTcxMTIvMTUzMyB0cnlleGNlcHQgNTQvMi8x
>IGZvcmsgMTQzMzcxNzExMi8xNDMzNzE3MTEyLzc5OCBmb3JrdG9vbXVjaCAxNDMzNzE3MTEyLzE0
>MzM3MTcxMTIvMTQzMzcxNzExMiBhbGxvYyA3OS8xMi8yIGNyZWF0IDMwOTMvMjk1Mi83ODIgbG9j
>ayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcxMzUvMjk3NS8wICh0
>ZXN0czogcmVhZCAxNDMzNzE3MTM1LzYyNS8xNyBueHJlYWQgMTQzMzcxNzEzNS8xNDMzNzE3MTM1
>LzE1NTYgdHJ5ZXhjZXB0IDExLzMvMCBmb3JrIDE0MzM3MTcxMzUvMTQzMzcxNzEzNS84MjEgZm9y
>a3Rvb211Y2ggMTQzMzcxNzEzNS8xNDMzNzE3MTM1LzE0MzM3MTcxMzUgYWxsb2MgNDEvMTAvMSBj
>cmVhdCAzMTE2LzI5NzUvODA1IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3MTYxLzMwMDEvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzE2MS82NTEvMjIgbnhyZWFk
>IDE0MzM3MTcxNjEvMTQzMzcxNzE2MS8xNTgyIHRyeWV4Y2VwdCA1LzEvMCBmb3JrIDE0MzM3MTcx
>NjEvMTQzMzcxNzE2MS84NDcgZm9ya3Rvb211Y2ggMTQzMzcxNzE2MS8xNDMzNzE3MTYxLzE0MzM3
>MTcxNjEgYWxsb2MgMzYvMTEvMiBjcmVhdCAzMTQyLzMwMDEvODMxIGxvY2sgMS8xLzEpCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3MTg2LzMwMjYvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxNzE4Ni82NzYvNCBueHJlYWQgMTQzMzcxNzE4Ni8xNDMzNzE3MTg2LzE2MDcgdHJ5ZXhjZXB0
>IDE5LzIvMCBmb3JrIDE0MzM3MTcxODYvMTQzMzcxNzE4Ni84NzIgZm9ya3Rvb211Y2ggMTQzMzcx
>NzE4Ni8xNDMzNzE3MTg2LzE0MzM3MTcxODYgYWxsb2MgNTQvNC8xIGNyZWF0IDMxNjcvMzAyNi84
>NTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcyMTUvMzA1
>NS8wICh0ZXN0czogcmVhZCAxNDMzNzE3MjE1LzcwNS8yMCBueHJlYWQgMTQzMzcxNzIxNS8xNDMz
>NzE3MjE1LzE2MzYgdHJ5ZXhjZXB0IDI3LzIvMSBmb3JrIDE0MzM3MTcyMTUvMTQzMzcxNzIxNS85
>MDEgZm9ya3Rvb211Y2ggMTQzMzcxNzIxNS8xNDMzNzE3MjE1LzE0MzM3MTcyMTUgYWxsb2MgNDYv
>MTMvMCBjcmVhdCAzMTk2LzMwNTUvODg1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE3MjQ5LzMwODkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzI0OS83MzkvNiBu
>eHJlYWQgMTQzMzcxNzI0OS8xNDMzNzE3MjQ5LzE2NzAgdHJ5ZXhjZXB0IDUvMi8xIGZvcmsgMTQz
>MzcxNzI0OS8xNDMzNzE3MjQ5LzkzNSBmb3JrdG9vbXVjaCAxNDMzNzE3MjQ5LzE0MzM3MTcyNDkv
>MTQzMzcxNzI0OSBhbGxvYyAzOC8xMS82IGNyZWF0IDMyMzAvMzA4OS85MTkgbG9jayA2LzAvMCkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcyODAvMzEyMC8wICh0ZXN0czogcmVh
>ZCAxNDMzNzE3MjgwLzc3MC8xNSBueHJlYWQgMTQzMzcxNzI4MC8xNDMzNzE3MjgwLzE3MDEgdHJ5
>ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcxNzI4MC8xNDMzNzE3MjgwLzk2NiBmb3JrdG9vbXVjaCAx
>NDMzNzE3MjgwLzE0MzM3MTcyODAvMTQzMzcxNzI4MCBhbGxvYyA0OC8xMC80IGNyZWF0IDMyNjEv
>MzEyMC85NTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTcz
>MzIvMzE3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE3MzMyLzgyMi85IG54cmVhZCAxNDMzNzE3MzMy
>LzE0MzM3MTczMzIvMTc1MyB0cnlleGNlcHQgMjgvMS8wIGZvcmsgMTQzMzcxNzMzMi8xNDMzNzE3
>MzMyLzEwMTggZm9ya3Rvb211Y2ggMTQzMzcxNzMzMi8xNDMzNzE3MzMyLzE0MzM3MTczMzIgYWxs
>b2MgMzcvOS8yIGNyZWF0IDMzMTMvMzE3Mi8xMDAyIGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE3MzY3LzMyMDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzM2Ny84
>NTYvNiBueHJlYWQgMTQzMzcxNzM2Ny8xNDMzNzE3MzY3LzE3ODggdHJ5ZXhjZXB0IDE5LzMvMiBm
>b3JrIDE0MzM3MTczNjcvMTQzMzcxNzM2Ny8xMDUzIGZvcmt0b29tdWNoIDE0MzM3MTczNjcvMTQz
>MzcxNzM2Ny8xNDMzNzE3MzY3IGFsbG9jIDE3LzYvMyBjcmVhdCAzMzQ4LzMyMDcvMTAzNyBsb2Nr
>IDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzQwOC8zMjQ4LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTc0MDgvODk3LzcgbnhyZWFkIDE0MzM3MTc0MDgvMTQzMzcxNzQwOC8x
>ODI5IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAxNDMzNzE3NDA4LzE0MzM3MTc0MDgvMTA5NCBmb3Jr
>dG9vbXVjaCAxNDMzNzE3NDA4LzE0MzM3MTc0MDgvMTQzMzcxNzQwOCBhbGxvYyA1NC8xMy8xIGNy
>ZWF0IDMzODkvMzI0OC8xMDc4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3NDM1LzMyNzUvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzQzNS8yOTYvNSBueHJlYWQg
>MTQzMzcxNzQzNS8xNDMzNzE3NDM1LzE4NTYgdHJ5ZXhjZXB0IDE4LzIvMSBmb3JrIDE0MzM3MTc0
>MzUvMTQzMzcxNzQzNS8xMTIxIGZvcmt0b29tdWNoIDE0MzM3MTc0MzUvMTQzMzcxNzQzNS8xNDMz
>NzE3NDM1IGFsbG9jIDgxLzUvNSBjcmVhdCAzNDE2LzMyNzUvMTEwNSBsb2NrIDUvNS8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzQ2Ny8zMzA3LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTc0NjcvMzI4LzE0IG54cmVhZCAxNDMzNzE3NDY3LzE0MzM3MTc0NjcvMTg4OCB0cnlleGNl
>cHQgMjkvMi8yIGZvcmsgMTQzMzcxNzQ2Ny8xNDMzNzE3NDY3LzExNTMgZm9ya3Rvb211Y2ggMTQz
>MzcxNzQ2Ny8xNDMzNzE3NDY3LzE0MzM3MTc0NjcgYWxsb2MgMTEzLzExLzMgY3JlYXQgMzQ0OC8z
>MzA3LzExMzcgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc0
>OTYvMzMzNi8wICh0ZXN0czogcmVhZCAxNDMzNzE3NDk2LzM1Ny8yMCBueHJlYWQgMTQzMzcxNzQ5
>Ni8xNDMzNzE3NDk2LzE5MTcgdHJ5ZXhjZXB0IDQ1LzIvMSBmb3JrIDE0MzM3MTc0OTYvMTQzMzcx
>NzQ5Ni8xMTgyIGZvcmt0b29tdWNoIDE0MzM3MTc0OTYvMTQzMzcxNzQ5Ni8xNDMzNzE3NDk2IGFs
>bG9jIDQ4LzkvNSBjcmVhdCAzNDc3LzMzMzYvMTE2NiBsb2NrIDUvMC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzU0My8zMzgzLzAgKHRlc3RzOiByZWFkIDE0MzM3MTc1NDMv
>NDA0LzEgbnhyZWFkIDE0MzM3MTc1NDMvMTQzMzcxNzU0My8xOTY0IHRyeWV4Y2VwdCAzNC8zLzAg
>Zm9yayAxNDMzNzE3NTQzLzE0MzM3MTc1NDMvMTIyOSBmb3JrdG9vbXVjaCAxNDMzNzE3NTQzLzE0
>MzM3MTc1NDMvMTQzMzcxNzU0MyBhbGxvYyA2MS8xLzEgY3JlYXQgMzUyNC8zMzgzLzEyMTMgbG9j
>ayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc1NjgvMzQwOC8wICh0
>ZXN0czogcmVhZCAxNDMzNzE3NTY4LzQyOS82IG54cmVhZCAxNDMzNzE3NTY4LzE0MzM3MTc1Njgv
>MTk4OSB0cnlleGNlcHQgMTIvMi8wIGZvcmsgMTQzMzcxNzU2OC8xNDMzNzE3NTY4LzEyNTQgZm9y
>a3Rvb211Y2ggMTQzMzcxNzU2OC8xNDMzNzE3NTY4LzE0MzM3MTc1NjggYWxsb2MgMjYvNi8xIGNy
>ZWF0IDM1NDkvMzQwOC8xMjM4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE3NTk5LzM0MzkvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzU5OS80NjAvNSBueHJlYWQg
>MTQzMzcxNzU5OS8xNDMzNzE3NTk5LzIwMjAgdHJ5ZXhjZXB0IDQvMS8xIGZvcmsgMTQzMzcxNzU5
>OS8xNDMzNzE3NTk5LzEyODUgZm9ya3Rvb211Y2ggMTQzMzcxNzU5OS8xNDMzNzE3NTk5LzE0MzM3
>MTc1OTkgYWxsb2MgMjcvMTEvNSBjcmVhdCAzNTgwLzM0MzkvMTI2OSBsb2NrIDMvMy8wKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzYzNS8zNDc1LzAgKHRlc3RzOiByZWFkIDE0
>MzM3MTc2MzUvNDk2LzM2IG54cmVhZCAxNDMzNzE3NjM1LzE0MzM3MTc2MzUvMjA1NiB0cnlleGNl
>cHQgNS8yLzEgZm9yayAxNDMzNzE3NjM1LzE0MzM3MTc2MzUvMTMyMSBmb3JrdG9vbXVjaCAxNDMz
>NzE3NjM1LzE0MzM3MTc2MzUvMTQzMzcxNzYzNSBhbGxvYyAzNi8xMC82IGNyZWF0IDM2MTYvMzQ3
>NS8xMzA1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3NjY3
>LzM1MDcvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzY2Ny81MjgvNSBueHJlYWQgMTQzMzcxNzY2Ny8x
>NDMzNzE3NjY3LzIwODggdHJ5ZXhjZXB0IDQvMi8yIGZvcmsgMTQzMzcxNzY2Ny8xNDMzNzE3NjY3
>LzEzNTMgZm9ya3Rvb211Y2ggMTQzMzcxNzY2Ny8xNDMzNzE3NjY3LzE0MzM3MTc2NjcgYWxsb2Mg
>NDIvNS81IGNyZWF0IDM2NDgvMzUwNy8xMzM3IGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE3Njk0LzM1MzQvMCAodGVzdHM6IHJlYWQgMTQzMzcxNzY5NC81NTUv
>MjMgbnhyZWFkIDE0MzM3MTc2OTQvMTQzMzcxNzY5NC8yMTE1IHRyeWV4Y2VwdCAzLzIvMCBmb3Jr
>IDE0MzM3MTc2OTQvMTQzMzcxNzY5NC8xMzgwIGZvcmt0b29tdWNoIDE0MzM3MTc2OTQvMTQzMzcx
>NzY5NC8xNDMzNzE3Njk0IGFsbG9jIDMyLzYvMSBjcmVhdCAzNjc1LzM1MzQvMTM2NCBsb2NrIDEv
>MS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzczMy8zNTczLzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTc3MzMvNTk0LzkgbnhyZWFkIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8yMTU0
>IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8xNDE5IGZvcmt0b29t
>dWNoIDE0MzM3MTc3MzMvMTQzMzcxNzczMy8xNDMzNzE3NzMzIGFsbG9jIDI0LzEzLzMgY3JlYXQg
>MzcxNC8zNTczLzE0MDMgbG9jayAyLzIvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTc3NjcvMzYwNy8wICh0ZXN0czogcmVhZCAxNDMzNzE3NzY3LzYyOC8yIG54cmVhZCAxNDMz
>NzE3NzY3LzE0MzM3MTc3NjcvMjE4OCB0cnlleGNlcHQgMS8xLzEgZm9yayAxNDMzNzE3NzY3LzE0
>MzM3MTc3NjcvMTQ1MyBmb3JrdG9vbXVjaCAxNDMzNzE3NzY3LzE0MzM3MTc3NjcvMTQzMzcxNzc2
>NyBhbGxvYyA1OC8xMS8yIGNyZWF0IDM3NDgvMzYwNy8xNDM3IGxvY2sgMi8yLzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE3NzkwLzM2MzAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>Nzc5MC82NTEvMSBueHJlYWQgMTQzMzcxNzc5MC8xNDMzNzE3NzkwLzIyMTEgdHJ5ZXhjZXB0IDQv
>Mi8wIGZvcmsgMTQzMzcxNzc5MC8xNDMzNzE3NzkwLzE0NzYgZm9ya3Rvb211Y2ggMTQzMzcxNzc5
>MC8xNDMzNzE3NzkwLzE0MzM3MTc3OTAgYWxsb2MgMzQvMTQvMiBjcmVhdCAzNzcxLzM2MzAvMTQ2
>MCBsb2NrIDEvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzgzNy8zNjc3
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc4MzcvNDM3LzUgbnhyZWFkIDE0MzM3MTc4MzcvMTQzMzcx
>NzgzNy8yMjU4IHRyeWV4Y2VwdCAyMS8yLzEgZm9yayAxNDMzNzE3ODM3LzE0MzM3MTc4MzcvMTUy
>MyBmb3JrdG9vbXVjaCAxNDMzNzE3ODM3LzE0MzM3MTc4MzcvMTQzMzcxNzgzNyBhbGxvYyAyNS81
>LzAgY3JlYXQgMzgxOC8zNjc3LzE1MDcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTc4NzIvMzcxMi8wICh0ZXN0czogcmVhZCAxNDMzNzE3ODcyLzQ3Mi8xNiBu
>eHJlYWQgMTQzMzcxNzg3Mi8xNDMzNzE3ODcyLzIyOTMgdHJ5ZXhjZXB0IDIzLzIvMSBmb3JrIDE0
>MzM3MTc4NzIvMTQzMzcxNzg3Mi8xNTU4IGZvcmt0b29tdWNoIDE0MzM3MTc4NzIvMTQzMzcxNzg3
>Mi8xNDMzNzE3ODcyIGFsbG9jIDYwLzIyLzYgY3JlYXQgMzg1My8zNzEyLzE1NDIgbG9jayA0LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc5MDkvMzc0OS8wICh0ZXN0czog
>cmVhZCAxNDMzNzE3OTA5LzUwOS8xOSBueHJlYWQgMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzIzMzAg
>dHJ5ZXhjZXB0IDMvMS8wIGZvcmsgMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzE1OTUgZm9ya3Rvb211
>Y2ggMTQzMzcxNzkwOS8xNDMzNzE3OTA5LzE0MzM3MTc5MDkgYWxsb2MgNDMvMTMvMSBjcmVhdCAz
>ODkwLzM3NDkvMTU3OSBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQz
>MzcxNzk0OS8zNzg5LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc5NDkvNTQ5LzEwIG54cmVhZCAxNDMz
>NzE3OTQ5LzE0MzM3MTc5NDkvMjM3MCB0cnlleGNlcHQgMy8yLzIgZm9yayAxNDMzNzE3OTQ5LzE0
>MzM3MTc5NDkvMTYzNSBmb3JrdG9vbXVjaCAxNDMzNzE3OTQ5LzE0MzM3MTc5NDkvMTQzMzcxNzk0
>OSBhbGxvYyAxNS82LzYgY3JlYXQgMzkzMC8zNzg5LzE2MTkgbG9jayA2LzYvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTc5NjEvMzgwMS8wICh0ZXN0czogcmVhZCAxNDMzNzE3
>OTYxLzU2MS8xMiBueHJlYWQgMTQzMzcxNzk2MS8xNDMzNzE3OTYxLzIzODIgdHJ5ZXhjZXB0IDkv
>My8wIGZvcmsgMTQzMzcxNzk2MS8xNDMzNzE3OTYxLzE2NDcgZm9ya3Rvb211Y2ggMTQzMzcxNzk2
>MS8xNDMzNzE3OTYxLzE0MzM3MTc5NjEgYWxsb2MgMjcvMTIvNyBjcmVhdCAzOTQyLzM4MDEvMTYz
>MSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxNzk5Ni8zODM2
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTc5OTYvNTk2LzEgbnhyZWFkIDE0MzM3MTc5OTYvMTQzMzcx
>Nzk5Ni8yNDE3IHRyeWV4Y2VwdCA0LzMvMCBmb3JrIDE0MzM3MTc5OTYvMTQzMzcxNzk5Ni8xNjgy
>IGZvcmt0b29tdWNoIDE0MzM3MTc5OTYvMTQzMzcxNzk5Ni8xNDMzNzE3OTk2IGFsbG9jIDUzLzEy
>LzEgY3JlYXQgMzk3Ny8zODM2LzE2NjYgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MTgwNTEvMzg5MS8wICh0ZXN0czogcmVhZCAxNDMzNzE4MDUxLzY1MS8yMCBu
>eHJlYWQgMTQzMzcxODA1MS8xNDMzNzE4MDUxLzI0NzIgdHJ5ZXhjZXB0IDE3LzIvMSBmb3JrIDE0
>MzM3MTgwNTEvMTQzMzcxODA1MS8xNzM3IGZvcmt0b29tdWNoIDE0MzM3MTgwNTEvMTQzMzcxODA1
>MS8xNDMzNzE4MDUxIGFsbG9jIDI2LzkvMyBjcmVhdCA0MDMyLzM4OTEvMTcyMSBsb2NrIDIvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODA4Ni8zOTI2LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MTgwODYvNjg2LzIzIG54cmVhZCAxNDMzNzE4MDg2LzE0MzM3MTgwODYvMjUwNyB0
>cnlleGNlcHQgNTIvMi8xIGZvcmsgMTQzMzcxODA4Ni8xNDMzNzE4MDg2LzE3NzIgZm9ya3Rvb211
>Y2ggMTQzMzcxODA4Ni8xNDMzNzE4MDg2LzE0MzM3MTgwODYgYWxsb2MgMzgvOS80IGNyZWF0IDQw
>NjcvMzkyNi8xNzU2IGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzE4MTEzLzM5NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODExMy83MTMvMTggbnhyZWFkIDE0MzM3
>MTgxMTMvMTQzMzcxODExMy8yNTM0IHRyeWV4Y2VwdCAyNS8yLzEgZm9yayAxNDMzNzE4MTEzLzE0
>MzM3MTgxMTMvMTc5OSBmb3JrdG9vbXVjaCAxNDMzNzE4MTEzLzE0MzM3MTgxMTMvMTQzMzcxODEx
>MyBhbGxvYyA1OS8xMC81IGNyZWF0IDQwOTQvMzk1My8xNzgzIGxvY2sgNS81LzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MTUwLzM5OTAvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>ODE1MC83NTAvMSBueHJlYWQgMTQzMzcxODE1MC8xNDMzNzE4MTUwLzI1NzEgdHJ5ZXhjZXB0IDkv
>Mi8wIGZvcmsgMTQzMzcxODE1MC8xNDMzNzE4MTUwLzE4MzYgZm9ya3Rvb211Y2ggMTQzMzcxODE1
>MC8xNDMzNzE4MTUwLzE0MzM3MTgxNTAgYWxsb2MgMzcvMy8xIGNyZWF0IDQxMzEvMzk5MC8xODIw
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MTgxLzQwMjEv
>MCAodGVzdHM6IHJlYWQgMTQzMzcxODE4MS83ODEvMjMgbnhyZWFkIDE0MzM3MTgxODEvMTQzMzcx
>ODE4MS8yNjAyIHRyeWV4Y2VwdCAzMy8xMC8yIGZvcmsgMTQzMzcxODE4MS8xNDMzNzE4MTgxLzE4
>NjcgZm9ya3Rvb211Y2ggMTQzMzcxODE4MS8xNDMzNzE4MTgxLzE0MzM3MTgxODEgYWxsb2MgMzQv
>MTIvMCBjcmVhdCA0MTYyLzQwMjEvMTg1MSBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxODIyNy80MDY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTgyMjcvODI3LzEg
>bnhyZWFkIDE0MzM3MTgyMjcvMTQzMzcxODIyNy8yNjQ4IHRyeWV4Y2VwdCA0Mi8yLzAgZm9yayAx
>NDMzNzE4MjI3LzE0MzM3MTgyMjcvMTkxMyBmb3JrdG9vbXVjaCAxNDMzNzE4MjI3LzE0MzM3MTgy
>MjcvMTQzMzcxODIyNyBhbGxvYyA0NC8xMi8wIGNyZWF0IDQyMDgvNDA2Ny8xODk3IGxvY2sgMC8w
>LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MjU3LzQwOTcvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxODI1Ny84NTcvMTMgbnhyZWFkIDE0MzM3MTgyNTcvMTQzMzcxODI1Ny8yNjc4
>IHRyeWV4Y2VwdCAyMi8yLzAgZm9yayAxNDMzNzE4MjU3LzE0MzM3MTgyNTcvMTk0MyBmb3JrdG9v
>bXVjaCAxNDMzNzE4MjU3LzE0MzM3MTgyNTcvMTQzMzcxODI1NyBhbGxvYyA3NC8zLzEgY3JlYXQg
>NDIzOC80MDk3LzE5MjcgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTgzMDIvNDE0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzE4MzAyLzkwMi84IG54cmVhZCAxNDMz
>NzE4MzAyLzE0MzM3MTgzMDIvMjcyMyB0cnlleGNlcHQgMjQvMy8wIGZvcmsgMTQzMzcxODMwMi8x
>NDMzNzE4MzAyLzE5ODggZm9ya3Rvb211Y2ggMTQzMzcxODMwMi8xNDMzNzE4MzAyLzE0MzM3MTgz
>MDIgYWxsb2MgMzcvNC8xIGNyZWF0IDQyODMvNDE0Mi8xOTcyIGxvY2sgMS8xLzEpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MzIyLzQxNjIvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>ODMyMi85MjIvMTcgbnhyZWFkIDE0MzM3MTgzMjIvMTQzMzcxODMyMi8yNzQzIHRyeWV4Y2VwdCAy
>My8xLzAgZm9yayAxNDMzNzE4MzIyLzE0MzM3MTgzMjIvMjAwOCBmb3JrdG9vbXVjaCAxNDMzNzE4
>MzIyLzE0MzM3MTgzMjIvMTQzMzcxODMyMiBhbGxvYyAzOS8xNy8xIGNyZWF0IDQzMDMvNDE2Mi8x
>OTkyIGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4MzY4LzMx
>OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODM2OC85NTQvNCBueHJlYWQgMTQzMzcxODM2OC8xNDMz
>NzE4MzY4LzI3ODkgdHJ5ZXhjZXB0IDQyLzIvMSBmb3JrIDE0MzM3MTgzNjgvMTQzMzcxODM2OC8y
>MDU0IGZvcmt0b29tdWNoIDE0MzM3MTgzNjgvMTQzMzcxODM2OC8xNDMzNzE4MzY4IGFsbG9jIDI2
>LzcvMCBjcmVhdCA0MzQ5LzQyMDgvMjAzOCBsb2NrIDMvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0
>aHJlYWQgaXMgMTQzMzcxODQwMi8zMjI3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg0MDIvOTg4LzIy
>IG54cmVhZCAxNDMzNzE4NDAyLzE0MzM3MTg0MDIvMjgyMyB0cnlleGNlcHQgMTMvMy8wIGZvcmsg
>MTQzMzcxODQwMi8xNDMzNzE4NDAyLzIwODggZm9ya3Rvb211Y2ggMTQzMzcxODQwMi8xNDMzNzE4
>NDAyLzE0MzM3MTg0MDIgYWxsb2MgMzgvNi8yIGNyZWF0IDQzODMvNDI0Mi8yMDcyIGxvY2sgMi8y
>LzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NDIyLzMyNDcvMCAodGVzdHM6
>IHJlYWQgMTQzMzcxODQyMi8xMDA4LzQgbnhyZWFkIDE0MzM3MTg0MjIvMTQzMzcxODQyMi8yODQz
>IHRyeWV4Y2VwdCAzMy8zLzAgZm9yayAxNDMzNzE4NDIyLzE0MzM3MTg0MjIvMjEwOCBmb3JrdG9v
>bXVjaCAxNDMzNzE4NDIyLzE0MzM3MTg0MjIvMTQzMzcxODQyMiBhbGxvYyA1MC8xMC8yIGNyZWF0
>IDQ0MDMvNDI2Mi8yMDkyIGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE4NDU2LzMyODEvMCAodGVzdHM6IHJlYWQgMTQzMzcxODQ1Ni8xMDQyLzExIG54cmVhZCAx
>NDMzNzE4NDU2LzE0MzM3MTg0NTYvMjg3NyB0cnlleGNlcHQgMy8xLzEgZm9yayAxNDMzNzE4NDU2
>LzE0MzM3MTg0NTYvMjE0MiBmb3JrdG9vbXVjaCAxNDMzNzE4NDU2LzE0MzM3MTg0NTYvMTQzMzcx
>ODQ1NiBhbGxvYyAzOC8xNS80IGNyZWF0IDQ0MzcvNDI5Ni8yMTI2IGxvY2sgNC80LzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NDkwLzMzMTUvMCAodGVzdHM6IHJlYWQgMTQz
>MzcxODQ5MC8xMDc2LzEgbnhyZWFkIDE0MzM3MTg0OTAvMTQzMzcxODQ5MC8yOTExIHRyeWV4Y2Vw
>dCA0LzIvMCBmb3JrIDE0MzM3MTg0OTAvMTQzMzcxODQ5MC8yMTc2IGZvcmt0b29tdWNoIDE0MzM3
>MTg0OTAvMTQzMzcxODQ5MC8xNDMzNzE4NDkwIGFsbG9jIDM4LzcvMSBjcmVhdCA0NDcxLzQzMzAv
>MjE2MCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODUyMS8z
>MzQ2LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg1MjEvMTEwNy83IG54cmVhZCAxNDMzNzE4NTIxLzE0
>MzM3MTg1MjEvMjk0MiB0cnlleGNlcHQgNi8xLzAgZm9yayAxNDMzNzE4NTIxLzE0MzM3MTg1MjEv
>MjIwNyBmb3JrdG9vbXVjaCAxNDMzNzE4NTIxLzE0MzM3MTg1MjEvMTQzMzcxODUyMSBhbGxvYyAy
>Mi83LzMgY3JlYXQgNDUwMi80MzYxLzIxOTEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MTg1NTAvMzM3NS8wICh0ZXN0czogcmVhZCAxNDMzNzE4NTUwLzExMzYv
>NyBueHJlYWQgMTQzMzcxODU1MC8xNDMzNzE4NTUwLzI5NzEgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsg
>MTQzMzcxODU1MC8xNDMzNzE4NTUwLzIyMzYgZm9ya3Rvb211Y2ggMTQzMzcxODU1MC8xNDMzNzE4
>NTUwLzE0MzM3MTg1NTAgYWxsb2MgNTEvMTQvNyBjcmVhdCA0NTMxLzQzOTAvMjIyMCBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODU4My8zNDA4LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTg1ODMvMTE2OS81IG54cmVhZCAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMzAw
>NCB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMjI2OSBmb3JrdG9v
>bXVjaCAxNDMzNzE4NTgzLzE0MzM3MTg1ODMvMTQzMzcxODU4MyBhbGxvYyA3NC81LzAgY3JlYXQg
>NDU2NC80NDIzLzIyNTMgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTg2MDkvMzQzNC8wICh0ZXN0czogcmVhZCAxNDMzNzE4NjA5LzExOTUvNyBueHJlYWQgMTQz
>MzcxODYwOS8xNDMzNzE4NjA5LzMwMzAgdHJ5ZXhjZXB0IDE1LzEvMSBmb3JrIDE0MzM3MTg2MDkv
>MTQzMzcxODYwOS8yMjk1IGZvcmt0b29tdWNoIDE0MzM3MTg2MDkvMTQzMzcxODYwOS8xNDMzNzE4
>NjA5IGFsbG9jIDEwMC83LzIgY3JlYXQgNDU5MC80NDQ5LzIyNzkgbG9jayAyLzIvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg2NDEvMzQ2Ni8wICh0ZXN0czogcmVhZCAxNDMz
>NzE4NjQxLzEyMjcvNyBueHJlYWQgMTQzMzcxODY0MS8xNDMzNzE4NjQxLzMwNjIgdHJ5ZXhjZXB0
>IDMzLzEvMSBmb3JrIDE0MzM3MTg2NDEvMTQzMzcxODY0MS8yMzI3IGZvcmt0b29tdWNoIDE0MzM3
>MTg2NDEvMTQzMzcxODY0MS8xNDMzNzE4NjQxIGFsbG9jIDM0LzcvMCBjcmVhdCA0NjIyLzQ0ODEv
>MjMxMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxODY3OS8z
>NTA0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg2NzkvMTI2NS81IG54cmVhZCAxNDMzNzE4Njc5LzE0
>MzM3MTg2NzkvMzEwMCB0cnlleGNlcHQgNi8xLzEgZm9yayAxNDMzNzE4Njc5LzE0MzM3MTg2Nzkv
>MjM2NSBmb3JrdG9vbXVjaCAxNDMzNzE4Njc5LzE0MzM3MTg2NzkvMTQzMzcxODY3OSBhbGxvYyA0
>NS8xNi81IGNyZWF0IDQ2NjAvNDUxOS8yMzQ5IGxvY2sgNC80LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE4NzEyLzM1MzcvMCAodGVzdHM6IHJlYWQgMTQzMzcxODcxMi8xMjk4
>LzM4IG54cmVhZCAxNDMzNzE4NzEyLzE0MzM3MTg3MTIvMzEzMyB0cnlleGNlcHQgMjEvMi8xIGZv
>cmsgMTQzMzcxODcxMi8xNDMzNzE4NzEyLzIzOTggZm9ya3Rvb211Y2ggMTQzMzcxODcxMi8xNDMz
>NzE4NzEyLzE0MzM3MTg3MTIgYWxsb2MgNTIvOS81IGNyZWF0IDQ2OTMvNDU1Mi8yMzgyIGxvY2sg
>NS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE4NzM4LzM1NjMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxODczOC8xMzI0LzcgbnhyZWFkIDE0MzM3MTg3MzgvMTQzMzcxODczOC8z
>MTU5IHRyeWV4Y2VwdCAyNy8yLzIgZm9yayAxNDMzNzE4NzM4LzE0MzM3MTg3MzgvMjQyNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE4NzM4LzE0MzM3MTg3MzgvMTQzMzcxODczOCBhbGxvYyA2OS8xOS83IGNy
>ZWF0IDQ3MTkvNDU3OC8yNDA4IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE4NzY4LzM1OTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxODc2OC8xMzU0LzE1IG54cmVh
>ZCAxNDMzNzE4NzY4LzE0MzM3MTg3NjgvMzE4OSB0cnlleGNlcHQgNi8zLzEgZm9yayAxNDMzNzE4
>NzY4LzE0MzM3MTg3NjgvMjQ1NCBmb3JrdG9vbXVjaCAxNDMzNzE4NzY4LzE0MzM3MTg3NjgvMTQz
>MzcxODc2OCBhbGxvYyA0OS84LzUgY3JlYXQgNDc0OS80NjA4LzI0MzggbG9jayAwLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg3OTYvMzYyMS8wICh0ZXN0czogcmVhZCAx
>NDMzNzE4Nzk2LzEzODIvMTIgbnhyZWFkIDE0MzM3MTg3OTYvMTQzMzcxODc5Ni8zMjE3IHRyeWV4
>Y2VwdCAzNC8zLzEgZm9yayAxNDMzNzE4Nzk2LzE0MzM3MTg3OTYvMjQ4MiBmb3JrdG9vbXVjaCAx
>NDMzNzE4Nzk2LzE0MzM3MTg3OTYvMTQzMzcxODc5NiBhbGxvYyAzMy8xOS81IGNyZWF0IDQ3Nzcv
>NDYzNi8yNDY2IGxvY2sgMTAvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>ODg0OS8zNjc0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTg4NDkvMTQzNS80NSBueHJlYWQgMTQzMzcx
>ODg0OS8xNDMzNzE4ODQ5LzMyNzAgdHJ5ZXhjZXB0IDIwLzIvMSBmb3JrIDE0MzM3MTg4NDkvMTQz
>MzcxODg0OS8yNTM1IGZvcmt0b29tdWNoIDE0MzM3MTg4NDkvMTQzMzcxODg0OS8xNDMzNzE4ODQ5
>IGFsbG9jIDQwLzEwLzQgY3JlYXQgNDgzMC80Njg5LzI1MTkgbG9jayA0LzQvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg4OTEvMzcxNi8wICh0ZXN0czogcmVhZCAxNDMzNzE4
>ODkxLzE0NzcvMSBueHJlYWQgMTQzMzcxODg5MS8xNDMzNzE4ODkxLzMzMTIgdHJ5ZXhjZXB0IDMx
>LzIvMCBmb3JrIDE0MzM3MTg4OTEvMTQzMzcxODg5MS8yNTc3IGZvcmt0b29tdWNoIDE0MzM3MTg4
>OTEvMTQzMzcxODg5MS8xNDMzNzE4ODkxIGFsbG9jIDQyLzExLzEgY3JlYXQgNDg3Mi80NzMxLzI1
>NjEgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTg5NDkvMzc3
>NC8wICh0ZXN0czogcmVhZCAxNDMzNzE4OTQ5LzE1MzUvOCBueHJlYWQgMTQzMzcxODk0OS8xNDMz
>NzE4OTQ5LzMzNzAgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcxODk0OS8xNDMzNzE4OTQ5LzI2
>MzUgZm9ya3Rvb211Y2ggMTQzMzcxODk0OS8xNDMzNzE4OTQ5LzE0MzM3MTg5NDkgYWxsb2MgMjgv
>Mi8yIGNyZWF0IDQ5MzAvNDc4OS8yNjE5IGxvY2sgMi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE5MDAyLzM4MjcvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTAwMi8xNTg4LzE5
>IG54cmVhZCAxNDMzNzE5MDAyLzE0MzM3MTkwMDIvMzQyMyB0cnlleGNlcHQgMjgvMS8wIGZvcmsg
>MTQzMzcxOTAwMi8xNDMzNzE5MDAyLzI2ODggZm9ya3Rvb211Y2ggMTQzMzcxOTAwMi8xNDMzNzE5
>MDAyLzE0MzM3MTkwMDIgYWxsb2MgNTUvMTEvMiBjcmVhdCA0OTgzLzQ4NDIvMjY3MiBsb2NrIDEv
>MS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTAzMy8zODU4LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTkwMzMvMTYxOS81IG54cmVhZCAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMzQ1
>NCB0cnlleGNlcHQgNC8yLzEgZm9yayAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMjcxOSBmb3JrdG9v
>bXVjaCAxNDMzNzE5MDMzLzE0MzM3MTkwMzMvMTQzMzcxOTAzMyBhbGxvYyAyNy8xMS8wIGNyZWF0
>IDUwMTQvNDg3My8yNzAzIGxvY2sgNC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAx
>NDMzNzE5MDYzLzM4ODgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTA2My8xNjQ5LzYgbnhyZWFkIDE0
>MzM3MTkwNjMvMTQzMzcxOTA2My8zNDg0IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MTkwNjMv
>MTQzMzcxOTA2My8yNzQ5IGZvcmt0b29tdWNoIDE0MzM3MTkwNjMvMTQzMzcxOTA2My8xNDMzNzE5
>MDYzIGFsbG9jIDMwLzYvMSBjcmVhdCA1MDQ0LzQ5MDMvMjczMyBsb2NrIDAvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTEwNi8zOTMxLzAgKHRlc3RzOiByZWFkIDE0MzM3
>MTkxMDYvMTY5Mi80OSBueHJlYWQgMTQzMzcxOTEwNi8xNDMzNzE5MTA2LzM1MjcgdHJ5ZXhjZXB0
>IDcvMS8wIGZvcmsgMTQzMzcxOTEwNi8xNDMzNzE5MTA2LzI3OTIgZm9ya3Rvb211Y2ggMTQzMzcx
>OTEwNi8xNDMzNzE5MTA2LzE0MzM3MTkxMDYgYWxsb2MgNTQvMS8xIGNyZWF0IDUwODcvNDk0Ni8y
>Nzc2IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MTQ2LzM5
>NzEvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTE0Ni8xNzMyLzEzIG54cmVhZCAxNDMzNzE5MTQ2LzE0
>MzM3MTkxNDYvMzU2NyB0cnlleGNlcHQgMTMvMi8xIGZvcmsgMTQzMzcxOTE0Ni8xNDMzNzE5MTQ2
>LzI4MzIgZm9ya3Rvb211Y2ggMTQzMzcxOTE0Ni8xNDMzNzE5MTQ2LzE0MzM3MTkxNDYgYWxsb2Mg
>NDEvMTMvNSBjcmVhdCA1MTI3LzQ5ODYvMjgxNiBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVz
>dCB0aHJlYWQgaXMgMTQzMzcxOTE4Mi80MDA3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTkxODIvMTc2
>OC85IG54cmVhZCAxNDMzNzE5MTgyLzE0MzM3MTkxODIvMzYwMyB0cnlleGNlcHQgOC83LzEgZm9y
>ayAxNDMzNzE5MTgyLzE0MzM3MTkxODIvMjg2OCBmb3JrdG9vbXVjaCAxNDMzNzE5MTgyLzE0MzM3
>MTkxODIvMTQzMzcxOTE4MiBhbGxvYyA0OS85LzIgY3JlYXQgNTE2My81MDIyLzI4NTIgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTkyMTgvNDA0My8wICh0ZXN0
>czogcmVhZCAxNDMzNzE5MjE4LzE4MDQvMTkgbnhyZWFkIDE0MzM3MTkyMTgvMTQzMzcxOTIxOC8z
>NjM5IHRyeWV4Y2VwdCAyMi81LzEgZm9yayAxNDMzNzE5MjE4LzE0MzM3MTkyMTgvMjkwNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE5MjE4LzE0MzM3MTkyMTgvMTQzMzcxOTIxOCBhbGxvYyA2OC8xMS8zIGNy
>ZWF0IDUxOTkvNTA1OC8yODg4IGxvY2sgNC8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE5MjQ1LzQwNzAvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTI0NS8xODMxLzE2IG54cmVh
>ZCAxNDMzNzE5MjQ1LzE0MzM3MTkyNDUvMzY2NiB0cnlleGNlcHQgNDgvMi8wIGZvcmsgMTQzMzcx
>OTI0NS8xNDMzNzE5MjQ1LzI5MzEgZm9ya3Rvb211Y2ggMTQzMzcxOTI0NS8xNDMzNzE5MjQ1LzE0
>MzM3MTkyNDUgYWxsb2MgNDIvOS8xIGNyZWF0IDUyMjYvNTA4NS8yOTE1IGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MjczLzQwOTgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTI3My8xODU5LzMgbnhyZWFkIDE0MzM3MTkyNzMvMTQzMzcxOTI3My8zNjk0IHRyeWV4
>Y2VwdCA3LzIvMSBmb3JrIDE0MzM3MTkyNzMvMTQzMzcxOTI3My8yOTU5IGZvcmt0b29tdWNoIDE0
>MzM3MTkyNzMvMTQzMzcxOTI3My8xNDMzNzE5MjczIGFsbG9jIDU1LzgvMCBjcmVhdCA1MjU0LzUx
>MTMvMjk0MyBsb2NrIDMvMy8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTI5
>NS80MTIwLzAgKHRlc3RzOiByZWFkIDE0MzM3MTkyOTUvMTg4MS82IG54cmVhZCAxNDMzNzE5Mjk1
>LzE0MzM3MTkyOTUvMzcxNiB0cnlleGNlcHQgMTUvMi8wIGZvcmsgMTQzMzcxOTI5NS8xNDMzNzE5
>Mjk1LzI5ODEgZm9ya3Rvb211Y2ggMTQzMzcxOTI5NS8xNDMzNzE5Mjk1LzE0MzM3MTkyOTUgYWxs
>b2MgMjIvNi8xIGNyZWF0IDUyNzYvNTEzNS8yOTY1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzE5MzQ4LzQxNzMvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTM0OC8x
>OTM0LzQ5IG54cmVhZCAxNDMzNzE5MzQ4LzE0MzM3MTkzNDgvMzc2OSB0cnlleGNlcHQgNi8yLzIg
>Zm9yayAxNDMzNzE5MzQ4LzE0MzM3MTkzNDgvMzAzNCBmb3JrdG9vbXVjaCAxNDMzNzE5MzQ4LzE0
>MzM3MTkzNDgvMTQzMzcxOTM0OCBhbGxvYyA2Mi8xNS83IGNyZWF0IDUzMjkvNTE4OC8zMDE4IGxv
>Y2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5MzcxLzQxOTYvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcxOTM3MS8xOTU3LzggbnhyZWFkIDE0MzM3MTkzNzEvMTQzMzcxOTM3
>MS8zNzkyIHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MTkzNzEvMTQzMzcxOTM3MS8zMDU3IGZv
>cmt0b29tdWNoIDE0MzM3MTkzNzEvMTQzMzcxOTM3MS8xNDMzNzE5MzcxIGFsbG9jIDYxLzgvMSBj
>cmVhdCA1MzUyLzUyMTEvMzA0MSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxOTQwMy80MjI4LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk0MDMvMTk4OS84IG54cmVh
>ZCAxNDMzNzE5NDAzLzE0MzM3MTk0MDMvMzgyNCB0cnlleGNlcHQgNS8yLzEgZm9yayAxNDMzNzE5
>NDAzLzE0MzM3MTk0MDMvMzA4OSBmb3JrdG9vbXVjaCAxNDMzNzE5NDAzLzE0MzM3MTk0MDMvMTQz
>MzcxOTQwMyBhbGxvYyA4OC8xNy84IGNyZWF0IDUzODQvNTI0My8zMDczIGxvY2sgNi8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NDMyLzQyNTcvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTQzMi8yMDE4LzggbnhyZWFkIDE0MzM3MTk0MzIvMTQzMzcxOTQzMi8zODUzIHRyeWV4
>Y2VwdCA0LzIvMCBmb3JrIDE0MzM3MTk0MzIvMTQzMzcxOTQzMi8zMTE4IGZvcmt0b29tdWNoIDE0
>MzM3MTk0MzIvMTQzMzcxOTQzMi8xNDMzNzE5NDMyIGFsbG9jIDM3LzEvMSBjcmVhdCA1NDEzLzUy
>NzIvMzEwMiBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTQ2
>OS80Mjk0LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk0NjkvMjA1NS8xIG54cmVhZCAxNDMzNzE5NDY5
>LzE0MzM3MTk0NjkvMzg5MCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzE5NDY5LzE0MzM3MTk0
>NjkvMzE1NSBmb3JrdG9vbXVjaCAxNDMzNzE5NDY5LzE0MzM3MTk0NjkvMTQzMzcxOTQ2OSBhbGxv
>YyA1MC8xLzEgY3JlYXQgNTQ1MC81MzA5LzMxMzkgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MTk1MTMvNDMzOC8wICh0ZXN0czogcmVhZCAxNDMzNzE5NTEzLzIw
>OTkvMTcgbnhyZWFkIDE0MzM3MTk1MTMvMTQzMzcxOTUxMy8zOTM0IHRyeWV4Y2VwdCAzLzMvMCBm
>b3JrIDE0MzM3MTk1MTMvMTQzMzcxOTUxMy8zMTk5IGZvcmt0b29tdWNoIDE0MzM3MTk1MTMvMTQz
>MzcxOTUxMy8xNDMzNzE5NTEzIGFsbG9jIDIyLzYvMSBjcmVhdCA1NDk0LzUzNTMvMzE4MyBsb2Nr
>IDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTU0MS80MzY2LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MTk1NDEvMjEyNy8zIG54cmVhZCAxNDMzNzE5NTQxLzE0MzM3MTk1NDEv
>Mzk2MiB0cnlleGNlcHQgMTEvOC8yIGZvcmsgMTQzMzcxOTU0MS8xNDMzNzE5NTQxLzMyMjcgZm9y
>a3Rvb211Y2ggMTQzMzcxOTU0MS8xNDMzNzE5NTQxLzE0MzM3MTk1NDEgYWxsb2MgMzQvMTAvMCBj
>cmVhdCA1NTIyLzUzODEvMzIxMSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcxOTU2Mi80Mzg3LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk1NjIvMjE0OC8yNCBueHJl
>YWQgMTQzMzcxOTU2Mi8xNDMzNzE5NTYyLzM5ODMgdHJ5ZXhjZXB0IDI5LzMvMCBmb3JrIDE0MzM3
>MTk1NjIvMTQzMzcxOTU2Mi8zMjQ4IGZvcmt0b29tdWNoIDE0MzM3MTk1NjIvMTQzMzcxOTU2Mi8x
>NDMzNzE5NTYyIGFsbG9jIDMxLzE1LzEgY3JlYXQgNTU0My81NDAyLzMyMzIgbG9jayAxLzEvMSkK
>Li4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MTk1OTgvNDQyMy8wICh0ZXN0czogcmVh
>ZCAxNDMzNzE5NTk4LzIxODQvMjMgbnhyZWFkIDE0MzM3MTk1OTgvMTQzMzcxOTU5OC80MDE5IHRy
>eWV4Y2VwdCA3LzMvMiBmb3JrIDE0MzM3MTk1OTgvMTQzMzcxOTU5OC8zMjg0IGZvcmt0b29tdWNo
>IDE0MzM3MTk1OTgvMTQzMzcxOTU5OC8xNDMzNzE5NTk4IGFsbG9jIDUxLzI3LzYgY3JlYXQgNTU3
>OS81NDM4LzMyNjggbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MTk2MjkvNDQ1NC8wICh0ZXN0czogcmVhZCAxNDMzNzE5NjI5LzIyMTUvMTEgbnhyZWFkIDE0MzM3
>MTk2MjkvMTQzMzcxOTYyOS80MDUwIHRyeWV4Y2VwdCAzMy8yLzIgZm9yayAxNDMzNzE5NjI5LzE0
>MzM3MTk2MjkvMzMxNSBmb3JrdG9vbXVjaCAxNDMzNzE5NjI5LzE0MzM3MTk2MjkvMTQzMzcxOTYy
>OSBhbGxvYyA2OC8xNi82IGNyZWF0IDU2MTAvNTQ2OS8zMjk5IGxvY2sgMC8wLzApCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NjUyLzQ0NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcx
>OTY1Mi8yMjM4LzcgbnhyZWFkIDE0MzM3MTk2NTIvMTQzMzcxOTY1Mi80MDczIHRyeWV4Y2VwdCAx
>NS8zLzIgZm9yayAxNDMzNzE5NjUyLzE0MzM3MTk2NTIvMzMzOCBmb3JrdG9vbXVjaCAxNDMzNzE5
>NjUyLzE0MzM3MTk2NTIvMTQzMzcxOTY1MiBhbGxvYyAyMy8xNy83IGNyZWF0IDU2MzMvNTQ5Mi8z
>MzIyIGxvY2sgNi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NjkzLzQ1
>MTgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTY5My8yMjc5LzUgbnhyZWFkIDE0MzM3MTk2OTMvMTQz
>MzcxOTY5My80MTE0IHRyeWV4Y2VwdCA1Ni8yLzEgZm9yayAxNDMzNzE5NjkzLzE0MzM3MTk2OTMv
>MzM3OSBmb3JrdG9vbXVjaCAxNDMzNzE5NjkzLzE0MzM3MTk2OTMvMTQzMzcxOTY5MyBhbGxvYyAz
>MC8xNC81IGNyZWF0IDU2NzQvNTUzMy8zMzYzIGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzE5NzE2LzQ1NDEvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTcxNi8yMzAy
>LzE5IG54cmVhZCAxNDMzNzE5NzE2LzE0MzM3MTk3MTYvNDEzNyB0cnlleGNlcHQgMjAvMy8wIGZv
>cmsgMTQzMzcxOTcxNi8xNDMzNzE5NzE2LzM0MDIgZm9ya3Rvb211Y2ggMTQzMzcxOTcxNi8xNDMz
>NzE5NzE2LzE0MzM3MTk3MTYgYWxsb2MgNTMvOC8wIGNyZWF0IDU2OTcvNTU1Ni8zMzg2IGxvY2sg
>MS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5NzQ4LzQ1NzMvMCAodGVz
>dHM6IHJlYWQgMTQzMzcxOTc0OC8yMzM0LzQgbnhyZWFkIDE0MzM3MTk3NDgvMTQzMzcxOTc0OC80
>MTY5IHRyeWV4Y2VwdCA1Mi8xLzEgZm9yayAxNDMzNzE5NzQ4LzE0MzM3MTk3NDgvMzQzNCBmb3Jr
>dG9vbXVjaCAxNDMzNzE5NzQ4LzE0MzM3MTk3NDgvMTQzMzcxOTc0OCBhbGxvYyA1NS8xNS80IGNy
>ZWF0IDU3MjkvNTU4OC8zNDE4IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzE5NzgzLzQ2MDgvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTc4My8yMzY5LzkgbnhyZWFk
>IDE0MzM3MTk3ODMvMTQzMzcxOTc4My80MjA0IHRyeWV4Y2VwdCA4My8yLzAgZm9yayAxNDMzNzE5
>NzgzLzE0MzM3MTk3ODMvMzQ2OSBmb3JrdG9vbXVjaCAxNDMzNzE5NzgzLzE0MzM3MTk3ODMvMTQz
>MzcxOTc4MyBhbGxvYyA0Mi8xNi8xIGNyZWF0IDU3NjQvNTYyMy8zNDUzIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzE5ODEzLzQ2MzgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcxOTgxMy8yMzk5LzUgbnhyZWFkIDE0MzM3MTk4MTMvMTQzMzcxOTgxMy80MjM0IHRyeWV4
>Y2VwdCAxMTMvMC8wIGZvcmsgMTQzMzcxOTgxMy8xNDMzNzE5ODEzLzM0OTkgZm9ya3Rvb211Y2gg
>MTQzMzcxOTgxMy8xNDMzNzE5ODEzLzE0MzM3MTk4MTMgYWxsb2MgNTYvMTYvMiBjcmVhdCA1Nzk0
>LzU2NTMvMzQ4MyBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcx
>OTg0Ny80NjcyLzAgKHRlc3RzOiByZWFkIDE0MzM3MTk4NDcvMjQzMy82IG54cmVhZCAxNDMzNzE5
>ODQ3LzE0MzM3MTk4NDcvNDI2OCB0cnlleGNlcHQgMjcvMS8wIGZvcmsgMTQzMzcxOTg0Ny8xNDMz
>NzE5ODQ3LzM1MzMgZm9ya3Rvb211Y2ggMTQzMzcxOTg0Ny8xNDMzNzE5ODQ3LzE0MzM3MTk4NDcg
>YWxsb2MgNDUvNi8yIGNyZWF0IDU4MjgvNTY4Ny8zNTE3IGxvY2sgMi8yLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzE5ODg4LzQ3MTMvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTg4
>OC8yNDc0LzI3IG54cmVhZCAxNDMzNzE5ODg4LzE0MzM3MTk4ODgvNDMwOSB0cnlleGNlcHQgMTMv
>Mi8yIGZvcmsgMTQzMzcxOTg4OC8xNDMzNzE5ODg4LzM1NzQgZm9ya3Rvb211Y2ggMTQzMzcxOTg4
>OC8xNDMzNzE5ODg4LzE0MzM3MTk4ODggYWxsb2MgNDcvMTcvMCBjcmVhdCA1ODY5LzU3MjgvMzU1
>OCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTkxOS80NzQ0
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MTk5MTkvMjUwNS82IG54cmVhZCAxNDMzNzE5OTE5LzE0MzM3
>MTk5MTkvNDM0MCB0cnlleGNlcHQgNDQvMi8xIGZvcmsgMTQzMzcxOTkxOS8xNDMzNzE5OTE5LzM2
>MDUgZm9ya3Rvb211Y2ggMTQzMzcxOTkxOS8xNDMzNzE5OTE5LzE0MzM3MTk5MTkgYWxsb2MgNDMv
>Ni8wIGNyZWF0IDU5MDAvNTc1OS8zNTg5IGxvY2sgNi82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzE5OTM5LzQ3NjQvMCAodGVzdHM6IHJlYWQgMTQzMzcxOTkzOS8yNTI1LzEx
>IG54cmVhZCAxNDMzNzE5OTM5LzE0MzM3MTk5MzkvNDM2MCB0cnlleGNlcHQgMjEvMi8xIGZvcmsg
>MTQzMzcxOTkzOS8xNDMzNzE5OTM5LzM2MjUgZm9ya3Rvb211Y2ggMTQzMzcxOTkzOS8xNDMzNzE5
>OTM5LzE0MzM3MTk5MzkgYWxsb2MgMzcvMTEvNSBjcmVhdCA1OTIwLzU3NzkvMzYwOSBsb2NrIDAv
>MC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcxOTk2OS80Nzk0LzAgKHRlc3Rz
>OiByZWFkIDE0MzM3MTk5NjkvMjU1NS85IG54cmVhZCAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvNDM5
>MCB0cnlleGNlcHQgNC8xLzEgZm9yayAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvMzY1NSBmb3JrdG9v
>bXVjaCAxNDMzNzE5OTY5LzE0MzM3MTk5NjkvMTQzMzcxOTk2OSBhbGxvYyA0MS85LzUgY3JlYXQg
>NTk1MC81ODA5LzM2MzkgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MTk5ODQvNDgwOS8wICh0ZXN0czogcmVhZCAxNDMzNzE5OTg0LzI1NzAvMTUgbnhyZWFkIDE0
>MzM3MTk5ODQvMTQzMzcxOTk4NC80NDA1IHRyeWV4Y2VwdCA3LzcvMCBmb3JrIDE0MzM3MTk5ODQv
>MTQzMzcxOTk4NC8zNjcwIGZvcmt0b29tdWNoIDE0MzM3MTk5ODQvMTQzMzcxOTk4NC8xNDMzNzE5
>OTg0IGFsbG9jIDQ1LzIwLzggY3JlYXQgNTk2NS81ODI0LzM2NTQgbG9jayAxLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjAwMTYvNDg0MS8wICh0ZXN0czogcmVhZCAxNDMz
>NzIwMDE2LzI2MDIvMSBueHJlYWQgMTQzMzcyMDAxNi8xNDMzNzIwMDE2LzQ0MzcgdHJ5ZXhjZXB0
>IDE4LzMvMCBmb3JrIDE0MzM3MjAwMTYvMTQzMzcyMDAxNi8zNzAyIGZvcmt0b29tdWNoIDE0MzM3
>MjAwMTYvMTQzMzcyMDAxNi8xNDMzNzIwMDE2IGFsbG9jIDU2LzkvMSBjcmVhdCA1OTk3LzU4NTYv
>MzY4NiBsb2NrIDEvMS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDA1Mi80
>ODc3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjAwNTIvMjYzOC8xMCBueHJlYWQgMTQzMzcyMDA1Mi8x
>NDMzNzIwMDUyLzQ0NzMgdHJ5ZXhjZXB0IDUzLzIvMSBmb3JrIDE0MzM3MjAwNTIvMTQzMzcyMDA1
>Mi8zNzM4IGZvcmt0b29tdWNoIDE0MzM3MjAwNTIvMTQzMzcyMDA1Mi8xNDMzNzIwMDUyIGFsbG9j
>IDQ1LzE4LzYgY3JlYXQgNjAzMy81ODkyLzM3MjIgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjAwNzYvNDkwMS8wICh0ZXN0czogcmVhZCAxNDMzNzIwMDc2LzI2
>NjIvMTEgbnhyZWFkIDE0MzM3MjAwNzYvMTQzMzcyMDA3Ni80NDk3IHRyeWV4Y2VwdCAxMi8xLzAg
>Zm9yayAxNDMzNzIwMDc2LzE0MzM3MjAwNzYvMzc2MiBmb3JrdG9vbXVjaCAxNDMzNzIwMDc2LzE0
>MzM3MjAwNzYvMTQzMzcyMDA3NiBhbGxvYyA1NS8xLzEgY3JlYXQgNjA1Ny81OTE2LzM3NDYgbG9j
>ayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjAxMDgvNDkzMy8wICh0
>ZXN0czogcmVhZCAxNDMzNzIwMTA4LzI2OTQvNSBueHJlYWQgMTQzMzcyMDEwOC8xNDMzNzIwMTA4
>LzQ1MjkgdHJ5ZXhjZXB0IDE2LzIvMCBmb3JrIDE0MzM3MjAxMDgvMTQzMzcyMDEwOC8zNzk0IGZv
>cmt0b29tdWNoIDE0MzM3MjAxMDgvMTQzMzcyMDEwOC8xNDMzNzIwMTA4IGFsbG9jIDMzLzkvMSBj
>cmVhdCA2MDg5LzU5NDgvMzc3OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMDE0My80OTY4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjAxNDMvMjcyOS8yNCBueHJl
>YWQgMTQzMzcyMDE0My8xNDMzNzIwMTQzLzQ1NjQgdHJ5ZXhjZXB0IDkvMi8wIGZvcmsgMTQzMzcy
>MDE0My8xNDMzNzIwMTQzLzM4MjkgZm9ya3Rvb211Y2ggMTQzMzcyMDE0My8xNDMzNzIwMTQzLzE0
>MzM3MjAxNDMgYWxsb2MgNTYvMTAvMSBjcmVhdCA2MTI0LzU5ODMvMzgxMyBsb2NrIDAvMC8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDE4NS81MDEwLzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjAxODUvMTk0MS84IG54cmVhZCAxNDMzNzIwMTg1LzE0MzM3MjAxODUvNDYwNiB0cnll
>eGNlcHQgMjIvMC8wIGZvcmsgMTQzMzcyMDE4NS8xNDMzNzIwMTg1LzM4NzEgZm9ya3Rvb211Y2gg
>MTQzMzcyMDE4NS8xNDMzNzIwMTg1LzE0MzM3MjAxODUgYWxsb2MgMzkvMTMvMyBjcmVhdCA2MTY2
>LzYwMjUvMzg1NSBsb2NrIDMvMi8yKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcy
>MDIxOC81MDQzLzAgKHRlc3RzOiByZWFkIDE0MzM3MjAyMTgvMTk3NC8xMiBueHJlYWQgMTQzMzcy
>MDIxOC8xNDMzNzIwMjE4LzQ2MzkgdHJ5ZXhjZXB0IDQvMi8wIGZvcmsgMTQzMzcyMDIxOC8xNDMz
>NzIwMjE4LzM5MDQgZm9ya3Rvb211Y2ggMTQzMzcyMDIxOC8xNDMzNzIwMjE4LzE0MzM3MjAyMTgg
>YWxsb2MgMTgvNy8xIGNyZWF0IDYxOTkvNjA1OC8zODg4IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIwMjYzLzUwODgvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDI2
>My8yMDE5LzQgbnhyZWFkIDE0MzM3MjAyNjMvMTQzMzcyMDI2My80Njg0IHRyeWV4Y2VwdCAxMy8y
>LzEgZm9yayAxNDMzNzIwMjYzLzE0MzM3MjAyNjMvMzk0OSBmb3JrdG9vbXVjaCAxNDMzNzIwMjYz
>LzE0MzM3MjAyNjMvMTQzMzcyMDI2MyBhbGxvYyA1Ny8xNC80IGNyZWF0IDYyNDQvNjEwMy8zOTMz
>IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwMzA1LzUxMzAv
>MCAodGVzdHM6IHJlYWQgMTQzMzcyMDMwNS8yMDYxLzExIG54cmVhZCAxNDMzNzIwMzA1LzE0MzM3
>MjAzMDUvNDcyNiB0cnlleGNlcHQgNS81LzAgZm9yayAxNDMzNzIwMzA1LzE0MzM3MjAzMDUvMzk5
>MSBmb3JrdG9vbXVjaCAxNDMzNzIwMzA1LzE0MzM3MjAzMDUvMTQzMzcyMDMwNSBhbGxvYyAzMi8x
>Ni81IGNyZWF0IDYyODYvNjE0NS8zOTc1IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIwMzM1LzUxNjAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDMzNS8yMDkxLzIg
>bnhyZWFkIDE0MzM3MjAzMzUvMTQzMzcyMDMzNS80NzU2IHRyeWV4Y2VwdCAxNy8zLzAgZm9yayAx
>NDMzNzIwMzM1LzE0MzM3MjAzMzUvNDAyMSBmb3JrdG9vbXVjaCAxNDMzNzIwMzM1LzE0MzM3MjAz
>MzUvMTQzMzcyMDMzNSBhbGxvYyA0MS8xMC8yIGNyZWF0IDYzMTYvNjE3NS80MDA1IGxvY2sgMi8x
>LzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNDE1LzUxOTYvMCAodGVzdHM6
>IHJlYWQgMTQzMzcyMDQxNS8yMDUxLzE2IG54cmVhZCAxNDMzNzIwNDE1LzE0MzM3MjA0MTUvNDgz
>NiB0cnlleGNlcHQgMTgvMi8yIGZvcmsgMTQzMzcyMDQxNS8xNDMzNzIwNDE1LzQxMDEgZm9ya3Rv
>b211Y2ggMTQzMzcyMDQxNS8xNDMzNzIwNDE1LzE0MzM3MjA0MTUgYWxsb2MgNDkvMjUvNCBjcmVh
>dCA2Mzk2LzYyNTUvNDA4NSBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMDQ0NS81MjA4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA0NDUvMTQyOC80IG54cmVhZCAx
>NDMzNzIwNDQ1LzE0MzM3MjA0NDUvNDg2NiB0cnlleGNlcHQgNDMvMi8xIGZvcmsgMTQzMzcyMDQ0
>NS8xNDMzNzIwNDQ1LzQxMzEgZm9ya3Rvb211Y2ggMTQzMzcyMDQ0NS8xNDMzNzIwNDQ1LzE0MzM3
>MjA0NDUgYWxsb2MgMzAvOC80IGNyZWF0IDY0MjYvNjI4NS80MTE1IGxvY2sgMC8wLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNDczLzUyMzYvMCAodGVzdHM6IHJlYWQgMTQz
>MzcyMDQ3My8xNDU2LzE2IG54cmVhZCAxNDMzNzIwNDczLzE0MzM3MjA0NzMvNDg5NCB0cnlleGNl
>cHQgNDIvMS8wIGZvcmsgMTQzMzcyMDQ3My8xNDMzNzIwNDczLzQxNTkgZm9ya3Rvb211Y2ggMTQz
>MzcyMDQ3My8xNDMzNzIwNDczLzE0MzM3MjA0NzMgYWxsb2MgNTgvMTYvMSBjcmVhdCA2NDU0LzYz
>MTMvNDE0MyBsb2NrIDEvMS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDUw
>OC81MjcxLzAgKHRlc3RzOiByZWFkIDE0MzM3MjA1MDgvMTQ5MS8xIG54cmVhZCAxNDMzNzIwNTA4
>LzE0MzM3MjA1MDgvNDkyOSB0cnlleGNlcHQgMTkvMi8wIGZvcmsgMTQzMzcyMDUwOC8xNDMzNzIw
>NTA4LzQxOTQgZm9ya3Rvb211Y2ggMTQzMzcyMDUwOC8xNDMzNzIwNTA4LzE0MzM3MjA1MDggYWxs
>b2MgNjcvMTMvMSBjcmVhdCA2NDg5LzYzNDgvNDE3OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDU1Ni81MzE5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA1NTYv
>MTUzOS8xIG54cmVhZCAxNDMzNzIwNTU2LzE0MzM3MjA1NTYvNDk3NyB0cnlleGNlcHQgMTgvMi8w
>IGZvcmsgMTQzMzcyMDU1Ni8xNDMzNzIwNTU2LzQyNDIgZm9ya3Rvb211Y2ggMTQzMzcyMDU1Ni8x
>NDMzNzIwNTU2LzE0MzM3MjA1NTYgYWxsb2MgMjYvNC8xIGNyZWF0IDY1MzcvNjM5Ni80MjI2IGxv
>Y2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNTg0LzUzNDcvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMDU4NC8xNTY3LzcgbnhyZWFkIDE0MzM3MjA1ODQvMTQzMzcyMDU4
>NC81MDA1IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MjA1ODQvMTQzMzcyMDU4NC80MjcwIGZv
>cmt0b29tdWNoIDE0MzM3MjA1ODQvMTQzMzcyMDU4NC8xNDMzNzIwNTg0IGFsbG9jIDMyLzcvMSBj
>cmVhdCA2NTY1LzY0MjQvNDI1NCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMDY0NS81NDA4LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA2NDUvMTYyOC82IG54cmVh
>ZCAxNDMzNzIwNjQ1LzE0MzM3MjA2NDUvNTA2NiB0cnlleGNlcHQgMTQvMi8xIGZvcmsgMTQzMzcy
>MDY0NS8xNDMzNzIwNjQ1LzQzMzEgZm9ya3Rvb211Y2ggMTQzMzcyMDY0NS8xNDMzNzIwNjQ1LzE0
>MzM3MjA2NDUgYWxsb2MgNDAvMTMvNiBjcmVhdCA2NjI2LzY0ODUvNDMxNSBsb2NrIDUvNS8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDY4MC81NDQzLzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjA2ODAvMTY2My8zNSBueHJlYWQgMTQzMzcyMDY4MC8xNDMzNzIwNjgwLzUxMDEgdHJ5
>ZXhjZXB0IDEvMS8xIGZvcmsgMTQzMzcyMDY4MC8xNDMzNzIwNjgwLzQzNjYgZm9ya3Rvb211Y2gg
>MTQzMzcyMDY4MC8xNDMzNzIwNjgwLzE0MzM3MjA2ODAgYWxsb2MgNzUvMTMvMiBjcmVhdCA2NjYx
>LzY1MjAvNDM1MCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcy
>MDcxNC81NDc3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA3MTQvMTY5Ny8xMiBueHJlYWQgMTQzMzcy
>MDcxNC8xNDMzNzIwNzE0LzUxMzUgdHJ5ZXhjZXB0IDQvMi8wIGZvcmsgMTQzMzcyMDcxNC8xNDMz
>NzIwNzE0LzQ0MDAgZm9ya3Rvb211Y2ggMTQzMzcyMDcxNC8xNDMzNzIwNzE0LzE0MzM3MjA3MTQg
>YWxsb2MgMzQvMS8xIGNyZWF0IDY2OTUvNjU1NC80Mzg0IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIwNzQxLzU1MDQvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDc0
>MS8xNzI0LzIgbnhyZWFkIDE0MzM3MjA3NDEvMTQzMzcyMDc0MS81MTYyIHRyeWV4Y2VwdCA0LzAv
>MCBmb3JrIDE0MzM3MjA3NDEvMTQzMzcyMDc0MS80NDI3IGZvcmt0b29tdWNoIDE0MzM3MjA3NDEv
>MTQzMzcyMDc0MS8xNDMzNzIwNzQxIGFsbG9jIDM5LzIvMiBjcmVhdCA2NzIyLzY1ODEvNDQxMSBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDc2NS81NTI4LzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjA3NjUvMTc0OC81IG54cmVhZCAxNDMzNzIwNzY1LzE0MzM3MjA3
>NjUvNTE4NiB0cnlleGNlcHQgNC8wLzAgZm9yayAxNDMzNzIwNzY1LzE0MzM3MjA3NjUvNDQ1MSBm
>b3JrdG9vbXVjaCAxNDMzNzIwNzY1LzE0MzM3MjA3NjUvMTQzMzcyMDc2NSBhbGxvYyAzNy8xNS8z
>IGNyZWF0IDY3NDYvNjYwNS80NDM1IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIwNzkwLzU1NTMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDc5MC8xNzczLzIyIG54
>cmVhZCAxNDMzNzIwNzkwLzE0MzM3MjA3OTAvNTIxMSB0cnlleGNlcHQgNS8xLzAgZm9yayAxNDMz
>NzIwNzkwLzE0MzM3MjA3OTAvNDQ3NiBmb3JrdG9vbXVjaCAxNDMzNzIwNzkwLzE0MzM3MjA3OTAv
>MTQzMzcyMDc5MCBhbGxvYyAzMC8xMS8yIGNyZWF0IDY3NzEvNjYzMC80NDYwIGxvY2sgMS8xLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIwODI1LzU1ODgvMCAodGVzdHM6IHJl
>YWQgMTQzMzcyMDgyNS8xODA4LzI0IG54cmVhZCAxNDMzNzIwODI1LzE0MzM3MjA4MjUvNTI0NiB0
>cnlleGNlcHQgNS8xLzEgZm9yayAxNDMzNzIwODI1LzE0MzM3MjA4MjUvNDUxMSBmb3JrdG9vbXVj
>aCAxNDMzNzIwODI1LzE0MzM3MjA4MjUvMTQzMzcyMDgyNSBhbGxvYyA0Ni8xNS82IGNyZWF0IDY4
>MDYvNjY2NS80NDk1IGxvY2sgNS81LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIwODUzLzU2MTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMDg1My8xODM2LzEgbnhyZWFkIDE0MzM3
>MjA4NTMvMTQzMzcyMDg1My81Mjc0IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjA4NTMvMTQz
>MzcyMDg1My80NTM5IGZvcmt0b29tdWNoIDE0MzM3MjA4NTMvMTQzMzcyMDg1My8xNDMzNzIwODUz
>IGFsbG9jIDE2LzYvMSBjcmVhdCA2ODM0LzY2OTMvNDUyMyBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMDg4Mi81NjQ1LzAgKHRlc3RzOiByZWFkIDE0MzM3MjA4
>ODIvMTg2NS8xIG54cmVhZCAxNDMzNzIwODgyLzE0MzM3MjA4ODIvNTMwMyB0cnlleGNlcHQgMy8y
>LzAgZm9yayAxNDMzNzIwODgyLzE0MzM3MjA4ODIvNDU2OCBmb3JrdG9vbXVjaCAxNDMzNzIwODgy
>LzE0MzM3MjA4ODIvMTQzMzcyMDg4MiBhbGxvYyAzMC82LzEgY3JlYXQgNjg2My82NzIyLzQ1NTIg
>bG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjA5MjEvNTY4NC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIwOTIxLzE5MDQvMSBueHJlYWQgMTQzMzcyMDkyMS8xNDMzNzIw
>OTIxLzUzNDIgdHJ5ZXhjZXB0IDE0LzIvMCBmb3JrIDE0MzM3MjA5MjEvMTQzMzcyMDkyMS80NjA3
>IGZvcmt0b29tdWNoIDE0MzM3MjA5MjEvMTQzMzcyMDkyMS8xNDMzNzIwOTIxIGFsbG9jIDQ1LzE3
>LzEgY3JlYXQgNjkwMi82NzYxLzQ1OTEgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MjA5NDYvNTcwOS8wICh0ZXN0czogcmVhZCAxNDMzNzIwOTQ2LzE5MjkvMTEg
>bnhyZWFkIDE0MzM3MjA5NDYvMTQzMzcyMDk0Ni81MzY3IHRyeWV4Y2VwdCAzOS8zLzAgZm9yayAx
>NDMzNzIwOTQ2LzE0MzM3MjA5NDYvNDYzMiBmb3JrdG9vbXVjaCAxNDMzNzIwOTQ2LzE0MzM3MjA5
>NDYvMTQzMzcyMDk0NiBhbGxvYyAyNi8xLzEgY3JlYXQgNjkyNy82Nzg2LzQ2MTYgbG9jayAxLzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjA5NzUvNTczOC8wICh0ZXN0czog
>cmVhZCAxNDMzNzIwOTc1LzE5NTgvMjYgbnhyZWFkIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS81Mzk2
>IHRyeWV4Y2VwdCA0LzIvMCBmb3JrIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS80NjYxIGZvcmt0b29t
>dWNoIDE0MzM3MjA5NzUvMTQzMzcyMDk3NS8xNDMzNzIwOTc1IGFsbG9jIDI2LzEwLzEgY3JlYXQg
>Njk1Ni82ODE1LzQ2NDUgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjA5OTQvNTc1Ny8wICh0ZXN0czogcmVhZCAxNDMzNzIwOTk0LzE5NzcvMTYgbnhyZWFkIDE0
>MzM3MjA5OTQvMTQzMzcyMDk5NC81NDE1IHRyeWV4Y2VwdCAyMy8yLzEgZm9yayAxNDMzNzIwOTk0
>LzE0MzM3MjA5OTQvNDY4MCBmb3JrdG9vbXVjaCAxNDMzNzIwOTk0LzE0MzM3MjA5OTQvMTQzMzcy
>MDk5NCBhbGxvYyAzNC8xMC8yIGNyZWF0IDY5NzUvNjgzNC80NjY0IGxvY2sgMy8zLzApCi4uLi4u
>Li4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxMDE2LzU3NzkvMCAodGVzdHM6IHJlYWQgMTQz
>MzcyMTAxNi8xOTk5LzIgbnhyZWFkIDE0MzM3MjEwMTYvMTQzMzcyMTAxNi81NDM3IHRyeWV4Y2Vw
>dCA0LzQvMCBmb3JrIDE0MzM3MjEwMTYvMTQzMzcyMTAxNi80NzAyIGZvcmt0b29tdWNoIDE0MzM3
>MjEwMTYvMTQzMzcyMTAxNi8xNDMzNzIxMDE2IGFsbG9jIDU2LzEwLzIgY3JlYXQgNjk5Ny82ODU2
>LzQ2ODYgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEwODAv
>NTg0My8wICh0ZXN0czogcmVhZCAxNDMzNzIxMDgwLzc0Ny8yIG54cmVhZCAxNDMzNzIxMDgwLzE0
>MzM3MjEwODAvNTUwMSB0cnlleGNlcHQgMy8xLzAgZm9yayAxNDMzNzIxMDgwLzE0MzM3MjEwODAv
>NDc2NiBmb3JrdG9vbXVjaCAxNDMzNzIxMDgwLzE0MzM3MjEwODAvMTQzMzcyMTA4MCBhbGxvYyA0
>Ni8zLzIgY3JlYXQgNzA2MS82OTIwLzQ3NTAgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MjExMDYvNTg2OS8wICh0ZXN0czogcmVhZCAxNDMzNzIxMTA2Lzc3My8x
>NyBueHJlYWQgMTQzMzcyMTEwNi8xNDMzNzIxMTA2LzU1MjcgdHJ5ZXhjZXB0IDE4LzEvMSBmb3Jr
>IDE0MzM3MjExMDYvMTQzMzcyMTEwNi80NzkyIGZvcmt0b29tdWNoIDE0MzM3MjExMDYvMTQzMzcy
>MTEwNi8xNDMzNzIxMTA2IGFsbG9jIDQ3LzEzLzAgY3JlYXQgNzA4Ny82OTQ2LzQ3NzYgbG9jayAy
>LzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjExNDEvNTkwNC8wICh0ZXN0
>czogcmVhZCAxNDMzNzIxMTQxLzgwOC8xNyBueHJlYWQgMTQzMzcyMTE0MS8xNDMzNzIxMTQxLzU1
>NjIgdHJ5ZXhjZXB0IDI2LzAvMCBmb3JrIDE0MzM3MjExNDEvMTQzMzcyMTE0MS80ODI3IGZvcmt0
>b29tdWNoIDE0MzM3MjExNDEvMTQzMzcyMTE0MS8xNDMzNzIxMTQxIGFsbG9jIDU2LzExLzEgY3Jl
>YXQgNzEyMi82OTgxLzQ4MTEgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MjExNzQvNTkzNy8wICh0ZXN0czogcmVhZCAxNDMzNzIxMTc0Lzg0MS8xMCBueHJlYWQg
>MTQzMzcyMTE3NC8xNDMzNzIxMTc0LzU1OTUgdHJ5ZXhjZXB0IDEyLzIvMSBmb3JrIDE0MzM3MjEx
>NzQvMTQzMzcyMTE3NC80ODYwIGZvcmt0b29tdWNoIDE0MzM3MjExNzQvMTQzMzcyMTE3NC8xNDMz
>NzIxMTc0IGFsbG9jIDYwLzIwLzAgY3JlYXQgNzE1NS83MDE0LzQ4NDQgbG9jayAzLzMvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEyMDIvNTk2NS8wICh0ZXN0czogcmVhZCAx
>NDMzNzIxMjAyLzg2OS8zOCBueHJlYWQgMTQzMzcyMTIwMi8xNDMzNzIxMjAyLzU2MjMgdHJ5ZXhj
>ZXB0IDM2LzMvMCBmb3JrIDE0MzM3MjEyMDIvMTQzMzcyMTIwMi80ODg4IGZvcmt0b29tdWNoIDE0
>MzM3MjEyMDIvMTQzMzcyMTIwMi8xNDMzNzIxMjAyIGFsbG9jIDU4LzIwLzIgY3JlYXQgNzE4My83
>MDQyLzQ4NzIgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEy
>MzAvNTk5My8wICh0ZXN0czogcmVhZCAxNDMzNzIxMjMwLzg5Ny8xNSBueHJlYWQgMTQzMzcyMTIz
>MC8xNDMzNzIxMjMwLzU2NTEgdHJ5ZXhjZXB0IDMxLzIvMCBmb3JrIDE0MzM3MjEyMzAvMTQzMzcy
>MTIzMC80OTE2IGZvcmt0b29tdWNoIDE0MzM3MjEyMzAvMTQzMzcyMTIzMC8xNDMzNzIxMjMwIGFs
>bG9jIDg2LzE1LzEgY3JlYXQgNzIxMS83MDcwLzQ5MDAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MjEyNTYvNjAxOS8wICh0ZXN0czogcmVhZCAxNDMzNzIxMjU2
>LzkyMy81IG54cmVhZCAxNDMzNzIxMjU2LzE0MzM3MjEyNTYvNTY3NyB0cnlleGNlcHQgMTQvMi8x
>IGZvcmsgMTQzMzcyMTI1Ni8xNDMzNzIxMjU2LzQ5NDIgZm9ya3Rvb211Y2ggMTQzMzcyMTI1Ni8x
>NDMzNzIxMjU2LzE0MzM3MjEyNTYgYWxsb2MgNDUvMTMvNSBjcmVhdCA3MjM3LzcwOTYvNDkyNiBs
>b2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTI4MC82MDQzLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjEyODAvOTQ3LzEgbnhyZWFkIDE0MzM3MjEyODAvMTQzMzcyMTI4
>MC8xIHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjEyODAvMTQzMzcyMTI4MC80OTY2IGZvcmt0
>b29tdWNoIDE0MzM3MjEyODAvMTQzMzcyMTI4MC8xNDMzNzIxMjgwIGFsbG9jIDUxLzEvMSBjcmVh
>dCA3MjYxLzcxMjAvNDk1MCBsb2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMTMwNC82MDY3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjEzMDQvOTcxLzI1IG54cmVhZCAx
>NDMzNzIxMzA0LzE0MzM3MjEzMDQvMTQgdHJ5ZXhjZXB0IDQvMC8wIGZvcmsgMTQzMzcyMTMwNC8x
>NDMzNzIxMzA0LzQ5OTAgZm9ya3Rvb211Y2ggMTQzMzcyMTMwNC8xNDMzNzIxMzA0LzE0MzM3MjEz
>MDQgYWxsb2MgMjUvNC8yIGNyZWF0IDcyODUvNzE0NC80OTc0IGxvY2sgNC8yLzIpCi4uLi4uLi4u
>Li5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxMzM4LzYxMDEvMCAodGVzdHM6IHJlYWQgMTQzMzcy
>MTMzOC8xMDA1LzU5IG54cmVhZCAxNDMzNzIxMzM4LzE0MzM3MjEzMzgvNDggdHJ5ZXhjZXB0IDMw
>LzIvMCBmb3JrIDE0MzM3MjEzMzgvMTQzMzcyMTMzOC81MDI0IGZvcmt0b29tdWNoIDE0MzM3MjEz
>MzgvMTQzMzcyMTMzOC8xNDMzNzIxMzM4IGFsbG9jIDQzLzExLzAgY3JlYXQgNzMxOS83MTc4LzUw
>MDggbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjEzODMvNjE0
>Ni8wICh0ZXN0czogcmVhZCAxNDMzNzIxMzgzLzEwNTAvNCBueHJlYWQgMTQzMzcyMTM4My8xNDMz
>NzIxMzgzLzkzIHRyeWV4Y2VwdCAxNC8yLzEgZm9yayAxNDMzNzIxMzgzLzE0MzM3MjEzODMvNTA2
>OSBmb3JrdG9vbXVjaCAxNDMzNzIxMzgzLzE0MzM3MjEzODMvMTQzMzcyMTM4MyBhbGxvYyA0NS8x
>Ny80IGNyZWF0IDczNjQvNzIyMy81MDUzIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIxNDE4LzYxODEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTQxOC8xMDg1Lzcg
>bnhyZWFkIDE0MzM3MjE0MTgvMTQzMzcyMTQxOC8xMjggdHJ5ZXhjZXB0IDIyLzEvMCBmb3JrIDE0
>MzM3MjE0MTgvMTQzMzcyMTQxOC81MTA0IGZvcmt0b29tdWNoIDE0MzM3MjE0MTgvMTQzMzcyMTQx
>OC8xNDMzNzIxNDE4IGFsbG9jIDc2LzI0LzMgY3JlYXQgNzM5OS83MjU4LzUwODggbG9jayAxLzEv
>MSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE0NTQvNjIxNy8wICh0ZXN0czog
>cmVhZCAxNDMzNzIxNDU0LzExMjEvMTEgbnhyZWFkIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC8xNjQg
>dHJ5ZXhjZXB0IDI3LzIvMCBmb3JrIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC81MTQwIGZvcmt0b29t
>dWNoIDE0MzM3MjE0NTQvMTQzMzcyMTQ1NC8xNDMzNzIxNDU0IGFsbG9jIDQzLzExLzEgY3JlYXQg
>NzQzNS83Mjk0LzUxMjQgbG9jayAxLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjE0ODkvNjI1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIxNDg5LzExNTYvMiBueHJlYWQgMTQz
>MzcyMTQ4OS8xNDMzNzIxNDg5LzE5OSB0cnlleGNlcHQgNjIvMS8xIGZvcmsgMTQzMzcyMTQ4OS8x
>NDMzNzIxNDg5LzUxNzUgZm9ya3Rvb211Y2ggMTQzMzcyMTQ4OS8xNDMzNzIxNDg5LzE0MzM3MjE0
>ODkgYWxsb2MgNDYvMTEvMiBjcmVhdCA3NDcwLzczMjkvNTE1OSBsb2NrIDIvMC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTUyMy82Mjg2LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MjE1MjMvMTE5MC8yNCBueHJlYWQgMTQzMzcyMTUyMy8xNDMzNzIxNTIzLzIzMyB0cnlleGNlcHQg
>NC8yLzEgZm9yayAxNDMzNzIxNTIzLzE0MzM3MjE1MjMvNTIwOSBmb3JrdG9vbXVjaCAxNDMzNzIx
>NTIzLzE0MzM3MjE1MjMvMTQzMzcyMTUyMyBhbGxvYyAyMC8xMC8wIGNyZWF0IDc1MDQvNzM2My81
>MTkzIGxvY2sgNS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxNTQ3LzYz
>MTAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTU0Ny8xMjE0LzQ4IG54cmVhZCAxNDMzNzIxNTQ3LzE0
>MzM3MjE1NDcvMjU3IHRyeWV4Y2VwdCA0LzIvMSBmb3JrIDE0MzM3MjE1NDcvMTQzMzcyMTU0Ny81
>MjMzIGZvcmt0b29tdWNoIDE0MzM3MjE1NDcvMTQzMzcyMTU0Ny8xNDMzNzIxNTQ3IGFsbG9jIDQ0
>LzE5LzUgY3JlYXQgNzUyOC83Mzg3LzUyMTcgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3Qg
>dGhyZWFkIGlzIDE0MzM3MjE1NjkvNjMzMi8wICh0ZXN0czogcmVhZCAxNDMzNzIxNTY5LzEyMzYv
>OSBueHJlYWQgMTQzMzcyMTU2OS8xNDMzNzIxNTY5LzI3OSB0cnlleGNlcHQgMi8yLzAgZm9yayAx
>NDMzNzIxNTY5LzE0MzM3MjE1NjkvNTI1NSBmb3JrdG9vbXVjaCAxNDMzNzIxNTY5LzE0MzM3MjE1
>NjkvMTQzMzcyMTU2OSBhbGxvYyAxNy85LzEgY3JlYXQgNzU1MC83NDA5LzUyMzkgbG9jayAwLzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE2MDIvNjM2NS8wICh0ZXN0czog
>cmVhZCAxNDMzNzIxNjAyLzEyNjkvMSBueHJlYWQgMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzMxMiB0
>cnlleGNlcHQgMjcvMi8wIGZvcmsgMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzUyODggZm9ya3Rvb211
>Y2ggMTQzMzcyMTYwMi8xNDMzNzIxNjAyLzE0MzM3MjE2MDIgYWxsb2MgNTAvNS8xIGNyZWF0IDc1
>ODMvNzQ0Mi81MjcyIGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIxNjMzLzYzOTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTYzMy8xMzAwLzE1IG54cmVhZCAxNDMz
>NzIxNjMzLzE0MzM3MjE2MzMvMzQzIHRyeWV4Y2VwdCA0MS8yLzAgZm9yayAxNDMzNzIxNjMzLzE0
>MzM3MjE2MzMvNTMxOSBmb3JrdG9vbXVjaCAxNDMzNzIxNjMzLzE0MzM3MjE2MzMvMTQzMzcyMTYz
>MyBhbGxvYyA1MS81LzEgY3JlYXQgNzYxNC83NDczLzUzMDMgbG9jayAwLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjE2NzkvNjQ0Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIx
>Njc5LzEzNDYvMjAgbnhyZWFkIDE0MzM3MjE2NzkvMTQzMzcyMTY3OS8zODkgdHJ5ZXhjZXB0IDE1
>LzEvMSBmb3JrIDE0MzM3MjE2NzkvMTQzMzcyMTY3OS81MzY1IGZvcmt0b29tdWNoIDE0MzM3MjE2
>NzkvMTQzMzcyMTY3OS8xNDMzNzIxNjc5IGFsbG9jIDcwLzkvNCBjcmVhdCA3NjYwLzc1MTkvNTM0
>OSBsb2NrIDQvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTcxOC82NDgx
>LzAgKHRlc3RzOiByZWFkIDE0MzM3MjE3MTgvMTMzMS8xIG54cmVhZCAxNDMzNzIxNzE4LzE0MzM3
>MjE3MTgvNDI4IHRyeWV4Y2VwdCAxMS8zLzAgZm9yayAxNDMzNzIxNzE4LzE0MzM3MjE3MTgvNTQw
>NCBmb3JrdG9vbXVjaCAxNDMzNzIxNzE4LzE0MzM3MjE3MTgvMTQzMzcyMTcxOCBhbGxvYyA0OC8x
>Ny8xIGNyZWF0IDc2OTkvNzU1OC81Mzg4IGxvY2sgMS8xLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIxNzU2LzU0NTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTc1Ni83NDIvOCBu
>eHJlYWQgMTQzMzcyMTc1Ni8xNDMzNzIxNzU2LzQ2NiB0cnlleGNlcHQgMTYvMC8wIGZvcmsgMTQz
>MzcyMTc1Ni8xNDMzNzIxNzU2LzU0NDIgZm9ya3Rvb211Y2ggMTQzMzcyMTc1Ni8xNDMzNzIxNzU2
>LzE0MzM3MjE3NTYgYWxsb2MgNTUvOC8xIGNyZWF0IDc3MzcvNzU5Ni81NDI2IGxvY2sgMS8xLzAp
>Ci4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxNzg4LzU0ODgvMCAodGVzdHM6IHJl
>YWQgMTQzMzcyMTc4OC83NzQvMTAgbnhyZWFkIDE0MzM3MjE3ODgvMTQzMzcyMTc4OC80OTggdHJ5
>ZXhjZXB0IDgvMi8wIGZvcmsgMTQzMzcyMTc4OC8xNDMzNzIxNzg4LzU0NzQgZm9ya3Rvb211Y2gg
>MTQzMzcyMTc4OC8xNDMzNzIxNzg4LzE0MzM3MjE3ODggYWxsb2MgMjgvMS8xIGNyZWF0IDc3Njkv
>NzYyOC81NDU4IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIx
>ODIyLzU1MjIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMTgyMi83NjgvMTQgbnhyZWFkIDE0MzM3MjE4
>MjIvMTQzMzcyMTgyMi81MzIgdHJ5ZXhjZXB0IDIyLzIvMSBmb3JrIDE0MzM3MjE4MjIvMTQzMzcy
>MTgyMi81NTA4IGZvcmt0b29tdWNoIDE0MzM3MjE4MjIvMTQzMzcyMTgyMi8xNDMzNzIxODIyIGFs
>bG9jIDM1LzgvNCBjcmVhdCA3ODAzLzc2NjIvNTQ5MiBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6
>aWVzdCB0aHJlYWQgaXMgMTQzMzcyMTg4Ny81NTg3LzAgKHRlc3RzOiByZWFkIDE0MzM3MjE4ODcv
>MjA4LzE5IG54cmVhZCAxNDMzNzIxODg3LzE0MzM3MjE4ODcvNTk3IHRyeWV4Y2VwdCAyOS8yLzAg
>Zm9yayAxNDMzNzIxODg3LzE0MzM3MjE4ODcvNTU3MyBmb3JrdG9vbXVjaCAxNDMzNzIxODg3LzE0
>MzM3MjE4ODcvMTQzMzcyMTg4NyBhbGxvYyA3OS8xMC8xIGNyZWF0IDc4NjgvNzcyNy81NTU3IGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxOTEyLzU2MTIvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMTkxMi8yMzMvMTIgbnhyZWFkIDE0MzM3MjE5MTIvMTQzMzcyMTkx
>Mi82MjIgdHJ5ZXhjZXB0IDQwLzEvMSBmb3JrIDE0MzM3MjE5MTIvMTQzMzcyMTkxMi81NTk4IGZv
>cmt0b29tdWNoIDE0MzM3MjE5MTIvMTQzMzcyMTkxMi8xNDMzNzIxOTEyIGFsbG9jIDM5LzEyLzAg
>Y3JlYXQgNzg5My83NzUyLzU1ODIgbG9jayA1LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MjE5NTIvNTY1Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIxOTUyLzI3My8xMiBueHJl
>YWQgMTQzMzcyMTk1Mi8xNDMzNzIxOTUyLzY2MiB0cnlleGNlcHQgNi8xLzEgZm9yayAxNDMzNzIx
>OTUyLzE0MzM3MjE5NTIvNTYzOCBmb3JrdG9vbXVjaCAxNDMzNzIxOTUyLzE0MzM3MjE5NTIvMTQz
>MzcyMTk1MiBhbGxvYyA3OS8xMi81IGNyZWF0IDc5MzMvNzc5Mi81NjIyIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIxOTc4LzU2NzgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMTk3OC8yOTkvNiBueHJlYWQgMTQzMzcyMTk3OC8xNDMzNzIxOTc4LzY4OCB0cnlleGNl
>cHQgNy8zLzEgZm9yayAxNDMzNzIxOTc4LzE0MzM3MjE5NzgvNTY2NCBmb3JrdG9vbXVjaCAxNDMz
>NzIxOTc4LzE0MzM3MjE5NzgvMTQzMzcyMTk3OCBhbGxvYyAxMDUvMTYvNiBjcmVhdCA3OTU5Lzc4
>MTgvNTY0OCBsb2NrIDYvNi8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjAw
>OS81NzA5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjIwMDkvMzMwLzI0IG54cmVhZCAxNDMzNzIyMDA5
>LzE0MzM3MjIwMDkvNzE5IHRyeWV4Y2VwdCAzOC8yLzEgZm9yayAxNDMzNzIyMDA5LzE0MzM3MjIw
>MDkvNTY5NSBmb3JrdG9vbXVjaCAxNDMzNzIyMDA5LzE0MzM3MjIwMDkvMTQzMzcyMjAwOSBhbGxv
>YyAyMC84LzUgY3JlYXQgNzk5MC83ODQ5LzU2NzkgbG9jayAzLzMvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjIwMzYvNTczNi8wICh0ZXN0czogcmVhZCAxNDMzNzIyMDM2LzM1
>Ny8xIG54cmVhZCAxNDMzNzIyMDM2LzE0MzM3MjIwMzYvNzQ2IHRyeWV4Y2VwdCAyOS8wLzAgZm9y
>ayAxNDMzNzIyMDM2LzE0MzM3MjIwMzYvNTcyMiBmb3JrdG9vbXVjaCAxNDMzNzIyMDM2LzE0MzM3
>MjIwMzYvMTQzMzcyMjAzNiBhbGxvYyAzNS8xMS8xIGNyZWF0IDgwMTcvNzg3Ni81NzA2IGxvY2sg
>MS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMDYxLzU3NjEvMCAodGVz
>dHM6IHJlYWQgMTQzMzcyMjA2MS8zODIvMTkgbnhyZWFkIDE0MzM3MjIwNjEvMTQzMzcyMjA2MS83
>NzEgdHJ5ZXhjZXB0IDYvMS8wIGZvcmsgMTQzMzcyMjA2MS8xNDMzNzIyMDYxLzU3NDcgZm9ya3Rv
>b211Y2ggMTQzMzcyMjA2MS8xNDMzNzIyMDYxLzE0MzM3MjIwNjEgYWxsb2MgNjAvMjIvMyBjcmVh
>dCA4MDQyLzc5MDEvNTczMSBsb2NrIDMvMi8yKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMjEwNi81ODA2LzAgKHRlc3RzOiByZWFkIDE0MzM3MjIxMDYvNDI3LzI4IG54cmVhZCAx
>NDMzNzIyMTA2LzE0MzM3MjIxMDYvODE2IHRyeWV4Y2VwdCAyOS8yLzEgZm9yayAxNDMzNzIyMTA2
>LzE0MzM3MjIxMDYvNTc5MiBmb3JrdG9vbXVjaCAxNDMzNzIyMTA2LzE0MzM3MjIxMDYvMTQzMzcy
>MjEwNiBhbGxvYyA0MC82LzYgY3JlYXQgODA4Ny83OTQ2LzU3NzYgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIxMjkvNTgyOS8wICh0ZXN0czogcmVhZCAxNDMz
>NzIyMTI5LzQ1MC8xNCBueHJlYWQgMTQzMzcyMjEyOS8xNDMzNzIyMTI5LzgzOSB0cnlleGNlcHQg
>MTUvMS8wIGZvcmsgMTQzMzcyMjEyOS8xNDMzNzIyMTI5LzU4MTUgZm9ya3Rvb211Y2ggMTQzMzcy
>MjEyOS8xNDMzNzIyMTI5LzE0MzM3MjIxMjkgYWxsb2MgMjkvOC8xIGNyZWF0IDgxMTAvNzk2OS81
>Nzk5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMTUyLzU4
>NTIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjE1Mi80NzMvNCBueHJlYWQgMTQzMzcyMjE1Mi8xNDMz
>NzIyMTUyLzg2MiB0cnlleGNlcHQgMzMvMi8wIGZvcmsgMTQzMzcyMjE1Mi8xNDMzNzIyMTUyLzU4
>MzggZm9ya3Rvb211Y2ggMTQzMzcyMjE1Mi8xNDMzNzIyMTUyLzE0MzM3MjIxNTIgYWxsb2MgMzcv
>OC8xIGNyZWF0IDgxMzMvNzk5Mi81ODIyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRo
>cmVhZCBpcyAxNDMzNzIyMTcwLzU4NzAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjE3MC80OTEvMyBu
>eHJlYWQgMTQzMzcyMjE3MC8xNDMzNzIyMTcwLzg4MCB0cnlleGNlcHQgMTMvMS8wIGZvcmsgMTQz
>MzcyMjE3MC8xNDMzNzIyMTcwLzU4NTYgZm9ya3Rvb211Y2ggMTQzMzcyMjE3MC8xNDMzNzIyMTcw
>LzE0MzM3MjIxNzAgYWxsb2MgNTUvMTkvMyBjcmVhdCA4MTUxLzgwMTAvNTg0MCBsb2NrIDIvMi8y
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjE5NC81ODk0LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MjIxOTQvNTE1LzI3IG54cmVhZCAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvOTA0IHRy
>eWV4Y2VwdCAzNC8yLzEgZm9yayAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvNTg4MCBmb3JrdG9vbXVj
>aCAxNDMzNzIyMTk0LzE0MzM3MjIxOTQvMTQzMzcyMjE5NCBhbGxvYyA3OS8xNi82IGNyZWF0IDgx
>NzUvODAzNC81ODY0IGxvY2sgNi82LzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIyMjM2LzU5MzYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjIzNi81NTcvMTEgbnhyZWFkIDE0MzM3
>MjIyMzYvMTQzMzcyMjIzNi85NDYgdHJ5ZXhjZXB0IDcwLzIvMSBmb3JrIDE0MzM3MjIyMzYvMTQz
>MzcyMjIzNi81OTIyIGZvcmt0b29tdWNoIDE0MzM3MjIyMzYvMTQzMzcyMjIzNi8xNDMzNzIyMjM2
>IGFsbG9jIDU4LzE1LzUgY3JlYXQgODIxNy84MDc2LzU5MDYgbG9jayA1LzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIyNzIvNTk3Mi8wICh0ZXN0czogcmVhZCAxNDMzNzIy
>MjcyLzU5My81IG54cmVhZCAxNDMzNzIyMjcyLzE0MzM3MjIyNzIvOTgyIHRyeWV4Y2VwdCA1LzEv
>MSBmb3JrIDE0MzM3MjIyNzIvMTQzMzcyMjI3Mi81OTU4IGZvcmt0b29tdWNoIDE0MzM3MjIyNzIv
>MTQzMzcyMjI3Mi8xNDMzNzIyMjcyIGFsbG9jIDI2LzExLzUgY3JlYXQgODI1My84MTEyLzU5NDIg
>bG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjIzMDAvNjAwMC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIyMzAwLzYyMS8yOCBueHJlYWQgMTQzMzcyMjMwMC8xNDMzNzIy
>MzAwLzEwMTAgdHJ5ZXhjZXB0IDMvMS8wIGZvcmsgMTQzMzcyMjMwMC8xNDMzNzIyMzAwLzU5ODYg
>Zm9ya3Rvb211Y2ggMTQzMzcyMjMwMC8xNDMzNzIyMzAwLzE0MzM3MjIzMDAgYWxsb2MgMjgvNi8x
>IGNyZWF0IDgyODEvODE0MC81OTcwIGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIyMzMxLzYwMzEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjMzMS82NTIvMSBueHJl
>YWQgMTQzMzcyMjMzMS8xNDMzNzIyMzMxLzEwNDEgdHJ5ZXhjZXB0IDMvMi8wIGZvcmsgMTQzMzcy
>MjMzMS8xNDMzNzIyMzMxLzYwMTcgZm9ya3Rvb211Y2ggMTQzMzcyMjMzMS8xNDMzNzIyMzMxLzE0
>MzM3MjIzMzEgYWxsb2MgMTcvMS8xIGNyZWF0IDgzMTIvODE3MS82MDAxIGxvY2sgMS8xLzEpCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyMzY3LzYwNjcvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMjM2Ny82ODgvMTQgbnhyZWFkIDE0MzM3MjIzNjcvMTQzMzcyMjM2Ny8xMDc3IHRyeWV4
>Y2VwdCAyMC8yLzAgZm9yayAxNDMzNzIyMzY3LzE0MzM3MjIzNjcvNjA1MyBmb3JrdG9vbXVjaCAx
>NDMzNzIyMzY3LzE0MzM3MjIzNjcvMTQzMzcyMjM2NyBhbGxvYyAzNy8xOS8xIGNyZWF0IDgzNDgv
>ODIwNy82MDM3IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIy
>NDAzLzYxMDMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjQwMy83MjQvNTAgbnhyZWFkIDE0MzM3MjI0
>MDMvMTQzMzcyMjQwMy8xMTEzIHRyeWV4Y2VwdCAxNC8yLzIgZm9yayAxNDMzNzIyNDAzLzE0MzM3
>MjI0MDMvNjA4OSBmb3JrdG9vbXVjaCAxNDMzNzIyNDAzLzE0MzM3MjI0MDMvMTQzMzcyMjQwMyBh
>bGxvYyAzMi82LzYgY3JlYXQgODM4NC84MjQzLzYwNzMgbG9jayA2LzAvMCkKLi4uLi4uLi4uLmxh
>emllc3QgdGhyZWFkIGlzIDE0MzM3MjI0MzEvNjEzMS8wICh0ZXN0czogcmVhZCAxNDMzNzIyNDMx
>Lzc1Mi8xOCBueHJlYWQgMTQzMzcyMjQzMS8xNDMzNzIyNDMxLzExNDEgdHJ5ZXhjZXB0IDYvMi8x
>IGZvcmsgMTQzMzcyMjQzMS8xNDMzNzIyNDMxLzYxMTcgZm9ya3Rvb211Y2ggMTQzMzcyMjQzMS8x
>NDMzNzIyNDMxLzE0MzM3MjI0MzEgYWxsb2MgMzQvNS81IGNyZWF0IDg0MTIvODI3MS82MTAxIGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIyNDU4LzYxNTgvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMjQ1OC83NzkvNSBueHJlYWQgMTQzMzcyMjQ1OC8xNDMzNzIyNDU4
>LzExNjggdHJ5ZXhjZXB0IDUvMi8wIGZvcmsgMTQzMzcyMjQ1OC8xNDMzNzIyNDU4LzYxNDQgZm9y
>a3Rvb211Y2ggMTQzMzcyMjQ1OC8xNDMzNzIyNDU4LzE0MzM3MjI0NTggYWxsb2MgMzIvMTIvMSBj
>cmVhdCA4NDM5LzgyOTgvNjEyOCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMjQ5NC82MTk0LzAgKHRlc3RzOiByZWFkIDE0MzM3MjI0OTQvODE1LzIgbnhyZWFk
>IDE0MzM3MjI0OTQvMTQzMzcyMjQ5NC8xMjA0IHRyeWV4Y2VwdCAxLzEvMSBmb3JrIDE0MzM3MjI0
>OTQvMTQzMzcyMjQ5NC82MTgwIGZvcmt0b29tdWNoIDE0MzM3MjI0OTQvMTQzMzcyMjQ5NC8xNDMz
>NzIyNDk0IGFsbG9jIDYzLzEyLzIgY3JlYXQgODQ3NS84MzM0LzYxNjQgbG9jayAxLzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI1NDAvNjI0MC8wICh0ZXN0czogcmVhZCAx
>NDMzNzIyNTQwLzg2MS82IG54cmVhZCAxNDMzNzIyNTQwLzE0MzM3MjI1NDAvMTI1MCB0cnlleGNl
>cHQgMi8yLzAgZm9yayAxNDMzNzIyNTQwLzE0MzM3MjI1NDAvNjIyNiBmb3JrdG9vbXVjaCAxNDMz
>NzIyNTQwLzE0MzM3MjI1NDAvMTQzMzcyMjU0MCBhbGxvYyAxMC8xLzEgY3JlYXQgODUyMS84Mzgw
>LzYyMTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI1ODUv
>NjI4NS8wICh0ZXN0czogcmVhZCAxNDMzNzIyNTg1LzkwNi83IG54cmVhZCAxNDMzNzIyNTg1LzE0
>MzM3MjI1ODUvMTI5NSB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzIyNTg1LzE0MzM3MjI1ODUv
>NjI3MSBmb3JrdG9vbXVjaCAxNDMzNzIyNTg1LzE0MzM3MjI1ODUvMTQzMzcyMjU4NSBhbGxvYyAz
>OC8xMi83IGNyZWF0IDg1NjYvODQyNS82MjU1IGxvY2sgNy83LzApCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzIyNjEwLzYzMTAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjYxMC85MzEv
>MTAgbnhyZWFkIDE0MzM3MjI2MTAvMTQzMzcyMjYxMC8xMzIwIHRyeWV4Y2VwdCA0LzIvMSBmb3Jr
>IDE0MzM3MjI2MTAvMTQzMzcyMjYxMC82Mjk2IGZvcmt0b29tdWNoIDE0MzM3MjI2MTAvMTQzMzcy
>MjYxMC8xNDMzNzIyNjEwIGFsbG9jIDYzLzE1LzUgY3JlYXQgODU5MS84NDUwLzYyODAgbG9jayAw
>LzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI2NjkvNjM2OS8wICh0ZXN0
>czogcmVhZCAxNDMzNzIyNjY5Lzk5MC8xIG54cmVhZCAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvMTM3
>OSB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvNjM1NSBmb3JrdG9v
>bXVjaCAxNDMzNzIyNjY5LzE0MzM3MjI2NjkvMTQzMzcyMjY2OSBhbGxvYyA0Ny8xLzEgY3JlYXQg
>ODY1MC84NTA5LzYzMzkgbG9jayAxLzEvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0
>MzM3MjI2OTMvNjM5My8wICh0ZXN0czogcmVhZCAxNDMzNzIyNjkzLzEwMTQvMTQgbnhyZWFkIDE0
>MzM3MjI2OTMvMTQzMzcyMjY5My8xNDAzIHRyeWV4Y2VwdCA4LzIvMSBmb3JrIDE0MzM3MjI2OTMv
>MTQzMzcyMjY5My82Mzc5IGZvcmt0b29tdWNoIDE0MzM3MjI2OTMvMTQzMzcyMjY5My8xNDMzNzIy
>NjkzIGFsbG9jIDU2LzE0LzcgY3JlYXQgODY3NC84NTMzLzYzNjMgbG9jayAwLzAvMCkKLi4uLi4u
>Li4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI3MTYvNjQxNi8wICh0ZXN0czogcmVhZCAxNDMz
>NzIyNzE2LzEwMzcvMTQgbnhyZWFkIDE0MzM3MjI3MTYvMTQzMzcyMjcxNi8xNDI2IHRyeWV4Y2Vw
>dCAzMS84LzEgZm9yayAxNDMzNzIyNzE2LzE0MzM3MjI3MTYvNjQwMiBmb3JrdG9vbXVjaCAxNDMz
>NzIyNzE2LzE0MzM3MjI3MTYvMTQzMzcyMjcxNiBhbGxvYyAzOC84LzIgY3JlYXQgODY5Ny84NTU2
>LzYzODYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI3Mzcv
>NjQzNy8wICh0ZXN0czogcmVhZCAxNDMzNzIyNzM3LzEwNTgvMzUgbnhyZWFkIDE0MzM3MjI3Mzcv
>MTQzMzcyMjczNy8xNDQ3IHRyeWV4Y2VwdCAzMS8xLzEgZm9yayAxNDMzNzIyNzM3LzE0MzM3MjI3
>MzcvNjQyMyBmb3JrdG9vbXVjaCAxNDMzNzIyNzM3LzE0MzM3MjI3MzcvMTQzMzcyMjczNyBhbGxv
>YyA1OC8yMS80IGNyZWF0IDg3MTgvODU3Ny82NDA3IGxvY2sgMy8zLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIyNzc3LzY0NzcvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjc3Ny8x
>MDk4LzIwIG54cmVhZCAxNDMzNzIyNzc3LzE0MzM3MjI3NzcvMTQ4NyB0cnlleGNlcHQgMjgvMy8x
>IGZvcmsgMTQzMzcyMjc3Ny8xNDMzNzIyNzc3LzY0NjMgZm9ya3Rvb211Y2ggMTQzMzcyMjc3Ny8x
>NDMzNzIyNzc3LzE0MzM3MjI3NzcgYWxsb2MgNjkvMjMvNSBjcmVhdCA4NzU4Lzg2MTcvNjQ0NyBs
>b2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjgwMy82NTAzLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjI4MDMvMTA1NS8yIG54cmVhZCAxNDMzNzIyODAzLzE0MzM3MjI4
>MDMvMTUxMyB0cnlleGNlcHQgNy8zLzAgZm9yayAxNDMzNzIyODAzLzE0MzM3MjI4MDMvNjQ4OSBm
>b3JrdG9vbXVjaCAxNDMzNzIyODAzLzE0MzM3MjI4MDMvMTQzMzcyMjgwMyBhbGxvYyA5NS8yMy8y
>IGNyZWF0IDg3ODQvODY0My82NDczIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzIyODMzLzY1MzMvMCAodGVzdHM6IHJlYWQgMTQzMzcyMjgzMy8xMDg1LzIgbnhy
>ZWFkIDE0MzM3MjI4MzMvMTQzMzcyMjgzMy8xNTQzIHRyeWV4Y2VwdCA0LzEvMSBmb3JrIDE0MzM3
>MjI4MzMvMTQzMzcyMjgzMy82NTE5IGZvcmt0b29tdWNoIDE0MzM3MjI4MzMvMTQzMzcyMjgzMy8x
>NDMzNzIyODMzIGFsbG9jIDI2LzYvMiBjcmVhdCA4ODE0Lzg2NzMvNjUwMyBsb2NrIDAvMC8wKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjg1Ni82NTU2LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjI4NTYvMTEwOC8xOSBueHJlYWQgMTQzMzcyMjg1Ni8xNDMzNzIyODU2LzE1NjYgdHJ5
>ZXhjZXB0IDI2LzIvMiBmb3JrIDE0MzM3MjI4NTYvMTQzMzcyMjg1Ni82NTQyIGZvcmt0b29tdWNo
>IDE0MzM3MjI4NTYvMTQzMzcyMjg1Ni8xNDMzNzIyODU2IGFsbG9jIDQ5LzE5LzcgY3JlYXQgODgz
>Ny84Njk2LzY1MjYgbG9jayA1LzUvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MjI4ODQvNjU4NC8wICh0ZXN0czogcmVhZCAxNDMzNzIyODg0LzExMzYvMjQgbnhyZWFkIDE0MzM3
>MjI4ODQvMTQzMzcyMjg4NC8xNTk0IHRyeWV4Y2VwdCAyLzIvMSBmb3JrIDE0MzM3MjI4ODQvMTQz
>MzcyMjg4NC82NTcwIGZvcmt0b29tdWNoIDE0MzM3MjI4ODQvMTQzMzcyMjg4NC8xNDMzNzIyODg0
>IGFsbG9jIDM1LzgvMiBjcmVhdCA4ODY1Lzg3MjQvNjU1NCBsb2NrIDAvMC8wKQouLi4uLi4uLi4u
>bGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMjk0NS82NjQ1LzAgKHRlc3RzOiByZWFkIDE0MzM3MjI5
>NDUvMTE5Ny8xIG54cmVhZCAxNDMzNzIyOTQ1LzE0MzM3MjI5NDUvMTY1NSB0cnlleGNlcHQgNS8y
>LzAgZm9yayAxNDMzNzIyOTQ1LzE0MzM3MjI5NDUvNjYzMSBmb3JrdG9vbXVjaCAxNDMzNzIyOTQ1
>LzE0MzM3MjI5NDUvMTQzMzcyMjk0NSBhbGxvYyAzNS85LzEgY3JlYXQgODkyNi84Nzg1LzY2MTUg
>bG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjI5ODQvNjY4NC8w
>ICh0ZXN0czogcmVhZCAxNDMzNzIyOTg0LzEyMzYvMTEgbnhyZWFkIDE0MzM3MjI5ODQvMTQzMzcy
>Mjk4NC8xNjk0IHRyeWV4Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjI5ODQvMTQzMzcyMjk4NC82Njcw
>IGZvcmt0b29tdWNoIDE0MzM3MjI5ODQvMTQzMzcyMjk4NC8xNDMzNzIyOTg0IGFsbG9jIDU0LzYv
>MSBjcmVhdCA4OTY1Lzg4MjQvNjY1NCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJl
>YWQgaXMgMTQzMzcyMzA1Mi82NzUyLzAgKHRlc3RzOiByZWFkIDE0MzM3MjMwNTIvMTMwNC8xOSBu
>eHJlYWQgMTQzMzcyMzA1Mi8xNDMzNzIzMDUyLzE3NjIgdHJ5ZXhjZXB0IDM2LzIvMSBmb3JrIDE0
>MzM3MjMwNTIvMTQzMzcyMzA1Mi82NzM4IGZvcmt0b29tdWNoIDE0MzM3MjMwNTIvMTQzMzcyMzA1
>Mi8xNDMzNzIzMDUyIGFsbG9jIDM3LzE5LzYgY3JlYXQgOTAzMy84ODkyLzY3MjIgbG9jayA1LzAv
>MCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMwODIvNjc4Mi8wICh0ZXN0czog
>cmVhZCAxNDMzNzIzMDgyLzEzMzQvOSBueHJlYWQgMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzE3OTIg
>dHJ5ZXhjZXB0IDQvMS8wIGZvcmsgMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzY3NjggZm9ya3Rvb211
>Y2ggMTQzMzcyMzA4Mi8xNDMzNzIzMDgyLzE0MzM3MjMwODIgYWxsb2MgNjcvOS8yIGNyZWF0IDkw
>NjMvODkyMi82NzUyIGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMz
>NzIzMTA5LzY4MDkvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzEwOS8xMzYxLzEzIG54cmVhZCAxNDMz
>NzIzMTA5LzE0MzM3MjMxMDkvMTgxOSB0cnlleGNlcHQgNy8yLzEgZm9yayAxNDMzNzIzMTA5LzE0
>MzM3MjMxMDkvNjc5NSBmb3JrdG9vbXVjaCAxNDMzNzIzMTA5LzE0MzM3MjMxMDkvMTQzMzcyMzEw
>OSBhbGxvYyA0MC85LzMgY3JlYXQgOTA5MC84OTQ5LzY3NzkgbG9jayAzLzAvMCkKLi4uLi4uLi4u
>Lmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMxMjYvNjgyNi8wICh0ZXN0czogcmVhZCAxNDMzNzIz
>MTI2LzEzNzgvMTcgbnhyZWFkIDE0MzM3MjMxMjYvMTQzMzcyMzEyNi8xODM2IHRyeWV4Y2VwdCAy
>My8xLzEgZm9yayAxNDMzNzIzMTI2LzE0MzM3MjMxMjYvNjgxMiBmb3JrdG9vbXVjaCAxNDMzNzIz
>MTI2LzE0MzM3MjMxMjYvMTQzMzcyMzEyNiBhbGxvYyA1Ny8xMy80IGNyZWF0IDkxMDcvODk2Ni82
>Nzk2IGxvY2sgMi8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzMTU2LzY4
>NTYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzE1Ni8xNDA4LzEzIG54cmVhZCAxNDMzNzIzMTU2LzE0
>MzM3MjMxNTYvMTg2NiB0cnlleGNlcHQgMi8yLzAgZm9yayAxNDMzNzIzMTU2LzE0MzM3MjMxNTYv
>Njg0MiBmb3JrdG9vbXVjaCAxNDMzNzIzMTU2LzE0MzM3MjMxNTYvMTQzMzcyMzE1NiBhbGxvYyA1
>Ni8yMi8xIGNyZWF0IDkxMzcvODk5Ni82ODI2IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5sYXppZXN0
>IHRocmVhZCBpcyAxNDMzNzIzMjAwLzY5MDAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzIwMC8xNDIy
>LzQgbnhyZWFkIDE0MzM3MjMyMDAvMTQzMzcyMzIwMC8xOTEwIHRyeWV4Y2VwdCAxMy8yLzEgZm9y
>ayAxNDMzNzIzMjAwLzE0MzM3MjMyMDAvNjg4NiBmb3JrdG9vbXVjaCAxNDMzNzIzMjAwLzE0MzM3
>MjMyMDAvMTQzMzcyMzIwMCBhbGxvYyA0MC8xMS8wIGNyZWF0IDkxODEvOTA0MC82ODcwIGxvY2sg
>My8zLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzMjQxLzY5NDEvMCAodGVz
>dHM6IHJlYWQgMTQzMzcyMzI0MS80NS83IG54cmVhZCAxNDMzNzIzMjQxLzE0MzM3MjMyNDEvMTk1
>MSB0cnlleGNlcHQgMjYvMi8xIGZvcmsgMTQzMzcyMzI0MS8xNDMzNzIzMjQxLzY5MjcgZm9ya3Rv
>b211Y2ggMTQzMzcyMzI0MS8xNDMzNzIzMjQxLzE0MzM3MjMyNDEgYWxsb2MgNDEvMTUvMCBjcmVh
>dCA5MjIyLzkwODEvNjkxMSBsb2NrIDQvNC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMg
>MTQzMzcyMzI2OS82OTY5LzAgKHRlc3RzOiByZWFkIDE0MzM3MjMyNjkvMzUvNiBueHJlYWQgMTQz
>MzcyMzI2OS8xNDMzNzIzMjY5LzE5NzkgdHJ5ZXhjZXB0IDQvMi8xIGZvcmsgMTQzMzcyMzI2OS8x
>NDMzNzIzMjY5LzY5NTUgZm9ya3Rvb211Y2ggMTQzMzcyMzI2OS8xNDMzNzIzMjY5LzE0MzM3MjMy
>NjkgYWxsb2MgNDMvMTEvNiBjcmVhdCA5MjUwLzkxMDkvNjkzOSBsb2NrIDQvNC8wKQouLi4uLi4u
>Li4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzI5OC82OTk4LzAgKHRlc3RzOiByZWFkIDE0MzM3
>MjMyOTgvNjQvMTQgbnhyZWFkIDE0MzM3MjMyOTgvMTQzMzcyMzI5OC8yMDA4IHRyeWV4Y2VwdCA4
>LzgvMCBmb3JrIDE0MzM3MjMyOTgvMTQzMzcyMzI5OC82OTg0IGZvcmt0b29tdWNoIDE0MzM3MjMy
>OTgvMTQzMzcyMzI5OC8xNDMzNzIzMjk4IGFsbG9jIDQwLzE0LzkgY3JlYXQgOTI3OS85MTM4LzY5
>NjggbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjMzNDAvNzA0
>MC8wICh0ZXN0czogcmVhZCAxNDMzNzIzMzQwLzEwNi8xIG54cmVhZCAxNDMzNzIzMzQwLzE0MzM3
>MjMzNDAvMjA1MCB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzMzQwLzE0MzM3MjMzNDAvNzAy
>NiBmb3JrdG9vbXVjaCAxNDMzNzIzMzQwLzE0MzM3MjMzNDAvMTQzMzcyMzM0MCBhbGxvYyAzMS82
>LzEgY3JlYXQgOTMyMS85MTgwLzcwMTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhy
>ZWFkIGlzIDE0MzM3MjMzNjUvNzA2NS8wICh0ZXN0czogcmVhZCAxNDMzNzIzMzY1LzEzMS8yNiBu
>eHJlYWQgMTQzMzcyMzM2NS8xNDMzNzIzMzY1LzIwNzUgdHJ5ZXhjZXB0IDE5LzAvMCBmb3JrIDE0
>MzM3MjMzNjUvMTQzMzcyMzM2NS83MDUxIGZvcmt0b29tdWNoIDE0MzM3MjMzNjUvMTQzMzcyMzM2
>NS8xNDMzNzIzMzY1IGFsbG9jIDMxLzUvMSBjcmVhdCA5MzQ2LzkyMDUvNzAzNSBsb2NrIDEvMC8w
>KQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzM4Ni83MDg2LzAgKHRlc3RzOiBy
>ZWFkIDE0MzM3MjMzODYvMTUyLzE4IG54cmVhZCAxNDMzNzIzMzg2LzE0MzM3MjMzODYvMjA5NiB0
>cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzMzg2LzE0MzM3MjMzODYvNzA3MiBmb3JrdG9vbXVj
>aCAxNDMzNzIzMzg2LzE0MzM3MjMzODYvMTQzMzcyMzM4NiBhbGxvYyA1Mi82LzEgY3JlYXQgOTM2
>Ny85MjI2LzcwNTYgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3
>MjM0MzUvNzEzNS8wICh0ZXN0czogcmVhZCAxNDMzNzIzNDM1LzIwMS8xIG54cmVhZCAxNDMzNzIz
>NDM1LzE0MzM3MjM0MzUvMjE0NSB0cnlleGNlcHQgNC8zLzAgZm9yayAxNDMzNzIzNDM1LzE0MzM3
>MjM0MzUvNzEyMSBmb3JrdG9vbXVjaCAxNDMzNzIzNDM1LzE0MzM3MjM0MzUvMTQzMzcyMzQzNSBh
>bGxvYyA0My8xNC8xIGNyZWF0IDk0MTYvOTI3NS83MTA1IGxvY2sgMS8xLzEpCi4uLi4uLi4uLi5s
>YXppZXN0IHRocmVhZCBpcyAxNDMzNzIzNDYyLzcxNjIvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzQ2
>Mi8yMjgvMjMgbnhyZWFkIDE0MzM3MjM0NjIvMTQzMzcyMzQ2Mi8yMTcyIHRyeWV4Y2VwdCAyLzIv
>MiBmb3JrIDE0MzM3MjM0NjIvMTQzMzcyMzQ2Mi83MTQ4IGZvcmt0b29tdWNoIDE0MzM3MjM0NjIv
>MTQzMzcyMzQ2Mi8xNDMzNzIzNDYyIGFsbG9jIDQ1LzcvMCBjcmVhdCA5NDQzLzkzMDIvNzEzMiBs
>b2NrIDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzUxMi83MjEyLzAg
>KHRlc3RzOiByZWFkIDE0MzM3MjM1MTIvMjc4LzkgbnhyZWFkIDE0MzM3MjM1MTIvMTQzMzcyMzUx
>Mi8yMjIyIHRyeWV4Y2VwdCA0Mi8yLzEgZm9yayAxNDMzNzIzNTEyLzE0MzM3MjM1MTIvNzE5OCBm
>b3JrdG9vbXVjaCAxNDMzNzIzNTEyLzE0MzM3MjM1MTIvMTQzMzcyMzUxMiBhbGxvYyAyMi85LzQg
>Y3JlYXQgOTQ5My85MzUyLzcxODIgbG9jayAzLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFk
>IGlzIDE0MzM3MjM1NDAvNzI0MC8wICh0ZXN0czogcmVhZCAxNDMzNzIzNTQwLzMwNi82IG54cmVh
>ZCAxNDMzNzIzNTQwLzE0MzM3MjM1NDAvMjI1MCB0cnlleGNlcHQgNDYvMS8wIGZvcmsgMTQzMzcy
>MzU0MC8xNDMzNzIzNTQwLzcyMjYgZm9ya3Rvb211Y2ggMTQzMzcyMzU0MC8xNDMzNzIzNTQwLzE0
>MzM3MjM1NDAgYWxsb2MgNDUvMTAvMiBjcmVhdCA5NTIxLzkzODAvNzIxMCBsb2NrIDIvMi8yKQou
>Li4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzU5OC83Mjk4LzAgKHRlc3RzOiByZWFk
>IDE0MzM3MjM1OTgvMzY0LzEgbnhyZWFkIDE0MzM3MjM1OTgvMTQzMzcyMzU5OC8yMzA4IHRyeWV4
>Y2VwdCAzLzIvMCBmb3JrIDE0MzM3MjM1OTgvMTQzMzcyMzU5OC83Mjg0IGZvcmt0b29tdWNoIDE0
>MzM3MjM1OTgvMTQzMzcyMzU5OC8xNDMzNzIzNTk4IGFsbG9jIDM5LzYvMSBjcmVhdCA5NTc5Lzk0
>MzgvNzI2OCBsb2NrIDEvMS8xKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzYy
>MC83MzIwLzAgKHRlc3RzOiByZWFkIDE0MzM3MjM2MjAvMzg2LzYgbnhyZWFkIDE0MzM3MjM2MjAv
>MTQzMzcyMzYyMC8yMzMwIHRyeWV4Y2VwdCA5LzEvMSBmb3JrIDE0MzM3MjM2MjAvMTQzMzcyMzYy
>MC83MzA2IGZvcmt0b29tdWNoIDE0MzM3MjM2MjAvMTQzMzcyMzYyMC8xNDMzNzIzNjIwIGFsbG9j
>IDYxLzE3LzYgY3JlYXQgOTYwMS85NDYwLzcyOTAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjM2NTEvNzM1MS8wICh0ZXN0czogcmVhZCAxNDMzNzIzNjUxLzQx
>Ny8xMCBueHJlYWQgMTQzMzcyMzY1MS8xNDMzNzIzNjUxLzIzNjEgdHJ5ZXhjZXB0IDM4LzgvMCBm
>b3JrIDE0MzM3MjM2NTEvMTQzMzcyMzY1MS83MzM3IGZvcmt0b29tdWNoIDE0MzM3MjM2NTEvMTQz
>MzcyMzY1MS8xNDMzNzIzNjUxIGFsbG9jIDY1LzEzLzEgY3JlYXQgOTYzMi85NDkxLzczMjEgbG9j
>ayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM2NzIvNzM3Mi8wICh0
>ZXN0czogcmVhZCAxNDMzNzIzNjcyLzQzOC84IG54cmVhZCAxNDMzNzIzNjcyLzE0MzM3MjM2NzIv
>MjM4MiB0cnlleGNlcHQgMjkvMi8yIGZvcmsgMTQzMzcyMzY3Mi8xNDMzNzIzNjcyLzczNTggZm9y
>a3Rvb211Y2ggMTQzMzcyMzY3Mi8xNDMzNzIzNjcyLzE0MzM3MjM2NzIgYWxsb2MgNzUvMjIvNyBj
>cmVhdCA5NjUzLzk1MTIvNzM0MiBsb2NrIDUvNS8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQg
>aXMgMTQzMzcyMzczMC83NDMwLzAgKHRlc3RzOiByZWFkIDE0MzM3MjM3MzAvNDk2LzIxIG54cmVh
>ZCAxNDMzNzIzNzMwLzE0MzM3MjM3MzAvMjQ0MCB0cnlleGNlcHQgNi8yLzEgZm9yayAxNDMzNzIz
>NzMwLzE0MzM3MjM3MzAvNzQxNiBmb3JrdG9vbXVjaCAxNDMzNzIzNzMwLzE0MzM3MjM3MzAvMTQz
>MzcyMzczMCBhbGxvYyA1OC8yMS8wIGNyZWF0IDk3MTEvOTU3MC83NDAwIGxvY2sgMC8wLzApCi4u
>Li4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzNzU4Lzc0NTgvMCAodGVzdHM6IHJlYWQg
>MTQzMzcyMzc1OC81MjQvMjMgbnhyZWFkIDE0MzM3MjM3NTgvMTQzMzcyMzc1OC8yNDY4IHRyeWV4
>Y2VwdCA3LzIvMiBmb3JrIDE0MzM3MjM3NTgvMTQzMzcyMzc1OC83NDQ0IGZvcmt0b29tdWNoIDE0
>MzM3MjM3NTgvMTQzMzcyMzc1OC8xNDMzNzIzNzU4IGFsbG9jIDI4LzE5LzUgY3JlYXQgOTczOS85
>NTk4Lzc0MjggbG9jayA0LzQvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM3
>ODcvNzQ4Ny8wICh0ZXN0czogcmVhZCAxNDMzNzIzNzg3LzU1My8xIG54cmVhZCAxNDMzNzIzNzg3
>LzE0MzM3MjM3ODcvMjQ5NyB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzNzg3LzE0MzM3MjM3
>ODcvNzQ3MyBmb3JrdG9vbXVjaCAxNDMzNzIzNzg3LzE0MzM3MjM3ODcvMTQzMzcyMzc4NyBhbGxv
>YyA0OC8xMC8xIGNyZWF0IDk3NjgvOTYyNy83NDU3IGxvY2sgMS8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIzODIwLzc1MjAvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzgyMC81
>ODYvNiBueHJlYWQgMTQzMzcyMzgyMC8xNDMzNzIzODIwLzI1MzAgdHJ5ZXhjZXB0IDMwLzMvMCBm
>b3JrIDE0MzM3MjM4MjAvMTQzMzcyMzgyMC83NTA2IGZvcmt0b29tdWNoIDE0MzM3MjM4MjAvMTQz
>MzcyMzgyMC8xNDMzNzIzODIwIGFsbG9jIDQzLzkvMSBjcmVhdCA5ODAxLzk2NjAvNzQ5MCBsb2Nr
>IDAvMC8wKQouLi4uLi4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyMzg1Ny83NTU3LzAgKHRl
>c3RzOiByZWFkIDE0MzM3MjM4NTcvNjIzLzEzIG54cmVhZCAxNDMzNzIzODU3LzE0MzM3MjM4NTcv
>MjU2NyB0cnlleGNlcHQgMy8yLzAgZm9yayAxNDMzNzIzODU3LzE0MzM3MjM4NTcvNzU0MyBmb3Jr
>dG9vbXVjaCAxNDMzNzIzODU3LzE0MzM3MjM4NTcvMTQzMzcyMzg1NyBhbGxvYyA0Ni8xLzEgY3Jl
>YXQgOTgzOC85Njk3Lzc1MjcgbG9jayAxLzEvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlz
>IDE0MzM3MjM4ODMvNzU4My8wICh0ZXN0czogcmVhZCAxNDMzNzIzODgzLzY0OS8zOSBueHJlYWQg
>MTQzMzcyMzg4My8xNDMzNzIzODgzLzI1OTMgdHJ5ZXhjZXB0IDEwLzIvMSBmb3JrIDE0MzM3MjM4
>ODMvMTQzMzcyMzg4My83NTY5IGZvcmt0b29tdWNoIDE0MzM3MjM4ODMvMTQzMzcyMzg4My8xNDMz
>NzIzODgzIGFsbG9jIDIyLzExLzAgY3JlYXQgOTg2NC85NzIzLzc1NTMgbG9jayA1LzAvMCkKLi4u
>Li4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjM5MDcvNzYwNy8wICh0ZXN0czogcmVhZCAx
>NDMzNzIzOTA3LzY3My8zIG54cmVhZCAxNDMzNzIzOTA3LzE0MzM3MjM5MDcvMjYxNyB0cnlleGNl
>cHQgMzMvMS8xIGZvcmsgMTQzMzcyMzkwNy8xNDMzNzIzOTA3Lzc1OTMgZm9ya3Rvb211Y2ggMTQz
>MzcyMzkwNy8xNDMzNzIzOTA3LzE0MzM3MjM5MDcgYWxsb2MgMzUvMy8zIGNyZWF0IDk4ODgvOTc0
>Ny83NTc3IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzOTI2
>Lzc2MjYvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzkyNi82OTIvMTkgbnhyZWFkIDE0MzM3MjM5MjYv
>MTQzMzcyMzkyNi8yNjM2IHRyeWV4Y2VwdCA1Mi8yLzEgZm9yayAxNDMzNzIzOTI2LzE0MzM3MjM5
>MjYvNzYxMiBmb3JrdG9vbXVjaCAxNDMzNzIzOTI2LzE0MzM3MjM5MjYvMTQzMzcyMzkyNiBhbGxv
>YyA1NC8xOS80IGNyZWF0IDk5MDcvOTc2Ni83NTk2IGxvY2sgMy8wLzApCi4uLi4uLi4uLi5sYXpp
>ZXN0IHRocmVhZCBpcyAxNDMzNzIzOTUxLzc2NTEvMCAodGVzdHM6IHJlYWQgMTQzMzcyMzk1MS83
>MTcvMTEgbnhyZWFkIDE0MzM3MjM5NTEvMTQzMzcyMzk1MS8yNjYxIHRyeWV4Y2VwdCAyNi8zLzEg
>Zm9yayAxNDMzNzIzOTUxLzE0MzM3MjM5NTEvNzYzNyBmb3JrdG9vbXVjaCAxNDMzNzIzOTUxLzE0
>MzM3MjM5NTEvMTQzMzcyMzk1MSBhbGxvYyA1OS8xMS81IGNyZWF0IDk5MzIvOTc5MS83NjIxIGxv
>Y2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBpcyAxNDMzNzIzOTc0Lzc2NzQvMCAo
>dGVzdHM6IHJlYWQgMTQzMzcyMzk3NC83NDAvMiBueHJlYWQgMTQzMzcyMzk3NC8xNDMzNzIzOTc0
>LzI2ODQgdHJ5ZXhjZXB0IDUvMy8wIGZvcmsgMTQzMzcyMzk3NC8xNDMzNzIzOTc0Lzc2NjAgZm9y
>a3Rvb211Y2ggMTQzMzcyMzk3NC8xNDMzNzIzOTc0LzE0MzM3MjM5NzQgYWxsb2MgNTIvNC8yIGNy
>ZWF0IDk5NTUvOTgxNC83NjQ0IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVhZCBp
>cyAxNDMzNzI0MDE1Lzc3MTUvMCAodGVzdHM6IHJlYWQgMTQzMzcyNDAxNS83ODEvMSBueHJlYWQg
>MTQzMzcyNDAxNS8xNDMzNzI0MDE1LzI3MjUgdHJ5ZXhjZXB0IDQ0LzMvMCBmb3JrIDE0MzM3MjQw
>MTUvMTQzMzcyNDAxNS83NzAxIGZvcmt0b29tdWNoIDE0MzM3MjQwMTUvMTQzMzcyNDAxNS8xNDMz
>NzI0MDE1IGFsbG9jIDYxLzYvMSBjcmVhdCA5OTk2Lzk4NTUvNzY4NSBsb2NrIDIvMi8xKQouLi4u
>Li4uLi4ubGF6aWVzdCB0aHJlYWQgaXMgMTQzMzcyNDA1MC83NzUwLzAgKHRlc3RzOiByZWFkIDE0
>MzM3MjQwNTAvODE2LzEgbnhyZWFkIDE0MzM3MjQwNTAvMTQzMzcyNDA1MC8yNzYwIHRyeWV4Y2Vw
>dCAzLzIvMCBmb3JrIDE0MzM3MjQwNTAvMTQzMzcyNDA1MC83NzM2IGZvcmt0b29tdWNoIDE0MzM3
>MjQwNTAvMTQzMzcyNDA1MC8xNDMzNzI0MDUwIGFsbG9jIDQ1LzYvMSBjcmVhdCAxMDAzMS85ODkw
>Lzc3MjAgbG9jayAwLzAvMCkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjQwODAv
>Nzc4MC8wICh0ZXN0czogcmVhZCAxNDMzNzI0MDgwLzg0Ni85IG54cmVhZCAxNDMzNzI0MDgwLzE0
>MzM3MjQwODAvMjc5MCB0cnlleGNlcHQgMTIvMC8wIGZvcmsgMTQzMzcyNDA4MC8xNDMzNzI0MDgw
>Lzc3NjYgZm9ya3Rvb211Y2ggMTQzMzcyNDA4MC8xNDMzNzI0MDgwLzE0MzM3MjQwODAgYWxsb2Mg
>MzYvMTUvMiBjcmVhdCAxMDA2MS85OTIwLzc3NTAgbG9jayAyLzIvMikKLi4uLi4uLi4uLmxhemll
>c3QgdGhyZWFkIGlzIDE0MzM3MjQxMDQvNzgwNC8wICh0ZXN0czogcmVhZCAxNDMzNzI0MTA0Lzg3
>MC8zIG54cmVhZCAxNDMzNzI0MTA0LzE0MzM3MjQxMDQvMjgxNCB0cnlleGNlcHQgMzMvMS8wIGZv
>cmsgMTQzMzcyNDEwNC8xNDMzNzI0MTA0Lzc3OTAgZm9ya3Rvb211Y2ggMTQzMzcyNDEwNC8xNDMz
>NzI0MTA0LzE0MzM3MjQxMDQgYWxsb2MgMzkvMTIvMyBjcmVhdCAxMDA4NS85OTQ0Lzc3NzQgbG9j
>ayAyLzIvMSkKLi4uLi4uLi4uLmxhemllc3QgdGhyZWFkIGlzIDE0MzM3MjQxNDkvNzg0OS8wICh0
>ZXN0czogcmVhZCAxNDMzNzI0MTQ5LzkxNS8zNCBueHJlYWQgMTQzMzcyNDE0OS8xNDMzNzI0MTQ5
>LzI4NTkgdHJ5ZXhjZXB0IDQzLzIvMCBmb3JrIDE0MzM3MjQxNDkvMTQzMzcyNDE0OS83ODM1IGZv
>cmt0b29tdWNoIDE0MzM3MjQxNDkvMTQzMzcyNDE0OS8xNDMzNzI0MTQ5IGFsbG9jIDQyLzEyLzEg
>Y3JlYXQgMTAxMzAvOTk4OS83ODE5IGxvY2sgMC8wLzApCi4uLi4uLi4uLi5sYXppZXN0IHRocmVh
>ZCBpcyAxNDMzNzI0MTgwLzc4ODAvMCAodGVzdHM6IHJlYWQgMTQzMzcyNDE4MC85NDYvMSBueHJl
>YWQgMTQzMzcyNDE4MC8xNDMzNzI0MTgwLzI4OTAgdHJ5ZXhjZXB0IDE1LzIvMCBmb3JrIDE0MzM3
>MjQxODAvMTQzMzcyNDE4MC83ODY2IGZvcmt0b29tdWNoIDE0MzM3MjQxODAvMTQzMzcyNDE4MC8x
>NDMzNzI0MTgwIGFsbG9jIDU5LzU=
>
>--Multipart=_Tue__9_Jun_2015_22_44_48_+0200_rSB4Y9+qyzXusHHn--


From dmuysers at hotmail.com  Sat Jul  4 11:48:08 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 4 Jul 2015 11:48:08 +0200
Subject: [M3devel] Arithmetic Shift
Message-ID: <DUB127-DS2AA4B1C47C4D0A19C4634DD950@phx.gbl>

Why is there no arithmetic right shift operation in Modula-3 ?

Oberon software has a clever way to minimally encode
signed integers independently of their size.

PROCEDURE WriteInt (i: INTEGER) =
  BEGIN
    WHILE x < ?64 OR x > 63 DO
      Write (VAL (i MOD 128 + 128, CHAR));
      i := i DIV 128;
    END;
    Write (VAL (i MOD 128), CHAR));
  END Write;

Unfortunately it is impossible to implement the corresponding
decoder in M3, because it requires an arithmetic right shift
where the sign bit is replicated into the left end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150704/1b90114c/attachment-0002.html>

From dmuysers at hotmail.com  Sat Jul  4 12:31:46 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 4 Jul 2015 12:31:46 +0200
Subject: [M3devel] Arithmetic Shift
In-Reply-To: <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu>
References: <DUB127-DS2AA4B1C47C4D0A19C4634DD950@phx.gbl>
 <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu>
Message-ID: <DUB127-DS3CEC4034F7BA584E67E9EDD950@phx.gbl>

Sure, but then, since the amount of shift is a variable, it will oblige one
to index into a table of such constants, which is rather clumsy, and
possibly (?) poorly optimised by the compiler.

PROCEDURE ReadInt (VAR x: INTEGER) =
  VAR ch: CHAR;  n, y := 0;
  BEGIN
    Read (ch);
    WHILE ch >= 128 DO
      INC (y, Word.LeftShift (ORD (ch) - 128, n));
      INC (n, 7);
      Read (ch)
    END;
    x := arithmetic-shift (Word.LeftShift (ORD (ch), 25), n - 25) + y
  END ReadInt;

From: Antony Hosking 
Sent: Saturday, July 04, 2015 12:11 PM
To: dirk muysers 
Cc: m3devel at elegosoft.com 
Subject: Re: [M3devel] Arithmetic Shift

In this code you use DIV by a constant power of two.  That will turn into an arithmetic right shift. 

  On Jul 4, 2015, at 7:48 PM, dirk muysers <dmuysers at hotmail.com> wrote:

  Why is there no arithmetic right shift operation in Modula-3 ?

  Oberon software has a clever way to minimally encode
  signed integers independently of their size.

  PROCEDURE WriteInt (i: INTEGER) =
    BEGIN
      WHILE x < ?64 OR x > 63 DO
        Write (VAL (i MOD 128 + 128, CHAR));
        i := i DIV 128;
      END;
      Write (VAL (i MOD 128), CHAR));
    END Write;

  Unfortunately it is impossible to implement the corresponding
  decoder in M3, because it requires an arithmetic right shift
  where the sign bit is replicated into the left end.
  _______________________________________________
  M3devel mailing list
  M3devel at elegosoft.com
  https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150704/beadc2c2/attachment-0002.html>

From jay.krell at cornell.edu  Sat Jul 18 10:27:41 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 08:27:41 +0000
Subject: [M3devel] switching to C backend?
Message-ID: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>

Any objection if I start switching targets to the C backend?
In particular, Darwin does not support m3gdb, so debuggability is not a factor.
Thanks, - Jay



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/a1410c75/attachment-0002.html>

From dmuysers at hotmail.com  Sat Jul 18 10:42:14 2015
From: dmuysers at hotmail.com (dirk muysers)
Date: Sat, 18 Jul 2015 10:42:14 +0200
Subject: [M3devel] switching to C backend?
In-Reply-To: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>
References: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>
Message-ID: <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>

May I remind you Norman Ramsey?s opinion on the subject:



Code generation is my business :-)

Comments on a few options:

  a.. CLR: 

    a.. Pro: industrial support 
    b.. Con: you have to buy into their type system pretty much completely; depending on what you want to do with types, this may not matter 
    c.. Con: Only Windows platform is really prime-time quality
  b.. LLVM:

    a.. Pro: enthusiastic user community with charismatic leader 
    b.. Pro: many interesting performance improvements 
    c.. Con: somewhat complex interface 
    d.. Con: history of holes in the engineering; as LLVM matures expect the holes in the engineering to be plugged by adding to the complexity of the interface
  c.. C--

    a.. Pro: target is an actual written language, not an API; you can easily inspect, debug, and edit your C-- code 
    b.. Pro: design is reasonably mature and reasonably clean 
    c.. Pro: supports accurate garbage collection 
    d.. Pro: most users report it is very easy to use 
    e.. Con: very small development team 
    f.. Con: as of early 2009, supports only three hardware platforms (x86, PPC, ARM) 
    g.. Con: does not ship with a garbage collector 
    h.. Con: future of project is uncertain
  d.. C as target language

    a.. Pro: looks easy 
    b.. Con: nearly impossible to get decent performance 
    c.. Con: will drive you nuts in the long run; ask the long line of people who have tried to compile Haskell, ML, Modula-3, Scheme and more using this technique. At some point every one of these people gave up and built their own native code generator.
Summary: anything except C is a reasonable choice. For the best combination of flexibility, quality, and expected longevity, I'd probably recommend LLVM. But your example code is very close to C--, so that may be an advantage.

Full disclosure: I am affiliated with the C-- project.


From: Jay K 
Sent: Saturday, July 18, 2015 10:27 AM
To: m3devel 
Subject: [M3devel] switching to C backend?

Any objection if I start switching targets to the C backend? 

In particular, Darwin does not support m3gdb, so debuggability is not a factor.

Thanks,
- Jay







--------------------------------------------------------------------------------
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/0900c2cf/attachment-0002.html>

From jay.krell at cornell.edu  Sat Jul 18 10:48:09 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 08:48:09 +0000
Subject: [M3devel] representing word size in IR target-independently?
Message-ID: <COL130-W38AE30909909E4B9AF5E37E6870@phx.gbl>

 Ideally there would be one target-independent IR for, for example: 


 VAR a := BYTESIZE(INTEGER);   VAR b := BITSIZE(INTEGER) = 64;   TYPE T1 = RECORD a,b:INTEGER END;   CONST pt1: REF T1 = NIL;   VAR offset_of_b := LOOPHOLE(INTEGER, ADR(pt1.b));  


 so that it could be translated to target-independent C something like: 

 #if ...almost always true...   typedef ptrdiff_t INTEGER;  #else  ...  #endif   INTEGER a = sizeof(INTEGER);  typedef unsigned char BOOLEAN;   BOOLEAN b = (sizeof(INTEGER) * 8) == 64;   typedef struct { a,b:INTEGER; } T1;  T1* pt1;  // ideal but unlikely:  INTEGER offset_of_b = offsetof(T1, b);  // more likely:   INTEGER offset_of_b;  void module_initializer()  {    offset_of_b = (INTEGER)&pt1->b;  } 
  
Is this feasible?


 Can instances of "INTEGER" somehow be left higher level for resolution  by the backend? Or can they be left "dual", both "resolved" and "symbolic"?  Or would this require too much change?
 
 I would be very reluctantly satisfied if the frontend ran  a certain portion of itself twice, once for each word size, indicating  the start/end of the passes to the backend, so the generated C would  be doubled up with an #if something like: 

#if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || defined(__ppc64__) ...
 ... everything ... 
 #else // 32 bit 
 ... everything ... 
 #endif

The agenda is target-independent C output from the C backend,as a portable redistributable form.This is approximately one of the three problems to solve to achieve that.


Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/68359d67/attachment-0002.html>

From jay.krell at cornell.edu  Sat Jul 18 11:02:03 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 09:02:03 +0000
Subject: [M3devel] switching to C backend?
In-Reply-To: <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>
References: <COL130-W35000F24B5325A3AAA0B18E6870@phx.gbl>,
 <DUB127-DS22F26BA0AE1A0BF7523E02DD870@phx.gbl>
Message-ID: <COL130-W699475F4DD964C1D9FA199E6870@phx.gbl>

 I disagree.  The system is working. This isn't speculation.
  Using his terminology  
  C pros:   - written language (also a con)   - longevity   - does not drive me nuts   - design is very mature    - looks easy and is easy   - huge portability of implementation   - potential portability of object code    - debugability with stock debuggers    - large development teams ("back back end")  - multiple industrial strength "back back ends"   - likely similar compiled performance as anything else   - probably similar compiled performance 

 C cons:   - compiler performance     - debuggability on platforms that have m3gdb support    - cannot always efficiently express things portably,     in particular, portable C has the same inefficient exception      handling; we need to switch to C++ to fix it, or non-portable C      on some platforms (i.e. win32 __try)       
 For garbage collection, I believe C, m3cc, and llvm are currently all equivalent and not good. 
    - Jay



From: dmuysers at hotmail.com
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] switching to C backend?
Date: Sat, 18 Jul 2015 10:42:14 +0200








May I remind you Norman Ramsey?s opinion on the 
subject:

 

Code generation is my business :-)

Comments on a few options:


  
  CLR: 

  
    Pro: industrial support 
    Con: you have to buy into their type system 
    pretty much completely; depending on what you want to do with types, this 
    may not matter 
    Con: Only Windows platform is really 
    prime-time quality
  
  LLVM:

  
    Pro: enthusiastic user community with 
    charismatic leader 
    Pro: many interesting performance 
    improvements 
    Con: somewhat complex interface 
    Con: history of holes in the engineering; 
    as LLVM matures expect the holes in the engineering to be plugged by adding 
    to the complexity of the interface
  
  C--

  
    Pro: target is an actual written language, 
    not an API; you can easily inspect, debug, and edit your C-- code 
    Pro: design is reasonably mature and 
    reasonably clean 
    Pro: supports accurate garbage 
    collection 
    Pro: most users report it is very easy to 
    use 
    Con: very small development team 
    Con: as of early 2009, supports only three 
    hardware platforms (x86, PPC, ARM) 
    Con: does not ship with a garbage 
    collector 
    Con: future of project is 
    uncertain
  
  C as target language

  
    Pro: looks easy 
    Con: nearly impossible to get decent 
    performance 
    Con: will drive you nuts in the long run; 
    ask the long line of people who have tried to compile Haskell, ML, Modula-3, 
    Scheme and more using this technique. At some point every one of these 
    people gave up and built their own native code 
generator.
Summary: anything except C is a 
reasonable choice. For the best combination of flexibility, quality, and 
expected longevity, I'd probably recommend LLVM. But your example code is very 
close to C--, so that may be an advantage.

Full disclosure: I am affiliated with the C-- 
project.



 

From: Jay K 
Sent: Saturday, July 18, 2015 10:27 AM
To: m3devel 
Subject: [M3devel] switching to C backend?
 

Any objection if I start switching targets to the C backend? 
 
In particular, Darwin does not support m3gdb, 
so debuggability is not a factor.
 
Thanks,
- Jay







_______________________________________________
M3devel mailing 
list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/60be99d8/attachment-0002.html>

From jay.krell at cornell.edu  Sat Jul 18 13:05:43 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 11:05:43 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
Message-ID: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>

so..I know there is a much better way to do this, but..


Currently every time we have a TRY, we pay both for a setjmpand a jmpbuf.m3-sys/m3tests/src/p2/p259 demonstrates this, and it is what I thoughtthe code was doing anyway -- m3front doesn't maintain per-functionstate related to TRY.

Ideally we defer to an underlying non-portable highly optimized form.

However, has anyone considered a form that does use setjmp butuses at most one frame per procedure, instead of a frame per TRY?

Oh -- and also, the jmpbuf isn't just a large size, but a pthread_getspecific/pthread_setspecfic.

Or, does anything think we stand a chance of soon transitioning completely away from setjmp/longjmp?

Thanks, - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/44be732c/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jul 19 00:17:03 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 18 Jul 2015 22:17:03 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
Message-ID: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>

I want to eliminate the knowledge of jmpbuf size from the frontend.This is an old goal that I failed at previously.

I believe I need to:
 Extend M3.CheckState to include jmpbuf_count. The various Try*.m3.Check increment it and store its previous value in the statement's state.   And then a few choices.  1)  At the start of a function, call alloca with that count times external variable jmpbuf_size, initialized in C. 
 At each try, multiply its index by external variable jmpbuf_size and add to the start of the buffer and use that.   or  also have an array of n pointers filled in by C and index into that, eliminating the runtime non-const multiplication   and/or
  include that array in the alloca even    having a "composite" not called simply "alloca" but "m3_alloc_jmpbufs",  which backends still have to special case to look kinda the same,  alloca being very special
    and/or
    add to functions themselves a notion of jmpbuf count, still the same  underlying mechanism..
      and/or also add a m3cg primitive "jmpbuf_ref(n)", which gets the address  of the n'th jmpbuf of the current function, i.e. building in the multiplication  by jmpbuf size.
      Note that some of these combinations of proposals imply an m3cg change.  All require at least a minimum of backend cooperation -- at least  recognizing "m3_alloca" as "alloca" or "_alloca" or "builtin_alloca" or such.
  
  Note that hopefully/ideally there is a much higher level way to do this,  whose design currently eludes me,  something that a backend could translate to setjmp/longjmp, or Win32 C __try,  or C++ try, or something. The "lowering" of try/finally in the frontend  is portable but very inefficient.
  
 Another solution is for the function to have an n-array of pointers or merely n locals, initialized to null, and have each TRY dynamically call alloca if the pointer isn't null.

 This reduces stack use for the case of IF...TRY.

 At the cost of extra initialization and the test and branch.

This is currently my favorite proposal so I should restate: have a local pointer for each TRY; initialized to null; at each TRY, if the pointer is null, call alloca(external jmpbuf_size). TRY is already super expensive in code size and speed. This solution adds a pointer per TRY and a test and conditional jmp. Multiplication is avoided. IF...TRY ends up using much less stack than before, if not executed, but most code will pay extra stack, a pointer per TRY. What I was missing before is that I need to extend M3.CheckState to count the jmpbufs and do some of the work at the start of the function, not merely at each TRY -- declare, and more importantly, initialize the pointers.
  Thoughts?
 

 Thanks, - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150718/6b1c1349/attachment-0002.html>

From hendrik at topoi.pooq.com  Sun Jul 19 01:21:40 2015
From: hendrik at topoi.pooq.com (Hendrik Boom)
Date: Sat, 18 Jul 2015 19:21:40 -0400
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>
Message-ID: <20150718232140.GA7577@topoi.pooq.com>

On Sat, Jul 18, 2015 at 10:17:03PM +0000, Jay K wrote:
> I want to eliminate the knowledge of jmpbuf size from the frontend.This is an old goal that I failed at previously.
> 
> I believe I need to:
>  Extend M3.CheckState to include jmpbuf_count. The various Try*.m3.Check increment it and store its previous value in the statement's state.   And then a few choices.  1)  At the start of a function, call alloca with that count times external variable jmpbuf_size, initialized in C. 
>  At each try, multiply its index by external variable jmpbuf_size and add to the start of the buffer and use that.   or  also have an array of n pointers filled in by C and index into that, eliminating the runtime non-const multiplication   and/or
>   include that array in the alloca even    having a "composite" not called simply "alloca" but "m3_alloc_jmpbufs",  which backends still have to special case to look kinda the same,  alloca being very special
>     and/or
>     add to functions themselves a notion of jmpbuf count, still the same  underlying mechanism..
>       and/or also add a m3cg primitive "jmpbuf_ref(n)", which gets the address  of the n'th jmpbuf of the current function, i.e. building in the multiplication  by jmpbuf size.
>       Note that some of these combinations of proposals imply an m3cg change.  All require at least a minimum of backend cooperation -- at least  recognizing "m3_alloca" as "alloca" or "_alloca" or "builtin_alloca" or such.
>   
>   Note that hopefully/ideally there is a much higher level way to do this,  whose design currently eludes me,  something that a backend could translate to setjmp/longjmp, or Win32 C __try,  or C++ try, or something. The "lowering" of try/finally in the frontend  is portable but very inefficient.
>   
>  Another solution is for the function to have an n-array of pointers or merely n locals, initialized to null, and have each TRY dynamically call alloca if the pointer isn't null.
> 
>  This reduces stack use for the case of IF...TRY.
> 
>  At the cost of extra initialization and the test and branch.
> 
> This is currently my favorite proposal so I should restate: have a local pointer for each TRY; initialized to null; at each TRY, if the pointer is null, call alloca(external jmpbuf_size). TRY is already super expensive in code size and speed. This solution adds a pointer per TRY and a test and conditional jmp. Multiplication is avoided. IF...TRY ends up using much less stack than before, if not executed, but most code will pay extra stack, a pointer per TRY. What I was missing before is that I need to extend M3.CheckState to count the jmpbufs and do some of the work at the start of the function, not merely at each TRY -- declare, and more importantly, initialize the pointers.
>   Thoughts?

Unless things have changed  recently, alloca() is not standard.

see the discussion and links in http://c-faq.com/malloc/alloca.html

That page also contains the sentence

Now that C99 supports variable-length arrays (VLA's), they can be used to more cleanly accomplish most of the tasks which alloca used to be put to.

Not clear at aall if the VLA's can be used for this.

>  
> 
>  Thanks, - Jay
> 
>  		 	   		  

> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel



From jay.krell at cornell.edu  Sun Jul 19 10:23:46 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 08:23:46 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <20150718232140.GA7577@topoi.pooq.com>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>,
 <20150718232140.GA7577@topoi.pooq.com>
Message-ID: <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>

alloca is very portable even if it is not in ANSI C or even Posix.

 gcc has builtin support for it. Win32 provides it, where it is called _alloca.The NT/amd64 ABI specifically accounts for it -- functions that callalloca must have a fixed "frame pointer" in a register other than rsp,so that rsp can be changed by calling alloca.
 clang/LLVM presumably provide it. A lot of code depends on it and it is generally easy to provide.
OpenVMS apparently calls it __ALLOCA.


For more complete portability to the C backend we couldadd an m3cg operation to allocate an array of jmpbufswith a constant count.

It is certainly more portable than C99, and C99 VLAs are kind of more general than I need.That is, I might pass a "variable" to alloca, but it is kind of a constant.

My last/current proposal though does do the allocation dynamically, which thism3cg operation would not provide for.

 - Jay



> Date: Sat, 18 Jul 2015 19:21:40 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?
>> 
> Unless things have changed  recently, alloca() is not standard.
> 
> see the discussion and links in http://c-faq.com/malloc/alloca.html
> 
> That page also contains the sentence
> 
> Now that C99 supports variable-length arrays (VLA's), they can be used to more cleanly accomplish most of the tasks which alloca used to be put to.
> 
> Not clear at aall if the VLA's can be used for this.
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/c9f7ac81/attachment-0002.html>

From estellnb at elstel.org  Sun Jul 19 10:44:15 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 10:44:15 +0200
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>,
 <20150718232140.GA7577@topoi.pooq.com>
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>
Message-ID: <55AB635F.9060809@elstel.org>


Am 2015-07-19 um 10:23 schrieb Jay K:
> alloca is very portable even if it is not in ANSI C or even Posix.
>
>
>  gcc has builtin support for it.
>  Win32 provides it, where it is called _alloca.
> The NT/amd64 ABI specifically accounts for it -- functions that call
> alloca must have a fixed "frame pointer" in a register other than rsp,
> so that rsp can be changed by calling alloca.
>
>  clang/LLVM presumably provide it.
>  A lot of code depends on it and it is generally easy to provide.
>
> OpenVMS apparently calls it __ALLOCA.
>
Basically if you plan to build jumpbuf support into m3cg you could
easily use a few assembly statements as well in order to achieve
what alloca does (independently from the operating system):

   mov %[e/r]sp, PTR VAR
   sub %[e/r]sp, JUMPBUF_SIZE

I am sure that similar workarounds would exist for any arch other
than x86 and AMD64.


>
> For more complete portability to the C backend we could
> add an m3cg operation to allocate an array of jmpbufs
> with a constant count.
Why allocate an array or external buffer of jump bufs?
We used to have a linked list interleaved on the stack.
This is fully sufficient and faster than an independent
memory area.

>
>
> It is certainly more portable than C99, and C99 VLAs are kind of more 
> general than I need.
> That is, I might pass a "variable" to alloca, but it is kind of a 
> constant.

If we have arrived at using something similar as alloca in m3cg why 
shouldn`t we provide
this functionality to the user? i.e. let programmers call such a 
function from high level M3
code in order to alloc variable length bufffers, arrays, etc.

VAR localvar := NEWA(MyType);

This is a functionality which I believe that is really missing in M3!!
When we implemented the algorithm of Strassen (saving some 
multiplications for matrix
mults.) we had to notice that everything goes much slower just because 
of the need for
garbage collection ...


- Elmar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/492899e3/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jul 19 10:56:55 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 08:56:55 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <55AB635F.9060809@elstel.org>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>, <55AB635F.9060809@elstel.org>
Message-ID: <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>

Merely subtracting the stack pointer isn't correct on all systems.At least on NT, stack pages must be touched in order without skipping any,for stack overflow exceptions to work correctly.There is a high water mark, so it isn't necessarily linear.


The array is local.The reason for an array is that each instance of a TRY currentlyuses its own jmpbuf.

So a function with n TRY's wants an array of n jmpbufs.

The elements are then indeed linked/unlinked by PushFrame/PopFrame,which are incredibly unoptimized, vs. for example native NT C or C++exception handling, and presumably other systems.

*Ideally* we'd have just one jmpbuf per function, at most, anda local "scope id" to differentiate where in the function we are,for finally/except to dispatch on.You can think of it is a line number, but there can be multiple per line,and they can be denser/smaller than line numbers.


NEWA: alloca is considered kind of dangerous, in that failureis difficult to recognize, or not portably recognizable and handlable.

However, that is the same as merely deep function calls.

So maybe.And we could smush the portability problem into our runtime.In particular, we could catch the exception on NT, fix up thepage (_resetstkovflw) and call calloc/malloc instead.

I don't know how to handle the situation on other systems though.

My current proposal doesn't use an array, but the most portableproposal would.

If people can do the work/research/testing for recognizing stack exhaustionon a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, NetBSD, NT,possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction in my mind.

But yes, safety and garbage collection are not free.If you want the best possible performance, use C or C++.

 - Jay


Date: Sun, 19 Jul 2015 10:44:15 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:23 schrieb Jay K:

    
    
      
      
        alloca is very portable even if it is not in ANSI C or even
          Posix.
        

        
        

        
         gcc has builtin support for it.
         Win32 provides it, where
            it is called _alloca.
        The NT/amd64 ABI
            specifically accounts for it -- functions that call
        alloca must have a fixed
            "frame pointer" in a register other than rsp,
        so that rsp can be changed
            by calling alloca.
        

          
         clang/LLVM presumably
            provide it.
         A lot of code depends on
            it and it is generally easy to provide.
        

          
        OpenVMS apparently calls it
            __ALLOCA.
        

        
      
    
    Basically if you plan to build jumpbuf support into m3cg you could

    easily use a few assembly statements as well in order to achieve 

    what alloca does (independently from the operating system):

    

      mov %[e/r]sp, PTR VAR

      sub %[e/r]sp, JUMPBUF_SIZE 

    

    I am sure that similar workarounds would exist for any arch other

    than x86 and AMD64.

    

    

    
      
        

        
        For more complete portability to the C backend we could
        add an m3cg operation to allocate an array of jmpbufs
        with a constant count.
      
    
    Why allocate an array or external buffer of jump bufs?

    We used to have a linked list interleaved on the stack.

    This is fully sufficient and faster than an independent 

    memory area.

    

    
      
        

        
        

        
        It is certainly more portable than C99, and C99 VLAs are
          kind of more general than I need.
        That is, I might pass a "variable" to alloca, but it is
          kind of a constant.
      
    
    

    If we have arrived at using something similar as alloca in m3cg why
    shouldn`t we provide

    this functionality to the user? i.e. let programmers call such a
    function from high level M3 

    code in order to alloc variable length bufffers, arrays, etc.

    

    VAR localvar := NEWA(MyType);

    

    This is a functionality which I believe that is really missing in
    M3!!

    When we implemented the algorithm of Strassen (saving some
    multiplications for matrix

    mults.) we had to notice that everything goes much slower just
    because of the need for

    garbage collection ...

    

    

    - Elmar

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/5e3deb52/attachment-0002.html>

From estellnb at elstel.org  Sun Jul 19 10:57:11 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 10:57:11 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
Message-ID: <55AB6667.7010908@elstel.org>


Am 2015-07-18 um 13:05 schrieb Jay K:
>
> However, has anyone considered a form that does use setjmp but
> uses at most one frame per procedure, instead of a frame per TRY?

I don`t think that this will work for the general case.
Consider a try - except in the middle of a code block.
If you leave it, it needs to continue after the END of
the TRY-EXCEPT and not after the END of the
procedure.

What you can do is re-use the same jumpbuf-frame
for a nested try-finally and try - except :

  TRY
     TRY
       ...
      EXCEPT
       ...
      END;
   FINALLY
     ...
   END;

or simply

   TRY
     ....
   EXCEPT
     ....
   FINALLY
    ...
   END;

I can remember having once implemented the latter for PM3.
However I am no more sure about the intrinsics...




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/906c5b3c/attachment-0002.html>

From estellnb at elstel.org  Sun Jul 19 11:10:20 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 11:10:20 +0200
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>,
 <55AB635F.9060809@elstel.org> <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>
Message-ID: <55AB697C.7090109@elstel.org>


Am 2015-07-19 um 10:56 schrieb Jay K:
> Merely subtracting the stack pointer isn't correct on all systems.
> At least on NT, stack pages must be touched in order without skipping any,
> for stack overflow exceptions to work correctly.
> There is a high water mark, so it isn't necessarily linear.

Would that mind if the stack exception was generated somewhat
later when the jumpbuf actually becomes accessed?
I would believe no.

>
> NEWA: alloca is considered kind of dangerous, in that failure
> is difficult to recognize, or not portably recognizable and handlable.

The same stack overflow exception can be generated by any
procedure call so that I do not see why it should be that
dangerous. In the overwhelming majority of cases this should
be handled as gracefully as an extension of the heap on NEW:
simply map a new memory page as long as there is enough
free virtual address space.


>
> If people can do the work/research/testing for recognizing stack 
> exhaustion
> on a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, 
> NetBSD, NT,
> possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction 
> in my mind.
As we are planning a new realease I would believe that your new
alterations would become tested shortly.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/0c600193/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jul 19 11:10:53 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 09:10:53 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB6667.7010908@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
Message-ID: <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>

I'm pretty sure it can work, but you need also a local "dense" volatile integer that describes where in the function you are.  That isn't free, but it is much cheaper than calling setjmp/PushFrame for each try.

Try writing similar C++ for NT/x86 and look at what you get."PushFrame" is highly optimized to build a linked list through fs:0.And even that is only done at most once per function.

Java VM also specifies scope tables with a similar intent.

The key is figuring out the algorithm to assign the scope ids, and computing and interpreting the resulting tables. It is a little tricky.

 - Jay


Date: Sun, 19 Jul 2015 10:57:11 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?


  
    
  
  
    

    Am 2015-07-18 um 13:05 schrieb Jay K:

    
    
      
      
        

        
        However, has anyone considered a form that does use setjmp
          but
        uses at most one frame per procedure, instead of a frame
          per TRY?
      
    
    

    I don`t think that this will work for the general case.

    Consider a try - except in the middle of a code block.

    If you leave it, it needs to continue after the END of

    the TRY-EXCEPT and not after the END of the 

    procedure.

    

    What you can do is re-use the same jumpbuf-frame

    for a nested try-finally and try - except :

    

     TRY

        TRY

          ...

         EXCEPT

          ...

         END;

      FINALLY

        ...

      END;

    

    or simply

    

      TRY

        ....

      EXCEPT

        ....

      FINALLY

       ...

      END;

    

    I can remember having once implemented the latter for PM3.

    However I am no more sure about the intrinsics...

    

    

    

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/c2b31d95/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jul 19 11:18:02 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 09:18:02 +0000
Subject: [M3devel] elimination of jmpbuf size from cm3 frontend?
In-Reply-To: <55AB697C.7090109@elstel.org>
References: <COL130-W924D6A702E9CD198F3B32E6870@phx.gbl>, ,
 <20150718232140.GA7577@topoi.pooq.com>,
 <COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl>, <55AB635F.9060809@elstel.org>,
 <COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl>, <55AB697C.7090109@elstel.org>
Message-ID: <COL130-W2ED3E35017B6A73F03CC0E6860@phx.gbl>

The stack pages must be touched in order.

It cannot be dynamically ordered in such a way that pages are skipped.It is much easier to have a static order than worry about getting a dynamic order correct.

That is, sure, you can do some large subtract all at once,but you must not skip around in the order the pages are touched.

You can defer the exception until the jmpbuf is touched,and you can get away without touching any, but whatever youtouch, must be in order.

The solution is simple though -- actually call _alloca.It gets it right.

Imagine this:
jmpbuf bufs[n];while (1)    switch (srand() % n)    {    case 0: TRY ...  break;    case 1: TRY ...  break;    case 2: TRY ...  break;    case 3: TRY ...  break;    }}

that wouldn't work properly w/o a bit of extra code.

On NT, if you write a function with more than a page of locals,the start of the function calls chkstk, which is another name for alloca,to be sure to touch the page(s).

Because, imagine you have a function with more than a page of locals,that the first thing it does is call another function. The pushing of thereturn address will touch the stack, but possibly skip a page.

If you just have lots of functions with less than a page of locals,the pushing of return addresses to make further calls is what touchesthe pages.

It is easy to see in the generated code.We likely have a bug here in NT/x86 *forever*.It is fixed in the C backend. :)The C compiler knows the rules, and is heavily used, where the NT/x86 backend does/is not.

 - Jay



Date: Sun, 19 Jul 2015 11:10:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:56 schrieb Jay K:

    
    
      
      
        Merely subtracting the stack pointer isn't correct on all
          systems.
        At least on NT, stack pages must be touched in order
          without skipping any,
        for stack overflow exceptions to work correctly.
        There is a high water mark, so it isn't necessarily linear.
      
    
    

    Would that mind if the stack exception was generated somewhat 

    later when the jumpbuf actually becomes accessed?

    I would believe no.

    

    
      
        

        
        NEWA: alloca is considered kind of dangerous, in that
          failure
        is difficult to recognize, or not portably recognizable and
          handlable.
      
    
    

    The same stack overflow exception can be generated by any 

    procedure call so that I do not see why it should be that 

    dangerous. In the overwhelming majority of cases this should

    be handled as gracefully as an extension of the heap on NEW:

    simply map a new memory page as long as there is enough

    free virtual address space.

    

    

    
      
        

        
        If people can do the work/research/testing for recognizing
          stack exhaustion
        on a decent set of systems -- Linux, Solaris, FreeBSD,
          OpenBSD, NetBSD, NT,
        possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain
          traction in my mind.
      
    
    As we are planning a new realease I would believe that your new 

    alterations would become tested shortly.

    

    

    

    

    

    

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/73fe76fe/attachment-0002.html>

From estellnb at elstel.org  Sun Jul 19 11:38:25 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 11:38:25 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
Message-ID: <55AB7011.9070709@elstel.org>


Am 2015-07-19 um 11:10 schrieb Jay K:
> I'm pretty sure it can work, but you need also a local "dense" 
> volatile integer that describes where in the function you are.  That 
> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
> each try.
>
Is it really that much faster? I can remember having implemented my own 
setjump/longjump in assembly some time ago and it should only save you 
one procedure call but generate some additional jumps. However I do not 
know how time costly the new-fashioned register value obfuscation is 
(registers are no more stored as they are but obfuscated for security 
reasons by glibc). Xor-ing by a simple value; does it really cost the 
world? I am not the one who can tell you whether such a venture like 
this would pay off ...


>
> Try writing similar C++ for NT/x86 and look at what you get.
> "PushFrame" is highly optimized to build a linked list through fs:0.
> And even that is only done at most once per function.

Through fs:0 ? It used to be on the ss:[e/r]b in former times.
Since pthreading it may also be fs:0 under Linux because of get/setspecific.
I am not sure what these functions do in detail (something with fs at last).

Nonetheless I would believe that avoiding to call get/setspecific could 
speed
things up noticeably. First there is the function overhead, second we 
need to
touch an independent memory area and last but not least the stack is
always thread local. However I am not sure on how we could place the top
anchor for the linked list of exception frames otherwise. Push an exception
  frame pointer into every local variable area?

>
>
> Java VM also specifies scope tables with a similar intent.

However Java is not known for speed wonders ...


>
>
> The key is figuring out the algorithm to assign the scope ids, and 
> computing and interpreting the resulting tables. It is a little tricky.
>


Am 2015-07-19 um 11:18 schrieb Jay K:
> The stack pages must be touched in order...

Thanks a lot for an elaborate discussion of this!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/bc13a4ff/attachment-0002.html>

From estellnb at elstel.org  Sun Jul 19 12:06:20 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 12:06:20 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB7011.9070709@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl> <55AB7011.9070709@elstel.org>
Message-ID: <55AB769C.2020806@elstel.org>


Am 2015-07-19 um 11:38 schrieb Elmar Stellnberger:
>
> Am 2015-07-19 um 11:10 schrieb Jay K:
>> I'm pretty sure it can work, but you need also a local "dense" 
>> volatile integer that describes where in the function you are.  That 
>> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
>> each try.
>>
> Is it really that much faster? I can remember having implemented my 
> own setjump/longjump in assembly some time ago and it should only save 
> you one procedure call but generate some additional jumps. However I 
> do not know how time costly the new-fashioned register value 
> obfuscation is (registers are no more stored as they are but 
> obfuscated for security reasons by glibc). Xor-ing by a simple value; 
> does it really cost the world? I am not the one who can tell you 
> whether such a venture like this would pay off ...
>
>

You are right. It would be somewhat faster especially on AMD64 where we 
have a lot of registers to rescue ...


>>
>> Try writing similar C++ for NT/x86 and look at what you get.
>> "PushFrame" is highly optimized to build a linked list through fs:0.
>> And even that is only done at most once per function.
>
> Through fs:0 ? It used to be on the ss:[e/r]b in former times.
> Since pthreading it may also be fs:0 under Linux because of 
> get/setspecific.
> I am not sure what these functions do in detail (something with fs at 
> last).
>
> Nonetheless I would believe that avoiding to call get/setspecific 
> could speed
> things up noticeably. First there is the function overhead, second we 
> need to
> touch an independent memory area and last but not least the stack is
> always thread local. However I am not sure on how we could place the top
> anchor for the linked list of exception frames otherwise. Push an 
> exception
>  frame pointer into every local variable area?

However I believe this should also be worth a consideration as soon as 
we talk about m3cg support and speed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/ed02d46b/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jul 19 12:19:13 2015
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 19 Jul 2015 10:19:13 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB769C.2020806@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>, <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
 <55AB7011.9070709@elstel.org>,<55AB769C.2020806@elstel.org>
Message-ID: <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>

NT/x86 is the slow one.Still much faster than Modula-3.

There is a linked list through fs:0.fs:0 is thread local.For code speed, the link/unlink can be inlined.For code size, it can be a small function call.Just like two instructions for function enter and exit.And set a local volatile "as scopes are crossed".

locals used in the except/finallyblock are not likely enregistered across calls.

Compare this with current Modula-3:

 pthread_getspecific (TlsGetValue)  to get the current head  link it in  setjmp 
  And this happens for every TRY, instead of just at most once per function. 
The fs:0 link/unlink is at most once per function.

And all the other NT platforms are faster.

They don't link/unlink anything.They have metadata describing prologs.The runtime can use that to restore nonvolatile registers (includingthe stack) at any point.The codegen is somewhat constrained -- to be describable,but I suspect what you can describe encompasses anythinga compiler would want to do.Leaf functions have no data, and can't change nonvolatile registers,including rsp, and they can't make any calls (which would change rsp).

The tables are found from the return address.The only dynamic data the runtime has to leave aroundis the actual return address. No linked list, no volatile localindicating position in the function.

fs:0 is the NT/x86 location.This is a highly optimized thread local (fiber local actually).I don't know what other ABIs use, if anything -- again, all the otherNT platforms have no linked list, just return addresses and metadata.


Notes:The non-x86 approach is sometimes referred to as "no overhead", as "TRY" doesn't do anything (exceptleave cold data around).X86 exception dispatch is faster than non-x86. The stack is faster to walk, through the fs:0 linked list.The premise is that exception dispatch can be slow.The non exceptional paths are what should be optimized.And again, even NT/x86 is much more optimized than what Modula-3 does.


 - Jay



Date: Sun, 19 Jul 2015 12:06:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?


  
    
  
  
    

    Am 2015-07-19 um 11:38 schrieb Elmar
      Stellnberger:

    
    
      
      

      Am 2015-07-19 um 11:10 schrieb Jay K:

      
      
        
        I'm pretty sure it can work, but you need also a
          local "dense" volatile integer that describes where in the
          function you are.  That isn't free, but it is much cheaper
          than calling setjmp/PushFrame for each try.
          

          
        
      
      Is it really that much faster? I can remember having implemented
      my own setjump/longjump in assembly some time ago and it should
      only save you one procedure call but generate some additional
      jumps. However I do not know how time costly the new-fashioned
      register value obfuscation is (registers are no more stored as
      they are but obfuscated for security reasons by glibc). Xor-ing by
      a simple value; does it really cost the world? I am not the one
      who can tell you whether such a venture like this would pay off
      ...

      

      

    
    

    You are right. It would be somewhat faster especially on AMD64 where
    we have a lot of registers to rescue ...

    

    

    
      
        
          

          
          Try writing similar C++ for NT/x86 and look at what you
            get.
          "PushFrame" is highly optimized to build a linked list
            through fs:0.
          And even that is only done at most once per function.
        
      
      

      Through fs:0 ? It used to be on the ss:[e/r]b in former times.

      Since pthreading it may also be fs:0 under Linux because of
      get/setspecific.

      I am not sure what these functions do in detail (something with fs
      at last).

      

      Nonetheless I would believe that avoiding to call get/setspecific
      could speed

      things up noticeably. First there is the function overhead, second
      we need to

      touch an independent memory area and last but not least the stack
      is 

      always thread local. However I am not sure on how we could place
      the top

      anchor for the linked list of exception frames otherwise. Push an
      exception

       frame pointer into every local variable area?

    
    

    However I believe this should also be worth a consideration as soon
    as we talk about m3cg support and speed.

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/d27e2d99/attachment-0002.html>

From estellnb at elstel.org  Sun Jul 19 14:02:24 2015
From: estellnb at elstel.org (Elmar Stellnberger)
Date: Sun, 19 Jul 2015 14:02:24 +0200
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>,
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl> <55AB7011.9070709@elstel.org>,
 <55AB769C.2020806@elstel.org> <COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
Message-ID: <55AB91D0.80303@elstel.org>


Am 2015-07-19 um 12:19 schrieb Jay K:
> And all the other NT platforms are faster.
> They don't link/unlink anything.
> They have metadata describing prologs.
> The runtime can use that to restore nonvolatile registers (including
> the stack) at any point.

including NT-AMD64 or not? -
but PowerPC, MIPS, Alpha, Itanium and ARM?

interesting. What happens if I have a variable being kept in a register
like register int x? These registers would still need to be saved as
a prolog could never tell us (i.e. we would then again need a linked
list) ...

... and then if we have prologues we would not need to pin down
any word that could refer as a refany to the traced heap in our
locales area but only those which really do (The question is of
course what data is in these prologues and what data is not.).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/59daae07/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jul 19 19:46:36 2015
From: jay.krell at cornell.edu (Jay)
Date: Sun, 19 Jul 2015 10:46:36 -0700
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <55AB91D0.80303@elstel.org>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>
 <55AB6667.7010908@elstel.org> <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>
 <55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org>
 <COL130-W98F71B1447317E3FAF027E6860@phx.gbl> <55AB91D0.80303@elstel.org>
Message-ID: <F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>

NT/amd64 & likely all NT architectures except x86: The pdata gives function boundaries and the xdata provides information to restore nonvolatile registers, including rsp and return address. Locals may be enregistered across function calls in nonvolatile registers. 


There is no linked list.
There is a reliable stack walker including restoring nonvolatile registers provided by ther operating system (RtlUnwind, RtlVirtualUnwind).


 - Jay

On Jul 19, 2015, at 5:02 AM, Elmar Stellnberger <estellnb at elstel.org> wrote:

> 
> Am 2015-07-19 um 12:19 schrieb Jay K:
>> And all the other NT platforms are faster.
>> They don't link/unlink anything.
>> They have metadata describing prologs.
>> The runtime can use that to restore nonvolatile registers (including
>> the stack) at any point.
> 
> including NT-AMD64 or not? - 
> but PowerPC, MIPS, Alpha, Itanium and ARM?
> 
> interesting. What happens if I have a variable being kept in a register
> like register int x? These registers would still need to be saved as 
> a prolog could never tell us (i.e. we would then again need a linked 
> list) ...
> 
> ... and then if we have prologues we would not need to pin down
> any word that could refer as a refany to the traced heap in our 
> locales area but only those which really do (The question is of
> course what data is in these prologues and what data is not.).
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/60d15479/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jul 20 09:21:18 2015
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 20 Jul 2015 07:21:18 +0000
Subject: [M3devel] frame per procedure instead of frame per TRY?
In-Reply-To: <F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>
References: <COL130-W5029CFBDDFEF7AF47CB19BE6870@phx.gbl>,
 <55AB6667.7010908@elstel.org>
 <COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl>,<55AB7011.9070709@elstel.org>
 <55AB769C.2020806@elstel.org>,<COL130-W98F71B1447317E3FAF027E6860@phx.gbl>
 <55AB91D0.80303@elstel.org>,<F42A0A53-4762-4EC1-A80F-8FE9DD7B8E29@gmail.com>
Message-ID: <COL130-W47FB963569F6C12D414571E6850@phx.gbl>

ps: translating to C for Win32 or C++ for any targets nets you whatever is the local optimized exception handling runtime, including certainly this stuff on NT.
Sometimes that might merely be a similar setjmp/longjmp based system, but often not.
But we need higher level m3cg operations for exception handling to do this (or some awful reverse induction in the backend..)
 - Jay


From: jay.krell at cornell.edu
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] frame per procedure instead of frame per TRY?
Date: Sun, 19 Jul 2015 10:46:36 -0700
To: estellnb at elstel.org

NT/amd64 & likely all NT architectures except x86: The pdata gives function boundaries and the xdata provides information to restore nonvolatile registers, including rsp and return address. Locals may be enregistered across function calls in nonvolatile registers. 

There is no linked list.There is a reliable stack walker including restoring nonvolatile registers provided by ther operating system (RtlUnwind, RtlVirtualUnwind).

 - Jay
On Jul 19, 2015, at 5:02 AM, Elmar Stellnberger <estellnb at elstel.org> wrote:


  
    
  
  
    

    Am 2015-07-19 um 12:19 schrieb Jay K:

    
    
      
      
        And all the other NT platforms are faster.
      
    
    
      
        They don't link/unlink anything.
        They have metadata describing prologs.
        The runtime can use that to restore nonvolatile registers
          (including
        the stack) at any point.
      
    
    

    including NT-AMD64 or not? - 

    but PowerPC, MIPS, Alpha, Itanium and ARM?

    

    interesting. What happens if I have a variable being kept in a
    register

    like register int x? These registers would still need to be saved as
    

    a prolog could never tell us (i.e. we would then again need a linked
    

    list) ...

    

    ... and then if we have prologues we would not need to pin down

    any word that could refer as a refany to the traced heap in our 

    locales area but only those which really do (The question is of

    course what data is in these prologues and what data is not.).

    

    

    

  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150720/8c45a67f/attachment-0002.html>

From rodney_bates at lcwb.coop  Tue Jul 21 18:21:22 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 21 Jul 2015 11:21:22 -0500
Subject: [M3devel] O(1) FIFO wakeup of waiters on both Mutexs and Conditions
Message-ID: <55AE7182.3060709@lcwb.coop>

I just committed and pushed the subject change.  It could probably use more
testing.  It has shown no problems with m3-libs/m3core/tests/thread, for a
few combinations of thread count and iteration count.

I committed the old version as ThreadPThread0.m3, so it can be reverted
quickly, if bugs show up.  Look in the m3makefile to switch by simple
commenting in and out.

New or old version, it will require recompiles and ships of everything
in the closure of a main program to try it.


-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Wed Jul 22 07:42:29 2015
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 22 Jul 2015 05:42:29 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
Message-ID: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>

In the C backend I have a notion of "weak struct types" and "strong struct types".

"Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.

"Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.


Originally I had only weak types.Ideally I have no weak types.I'm down to very few weak types now.I'd like to finish eliminating weak types.


A quick investigation shows weak types come from open arrays and jmpbufs.Open array temporaries from SUBARRAY specifically.


Can we fix this?


We have:m3front/src/types/OpenArrayType.m3:
PROCEDURE DeclareTemp (t: Type.T): CG.Var =  VAR    p    := Reduce (t);    size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;  BEGIN    RETURN CG.Declare_temp (size, Target.Address.align,                            CG.Type.Struct, in_memory := TRUE);  END DeclareTemp;

PROCEDURE Compiler (p: P) =  VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;  BEGIN    Type.Compile (p.element);    CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);  END Compiler;

DeclareTemp is used in SUBARRAY expressions -- truly temporaries,not variables authored by anyone in Modula-3.

Can this be easily fixed?

Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150722/b0e622c2/attachment-0002.html>

From rodney_bates at lcwb.coop  Thu Jul 23 02:30:12 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 22 Jul 2015 19:30:12 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>
Message-ID: <55B03594.20800@lcwb.coop>

I'm not exactly sure what you are asking, but here is some light on what
you are seeing.  These temporaries are exactly the dope the compiler uses
to represent all open array values.  First a pointer to the zeroth
array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
an array of element counts for each open subscript.  For an open array
parameter, this would be the machine representation of the parameter
itself, authored in M3. (but passed by reference.)  For a heap object,
it is stored right before the elements themselves.  For a SUBARRAY
expression, it has to be a temporary.  It also has to be constructed
at the call site, as an anonymous temporary, when passing an entire fixed
array to an open array parameter

So, a good type for it might look like:


RECORD
   Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
END

Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
static limit here in the type of Elements, as it will be enforced dynamically,
using Shape.  But we don't want to just say REF ARRAY OF ElementType either,
as this would mean another open array inside the dope, resulting in infinite
recursion.

On 07/22/2015 12:42 AM, Jay K wrote:
> In the C backend I have a notion of "weak struct types" and "strong struct types".
>
>
> "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>
>
> "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>
>
>
> Originally I had only weak types.
> Ideally I have no weak types.
> I'm down to very few weak types now.
> I'd like to finish eliminating weak types.
>
>
>
> A quick investigation shows weak types come from open arrays and jmpbufs.
> Open array temporaries from SUBARRAY specifically.
>
>
>
> Can we fix this?
>
>
>
> We have:
> m3front/src/types/OpenArrayType.m3:
>
> PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>    VAR
>      p    := Reduce (t);
>      size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>    BEGIN
>      RETURN CG.Declare_temp (size, Target.Address.align,
>                              CG.Type.Struct, in_memory := TRUE);
>    END DeclareTemp;
>
>
> PROCEDURE Compiler (p: P) =
>    VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>    BEGIN
>      Type.Compile (p.element);
>      CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>    END Compiler;
>
>
> DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> not variables authored by anyone in Modula-3.
>
>
> Can this be easily fixed?
>
>
> Thanks,
>   - Jay
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Fri Jul 24 10:57:14 2015
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 24 Jul 2015 08:57:14 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <55B03594.20800@lcwb.coop>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>,
 <55B03594.20800@lcwb.coop>
Message-ID: <COL130-W78229587075BD6B3A94050E6810@phx.gbl>

I model this in C like:

M3C.m3:        print(self, "/*declare_open_array*/typedef struct {");        print(self, element_type.text);        print(self, "* _elts; CARDINAL _size");        IF bit_size > Target.Integer.size * 2 THEN            print(self, "s[");            print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));            print(self, "]");        END;

that is..and this i stinky that I get the struct "size",

size == 2 * sizeof(integer):

struct {T* elementssize_t size;}

else: N = size - sizeof(INTEGER) / sizeof(INTEGER) T ** elements; // where the number of star is N  size_t sizes[N]

It is kind of lame that the frontend just gives the overall sizeand the backend is just left to assume the layout like that.
Really, the frontend should declare a type "pointer to pointer to pointer" withthe right "depth", and then a record with that pointer and a size or fixed size array of sizes.

Again, really ugly how it works now where backend is just given a size and can onlyassume the layout.
I don't know what a "dope vector" is. A value used as an initializer?

It is even worse for subarray. In this case we aren't even told it is an open array, justsome random struct with a size. That is what I first want to fix. It should declare an open array,assuming they do have the same layout, which I think they do.

subarray temporaries and jmpbufs are I believe the only place the frontend passes so littletype information.

For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace themwith #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.



 - Jay


> Date: Wed, 22 Jul 2015 19:30:12 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> 
> I'm not exactly sure what you are asking, but here is some light on what
> you are seeing.  These temporaries are exactly the dope the compiler uses
> to represent all open array values.  First a pointer to the zeroth
> array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
> an array of element counts for each open subscript.  For an open array
> parameter, this would be the machine representation of the parameter
> itself, authored in M3. (but passed by reference.)  For a heap object,
> it is stored right before the elements themselves.  For a SUBARRAY
> expression, it has to be a temporary.  It also has to be constructed
> at the call site, as an anonymous temporary, when passing an entire fixed
> array to an open array parameter
> 
> So, a good type for it might look like:
> 
> 
> RECORD
>    Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
> ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
> END
> 
> Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
> static limit here in the type of Elements, as it will be enforced dynamically,
> using Shape.  But we don't want to just say REF ARRAY OF ElementType either,
> as this would mean another open array inside the dope, resulting in infinite
> recursion.
> 
> On 07/22/2015 12:42 AM, Jay K wrote:
> > In the C backend I have a notion of "weak struct types" and "strong struct types".
> >
> >
> > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
> >
> >
> > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
> >
> >
> >
> > Originally I had only weak types.
> > Ideally I have no weak types.
> > I'm down to very few weak types now.
> > I'd like to finish eliminating weak types.
> >
> >
> >
> > A quick investigation shows weak types come from open arrays and jmpbufs.
> > Open array temporaries from SUBARRAY specifically.
> >
> >
> >
> > Can we fix this?
> >
> >
> >
> > We have:
> > m3front/src/types/OpenArrayType.m3:
> >
> > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
> >    VAR
> >      p    := Reduce (t);
> >      size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >    BEGIN
> >      RETURN CG.Declare_temp (size, Target.Address.align,
> >                              CG.Type.Struct, in_memory := TRUE);
> >    END DeclareTemp;
> >
> >
> > PROCEDURE Compiler (p: P) =
> >    VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >    BEGIN
> >      Type.Compile (p.element);
> >      CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
> >    END Compiler;
> >
> >
> > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> > not variables authored by anyone in Modula-3.
> >
> >
> > Can this be easily fixed?
> >
> >
> > Thanks,
> >   - Jay
> >
> >
> >
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150724/9fc74156/attachment-0002.html>

From rodney_bates at lcwb.coop  Fri Jul 24 16:57:37 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 24 Jul 2015 09:57:37 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W78229587075BD6B3A94050E6810@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>,
 <55B03594.20800@lcwb.coop>
 <COL130-W78229587075BD6B3A94050E6810@phx.gbl>
Message-ID: <55B25261.5010106@lcwb.coop>



On 07/24/2015 03:57 AM, Jay K wrote:
> I model this in C like:
>
>
> M3C.m3:
>          print(self, "/*declare_open_array*/typedef struct {");

Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?

>          print(self, element_type.text);
>          print(self, "* _elts; CARDINAL _size");
>          IF bit_size > Target.Integer.size * 2 THEN
>              print(self, "s[");
>              print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
>              print(self, "]");
>          END;
>
>
> that is..and this i stinky that I get the struct "size",
>
>
> size == 2 * sizeof(integer):
>
>
> struct {
> T* elements
> size_t size;
> }
>
>
> else:
>   N = size - sizeof(INTEGER) / sizeof(INTEGER)
>   T ** elements; // where the number of star is N

I would not do pointer to pointer to pointer ... here.  Just "T* elements", regardless
of the number of open dimensions.  As I understand them, C's language-supported
multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
the language does the multi-subscript address arithmetic, which means the type
system needs to provide a static element size of each dimension.  And that,
except for the innermost, depends on the element count of the next inner
dimension, which is not static here.

So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
is lowered by the front end into explicit address arithmetic into the flattened
array, using the values in the shape.  Something like A[I*Shape[0]+J*Shape[1]+K]

>    size_t sizes[N]
>
>
> It is kind of lame that the frontend just gives the overall size
> and the backend is just left to assume the layout like that.

If you know in M3C that it's an open array, you can infer what the layout is.
But yes, it's kind of lame.  This is just another of the several places we have
seen that the front end has lowered things too far, and you have to
You know it's generated by code in OpenArray.m3, and you know the general dope layout,
and open dimension count, so you can generate an appropriate type.


>
> Really, the frontend should declare a type "pointer to pointer to pointer" with
> the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
>
>
> Again, really ugly how it works now where backend is just given a size and can only
> assume the layout.
>
> I don't know what a "dope vector" is. A value used as an initializer?
>

This is a very old and rather uninformative term for any block of stuff stored at runtime
that describes some source programmer's real data and how to access it.  The only alternative
term I can think of would be "metadata", although that is rather overgeneral, and is usually
used with quite different specific meanings.  But it is data describing data.

>
> It is even worse for subarray. In this case we aren't even told it is an open array, just
> some random struct with a size. That is what I first want to fix. It should declare an open array,
> assuming they do have the same layout, which I think they do.
>

What you really need to know is that it's an open array, of which subarray is a subcategory.
In our implementation, all open array values have the same dope.  E.g., look for the case where
a fixed array actual parameter is passed to an open array formal.

>
> subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
> type information.
>
>
> For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
> with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
>
>
>
>
>   - Jay
>
>
>  > Date: Wed, 22 Jul 2015 19:30:12 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  >
>  > I'm not exactly sure what you are asking, but here is some light on what
>  > you are seeing. These temporaries are exactly the dope the compiler uses
>  > to represent all open array values. First a pointer to the zeroth
>  > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
>  > an array of element counts for each open subscript. For an open array
>  > parameter, this would be the machine representation of the parameter
>  > itself, authored in M3. (but passed by reference.) For a heap object,
>  > it is stored right before the elements themselves. For a SUBARRAY
>  > expression, it has to be a temporary. It also has to be constructed
>  > at the call site, as an anonymous temporary, when passing an entire fixed
>  > array to an open array parameter
>  >
>  > So, a good type for it might look like:
>  >
>  >
>  > RECORD
>  > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
>  > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
>  > END
>  >
>  > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
>  > static limit here in the type of Elements, as it will be enforced dynamically,
>  > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
>  > as this would mean another open array inside the dope, resulting in infinite
>  > recursion.
>  >
>  > On 07/22/2015 12:42 AM, Jay K wrote:
>  > > In the C backend I have a notion of "weak struct types" and "strong struct types".
>  > >
>  > >
>  > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>  > >
>  > >
>  > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>  > >
>  > >
>  > >
>  > > Originally I had only weak types.
>  > > Ideally I have no weak types.
>  > > I'm down to very few weak types now.
>  > > I'd like to finish eliminating weak types.
>  > >
>  > >
>  > >
>  > > A quick investigation shows weak types come from open arrays and jmpbufs.
>  > > Open array temporaries from SUBARRAY specifically.
>  > >
>  > >
>  > >
>  > > Can we fix this?
>  > >
>  > >
>  > >
>  > > We have:
>  > > m3front/src/types/OpenArrayType.m3:
>  > >
>  > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>  > > VAR
>  > > p := Reduce (t);
>  > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > BEGIN
>  > > RETURN CG.Declare_temp (size, Target.Address.align,
>  > > CG.Type.Struct, in_memory := TRUE);
>  > > END DeclareTemp;
>  > >
>  > >
>  > > PROCEDURE Compiler (p: P) =
>  > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > BEGIN
>  > > Type.Compile (p.element);
>  > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>  > > END Compiler;
>  > >
>  > >
>  > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
>  > > not variables authored by anyone in Modula-3.
>  > >
>  > >
>  > > Can this be easily fixed?
>  > >
>  > >
>  > > Thanks,
>  > > - Jay
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > > M3devel mailing list
>  > > M3devel at elegosoft.com
>  > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  > >
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Sat Jul 25 18:39:45 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 25 Jul 2015 11:39:45 -0500
Subject: [M3devel] Strange CM3 IR for FINALLY
Message-ID: <55B3BBD1.7040203@lcwb.coop>

In looking at CM3 IR for TRY-FINALLY, for an unrelated reason, I find the following:

The front end translates the code found between FINALLY and END into a nested procedure.
This is declared as having one parameter of type ADDRESS.  But, in the the direct call
it generates, right before the FINALLY, it passes no actual.  Also, in the simple example
I looked at, the finally procedure does not access its formal.

It also stores the address of the finally procedure in a 5-word record whose address
it passes to RTHooks.PushEFrame and PopEFrame.  RTHooks.i3 treats this as ADDRESS, and
tells us nothing about what it actually points to.

Is there a bug, or does anybody understand what is going on here?
-- 
Rodney Bates
rodney.m.bates at acm.org


From peter.mckinna at gmail.com  Sun Jul 26 03:02:35 2015
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 26 Jul 2015 11:02:35 +1000
Subject: [M3devel] Strange CM3 IR for FINALLY
In-Reply-To: <55B3BBD1.7040203@lcwb.coop>
References: <55B3BBD1.7040203@lcwb.coop>
Message-ID: <CAEy6uxpjkVbMtHwF+=AqfmFs32F3DT0pjMeZqy0QBbbt3DSXXA@mail.gmail.com>

Theres a comment at about line 216 in TryFinStmt.m3 that suggests the
authors were not too sure about this either.

Regards Peter.

On Sun, Jul 26, 2015 at 2:39 AM, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:

> In looking at CM3 IR for TRY-FINALLY, for an unrelated reason, I find the
> following:
>
> The front end translates the code found between FINALLY and END into a
> nested procedure.
> This is declared as having one parameter of type ADDRESS.  But, in the the
> direct call
> it generates, right before the FINALLY, it passes no actual.  Also, in the
> simple example
> I looked at, the finally procedure does not access its formal.
>
> It also stores the address of the finally procedure in a 5-word record
> whose address
> it passes to RTHooks.PushEFrame and PopEFrame.  RTHooks.i3 treats this as
> ADDRESS, and
> tells us nothing about what it actually points to.
>
> Is there a bug, or does anybody understand what is going on here?
> --
> Rodney Bates
> rodney.m.bates at acm.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150726/a27f1a68/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jul 30 02:07:18 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 00:07:18 +0000
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <55B25261.5010106@lcwb.coop>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>, ,
 <55B03594.20800@lcwb.coop>, <COL130-W78229587075BD6B3A94050E6810@phx.gbl>,
 <55B25261.5010106@lcwb.coop>
Message-ID: <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>

As part of fixing this, I want M3CG_Ops.i3
declare_temp (s: ByteSize;  a: Alignment;  t: Type;              in_memory: BOOLEAN): Var;

to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, ifthat syntax is allowed, or all existing calls can initially pass M3ID.NoID.

The use in OpenArrayType.DeclareTemp will then be changed to something else.DeclareTemp will look more like OpenArrayType.Compiler.

And, something will be done for jmpbufs, such having them be named and passing that name alongsomewhere. Or giving them a special uid, or even their own special CG.Type?

And then, every use of CG.Type.Struct must come along with a TypeUID.

ok?
The C backend will/should actually be able notice the name of the jmpbuf type and substitutein.. #include <setjmp.h> jmpbuf.
Other backends should  substitute in the alloca use.
Or, it will be an internal parameter to the frontend for it to do the alloca transformation.
But this is getting ahead of things.
First -- change declare_temp to accept a TypeUID ok?


 - Jay


> Date: Fri, 24 Jul 2015 09:57:37 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu; m3devel at elegosoft.com; m3devel at elegosoft.com
> Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> 
> 
> 
> On 07/24/2015 03:57 AM, Jay K wrote:
> > I model this in C like:
> >
> >
> > M3C.m3:
> >          print(self, "/*declare_open_array*/typedef struct {");
> 
> Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?
> 
> >          print(self, element_type.text);
> >          print(self, "* _elts; CARDINAL _size");
> >          IF bit_size > Target.Integer.size * 2 THEN
> >              print(self, "s[");
> >              print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
> >              print(self, "]");
> >          END;
> >
> >
> > that is..and this i stinky that I get the struct "size",
> >
> >
> > size == 2 * sizeof(integer):
> >
> >
> > struct {
> > T* elements
> > size_t size;
> > }
> >
> >
> > else:
> >   N = size - sizeof(INTEGER) / sizeof(INTEGER)
> >   T ** elements; // where the number of star is N
> 
> I would not do pointer to pointer to pointer ... here.  Just "T* elements", regardless
> of the number of open dimensions.  As I understand them, C's language-supported
> multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
> the language does the multi-subscript address arithmetic, which means the type
> system needs to provide a static element size of each dimension.  And that,
> except for the innermost, depends on the element count of the next inner
> dimension, which is not static here.
> 
> So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
> is lowered by the front end into explicit address arithmetic into the flattened
> array, using the values in the shape.  Something like A[I*Shape[0]+J*Shape[1]+K]
> 
> >    size_t sizes[N]
> >
> >
> > It is kind of lame that the frontend just gives the overall size
> > and the backend is just left to assume the layout like that.
> 
> If you know in M3C that it's an open array, you can infer what the layout is.
> But yes, it's kind of lame.  This is just another of the several places we have
> seen that the front end has lowered things too far, and you have to
> You know it's generated by code in OpenArray.m3, and you know the general dope layout,
> and open dimension count, so you can generate an appropriate type.
> 
> 
> >
> > Really, the frontend should declare a type "pointer to pointer to pointer" with
> > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
> >
> >
> > Again, really ugly how it works now where backend is just given a size and can only
> > assume the layout.
> >
> > I don't know what a "dope vector" is. A value used as an initializer?
> >
> 
> This is a very old and rather uninformative term for any block of stuff stored at runtime
> that describes some source programmer's real data and how to access it.  The only alternative
> term I can think of would be "metadata", although that is rather overgeneral, and is usually
> used with quite different specific meanings.  But it is data describing data.
> 
> >
> > It is even worse for subarray. In this case we aren't even told it is an open array, just
> > some random struct with a size. That is what I first want to fix. It should declare an open array,
> > assuming they do have the same layout, which I think they do.
> >
> 
> What you really need to know is that it's an open array, of which subarray is a subcategory.
> In our implementation, all open array values have the same dope.  E.g., look for the case where
> a fixed array actual parameter is passed to an open array formal.
> 
> >
> > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
> > type information.
> >
> >
> > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
> > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
> >
> >
> >
> >
> >   - Jay
> >
> >
> >  > Date: Wed, 22 Jul 2015 19:30:12 -0500
> >  > From: rodney_bates at lcwb.coop
> >  > To: m3devel at elegosoft.com
> >  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
> >  >
> >  > I'm not exactly sure what you are asking, but here is some light on what
> >  > you are seeing. These temporaries are exactly the dope the compiler uses
> >  > to represent all open array values. First a pointer to the zeroth
> >  > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
> >  > an array of element counts for each open subscript. For an open array
> >  > parameter, this would be the machine representation of the parameter
> >  > itself, authored in M3. (but passed by reference.) For a heap object,
> >  > it is stored right before the elements themselves. For a SUBARRAY
> >  > expression, it has to be a temporary. It also has to be constructed
> >  > at the call site, as an anonymous temporary, when passing an entire fixed
> >  > array to an open array parameter
> >  >
> >  > So, a good type for it might look like:
> >  >
> >  >
> >  > RECORD
> >  > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
> >  > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
> >  > END
> >  >
> >  > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
> >  > static limit here in the type of Elements, as it will be enforced dynamically,
> >  > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
> >  > as this would mean another open array inside the dope, resulting in infinite
> >  > recursion.
> >  >
> >  > On 07/22/2015 12:42 AM, Jay K wrote:
> >  > > In the C backend I have a notion of "weak struct types" and "strong struct types".
> >  > >
> >  > >
> >  > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
> >  > >
> >  > >
> >  > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
> >  > >
> >  > >
> >  > >
> >  > > Originally I had only weak types.
> >  > > Ideally I have no weak types.
> >  > > I'm down to very few weak types now.
> >  > > I'd like to finish eliminating weak types.
> >  > >
> >  > >
> >  > >
> >  > > A quick investigation shows weak types come from open arrays and jmpbufs.
> >  > > Open array temporaries from SUBARRAY specifically.
> >  > >
> >  > >
> >  > >
> >  > > Can we fix this?
> >  > >
> >  > >
> >  > >
> >  > > We have:
> >  > > m3front/src/types/OpenArrayType.m3:
> >  > >
> >  > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
> >  > > VAR
> >  > > p := Reduce (t);
> >  > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >  > > BEGIN
> >  > > RETURN CG.Declare_temp (size, Target.Address.align,
> >  > > CG.Type.Struct, in_memory := TRUE);
> >  > > END DeclareTemp;
> >  > >
> >  > >
> >  > > PROCEDURE Compiler (p: P) =
> >  > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
> >  > > BEGIN
> >  > > Type.Compile (p.element);
> >  > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
> >  > > END Compiler;
> >  > >
> >  > >
> >  > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
> >  > > not variables authored by anyone in Modula-3.
> >  > >
> >  > >
> >  > > Can this be easily fixed?
> >  > >
> >  > >
> >  > > Thanks,
> >  > > - Jay
> >  > >
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > M3devel mailing list
> >  > > M3devel at elegosoft.com
> >  > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >  > >
> >  >
> >  > --
> >  > Rodney Bates
> >  > rodney.m.bates at acm.org
> >  > _______________________________________________
> >  > M3devel mailing list
> >  > M3devel at elegosoft.com
> >  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/7b3133de/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jul 30 02:38:49 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 00:38:49 +0000
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or
 exception handling?
Message-ID: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>

I don't have one precise proposal, but somehow,jmpbuf/setjmp/longjmp should be represented in a higher level in m3cgor maybe "even higher level", exception handling.

There are multiple optimization opportunties and multipleopportunities to move/remove target-dependent code.


In particular m3middle/m3front should not know jmpbuf size.Generated C should not have jmpbuf sizes embedded in it.

gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exceptionhandling, that llvm replicates, that is optimized, like to notsave/restore unused registers.

Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.

In particular, the C backend just wants to know something is a "jmpbuf"so it can #include <setjmp.h> in the generated code and produce ajmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.

Or even better, a C++ backend wants to somehow module Modula-3 exceptionsas C++ exceptions.

Or, possibly, the Win32 C backend could model Modula-3 exceptions using"structured exception handling" -- advantage over C++ exceptions is portabilityto kernel mode.

Thoughts? - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/9ebaac62/attachment-0002.html>

From jay.krell at cornell.edu  Thu Jul 30 06:36:34 2015
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 30 Jul 2015 04:36:34 +0000
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
 or exception handling?
In-Reply-To: <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>,
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
Message-ID: <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>

On the last point -- I'm willing to generate C++ instead of C. Does that help?I think it probably does.

On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS Ithink all support what Win32 support -- not a coincidence..

One thing I'm missing is I don't know really know how exceptions are lowered currently.Like, what does the runtime data look like for the "filtering".I should know better..

I think we can also essentially claim all targets have a stack walker.One way or another -- libunwind, NT RtlUnwindEx, etc.

 - Jay



Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
From: hosking at purdue.edu
Date: Thu, 30 Jul 2015 14:04:14 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu> wrote:I don't have one precise proposal, but somehow,jmpbuf/setjmp/longjmp should be represented in a higher level in m3cgor maybe "even higher level", exception handling.

There are multiple optimization opportunties and multipleopportunities to move/remove target-dependent code.


In particular m3middle/m3front should not know jmpbuf size.Generated C should not have jmpbuf sizes embedded in it.

gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exceptionhandling, that llvm replicates, that is optimized, like to notsave/restore unused registers.

Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.

In particular, the C backend just wants to know something is a "jmpbuf"so it can #include <setjmp.h> in the generated code and produce ajmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.

Or even better, a C++ backend wants to somehow module Modula-3 exceptionsas C++ exceptions.

Or, possibly, the Win32 C backend could model Modula-3 exceptions using"structured exception handling" -- advantage over C++ exceptions is portabilityto kernel mode.

Thoughts? - Jay

_______________________________________________M3devel mailing listM3devel at elegosoft.comhttps://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150730/4be773ce/attachment-0002.html>

From rodney_bates at lcwb.coop  Thu Jul 30 16:16:58 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 Jul 2015 09:16:58 -0500
Subject: [M3devel] better typing on SUBARRAY temporaries?
In-Reply-To: <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>
References: <COL130-W159F9AB706512FB9E2629E6830@phx.gbl>, ,
 <55B03594.20800@lcwb.coop>, <COL130-W78229587075BD6B3A94050E6810@phx.gbl>,
 <55B25261.5010106@lcwb.coop> <COL130-W6974D1F79FC350793E8AB4E68B0@phx.gbl>
Message-ID: <55BA31DA.3020905@lcwb.coop>

I'm all for having a better IR in cm3.  I've had a few serious frustrations from lack of
sufficient information in it.  But, if we touch it at all, I really want to try very hard
to think of and do everything we are likely to want in the foreseeable future.  Any
change is painful.  There are somewhere in the neighborhood of 8 or so files that have
to reflect the change.  Also, it requires atomic update to both the front end and m3cc,
which then creates bootstrap issues that have to be handled very carefully.  Jay, your
recent changes to the build process help.  But I want to avoid changing it more than
once if we can possibly avoid it.  AFAIK, m3cc is the only one that ends up a separate
executable.

And when we do it, change the version number, for better mismatch messages.  Also,
it would be the best time to add a magic number, as Elmar was wanting.

One place I encountered was in trying to get better error messages from m3linker, etc.
We get stuff like (paraphrasing from memory) "Error: missing type _t187630885".  Need
I say more?  In trying to make these helpful, I ran up against lack of information.
I remember being able to make slight improvement in one message, but that was it,
without IR changes.

Then there are also some type info deficiencies for generating debug info.  I am
remembering something about inability to connect a procedure type to procedures
that match it, or something.

On 07/29/2015 07:07 PM, Jay K wrote:
> As part of fixing this, I want M3CG_Ops.i3
>
> declare_temp (s: ByteSize;  a: Alignment;  t: Type;
>                in_memory: BOOLEAN): Var;
>
>
> to accept an optional m3t: TypeUID which can be either default to M3ID.NoID, if
> that syntax is allowed, or all existing calls can initially pass M3ID.NoID.
>
>
> The use in OpenArrayType.DeclareTemp will then be changed to something else.
> DeclareTemp will look more like OpenArrayType.Compiler.
>
>
> And, something will be done for jmpbufs, such having them be named and passing that name along
> somewhere. Or giving them a special uid, or even their own special CG.Type?
>
>
> And then, every use of CG.Type.Struct must come along with a TypeUID.
>
>
> ok?
>
> The C backend will/should actually be able notice the name of the jmpbuf type and substitute
> in.. #include <setjmp.h> jmpbuf.
>
> Other backends should  substitute in the alloca use.
>
> Or, it will be an internal parameter to the frontend for it to do the alloca transformation.
>
> But this is getting ahead of things.
>
> First -- change declare_temp to accept a TypeUID ok?
>
>
>
>   - Jay
>
>
>  > Date: Fri, 24 Jul 2015 09:57:37 -0500
>  > From: rodney_bates at lcwb.coop
>  > To: jay.krell at cornell.edu; m3devel at elegosoft.com; m3devel at elegosoft.com
>  > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  >
>  >
>  >
>  > On 07/24/2015 03:57 AM, Jay K wrote:
>  > > I model this in C like:
>  > >
>  > >
>  > > M3C.m3:
>  > > print(self, "/*declare_open_array*/typedef struct {");
>  >
>  > Presumably, this comment means you have some way of knowing, in M3C, that this is an open array?
>  >
>  > > print(self, element_type.text);
>  > > print(self, "* _elts; CARDINAL _size");
>  > > IF bit_size > Target.Integer.size * 2 THEN
>  > > print(self, "s[");
>  > > print(self, IntToDec((bit_size - Target.Integer.size) DIV Target.Integer.size));
>  > > print(self, "]");
>  > > END;
>  > >
>  > >
>  > > that is..and this i stinky that I get the struct "size",
>  > >
>  > >
>  > > size == 2 * sizeof(integer):
>  > >
>  > >
>  > > struct {
>  > > T* elements
>  > > size_t size;
>  > > }
>  > >
>  > >
>  > > else:
>  > > N = size - sizeof(INTEGER) / sizeof(INTEGER)
>  > > T ** elements; // where the number of star is N
>  >
>  > I would not do pointer to pointer to pointer ... here. Just "T* elements", regardless
>  > of the number of open dimensions. As I understand them, C's language-supported
>  > multidimensional arrays are like Modula3 multidimensional _fixed_ arrays, i.e.,
>  > the language does the multi-subscript address arithmetic, which means the type
>  > system needs to provide a static element size of each dimension. And that,
>  > except for the innermost, depends on the element count of the next inner
>  > dimension, which is not static here.
>  >
>  > So, the multiple dimensions are essentially flattened into one, and access to A[I,J,K]
>  > is lowered by the front end into explicit address arithmetic into the flattened
>  > array, using the values in the shape. Something like A[I*Shape[0]+J*Shape[1]+K]
>  >
>  > > size_t sizes[N]
>  > >
>  > >
>  > > It is kind of lame that the frontend just gives the overall size
>  > > and the backend is just left to assume the layout like that.
>  >
>  > If you know in M3C that it's an open array, you can infer what the layout is.
>  > But yes, it's kind of lame. This is just another of the several places we have
>  > seen that the front end has lowered things too far, and you have to
>  > You know it's generated by code in OpenArray.m3, and you know the general dope layout,
>  > and open dimension count, so you can generate an appropriate type.
>  >
>  >
>  > >
>  > > Really, the frontend should declare a type "pointer to pointer to pointer" with
>  > > the right "depth", and then a record with that pointer and a size or fixed size array of sizes.
>  > >
>  > >
>  > > Again, really ugly how it works now where backend is just given a size and can only
>  > > assume the layout.
>  > >
>  > > I don't know what a "dope vector" is. A value used as an initializer?
>  > >
>  >
>  > This is a very old and rather uninformative term for any block of stuff stored at runtime
>  > that describes some source programmer's real data and how to access it. The only alternative
>  > term I can think of would be "metadata", although that is rather overgeneral, and is usually
>  > used with quite different specific meanings. But it is data describing data.
>  >
>  > >
>  > > It is even worse for subarray. In this case we aren't even told it is an open array, just
>  > > some random struct with a size. That is what I first want to fix. It should declare an open array,
>  > > assuming they do have the same layout, which I think they do.
>  > >
>  >
>  > What you really need to know is that it's an open array, of which subarray is a subcategory.
>  > In our implementation, all open array values have the same dope. E.g., look for the case where
>  > a fixed array actual parameter is passed to an open array formal.
>  >
>  > >
>  > > subarray temporaries and jmpbufs are I believe the only place the frontend passes so little
>  > > type information.
>  > >
>  > >
>  > > For jmpbufs I'm hoping to notice their name, and, unfortunately expensive, replace them
>  > > with #include <setjmp.h> and jmpbuf, instead of just a struct with an array of bytes.
>  > >
>  > >
>  > >
>  > >
>  > > - Jay
>  > >
>  > >
>  > > > Date: Wed, 22 Jul 2015 19:30:12 -0500
>  > > > From: rodney_bates at lcwb.coop
>  > > > To: m3devel at elegosoft.com
>  > > > Subject: Re: [M3devel] better typing on SUBARRAY temporaries?
>  > > >
>  > > > I'm not exactly sure what you are asking, but here is some light on what
>  > > > you are seeing. These temporaries are exactly the dope the compiler uses
>  > > > to represent all open array values. First a pointer to the zeroth
>  > > > array element, then the "shape", as defined in M3 definition, 2.2.3, i.e.
>  > > > an array of element counts for each open subscript. For an open array
>  > > > parameter, this would be the machine representation of the parameter
>  > > > itself, authored in M3. (but passed by reference.) For a heap object,
>  > > > it is stored right before the elements themselves. For a SUBARRAY
>  > > > expression, it has to be a temporary. It also has to be constructed
>  > > > at the call site, as an anonymous temporary, when passing an entire fixed
>  > > > array to an open array parameter
>  > > >
>  > > > So, a good type for it might look like:
>  > > >
>  > > >
>  > > > RECORD
>  > > > Elements : REF ARRAY [0..Max, ... ,0..Max] OF ElementType
>  > > > ; Shape : ARRAY [0..OpenDepth-1] of CARDINAL
>  > > > END
>  > > >
>  > > > Max will be like the notorious TextLiteral.MaxBytes, i.e., we don't want any
>  > > > static limit here in the type of Elements, as it will be enforced dynamically,
>  > > > using Shape. But we don't want to just say REF ARRAY OF ElementType either,
>  > > > as this would mean another open array inside the dope, resulting in infinite
>  > > > recursion.
>  > > >
>  > > > On 07/22/2015 12:42 AM, Jay K wrote:
>  > > > > In the C backend I have a notion of "weak struct types" and "strong struct types".
>  > > > >
>  > > > >
>  > > > > "Strong" types have fields with types and names corresponding to the original Modula-3. i.e. they debug well.
>  > > > >
>  > > > >
>  > > > > "Weak" types have just arrays of characters (in a struct), sized/aligned to what the front end asked for. i.e. they debug poorly.
>  > > > >
>  > > > >
>  > > > >
>  > > > > Originally I had only weak types.
>  > > > > Ideally I have no weak types.
>  > > > > I'm down to very few weak types now.
>  > > > > I'd like to finish eliminating weak types.
>  > > > >
>  > > > >
>  > > > >
>  > > > > A quick investigation shows weak types come from open arrays and jmpbufs.
>  > > > > Open array temporaries from SUBARRAY specifically.
>  > > > >
>  > > > >
>  > > > >
>  > > > > Can we fix this?
>  > > > >
>  > > > >
>  > > > >
>  > > > > We have:
>  > > > > m3front/src/types/OpenArrayType.m3:
>  > > > >
>  > > > > PROCEDURE DeclareTemp (t: Type.T): CG.Var =
>  > > > > VAR
>  > > > > p := Reduce (t);
>  > > > > size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > > > BEGIN
>  > > > > RETURN CG.Declare_temp (size, Target.Address.align,
>  > > > > CG.Type.Struct, in_memory := TRUE);
>  > > > > END DeclareTemp;
>  > > > >
>  > > > >
>  > > > > PROCEDURE Compiler (p: P) =
>  > > > > VAR size := Target.Address.pack + OpenDepth (p) * Target.Integer.pack;
>  > > > > BEGIN
>  > > > > Type.Compile (p.element);
>  > > > > CG.Declare_open_array (Type.GlobalUID(p), Type.GlobalUID(p.element), size);
>  > > > > END Compiler;
>  > > > >
>  > > > >
>  > > > > DeclareTemp is used in SUBARRAY expressions -- truly temporaries,
>  > > > > not variables authored by anyone in Modula-3.
>  > > > >
>  > > > >
>  > > > > Can this be easily fixed?
>  > > > >
>  > > > >
>  > > > > Thanks,
>  > > > > - Jay
>  > > > >
>  > > > >
>  > > > >
>  > > > > _______________________________________________
>  > > > > M3devel mailing list
>  > > > > M3devel at elegosoft.com
>  > > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  > > > >
>  > > >
>  > > > --
>  > > > Rodney Bates
>  > > > rodney.m.bates at acm.org
>  > > > _______________________________________________
>  > > > M3devel mailing list
>  > > > M3devel at elegosoft.com
>  > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>  >
>  > --
>  > Rodney Bates
>  > rodney.m.bates at acm.org
>  > _______________________________________________
>  > M3devel mailing list
>  > M3devel at elegosoft.com
>  > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

-- 
Rodney Bates
rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Thu Jul 30 16:27:25 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 30 Jul 2015 09:27:25 -0500
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
 or exception handling?
In-Reply-To: <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>,
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
 <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl>
Message-ID: <55BA344D.3020407@lcwb.coop>



On 07/29/2015 11:36 PM, Jay K wrote:
> On the last point -- I'm willing to generate C++ instead of C. Does that help?
> I think it probably does.
>
>
> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
> think all support what Win32 support -- not a coincidence..
>
>
> One thing I'm missing is I don't know really know how exceptions are lowered currently.
> Like, what does the runtime data look like for the "filtering".
> I should know better..
>
>
> I think we can also essentially claim all targets have a stack walker.
> One way or another -- libunwind, NT RtlUnwindEx, etc.

Really?  That would be great news.  If it really applies to them all, wouldn't
the jmpbuf problem just go away?

>
>
>   - Jay
>
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
> From: hosking at purdue.edu
> Date: Thu, 30 Jul 2015 14:04:14 +1000
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
> That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
>
>     On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>
>     I don't have one precise proposal, but somehow,
>     jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>     or maybe "even higher level", exception handling.
>
>
>     There are multiple optimization opportunties and multiple
>     opportunities to move/remove target-dependent code.
>
>
>
>     In particular m3middle/m3front should not know jmpbuf size.
>     Generated C should not have jmpbuf sizes embedded in it.
>
>
>     gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>     handling, that llvm replicates, that is optimized, like to not
>     save/restore unused registers.
>
>
>     Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>
>
>     In particular, the C backend just wants to know something is a "jmpbuf"
>     so it can #include <setjmp.h> in the generated code and produce a
>     jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>
>
>     Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>     as C++ exceptions.
>
>
>     Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>     "structured exception handling" -- advantage over C++ exceptions is portability
>     to kernel mode.
>
>
>     Thoughts?
>       - Jay
>
>
>     _______________________________________________
>     M3devel mailing list
>     M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>     https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org


From jay.krell at cornell.edu  Thu Jul 30 21:32:42 2015
From: jay.krell at cornell.edu (Jay)
Date: Thu, 30 Jul 2015 12:32:42 -0700
Subject: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp
	or exception handling?
In-Reply-To: <55BA344D.3020407@lcwb.coop>
References: <COL130-W95DE4E052A746C90F7BFF8E68B0@phx.gbl>
 <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu>
 <COL130-W3691B04E503A1E93F4717E68B0@phx.gbl> <55BA344D.3020407@lcwb.coop>
Message-ID: <5C73404D-582C-46BF-8F45-D6F1615B8769@gmail.com>

I believe libunwind/libgcc_s applies pretty broadly and address all non-NT platforms. I believe NT/non-x86 is documented enough. NT/x86 will take more research.


I also believe generating C++ is a good option, or Win32-specific C.


I do have the alloca+setjmp work finally almost done, slightly more work than I earlier realized & would like to get it in first, then optimize it in the C backend (the C backend specifically should declare a setjmp.h declared jmp_buf w/o alloca), & then look more into the "unwind" options. 


 - Jay

On Jul 30, 2015, at 7:27 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> 
> 
> On 07/29/2015 11:36 PM, Jay K wrote:
>> On the last point -- I'm willing to generate C++ instead of C. Does that help?
>> I think it probably does.
>> 
>> 
>> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
>> think all support what Win32 support -- not a coincidence..
>> 
>> 
>> One thing I'm missing is I don't know really know how exceptions are lowered currently.
>> Like, what does the runtime data look like for the "filtering".
>> I should know better..
>> 
>> 
>> I think we can also essentially claim all targets have a stack walker.
>> One way or another -- libunwind, NT RtlUnwindEx, etc.
> 
> Really?  That would be great news.  If it really applies to them all, wouldn't
> the jmpbuf problem just go away?
> 
>> 
>> 
>>  - Jay
>> 
>> 
>> 
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
> ---
>> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
>> From: hosking at purdue.edu
>> Date: Thu, 30 Jul 2015 14:04:14 +1000
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
>> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
>> That suggests we at least lift to the LLVM level of abstraction, but I don?t know how easy that will be to generate from for the C backend.
>> 
>>    On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>> 
>>    I don't have one precise proposal, but somehow,
>>    jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>>    or maybe "even higher level", exception handling.
>> 
>> 
>>    There are multiple optimization opportunties and multiple
>>    opportunities to move/remove target-dependent code.
>> 
>> 
>> 
>>    In particular m3middle/m3front should not know jmpbuf size.
>>    Generated C should not have jmpbuf sizes embedded in it.
>> 
>> 
>>    gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>>    handling, that llvm replicates, that is optimized, like to not
>>    save/restore unused registers.
>> 
>> 
>>    Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>> 
>> 
>>    In particular, the C backend just wants to know something is a "jmpbuf"
>>    so it can #include <setjmp.h> in the generated code and produce a
>>    jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>> 
>> 
>>    Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>>    as C++ exceptions.
>> 
>> 
>>    Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>>    "structured exception handling" -- advantage over C++ exceptions is portability
>>    to kernel mode.
>> 
>> 
>>    Thoughts?
>>      - Jay
>> 
>> 
>>    _______________________________________________
>>    M3devel mailing list
>>    M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>>    https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>> 
>> 
>> 
>> 
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org


From rodney_bates at lcwb.coop  Fri Jul 31 22:39:43 2015
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 31 Jul 2015 15:39:43 -0500
Subject: [M3devel] m3core.h broken
Message-ID: <55BBDD0F.4080206@lcwb.coop>

On AMD64_LINUX, with gcc 4.8.1, m3-libs/src/m3core.h suffers many compile errors,
when compiling on m3core and cm3.  reverting line 363 of m3core.h makes them go away.
This is probably not the right way to fix this.


-- 
Rodney Bates
rodney.m.bates at acm.org