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 wrote: > On 5/29/2015 15:58, Olaf Wagner wrote: > > On Fri, 29 May 2015 12:40:29 +0200 > > John Marino 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: 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: <20150502155713.29DCC1A2062@async.async.caltech.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: 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: <20150502155713.29DCC1A2062@async.async.caltech.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: 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: 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: <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu> Message-ID: 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 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: 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: 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: 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: References: Message-ID: 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: 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: 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: 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: References: , Message-ID: 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: 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: 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: 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: 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: 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: References: 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: , <20150718232140.GA7577@topoi.pooq.com> Message-ID: 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: 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: References: , <20150718232140.GA7577@topoi.pooq.com> 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: 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: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org> Message-ID: 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: 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: References: 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: 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: References: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org> 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: 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: , <55AB6667.7010908@elstel.org> Message-ID: 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: 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: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org>, , <55AB697C.7090109@elstel.org> Message-ID: 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: 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: References: , <55AB6667.7010908@elstel.org> 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: 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: , <55AB6667.7010908@elstel.org> <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: 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: , <55AB6667.7010908@elstel.org>, <55AB7011.9070709@elstel.org>,<55AB769C.2020806@elstel.org> Message-ID: 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: 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: References: , <55AB6667.7010908@elstel.org>, <55AB7011.9070709@elstel.org>, <55AB769C.2020806@elstel.org> 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: 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: <55AB6667.7010908@elstel.org> <55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org> <55AB91D0.80303@elstel.org> Message-ID: 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 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: 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: References: , <55AB6667.7010908@elstel.org> ,<55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org>, <55AB91D0.80303@elstel.org>, Message-ID: 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 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: 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: 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: 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: References: 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: , <55B03594.20800@lcwb.coop> Message-ID: 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 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: 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: References: , <55B03594.20800@lcwb.coop> 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 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: 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 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: 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: , , <55B03594.20800@lcwb.coop>, , <55B25261.5010106@lcwb.coop> Message-ID: 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 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 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: 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: 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 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: 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: , <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> Message-ID: 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 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 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: 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: References: , , <55B03594.20800@lcwb.coop>, , <55B25261.5010106@lcwb.coop> 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 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 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: References: , <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> 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 > 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 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 > 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: <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> <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" 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 > 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 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 >> 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 wrote: > On 5/29/2015 15:58, Olaf Wagner wrote: > > On Fri, 29 May 2015 12:40:29 +0200 > > John Marino 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: 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: <20150502155713.29DCC1A2062@async.async.caltech.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: 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: <20150502155713.29DCC1A2062@async.async.caltech.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: 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: 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: <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu> Message-ID: 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 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: 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: 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: 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: References: Message-ID: 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: 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: 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: 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: References: , Message-ID: 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: 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: 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: 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: 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: 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: References: 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: , <20150718232140.GA7577@topoi.pooq.com> Message-ID: 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: 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: References: , <20150718232140.GA7577@topoi.pooq.com> 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: 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: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org> Message-ID: 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: 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: References: 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: 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: References: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org> 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: 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: , <55AB6667.7010908@elstel.org> Message-ID: 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: 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: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org>, , <55AB697C.7090109@elstel.org> Message-ID: 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: 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: References: , <55AB6667.7010908@elstel.org> 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: 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: , <55AB6667.7010908@elstel.org> <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: 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: , <55AB6667.7010908@elstel.org>, <55AB7011.9070709@elstel.org>,<55AB769C.2020806@elstel.org> Message-ID: 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: 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: References: , <55AB6667.7010908@elstel.org>, <55AB7011.9070709@elstel.org>, <55AB769C.2020806@elstel.org> 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: 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: <55AB6667.7010908@elstel.org> <55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org> <55AB91D0.80303@elstel.org> Message-ID: 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 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: 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: References: , <55AB6667.7010908@elstel.org> ,<55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org>, <55AB91D0.80303@elstel.org>, Message-ID: 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 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: 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: 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: 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: References: 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: , <55B03594.20800@lcwb.coop> Message-ID: 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 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: 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: References: , <55B03594.20800@lcwb.coop> 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 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: 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 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: 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: , , <55B03594.20800@lcwb.coop>, , <55B25261.5010106@lcwb.coop> Message-ID: 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 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 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: 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: 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 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: 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: , <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> Message-ID: 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 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 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: 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: References: , , <55B03594.20800@lcwb.coop>, , <55B25261.5010106@lcwb.coop> 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 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 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: References: , <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> 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 > 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 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 > 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: <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> <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" 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 > 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 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 >> 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 wrote: > On 5/29/2015 15:58, Olaf Wagner wrote: > > On Fri, 29 May 2015 12:40:29 +0200 > > John Marino 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: 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: <20150502155713.29DCC1A2062@async.async.caltech.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: 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: <20150502155713.29DCC1A2062@async.async.caltech.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: 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: 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: <93353043-82E3-4D21-A1A9-05A015BA48E0@purdue.edu> Message-ID: 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 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: 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: 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: 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: References: Message-ID: 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: 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: 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: 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: References: , Message-ID: 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: 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: 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: 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: 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: 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: References: 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: , <20150718232140.GA7577@topoi.pooq.com> Message-ID: 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: 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: References: , <20150718232140.GA7577@topoi.pooq.com> 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: 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: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org> Message-ID: 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: 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: References: 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: 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: References: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org> 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: 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: , <55AB6667.7010908@elstel.org> Message-ID: 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: 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: , , <20150718232140.GA7577@topoi.pooq.com>, , <55AB635F.9060809@elstel.org>, , <55AB697C.7090109@elstel.org> Message-ID: 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: 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: References: , <55AB6667.7010908@elstel.org> 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: 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: , <55AB6667.7010908@elstel.org> <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: 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: , <55AB6667.7010908@elstel.org>, <55AB7011.9070709@elstel.org>,<55AB769C.2020806@elstel.org> Message-ID: 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: 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: References: , <55AB6667.7010908@elstel.org>, <55AB7011.9070709@elstel.org>, <55AB769C.2020806@elstel.org> 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: 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: <55AB6667.7010908@elstel.org> <55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org> <55AB91D0.80303@elstel.org> Message-ID: 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 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: 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: References: , <55AB6667.7010908@elstel.org> ,<55AB7011.9070709@elstel.org> <55AB769C.2020806@elstel.org>, <55AB91D0.80303@elstel.org>, Message-ID: 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 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: 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: 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: 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: References: 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: , <55B03594.20800@lcwb.coop> Message-ID: 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 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: 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: References: , <55B03594.20800@lcwb.coop> 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 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: 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 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: 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: , , <55B03594.20800@lcwb.coop>, , <55B25261.5010106@lcwb.coop> Message-ID: 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 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 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: 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: 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 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: 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: , <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> Message-ID: 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 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 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: 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: References: , , <55B03594.20800@lcwb.coop>, , <55B25261.5010106@lcwb.coop> 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 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 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: References: , <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> 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 > 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 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 > 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: <8E43ADAC-7F1D-4537-96CE-6FDF28FA663F@purdue.edu> <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" 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 > 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 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 >> 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