group by / having
Hello,
Do you know why this command doesn't work ?
select * from T;
x|y
-+-
1|1
1|2
2|1
2|2
2|3
select X,Y from T group by X having Y=min(Y);
ERROR: Illegal use of aggregates or non-group column in target list
My goal is quite simple : get only one line per X value (the value which is
returned for Y is not important as long as it's one of the values linked to
the right X).
The query "select X,Y from T group by X" works under MySQL and
returns exactly what I want, how can I do it in PostgreSQL ?
Thanks for your help,
Alain
From bouncefilter Sun Dec 19 13:08:45 1999
Received: from ale.vtiscan.com (ale.vtiscan.com [192.76.184.74])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA04293
for <pgsql-general@postgresql.org>;
Sun, 19 Dec 1999 13:08:10 -0500 (EST) (envelope-from rwb@vtiscan.com)
Received: from porter.vtiscan.com (porter.vtiscan.com [192.76.184.97])
by ale.vtiscan.com (8.8.7/8.8.7) with ESMTP id NAA31987
for <pgsql-general@postgresql.org>; Sun, 19 Dec 1999 13:08:09 -0500
Date: Sun, 19 Dec 1999 13:08:11 -0500
From: "Robert W. Berger" <rwb@vtiscan.com>
To: pgsql-general@postgresql.org
Subject: select count(distinct ...
Message-ID: <17746447.3154597691@porter.vtiscan.com>
Originator-Info: login-id=rwb; server=vtiscan.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n U-300796]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
How do I do the equivilant of
select count(distinct c) from t...
which I believe is legal in SQL92 but doesn't work in Postgresql...
From bouncefilter Sun Dec 19 13:44:44 1999
Received: from emr01.bellatlantic.COM (emr01.bellatlantic.com [198.23.5.143])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA11490
for <pgsql-general@hub.org>; Sun, 19 Dec 1999 13:43:53 -0500 (EST)
(envelope-from david.gormley@bellatlantic.com)
From: david.gormley@bellatlantic.com
Received: (from root@localhost)
by emr01.bellatlantic.COM (8.8.8/8.8.8) id NAA13052
for pgsql-general@hub.org.filtered;
Sun, 19 Dec 1999 13:43:23 -0500 (EST)
Received: from imr01.bellatlantic.com (imr01 [141.152.156.12])
by emr01.bellatlantic.COM (8.8.8/8.8.8) with ESMTP id NAA13048
for <pgsql-general@hub.org>; Sun, 19 Dec 1999 13:43:23 -0500 (EST)
Received: from fhsmtp01.bell-atl.com (is051991.bellatlantic.com
[141.152.101.47])
by imr01.bellatlantic.com (8.8.8/8.8.5) with SMTP id NAA08762
for <pgsql-general@hub.org>; Sun, 19 Dec 1999 13:43:22 -0500 (EST)
Received: by fhsmtp01.bell-atl.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id
8525684C.0066D45E ; Sun, 19 Dec 1999 13:43:10 -0500
X-Lotus-FromDomain: NYNEX
To: pgsql-general@hub.org
Message-ID: <8525684C.0066D389.00@fhsmtp01.bell-atl.com>
Date: Sun, 19 Dec 1999 13:43:09 -0500
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
unsubscribe
From bouncefilter Sun Dec 19 14:05:44 1999
Received: from zmail6.easynet.fr (email.easynet.fr [195.114.64.207])
by hub.org (8.9.3/8.9.3) with SMTP id OAA15726
for <pgsql-general@postgreSQL.org>;
Sun, 19 Dec 1999 14:04:56 -0500 (EST)
(envelope-from tesio@easynet.fr)
Received: (qmail 91307 invoked from network); 19 Dec 1999 19:04:55 -0000
Received: from mailgate2.easynet.fr (192.168.1.3)
by mailserver.easynet.fr with QMQP; 19 Dec 1999 19:04:55 -0000
Received: from pop-nice-206.pops.easynet.fr (HELO atesio) (195.114.95.206)
by mrelay2.easynet.fr with SMTP; 19 Dec 1999 19:09:22 -0000
Message-ID: <006301bf4a54$2f50dc80$de5f72c3@atesio>
From: "Alain TESIO" <tesio@easynet.fr>
To: <pgsql-general@postgreSQL.org>
References: <385C1F8E.2CC771A7@nlr.ru> <385C3BE0.D307E8B5@mascari.com>
Subject: Right to create temp tables
Date: Sun, 19 Dec 1999 20:06:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Hello,
I need to access the database through PHP on an Apache server.
The connections are done with the user "nobody", which I created
in PostgreSQL (version 6.5.3)
It works fine for select, however I'd need to create temporary tables,
and execute insert / update on them with that user. The documentation
about the grant command seems to apply only to existing objects.
Any idea ?
Thanks,
Alain
From bouncefilter Sun Dec 19 14:11:45 1999
Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net
[207.172.4.60])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA16283;
Sun, 19 Dec 1999 14:10:49 -0500 (EST)
(envelope-from tlaswell@erols.com)
Received: from 207-172-130-26.s26.tnt3.col.md.dialup.rcn.com
([207.172.130.26])
by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3)
id 11zlhy-0000bo-00; Sun, 19 Dec 1999 14:09:31 -0500
Date: Sun, 19 Dec 1999 15:09:00 -0500 (EST)
From: Timothy Laswell <tlaswell@erols.com>
To: Mike Mascari <mascarm@mascari.com>
cc: Alex Guryanow <gav@nlr.ru>, pgsql-general@postgresql.org,
pgsql-sql@postgresql.org
Subject: Re: [GENERAL] NOTICE: (transaction aborted): queries ignored until
END
In-Reply-To: <385C3BE0.D307E8B5@mascari.com>
Message-ID: <Pine.LNX.4.10.9912191506520.3954-100000@tlashome.erols.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Thanks Mike, I had the same problem and couldn't figure it out. I forgot
that since the last time I ran this type of routine I had added some
quotes in. I forgot to add the routines to handle the single quotes in
the new program.
Tim in Columbia MD
On Sat, 18 Dec 1999, Mike Mascari wrote:
Alex Guryanow wrote:
NOTICE: (transaction aborted): queries ignored until
What means this message? And why this happens?
Best regards,
AlexThat message appears when an error has occurred in a
transaction. It means that no other SQL statements will be
processed until the transaction has ended and a new one has
begun. For example:It sounds as if some of your INSERT statements are not being
properly executed, often due to embedded single quotes in
text strings, lack of NULL values for missing datetime
values, or some other such syntax error. You should be able
to use PQresultStatus() and PQerrorMessage() to determine
precisely the error which is causing the transaction to
abort.Hope that helps,
Mike Mascari
From bouncefilter Sun Dec 19 17:06:47 1999
Received: from emr01.bellatlantic.COM (emr01.bellatlantic.com [198.23.5.143])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA47938
for <pgsql-general@postgreSQL.org>;
Sun, 19 Dec 1999 17:06:27 -0500 (EST)
(envelope-from david.gormley@bellatlantic.com)
From: david.gormley@bellatlantic.com
Received: (from root@localhost)
by emr01.bellatlantic.COM (8.8.8/8.8.8) id RAA06718
for pgsql-general@postgreSQL.org.filtered;
Sun, 19 Dec 1999 17:05:57 -0500 (EST)
Received: from imr01.bellatlantic.com (imr01 [141.152.156.12])
by emr01.bellatlantic.COM (8.8.8/8.8.8) with ESMTP id RAA06713
for <pgsql-general@postgreSQL.org>;
Sun, 19 Dec 1999 17:05:57 -0500 (EST)
Received: from fhsmtp01.bell-atl.com (is051991.bellatlantic.com
[141.152.101.47])
by imr01.bellatlantic.com (8.8.8/8.8.5) with SMTP id RAA02621
for <pgsql-general@postgreSQL.org>;
Sun, 19 Dec 1999 17:05:56 -0500 (EST)
Received: by fhsmtp01.bell-atl.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id
8525684C.007962E6 ; Sun, 19 Dec 1999 17:05:51 -0500
X-Lotus-FromDomain: NYNEX
To: pgsql-general@postgreSQL.org
Message-ID: <8525684C.007960BD.00@fhsmtp01.bell-atl.com>
Date: Sun, 19 Dec 1999 17:05:47 -0500
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
unsubscribe david gormley david.gormley@bellatlantic.com
From bouncefilter Mon Dec 20 01:07:52 1999
Received: from hotmail.com (law-f207.hotmail.com [209.185.130.117])
by hub.org (8.9.3/8.9.3) with SMTP id BAA44304
for <pgsql-general@hub.org>; Mon, 20 Dec 1999 01:07:51 -0500 (EST)
(envelope-from oomoomi@hotmail.com)
Received: (qmail 82333 invoked by uid 0); 20 Dec 1999 06:07:20 -0000
Message-ID: <19991220060720.82332.qmail@hotmail.com>
Received: from 195.200.226.110 by www.hotmail.com with HTTP;
Sun, 19 Dec 1999 22:07:20 PST
X-Originating-IP: [195.200.226.110]
From: "omid omoomi" <oomoomi@hotmail.com>
To: pgajer@chow.mat.jhu.edu
Cc: pgsql-general@hub.org
Subject: Re: [GENERAL] dynamic queries in Postgres
Date: Sun, 19 Dec 1999 22:07:20 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Hi,
I think you should use some CGI programming on your pages. Once I'v done
some thing like this,using PHP. Also perl & dbi are avaiable for that job.
good luck
omid
From: pawel <pgajer@chow.mat.jhu.edu>
To: pgsql-general@hub.org
Subject: [GENERAL] dynamic queries in Postgres
Date: Sun, 19 Dec 1999 23:12:26 -0500Hi,
does anybody know if Postgres supports dynamic queries? I have a DB
with an html interface. I want users to be able to specify on the
fly
which columns they want to see and with what constrains.
Oracle has a package dbms_sql that allows to do something like this.
I
wander if I can do the same in Postgres.
Cheers,
pawel************
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From bouncefilter Sun Dec 19 23:12:51 1999
Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA21348
for <pgsql-general@hub.org>; Sun, 19 Dec 1999 23:12:27 -0500 (EST)
(envelope-from pgajer@chow.mat.jhu.edu)
Received: from math.jhu.edu ([24.5.88.152]) by mail.rdc1.md.home.com
(InterMail v4.01.01.00 201-229-111) with ESMTP
id <19991220041222.DZLE26939.mail.rdc1.md.home.com@math.jhu.edu>
for <pgsql-general@hub.org>; Sun, 19 Dec 1999 20:12:22 -0800
Sender: pawel
Message-ID: <385DACA9.52E83F0B@math.jhu.edu>
Date: Sun, 19 Dec 1999 23:12:26 -0500
From: pawel <pgajer@chow.mat.jhu.edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.13-14mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@hub.org
Subject: dynamic queries in Postgres
References: <199912190401.XAA45762@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
does anybody know if Postgres supports dynamic queries? I have a DB
with an html interface. I want users to be able to specify on the
fly
which columns they want to see and with what constrains.
Oracle has a package dbms_sql that allows to do something like this.
I
wander if I can do the same in Postgres.
Cheers,
pawel
From bouncefilter Sun Dec 19 23:36:51 1999
Received: from mail.internal (isdn244.vocollect.com [209.166.154.244])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA27272
for <pgsql-general@postgresql.org>;
Sun, 19 Dec 1999 23:36:28 -0500 (EST)
(envelope-from bbender@vocollect.com)
Received: from brianbnt5 ([172.31.5.194])
by mail.internal (8.9.3/8.9.3) with SMTP id XAA06335
for <pgsql-general@postgresql.org>; Sun, 19 Dec 1999 23:34:11 -0500
From: "Brian Bender" <bbender@vocollect.com>
To: <pgsql-general@postgresql.org>
Subject: RFH (req for HELP!) -- Putting the pieces back together...
Date: Sun, 19 Dec 1999 23:34:43 -0500
Message-ID: <001d01bf4aa2$e26fd340$5c8aa6d1@brianbnt5>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Hi folks,
Sorry for the crosspost, but I'm new to the lists & wasn't sure which was
more appropriate.
The short story is I'm trying to rescue at least some data from a PG 6.5.1
database that's gone belly up. I've got a recent (day before I was called
in to help rescue) "core" in data/base/mydb, a pg_log that's almost 1 GB
(the databases themselves, 2 or 3 of them, are only 1-5MB of data), and a PG
engine that thinks no databases exist (\L says "no databases") even though I
can connect to mydb. Once connected to mydb (through psql), if I "select *
from known_table;", it returns 0 records. The "known_table" file is still
about 5MB, I'm assuming the data is still actually in there?
Is there *any* hope of recovering the data from those tables? The last
pg_dump was apparently the one I demonstrated over a week ago. I was
working on getting them automated and the dumps added to my backup cycle,
but I assumed (yeah, I know <sigh>) that in the meantime the developers were
still manually doing pg_dump's daily or so...... >:-P
Thanks for any pointers, and Happy Holidays (yes, I did put this aside long
enough this weekend to finish decorating the tree and spend some time with
my little girl <g>).
- Brian Bender
Part-time (usually the *wrong* times) sysadmin
Vocollect, Inc.
Pittsburgh, PA, USA
From bouncefilter Mon Dec 20 00:00:53 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA31356
for <pgsql-general@postgreSQL.org>;
Mon, 20 Dec 1999 00:00:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA27072;
Sun, 19 Dec 1999 23:58:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912200458.XAA27072@candle.pha.pa.us>
Subject: Re: [GENERAL] RFH (req for HELP!) -- Putting the pieces back
together...
In-Reply-To: <001d01bf4aa2$e26fd340$5c8aa6d1@brianbnt5> from Brian Bender at
"Dec 19, 1999 11:34:43 pm"
To: Brian Bender <bbender@vocollect.com>
Date: Sun, 19 Dec 1999 23:58:57 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Hi folks,
Sorry for the crosspost, but I'm new to the lists & wasn't sure which was
more appropriate.The short story is I'm trying to rescue at least some data from a PG 6.5.1
database that's gone belly up. I've got a recent (day before I was called
in to help rescue) "core" in data/base/mydb, a pg_log that's almost 1 GB
(the databases themselves, 2 or 3 of them, are only 1-5MB of data), and a PG
engine that thinks no databases exist (\L says "no databases") even though I
can connect to mydb. Once connected to mydb (through psql), if I "select *
from known_table;", it returns 0 records. The "known_table" file is still
about 5MB, I'm assuming the data is still actually in there?
Yes, you can. My recommendation is to first backup all the files under
pgsql. Then, use pg_upgrade on your old pg_dump. pg_upgrade can use
the schema from the old pg_dump output, and places your current data
files into place after the upgrade. The script is intended to be used
only when moving from release to release, but it can be used to fix
problems where your system tables are messed up.
Another idea is to insert into pg_database and see if that will help you
pg_dump.
You may need to edit pg_upgrade so it will run. It was disabled for
6.5.* because file formats changed from 6.4.*.
You may need to phone me if you need more help.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Dec 20 00:00:51 1999
Received: from mail.netic.de (mail.s.netic.de [212.9.160.11])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA31983
for <pgsql-general@hub.org>; Mon, 20 Dec 1999 00:00:39 -0500 (EST)
(envelope-from eschmid@php.net)
Received: by mail.netic.de (Smail3.2.0.106/mail.s.netic.de)
via LF.net GmbH Internet Services via remoteip 212.9.162.35
via remotehost php.net with esmtp for hub.org
id m11zunT-001WzjC; Mon, 20 Dec 1999 05:51:47 +0100 (CET)
Sender: eschmid
Message-ID: <385DBA93.B51C43EC@php.net>
Date: Mon, 20 Dec 1999 06:11:47 +0100
From: Egon Schmid <eschmid@php.net>
Organization: PHP Documentation Group
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586)
MIME-Version: 1.0
To: pawel <pgajer@chow.mat.jhu.edu>
CC: pgsql-general@hub.org
Subject: Re: [GENERAL] dynamic queries in Postgres
References: <199912190401.XAA45762@hub.org> <385DACA9.52E83F0B@math.jhu.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
pawel wrote:
does anybody know if Postgres supports dynamic queries? I have a DB
with an html interface. I want users to be able to specify on the
fly
which columns they want to see and with what constrains.
Oracle has a package dbms_sql that allows to do something like this.
I
wander if I can do the same in Postgres.
Use PHP (see http://www.php.net/)
-Egon
--
Gr�ninger Stra�e 6 � D-70599 Stuttgart
Fon +49 711 45 37 21 � http://www.php.net/
http://www.php.net/manual/ � http://www.php.net/books.php3
Concert Band: http://www.uni-hohenheim.de/~windband/
From bouncefilter Mon Dec 20 02:50:53 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA61220
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 02:50:15 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.16.188]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 20 Dec 1999 01:50:32 -0600
Sender: ed
Message-ID: <385DDFE9.8BB91CB7@austin.rr.com>
Date: Mon, 20 Dec 1999 01:51:05 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pg-gen <pgsql-general@postgresql.org>
Subject: [GENERAL] Query optimization question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Which is faster? This...
SELECT t1.name
FROM t1, t2, t3, t4
WHERE
t1.id = 1 AND
t2.id = 2 AND
t3.id = 3 AND
t3.id = t4.id;
...or this...
SELECT t1.name
FROM t1, t2, t3, t4
WHERE
t1.id = 1 AND
t3.id = t4.id AND
t2.id = 2 AND
t3.id = 3;
Does it make a difference in pgsql?
Cheers,
Ed Loehr
From bouncefilter Mon Dec 20 11:54:59 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA71780
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 11:54:28 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id RAA05565;
Mon, 20 Dec 1999 17:53:42 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 12047o-0002Yu-00; Mon, 20 Dec 1999 14:49:24 +0000
Message-ID: <385E345B.EB292FAD@sferacarta.com>
Date: Mon, 20 Dec 1999 14:51:23 +0100
From: Jose Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Beller <beller@tradeworx.com>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] copy command -- foiled by pg_atoi
References: <385C01E1.6876466D@tradeworx.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
This is also my problem. I'm getting '@!?�����+*_|!&/%��' to load a
table with more than 23,000 rows
because I don't know in which line I have to look for the the error.
It's obvious that psql reads the input file line by line, and of course
psql knows in wich line the error
occurred. This information would be very important to correct any syntax
error in the file.
Comments?
Jose'
Mike Beller wrote:
Hi
I'm using postgresql on RedHat/i386 from the RH6.1 RPMs
(Linux 2.2.5-15 PostgreSQL-6.5.2). I've been evaluating it,
and am quite excited about the possibilty of using this outstanding
open-source code in my company's systems.I noticed the following and want to submit it for your consideration:
When doing a 'copy' from a big text file, if there is a record, say
half way down, which has an unparseable integer field (say 'X'
in a column that shoudl be an integer) one gets the following error:ERROR: pg_atoi: error in "X": can't parse "X"
However, I don't get a line number reference where the error
occurred. This is a problem when you have half a million lines
in your file, some of which may contain legitimate X's as
well as non-legit ones. I don't even know which attribute failed.Simple example: (imagine a million rows with 12 columns and
you're trying to find the problem:)-------
create table foo (x int);
copy foo from stdin;
1
2
3
X
4
\.
-----------I noticed that in pg_atoi there is this code:
if (errno) /* strtol must set ERANGE */
elog(ERROR, "pg_atoi: error reading \"%s\": %m", s);
if (badp && *badp && (*badp != c))
elog(ERROR, "pg_atoi: error in \"%s\": can\'t parse
\"%s\"",s, badp);This is called (via int4in or some such) from copy.c:
values[i] = (Datum) (*fmgr_faddr(&in_functions[i]))(string,
elements[i],typmod[i]);
/*
* Sanity check - by reference attributes cannot
* return NULL
*/
if (!PointerIsValid(values[i]) &&
!(rel->rd_att->attrs[i]->attbyval))
elog(ERROR, "copy from line %d: Bad file format",
lineno);So the lineno information is there, it's just not available when pg_atoi
logs its error and bails out.Is it possible for pg_atoi to return an invalid pointer instead
of completely bailing out, thus allowing the 'sanity check' code
to print the line number? I have no idea how many things this
might break...Regards
Mike Beller
CTO
Tradeworx.com************
From bouncefilter Mon Dec 20 09:26:58 1999
Received: from relay5.ftech.net (littleblue.ftech.net [195.200.12.27])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA37977
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 09:26:38 -0500 (EST)
(envelope-from MarkA@idnltd.com)
Received: from ibm9.ftech.net ([212.32.16.79] helo=idnltd.com)
by relay5.ftech.net with smtp (Exim 3.12.ftech-p6 #1)
id 1203qt-0003AQ-00
for pgsql-general@postgresql.org; Mon, 20 Dec 1999 14:31:55 +0000
Message-ID: <003401bf4af5$0f3b4a10$c80110ac@centauri>
From: "Mark Alliban" <MarkA@idnltd.com>
To: <pgsql-general@postgresql.org>
Subject: Getting value of SERIAL column after insert from libpq?
Date: Mon, 20 Dec 1999 14:18:15 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0031_01BF4AF5.0E2E6DF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2110.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
This is a multi-part message in MIME format.
------=_NextPart_000_0031_01BF4AF5.0E2E6DF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I have written a C program to insert a row into a table with a SERIAL =
column.
Is there a way of returning the inserted value for this column to my =
program? I.e. if there are rows with the serial column for 1,2,3,4 and =
5, and I insert a row, my program needs to be told "6" for the new =
serial. There may be many instances of the program running =
simultaneously so I can't do a "select max..." or "select last_value..." =
workaround because by the time the select is done, there may have been =
other rows inserted so the last_value would be wrong. Also the program =
needs to be table-name and column-name independent so that it can work =
for ANY insert query into a table with a SERIAL column.
TIA,
Mark.
------=_NextPart_000_0031_01BF4AF5.0E2E6DF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>I have written a C =
program to insert=20
a row into a table with a SERIAL column.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Is there a way of =
returning the=20
inserted value for this column to my program? I.e. if there are rows =
with the=20
serial column for 1,2,3,4 and 5, and I insert a row, my program needs to =
be told=20
"6" for the new serial. There may be many instances of the =
program=20
running simultaneously so I can't do a "select max..." or =
"select=20
last_value..." workaround because by the time the select is done, =
there may=20
have been other rows inserted so the last_value would be wrong. Also the =
program=20
needs to be table-name and column-name independent so that it can work =
for ANY=20
insert query into a table with a SERIAL column.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>TIA,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Mark.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial =
size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_0031_01BF4AF5.0E2E6DF0--
From bouncefilter Mon Dec 20 09:51:59 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA44167
for <pgsql-general@postgreSQL.org>;
Mon, 20 Dec 1999 09:51:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
JAA19602;
Mon, 20 Dec 1999 09:48:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912201448.JAA19602@candle.pha.pa.us>
Subject: Re: [GENERAL] Getting value of SERIAL column after insert from libpq?
In-Reply-To: <003401bf4af5$0f3b4a10$c80110ac@centauri> from Mark Alliban at
"Dec 20, 1999 02:18:15 pm"
To: Mark Alliban <MarkA@idnltd.com>
Date: Mon, 20 Dec 1999 09:48:35 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Hi,
I have written a C program to insert a row into a table with a
SERIAL column.Is there a way of returning the inserted value for this column
to my program? I.e. if there are rows with the serial column
for 1,2,3,4 and 5, and I insert a row, my program needs to be
told "6" for the new serial. There may be many instances of the
program running simultaneously so I can't do a "select max..."
or "select last_value..." workaround because by the time the
select is done, there may have been other rows inserted so the
last_value would be wrong. Also the program needs to be table-name
and column-name independent so that it can work for ANY insert
query into a table with a SERIAL column.
Answer is that currval('seqence_name') will return your last sequence
number, even if another session has assigned a sequence number since
your nextval() call.
---------------------------------------------------------------------------
test=> create table oo(x serial, y text);
NOTICE: CREATE TABLE will create implicit sequence 'oo_x_seq' for
SERIAL column 'oo.x'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'oo_x_key' for
table 'oo'
CREATE
test=> insert into oo (y ) values ('ds');
INSERT 18879 1
test=> \d oo
Table "oo"
Attribute | Type | Extra
-----------+------+--------------------------------------------
x | int4 | not null default nextval('oo_x_seq'::text)
y | text |
Index: oo_x_key... Another session gets a new sequence number, but mine is the same
test=> select currval('oo_x_seq');
currval
---------
1
(1 row)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Dec 20 04:18:54 1999
Received: from impact1.hpcc.nectec.or.th (impact1.hpcc.nectec.or.th
[164.115.24.217]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA80988
for <pgsql-general@postgreSQL.org>;
Mon, 20 Dec 1999 04:18:01 -0500 (EST)
(envelope-from jhickey@impact1.hpcc.nectec.or.th)
Received: (from jhickey@localhost)
by impact1.hpcc.nectec.or.th (8.9.3/8.9.3) id QAA06071;
Mon, 20 Dec 1999 16:15:14 +0700 (TST)
From: "Justin Hickey" <jhickey@impact1.hpcc.nectec.or.th>
Message-Id: <9912201615.ZM6069@impact1.hpcc.nectec.or.th>
Date: Mon, 20 Dec 1999 16:15:14 +0000
In-Reply-To: Bruce Momjian <pgman@candle.pha.pa.us>
"Re: [GENERAL] Confirmation of feature of in version 7" (Dec 17,
12:52pm)
References: <199912171752.MAA17569@candle.pha.pa.us>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [GENERAL] Confirmation of feature of in version 7
Cc: pgsql-general@postgreSQL.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Bruce
Until today, there was hope that we could eliminate that limit in 7.0,
which goes to beta on Feb 1. However, the group has decided to not
included that in 7.0 because the job is larger than anticipated. It
will certainly be in 7.1. We realize many people need that
functionality, and we clearly have a plan to implement it. In fact,
coding has already begun on it.
This is great news!! Thank you very much for confirming this.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
==================================================================
From bouncefilter Mon Dec 20 11:35:59 1999
Received: from propertykey.com (IDENT:root@propertykey.com [206.196.37.193])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA69359
for <pgsql-general@postgreSQL.org>;
Mon, 20 Dec 1999 11:35:57 -0500 (EST)
(envelope-from jeff@propertykey.com)
Received: from propertykey.com (gotojail.propertykey.com [206.196.37.197])
by propertykey.com (8.9.3/8.9.3) with ESMTP id LAA20667
for <pgsql-general@postgreSQL.org>; Mon, 20 Dec 1999 11:35:56 -0600
Message-ID: <385E5AD6.B3FE607E@propertykey.com>
Date: Mon, 20 Dec 1999 10:35:34 -0600
From: Jeff Hoffmann <jeff@propertykey.com>
Organization: PropertyKey.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: recovering a "lost" database
References: <3859012C.3C6FAC7A@lillysoftware.com>
<004a01bf47d9$f9fac5e0$8402a8c0@sentec.demon.nl>
<385909C5.146770D3@lillysoftware.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
i have a database that was "lost" -- the database is still there (i can
see the files on disk in the database's directory), but when i try to
connect to the database, it says that it doesn't exist in pg_database.
what happened is that the database got dropped while the drive with the
data on it was unmounted, but now that i thought about it, it would be
nice to have a backup of it if i can get it. is there a way that i can
manually add it to the pg_database table (and are there other tables i
have to mess with?) so i can access it again?
thanks,
jeff
From bouncefilter Mon Dec 20 12:04:01 1999
Received: from goa1.dot.net.in (goa1.dot.net.in [202.54.17.30])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA75681
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 12:03:45 -0500 (EST)
(envelope-from grbhat@exocore.com)
Received: from suman.greenfields.universe (root@[202.54.17.82])
by goa1.dot.net.in (8.9.2/8.9.2) with ESMTP id WAA01596
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 22:35:19 +0530 (GMT)
Received: from localhost (grbhat@localhost)
by suman.greenfields.universe (8.9.3/8.9.3) with ESMTP id WAA01935
for <pgsql-general@postgresql.org>; Mon, 20 Dec 1999 22:30:37 +0530
Date: Mon, 20 Dec 1999 22:30:36 +0530 (IST)
From: "Gurunandan R. Bhat" <grbhat@exocore.com>
To: pgsql-general@postgresql.org
Subject: Trying to understand SPI
Message-ID:
<Pine.LNX.4.10.9912202209070.1887-100000@suman.greenfields.universe>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Greetings,
I have recently started working on PostgreSQL and am enjoying some
of its exciting features. I would now like to understand more about
incorporating my own functions into the Posgres backend. I have read
what I believe to be relevant documentation, and I have several questions.
Unfortunately a search of the mailing list archives could not yield a
"hit" on the phrases that I could come up with.
1) When I tried to compile some functions of my own, many header files
could not be located. I therefore copied the entire src/include tree
into /usr/local/pgsql/include. Is this a Bad Thing?
2) The examples in contrib/spi use several functions (elog, SPI_execp) and
typedefs (Relation, Trigger, Datum, EPlan) , which are not documented
in the Programmer's Manual. Where might I find the relevant
documentation?
3) Does one need a good grasp of PostgreSQL source internals before one
can use the SPI and other Extensible features of Postgres?
Thank you for time and attention.
Gurunandan
From bouncefilter Mon Dec 20 12:18:00 1999
Received: from oxmail.ox.ac.uk (oxmail3.ox.ac.uk [163.1.2.9])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA77702
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 12:17:55 -0500 (EST)
(envelope-from moray.mcconnachie@computing-services.oxford.ac.uk)
Received: from ermine.ox.ac.uk ([163.1.2.13])
by oxmail.ox.ac.uk with esmtp (Exim 2.10 #1) id 1206RV-0006GK-00
for pgsql-general@postgresql.org; Mon, 20 Dec 1999 17:17:53 +0000
Received: from ermine.ox.ac.uk ([163.1.2.13] helo=moraypc ident=root)
by ermine.ox.ac.uk with smtp (Exim 2.12 #1) id 1206RV-0007BH-00
for pgsql-general@postgresql.org; Mon, 20 Dec 1999 17:17:53 +0000
Message-ID: <00ca01bf4b0e$25490130$760e01a3@oucs.ox.ac.uk>
From: "Moray McConnachie" <moray.mcconnachie@computing-services.oxford.ac.uk>
To: <pgsql-general@postgresql.org>
Subject: 0x44
Date: Mon, 20 Dec 1999 17:17:51 -0000
Organization: Oxford University
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
I've very recently experienced a failure of my postgres database which
neither vacuuming nor rebuilding indices cured. This may have been
caused by my being forced to flip the switch - something that's never
happened to me under linux before, and on a machine with a light load
running nothing but postmaster, some postgres connections, a small
selection of admin demons and sshd.
Thereafter vacuum would die processing certain tables, and pg_dump
would fail similarly. Certain simple operations under psql failed
also, e.g. 'select fieldone,fieldtwo from table;'
I'm afraid I simply restored from backups, so I'm not in a position to
speculate on why it might have occurred, since I didn't delve much
further.
However, the message with which postgres crashed was along the lines
of
"backend received a 0x44 while idle" or something like that. This
appears to come from fe-exec.c, i.e. libpq, presumably.
Can anyone tell me what this means in the context? I did look at
source, but my C is non-existent.
I'm keeping a close eye out now, and will obviously post with logs if
the event recurs in the future.
Thanks,
Moray
----------------------------------------------------------------------
----------------
Moray.McConnachie@computing-services.oxford.ac.uk
From bouncefilter Mon Dec 20 12:29:01 1999
Received: from co832821-a (cogeco-91-40.cgocable.net [24.141.91.40])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA78914
for <pgsql-general@postgreSQL.org>;
Mon, 20 Dec 1999 12:28:02 -0500 (EST)
(envelope-from reinke@e-softinc.com)
Received: from e-softinc.com ([10.1.1.4])
by co832821-a (8.8.7/8.8.7) with ESMTP id MAA18220;
Mon, 20 Dec 1999 12:27:25 -0500
Message-ID: <385E671B.C93F49D6@e-softinc.com>
Date: Mon, 20 Dec 1999 12:27:55 -0500
From: Thomas Reinke <reinke@e-softinc.com>
Organization: E-Soft Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jose Soares <jose@sferacarta.com>
CC: Mike Beller <beller@tradeworx.com>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] copy command -- foiled by pg_atoi
References: <385C01E1.6876466D@tradeworx.com>
<385E345B.EB292FAD@sferacarta.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I've run into this a few times as well. My strategy to "hunt" down
the offending line has been to do a "bisection" algorithm.
Essentially, cut your file in half. If the first half loads ok,
you know the problem is in the second half, and vice versa.
Now cut the offending half in half again. Do the same.
With 23,000 rows, you will do this sequence no more than 15
times, and you will have narrowed down the offender (assuming
23,000 rows). With 2 million rows (something we've had to contend
with in the past), you'll nail it down in 21 iterations.
Not pretty to say the least, but workable.
Cheers, Thomas
Jose Soares wrote:
This is also my problem. I'm getting '@!?�����+*_|!&/%��' to load a
table with more than 23,000 rows
because I don't know in which line I have to look for the the error.
It's obvious that psql reads the input file line by line, and of course
psql knows in wich line the error
occurred. This information would be very important to correct any syntax
error in the file.Comments?
Jose'
Mike Beller wrote:
Hi
I'm using postgresql on RedHat/i386 from the RH6.1 RPMs
(Linux 2.2.5-15 PostgreSQL-6.5.2). I've been evaluating it,
and am quite excited about the possibilty of using this outstanding
open-source code in my company's systems.I noticed the following and want to submit it for your consideration:
When doing a 'copy' from a big text file, if there is a record, say
half way down, which has an unparseable integer field (say 'X'
in a column that shoudl be an integer) one gets the following error:ERROR: pg_atoi: error in "X": can't parse "X"
However, I don't get a line number reference where the error
occurred. This is a problem when you have half a million lines
in your file, some of which may contain legitimate X's as
well as non-legit ones. I don't even know which attribute failed.Simple example: (imagine a million rows with 12 columns and
you're trying to find the problem:)-------
create table foo (x int);
copy foo from stdin;
1
2
3
X
4
\.
-----------I noticed that in pg_atoi there is this code:
if (errno) /* strtol must set ERANGE */
elog(ERROR, "pg_atoi: error reading \"%s\": %m", s);
if (badp && *badp && (*badp != c))
elog(ERROR, "pg_atoi: error in \"%s\": can\'t parse
\"%s\"",s, badp);This is called (via int4in or some such) from copy.c:
values[i] = (Datum) (*fmgr_faddr(&in_functions[i]))(string,
elements[i],typmod[i]);
/*
* Sanity check - by reference attributes cannot
* return NULL
*/
if (!PointerIsValid(values[i]) &&
!(rel->rd_att->attrs[i]->attbyval))
elog(ERROR, "copy from line %d: Bad file format",
lineno);So the lineno information is there, it's just not available when pg_atoi
logs its error and bails out.Is it possible for pg_atoi to return an invalid pointer instead
of completely bailing out, thus allowing the 'sanity check' code
to print the line number? I have no idea how many things this
might break...Regards
Mike Beller
CTO
Tradeworx.com************
************
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
From bouncefilter Mon Dec 20 13:19:02 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA90966
for <pgsql-general@postgreSQL.org>;
Mon, 20 Dec 1999 13:18:14 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA24753;
Mon, 20 Dec 1999 13:16:54 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912201816.NAA24753@candle.pha.pa.us>
Subject: Re: [GENERAL] recovering a "lost" database
In-Reply-To: <385E5AD6.B3FE607E@propertykey.com> from Jeff Hoffmann at "Dec
20,
1999 10:35:34 am"
To: Jeff Hoffmann <jeff@propertykey.com>
Date: Mon, 20 Dec 1999 13:16:54 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
i have a database that was "lost" -- the database is still there (i can
see the files on disk in the database's directory), but when i try to
connect to the database, it says that it doesn't exist in pg_database.
what happened is that the database got dropped while the drive with the
data on it was unmounted, but now that i thought about it, it would be
nice to have a backup of it if i can get it. is there a way that i can
manually add it to the pg_database table (and are there other tables i
have to mess with?) so i can access it again?
Go into template1 database and insert a new row into the pg_database
table for the missing databases.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Dec 20 15:47:02 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA28490
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 15:46:35 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.93.43.211]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 20 Dec 1999 14:46:50 -0600
Sender: ed
Message-ID: <385E95D9.CAD4F50D@austin.rr.com>
Date: Mon, 20 Dec 1999 14:47:21 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Reinke <reinke@e-softinc.com>
CC: Jose Soares <jose@sferacarta.com>, Mike Beller <beller@tradeworx.com>,
pgsql-general@postgresql.org
Subject: Re: [GENERAL] copy command -- foiled by pg_atoi
References: <385C01E1.6876466D@tradeworx.com>
<385E345B.EB292FAD@sferacarta.com>
<385E671B.C93F49D6@e-softinc.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I have found that judicious placement of a few queries (selects, intentional
errors, etc.) within a long sequence of inserts will help segment them for
identification of offending lines. Hokie, but it helps me.
Cheers,
Ed Loehr
Thomas Reinke wrote:
I've run into this a few times as well. My strategy to "hunt" down
the offending line has been to do a "bisection" algorithm.Essentially, cut your file in half. If the first half loads ok,
you know the problem is in the second half, and vice versa.
Now cut the offending half in half again. Do the same.
With 23,000 rows, you will do this sequence no more than 15
times, and you will have narrowed down the offender (assuming
23,000 rows). With 2 million rows (something we've had to contend
with in the past), you'll nail it down in 21 iterations.Not pretty to say the least, but workable.
Cheers, Thomas
Jose Soares wrote:
This is also my problem. I'm getting '@!?�����+*_|!&/%��' to load a
table with more than 23,000 rows
because I don't know in which line I have to look for the the error.
It's obvious that psql reads the input file line by line, and of course
psql knows in wich line the error
occurred. This information would be very important to correct any syntax
error in the file.Comments?
Jose'
Mike Beller wrote:
Hi
I'm using postgresql on RedHat/i386 from the RH6.1 RPMs
(Linux 2.2.5-15 PostgreSQL-6.5.2). I've been evaluating it,
and am quite excited about the possibilty of using this outstanding
open-source code in my company's systems.I noticed the following and want to submit it for your consideration:
When doing a 'copy' from a big text file, if there is a record, say
half way down, which has an unparseable integer field (say 'X'
in a column that shoudl be an integer) one gets the following error:ERROR: pg_atoi: error in "X": can't parse "X"
However, I don't get a line number reference where the error
occurred. This is a problem when you have half a million lines
in your file, some of which may contain legitimate X's as
well as non-legit ones. I don't even know which attribute failed.Simple example: (imagine a million rows with 12 columns and
you're trying to find the problem:)-------
create table foo (x int);
copy foo from stdin;
1
2
3
X
4
\.
-----------I noticed that in pg_atoi there is this code:
if (errno) /* strtol must set ERANGE */
elog(ERROR, "pg_atoi: error reading \"%s\": %m", s);
if (badp && *badp && (*badp != c))
elog(ERROR, "pg_atoi: error in \"%s\": can\'t parse
\"%s\"",s, badp);This is called (via int4in or some such) from copy.c:
values[i] = (Datum) (*fmgr_faddr(&in_functions[i]))(string,
elements[i],typmod[i]);
/*
* Sanity check - by reference attributes cannot
* return NULL
*/
if (!PointerIsValid(values[i]) &&
!(rel->rd_att->attrs[i]->attbyval))
elog(ERROR, "copy from line %d: Bad file format",
lineno);So the lineno information is there, it's just not available when pg_atoi
logs its error and bails out.Is it possible for pg_atoi to return an invalid pointer instead
of completely bailing out, thus allowing the 'sanity check' code
to print the line number? I have no idea how many things this
might break...Regards
Mike Beller
CTO
Tradeworx.com************
************
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com************
From bouncefilter Mon Dec 20 16:11:02 1999
Received: from mailhub.usp.br (serv1.uspnet.usp.br [143.107.253.61])
by hub.org (8.9.3/8.9.3) with SMTP id QAA34458
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 16:10:34 -0500 (EST)
(envelope-from monteiro@ime.usp.br)
Received: (qmail 11306 invoked from network); 20 Dec 1999 21:09:39 -0000
Received: from unknown (HELO PLUCKY) (143.107.93.180)
by mailhub.usp.br with SMTP; 20 Dec 1999 21:09:39 -0000
Message-ID: <000801bf4b2e$8f390200$b45d6b8f@PLUCKY>
From: "Fabiano Ralo Monteiro" <monteiro@ime.usp.br>
To: <pgsql-general@postgresql.org>
Subject: PostgreSQL rows limit
Date: Mon, 20 Dec 1999 19:09:52 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0005_01BF4B1D.CB26B6B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01BF4B1D.CB26B6B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi folks,
According to the documentation, every row in a PostgreSQL =
database has a unique identifier (OID). Being this OID a 4-byte integer, =
I ask you: do this limit the number of rows that a database can hold (to =
2^32 ~=3D 4 billion) If yes, can I change that at compile time or such ?
Best Regards,
Fabiano
------=_NextPart_000_0005_01BF4B1D.CB26B6B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks,</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2> =
According to=20
the documentation, every row in a PostgreSQL database has a unique =
identifier=20
(OID). Being this OID a 4-byte integer, I ask you: do this limit the =
number of=20
rows that a database can hold (to 2^32 ~=3D 4 billion) If yes, can I =
change that=20
at compile time or such ?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Best Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Fabiano</FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01BF4B1D.CB26B6B0--
From bouncefilter Mon Dec 20 17:31:06 1999
Received: from www.inx.de (exim@www.inx.de [195.21.255.251])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA52581
for <pgsql-general@postgresql.org>;
Mon, 20 Dec 1999 17:30:21 -0500 (EST) (envelope-from plexus@snafu.de)
Received: from n65-246.berlin.snafu.de ([194.42.65.246] helo=snafu.de)
by www.inx.de with smtp (Exim 3.02 #1) id 120BJq-0000og-00
for pgsql-general@postgreSQL.org; Mon, 20 Dec 1999 23:30:19 +0100
Date: Mon, 20 Dec 1999 23:16:09 +0100
From: Oliver Fischer <plexus@snafu.de>
Reply-To: Oliver Fischer <plexus@snafu.de>
To: pgsql-general@postgresql.org
Subject: Description fo the database catalog
X-Mailer: Fischer Oliver's registered AK-Mail 3.0b [ger]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E120BJq-0000og-00@www.inx.de>
Hi,
i look for a good and detailed description of the catalog tables
like pg_class and their coloums. Where can i find it? Or it is in
the documentation and i haven't seen it?
Bye
Oliver
#--{ plexus@snafu.de }----------------------------
Oliver Fischer, Gleimstrasse 59, 10437 Berlin, Germany
From bouncefilter Mon Dec 20 16:28:02 1999
Received: from ubik.melog.com.pl (IDENT:qmailr@ubik.melog.com.pl
[212.160.91.66]) by hub.org (8.9.3/8.9.3) with SMTP id QAA36028
for <pgsql-general@hub.org>; Mon, 20 Dec 1999 16:27:49 -0500 (EST)
(envelope-from bart@ubik.melog.com.pl)
Received: (qmail 9397 invoked by uid 500); 20 Dec 1999 22:29:08 -0000
Date: Mon, 20 Dec 1999 23:29:08 +0100
From: Bart Ogryczak <bart@bart.w-wa.pl>
To: pgsql-general@hub.org
Subject: compiling PostgreSQL on SCO UW7?
Message-ID: <19991220232908.A9243@ubik.melog.com.pl>
Reply-To: bart@bart.w-wa.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.4us
Hi,
Is it possible to compile PostgresSQL on SCO UnixWare 7?
I've installed gnu make and gcc, but compilation (or rather
linking ) still fails complaining about declatration of
strdup and memset missing.
Just how hard is it to compile PostgresSQL on UW7?
Bar�omiej Ogryczak
--
Melog s.c. systemy i software http://www.melog.com.pl
Najlepszy serwis por�wnawczy w sieci http://to.czy.to
B.Ogryczak@melog.com.pl http://www.bart.w-wa.pl
From bouncefilter Mon Dec 20 05:29:55 1999
Received: from fep4-orange.clear.net.nz (fep4-orange.clear.net.nz
[203.97.32.4]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA94309
for <pgsql-general@hub.org>; Mon, 20 Dec 1999 05:29:16 -0500 (EST)
(envelope-from aibin@clear.net.nz)
Received: from clear.net.nz (d2-u3.acld.clear.net.nz [203.97.48.67]) by
fep4-orange.clear.net.nz (1.5/1.4) with ESMTP id XAA17681;
Mon, 20 Dec 1999 23:29:02 +1300 (NZDT)
Sender: postgres@clear.net.nz
Message-ID: <385EBB3B.FB04EC90@clear.net.nz>
Date: Tue, 21 Dec 1999 12:26:51 +1300
From: Peter Ai <aibin@clear.net.nz>
X-Mailer: Mozilla 4.51C-Caldera [en] (X11; I; Linux 2.2.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: peter_e@gmx.net, pgsql-general@hub.org
Subject: Re: Fw: [GENERAL] Postgres install problem
References: <000d01bf4ac6$e322c530$46c6a7cb@grace>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Peter Ai wrote:
----- Original Message -----
From: "Peter Eisentraut" <peter_e@gmx.net>
To: "Peter Ai" <aibin@clear.net.nz>
Cc: <pgsql-general@hub.org>
Sent: Sunday, December 19, 1999 5:13 AM
Subject: Re: [GENERAL] Postgres install problem
Thanks for that , But I only have /usr/lib/libshadow.so.0.0.0 and
/lib/libc-2.1.so
I tried adding -lcrypt or -lshadow without success.
Do i need glibc2.1 ?
On 1999-12-18, Peter Ai mentioned:
gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o
commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o
main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o
port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o
storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o
../utils/version.o -lnsl -ldl -lm -export-dynamic
libpq/SUBSYS.o: In function `crypt_verify':
libpq/SUBSYS.o(.text+0x3ca2): undefined reference to `crypt'
libpq/SUBSYS.o: In function `verify_password':
libpq/SUBSYS.o(.text+0x3fba): undefined reference to `crypt'
make[1]: *** [postgres] Error 1
make[1]: Leaving directory `/usr/src/pgsql/postgresql-6.5.3/src/backend'
make: *** [all] Error 2I'm not familiar with Caldera, but there is a slight chance that adding
one of -lcrypt or -lshadow to LDFLAGS in Makefile.global (after configure)
might help. If that doesn't work, look if your libcrypt.a or libshadow.a
library really exists and is findable or let us know what kind of C
library you have (ls /lib/libc.*). If that helps then we'd need to fix up
configure a little.--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Tue Dec 21 00:26:08 1999
Received: from mailbox.reptiles.org (IDENT:root@mailbox.reptiles.org
[198.96.117.155]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA29832
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 00:25:16 -0500 (EST)
(envelope-from jim@reptiles.org)
Received: from localhost (2529 bytes) by mailbox.reptiles.org
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <jim>) (ident <jim> using unix)
id <m120HnP-00080yC@mailbox.reptiles.org>
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 00:25:15 -0500 (EST)
(Smail-3.2.0.108 1999-Sep-19 #3 built 1999-Oct-27)
Message-Id: <m120HnP-00080yC@mailbox.reptiles.org>
From: jim@reptiles.org (Jim Mercer)
Subject: potential bug! hardcoded location of data files
To: pgsql-general@postgreSQL.org
Date: Tue, 21 Dec 1999 00:25:14 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
i started out with a normal installation where the PGDATA dir was
/usr/local/pgsql/data
the database grew, so i created /data/pgsql/data, moved the data and symlinked
/usr/local/pgsql/data to point to /data/pgsql/data.
at some point, i changed the PGDATA env var in ~pgsql/.profile to be
/data/pgsql/data, hence when the postmaster started up, the PGDATA env var
supposedly overrode the -D flag.
(my pgsql.sh rc startup file sources ~pgsql/.profile)
time moves on, and i jiggled the disk around, and actually mounted a RAID
array as /usr/local/pgsql/data.
in that process, i added a symlink pointing /data/pgsql/data back to
/usr/local/pgsql/data.
i then updated ~pgsql/.profile to have PGDATA using /usr/local/pgsql/data
once again.
i nuked the /data/pgsql/data symlink, figuring that both PGDATA and -D
both pointed to /usr/local/pgsql/data.
my applications, which insert piles of records into several tables went fine.
for about 6 hours.
then the nightly job fired up, halted the insert processes, and attempted to
vacuum the database.
well, things got highly unpleasant.
the normal vacuum on the main table crashed with a message saying the backend
was gone.
i killed and restarted the postmaster, and couldn't even do a "\dt".
i recompiled and installed (maybe the binaries somehow got icked??).
still vacuum crashed.
figuring something got icky, i su'd to pgsql and attempted to vacuum template1.
crash again.
i thought about what i had done, and thought i'd put back the symlink, pointing
/data/pgsql/data to /usr/local/pgsql/data.
whamo, the vacuums worked fine.
now, it just gets more strange, after vacuuming several tables (but not all
of them), decided to do some dignostics.
i nuked the symlink, and the vacuums worked fine.
so, my questions are:
does something somewhere records the absolute pathname?
does vacuum update this item using PGDATA?
why are absolute pathnames stored?
--
[ Jim Mercer jim@reptiles.org +1 416 506-0654 ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
From bouncefilter Tue Dec 21 00:44:10 1999
Received: from kiln.isn.net (root@kiln.isn.net [198.167.161.1])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA34347
for <pgsql-general@hub.org>; Tue, 21 Dec 1999 00:43:19 -0500 (EST)
(envelope-from ctassell@isn.net)
Received: from niki (ryan11.isn.net [198.167.161.81])
by kiln.isn.net (8.9.3/8.9.3) with ESMTP id BAA14676;
Tue, 21 Dec 1999 01:43:50 -0400
Message-Id: <4.2.0.58.19991221013818.00a516e0@mailer.isn.net>
X-Sender: ctassell@mailer.isn.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 21 Dec 1999 01:44:20 -0400
To: Peter Ai <aibin@clear.net.nz>, peter_e@gmx.net, pgsql-general@hub.org
From: Charles Tassell <ctassell@isn.net>
Subject: Re: Fw: [GENERAL] Postgres install problem
In-Reply-To: <385EBB3B.FB04EC90@clear.net.nz>
References: <000d01bf4ac6$e322c530$46c6a7cb@grace>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id AAA34433
Yes, you need the libc 2.1 crypt addon (it's a separate library due to the
US crypto export laws.) You should be able to get it from Caldera's web
site, it's called libcrypt-2.#.#.so
At 07:26 PM 12/20/99, Peter Ai wrote:
Peter Ai wrote:
----- Original Message -----
From: "Peter Eisentraut" <peter_e@gmx.net>
To: "Peter Ai" <aibin@clear.net.nz>
Cc: <pgsql-general@hub.org>
Sent: Sunday, December 19, 1999 5:13 AM
Subject: Re: [GENERAL] Postgres install problemThanks for that , But I only have /usr/lib/libshadow.so.0.0.0 and
/lib/libc-2.1.so
I tried adding -lcrypt or -lshadow without success.
Do i need glibc2.1 ?On 1999-12-18, Peter Ai mentioned:
gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o
commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o
main/SUBSYS.o parser/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o
port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o
storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o
../utils/version.o -lnsl -ldl -lm -export-dynamic
libpq/SUBSYS.o: In function `crypt_verify':
libpq/SUBSYS.o(.text+0x3ca2): undefined reference to `crypt'
libpq/SUBSYS.o: In function `verify_password':
libpq/SUBSYS.o(.text+0x3fba): undefined reference to `crypt'
make[1]: *** [postgres] Error 1
make[1]: Leaving directory`/usr/src/pgsql/postgresql-6.5.3/src/backend'
make: *** [all] Error 2
I'm not familiar with Caldera, but there is a slight chance that adding
one of -lcrypt or -lshadow to LDFLAGS in Makefile.global (afterconfigure)
might help. If that doesn't work, look if your libcrypt.a or libshadow.a
library really exists and is findable or let us know what kind of C
library you have (ls /lib/libc.*). If that helps then we'd need to fix up
configure a little.--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden************
From bouncefilter Tue Dec 21 00:50:08 1999
Received: from homer.is.com.fj (homer.is.com.fj [202.62.124.238])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA35153
for <pgsql-general@hub.org>; Tue, 21 Dec 1999 00:49:42 -0500 (EST)
(envelope-from jrh@is.com.fj)
Received: from john (test2.is.com.fj [202.62.124.234])
by homer.is.com.fj (8.9.3/8.9.3) with SMTP id SAA13579;
Tue, 21 Dec 1999 18:49:11 +1300 (FJDST)
Message-ID: <008e01bf4b7f$155fe880$ea7c3eca@john.is.com.fj>
Reply-To: "John Henderson" <jrh@is.com.fj>
From: "John Henderson" <jrh@is.com.fj>
To: <bsdi-users@mailinglists.org>, <pgsql-general@hub.org>
Cc: "Sin'ichiro MIYATANI" <siu@phaseone.co.jp>, <daniel@digsys.bg>
Subject: shared memory
Date: Tue, 21 Dec 1999 18:46:04 +1200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Hi y'all,
Here is the latest update.
The problem is with PostgreSQL allocating shared memory in BSD/OS 3.0.
The system has 128M of RAM and 262M of swap.
Currently postgres starts as:
su -l postgres -c '/usr/local/pgsql/bin/postmaster -i -d 3 -B 887 -o "-eF
-S 1024" >> /var/log/postgres 2>&1 &'
without problems. However, try to start with -B 1024 (which allocates 1024
of 8K blocks used for shared memory buffers)
and the following is logged:
FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
binding ShmemCreate(key=52e2c1, size=8852184)
IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=8852184,
per
mission=600
FATAL 1: ShmemCreate: cannot create region
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
OK, so we have to get BSD/OS to allocate more shared memory.
Note that the actual postgres error is related to calloc and malloc and
something else that specifically tells me to increase -B.
When -B is increased to 1024 the daemon dies as soon as it starts. The error
is not with memory usage but with memory allocation.
In this case setting
#options SYSVSHM
#options SYSVSEM
#options SYSVMSG
have no value. In some older version of BSD these would tell the compiler to
include the optional shared memory header files which are automatically
included in this version of BSD so these configs are redundant.
In previous attempts I have mucked with:
#options "KMEMSIZE=\(16*1024*1024\)"
#options "DFLDSIZ=\(32*1024*1024\)"
#options "DFLSSIZ=\(4*1024*1024\)"
#options "SOMAXCONN=128"
#options "MAXDSIZ=\(256*1024*1024\)"
and made them available to the shell with ulimit. All to no avail.
Currently I use the default values from BSD so my front end processes get:
moe:~ $ ulimit -a
core file size (blocks) unlimited
data seg size (kbytes) 32768
file size (blocks) unlimited
max memory size (kbytes) 126280
stack size (kbytes) 32768
cpu time (seconds) unlimited
max user processes 64
pipe size (512 bytes) 2
open files 128
virtual memory (kbytes) 65536
The backend of PostgreSQL is booted from a script /etc/rc.postgres with
ulimit -d unlimited just before the daemon is started so I am assuming that
postgres gets lots of data space.
(In fact I have checked this out and it is true).
Adjusting
#options "SHMMAXPGS=4096"
has no effect. The BSD default seems to be 2048 pages and pages are 4K.
That means the BSD default is around 8M which is just above my -B 886 (*8 =
7.5M) allocation for shared memory.
Allowing the system to soak up some shared mem for whatever reason I would
say this is the variable that I have to adjust.
So why doesn't it adjust!!??
Sin'ichiro M from sdi-users suggested it might be related to semaphore
identifiers:
but when I used a config from Daniel Kalchev
options "KMAPENTRIES=4000" #prevents kmem malloc errors
options "SHMMAXPGS=32768"
options "SHMMNI=400"
options "SHMSEG=204"
options "SEMMNS=600"
Nothing different happens.
Finally there is a tip from Bruce that I need to increase SYSPTSIZE, the
number of dynamically allocated page tables for the kernel.
SYSPTSIZE is discovered by
bpatch -r sysptsize
In my case 28.
You can adjust this directly into the finished kernel by
bpatch sysptsize 40
Don't forget to reboot so that the change becomes effective.
This should actually allow me to allocate 12*4 = 48 extra Megs of shared
memory.
Guess what, no difference.
Thanks to anyone who has read this far.
Here are some questions:
1) What part of memory do shared memory buffers get loaded into: kernel?
data? This is to determine which of the ulimitable variables to concentrate
on.
2) Is it universally agreed that SHMMAXPGS is the key variable to address
and we just need to figure out what is related directly to it?
3) I don't have a clue - do you?
Best,
John Henderson
From bouncefilter Tue Dec 21 02:22:10 1999
Received: from dcave.digsys.bg (root@dcave.digsys.bg [192.92.129.5])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA52277
for <pgsql-general@hub.org>; Tue, 21 Dec 1999 02:21:44 -0500 (EST)
(envelope-from daniel@dcave.digsys.bg)
Received: from dcave.digsys.bg (daniel@localhost.digsys.bg [127.0.0.1])
by dcave.digsys.bg (8.9.0/8.9.0) with ESMTP id JAA24199;
Tue, 21 Dec 1999 09:19:36 +0200 (EET)
Message-Id: <199912210719.JAA24199@dcave.digsys.bg>
X-Mailer: exmh version 2.0.2 2/24/98
To: "John Henderson" <jrh@is.com.fj>
cc: bsdi-users@mailinglists.org, pgsql-general@hub.org,
"Sin'ichiro MIYATANI" <siu@phaseone.co.jp>
Subject: Re: shared memory
In-reply-to: Your message of "Tue, 21 Dec 1999 18:46:04 +1200."
<008e01bf4b7f$155fe880$ea7c3eca@john.is.com.fj>
Date: Tue, 21 Dec 1999 09:19:34 +0200
From: Daniel Kalchev <daniel@digsys.bg>
I have further researched this topic to find out that in the shmget man page
it says:
[EINVAL] Size specified is greater than the size of the previously
existing segment. Size specified is less than the system
imposed minimum, or greater than the system imposed maxi-
mum.
This is the error you get.
However, what you get is not related to BSD/OS shared memory limits. My
'limit' errors were resolved by increased the BSD/OS kernel options as
described. I unsed to get the error:
IpcMemoryCreate: shmget failed (Cannot allocate memory) key=5432101,
size=3070976, permission=600
Note the diffrerent errors (in the parenthesis). Actually, the BSD/OS 3.x
shmget man page does not specify that ENOMEM (my problem) can be returned. :-)
Hope this helps find where this problem is - in my opinion PostgreSQL wrongly
makes assumptions about shared memory allocation, that might happen to work on
some platforms (e.g. Linux), but perhaps not on others.
Regards,
Daniel
"John Henderson" said:
Hi y'all,
Here is the latest update.The problem is with PostgreSQL allocating shared memory in BSD/OS 3.0.
The system has 128M of RAM and 262M of swap.
Currently postgres starts as:su -l postgres -c '/usr/local/pgsql/bin/postmaster -i -d 3 -B 887 -o "-eF
-S 1024" >> /var/log/postgres 2>&1 &'without problems. However, try to start with -B 1024 (which allocates 1024
of 8K blocks used for shared memory buffers)
and the following is logged:FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
binding ShmemCreate(key=52e2c1, size=8852184)
IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=8852184,
per
mission=600
FATAL 1: ShmemCreate: cannot create region
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)OK, so we have to get BSD/OS to allocate more shared memory.
Note that the actual postgres error is related to calloc and malloc and
something else that specifically tells me to increase -B.
When -B is increased to 1024 the daemon dies as soon as it starts. The error
is not with memory usage but with memory allocation.In this case setting
#options SYSVSHM
#options SYSVSEM
#options SYSVMSGhave no value. In some older version of BSD these would tell the compiler to
include the optional shared memory header files which are automatically
included in this version of BSD so these configs are redundant.In previous attempts I have mucked with:
#options "KMEMSIZE=\(16*1024*1024\)"
#options "DFLDSIZ=\(32*1024*1024\)"
#options "DFLSSIZ=\(4*1024*1024\)"
#options "SOMAXCONN=128"
#options "MAXDSIZ=\(256*1024*1024\)"
and made them available to the shell with ulimit. All to no avail.
Currently I use the default values from BSD so my front end processes get:
moe:~ $ ulimit -a
core file size (blocks) unlimited
data seg size (kbytes) 32768
file size (blocks) unlimited
max memory size (kbytes) 126280
stack size (kbytes) 32768
cpu time (seconds) unlimited
max user processes 64
pipe size (512 bytes) 2
open files 128
virtual memory (kbytes) 65536The backend of PostgreSQL is booted from a script /etc/rc.postgres with
ulimit -d unlimited just before the daemon is started so I am assuming that
postgres gets lots of data space.
(In fact I have checked this out and it is true).Adjusting
#options "SHMMAXPGS=4096"
has no effect. The BSD default seems to be 2048 pages and pages are 4K.
That means the BSD default is around 8M which is just above my -B 886 (*8 =
7.5M) allocation for shared memory.
Allowing the system to soak up some shared mem for whatever reason I would
say this is the variable that I have to adjust.
So why doesn't it adjust!!??
Sin'ichiro M from sdi-users suggested it might be related to semaphore
identifiers:
but when I used a config from Daniel Kalchev
options "KMAPENTRIES=4000" #prevents kmem malloc errors
options "SHMMAXPGS=32768"
options "SHMMNI=400"
options "SHMSEG=204"
options "SEMMNS=600"
Nothing different happens.Finally there is a tip from Bruce that I need to increase SYSPTSIZE, the
number of dynamically allocated page tables for the kernel.
SYSPTSIZE is discovered by
bpatch -r sysptsize
In my case 28.
You can adjust this directly into the finished kernel by
bpatch sysptsize 40
Don't forget to reboot so that the change becomes effective.
This should actually allow me to allocate 12*4 = 48 extra Megs of shared
memory.
Guess what, no difference.Thanks to anyone who has read this far.
Here are some questions:
1) What part of memory do shared memory buffers get loaded into: kernel?
data? This is to determine which of the ulimitable variables to concentrate
on.
2) Is it universally agreed that SHMMAXPGS is the key variable to address
and we just need to figure out what is related directly to it?
3) I don't have a clue - do you?
Best,
John Henderson
From bouncefilter Tue Dec 21 01:52:09 1999
Received: from homer.is.com.fj (homer.is.com.fj [202.62.124.238])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA46866
for <pgsql-general@hub.org>; Tue, 21 Dec 1999 01:51:15 -0500 (EST)
(envelope-from jrh@is.com.fj)
Received: from john (test2.is.com.fj [202.62.124.234])
by homer.is.com.fj (8.9.3/8.9.3) with SMTP id TAA21505;
Tue, 21 Dec 1999 19:51:05 +1300 (FJDST)
Message-ID: <000901bf4b87$b4398580$ea7c3eca@john.is.com.fj>
Reply-To: "John Henderson" <jrh@is.com.fj>
From: "John Henderson" <jrh@is.com.fj>
To: <bsdi-users@mailinglists.org>, <pgsql-general@hub.org>
Subject: shared memory
Date: Tue, 21 Dec 1999 19:47:59 +1200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Hi there,
Someone suggested to me that if BSDI loads a kernel with certain memory
configuration errors it will not panic but simply revert to its defaults.
Could this be why all of my kernel tinkering is in vain. I am missing some
config and so everything else is being ignored. Is this even plausible.
G'night,
John
From bouncefilter Tue Dec 21 03:38:10 1999
Received: from innocence.interface-business.de
(innocence.interface-business.de [193.101.57.202])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA73369
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 03:37:49 -0500 (EST)
(envelope-from gerald@mauz.interface-business.de)
Received: from mauz.interface-business.de (mauz.interface-business.de
[193.101.57.233])
by innocence.interface-business.de with ESMTP id JAA41156;
Tue, 21 Dec 1999 09:37:47 +0100 (CET)
Received: (from gerald@localhost)
by mauz.interface-business.de (8.8.8/8.8.8) id JAA05705;
Tue, 21 Dec 1999 09:37:47 +0100 (CET) (envelope-from gerald)
Message-ID: <XFMail.991221093746.postgres@taifun.interface-business.de>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <93314B6256A5D211BE8B006097B95027179164@NZAM>
Date: Tue, 21 Dec 1999 09:37:46 +0100 (CET)
Reply-To: gerald@interface-business.de
Organization: Interface Business
Sender: gerald@mauz.interface-business.de
From: postgres@taifun.interface-business.de
To: "Derricutt, Mark" <DerricuttM@pbworld.com>
Subject: RE: [GENERAL] Announce: Postgres Access Control Tool
Cc: pgsql-general@postgreSQL.org
Hi Mark,
Is there anyway I can get this run under Tcl/Tk on Windows NT? I tried
simply loading ./paco into wish but it failed looking up /usr/....
references.
I haven't tested PACO on Windows. But this should work:
PACO needs two Tcl/Tk extensions loaded as shared object files:
libpgtcl.so - Tcl/Tk Postgres interface
libtix.so - widget frameset
On Windows this files are LIBPGTCL.DLL and LIBTIX.DLL. The first
is part of Postgres and the second can be downloaded from
ftp://www.neosoft.com/pub/tcl/sorted/packages-7.6/unknown/tixwin41p6bin.zip
You have to edit the PACO source and correct the path. (Search
for the "load" command at top of the file.)
Please let me know if all has done ok.
Gerald
From bouncefilter Tue Dec 21 10:20:15 1999
Received: from mailgate1a.bridge.com (firewall-user@mailgate1a.ext.bridge.com
[167.76.159.72]) by hub.org (8.9.3/8.9.3) with SMTP id KAA51049
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 10:20:06 -0500 (EST)
(envelope-from tayers@bridge.com)
Received: by mailgate1a.bridge.com; id JAA14924;
Tue, 21 Dec 1999 09:20:02 -0600
Received: from unknown(167.76.56.34) by mailgate1a.bridge.com via smap (V5.5)
id xma014831; Tue, 21 Dec 99 09:19:49 -0600
Received: from mnmailhost (mnmailhost.bridge.com [167.76.59.14]) by
mail1srv.bridge.com (8.8.8/8.7.3) with SMTP id JAA20654 for
<pgsql-general@postgreSQL.org>; Tue, 21 Dec 1999 09:19:47 -0600 (CST)
Received: from 89-8 ([167.76.89.8]) by mnmailhost (4.1/SMI-4.1)
id AA03137; Tue, 21 Dec 99 10:19:43 EST
Date: Tue, 21 Dec 99 10:19:42 EST
Message-Id: <9912211519.AA03137@mnmailhost>
From: Tim Ayers <tayers@bridge.com>
To: pgsql-general@postgreSQL.org
Reply-To: tayers@bridge.com
subscribe
end
From bouncefilter Tue Dec 21 07:09:12 1999
Received: from shaked.cc.openu.ac.il (shaked.cc.openu.ac.il [147.233.145.65])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA12883
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 07:08:14 -0500 (EST)
(envelope-from herouth@oumail.openu.ac.il)
Received: from [147.233.159.109] (herouth@mac-herouth.pc.openu.ac.il
[147.233.159.109])
by shaked.cc.openu.ac.il (8.8.8/8.8.8) with ESMTP id OAA25852
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 14:08:11 +0200 (IST)
X-Sender: herouth@shaked.cc.openu.ac.il
Message-Id: <l03130301b4851b846903@[147.233.159.109]>
In-Reply-To: <199912170100.TAA11338@mail.xnet.com>
References: Your message of "Thu, 16 Dec 1999 16:54:07 +0200."
<002801bf47d5$6aebaee0$ce2a18c3@skillbrokers.bg>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 21 Dec 1999 14:08:50 +0200
To: "pgsql-general" <pgsql-general@postgreSQL.org>
From: Herouth Maoz <herouth@oumail.openu.ac.il>
Subject: Re: [GENERAL] char(xx) problem
At 4:02 +0200 on 17/12/1999, Gene Selkov, Jr. wrote:
I'm just wondering: are there any alternatives to blank padding? Why
is it done in the first place?
That's how fixed-length char type works, since the early days of SQL. You
come to expect it, which means that if you use legacy code that has a
fixed-width char type, or you decided to use it for its time-saving
possibilities, it should behave according to some way which has been
established long ago.
What I don't get is why, given two bpchar argument, Postgres doesn't just
pad the shorter one to the length of the other and then compares, selects
and whatnot.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herouth/personal/
From bouncefilter Tue Dec 21 08:17:13 1999
Received: from alert.infoplease.com ([208.222.166.25])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA25659
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 08:16:42 -0500 (EST)
(envelope-from kdebisschop@range.infoplease.com)
Received: from skillet.infoplease.com (skillet [10.0.1.212])
by alert.infoplease.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27829
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 08:16:10 -0500 (EST)
Received: (from kdebisschop@localhost)
by skillet.infoplease.com (8.9.3/8.9.1) id IAA01837;
Tue, 21 Dec 1999 08:16:11 -0500
Date: Tue, 21 Dec 1999 08:16:11 -0500
Message-Id: <199912211316.IAA01837@skillet.infoplease.com>
X-Authentication-Warning: skillet.infoplease.com: kdebisschop set sender to
kdebisschop@spaceheater.infoplease.com using -f
From: Karl DeBisschop <kdebisschop@range.infoplease.com>
To: pgsql-general@postgreSQL.org
In-reply-to: <8703.945457153@sss.pgh.pa.us> (message from Tom Lane on Fri, 17
Dec 1999 13:59:13 -0500)
Subject: Cannot index large table in 6.5.3 on Linux
Reply-to: kdebisschop@range.infoplease.com
References: <8703.945457153@sss.pgh.pa.us>
This was originally posted on bugs, to no avail. Maybe someone else
in the general mailing list has had similar problems and can shed some
light.
Basically, the subject say it all. I am trying to index a text field
in a somehwhat large table (approx 1GB). We have had this database
running for over a year now, and we have never had this problem until
upgrading to 6.5.3. Most recently, we were running 6.5.1 and the
table indexed fine. We do a lot of inserts on the table each night,
so we drop the index first for performance reasons. Since upgrading
to 6.5.3, we have not been able to recreate the index (However, an
index on a char(1) field and a joint index on (date,integer) both do
work -- they generate 200000000 byte indexes.)
When we moved to 6.5.3, we vacuumed the database just to be make sure
there were no problems. That worked fine. It's just the creation
that seems to be the problem.
I have watched the process of creation. It seems to get most or all
of the way through the process - it creates an index file about the
size of the old one (~750000000 bytes). Then we get:
webusers=> CREATE INDEX zdaily_id ON daily (id);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.
and everything is deleted.
The original 6.5.3 install was from the RPM. I have recompiled the
database on the machine in question, and still the same result. I
have tried both btree and hash indexes, still the same result. At
first, the table spanned two files. I moved old data out and shrunk
it to one file. Still the same result.
I have not been able to cause postmaster to generate a core when it
dies.
So no I'm stumped.
I am running on 1 dual-processor VA-linux machine:
Architecture (example: Intel Pentium) :
Intel Pentium III 450MHz x2 SMP
Operating System (example: Linux 2.0.26 ELF) :
Linux version 2.2.7-1.23smp (root@jiangsup.var.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Thu Jul 8 15:23:01 PDT 1999
PostgreSQL version (example: PostgreSQL-6.5.2): PostgreSQL-6.5.3
(from postgresql-6.5.3-1.i386.rpm distributed by
www.POstgreSQL.org, then compiled on local machine)
Compiler used (example: gcc 2.8.0) :
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
I would appreciate any suggestions on additional possibilities for
diagnosis or repair.
--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.832.0332 (Fax: 617.956.2696)
Information Please - your source for FREE online reference
http://www.infoplease.com - Your Ultimate Fact Finder
http://kids.infoplease.com - The Great Homework Helper
Netsaint Plugins Development
http://netsaintplug.sourceforge.net
From bouncefilter Tue Dec 21 10:07:18 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id KAA49380
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 10:07:03 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 12441 invoked by uid 417); 21 Dec 1999 15:12:29 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 21 Dec 1999 15:12:29 -0000
Message-ID: <004201bf4bc4$f0ace880$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-general@postgreSQL.org>
Cc: <j.roeleveld@softhome.net>
Subject: item descriptions in psql
Date: Tue, 21 Dec 1999 16:06:14 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I just found a reference to descriptions to functions/tables/...etc.
and am now wondering how to add them myself?
Joost Roeleveld
ps. as an example of what I'm referring to:
mydb=> \dd currval
description
----------------------
sequence current value
(1 row)
mydb=> \dd mytable --- I want to enter a description for this......
description
--------------
no description
(1 row)
From bouncefilter Tue Dec 21 10:07:18 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id KAA49387
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 10:07:15 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 12822 invoked by uid 417); 21 Dec 1999 15:12:50 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 21 Dec 1999 15:12:50 -0000
Message-ID: <004301bf4bc4$fd375b80$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-general@postgreSQL.org>
Cc: <j.roeleveld@softhome.net>
Subject: item descriptions in psql
Date: Tue, 21 Dec 1999 16:06:14 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I just found a reference to descriptions to functions/tables/...etc.
and am now wondering how to add them myself?
Joost Roeleveld
ps. as an example of what I'm referring to:
mydb=> \dd currval
description
----------------------
sequence current value
(1 row)
mydb=> \dd mytable --- I want to enter a description for this......
description
--------------
no description
(1 row)
From bouncefilter Tue Dec 21 10:31:16 1999
Received: from kevlo.efsns.com ([210.241.235.250])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA54750;
Tue, 21 Dec 1999 10:30:53 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (kevlo.efsns.com [210.241.235.250])
by kevlo.efsns.com (8.9.3/8.9.3) with ESMTP id XAA00518;
Tue, 21 Dec 1999 23:38:43 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@@wahoo.com.tw
Message-ID: <385F9F03.D9C199A0@hello.com.tw>
Date: Tue, 21 Dec 1999 23:38:43 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; Linux 2.0.36 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-announce@postgreSQL.org, pgsql-general@postgreSQL.org,
pgsql-interfaces@postgreSQL.org, pgsql-ports@postgreSQL.org
Subject: Announce: PostgreSQL-6.5.3 binaries available for Windows NT
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Hi,
Some people asked me to build PostgreSQL binaries for Windows NT.
The binaries(PostgreSQL-6.5.3) are now available at:
ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Please go to my page if you want to build it yourself :)
http://www.freebsd.org/~kevlo/postgres/portNT.html
The Chinese version is at:
http://www.freebsd.org/~kevlo/postgres/portNT_Big5.html
Enjoy!
Kevin.
From bouncefilter Tue Dec 21 10:48:19 1999
Received: from eth.net (pop3.eth.net [202.9.145.19])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57977
for <pgsql-general@postgresql.org>;
Tue, 21 Dec 1999 10:46:45 -0500 (EST)
(envelope-from kimi@intercept.co.in)
Received: from intercept.co.in ([202.9.149.6]) by eth.net with Microsoft
SMTPSVC(5.5.1877.357.35); Tue, 21 Dec 1999 21:15:46 +0530
Message-ID: <385F9F57.32618C61@intercept.co.in>
Date: Tue, 21 Dec 1999 21:10:08 +0530
From: Kimi <kimi@cricket.org>
Reply-To: kimi@intercept.co.in
Organization: Intercept
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org, scrappy@hub.org
Subject: Release LRU file
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
This is in continuation of mails I sent last week about postgres
crashing
We are running pg 6.5.1, on Redhar 5.1 with DBI 0.92 and DBD 1.13 on a
512 MB RAM
and SCSI machine
Our application consists of requests going upto 150 per second on this
database
with an expected uptime of 24 by 7.
Earlier we were getting spinlock messages which we have hoped to sort
out by raising
number of open files per process to 1024 from the earlier 256
Postgres crashes giving an error message : FATAL 1: Release LRU file :
No opened files /
no one can be closed.
Now can anybody help on how to solve this.
Please help
Bye,
Murali
Differentiated Software Solutions
From bouncefilter Tue Dec 21 11:18:18 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA66749
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 11:17:55 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id LAA19916;
Tue, 21 Dec 1999 11:15:49 -0500
Message-ID: <385FA7E0.C9C26701@mascari.com>
Date: Tue, 21 Dec 1999 11:16:32 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: kimi@intercept.co.in
CC: pgsql-general@postgreSQL.org, scrappy@hub.org
Subject: Re: [GENERAL] Release LRU file
References: <385F9F57.32618C61@intercept.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kimi wrote:
Hi,
This is in continuation of mails I sent last week about postgres
crashing
We are running pg 6.5.1, on Redhar 5.1 with DBI 0.92 and DBD 1.13 on a
512 MB RAM
and SCSI machineOur application consists of requests going upto 150 per second on this
database
with an expected uptime of 24 by 7.
Earlier we were getting spinlock messages which we have hoped to sort
out by raising
number of open files per process to 1024 from the earlier 256Postgres crashes giving an error message : FATAL 1: Release LRU file :
No opened files /
no one can be closed.Now can anybody help on how to solve this.
Please help
Bye,
Murali
Differentiated Software Solutions
We have been running a production server under a somewhat
lighter load, and encountered this once. The following
conversation took place on the mailing list about a month
ago:
http://www.PostgreSQL.ORG/mhonarc/pgsql-hackers/1999-11/msg00454.html
------------------------------------------------------------
Mike Mascari <mascarim@yahoo.com> writes:
FATAL 1: ReleaseLruFile: No opened files - no one can be closed
This is the first time this has ever happened.
I've never seen that either. Offhand I do not recall any
post-6.5
changes that would affect it, so the problem (whatever it
is) is
probably still there.
After eyeballing the code, it seems there are only two ways
this
could happen:
1. the number of "allocated" (non-virtual) file descriptors
grew to
exceed the number of files Postgres thinks it can have open;
2. something else was temporarily exhausting your kernel's
file table
space, so that ENFILE was returned for many successive
attempts to
open a file. (After each one, fd.c will close another file
and try
again.)
#2 seems improbable on an unloaded system, and isn't real
probable even
on a loaded one, since you'd have to assume that some other
process
managed to suck up each filetable slot that fd.c released
before fd.c
could re-acquire it. Once, yes, but several dozen times in
a row?
So I'm guessing a leak of allocated file descriptors.
After grovelling through the calls to AllocateFile, I only
see one
prospect for a leak: it looks to me like verify_password()
neglects
to close the password file if an invalid user name is
given. Do you
use a plain (non-encrypted) password file? If so, I'll bet
you can
reproduce the crash by trying repeatedly to connect with a
username
that's not in the password file. If that pans out, it's a
simple fix:
add "FreeFile(pw_file);" near the bottom of
verify_password() in
src/backend/libpq/password.c. Let me know if this guess is
right...
regards, tom lane
------------------------------------------------------------
Hope that helps,
Mike Mascari
From bouncefilter Tue Dec 21 11:22:15 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA67255
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 11:22:13 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id LAA19942;
Tue, 21 Dec 1999 11:19:54 -0500
Message-ID: <385FA8D5.39FB7CE0@mascari.com>
Date: Tue, 21 Dec 1999 11:20:37 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "J. Roeleveld" <j.roeleveld@softhome.net>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] item descriptions in psql
References: <004301bf4bc4$fd375b80$8402a8c0@sentec.demon.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"J. Roeleveld" wrote:
Hi,
I just found a reference to descriptions to functions/tables/...etc.
and am now wondering how to add them myself?Joost Roeleveld
ps. as an example of what I'm referring to:
mydb=> \dd currval
description
----------------------
sequence current value
(1 row)mydb=> \dd mytable --- I want to enter a description for this......
description
--------------
no description
(1 row)
In the next release, PostgreSQL will have the equivalent of
Oracle's COMMENT ON statement to allow for user comments of
various database schema objects. Until then, you have to
manually insert rows into pg_description with the oid of the
target object and the relevant comments:
emptoris=> select oid from pg_class where relname =
'webusers';
oid
------
155868
(1 row)
emptoris=> insert into pg_description values (155868,
'Webuser Information');
INSERT 182688 1
emptoris=> \dd webusers;
description
-------------------
Webuser Information
(1 row)
Hope that helps,
Mike Mascari
From bouncefilter Tue Dec 21 11:42:17 1999
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA72733;
Tue, 21 Dec 1999 11:41:49 -0500 (EST) (envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id 68BB1B2EE; Tue, 21 Dec 1999 18:44:45 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <385FAE7D.9AFD4D22@tm.ee>
Date: Tue, 21 Dec 1999 18:44:45 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Lo <kevlo@hello.com.tw>
Cc: pgsql-announce@postgreSQL.org, pgsql-general@postgreSQL.org,
pgsql-interfaces@postgreSQL.org, pgsql-ports@postgreSQL.org
Subject: Re: [ANNOUNCE] Announce: PostgreSQL-6.5.3 binaries available for
Windows NT
References: <385F9F03.D9C199A0@hello.com.tw>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kevin Lo wrote:
Hi,
Some people asked me to build PostgreSQL binaries for Windows NT.
The binaries(PostgreSQL-6.5.3) are now available at:ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Great !
Please go to my page if you want to build it yourself :)
http://www.freebsd.org/~kevlo/postgres/portNT.html
The Chinese version is at:
And could someone please put a note about them on www.postgresql.org ?
I searched it on Sunday for just this and I could only find a link to
the last url - the chinese translation ;(
---------------
Hannu
From bouncefilter Tue Dec 21 20:48:22 1999
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA89953;
Tue, 21 Dec 1999 20:48:09 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id JAA68966;
Wed, 22 Dec 1999 09:47:58 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <38602DCE.DDE8DD2A@hello.com.tw>
Date: Wed, 22 Dec 1999 09:47:58 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: pgsql-announce@postgreSQL.org, pgsql-general@postgreSQL.org,
pgsql-interfaces@postgreSQL.org, pgsql-ports@postgreSQL.org
Subject: Re: [ANNOUNCE] Announce: PostgreSQL-6.5.3 binaries available
forWindows NT
References: <385F9F03.D9C199A0@hello.com.tw> <385FAE7D.9AFD4D22@tm.ee>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Hannu Krosing wrote:
Kevin Lo wrote:
Hi,
Some people asked me to build PostgreSQL binaries for Windows NT.
The binaries(PostgreSQL-6.5.3) are now available at:ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Great !
Please go to my page if you want to build it yourself :)
http://www.freebsd.org/~kevlo/postgres/portNT.html
The Chinese version is at:
And could someone please put a note about them on www.postgresql.org ?
I searched it on Sunday for just this and I could only find a link to
the last url - the chinese translation ;(
Seems you don't read the FAQ :)
See http://www.postgresql.org/docs/faq-english.html#1.4
---------------
Hannu
- Kevin
From bouncefilter Tue Dec 21 23:48:24 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA24977
for <pgsql-general@postgresql.org>;
Tue, 21 Dec 1999 23:48:22 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.169]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 21 Dec 1999 22:39:52 -0600
Sender: ed
Message-ID: <38605846.3F21ADA9@austin.rr.com>
Date: Tue, 21 Dec 1999 22:49:10 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pg-gen <pgsql-general@postgresql.org>
Subject: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS NOT THE
SAME AS HEAP' (1070)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)
Cheers,
Ed Loehr
From bouncefilter Tue Dec 21 23:53:24 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id XAA25502
for <pgsql-general@postgreSQL.org>;
Tue, 21 Dec 1999 23:53:13 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA28094;
Tue, 21 Dec 1999 23:52:32 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912220452.XAA28094@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071) IS NOT THE SAME AS HEAP' (1070)
In-Reply-To: <38605846.3F21ADA9@austin.rr.com> from Ed Loehr at "Dec 21, 1999
10:49:10 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Tue, 21 Dec 1999 23:52:32 -0500 (EST)
CC: pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)
Drop index and recreate. Next release will be more specific in error
message.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 00:11:24 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA30806
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 00:10:45 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.169]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 21 Dec 1999 23:10:53 -0600
Sender: ed
Message-ID: <38605D78.8E77F0B6@austin.rr.com>
Date: Tue, 21 Dec 1999 23:11:20 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)IS NOT THE SAME AS HEAP' (1070)
References: <199912220452.XAA28094@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)Drop index and recreate. Next release will be more specific in error
message.
I have no idea *which* index to drop/recreate, and I have hundreds of them.
Ouch.
From bouncefilter Wed Dec 22 00:18:24 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id AAA31475
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 00:17:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA28758;
Wed, 22 Dec 1999 00:16:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912220516.AAA28758@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)IS NOT THE SAME AS HEAP' (1070)
In-Reply-To: <38605D78.8E77F0B6@austin.rr.com> from Ed Loehr at "Dec 21, 1999
11:11:20 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Wed, 22 Dec 1999 00:16:56 -0500 (EST)
CC: pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)Drop index and recreate. Next release will be more specific in error
message.I have no idea *which* index to drop/recreate, and I have hundreds of them.
Ouch.
That will also be fixed.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 00:23:24 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA32306
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 00:23:15 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.169]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 21 Dec 1999 23:23:22 -0600
Sender: ed
Message-ID: <38606065.A5AF6949@austin.rr.com>
Date: Tue, 21 Dec 1999 23:23:49 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
References: <199912220516.AAA28758@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)Drop index and recreate. Next release will be more specific in error
message.I have no idea *which* index to drop/recreate, and I have hundreds of them.
Ouch.That will also be fixed.
Do you mean to say the offending index will be auto-corrected on the fly? That
would be almost as good as preventing the root cause in the first place...
Cheers,
Ed Loehr
From bouncefilter Wed Dec 22 00:27:24 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id AAA32824
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 00:26:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA29087;
Wed, 22 Dec 1999 00:26:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912220526.AAA29087@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
In-Reply-To: <38606065.A5AF6949@austin.rr.com> from Ed Loehr at "Dec 21, 1999
11:23:49 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Wed, 22 Dec 1999 00:26:14 -0500 (EST)
CC: pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
That will also be fixed.
Do you mean to say the offending index will be auto-corrected on the fly? That
would be almost as good as preventing the root cause in the first place...
No, it just reports the index name. In 7.1, I think this problem will
go away, if not in 7.0.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 00:48:24 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA38150
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 00:47:27 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.169]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 21 Dec 1999 23:47:40 -0600
Sender: ed
Message-ID: <38606618.153DD23D@austin.rr.com>
Date: Tue, 21 Dec 1999 23:48:08 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
References: <199912220526.AAA29087@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
That will also be fixed.
Do you mean to say the offending index will be auto-corrected on the fly? That
would be almost as good as preventing the root cause in the first place...No, it just reports the index name. In 7.1, I think this problem will
go away, if not in 7.0.
Is the problem well-understood? Is there a place where I can read up on it? This
kind of instability is painful enough to get me thinking about trying to hack my
distribution...
Cheers,
Ed Loehr
From bouncefilter Wed Dec 22 00:50:24 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id AAA38436
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 00:49:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA29484;
Wed, 22 Dec 1999 00:49:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912220549.AAA29484@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
In-Reply-To: <38606618.153DD23D@austin.rr.com> from Ed Loehr at "Dec 21, 1999
11:48:08 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Wed, 22 Dec 1999 00:49:13 -0500 (EST)
CC: pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
That will also be fixed.
Do you mean to say the offending index will be auto-corrected on the fly? That
would be almost as good as preventing the root cause in the first place...No, it just reports the index name. In 7.1, I think this problem will
go away, if not in 7.0.Is the problem well-understood? Is there a place where I can read up on it? This
kind of instability is painful enough to get me thinking about trying to hack my
distribution...
I believe it has to do with extra index tuples showing up in the index
that are not in the heap. When the count's don't match, the problem is
reported. I believe it only happens when the system crashes during an
index update. I think it is harmless. To fix it properly requires a
very sophisticated write-ahead log that is scheduled for 7.1 in about
six months.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 01:04:25 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA43057
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 01:04:10 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.169]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 21 Dec 1999 23:55:20 -0600
Sender: ed
Message-ID: <386069F6.D9ED7BC2@austin.rr.com>
Date: Wed, 22 Dec 1999 00:04:38 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
References: <199912220549.AAA29484@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Is the problem well-understood? Is there a place where I can read up on it? This
kind of instability is painful enough to get me thinking about trying to hack my
distribution...I believe it has to do with extra index tuples showing up in the index
that are not in the heap. When the count's don't match, the problem is
reported. I believe it only happens when the system crashes during an
index update.
That is consistent with my crash experiences this evening.
I think it is harmless. To fix it properly requires a
very sophisticated write-ahead log that is scheduled for 7.1 in about
six months.
This problem stops my psql dead in its tracks for related queries even across new
sessions. Requires a rebuild of indices before any queries work with the related
tables/functions, and since I don't know which one to rebuild (die, horsey, die), I
might as well rebuild them all. In production mode, that means stopping user access due
to the possibility of violating unique constraints enforced by unique indices. That
means downtime, which would makes moi persona non grata. But maybe my assumptions are
incorrect or I didn't understand what you mean by harmless?
Cheers,
Ed Loehr
From bouncefilter Wed Dec 22 01:20:25 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id BAA44608
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 01:19:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA00473;
Wed, 22 Dec 1999 01:18:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912220618.BAA00473@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
In-Reply-To: <386069F6.D9ED7BC2@austin.rr.com> from Ed Loehr at "Dec 22, 1999
00:04:38 am"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Wed, 22 Dec 1999 01:18:59 -0500 (EST)
CC: pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I think it is harmless. To fix it properly requires a
very sophisticated write-ahead log that is scheduled for 7.1 in about
six months.This problem stops my psql dead in its tracks for related queries even across new
sessions. Requires a rebuild of indices before any queries work with the related
tables/functions, and since I don't know which one to rebuild (die, horsey, die), I
might as well rebuild them all. In production mode, that means stopping user access due
to the possibility of violating unique constraints enforced by unique indices. That
means downtime, which would makes moi persona non grata. But maybe my assumptions are
incorrect or I didn't understand what you mean by harmless?
Maybe other people can chime in here. Why are you getting the inital
crashes?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 02:19:26 1999
Received: from bbs.myhome.com (IDENT:root@[202.54.100.26])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA55657;
Wed, 22 Dec 1999 02:18:02 -0500 (EST)
(envelope-from tusar@netshooter.com)
Received: from localhost (tusar@localhost)
by bbs.myhome.com (8.9.3/8.8.7) with ESMTP id MAA02255;
Wed, 22 Dec 1999 12:01:20 +0530
Date: Wed, 22 Dec 1999 12:01:09 +0530 (IST)
From: Tusar <tusar@netshooter.com>
Sender: tusar@bbs.myhome.com
To: Kevin Lo <kevlo@hello.com.tw>
cc: pgsql-announce@postgreSQL.org, pgsql-general@postgreSQL.org,
pgsql-interfaces@postgreSQL.org, pgsql-ports@postgreSQL.org
Subject: Re: [INTERFACES] Announce: PostgreSQL-6.5.3 binaries available for
Windows NT
In-Reply-To: <385F9F03.D9C199A0@hello.com.tw>
Message-ID: <Pine.LNX.4.10.9912221200440.2234-100000@bbs.myhome.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Does the binary contain sql server with it?
On Tue, 21 Dec 1999, Kevin Lo wrote:
Tusar>Hi,
Tusar>
Tusar>Some people asked me to build PostgreSQL binaries for Windows NT.
Tusar>The binaries(PostgreSQL-6.5.3) are now available at:
Tusar>
Tusar>ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Tusar>
Tusar>Please go to my page if you want to build it yourself :)
Tusar>
Tusar>http://www.freebsd.org/~kevlo/postgres/portNT.html
Tusar>
Tusar>The Chinese version is at:
Tusar>
Tusar>http://www.freebsd.org/~kevlo/postgres/portNT_Big5.html
Tusar>
Tusar>Enjoy!
Tusar>Kevin.
Tusar>
Tusar>
Tusar>
Tusar>************
Tusar>
Tusarkanti Nayak
@Communicators
Phone: 91 - 11 - 5535770(O)
Phone: 91 - 11 - 5613992(O)
Phone: 91 - 11 - 5528098(R)
Fax: 91 - 11 - 5613991
URL: http://tusar.netshooter.com
Mail:<tusar@netshooter.com>
*************************************************
** You never know what is enough until you
you know what is more than enough *******
*************************************************
DeVries' Dilemma:
If you hit two keys on the typewriter, the one you don't want
hits the paper.
From bouncefilter Wed Dec 22 02:42:26 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA60594
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 02:42:05 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.169]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 22 Dec 1999 01:41:36 -0600
Sender: ed
Message-ID: <386080CB.224292CD@austin.rr.com>
Date: Wed, 22 Dec 1999 01:42:03 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
References: <199912220618.BAA00473@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I think it is harmless. To fix it properly requires a
very sophisticated write-ahead log that is scheduled for 7.1 in about
six months.This problem stops my psql dead in its tracks for related queries even across new
sessions. Requires a rebuild of indices before any queries work with the related
tables/functions, and since I don't know which one to rebuild (die, horsey, die), I
might as well rebuild them all. In production mode, that means stopping user access due
to the possibility of violating unique constraints enforced by unique indices. That
means downtime, which would makes moi persona non grata. But maybe my assumptions are
incorrect or I didn't understand what you mean by harmless?Maybe other people can chime in here. Why are you getting the inital
crashes?
I don't know. My only suspect right now is that it may be the residual effects of having
parameter mismatches in 'RAISE' statements in PL/pgSQL. In any event, I'll try to collect
some data for troubleshooting...
Cheers,
Ed Loehr
From bouncefilter Wed Dec 22 03:04:26 1999
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA69209;
Wed, 22 Dec 1999 03:04:02 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id QAA77161;
Wed, 22 Dec 1999 16:03:29 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <386085D1.6D821744@hello.com.tw>
Date: Wed, 22 Dec 1999 16:03:29 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Tusar <tusar@netshooter.com>
CC: Kevin Lo <kevlo@hello.com.tw>, pgsql-announce@postgreSQL.org,
pgsql-general@postgreSQL.org, pgsql-interfaces@postgreSQL.org,
pgsql-ports@postgreSQL.org
Subject: Re: [INTERFACES] Announce: PostgreSQL-6.5.3 binaries available
forWindows NT
References: <Pine.LNX.4.10.9912221200440.2234-100000@bbs.myhome.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Tusar wrote:
Does the binary contain sql server with it?
Sure. Please run "psql -h hostName template1".
Tusarkanti Nayak
@Communicators
Phone: 91 - 11 - 5535770(O)
Phone: 91 - 11 - 5613992(O)
Phone: 91 - 11 - 5528098(R)
Fax: 91 - 11 - 5613991
URL: http://tusar.netshooter.com
Mail:<tusar@netshooter.com>
*************************************************
** You never know what is enough until you
you know what is more than enough *******
*************************************************
DeVries' Dilemma:
If you hit two keys on the typewriter, the one you don't want
hits the paper.
Enjoy!
Kevin.
From bouncefilter Wed Dec 22 03:23:26 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA72329
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 03:22:37 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id DAA21684;
Wed, 22 Dec 1999 03:20:36 -0500
Message-ID: <38608A02.A82383C3@mascari.com>
Date: Wed, 22 Dec 1999 03:21:22 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Ed Loehr <ELOEHR@austin.rr.com>, pg-gen <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
References: <199912220516.AAA28758@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)Drop index and recreate. Next release will be more specific in error
message.I have no idea *which* index to drop/recreate, and I have hundreds of them.
Ouch.That will also be fixed.
I thought that the index in question was, in fact,
pg_proc_prosrc_index in the above example. If that's the
case, then is it possible for Ed to rebuild a system index?
The only absolutely surefire way is to dump/reload, isn't
it? Maybe somewhere someone is doing a heap_insert(),
heap_replace(), et al, and an event is happening which is
causing the code to not get to the
CatalogOpenIndices()/CatalogIndexInsert()/CatalogCloseIndices()...
Just curious,
Mike Mascari
From bouncefilter Wed Dec 22 03:31:26 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA76310
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 03:31:14 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id DAA21741;
Wed, 22 Dec 1999 03:29:12 -0500
Message-ID: <38608C07.4A1A6E1D@mascari.com>
Date: Wed, 22 Dec 1999 03:29:59 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gene Selkov, Jr." <selkovjr@mcs.anl.gov>
CC: "J. Roeleveld" <j.roeleveld@softhome.net>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] item descriptions in psql
References: <199912220757.BAA26921@mail.xnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Gene Selkov, Jr." wrote:
Hi,
I just found a reference to descriptions to functions/tables/...etc.
and am now wondering how to add them myself?Joost Roeleveld
not sure if there is a shortcut to this (it's short enough already):
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_class WHERE relname = 'your_table_name';INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_proc WHERE proname = 'your_procedure_name';INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_type WHERE typname = 'your_type_name';INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_operator WHERE oprname = 'your_operator_name';(in case of operators, oprname is '=', '<=', '>>~', etc.)
in older versions (pre-6.3), one had to typecast the names and descriptions:
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description'::text FROM pg_type WHERE typname = 'your_type_name'::name;--Gene
And also note that pg_dump does not yet dump descriptions.
So, until the next release, if your going to document your
database schema, be sure to dump pg_description before
performing any dump..blow-away..reload sequence.
Mike Mascari
From bouncefilter Wed Dec 22 02:57:26 1999
Received: from mail.xnet.com (quake.xnet.com [198.147.221.67])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA62042
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 02:57:23 -0500 (EST)
(envelope-from selkovjr@selkovjr.xnet.com)
Received: from selkovjr.xnet.com ([204.248.57.203]) by mail.xnet.com
(8.9.3+Sun/XNet-3.0R) with ESMTP id BAA26921;
Wed, 22 Dec 1999 01:57:19 -0600 (CST)
Message-Id: <199912220757.BAA26921@mail.xnet.com>
To: "J. Roeleveld" <j.roeleveld@softhome.net>
From: "Gene Selkov, Jr." <selkovjr@mcs.anl.gov>
cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] item descriptions in psql
In-Reply-To: Your message of "Tue, 21 Dec 1999 16:06:14 +0100."
<004301bf4bc4$fd375b80$8402a8c0@sentec.demon.nl>
Date: Wed, 22 Dec 1999 03:00:38 -0600
Sender: selkovjr@selkovjr.xnet.com
Hi,
I just found a reference to descriptions to functions/tables/...etc.
and am now wondering how to add them myself?Joost Roeleveld
not sure if there is a shortcut to this (it's short enough already):
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_class WHERE relname = 'your_table_name';
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_proc WHERE proname = 'your_procedure_name';
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_type WHERE typname = 'your_type_name';
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description' FROM pg_operator WHERE oprname = 'your_operator_name';
(in case of operators, oprname is '=', '<=', '>>~', etc.)
in older versions (pre-6.3), one had to typecast the names and descriptions:
INSERT INTO pg_description (objoid, description)
SELECT oid, 'your description'::text FROM pg_type WHERE typname = 'your_type_name'::name;
--Gene
From bouncefilter Wed Dec 22 05:06:27 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id FAA94794
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 05:06:04 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 12895 invoked by uid 417); 22 Dec 1999 10:11:40 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 22 Dec 1999 10:11:40 -0000
Message-ID: <000501bf4c64$108ed560$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-general@postgreSQL.org>
Subject: getting user-list
Date: Wed, 22 Dec 1999 11:04:56 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I would like to know if, and how, I can find out who's logged into
the database at any given time.
And is it possible to maintain a connection-log of log-ins and log-outs?
with kind regards,
Joost Roeleveld
From bouncefilter Wed Dec 22 08:33:30 1999
Received: from genesis.sundayta.co.uk (mail.sundayta.co.uk [212.24.70.227])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA30847
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 08:33:17 -0500 (EST)
(envelope-from david@sundayta.co.uk)
Received: from kings.sundayta.co.uk
([192.168.100.31] helo=sundayta.co.uk ident=david)
by genesis.sundayta.co.uk with esmtp (Exim 3.03 #1 (Debian))
id 120mU5-0003kv-00; Wed, 22 Dec 1999 14:11:21 +0000
Sender: david
Message-ID: <3860CDCA.68610DC1@sundayta.co.uk>
Date: Wed, 22 Dec 1999 13:10:34 +0000
From: David Warnock <david@sundayta.co.uk>
Organization: Sundayta Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-general@postgreSQL.org" <pgsql-general@postgresql.org>
Subject: Interbase replacement
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
We use Postgresql, but we also use Interbase. However, at present there
is a question mark over the future of Interbase (the top people have all
resigned and we do not yet know what inprise will do with the product,
there are rumours it will be dropped).
Many users of Interbase are currently looking at alternatives. Of these
Postgresql is in many ways one of the best options. It lacks only a few
things
critical (at least for some)
- support for Windows 9x
- transaction log with roll forward from backups
desireable
- stored procedures
- relational integrity via foreign keys
Would it be possible to find ways to pay postgresql developers to add
these things? We would be very happy to pay several $1000 for these and
it might be possible to find others from the Interbase community.
I know that we have discussed Win 9x before and that there are technical
issues. I am hoping that with funds ways around these could be found.
Dave
From bouncefilter Wed Dec 22 08:25:29 1999
Received: from intercept-india.com (intercep@intercept-india.com
[192.41.37.131]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA27175
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 08:25:08 -0500 (EST)
(envelope-from kimi@intercept.co.in)
Received: from intercept.co.in ([202.9.149.187]) by intercept-india.com
(8.8.5) id GAA15660; Wed, 22 Dec 1999 06:24:51 -0700 (MST)
X-Authentication-Warning: intercept-india.com: Host [202.9.149.187] claimed to
be intercept.co.in
Message-Id: <3.0.5.32.19991222184930.00808700@10.10.10.4>
X-Sender: kimi#intercept-india.com@10.10.10.4
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 22 Dec 1999 18:49:30 +0500
To: pgsql-general@postgreSQL.org, scrappy@hub.org
From: Kimi <kimi@intercept.co.in>
Subject: Postgres performance problems.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hi,
We have developed an application using PG 6.5.1, DBI-1.13 and DBD-0.92 with
perl5.
We have a small db with a query with 5 joins and other smaller singleton
selects.
Now this query will be executed about 50 times a second.
While doing a load test to find performance we find that for 100 parallel
perl requests
only around 10 postgres processes get executed.
Why is this so. Is there anyway to configure and increase this. -N and -B
parameters in
postmaster don't seem to help.
Thanks in Advance,
Murali
Differentiated Software Solutions
____________________________________________________________________________
K.P.Krishnan Phones:+91-44-4349882
Client Understanding +91-44-4349469
Intercept Consulting India (P) Ltd Fax: +91-44-4349842
Chennai Mobile 9841064540
India email: krishnan@intercept.co.in
____________________________________________________________________________
From bouncefilter Wed Dec 22 09:56:32 1999
Received: from virnts.virgobc.com ([208.239.49.67])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA55208
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 09:56:04 -0500 (EST)
(envelope-from beller@tradeworx.com)
Received: from tradeworx.com (208.239.49.90 [208.239.49.90]) by
virnts.virgobc.com with SMTP (Microsoft Exchange Internet Mail
Service Version 5.5.2448.0)
id X8SG5VXA; Wed, 22 Dec 1999 09:56:03 -0500
Sender: mike
Message-ID: <3860E67C.68F4E9E4@tradeworx.com>
Date: Wed, 22 Dec 1999 09:55:56 -0500
From: Mike Beller <beller@tradeworx.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ed Loehr <ELOEHR@austin.rr.com>
CC: Thomas Reinke <reinke@e-softinc.com>, Jose Soares <jose@sferacarta.com>,
pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] copy command -- foiled by pg_atoi
References: <385C01E1.6876466D@tradeworx.com>
<385E345B.EB292FAD@sferacarta.com>
<385E671B.C93F49D6@e-softinc.com> <385E95D9.CAD4F50D@austin.rr.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Folks--
Thanks for the ideas. But bisection just seemed too cumbersome.
In the end I decided to write a data filter in perl which checks
all the data for valid types before putting it into the DB!
Mike
Ed Loehr wrote:
I have found that judicious placement of a few queries (selects, intentional
errors, etc.) within a long sequence of inserts will help segment them for
identification of offending lines. Hokie, but it helps me.
...
Thomas Reinke wrote:
I've run into this a few times as well. My strategy to "hunt" down
the offending line has been to do a "bisection" algorithm.
Jose Soares wrote:
This is also my problem. I'm getting '@!?�����+*_|!&/%��' to load a
table with more than 23,000 rows
because I don't know in which line I have to look for the the error.
From bouncefilter Wed Dec 22 10:18:31 1999
Received: from web2106.mail.yahoo.com (web2106.mail.yahoo.com [128.11.68.250])
by hub.org (8.9.3/8.9.3) with SMTP id KAA60986
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 10:17:55 -0500 (EST)
(envelope-from psrajan@yahoo.com)
Received: (qmail 19850 invoked by uid 60001); 22 Dec 1999 15:17:54 -0000
Message-ID: <19991222151754.19849.qmail@web2106.mail.yahoo.com>
Received: from [205.172.146.239] by web2106.mail.yahoo.com;
Wed, 22 Dec 1999 07:17:54 PST
Date: Wed, 22 Dec 1999 07:17:54 -0800 (PST)
From: soundar rajan <psrajan@yahoo.com>
Subject: Trigger
To: Mike Beller <beller@tradeworx.com>, Ed Loehr <ELOEHR@austin.rr.com>,
pgsql-general@postgreSQL.org
Cc: Thomas Reinke <reinke@e-softinc.com>, Jose Soares <jose@sferacarta.com>,
pgsql-general@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
I'm trying to create a trigger. The function I'm
using returns the count(*) from a table. But, during
the creation of the trigger, I get an error stating
the function must return opaque. I tried the same
with the function to be returning a varchar. But,
again I get the same error.
In simple words, it's this. I'm trying to create a
simple trigger which just prints out a message (as
dbms_out.println() in oracle) before or after
insertion or updation on a table. Even if it doesn't
print a message, some changes to be made on the table.
Can some one give me a simple example which does it.
Thanks in advance.
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
From bouncefilter Wed Dec 22 10:34:31 1999
Received: from web2102.mail.yahoo.com (web2102.mail.yahoo.com [128.11.68.246])
by hub.org (8.9.3/8.9.3) with SMTP id KAA65694
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 10:33:46 -0500 (EST)
(envelope-from psrajan@yahoo.com)
Received: (qmail 27641 invoked by uid 60001); 22 Dec 1999 15:33:45 -0000
Message-ID: <19991222153345.27640.qmail@web2102.mail.yahoo.com>
Received: from [205.172.146.239] by web2102.mail.yahoo.com;
Wed, 22 Dec 1999 07:33:45 PST
Date: Wed, 22 Dec 1999 07:33:45 -0800 (PST)
From: soundar rajan <psrajan@yahoo.com>
Subject: creating trigger
To: pgsql-general@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Hi all,
can anyone help me in creating a simple trigger with
an example.
Thanks in advance.
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
From bouncefilter Wed Dec 22 10:32:31 1999
Received: from adidbsrv.edn.echostar.com (w146-239.echostar.com
[205.172.146.239]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA65520
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 10:32:29 -0500 (EST)
(envelope-from Soundar.Pandurangan@exchange1.echostar.com)
Received: from exchange1.echostar.com (IDENT:psrajan@localhost [127.0.0.1])
by adidbsrv.edn.echostar.com (8.9.3/8.9.3) with ESMTP id KAA01589
for <pgsql-general@postgresql.org>; Wed, 22 Dec 1999 10:38:27 -0500
Sender: psrajan@adidbsrv.edn.echostar.com
Message-ID: <3860F073.F0630132@exchange1.echostar.com>
Date: Wed, 22 Dec 1999 10:38:27 -0500
From: Soundar <Soundar.Pandurangan@exchange1.echostar.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: creating trigger
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I'm trying to create a trigger.
I created a function which returns a count of the rows. I used this
procedure while creating the trigger. But, I get an error stating SQL
must return opaque. I tried the same with returning a varchar. I get
the same error again.
In simple words, I need to create a trigger. Can anyone help me in
doing this. BTW, what is similar fxn. as dbms_output.println() in
Oracle.
Thanks in advance.
From bouncefilter Wed Dec 22 11:57:32 1999
Received: from relay4.ftech.net (status.ftech.net [195.200.0.89])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA83982
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 11:56:39 -0500 (EST)
(envelope-from MarkA@idnltd.com)
Received: from ibm9.ftech.net ([212.32.16.79] helo=idnltd.com)
by relay4.ftech.net with smtp (Exim 3.12.ftech-p6 #1)
id 120p3v-0006Tt-00
for pgsql-general@postgreSQL.org; Wed, 22 Dec 1999 16:56:31 +0000
Message-ID: <001201bf4c9c$916863d0$c80110ac@centauri>
From: "Mark Alliban" <MarkA@idnltd.com>
To: <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Getting value of SERIAL column after insert from libpq?
Date: Wed, 22 Dec 1999 16:49:51 -0000
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2110.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Thanks for the help, it works great!
However, there is a problem with performance.
I am moving from MySQL to Postgres, and to test performance I am inserting a
large row (30 fields) into a table from my C program. I am running this
program 50 times, and timing the results. The MySQL version of the program
took 0.75 seconds to execute 50 times, but the Postgres version takes 22-25
seconds. A similar test with a simple select takes 3.5 seconds on Postgres
but 0.8 on MySQL. Postgres undoubtably has more features and is better for
my app than MySQL, but are these performance values normal?
All my program does is read the query from a text file, open the database
connection, perform the query, output currval('seqence_name') or the query
results to a text file, and close the connection. This is how my app needs
to work.
Thanks,
Mark.
Hi,
I have written a C program to insert a row into a table with a
SERIAL column.Is there a way of returning the inserted value for this column
to my program? I.e. if there are rows with the serial column
for 1,2,3,4 and 5, and I insert a row, my program needs to be
told "6" for the new serial. There may be many instances of the
program running simultaneously so I can't do a "select max..."
or "select last_value..." workaround because by the time the
select is done, there may have been other rows inserted so the
last_value would be wrong. Also the program needs to be table-name
and column-name independent so that it can work for ANY insert
query into a table with a SERIAL column.Answer is that currval('seqence_name') will return your last sequence
number, even if another session has assigned a sequence number since
your nextval() call.
From bouncefilter Wed Dec 22 12:10:32 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA89342
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 12:10:11 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id MAA23236;
Wed, 22 Dec 1999 12:07:58 -0500
Message-ID: <386105A0.402D5A30@mascari.com>
Date: Wed, 22 Dec 1999 12:08:48 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Alliban <MarkA@idnltd.com>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Getting value of SERIAL column after insert from libpq?
References: <001201bf4c9c$916863d0$c80110ac@centauri>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mark Alliban wrote:
Thanks for the help, it works great!
However, there is a problem with performance.
I am moving from MySQL to Postgres, and to test performance I am inserting a
large row (30 fields) into a table from my C program. I am running this
program 50 times, and timing the results. The MySQL version of the program
took 0.75 seconds to execute 50 times, but the Postgres version takes 22-25
seconds. A similar test with a simple select takes 3.5 seconds on Postgres
but 0.8 on MySQL. Postgres undoubtably has more features and is better for
my app than MySQL, but are these performance values normal?All my program does is read the query from a text file, open the database
connection, perform the query, output currval('seqence_name') or the query
results to a text file, and close the connection. This is how my app needs
to work.Thanks,
Mark.
Are you running with fsync() disabled? That is the single
largest bottleneck for PostgreSQL performance and is
disabled by default in MySQL, except on NT (since NT has a
tendency to crash). You can disable fsync() with the
postmaster -o -F option, to pass the option to the backend.
See the postmaster and postgres man pages for more info.
Hope that helps,
Mike Mascari
From bouncefilter Wed Dec 22 12:37:32 1999
Received: from bigdog.templegames.com (bigdog.templegames.com [209.6.215.115])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA96509
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 12:36:38 -0500 (EST)
(envelope-from kevin@templegames.com)
Received: from templegames.com ([209.6.215.67]) by bigdog.templegames.com
(Netscape Messaging Server 3.5) with ESMTP id AAA6667
for <pgsql-general@postgreSQL.org>; Wed, 22 Dec 1999 12:37:29 -0500
Message-ID: <38610AD7.2ED8CB36@templegames.com>
Date: Wed, 22 Dec 1999 12:31:03 -0500
From: "Kevin Holbrook" <kevin@templegames.com>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: postgres <pgsql-general@postgreSQL.org>
Subject: [GENERAL] Stored procedures
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I am using version 6.5.3, and have a quick question on CREATE
FUNCTION.
Now, it seems that "LIMIT clause from SQL functions not yet
implemented".
Any ideas on how I could somehow limit the number of results coming
back?
I want to grab the top 100 records out of a table with of 60K
records or so.
Any help would be greatly appreciated.
Thanks!
-Kevin Holbrook
From bouncefilter Wed Dec 22 12:50:32 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA98164
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 12:49:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA16689;
Wed, 22 Dec 1999 12:39:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912221739.MAA16689@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
In-Reply-To: <38608A02.A82383C3@mascari.com> from Mike Mascari at "Dec 22,
1999
03:21:22 am"
To: Mike Mascari <mascarm@mascari.com>
Date: Wed, 22 Dec 1999 12:39:34 -0500 (EST)
CC: Ed Loehr <ELOEHR@austin.rr.com>, pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)Drop index and recreate. Next release will be more specific in error
message.I have no idea *which* index to drop/recreate, and I have hundreds of them.
Ouch.That will also be fixed.
I thought that the index in question was, in fact,
pg_proc_prosrc_index in the above example. If that's the
case, then is it possible for Ed to rebuild a system index?
The only absolutely surefire way is to dump/reload, isn't
it? Maybe somewhere someone is doing a heap_insert(),
heap_replace(), et al, and an event is happening which is
causing the code to not get to the
CatalogOpenIndices()/CatalogIndexInsert()/CatalogCloseIndices()...
Signe me up as a dope. Yes, it is clearly that index. I was thinking
of another place that has this problem, the famous "My bits moved off
the end of the world" error message. This one is clearly the
pg_proc_prosrc_index index.
The only way to fix that is to initdb, I think. I would recommend
pg_upgrade, after removing the disable from the pg_upgrade script that
was added in 6.5. That will fix it. Not sure how it got that way,
though.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 13:32:33 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id NAA08827
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 13:32:22 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA20421;
Wed, 22 Dec 1999 13:30:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912221830.NAA20421@candle.pha.pa.us>
Subject: Re: [GENERAL] Interbase replacement
In-Reply-To: <3860CDCA.68610DC1@sundayta.co.uk> from David Warnock at "Dec 22,
1999 01:10:34 pm"
To: David Warnock <david@sundayta.co.uk>
Date: Wed, 22 Dec 1999 13:30:57 -0500 (EST)
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi,
We use Postgresql, but we also use Interbase. However, at present there
is a question mark over the future of Interbase (the top people have all
resigned and we do not yet know what inprise will do with the product,
there are rumours it will be dropped).Many users of Interbase are currently looking at alternatives. Of these
Postgresql is in many ways one of the best options. It lacks only a few
thingscritical (at least for some)
- support for Windows 9x
This is a huge leap for us. Only if cgywin can be ported to it. That's
the only way we got to NT.
- transaction log with roll forward from backups
That will be in 7.1, due in 6 months.
desireable
- stored procedures
Have it.
- relational integrity via foreign keys
That will be in 7.0, due in a few months.
Would it be possible to find ways to pay postgresql developers to add
these things? We would be very happy to pay several $1000 for these and
it might be possible to find others from the Interbase community.
Money always helps, but we already have most of what you need coming.
I know that we have discussed Win 9x before and that there are technical
issues. I am hoping that with funds ways around these could be found.
Win 9x seems like a HUGE leap for us. Where is cgywin on that?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 13:31:33 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA08736
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 13:31:11 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
NAA29995; Wed, 22 Dec 1999 13:38:18 -0500
Date: Wed, 22 Dec 1999 18:38:18 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: David Warnock <david@sundayta.co.uk>
cc: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Interbase replacement
In-Reply-To: <3860CDCA.68610DC1@sundayta.co.uk>
Message-ID: <Pine.LNX.3.96.991222183218.25654Y-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 22 Dec 1999, David Warnock wrote:
[SNIP]
critical (at least for some)
- support for Windows 9x
as in a native port of pgsql to ms-windows or as in odbc drivers ( which
postgresql already has ) ?
- transaction log with roll forward from backups
desireable
- stored procedures
there was a huge discussion on this earlier. i think its coming rsn.
- relational integrity via foreign keys
due in 7.x i think ( im not a pgsql developer ). for now one can use
'refint' ( $PGSQL_SRC_ROOT/contrib/spi/refint.* ) to get some degree of
foreign key support. check the list archive for extended discussions on
it.
Would it be possible to find ways to pay postgresql developers to add
these things? We would be very happy to pay several $1000 for these and
it might be possible to find others from the Interbase community.
www.pgsql.com has the necessary info.
[SNIP]
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Wed Dec 22 13:53:35 1999
Received: from kiln.isn.net (root@kiln.isn.net [198.167.161.1])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA11800
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 13:52:36 -0500 (EST)
(envelope-from ctassell@isn.net)
Received: from niki (cosmo09.isn.net [198.167.161.143])
by kiln.isn.net (8.9.3/8.9.3) with ESMTP id OAA02800;
Wed, 22 Dec 1999 14:53:25 -0400
Message-Id: <4.2.0.58.19991222144649.00a27b00@mailer.isn.net>
X-Sender: ctassell@mailer.isn.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 22 Dec 1999 14:50:27 -0400
To: "Mark Alliban" <MarkA@idnltd.com>, <pgsql-general@postgreSQL.org>
From: Charles Tassell <ctassell@isn.net>
Subject: Re: [GENERAL] Getting value of SERIAL column after insert from libpq?
In-Reply-To: <001201bf4c9c$916863d0$c80110ac@centauri>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Someone else had a good idea with the fsync thing, but for the inserts, you
also might want to double-check that you are using a transaction, as that
speeds up transactions considerably. To start a transaction use the SQL
command "BEGIN WORK;" and then use "COMMIT WORK;" after you have finished
your inserts. I don't think you can do a select inside a transaction,
(although I've never tried) so you may have to open up a second connection
to the database and find the value your sequence was assigned by SELECTing
the oid returned instead of by using curval() I believe instructions on
this are in the FAQ. If not, drop me a lien and I'll look for the PHP3
code I use to do it, it should be fairly close to how you do it in C.
At 12:49 PM 12/22/99, Mark Alliban wrote:
Thanks for the help, it works great!
However, there is a problem with performance.
I am moving from MySQL to Postgres, and to test performance I am inserting a
large row (30 fields) into a table from my C program. I am running this
program 50 times, and timing the results. The MySQL version of the program
took 0.75 seconds to execute 50 times, but the Postgres version takes 22-25
seconds. A similar test with a simple select takes 3.5 seconds on Postgres
but 0.8 on MySQL. Postgres undoubtably has more features and is better for
my app than MySQL, but are these performance values normal?All my program does is read the query from a text file, open the database
connection, perform the query, output currval('seqence_name') or the query
results to a text file, and close the connection. This is how my app needs
to work.Thanks,
Mark.Hi,
I have written a C program to insert a row into a table with a
SERIAL column.Is there a way of returning the inserted value for this column
to my program? I.e. if there are rows with the serial column
for 1,2,3,4 and 5, and I insert a row, my program needs to be
told "6" for the new serial. There may be many instances of the
program running simultaneously so I can't do a "select max..."
or "select last_value..." workaround because by the time the
select is done, there may have been other rows inserted so the
last_value would be wrong. Also the program needs to be table-name
and column-name independent so that it can work for ANY insert
query into a table with a SERIAL column.Answer is that currval('seqence_name') will return your last sequence
number, even if another session has assigned a sequence number since
your nextval() call.************
From bouncefilter Wed Dec 22 13:53:33 1999
Received: from ale.vtiscan.com (ale.vtiscan.com [192.76.184.74])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA11827
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 13:52:47 -0500 (EST) (envelope-from rwb@vtiscan.com)
Received: from ice.vtiscan.com (ice.vtiscan.com [192.76.184.81])
by ale.vtiscan.com (8.8.7/8.8.7) with ESMTP id NAA14110;
Wed, 22 Dec 1999 13:52:24 -0500
Date: Wed, 22 Dec 1999 13:52:24 -0500
From: "Robert W. Berger" <rwb@vtiscan.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Interbase replacement
Message-ID: <2556814.3154859544@ice.vtiscan.com>
In-Reply-To: <199912221830.NAA20421@candle.pha.pa.us>
Originator-Info: login-id=rwb; server=ale.vtiscan.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n U-300796]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Is SELECT COUNT(DISTINCT ...
going to be supported in an upcoming version?
From bouncefilter Wed Dec 22 13:48:33 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA11158
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 13:48:29 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
NAA30681; Wed, 22 Dec 1999 13:55:42 -0500
Date: Wed, 22 Dec 1999 18:55:42 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: Mark Alliban <MarkA@idnltd.com>
cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Getting value of SERIAL column after insert from libpq?
In-Reply-To: <001201bf4c9c$916863d0$c80110ac@centauri>
Message-ID: <Pine.LNX.3.96.991222184042.25654Z-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 22 Dec 1999, Mark Alliban wrote:
Thanks for the help, it works great!
However, there is a problem with performance.
I am moving from MySQL to Postgres, and to test performance I am inserting a
large row (30 fields) into a table from my C program. I am running this
program 50 times, and timing the results. The MySQL version of the program
took 0.75 seconds to execute 50 times, but the Postgres version takes 22-25
seconds.
yeouch, that doesnt sound normal... especially seeing that ive been
inserting ~100 rows, doing a convert, cp'ing a file, _and_ checking for
referential integrity in ~40-45 seconds... and the app has the normal perl
overhead.
make sure you've turned fsync off ( -F opt to postmaster iirc ).
A similar test with a simple select takes 3.5 seconds on Postgres
but 0.8 on MySQL. Postgres undoubtably has more features and is better for
my app than MySQL, but are these performance values normal?
depends on the select. if its not hitting indexes ( doing a full table
scan ), things get slow. try doing an explain of the query and make sure
you have indexes on most (if not all) of the columns in the WHERE clause.
[SNIP]
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Wed Dec 22 14:37:34 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67] (may
be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id OAA24035
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 14:37:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA00316;
Wed, 22 Dec 1999 14:36:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912221936.OAA00316@candle.pha.pa.us>
Subject: Re: [GENERAL] Interbase replacement
In-Reply-To: <2556814.3154859544@ice.vtiscan.com> from "Robert W. Berger" at
"Dec 22, 1999 01:52:24 pm"
To: "Robert W. Berger" <rwb@vtiscan.com>
Date: Wed, 22 Dec 1999 14:36:37 -0500 (EST)
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Is SELECT COUNT(DISTINCT ...
going to be supported in an upcoming version?
Yes, 7.0.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 22 14:46:34 1999
Received: from geeks.linux.com (root@216.200.201.220.linux.com
[216.200.201.220] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id OAA25099
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 14:45:51 -0500 (EST)
(envelope-from chewie@wookimus.net)
Received: from geeks.linux.com (chewie@geeks.linux.com [216.200.201.220])
by geeks.linux.com (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id LAA23561;
Wed, 22 Dec 1999 11:45:46 -0800
Date: Wed, 22 Dec 1999 11:45:46 -0800 (PST)
From: ^chewie <chewie@wookimus.net>
X-Sender: chewie@geeks.linux.com
To: David Warnock <david@sundayta.co.uk>
cc: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Interbase replacement
In-Reply-To: <3860CDCA.68610DC1@sundayta.co.uk>
Message-ID: <Pine.LNX.4.10.9912221141540.23528-100000@geeks.linux.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 22 Dec 1999, David Warnock wrote:
Would it be possible to find ways to pay postgresql developers to add
these things? We would be very happy to pay several $1000 for these and
it might be possible to find others from the Interbase community.
He he. That's one way to get your needs upgraded in priority on the
development path. ;-) I'm sure the developers of PostgreSQL would be
most happy to hear your interest in furthering the features of PostgreSQL.
I'd probably look for some email addresses off the
http://www.postgresql.org/ web site. That is if they haven't seen you
already on this email list, which I doubt. ;-)
I'd help out, but I'm about to go head-first into an Open Resource
Planning project I started on http://www.sourceforge.net/, OpenRP for
short. Creating a suitable replacement for MRP/ERP software like SAP is
going to be a huge chore, but it needs to be done. ;-)
----------------------------------------------------------------
Chad Walstrom mailto:chewie@wookimus.net
a.k.a ^chewie, gunnarr http://wookimus.net/~chewie
Gnupg = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD
----------------------------------------------------------------
From bouncefilter Wed Dec 22 15:21:34 1999
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA32996
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 15:20:53 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id PAA82894
for pgsql-general@postgresql.org; Wed, 22 Dec 1999 15:11:20 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: Eldad Midan <af8@stern.nyu.edu>
Organization: -
Subject: newbie needs help setting up pgsql on linux
X-Newsreader: KRN http://ultra7.unl.edu.ar
Content-Type: text/plain;
charset="us-ascii"
X-Newsgroups: comp.databases.postgresql.questions
Followup-To: comp.databases.postgresql.questions; af8@stern.nyu.edu
MIME-Version: 1.0
Message-ID: <945893469.1219290919@news.nyu.edu>
Content-Transfer-Encoding: 8bit
Lines: 20
Date: Wed, 22 Dec 1999 14:59:40 -0500
X-Trace: typhoon.nyu.edu 945893606 216.165.1.224 (Wed,
22 Dec 1999 15:13:26 EDT)
To: pgsql-questions@postgresql.org
Hi everybody,
I am running RedHat Linux 6.1 on a Pentium, and am trying to migrate existing
databases from Access-Win95 to PostgreSQL on Linux.
I have installed the RPMs retrieved from RedHat's ftp site, read the relevant
sections in the admin guide, the user's guide and some more, but I can't get
postmaster to start. It seems that in order to start I need to install a
database with a template (template1) which should be in some ... .../data
directory. However, those files are nowhere to be found. I created a ...
.../data directory, ran initlocation -D the-directory-where-the-data-will-reside
and postmaster claims not to find a file called ...
.../data/base/template1/pg_class. I looked around in various directories, and
found some candidates in /usr/lib/pgsql/* but without instructions on how to
make that into my template. Finally, when I 'touch' a file to be named
pg_class, postmaster complains that the file PG_VERSION does not exist.
Can anyone help me?
ari
From bouncefilter Wed Dec 22 14:01:33 1999
Received: from mail.xnet.com (quake.xnet.com [198.147.221.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA16227
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 14:01:19 -0500 (EST)
(envelope-from selkovjr@selkovjr.xnet.com)
Received: from selkovjr.xnet.com ([204.248.57.203]) by mail.xnet.com
(8.9.3+Sun/XNet-3.0R) with ESMTP id MAA25056;
Wed, 22 Dec 1999 12:57:25 -0600 (CST)
Message-Id: <199912221857.MAA25056@mail.xnet.com>
To: Herouth Maoz <herouth@oumail.openu.ac.il>
From: Gene Selkov <selkovjr@mcs.anl.gov>
cc: "pgsql-general" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] char(xx) problem
In-Reply-To: Your message of "Tue, 21 Dec 1999 14:08:50 +0200."
<l03130301b4851b846903@[147.233.159.109]>
Date: Wed, 22 Dec 1999 14:00:48 -0600
Sender: selkovjr@selkovjr.xnet.com
I'm just wondering: are there any alternatives to blank padding? Why
is it done in the first place?That's how fixed-length char type works, since the early days of SQL. You
come to expect it, which means that if you use legacy code that has a
fixed-width char type, or you decided to use it for its time-saving
possibilities, it should behave according to some way which has been
established long ago.
I thik I understand why a fixed-size type should be aligned to the
multiples of its size in storage -- that's what accounts for some
speed improvement. I am still not getting the point when it comes to
padding. Because it looks like it draws on speed -- both when you do
the padding and when you trim the results. The question is
whether a null-terminated string would do as well.
My suspicion is that somebody simply didn't like to see the garbage in the
database files, and then it stuck.
What I don't get is why, given two bpchar argument, Postgres doesn't just
pad the shorter one to the length of the other and then compares, selects
and whatnot.
As the original post by Nikolay Mijaylov indicated, there is (was?) a
mechanism for correct comparison between various char(*) and text
types, but whether it works or not depends on the weather outside. I
can witness its existence in the past, as I still have some code that
relies on cross-type comparisons which do not seem to work
anymore. Unfortunately, I did not check since a few versions back, but
if I understood Nikolay Mijaylov right, he claims to have two
installations of the same version that behave differently.
Now these code snippets clearly shows how it was intended to work:
/*****************************************************************************
* Comparison Functions used for bpchar
*****************************************************************************/
static int
bcTruelen(char *arg)
{
char *s = VARDATA(arg);
int i;
int len;
len = VARSIZE(arg) - VARHDRSZ;
for (i = len - 1; i >= 0; i--)
{
if (s[i] != ' ')
break;
}
return i + 1;
}
. . . .
bool
bpchareq(char *arg1, char *arg2)
{
int len1,
len2;
if (arg1 == NULL || arg2 == NULL)
return (bool) 0;
len1 = bcTruelen(arg1);
len2 = bcTruelen(arg2);
if (len1 != len2)
return 0;
return strncmp(VARDATA(arg1), VARDATA(arg2), len1) == 0;
}
What's up with bcTruelen() then? Where does the noise come from?
--Gene
From bouncefilter Wed Dec 22 15:12:35 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA31366
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 15:11:42 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.93.43.109]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 22 Dec 1999 14:03:03 -0600
Sender: ed
Message-ID: <386130A5.60BB2522@austin.rr.com>
Date: Wed, 22 Dec 1999 14:12:21 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Soundar <Soundar.Pandurangan@exchange1.echostar.com>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] creating trigger
References: <3860F073.F0630132@exchange1.echostar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Soundar wrote:
Hi all,
I'm trying to create a trigger.
I created a function which returns a count of the rows. I used this
procedure while creating the trigger. But, I get an error stating SQL
must return opaque. I tried the same with returning a varchar. I get
the same error again.
I vaguely recall that functions directly invoked by triggers must return
opaque types.
But you can call a function from within that function to get a count.
Not sure what you want to do with the count once you have, though...
Cheers,
Ed Loehr
From bouncefilter Wed Dec 22 16:21:35 1999
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA46145
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 16:20:54 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id QAA86789
for pgsql-general@postgresql.org; Wed, 22 Dec 1999 16:00:45 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <38613E63.47B6BB22@ix.netcom.com>
From: Steve <haltline@ix.netcom.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.questions
Subject: Re: newbie needs help setting up pgsql on linux
References: <945893469.1219290919@news.nyu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 26
Date: Wed, 22 Dec 1999 21:00:44 GMT
X-Complaints-To: abuse@home.net
X-Trace: news.rdc2.mi.home.com 945896444 24.0.61.108 (Wed,
22 Dec 1999 13:00:44 PST)
Organization: @Home Network
To: pgsql-questions@postgresql.org
There is a program called 'initdb' you need to run under your postgres usercode.
See 'man initdb' for details.
Eldad Midan wrote:
Hi everybody,
I am running RedHat Linux 6.1 on a Pentium, and am trying to migrate existing
databases from Access-Win95 to PostgreSQL on Linux.I have installed the RPMs retrieved from RedHat's ftp site, read the relevant
sections in the admin guide, the user's guide and some more, but I can't get
postmaster to start. It seems that in order to start I need to install a
database with a template (template1) which should be in some ... .../data
directory. However, those files are nowhere to be found. I created a ...
../data directory, ran initlocation -D the-directory-where-the-data-will-reside
and postmaster claims not to find a file called ...
../data/base/template1/pg_class. I looked around in various directories, and
found some candidates in /usr/lib/pgsql/* but without instructions on how to
make that into my template. Finally, when I 'touch' a file to be named
pg_class, postmaster complains that the file PG_VERSION does not exist.Can anyone help me?
ari
From bouncefilter Wed Dec 22 16:52:35 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA52097
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 16:52:22 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.93.40.202]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 22 Dec 1999 15:43:51 -0600
Sender: ed
Message-ID: <38614845.A012B24@austin.rr.com>
Date: Wed, 22 Dec 1999 15:53:09 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pg-gen <pgsql-general@postgresql.org>
Subject: [GENERAL] fsync performance impact
References: <Pine.LNX.3.96.991222184042.25654Z-100000@rabies.toodarkpark.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thought some would like to see a little quatitative data on the impact of running
with the -F flag...
Test case: Using psql via stdin to load 5,238 inserts of the following form:
INSERT INTO exchange_rate
( from_currency_id, to_currency_id, rate, start_time)
VALUES
(150,164, 6.01500000, '09/04/1999');
Platform: RH6.1, 2.2.12-20smp, dual P3 600Mhz, 1 Gb RAM, 3 10K rpm scsi drives
in software raid.
Without -F, it loaded in 228 seconds (~23 inserts/sec).
With -F, it loaded in 10 seconds (~524 inserts/sec).
2200% boost...
Remember this performance boost comes at the expense of increased risk of data
loss in the event of a system crash.
Cheers,
Ed Loehr
From bouncefilter Wed Dec 22 20:57:23 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA96752
for <pgsql-general@postgresql.org>;
Wed, 22 Dec 1999 20:57:10 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.93.40.202]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 22 Dec 1999 19:56:29 -0600
Sender: ed
Message-ID: <38618166.F6CE2E57@austin.rr.com>
Date: Wed, 22 Dec 1999 19:56:54 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Mike Mascari <mascarm@mascari.com>, pg-gen <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
References: <199912221739.MAA16689@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)The only way to fix that is to initdb, I think. I would recommend
pg_upgrade, after removing the disable from the pg_upgrade script that
was added in 6.5. That will fix it. Not sure how it got that way,
though.
El dope primero aqui...
Thanks for the tip. Here's what I had to do to make this work, for what it's worth
to future travelers...
Cheers,
Ed Loehr
psql -d mydb -c "select * from title;" > before
# Save for after cmp test...
cd /usr/local/pgsql # my install root...
vacuumdb mydb # clean up before moving...
cp -pr data data.backup # make a backup...
pg_dumpall -s > schema.sql # dump schema w/out data...
killall postmaster # stop the server...
sleep 3
mv data data.old # set it aside...
cd /usr/src/pgsql/src # to the src tree...
gmake install # reinstall binaries...
cd /usr/local/pgsql # back to my install root...
initdb # recreate template1, sys stuff...
postmaster -i -o "-F -S 4096 -s" >& log & # restart server...
sleep 3
pg_upgrade -f schema.sql data >& upgrade.log # reload schema...
cp -p data.old/base/mydb/* data/base/mydb/ # replace data...
psql -d mydb -c "select * from title;" > after
# verify we still have data...
diff before after # quick sanity check...
From bouncefilter Wed Dec 22 21:17:23 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA01637
for <pgsql-general@postgreSQL.org>;
Wed, 22 Dec 1999 21:16:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA09313;
Wed, 22 Dec 1999 21:13:22 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912230213.VAA09313@candle.pha.pa.us>
Subject: Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES
(1071)ISNOT THE SAME AS HEAP' (1070)
In-Reply-To: <38618166.F6CE2E57@austin.rr.com> from Ed Loehr at "Dec 22, 1999
07:56:54 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Wed, 22 Dec 1999 21:13:22 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, pg-gen <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Anyone seen this message or know what it means?
NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS
NOT THE SAME AS HEAP' (1070)The only way to fix that is to initdb, I think. I would recommend
pg_upgrade, after removing the disable from the pg_upgrade script that
was added in 6.5. That will fix it. Not sure how it got that way,
though.El dope primero aqui...
Thanks for the tip. Here's what I had to do to make this work, for what it's worth
to future travelers...
Glad to see pg_upgrade fixed you.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 23 00:02:25 1999
Received: from homer.is.com.fj (homer.is.com.fj [202.62.124.238])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA31077
for <pgsql-general@hub.org>; Thu, 23 Dec 1999 00:01:49 -0500 (EST)
(envelope-from jrh@is.com.fj)
Received: from john (test2.is.com.fj [202.62.124.234])
by homer.is.com.fj (8.9.3/8.9.3) with SMTP id SAA13262;
Thu, 23 Dec 1999 18:01:23 +1300 (FJDST)
Message-ID: <008201bf4d0a$b72f3800$ea7c3eca@john.is.com.fj>
Reply-To: "John Henderson" <jrh@is.com.fj>
From: "John Henderson" <jrh@is.com.fj>
To: <bsdi-users@mailinglists.org>, <pgsql-general@hub.org>
Subject: shared memory - progress
Date: Thu, 23 Dec 1999 17:58:16 +1200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
OK,
I can assign and manipulate shared memory in BSD/OS3.0 notes to follow.
Now the problem is that as I vary the number of shared buffers and amount of
shared memory I vary between two kinds of errors. If shared mem is too low
that generates an error - 'out of buffers', if too high, I get palloc
errors - memory exhausted.
So, now I need to lay my hands on a basic tutorial that describes in general
terms how BSD divides its total memory resource among shared/kernel etc. and
a second tutorial on how postgres uses different types of memory ie. why
does one query create a palloc error and another run out of shmem.
Thanks so much for hanging with me through this.
John
From bouncefilter Thu Dec 23 01:11:26 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA44703
for <pgsql-general@hub.org>; Thu, 23 Dec 1999 01:10:30 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA15284;
Thu, 23 Dec 1999 01:05:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912230605.BAA15284@candle.pha.pa.us>
Subject: Re: [GENERAL] shared memory - progress
In-Reply-To: <008201bf4d0a$b72f3800$ea7c3eca@john.is.com.fj> from John
Henderson at "Dec 23, 1999 05:58:16 pm"
To: John Henderson <jrh@is.com.fj>
Date: Thu, 23 Dec 1999 01:05:26 -0500 (EST)
CC: bsdi-users@mailinglists.org, pgsql-general@hub.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
OK,
I can assign and manipulate shared memory in BSD/OS3.0 notes to follow.
Now the problem is that as I vary the number of shared buffers and amount of
shared memory I vary between two kinds of errors. If shared mem is too low
that generates an error - 'out of buffers', if too high, I get palloc
errors - memory exhausted.
Too low means you are asking for more shared memory than was configured
for your kernel. palloc errors are because there is not enough memory
left for your query to complete.
Most palloc errors are caused by some user error, or too many OR's in a
query, which will be fixed in the next release.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 23 02:06:26 1999
Received: from hermes.iol.cz (hermes.iol.cz [194.228.2.36])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA56110
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 02:05:44 -0500 (EST)
(envelope-from livingston@iol.cz)
Received: from goober.baffle.cz ([194.228.143.27]) by hermes.iol.cz
(Post.Office MTA v3.5.3 release 223
ID# 631-64078U55000L55000S0V35) with ESMTP id cz
for <pgsql-general@postgresql.org>; Thu, 23 Dec 1999 08:04:58 +0100
Received: (from livingston@localhost)
by goober.baffle.cz (8.9.3/8.9.3/Debian/GNU) id HAA12219
for pgsql-general@postgresql.org; Thu, 23 Dec 1999 07:41:07 +0100
X-Authentication-Warning: goober.baffle.cz: livingston set sender to
livingston@iol.cz using -f
Date: Thu, 23 Dec 1999 07:41:07 +0100
From: "Nathan L. Cutler" <livingston@iol.cz>
To: pgsql-general@postgresql.org
Subject: Possible FAQs: single-quote and rename database
Message-ID: <19991223074107.A12201@iol.cz>
References: <l03130301b4851b846903@[147.233.159.109]>
<199912221857.MAA25056@mail.xnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre2i
In-Reply-To: <199912221857.MAA25056@mail.xnet.com>
Organization: Livingston, s.r.o.
X-Operating-System: Debian GNU Linux
Hello:
I have two questions that might be FAQs (apologies in advance):
(1) Why does the parser choke on backslashed single-quote characters? Or,
in other words, why doesn't this work:
testing=> \d bubba
Table = bubba
+--------------------------+----------------------------------+-------+
| Field | Type | Length|
+--------------------------+----------------------------------+-------+
| litbub | varchar() | 60 |
+--------------------------+----------------------------------+-------+
testing=> insert '\'' into bubba;
ERROR: parser: parse error at or near "'"(2) How does one rename a database? Other than dump/destroydb/restore,
obviously.
TIA
--
Nathan L. Cutler < livingston @ iol.cz > telephone: +420-2-51611648
Livingston Professional Translations fax: +420-2-6514377
** When "pretty good" is not enough ** Prague, Czech Republic
From bouncefilter Thu Dec 23 03:28:14 1999
Received: from photon.skillbrokers.bg (root@photon.skillbrokers.bg
[195.24.42.194]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA73278
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 03:27:21 -0500 (EST) (envelope-from nmmm@nmmm.nu)
Received: from niki (proton.skillbrokers.bg [195.24.42.206])
by photon.skillbrokers.bg (8.9.0/8.9.0) with SMTP id LAA23552;
Thu, 23 Dec 1999 11:20:45 +0200
Message-ID: <002d01bf4d1f$5affc620$ce2a18c3@skillbrokers.bg>
From: "Nikolay Mijaylov" <nmmm@nmmm.nu>
To: "pgsql-general" <pgsql-general@postgreSQL.org>,
"Gene Selkov" <selkovjr@mcs.anl.gov>
References: <199912221857.MAA25056@mail.xnet.com>
Subject: Re: [GENERAL] char(xx) problem
Date: Thu, 23 Dec 1999 10:22:33 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Yes, u understood me right,
I plane to install new version in january, and if the problem still exist,
I;ll report it again
--------------------------------------------------------------
The reboots are for hardware upgrades!
"http://www.nmmm.nu; <nmmm@nmmm.nu>
----- Original Message -----
From: Gene Selkov <selkovjr@mcs.anl.gov>
To: Herouth Maoz <herouth@oumail.openu.ac.il>
Cc: pgsql-general <pgsql-general@postgresql.org>
Sent: �����, �������� 22, 1999 10:00
Subject: Re: [GENERAL] char(xx) problem
I'm just wondering: are there any alternatives to blank padding? Why
is it done in the first place?That's how fixed-length char type works, since the early days of SQL.
You
come to expect it, which means that if you use legacy code that has a
fixed-width char type, or you decided to use it for its time-saving
possibilities, it should behave according to some way which has been
established long ago.I thik I understand why a fixed-size type should be aligned to the
multiples of its size in storage -- that's what accounts for some
speed improvement. I am still not getting the point when it comes to
padding. Because it looks like it draws on speed -- both when you do
the padding and when you trim the results. The question is
whether a null-terminated string would do as well.My suspicion is that somebody simply didn't like to see the garbage in the
database files, and then it stuck.What I don't get is why, given two bpchar argument, Postgres doesn't
just
pad the shorter one to the length of the other and then compares,
selects
and whatnot.
As the original post by Nikolay Mijaylov indicated, there is (was?) a
mechanism for correct comparison between various char(*) and text
types, but whether it works or not depends on the weather outside. I
can witness its existence in the past, as I still have some code that
relies on cross-type comparisons which do not seem to work
anymore. Unfortunately, I did not check since a few versions back, but
if I understood Nikolay Mijaylov right, he claims to have two
installations of the same version that behave differently.Now these code snippets clearly shows how it was intended to work:
/*
****************************************************************************
* Comparison Functions used for bpchar
*
****
************************************************************************/
static int
bcTruelen(char *arg)
{
char *s = VARDATA(arg);
int i;
int len;len = VARSIZE(arg) - VARHDRSZ;
for (i = len - 1; i >= 0; i--)
{
if (s[i] != ' ')
break;
}
return i + 1;
}. . . .
bool
bpchareq(char *arg1, char *arg2)
{
int len1,
len2;if (arg1 == NULL || arg2 == NULL)
return (bool) 0;
len1 = bcTruelen(arg1);
len2 = bcTruelen(arg2);if (len1 != len2)
return 0;return strncmp(VARDATA(arg1), VARDATA(arg2), len1) == 0;
}What's up with bcTruelen() then? Where does the noise come from?
--Gene
************
From bouncefilter Thu Dec 23 04:07:28 1999
Received: from genesis.sundayta.co.uk (mail.sundayta.co.uk [212.24.70.227])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA83621
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 04:07:00 -0500 (EST)
(envelope-from david@sundayta.co.uk)
Received: from kings.sundayta.co.uk
([192.168.100.31] helo=sundayta.co.uk ident=david)
by genesis.sundayta.co.uk with esmtp (Exim 3.03 #1 (Debian))
id 1214no-0004mO-00; Thu, 23 Dec 1999 09:44:56 +0000
Sender: david
Message-ID: <3861E0D7.75629833@sundayta.co.uk>
Date: Thu, 23 Dec 1999 08:44:07 +0000
From: David Warnock <david@sundayta.co.uk>
Organization: Sundayta Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Howie <caffeine@toodarkpark.org>
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Interbase replacement
References: <Pine.LNX.3.96.991222183218.25654Y-100000@rabies.toodarkpark.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Howie wrote:
On Wed, 22 Dec 1999, David Warnock wrote:
[SNIP]
critical (at least for some)
- support for Windows 9xas in a native port of pgsql to ms-windows or as in odbc drivers ( which
It is the pgsql server part that we need for some very small sites
(single user or only a couple of users).
Dave
From bouncefilter Thu Dec 23 04:19:28 1999
Received: from genesis.sundayta.co.uk (mail.sundayta.co.uk [212.24.70.227])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA85372
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 04:19:25 -0500 (EST)
(envelope-from david@sundayta.co.uk)
Received: from kings.sundayta.co.uk
([192.168.100.31] helo=sundayta.co.uk ident=david)
by genesis.sundayta.co.uk with esmtp (Exim 3.03 #1 (Debian))
id 1214zw-0004mt-00; Thu, 23 Dec 1999 09:57:28 +0000
Sender: david
Message-ID: <3861E3C7.8A7018D9@sundayta.co.uk>
Date: Thu, 23 Dec 1999 08:56:39 +0000
From: David Warnock <david@sundayta.co.uk>
Organization: Sundayta Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Interbase replacement
References: <199912221830.NAA20421@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce,
critical (at least for some)
- support for Windows 9xThis is a huge leap for us. Only if cgywin can be ported to it. That's
the only way we got to NT.
The cgywin page at cygnus says that windows 9x is supported but that
some api calls are not available there.
I would seriously like to help move this forward if possible - how? I am
not a C coder, but have Win 9x available on 1 box.
- transaction log with roll forward from backups
That will be in 7.1, due in 6 months.
Wonderful.
- relational integrity via foreign keys
That will be in 7.0, due in a few months.
Excellent.
Would it be possible to find ways to pay postgresql developers to add
these things? We would be very happy to pay several $1000 for these and
it might be possible to find others from the Interbase community.Money always helps, but we already have most of what you need coming.
I know Postgresql has nearly all we need. For our apps if we could get
the Win 9x it would be fine already. Thats why I am encouraging the
interbase people to look here.
I know that we have discussed Win 9x before and that there are technical
issues. I am hoping that with funds ways around these could be found.Win 9x seems like a HUGE leap for us. Where is cgywin on that?
See above, who is the best person to drive this forward and check if the
required bits are all there?
Thanks for all your work.
Dave
From bouncefilter Thu Dec 23 07:09:30 1999
Received: from genesis.sundayta.co.uk (mail.sundayta.co.uk [212.24.70.227])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA22257
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 07:08:40 -0500 (EST)
(envelope-from david@sundayta.co.uk)
Received: from kings.sundayta.co.uk
([192.168.100.31] helo=sundayta.co.uk ident=david)
by genesis.sundayta.co.uk with esmtp (Exim 3.03 #1 (Debian))
id 1217dr-0004vF-00; Thu, 23 Dec 1999 12:46:51 +0000
Sender: david
Message-ID: <38620B7A.D407D155@sundayta.co.uk>
Date: Thu, 23 Dec 1999 11:46:03 +0000
From: David Warnock <david@sundayta.co.uk>
Organization: Sundayta Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Interbase replacement
References: <199912231147.GAA27559@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce,
Somehow I thought that is what you would say ;-)
We will make a start on this in the new year. Meanwhile if anyone has
better skills (some would be a good start) please feel free to help out.
Dave
Bruce Momjian wrote:
I know Postgresql has nearly all we need. For our apps if we could get
the Win 9x it would be fine already. Thats why I am encouraging the
interbase people to look here.I know that we have discussed Win 9x before and that there are technical
issues. I am hoping that with funds ways around these could be found.Win 9x seems like a HUGE leap for us. Where is cgywin on that?
See above, who is the best person to drive this forward and check if the
required bits are all there?Probably you. Get 6.5.* and cgywin installed on Win95 and see what
fails. Then report back. Let's find out what is missing.-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
From bouncefilter Thu Dec 23 06:52:29 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA17250
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 06:51:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
GAA27559;
Thu, 23 Dec 1999 06:47:54 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912231147.GAA27559@candle.pha.pa.us>
Subject: Re: [GENERAL] Interbase replacement
In-Reply-To: <3861E3C7.8A7018D9@sundayta.co.uk> from David Warnock at "Dec 23,
1999 08:56:39 am"
To: David Warnock <david@sundayta.co.uk>
Date: Thu, 23 Dec 1999 06:47:54 -0500 (EST)
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I know Postgresql has nearly all we need. For our apps if we could get
the Win 9x it would be fine already. Thats why I am encouraging the
interbase people to look here.I know that we have discussed Win 9x before and that there are technical
issues. I am hoping that with funds ways around these could be found.Win 9x seems like a HUGE leap for us. Where is cgywin on that?
See above, who is the best person to drive this forward and check if the
required bits are all there?
Probably you. Get 6.5.* and cgywin installed on Win95 and see what
fails. Then report back. Let's find out what is missing.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 23 06:52:30 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA17246
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 06:51:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
GAA27645;
Thu, 23 Dec 1999 06:50:08 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912231150.GAA27645@candle.pha.pa.us>
Subject: Re: [GENERAL] Possible FAQs: single-quote and rename database
In-Reply-To: <19991223074107.A12201@iol.cz> from "Nathan L. Cutler" at "Dec
23,
1999 07:41:07 am"
To: "Nathan L. Cutler" <livingston@iol.cz>
Date: Thu, 23 Dec 1999 06:50:08 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hello:
I have two questions that might be FAQs (apologies in advance):
(1) Why does the parser choke on backslashed single-quote characters? Or,
in other words, why doesn't this work:testing=> \d bubba Table = bubba +--------------------------+----------------------------------+-------+ | Field | Type | Length| +--------------------------+----------------------------------+-------+ | litbub | varchar() | 60 | +--------------------------+----------------------------------+-------+ testing=> insert '\'' into bubba; ERROR: parser: parse error at or near "'"
INSERT INTO bubba VALUES ('\'');
(2) How does one rename a database? Other than dump/destroydb/restore,
obviously.
I think you can modify pg_database with new name, stop postmaster,
rename database directory, and restart. Not sure, but that may work.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 23 07:34:30 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA28380
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 07:34:08 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA28261;
Thu, 23 Dec 1999 07:33:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912231233.HAA28261@candle.pha.pa.us>
Subject: Re: [GENERAL] Interbase replacement
In-Reply-To: <38620B7A.D407D155@sundayta.co.uk> from David Warnock at "Dec 23,
1999 11:46:03 am"
To: David Warnock <david@sundayta.co.uk>
Date: Thu, 23 Dec 1999 07:33:21 -0500 (EST)
CC: "pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce,
Somehow I thought that is what you would say ;-)
We will make a start on this in the new year. Meanwhile if anyone has
better skills (some would be a good start) please feel free to help out.
Sorry, I run only Unix here.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 23 08:29:31 1999
Received: from gonzales.fpg.de (pD4B89830.dip.t-dialin.net [212.184.152.48])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA36331
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 08:29:21 -0500 (EST)
(envelope-from Martin.Pfeifer@fpg.de)
Received: from fpg.de (martin.fpg.de [192.168.0.3])
by gonzales.fpg.de (8.8.8/8.8.8) with ESMTP id OAA06392
for <pgsql-general@postgresql.org>; Thu, 23 Dec 1999 14:28:58 +0100
Message-ID: <3862242C.D9040843@fpg.de>
Date: Thu, 23 Dec 1999 14:31:24 +0100
From: Martin Pfeifer <Martin.Pfeifer@fpg.de>
Reply-To: Martin.Pfeifer@fpg.de
Organization: Frost & Partner GmbH
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: subscribe
Content-Type: multipart/mixed; boundary="------------5CB5BC37AAC5E298B715C73F"
This is a multi-part message in MIME format.
--------------5CB5BC37AAC5E298B715C73F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
subscribe
--------------5CB5BC37AAC5E298B715C73F
Content-Type: text/x-vcard; charset=us-ascii;
name="Martin.Pfeifer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Martin Pfeifer
Content-Disposition: attachment;
filename="Martin.Pfeifer.vcf"
begin:vcard
n:Pfeifer;Martin
tel;home:06131 / 555 751
tel;work:06145 / 938 124
x-mozilla-html:TRUE
adr:;;Synagogenstra�e 6;Mainz-Hechtsheim;;55129;
version:2.1
email;internet:martin.pfeifer@fpg.de
end:vcard
--------------5CB5BC37AAC5E298B715C73F--
From bouncefilter Thu Dec 23 11:51:33 1999
Received: from typeline.com (typeline.com [209.116.143.131])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA80426
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 11:50:49 -0500 (EST)
(envelope-from rjb@typeline.com)
From: rjb@typeline.com
Received: from typeline.com (dev01.typeline.com [209.116.143.141])
by typeline.com (8.9.3/8.9.3) with ESMTP id LAA22238
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 11:49:34 -0500 (EST)
Message-ID: <386252C6.8D4011F0@typeline.com>
Date: Thu, 23 Dec 1999 11:50:14 -0500
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: SQL Features...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
There seems to be a few SQL compatibility issues in Postgres that are
making it difficult for me to convert from Interbase. They are:
Support for foreign keys
Cascading a deletion across a referenced table or tables using a foreign
key
Does anyone know when these feature might be implemented?
Also: Is libpg a shared library? Can I write a client program say on a
FreeBSD
box that links to this library and calls a remote
Postgres db server running on a Linux box?
Thanks
From bouncefilter Thu Dec 23 12:12:33 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA86590
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 12:11:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA10070;
Thu, 23 Dec 1999 12:09:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912231709.MAA10070@candle.pha.pa.us>
Subject: Re: [GENERAL] SQL Features...
In-Reply-To: <386252C6.8D4011F0@typeline.com> from "rjb@typeline.com" at "Dec
23, 1999 11:50:14 am"
To: rjb@typeline.com
Date: Thu, 23 Dec 1999 12:09:14 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
There seems to be a few SQL compatibility issues in Postgres that are
making it difficult for me to convert from Interbase. They are:Support for foreign keys
Cascading a deletion across a referenced table or tables using a foreign
key
Next release 7.0 in a few months will have this.
Does anyone know when these feature might be implemented?
Also: Is libpg a shared library? Can I write a client program say on a
FreeBSD
box that links to this library and calls a remote
Postgres db server running on a Linux box?
You can communicate via tcp/ip to any server machine.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 23 12:22:33 1999
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA88484
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 12:22:19 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id RAA18999; Thu, 23 Dec 1999 17:22:10 GMT
Sender: a.joubert@albourne.com
Message-ID: <38625BE0.C89DD64D@albourne.com>
Date: Thu, 23 Dec 1999 19:29:05 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.38 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: rjb@typeline.com
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] SQL Features...
References: <386252C6.8D4011F0@typeline.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
rjb@typeline.com wrote:
There seems to be a few SQL compatibility issues in Postgres that are
making it difficult for me to convert from Interbase. They are:Support for foreign keys
Cascading a deletion across a referenced table or tables using a foreign
keyDoes anyone know when these feature might be implemented?
Coming in the next version courtesy of Jan Wieck.
Also: Is libpg a shared library? Can I write a client program say on a
FreeBSD
box that links to this library and calls a remote
Postgres db server running on a Linux box?
libpq is a shared library and you can write a client on most unix client
systems to connect to a postgres database.
Adriaan
From bouncefilter Thu Dec 23 17:21:38 1999
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA58738
for <pgsql-general@postgresql.org>;
Thu, 23 Dec 1999 17:20:57 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id QAA06708
for pgsql-general@postgresql.org; Thu, 23 Dec 1999 16:55:08 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: Luis Cortes <LCortes@Flash.Net>
Message-ID: <19991224.4534600@negrita.brunner.org>
Subject: Setting up a client/server database
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Newsgroups: comp.databases.postgresql.questions
X-Newsreader: Mozilla/3.0 (compatible; StarOffice/5.1; Linux)
Lines: 16
Date: Thu, 23 Dec 1999 21:54:52 GMT
X-Complaints-To: abuse@flash.net
X-Trace: news.flash.net 945986092 209.30.46.75 (Thu, 23 Dec 1999 15:54:52 CST)
Organization: FlashNet Communications, http://www.flash.net
To: pgsql-questions@postgresql.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id RAA58770
Hello,
What I want to setup is a Linux box running postgres and various
clients on Windows 95/98 possibly using Borland C++ to develop the
client side apps. Are there any documents out there to help me set
this up? Is there any one out there that can give me some tips? What
technology should I be looking at? ODBC? All good answers
appriciated!
Thanks,
Luis.
Please also reply to sender.
From bouncefilter Thu Dec 23 20:29:39 1999
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA95791
for <pgsql-general@postgreSQL.org>;
Thu, 23 Dec 1999 20:28:39 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id JAA80658;
Fri, 24 Dec 1999 09:26:12 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <3862CBB3.741CCA76@hello.com.tw>
Date: Fri, 24 Dec 1999 09:26:11 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: David Warnock <david@sundayta.co.uk>,
"pgsql-general@postgreSQL.org" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Interbase replacement
References: <199912231147.GAA27559@candle.pha.pa.us>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
I know Postgresql has nearly all we need. For our apps if we could get
the Win 9x it would be fine already. Thats why I am encouraging the
interbase people to look here.I know that we have discussed Win 9x before and that there are technical
issues. I am hoping that with funds ways around these could be found.Win 9x seems like a HUGE leap for us. Where is cgywin on that?
See above, who is the best person to drive this forward and check if the
required bits are all there?Probably you. Get 6.5.* and cgywin installed on Win95 and see what
fails. Then report back. Let's find out what is missing.
I had tried to get 6.5.* and cygwin installed on Win95, no fails. But the problem
is it can not generate postgres.exe and pq.dll. I don't know how to solve this
problem, you know, I'm a BSDer :)
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
- Kevin
From bouncefilter Fri Dec 24 05:05:44 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id FAA00146
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 05:05:28 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 3963 invoked by uid 417); 24 Dec 1999 10:09:19 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 24 Dec 1999 10:09:19 -0000
Message-ID: <001701bf4df6$07fa4900$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-general@postgreSQL.org>
Subject: HELP, receiving error-message
Date: Fri, 24 Dec 1999 11:02:45 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I've recently started getting the following error-message:
ERROR: out of free buffers: time to abort !
Haven't seen this come before, and have no idea what is causing it,
please help.....
Joost Roeleveld
ps. this also comes when I move back to an older version of the database I'm
currently
developing.... (didn't have it before...)
From bouncefilter Fri Dec 24 05:09:44 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id FAA00549
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 05:09:05 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 7490 invoked by uid 417); 24 Dec 1999 10:15:04 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 24 Dec 1999 10:15:04 -0000
Message-ID: <002f01bf4df6$d536dfa0$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-general@postgreSQL.org>
Subject: Re: HELP, receiving error-message
Date: Fri, 24 Dec 1999 11:08:29 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I've recently started getting the following error-message:
ERROR: out of free buffers: time to abort !
Haven't seen this come before, and have no idea what is causing it,
please help.....
Joost Roeleveld
ps. this also comes when I move back to an older version of the database I'm
currently developing.... (didn't have it before...)
From bouncefilter Fri Dec 24 05:49:45 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id FAA07691
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 05:49:13 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 29684 invoked by uid 417); 24 Dec 1999 10:55:11 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 24 Dec 1999 10:55:11 -0000
Message-ID: <004201bf4dfc$7039d980$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: "J. Roeleveld" <j.roeleveld@softhome.net>, <pgsql-general@postgreSQL.org>
References: <002f01bf4df6$d536dfa0$8402a8c0@sentec.demon.nl>
Subject: HELP, receiving error-message (follow-up)
Date: Fri, 24 Dec 1999 11:48:37 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I've recently started getting the following error-message:
ERROR: out of free buffers: time to abort !
Haven't seen this come before, and have no idea what is causing it,
please help.....Joost Roeleveld
ps. this also comes when I move back to an older version of the database
I'm
currently developing.... (didn't have it before...)
Just restarted the Backend, it seems to have solved the problem, but I still
have
no idea what caused this.
It even affected the production database......
Joost Roeleveld
From bouncefilter Fri Dec 24 05:59:45 1999
Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49])
by hub.org (8.9.3/8.9.3) with SMTP id FAA08439
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 05:59:16 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 2318 invoked by uid 417); 24 Dec 1999 11:05:15 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtpa.softhome.net with SMTP; 24 Dec 1999 11:05:15 -0000
Message-ID: <005801bf4dfd$d836d500$8402a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-general@postgreSQL.org>
Subject: HELP, receiving error-message (follow-up)
Date: Fri, 24 Dec 1999 11:58:41 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hi,
I've recently started getting the following error-message:
ERROR: out of free buffers: time to abort !
Haven't seen this come before, and have no idea what is causing it,
please help.....Joost Roeleveld
ps. this also comes when I move back to an older version of the database
I'm currently developing.... (didn't have it before...)
Just restarted the Backend, it seems to have solved the problem, but I still
have no idea what caused this.
It even affected the production database, which caused me to restart the
back-end...
Joost Roeleveld
From bouncefilter Fri Dec 24 08:19:47 1999
Received: from rtsoft.msk.ru (rtsoft.rmt.ru [194.67.160.206])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA34760
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 08:18:57 -0500 (EST)
(envelope-from mak@rtsoft.msk.ru)
Received: from makushina (makushina.rtsoft.msk.ru [192.168.200.49])
by rtsoft.msk.ru (8.9.3/8.9.3) with SMTP id QAA32566
for <pgsql-general@postgreSQL.org>; Fri, 24 Dec 1999 16:52:26 +0300
Message-ID: <003f01bf4e11$814e5bf0$31c8a8c0@makushina.rtsoft.msk.ru>
From: "Natalya Makushina" <mak@rtsoft.msk.ru>
To: <pgsql-general@postgreSQL.org>
Subject: Can not destroy db
Date: Fri, 24 Dec 1999 16:19:27 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id IAA34815
Hello all!
I found very strange thing.
I have database "wwwnews". It have 4 tables, indexes and triggers. I destroy this database and create it again. All work okey.
Then i say
psql wwwnews
To my great surprise I saw all tables with information.
I repeat this sequence of command few times. Result is a same.
I try to create another database. I create it and this database have 4 tables too!
What do I do wrong?
Postgres version: 6.5.2.
Platform: Red Hat Linux release 5.0 (Hurricane) Kernel 2.1.57 on a ppc
Best regards, Natalya Makushina.
$psql wwwnews
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on powerpc-unknown-linux-gnu, compiled by gcc egcs-2.90.25 980302 (egcs-1.0.2 prer
elease)]
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: wwwnews
wwwnews=> \dt
Database = wwwnews
+------------------+----------------------------------+----------+
| Owner | Relation | Type |
+------------------+----------------------------------+----------+
| mak | exibition | table |
| mak | id | table |
| mak | information | table |
| mak | news | table |
| mak | seminar | table |
+------------------+----------------------------------+----------+wwwnews=> \q
$ destroydb wwwnews
$ psql wwwnews
Connection to database 'wwwnews' failed.
FATAL 1: Database wwwnews does not exist in pg_database
$ createdb wwwnews
$ psql wwwnews
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on powerpc-unknown-linux-gnu, compiled by gcc egcs-2.90.25 980302 (egcs-1.0.2 prer
elease)]
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: wwwnews
wwwnews=> \dt
Database = wwwnews
+------------------+----------------------------------+----------+
| Owner | Relation | Type |
+------------------+----------------------------------+----------+
| mak | exibition | table |
| mak | id | table |
| mak | information | table |
| mak | news | table |
| mak | seminar | table |
+------------------+----------------------------------+----------+wwwnews=> \q
$ createdb wwwnews1
$ psql wwwnews1
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.2 on powerpc-unknown-linux-gnu, compiled by gcc egcs-2.90.25 980302 (egcs-1.0.2 prer
elease)]
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: wwwnews1
wwwnews1=> \dt
Database = wwwnews1
+------------------+----------------------------------+----------+
| Owner | Relation | Type |
+------------------+----------------------------------+----------+
| mak | exibition | table |
| mak | id | table |
| mak | information | table |
| mak | news | table |
| mak | seminar | table |
+------------------+----------------------------------+----------+wwwnews1=> \q
$
From bouncefilter Fri Dec 24 11:53:49 1999
Received: from mailbox.reptiles.org (IDENT:root@mailbox.reptiles.org
[198.96.117.155]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA76515
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 11:53:18 -0500 (EST)
(envelope-from jim@reptiles.org)
Received: from localhost (3076 bytes) by mailbox.reptiles.org
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <jim>) (ident <jim> using unix)
id <m121Xxt-00080yC@mailbox.reptiles.org>
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 11:53:17 -0500 (EST)
(Smail-3.2.0.108 1999-Sep-19 #3 built 1999-Oct-27)
Date: Fri, 24 Dec 1999 11:53:17 -0500
From: Jim Mercer <jim@reptiles.org>
To: pgsql-general@postgreSQL.org
Subject: proctitle patch (useful)
Message-ID: <19991224115317.Z4188@reptiles.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
when trying to diagnose problems, it is sometimes difficult to identify which
backend process is connected to what client process.
here is a patch for src/backend/commands/variable.c
this patch adds a new variable PROCTITLE.
this allows client processes to set the backend proctitle to something useful:
$ ps auxww | grep post
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
11125 ?? I 0:00.42 (postgres)
$ psql database
database=> SET PROCTITLE = 'testing proctitle 123';
SET VARIABLE
database=>
$ ps ax | grep post
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
11125 ?? I 0:00.21 postmaster: testing proctitle 123 (postgres)
i'm not overly familiar with GNU configure, so i'll leave it up to the people
who manage the source to figure out a clean portable way of enabling the
feature.
also note: not all systems have setproctitle(), although there is usually
a way to do it.
--
[ Jim Mercer jim@reptiles.org +1 416 506-0654 ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
*** variable.c.orig Fri Dec 24 11:23:42 1999
--- variable.c Fri Dec 24 11:23:10 1999
***************
*** 21,26 ****
--- 21,32 ----
#include "mb/pg_wchar.h"
#endif+ #define PROCTITLE
+ #ifdef PROCTITLE
+ static bool show_title(void);
+ static bool reset_title(void);
+ static bool parse_title(const char *);
+ #endif
static bool show_date(void);
static bool reset_date(void);
static bool parse_date(const char *);
***************
*** 304,309 ****
--- 310,370 ----
return TRUE;
}+ #ifdef PROCTITLE
+ /*
+ *
+ * PROCTITLE
+ *
+ */
+ static char *ProcTitle = NULL;
+ static bool
+ parse_title(const char *value)
+ {
+ if (value == NULL)
+ {
+ reset_title();
+ return TRUE;
+ }
+
+ if (ProcTitle != NULL)
+ free(ProcTitle);
+
+ ProcTitle = strdup(value);
+ setproctitle(ProcTitle);
+
+ return TRUE;
+ }
+
+ static bool
+ show_title()
+ {
+ char buf[64];
+
+ strcpy(buf, "DateStyle is ");
+ if (ProcTitle != NULL)
+ strcat(buf, ProcTitle);
+ else
+ strcat(buf, "NULL");
+
+ elog(NOTICE, buf, NULL);
+
+ return TRUE;
+ }
+
+ static bool
+ reset_title()
+ {
+ if (ProcTitle != NULL)
+ {
+ free(ProcTitle);
+ ProcTitle = NULL;
+ }
+
+ setproctitle(ProcTitle);
+ return TRUE;
+ }
+ #endif
+
/*
*
* DATE_STYLE
***************
*** 539,544 ****
--- 600,610 ----
} VariableParsers[] = {
+ #ifdef PROCTITLE
+ {
+ "proctitle", parse_title, show_title, reset_title
+ },
+ #endif
{
"datestyle", parse_date, show_date, reset_date
},From bouncefilter Fri Dec 24 12:31:49 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA86298
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 12:31:44 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA13674;
Fri, 24 Dec 1999 12:09:31 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912241709.MAA13674@candle.pha.pa.us>
Subject: Re: [GENERAL] proctitle patch (useful)
In-Reply-To: <19991224115317.Z4188@reptiles.org> from Jim Mercer at "Dec 24,
1999 11:53:17 am"
To: Jim Mercer <jim@reptiles.org>
Date: Fri, 24 Dec 1999 12:09:31 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The problem is that we already have a complex system of displaying the
user, database, and SQL command being executed.
You should be seeing this on your platform already. What OS and pgsql
version?
In other words, you should not be seeing this:
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Dec 24 12:54:50 1999
Received: from mailbox.reptiles.org (IDENT:root@mailbox.reptiles.org
[198.96.117.155]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA88514
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 12:54:29 -0500 (EST)
(envelope-from jim@reptiles.org)
Received: from localhost (2287 bytes) by mailbox.reptiles.org
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <jim>) (ident <jim> using unix)
id <m121Yts-00080yC@mailbox.reptiles.org>
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 12:53:12 -0500 (EST)
(Smail-3.2.0.108 1999-Sep-19 #3 built 1999-Oct-27)
Date: Fri, 24 Dec 1999 12:53:12 -0500
From: Jim Mercer <jim@reptiles.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] proctitle patch (useful)
Message-ID: <19991224125311.B4188@reptiles.org>
References: <19991224115317.Z4188@reptiles.org>
<199912241709.MAA13674@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <199912241709.MAA13674@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Fri, Dec 24, 1999 at 12:09:31PM
-0500
On Fri, Dec 24, 1999 at 12:09:31PM -0500, Bruce Momjian wrote:
The problem is that we already have a complex system of displaying the
user, database, and SQL command being executed.
the current proctitle doesn't allow me to find the PID of the client process,
without guessing.
it becomes even worse when the client process is on a different machine.
using ProcTitle, i can have the client process set the proctitle to something
meaningful like "%s:%s:%d:%s", hostname, prgname, pid, status.
in my case, i'm actually opening multiple sessions on the same database,
so i'd like to know which backends are for which sessions.
You should be seeing this on your platform already. What OS and pgsql
version?In other words, you should not be seeing this:
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
that example was from NetBSD 1.4.1 and pgsql 6.5.3
on freebsd it looks like:
bigbird% ps auxww | grep post
pgsql 16429 0.0 0.5 4004 1496 ?? Ss Mon11PM 0:41.06 /usr/local/pgsql/bin/postmaster -i -S -o -F -D/usr/local/pgsql/data (postgres)
pgsql 10317 0.0 0.8 4468 2672 ?? S 12:43PM 0:00.03 /usr/local/pgsql/bin/postgres dbadmin localhost nagoss idle
(for some reason, i can't get my NetBSD box to do the same thing)
now that i think about it, the hack needs a little refining, to basically tell
the other code not to overwrite the ProcTitle.
--
[ Jim Mercer jim@reptiles.org +1 416 506-0654 ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
From bouncefilter Fri Dec 24 15:34:52 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA18789
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 15:34:22 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
PAA15686;
Fri, 24 Dec 1999 15:28:42 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912242028.PAA15686@candle.pha.pa.us>
Subject: Re: [GENERAL] proctitle patch (useful)
In-Reply-To: <19991224125311.B4188@reptiles.org> from Jim Mercer at "Dec 24,
1999 12:53:12 pm"
To: Jim Mercer <jim@reptiles.org>
Date: Fri, 24 Dec 1999 15:28:42 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Fri, Dec 24, 1999 at 12:09:31PM -0500, Bruce Momjian wrote:
The problem is that we already have a complex system of displaying the
user, database, and SQL command being executed.the current proctitle doesn't allow me to find the PID of the client process,
without guessing.it becomes even worse when the client process is on a different machine.
using ProcTitle, i can have the client process set the proctitle to something
meaningful like "%s:%s:%d:%s", hostname, prgname, pid, status.in my case, i'm actually opening multiple sessions on the same database,
so i'd like to know which backends are for which sessions.
A larger question is whether we want SQL clients to be able to control
this display. I certainly makes spoofing possible, where I look like
one person, but am actually someone else.
You should be seeing this on your platform already. What OS and pgsql
version?In other words, you should not be seeing this:
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
that example was from NetBSD 1.4.1 and pgsql 6.5.3
on freebsd it looks like:
bigbird% ps auxww | grep post
pgsql 16429 0.0 0.5 4004 1496 ?? Ss Mon11PM 0:41.06 /usr/local/pgsql/bin/postmaster -i -S -o -F -D/usr/local/pgsql/data (postgres)
pgsql 10317 0.0 0.8 4468 2672 ?? S 12:43PM 0:00.03 /usr/local/pgsql/bin/postgres dbadmin localhost nagoss idle(for some reason, i can't get my NetBSD box to do the same thing)
now that i think about it, the hack needs a little refining, to basically tell
the other code not to overwrite the ProcTitle.
I don't understand why NetBSD doesn't do it, while FreeBSD and BSDI do.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Dec 24 16:31:52 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA29346
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 16:31:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA18997;
Fri, 24 Dec 1999 16:08:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912242108.QAA18997@candle.pha.pa.us>
Subject: Re: [GENERAL] proctitle patch (useful)
In-Reply-To: <19991224115317.Z4188@reptiles.org> from Jim Mercer at "Dec 24,
1999 11:53:17 am"
To: Jim Mercer <jim@reptiles.org>
Date: Fri, 24 Dec 1999 16:08:40 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
when trying to diagnose problems, it is sometimes difficult to identify which
backend process is connected to what client process.here is a patch for src/backend/commands/variable.c
this patch adds a new variable PROCTITLE.
this allows client processes to set the backend proctitle to something useful:
$ ps auxww | grep post
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
11125 ?? I 0:00.42 (postgres)$ psql database
database=> SET PROCTITLE = 'testing proctitle 123';
SET VARIABLE
database=>$ ps ax | grep post
11080 ?? Is 0:00.06 postmaster -S -i -d 3 -o -F (postgres)
11125 ?? I 0:00.21 postmaster: testing proctitle 123 (postgres)i'm not overly familiar with GNU configure, so i'll leave it up to the people
who manage the source to figure out a clean portable way of enabling the
feature.
If we decide this is a nice feature addition, I would like it to use our
main PS_SET_STATUS() code rather than proctitle().
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Fri Dec 24 16:52:52 1999
Received: from mailbox.reptiles.org (IDENT:root@mailbox.reptiles.org
[198.96.117.155]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA32129
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 16:52:50 -0500 (EST)
(envelope-from jim@reptiles.org)
Received: from localhost (1466 bytes) by mailbox.reptiles.org
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <jim>) (ident <jim> using unix)
id <m121ccX-00080yC@mailbox.reptiles.org>
for <pgsql-general@postgreSQL.org>;
Fri, 24 Dec 1999 16:51:33 -0500 (EST)
(Smail-3.2.0.108 1999-Sep-19 #3 built 1999-Oct-27)
Date: Fri, 24 Dec 1999 16:51:32 -0500
From: Jim Mercer <jim@reptiles.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] proctitle patch (useful)
Message-ID: <19991224165132.C4188@reptiles.org>
References: <19991224115317.Z4188@reptiles.org>
<199912242108.QAA18997@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <199912242108.QAA18997@candle.pha.pa.us>;
from pgman@candle.pha.pa.us on Fri, Dec 24, 1999 at 04:08:40PM
-0500
On Fri, Dec 24, 1999 at 04:08:40PM -0500, Bruce Momjian wrote:
i'm not overly familiar with GNU configure, so i'll leave it up to the
people who manage the source to figure out a clean portable way of
enabling the feature.If we decide this is a nice feature addition, I would like it to use our
main PS_SET_STATUS() code rather than proctitle().
my implementation used the most expeditious method at hand.
the PS_SET_STATUS() code is likely more portable across platforms.
(although one might look at using setproctitle inside PS_SET_STATUS(), if
it is available).
--
[ Jim Mercer jim@reptiles.org +1 416 506-0654 ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
From bouncefilter Sat Dec 25 11:01:04 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA22529
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 11:00:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id LAA21597
for pgsql-general@postgreSQL.org; Sat, 25 Dec 1999 11:00:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912251600.LAA21597@candle.pha.pa.us>
Subject: Future of PostgreSQL
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
Date: Sat, 25 Dec 1999 11:00:46 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Consider this:
The stock market going crazy over Linux stocks
Interbase users are considering moving en-mass to PostgreSQL
Publishers are crawling all over each other to publish a PostgreSQL book
With these signs, it is possible we may be _very_ popular in the near
future. I am not sure this will happen, but I didn't think this would
happen to Linux.
My big question is, what new challenges will we face as we become more
popular?
Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Dec 25 12:25:05 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id MAA35743
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 12:24:57 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Hamster.DoCS.UU.SE (e99re41@Hamster.DoCS.UU.SE [130.238.9.95])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id SAA24752;
Sat, 25 Dec 1999 18:24:56 +0100
Received: from localhost (e99re41@localhost) by Hamster.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id SAA11440;
Sat, 25 Dec 1999 18:25:23 +0100
X-Authentication-Warning: Hamster.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Sat, 25 Dec 1999 18:25:23 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912251600.LAA21597@candle.pha.pa.us>
Message-ID: <Pine.GSO.4.02A.9912251821410.11431-100000@Hamster.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 25 Dec 1999, Bruce Momjian wrote:
Consider this:
The stock market going crazy over Linux stocks
Interbase users are considering moving en-mass to PostgreSQL
Publishers are crawling all over each other to publish a PostgreSQL bookWith these signs, it is possible we may be _very_ popular in the near
future. I am not sure this will happen, but I didn't think this would
happen to Linux.
The worst thing we could do is to intentionally try to stay less than
popular. There's a reason Linux is taking off and *BSD isn't really, and
it's not technology. (Sorry, Marc.)
My big question is, what new challenges will we face as we become more
popular?Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.
One thing we should definitely attempt to do before 7.0 is write our own
license or at least our own copyright in addition to the BSD license,
since none of us (?) actually work at UCB.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From bouncefilter Sat Dec 25 13:21:06 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA45868
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 13:20:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA24091;
Sat, 25 Dec 1999 13:19:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912251819.NAA24091@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.GSO.4.02A.9912251821410.11431-100000@Hamster.DoCS.UU.SE>
from Peter Eisentraut at "Dec 25, 1999 06:25:23 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 25 Dec 1999 13:19:33 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sat, 25 Dec 1999, Bruce Momjian wrote:
Consider this:
The stock market going crazy over Linux stocks
Interbase users are considering moving en-mass to PostgreSQL
Publishers are crawling all over each other to publish a PostgreSQL book
These three items represent three good signs:
Commercial success of a related technology
Increased user interest
Increased commercial interest
BTW, I forgot to mention that my web page at
With these signs, it is possible we may be _very_ popular in the near
future. I am not sure this will happen, but I didn't think this would
happen to Linux.The worst thing we could do is to intentionally try to stay less than
popular. There's a reason Linux is taking off and *BSD isn't really, and
it's not technology. (Sorry, Marc.)
I think everyone can agree with that, including Marc.
My big question is, what new challenges will we face as we become more
popular?Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.One thing we should definitely attempt to do before 7.0 is write our own
license or at least our own copyright in addition to the BSD license,
since none of us (?) actually work at UCB.
We certainly have the power to add a license of our own. BSDI has done
this, as well as many other companies. I don't want to wait until
things get very busy and then try to address these issues. We may
decide we don't want to do anything, but I would like to decide that
now.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Dec 25 14:52:07 1999
Received: from berghold.net (IDENT:root@cc1008600-a.etntwn1.nj.home.com
[24.3.204.54] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id OAA61240
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 14:51:36 -0500 (EST)
(envelope-from Peter@berghold.net)
Received: from lc8.skunkworks.berghold.net
(IDENT:101@lc8.skunkworks.berghold.net [10.1.1.25])
by berghold.net (8.9.3/8.9.3) with SMTP id OAA07095
for <pgsql-general@postgreSQL.org>; Sat, 25 Dec 1999 14:51:33 -0500
From: Peter Berghold <Peter@berghold.net>
Date: Sat, 25 Dec 1999 19:51:52 GMT
Message-ID: <19991225.19515200@lc8.skunkworks.berghold.net>
Subject: DBI::Pg for Perl?
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id OAA61284
Hi Folks,
Does anyone out there know of a DBI driver for Postgres for Perl? I
searched CPAN and didn't see one. Maybe I'm looking in the wrong
spot...
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Peter L. Berghold Peter@Berghold.Net
"Linux renders ships http://www.berghold.net
NT renders ships useless...." From bouncefilter Sat Dec 25 14:54:07 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA61418
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 14:53:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA26266;
Sat, 25 Dec 1999 14:53:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912251953.OAA26266@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <99122520103500.00975@olimpo> from Jose Miguel Pereira Tavares at
"Dec 25, 1999 08:07:14 pm"
To: Jose Miguel Pereira Tavares <mtavares@student.dei.uc.pt>
Date: Sat, 25 Dec 1999 14:53:26 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
We certainly have the power to add a license of our own. BSDI has done
this, as well as many other companies. I don't want to wait until
things get very busy and then try to address these issues. We may
decide we don't want to do anything, but I would like to decide that
now.I don't quite understand why you think that a license change is neaded.
One of the things that made me into PostgreSQL was exactly it's license.
I am not saying we need one. I am just asking.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Dec 25 14:44:08 1999
Received: from olimpo.dei.uc.pt (postfix@olimpo.dei.uc.pt [193.137.203.36])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA60546
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 14:43:26 -0500 (EST)
(envelope-from mtavares@dei.uc.pt)
Received: by olimpo.dei.uc.pt (Postfix, from userid 0)
id 016AD6176; Sat, 25 Dec 1999 20:10:35 +0000 (WET)
From: Jose Miguel Pereira Tavares <mtavares@student.dei.uc.pt>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
Date: Sat, 25 Dec 1999 20:07:14 +0000
X-Mailer: KMail [version 1.0.17]
Content-Type: text/plain
Cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
References: <199912251819.NAA24091@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99122520103500.00975@olimpo>
Content-Transfer-Encoding: 8bit
X-KMail-Mark:
Sender: mtavares@dei.uc.pt
On Sat, 25 Dec 1999, Bruce Momjian wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
The worst thing we could do is to intentionally try to stay less than
popular. There's a reason Linux is taking off and *BSD isn't really, and
it's not technology. (Sorry, Marc.)I think everyone can agree with that, including Marc.
As long as it's not like "*BSD has better tech than Linux" kinda thing.
We certainly have the power to add a license of our own. BSDI has done
this, as well as many other companies. I don't want to wait until
things get very busy and then try to address these issues. We may
decide we don't want to do anything, but I would like to decide that
now.
I don't quite understand why you think that a license change is neaded.
One of the things that made me into PostgreSQL was exactly it's license.
-------------------- Jose Miguel Pereira Tavares --------------------
Talking much about oneself can also be a means to conceal oneself.
-- Friedrich Nietzsche
From bouncefilter Sat Dec 25 17:57:09 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA91891
for <pgsql-general@postgresql.org>;
Sat, 25 Dec 1999 17:56:35 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.88.152]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 25 Dec 1999 16:56:55 -0600
Sender: ed
Message-ID: <38654BC8.644F88A7@austin.rr.com>
Date: Sat, 25 Dec 1999 16:57:12 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Berghold <Peter@berghold.net>
CC: PostgreSQL-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] DBI::Pg for Perl?
References: <19991225.19515200@lc8.skunkworks.berghold.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Berghold wrote:
Hi Folks,
Does anyone out there know of a DBI driver for Postgres for Perl? I
searched CPAN and didn't see one. Maybe I'm looking in the wrong
spot...
It's there...DBD::Pg, by E. Mergl. Works well.
Cheers,
Ed Loehr
From bouncefilter Sat Dec 25 18:18:09 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA96615
for <pgsql-general@postgresql.org>;
Sat, 25 Dec 1999 18:17:13 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.88.152]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 25 Dec 1999 17:17:13 -0600
Sender: ed
Message-ID: <38655089.B6D6B5A1@austin.rr.com>
Date: Sat, 25 Dec 1999 17:17:29 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <199912251600.LAA21597@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
My big question is, what new challenges will we face as we become more
popular?
The 3 greatest technical/engineering challenges: 1) system reliability
& recoverability, 2) system reliability & recoverability, and 3) system reliability
and recoverability. The masses won't stay long if the system won't stay up, isn't
easy to diagnose by non-experts, or cannot be easily restored from backups without
significant data losses. New functionality is great, but a system that won't stay
up consistently is approaching worthlessness for mission-critical 24x7
applications. And if the masses leave because of system reliability problems, you
can be very, very certain about what they will tell their friends and coworkers.
Cheers,
Ed Loehr
From bouncefilter Sat Dec 25 18:20:10 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA96812
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 18:20:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA29219;
Sat, 25 Dec 1999 18:20:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912252320.SAA29219@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <38655089.B6D6B5A1@austin.rr.com> from Ed Loehr at "Dec 25, 1999
05:17:29 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Sat, 25 Dec 1999 18:20:10 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
My big question is, what new challenges will we face as we
become more > popular?
The 3 greatest technical/engineering challenges: 1) system
reliability & recoverability, 2) system reliability & recoverability,
and 3) system reliability and recoverability. The masses won't
stay long if the system won't stay up, isn't easy to diagnose
by non-experts, or cannot be easily restored from backups without
significant data losses. New functionality is great, but a
system that won't stay up consistently is approaching worthlessness
for mission-critical 24x7 applications. And if the masses
leave because of system reliability problems, you can be very,
very certain about what they will tell their friends and coworkers.
And we don't have a problem in this area, do we?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Dec 25 18:22:09 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA97003
for <pgsql-general@postgresql.org>;
Sat, 25 Dec 1999 18:21:49 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.88.152]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 25 Dec 1999 17:22:10 -0600
Sender: ed
Message-ID: <386551B3.5DF632F6@austin.rr.com>
Date: Sat, 25 Dec 1999 17:22:27 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Berghold <Peter@berghold.net>,
PostgreSQL-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] DBI::Pg for Perl?
References: <19991225.19515200@lc8.skunkworks.berghold.net>
<38654BC8.644F88A7@austin.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
See DBD-Pg under http://www.cpan.org/modules/by-module/DBD/
Ed Loehr wrote:
Peter Berghold wrote:
Hi Folks,
Does anyone out there know of a DBI driver for Postgres for Perl? I
searched CPAN and didn't see one. Maybe I'm looking in the wrong
spot...It's there...DBD::Pg, by E. Mergl. Works well.
Cheers,
Ed Loehr
From bouncefilter Sat Dec 25 18:23:09 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA97133
for <pgsql-general@postgresql.org>;
Sat, 25 Dec 1999 18:22:49 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.88.152]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sat, 25 Dec 1999 17:23:09 -0600
Sender: ed
Message-ID: <386551EE.7E6B3140@austin.rr.com>
Date: Sat, 25 Dec 1999 17:23:26 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <199912252320.SAA29219@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Bruce Momjian wrote:
My big question is, what new challenges will we face as we
become more > popular?
The 3 greatest technical/engineering challenges: 1) system
reliability & recoverability, 2) system reliability & recoverability,
and 3) system reliability and recoverability. The masses won't
stay long if the system won't stay up, isn't easy to diagnose
by non-experts, or cannot be easily restored from backups without
significant data losses. New functionality is great, but a
system that won't stay up consistently is approaching worthlessness
for mission-critical 24x7 applications. And if the masses
leave because of system reliability problems, you can be very,
very certain about what they will tell their friends and coworkers.And we don't have a problem in this area, do we?
Please tell me you're kidding.
Cheers,
Ed Loehr
From bouncefilter Sat Dec 25 19:14:10 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA08394
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 19:13:20 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA29685;
Sat, 25 Dec 1999 19:13:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912260013.TAA29685@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <386551EE.7E6B3140@austin.rr.com> from Ed Loehr at "Dec 25, 1999
05:23:26 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Sat, 25 Dec 1999 19:13:26 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
system that won't stay up consistently is approaching worthlessness
for mission-critical 24x7 applications. And if the masses
leave because of system reliability problems, you can be very,
very certain about what they will tell their friends and coworkers.And we don't have a problem in this area, do we?
Please tell me you're kidding.
We don't have roll-forward logging until 7.1, and require vacuum
regularly. Other than that, I don't know of any major issues.
Reliability has always been of primary importance. We wouldn't be where
we are today without reliability.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Dec 25 20:44:11 1999
Received: from elwood.cais.com (elwood.cais.com [199.0.216.215])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA30559
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 20:43:51 -0500 (EST)
(envelope-from clark.evans@manhattanproject.com)
Received: from cauchy.clarkevans.com (IDENT:clark@209-9-30-66.sdsl.cais.net
[209.9.30.66]) by elwood.cais.com (8.9.1/Elwood) with ESMTP
id UAA00485; Sat, 25 Dec 1999 20:46:02 -0500 (EST)
Date: Sat, 25 Dec 1999 20:43:44 -0500 (EST)
From: "Clark C. Evans" <clark.evans@manhattanproject.com>
X-Sender: clark@cauchy.clarkevans.com
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912251600.LAA21597@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9912252042540.4979-100000@cauchy.clarkevans.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?
Plug-in Oracle 7 compatibility.
From bouncefilter Sat Dec 25 21:28:12 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA39309
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 21:27:54 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA01249;
Sat, 25 Dec 1999 21:27:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912260227.VAA01249@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.LNX.4.10.9912252042540.4979-100000@cauchy.clarkevans.com>
from "Clark C. Evans" at "Dec 25, 1999 08:43:44 pm"
To: "Clark C. Evans" <clark.evans@manhattanproject.com>
Date: Sat, 25 Dec 1999 21:27:39 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?Plug-in Oracle 7 compatibility.
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sat Dec 25 21:43:12 1999
Received: from elwood.cais.com (elwood.cais.com [199.0.216.215])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA44096
for <pgsql-general@postgreSQL.org>;
Sat, 25 Dec 1999 21:43:01 -0500 (EST)
(envelope-from clark.evans@manhattanproject.com)
Received: from cauchy.clarkevans.com (IDENT:clark@209-9-30-66.sdsl.cais.net
[209.9.30.66]) by elwood.cais.com (8.9.1/Elwood) with ESMTP
id VAA02663; Sat, 25 Dec 1999 21:44:51 -0500 (EST)
Date: Sat, 25 Dec 1999 21:42:33 -0500 (EST)
From: "Clark C. Evans" <clark.evans@manhattanproject.com>
X-Sender: clark@cauchy.clarkevans.com
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: "Clark C. Evans" <clark.evans@manhattanproject.com>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912260227.VAA01249@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9912252130330.11219-100000@cauchy.clarkevans.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 25 Dec 1999, Bruce Momjian wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?Plug-in Oracle 7 compatibility.
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?
How about an SQL*Net listener... this would make
PostgreSQL plug-n-play.
It could even be a proprietary product, thus allowing
VC's to fund it. It's a bit hard to justify changing
ODBC settings on 30+ apps on a few (hundred) thousand PC
workstations; some with hardcoded ODBC "ORA7.DLL" settings...
Why? Oracle is going to be shutting down Oracle 7 support
soon, forcing the upgrade to Oracle 8. This will leave
hundreds (thousands accross the industry?) of applications
stranded, and not alot of money to re-write/re-deploy/re-test
them. Just a thought... at every big company I've been with,
this has been a sore spot. It could also potentially
be a good consulting revenue stream for Marc's group.
Best,
Clark
From bouncefilter Sun Dec 26 01:02:14 1999
Received: from mx20.rmci.net (halcyon.rmci.net [205.162.184.63])
by hub.org (8.9.3/8.9.3) with SMTP id BAA78114
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 01:01:53 -0500 (EST)
(envelope-from webweaver@rmci.net)
Received: (qmail 443 invoked from network); 26 Dec 1999 08:02:36 -0000
Received: from usr-boi-86.rmci.net (HELO chilly-willy) (206.159.112.172)
by halcyon.rmci.net with SMTP; 26 Dec 1999 08:02:36 -0000
Message-Id: <4.2.0.58.19991225214814.0096abe0@mail.rmci.net>
X-Sender: webweaver@mail.rmci.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sat, 25 Dec 1999 23:01:27 -0700
To: Peter Eisentraut <peter_e@gmx.net>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Ken <webweaver@rmci.net>
Subject: Re: [GENERAL] Future of PostgreSQL
Cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
In-Reply-To: <Pine.GSO.4.02A.9912251821410.11431-100000@Hamster.DoCS.UU.
SE>
References: <199912251600.LAA21597@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 06:25 PM 12/25/99 +0100, Peter Eisentraut wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
Consider this:
The stock market going crazy over Linux stocks
Interbase users are considering moving en-mass to PostgreSQL
Publishers are crawling all over each other to publish aPostgreSQL book
With these signs, it is possible we may be _very_ popular in the near
future. I am not sure this will happen, but I didn't think this would
happen to Linux.The worst thing we could do is to intentionally try to stay less than
popular. There's a reason Linux is taking off and *BSD isn't really, and
it's not technology. (Sorry, Marc.)
I don't think the *BSD's have intentionally tried any such thing. You
could possibly have picked up these vibes from certain members of the Open
BSD camp, but I wouldn't extend them to encompass the *BSD community at
large. (And I wonder if I should comment about how Linux people are
migrating to the *BSD camps in droves.... But I guess it'd be best to just
let it slide ;-o)
My big question is, what new challenges will we face as we become more
popular?Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.One thing we should definitely attempt to do before 7.0 is write our own
license or at least our own copyright in addition to the BSD license,
since none of us (?) actually work at UCB.
I come to pgsql from MySQL. I've not done much of anything with it yet
really, so I should probably keep my mouth shut. But I thought you might
be interested in my perspective. And, after all, you did ask... My hands
on experience with pgsql is minimal, but follows is the sense I get from
the larger community and having lurked on this list for a bit.
The primary "feature" that has me looking at pgsql again is the license. I
like MySQL. The MySQL community is great. I don't like their license,
however, and feel pretty strongly about it. I would counsel against
developing your own. Why reinvent the wheel unless you've got some special
agenda that requires it? I prefer the more liberal BSD, but GPL is fine.
Transaction support is also nice, but secondary to license issues. There
are mysql workarounds in for the absence of transaction support, but it's
hard to get around the license and still be honest.
I would hope that future development continues to focus on reliability,
functionality, and speed. Your work will then speak for itself and more
people will adopt pgsql. I initially ruled it out because of reliability
and speed concerns. The past year has seen much improvement in these
areas, enough to have piqued my interest once again. The *perception*
remains, however, that pgsql still leaves a bit to be desired in the areas
of reliability and maintainability. This needs to be remedied. Like I
said, progress has been mad, but it appears pgsql isn't quite out of the
woods yet.
Well, there's my $0.02. Thanks for your indulgence.
Regards-- Ken
From bouncefilter Sun Dec 26 01:02:14 1999
Received: from mx20.rmci.net (halcyon.rmci.net [205.162.184.63])
by hub.org (8.9.3/8.9.3) with SMTP id BAA78118
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 01:01:54 -0500 (EST)
(envelope-from webweaver@rmci.net)
Received: (qmail 450 invoked from network); 26 Dec 1999 08:02:38 -0000
Received: from usr-boi-86.rmci.net (HELO chilly-willy) (206.159.112.172)
by halcyon.rmci.net with SMTP; 26 Dec 1999 08:02:38 -0000
Message-Id: <4.2.0.58.19991225230239.009748c0@mail.rmci.net>
X-Sender: webweaver@mail.rmci.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sat, 25 Dec 1999 23:02:46 -0700
To: Peter Eisentraut <peter_e@gmx.net>, Bruce Momjian <pgman@candle.pha.pa.us>
From: Ken <webweaver@rmci.net>
Subject: Re: [GENERAL] Future of PostgreSQL
Cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 06:25 PM 12/25/99 +0100, Peter Eisentraut wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
Consider this:
The stock market going crazy over Linux stocks
Interbase users are considering moving en-mass to PostgreSQL
Publishers are crawling all over each other to publish aPostgreSQL book
With these signs, it is possible we may be _very_ popular in the near
future. I am not sure this will happen, but I didn't think this would
happen to Linux.The worst thing we could do is to intentionally try to stay less than
popular. There's a reason Linux is taking off and *BSD isn't really, and
it's not technology. (Sorry, Marc.)
I don't think the *BSD's have intentionally tried any such thing. You
could possibly have picked up these vibes from certain members of the Open
BSD camp, but I wouldn't extend them to encompass the *BSD community at
large. (And I wonder if I should comment about how Linux people are
migrating to the *BSD camps in droves.... But I guess it'd be best to just
let it slide ;-o)
My big question is, what new challenges will we face as we become more
popular?Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.One thing we should definitely attempt to do before 7.0 is write our own
license or at least our own copyright in addition to the BSD license,
since none of us (?) actually work at UCB.
I come to pgsql from MySQL. I've not done much of anything with it yet
really, so I should probably keep my mouth shut. But I thought you might
be interested in my perspective. And, after all, you did ask... My hands
on experience with pgsql is minimal, but follows is the sense I get from
the larger community and having lurked on this list for a bit.
The primary "feature" that has me looking at pgsql again is the license. I
like MySQL. The MySQL community is great. I don't like their license,
however, and feel pretty strongly about it. I would counsel against
developing your own. Why reinvent the wheel unless you've got some special
agenda that requires it? I prefer the more liberal BSD, but GPL is fine.
Transaction support is also nice, but secondary to license issues. There
are mysql workarounds in for the absence of transaction support, but it's
hard to get around the license and still be honest.
I would hope that future development continues to focus on reliability,
functionality, and speed. Your work will then speak for itself and more
people will adopt pgsql. I initially ruled it out because of reliability
and speed concerns. The past year has seen much improvement in these
areas, enough to have piqued my interest once again. The *perception*
remains, however, that pgsql still leaves a bit to be desired in the areas
of reliability and maintainability. This needs to be remedied. Like I
said, progress has been mad, but it appears pgsql isn't quite out of the
woods yet.
Well, there's my $0.02. Thanks for your indulgence.
Regards-- Ken
From bouncefilter Sun Dec 26 01:41:14 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA84494
for <pgsql-general@postgresql.org>;
Sun, 26 Dec 1999 01:40:51 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.88.152]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 26 Dec 1999 00:40:21 -0600
Sender: ed
Message-ID: <3865B865.E963E659@austin.rr.com>
Date: Sun, 26 Dec 1999 00:40:37 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <199912260013.TAA29685@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
We don't have roll-forward logging until 7.1, and require vacuum
regularly. Other than that, I don't know of any major issues.
Reliability has always been of primary importance. We wouldn't be where
we are today without reliability.
Here's an idea: How about a web poll on www.postgresql.org to assess the
current state of affairs from the user's perspective? That would have
several advantages. First, it's pretty easy to do. Second, if there are,
in fact, few or no outstanding major reliability issues, that's good to know
and provides firmer footing for feature planning (also great marketing
fodder). Third, it could provide a quantitative baseline for future
comparisons, helping everyone to get warm fuzzies when measurable
improvement appears. Most importantly, it would provide an opportunity for
corrective action if by chance current assumptions are wrong.
Cheers,
Ed Loehr
From bouncefilter Sun Dec 26 01:56:09 1999
Received: from localhost (scrappy@localhost)
by hub.org (8.9.3/8.9.3) with ESMTP id BAA86065;
Sun, 26 Dec 1999 01:56:09 -0500 (EST) (envelope-from scrappy@hub.org)
Date: Sun, 26 Dec 1999 01:56:08 -0500 (EST)
From: "Marc G. Fournier" <scrappy@hub.org>
To: "Clark C. Evans" <clark.evans@manhattanproject.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.LNX.4.10.9912252042540.4979-100000@cauchy.clarkevans.com>
Message-ID: <Pine.BSF.4.21.9912260155210.13180-100000@hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 25 Dec 1999, Clark C. Evans wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?Plug-in Oracle 7 compatibility.
I know we have (and have for awhile) a good deal of Oracle
compatibility...what do you mean by 'Plug-In Oracle 7 compatibility'?
From bouncefilter Sun Dec 26 02:10:24 1999
Received: from localhost (scrappy@localhost)
by hub.org (8.9.3/8.9.3) with ESMTP id CAA90662;
Sun, 26 Dec 1999 02:10:23 -0500 (EST) (envelope-from scrappy@hub.org)
Date: Sun, 26 Dec 1999 02:10:22 -0500 (EST)
From: "Marc G. Fournier" <scrappy@hub.org>
To: Ken <webweaver@rmci.net>
cc: Peter Eisentraut <peter_e@gmx.net>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <4.2.0.58.19991225230239.009748c0@mail.rmci.net>
Message-ID: <Pine.BSF.4.21.9912260159340.13180-100000@hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I don't think the *BSD's have intentionally tried any such thing. You
could possibly have picked up these vibes from certain members of the Open
BSD camp, but I wouldn't extend them to encompass the *BSD community at
large. (And I wonder if I should comment about how Linux people are
migrating to the *BSD camps in droves.... But I guess it'd be best to just
let it slide ;-o)
There are alot of us that are finding that...one of my colleagues comments
to friends that ask him about Linux that "he's matured"...Linux, IMHO, is
the biggest thing that has happened to the "Unix Environment"...but as
Linux increases his market share in leaps and bounds, its also making it
easier for those of us using *BSDs to slip it into our work environments
(I've so far succeeded in migrating 3 co-workers from MicroSoft ->
FreeBSD) ...
I don't really care what OS someone runs, as anyone that has been here for
a long time already knows .. the Linux "fanatics" are just soooo much
easier to pick on, that's all :)
The primary "feature" that has me looking at pgsql again is the
license. I like MySQL. The MySQL community is great. I don't like
their license, however, and feel pretty strongly about it. I would
counsel against developing your own. Why reinvent the wheel unless
you've got some special agenda that requires it? I prefer the more
liberal BSD, but GPL is fine.
I'm against any change in license, except for the upcoming extension of
hte copyright dates to include our work (one of my projects for the new
year)...PostgreSQL will always be open source...BSD vs GPL doesn't change
that...Postgres is a BSD project that we, as a community, have extended to
where it is now...as long as there are ppl developing on it, the source
will always be available too, and I really can't see development really
ever stopping (too many ppl are having too much fun)...
The BSD license has served us perfectly for the past 4+ years, and I
haven't heard, over those years, any argument to the effect that it won't
continue to serve us perfectly for the next 4+ years...
once again. The *perception* remains, however, that pgsql still
leaves a bit to be desired in the areas of reliability and
maintainability. This needs to be remedied. Like I said, progress
has been mad, but it appears pgsql isn't quite out of the woods yet.
I keep hearing the old "reliability" argument...there are alot of us using
PostgreSQL for "mission critical" apps, and haven't seen these
problems. Can you provide more details on this? I'm not doubting that
you are hitting a "little known bug" that makes PostgreSQL unreliable for
you, but without details, we have no way of diagnosing and improving it...
From bouncefilter Sun Dec 26 02:11:48 1999
Received: from localhost (scrappy@localhost)
by hub.org (8.9.3/8.9.3) with ESMTP id CAA90778;
Sun, 26 Dec 1999 02:11:47 -0500 (EST) (envelope-from scrappy@hub.org)
Date: Sun, 26 Dec 1999 02:11:47 -0500 (EST)
From: "Marc G. Fournier" <scrappy@hub.org>
To: Ed Loehr <ELOEHR@austin.rr.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <3865B865.E963E659@austin.rr.com>
Message-ID: <Pine.BSF.4.21.9912260211040.13180-100000@hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 26 Dec 1999, Ed Loehr wrote:
Bruce Momjian wrote:
We don't have roll-forward logging until 7.1, and require vacuum
regularly. Other than that, I don't know of any major issues.
Reliability has always been of primary importance. We wouldn't be where
we are today without reliability.Here's an idea: How about a web poll on www.postgresql.org to assess
the current state of affairs from the user's perspective? That would
have several advantages. First, it's pretty easy to do. Second, if
there are, in fact, few or no outstanding major reliability issues,
that's good to know and provides firmer footing for feature planning
(also great marketing fodder). Third, it could provide a quantitative
baseline for future comparisons, helping everyone to get warm fuzzies
when measurable improvement appears. Most importantly, it would
provide an opportunity for corrective action if by chance current
assumptions are wrong.
Feel like writing it? I can provide you with an account, and database
access, if you want to work on this sort of thing?
From bouncefilter Sun Dec 26 03:01:16 1999
Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [203.96.92.15])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA02067
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 03:00:43 -0500 (EST) (envelope-from john@mwk.co.nz)
Received: from castleanthrax ([210.55.119.13]) by mta4-rme.xtra.co.nz
(InterMail v4.01.01.00 201-229-111) with SMTP
id <19991226080011.UHWL50393.mta4-rme@castleanthrax>
for <pgsql-general@postgreSQL.org>; Sun, 26 Dec 1999 21:00:11 +1300
Message-ID: <002301bf4f77$39884e40$ca5fa8c0@hisdad.org.nz>
From: "john huttley" <john@mwk.co.nz>
To: "PostgreSQL-general" <pgsql-general@postgreSQL.org>
References: <199912260227.VAA01249@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
Date: Sun, 26 Dec 1999 21:00:06 +1300
Organization: MWK Computers
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?
Yes, earlier in the year I was trying to migrate from Pervasive SQL to
posgtres and
came to a screaming halt when it wouldn't do a large view. Exceeded some
sort of internal buffer
or rule area. I dont recall the details, although the mail archive will have
it.
I think that was going into the V7 todo list.
And of course the perenial full (rowset returning) stored procedures with
parameters.
Regards
John
From bouncefilter Sun Dec 26 03:25:15 1999
Received: from mailgw2.prontomail.com (mailgw2.prontomail.com
[209.185.149.198]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA22684
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 03:25:03 -0500 (EST)
(envelope-from brent.wood@blazemail.com)
Received: from prontomail13.prontomail.com (209.185.149.113) by
mailgw2.prontomail.com (NPlex 2.0.123) for
pgsql-general@postgreSQL.org; Sun, 26 Dec 1999 00:17:41 -0800
Received: from web33 (209.185.149.233) by prontomail13.prontomail.com (NPlex
2.0.123) for pgsql-general@postgreSQL.org;
Sun, 26 Dec 1999 00:17:30 -0800
From: "brent wood" <brent.wood@blazemail.com>
Message-Id: <259D7B89B9AB3D1178D20005B823626F@brent.wood.blazemail.com>
Date: Sun, 26 Dec 1999 00:19:56 -0800
X-Priority: Normal
Content-Type: text/plain; charset=ISO-8859-1
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Future of PostgreSQL
X-Mailer: Web Based Pronto
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
My wish list has one major item, removal of the tuple/record limit.
This limit renders the spatial functionality as totally inadequate for any serious use. I like the approach in some RDBMS's where there is a facility for "overflow" data, where the record size may have a basic limit, much as PostgreSQL has, but additional data for a record (tuple) may be stored in secondary "volumes". Configuration of these limits is able to be adjusted dynamically by the DBA to suit the record structure & optimise for useage.
Close to this in priority for my systems are referential integrity (esp foreign keys).
Some user control of index type would be nice also, not so much from a technical perspective, but a users: eg, a "time series" style index where each attr is unique (typically incrementing) & an index suitable for bucket hits, where an attr is indexed but not unique. A good quad-tree would be nice for polygons too....
Summat that would be nice is a "user supplied code" site on the WWW somwhere. (I haven't been able to find such a beast). Even some commercial software companies provide this type of servicefor users, full of disclaimers about the contents of course.
EG: I may well want a user defined function as an addition to SQL functionality to return the distance between two spatial entities (either cartesian or great circle). If there was a repository for such code I could just grab it, of it it wasn't in the repository I could write & upload it...
I believe that some of these are in the pipeline... Can't come too soon :-)
Join AllAdvantage.com and get paid to surf the Web!
Please use my ID (EIS-467) when asked if someone referred you. Thanks!
http://www.alladvantage.com/go.asp?refid=EIS467
-------------------------
Get your own Free E-mail!
http://www.blazemail.com
From bouncefilter Sun Dec 26 04:44:16 1999
Received: from FreeBSD.efsns.com ([210.241.235.250])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA37324
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 04:43:45 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (kevlo.efsns.com [210.241.235.250])
by FreeBSD.efsns.com (8.9.3/8.9.3) with ESMTP id RAA00579;
Sun, 26 Dec 1999 17:42:10 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@@wahoo.com.tw
Message-ID: <3865E2F2.A19CF84E@hello.com.tw>
Date: Sun, 26 Dec 1999 17:42:10 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Berghold <Peter@berghold.net>
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] DBI::Pg for Perl?
References: <19991225.19515200@lc8.skunkworks.berghold.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Berghold wrote:
Hi Folks,
Does anyone out there know of a DBI driver for Postgres for Perl? I
searched CPAN and didn't see one. Maybe I'm looking in the wrong
spot...
It's at :
http://www.perl.com/CPAN-local/modules/by-module/DBD/DBD-Pg-0.93.tar.gz
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Peter L. Berghold Peter@Berghold.Net "Linux renders ships http://www.berghold.net NT renders ships useless...."
- Kevin
From bouncefilter Sun Dec 26 08:35:19 1999
Received: from berghold.net (IDENT:root@cc1008600-a.etntwn1.nj.home.com
[24.3.204.54] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id IAA84422
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 08:34:47 -0500 (EST)
(envelope-from Peter@berghold.net)
Received: from lc8.skunkworks.berghold.net
(IDENT:101@lc8.skunkworks.berghold.net [10.1.1.25])
by berghold.net (8.9.3/8.9.3) with SMTP id IAA09080;
Sun, 26 Dec 1999 08:34:38 -0500
From: Peter Berghold <Peter@berghold.net>
Date: Sun, 26 Dec 1999 13:34:59 GMT
Message-ID: <19991226.13345900@lc8.skunkworks.berghold.net>
Subject: Re: [GENERAL] DBI::Pg for Perl?
To: Kevin Lo <kevlo@hello.com.tw>
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>,
Peter Berghold <Peter@berghold.net>
In-Reply-To: <3865E2F2.A19CF84E@hello.com.tw>
References: <19991225.19515200@lc8.skunkworks.berghold.net>
<3865E2F2.A19CF84E@hello.com.tw>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id IAA84462
Thanks! I was looking in the wrong spot! Did a search of CPAN with
the key DBI::* and didn't see DBD::Pg. DOH!
Building it right now.
Original Message <<<<<<<<<<<<<<<<<<
On 12/26/99, 4:42:10 AM, Kevin Lo <kevlo@hello.com.tw> wrote regarding
Re: [GENERAL] DBI::Pg for Perl?:
Peter Berghold wrote:
Hi Folks,
Does anyone out there know of a DBI driver for Postgres for Perl? I
searched CPAN and didn't see one. Maybe I'm looking in the wrong
spot...
It's at :
http://www.perl.com/CPAN-local/modules/by-module/DBD/DBD-Pg-0.93.tar.gz
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Peter L. Berghold Peter@Berghold.Net "Linux renders ships http://www.berghold.net NT renders ships useless...."
- Kevin
************
From bouncefilter Sun Dec 26 09:02:19 1999
Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA89441
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 09:02:12 -0500 (EST)
(envelope-from sander@steffann.nl)
Received: from ns ([212.187.21.212]) by relay01.chello.nl
(InterMail vK.4.02.00.00 201-232-116 license
c87e1f87faef09851161f072fd7d9a7c)
with SMTP id <19991226140900.EPYN27901.relay01@ns>;
Sun, 26 Dec 1999 15:09:00 +0100
Message-ID: <003a01bf4fa9$bbd307a0$0201010a@chello.nl>
From: "Sander Steffann" <sander@steffann.nl>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"Ed Loehr" <ELOEHR@austin.rr.com>
Cc: "PostgreSQL-general" <pgsql-general@postgreSQL.org>
References: <199912252320.SAA29219@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
Date: Sun, 26 Dec 1999 15:01:40 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Hi,
The 3 greatest technical/engineering challenges: 1) system
reliability & recoverability, 2) system reliability & recoverability,
and 3) system reliability and recoverability.And we don't have a problem in this area, do we?
At the moment, not realy, but a few things would be VERY nice:
- No need for a complete dump/restore on an major upgrade
- A pg_dump that ALWAYS can make a dump that can be restored without editing
it first
(When a user had the access to create databases, creates some, and that
access is removed, the dump can't be restored anymore because it creates the
user without the rights to create databases, but somewhat later tries to
create a database with that user. I hope you understand this... :) I now
create all databases by hand as the superuser, and set the datdba myself.
- A dump program that can dump/restore large objects.
Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot
without any big problems. Just some ideas to make it easier for the
administrator.
And of course, thanks for all the work on PostgreSQL that makes it what it
is now, and a Merry Cristmas!
Sander Steffann.
From bouncefilter Sun Dec 26 09:20:19 1999
Received: from FreeBSD.efsns.com ([210.241.235.250])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA90583
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 09:19:55 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (kevlo.efsns.com [210.241.235.250])
by FreeBSD.efsns.com (8.9.3/8.9.3) with ESMTP id WAA00306;
Sun, 26 Dec 1999 22:19:00 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@@wahoo.com.tw
Message-ID: <386623D4.A2ABF5A6@hello.com.tw>
Date: Sun, 26 Dec 1999 22:19:00 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Berghold <Peter@berghold.net>
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] DBI::Pg for Perl?
References: <19991225.19515200@lc8.skunkworks.berghold.net>
<3865E2F2.A19CF84E@hello.com.tw>
<19991226.13345900@lc8.skunkworks.berghold.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter Berghold wrote:
Thanks! I was looking in the wrong spot! Did a search of CPAN with
the key DBI::* and didn't see DBD::Pg. DOH!
Right. I also couldn't find DBD::Pg if I search that key.
Building it right now.
Good luck,
Kevin.
From bouncefilter Sun Dec 26 10:53:20 1999
Received: from inago.swcp.com (inago.swcp.com [198.59.115.17])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA06212
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 10:52:42 -0500 (EST)
(envelope-from deichert@wrench.com)
Received: from localhost (deichert@localhost)
by inago.swcp.com (8.8.7/8.8.7) with ESMTP id IAA19196
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 08:52:40 -0700 (MST)
X-Authentication-Warning: inago.swcp.com: deichert owned process doing -bs
Date: Sun, 26 Dec 1999 08:52:40 -0700 (MST)
From: Diana Eichert <deichert@wrench.com>
X-Sender: deichert@inago.swcp.com
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.BSF.4.21.9912260159340.13180-100000@hub.org>
Message-ID: <Pine.GSO.4.10.9912260846090.19180-100000@inago.swcp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Howdy
A question, if you still have some code in the source that
originated at Berkeley how do you change the license?
Do you breakout new code from old code and have a different
license for old vs. new code?
I'm against any change in license, except for the upcoming extension of
hte copyright dates to include our work (one of my projects for the new
year)...PostgreSQL will always be open source...BSD vs GPL doesn't change
that...Postgres is a BSD project that we, as a community, have extended to
where it is now...as long as there are ppl developing on it, the source
will always be available too, and I really can't see development really
ever stopping (too many ppl are having too much fun)...The BSD license has served us perfectly for the past 4+ years, and I
haven't heard, over those years, any argument to the effect that it won't
continue to serve us perfectly for the next 4+ years...
Diana Eichert
VP Technical Services
Nothing in Particular at the Moment, Inc.
deichert@wrench.com
From bouncefilter Sun Dec 26 12:40:22 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26242
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 12:39:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA20945;
Sun, 26 Dec 1999 12:39:11 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912261739.MAA20945@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <002301bf4f77$39884e40$ca5fa8c0@hisdad.org.nz> from john huttley
at "Dec 26, 1999 09:00:06 pm"
To: john huttley <john@mwk.co.nz>
Date: Sun, 26 Dec 1999 12:39:11 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?Yes, earlier in the year I was trying to migrate from Pervasive SQL to
posgtres and
came to a screaming halt when it wouldn't do a large view. Exceeded some
sort of internal buffer
or rule area. I dont recall the details, although the mail archive will have
it.I think that was going into the V7 todo list.
We have a plan for large tuples, and Jan is working on it. I am pushing
to see if we can get it in 7.0, but it may have to wait for 7.1. Let's
see what happens.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Dec 26 12:47:22 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26910
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 12:46:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA21170;
Sun, 26 Dec 1999 12:46:10 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912261746.MAA21170@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <003a01bf4fa9$bbd307a0$0201010a@chello.nl> from Sander Steffann
at "Dec 26, 1999 03:01:40 pm"
To: Sander Steffann <sander@steffann.nl>
Date: Sun, 26 Dec 1999 12:46:10 -0500 (EST)
CC: Ed Loehr <ELOEHR@austin.rr.com>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Hi,
The 3 greatest technical/engineering challenges: 1) system
reliability & recoverability, 2) system reliability & recoverability,
and 3) system reliability and recoverability.And we don't have a problem in this area, do we?
At the moment, not realy, but a few things would be VERY nice:
- No need for a complete dump/restore on an major upgrade
pg_upgrade allows us to do that _when_ we don't change the on-disk
format of the data. We did not do that in 6.4, but did do that in 6.5.
I think 7.0 also will have a change. Not much we can do about that.
When we stop adding major features, pg_upgrade can be used for every
release. :-)
- A pg_dump that ALWAYS can make a dump that can be restored without editing
it first
(When a user had the access to create databases, creates some, and that
access is removed, the dump can't be restored anymore because it creates the
user without the rights to create databases, but somewhat later tries to
create a database with that user. I hope you understand this... :) I now
create all databases by hand as the superuser, and set the datdba myself.
We are working on dumping in OID order. That should solve that problem.
We only came up with that solution recently.
- A dump program that can dump/restore large objects.
Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot
without any big problems. Just some ideas to make it easier for the
administrator.
We are going to do very long tuples in 7.0 and 7.1. This may make large
objects obsolete.
And of course, thanks for all the work on PostgreSQL that makes it what it
is now, and a Merry Cristmas!
Oh, yes, Merry Christmas to everyone too.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Dec 26 12:48:22 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA27007
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 12:47:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA21215;
Sun, 26 Dec 1999 12:47:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912261747.MAA21215@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.GSO.4.10.9912260846090.19180-100000@inago.swcp.com> from
Diana Eichert at "Dec 26, 1999 08:52:40 am"
To: Diana Eichert <deichert@wrench.com>
Date: Sun, 26 Dec 1999 12:47:43 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Howdy
A question, if you still have some code in the source that
originated at Berkeley how do you change the license?Do you breakout new code from old code and have a different
license for old vs. new code?
Just add it to the top. If someone wants it without oure name on it,
they have to get the tarball from Berkeley.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Dec 26 12:42:22 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA26415
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 12:41:45 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
MAA32477; Sun, 26 Dec 1999 12:49:02 -0500
Date: Sun, 26 Dec 1999 17:49:02 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912260227.VAA01249@candle.pha.pa.us>
Message-ID: <Pine.LNX.3.96.991226174444.25654k-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 25 Dec 1999, Bruce Momjian wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?Plug-in Oracle 7 compatibility.
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?
tablespace support ( which isnt a trivial task ), groups ( pgsql has this
sort of functionality already, but i dont think its to the extent that
Oracle does ), some additional grants ( 'grant connect to' ), 'alter table
<table> add constraint <constraint definition>'...
tablespace support would put pgsql soooo far ahead of most other rdbmses.
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Sun Dec 26 18:47:26 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA99453
for <pgsql-general@postgresql.org>;
Sun, 26 Dec 1999 18:46:56 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id SAA03273
for <pgsql-general@postgresql.org>; Sun, 26 Dec 1999 18:44:22 -0500
Sender: mascarm@mascari.com
Message-ID: <38666255.BB8DC543@mascari.com>
Date: Sun, 26 Dec 1999 13:45:41 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: Re: Reliabilty, was [GENERAL] Future of PostgreSQL
References: <Pine.BSF.4.21.9912260159340.13180-100000@hub.org>
<386688D8.C714BDD1@e-softinc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Reinke wrote:
1) Up front, I'll state that we use 6.3, so a number of
the technical glitches may have been solved since...
6.3 is unbelievably old. Perhaps you weren't getting responses since most
people don't use versions of PostgreSQL that old? I know I tend not to respond
to posts about versions that old. Perhaps that's wrong...
4) We could never get any answers to reliability related
questions answered by any of the development team or
by anyone else on the various postgres discussion groups. We
would ask the question, post the relevant error log
message, describe the scenario we thought cause the
problem, and it's as if the question disappeared into
a black hole.Believe it or not, it's actually item #4 that annoys us
the most. Work arounds are a pain, but at least they
accomplish something - the problem no longer occurs.
But when you bang your head against a problem, and no
one seems to have heard of the issue ever, or even
acknowledges the post in question, it definitely
detracts from the value of the product.Case in point: a long time ago we found a problem affecting
insertions into the database - doing many inserts (I believe
where the record already existed) caused a memory leak when
the insert was rejected due to duplicate index entries.
This forced us to inject a drop/reconnect sequence into the
code to avoid using up all of our memory. We asked about
the problem - no response; we posted the bug in the PR
database - no response; 6 months later, we saw someone
else ask the exact same question (not sure of release,
i thought he was on 6.4, but don't hold me on that one).It's that kind of non-responsiveness that in our mind makes
the db reliability an issue.
The following are fixes relating to problems you described since 6.3:
Bug Fixes
---------
Fix for a tiny memory leak in PQsetdb/PQfinish(Bryan)
Fix for buffer leaks in large object calls(Pascal)
Fix memory leak in libpgtcl's pg_select(Constantin)
libpq memory overrun fix
pg_dump fixes for memory leak, inheritance constraints, layout change
Fix memory overruns(Tatsuo)
Memory overrun cleanups(Tatsuo)
Drop buffers before destroying database files(Bruce)
Fix for memory leak in executor with fjIsNull
Fix for aggregate memory leaks(Erik Riedel)
Fix for memory leak in failed queries(Tom)
Fix vacuum's memory consumption(Hiroshi,Tatsuo)
Reduce the total memory consumption of vacuum(Tom)
This is to re-use space on index pages freed by vacuum(Vadim)
Repair incorrect cleanup of heap memory allocation during transaction
abort(Tom)
These are just the ones I pulled from the change logs on www.postgresql.org
related to memory. There are hundreds of other fixes listed as well. I realize
that the answer of "upgrade" to problems you are experiencing is not a
definitive solution, since the bugs might very well be present in current
releases. For example, I can guess its still going to take quite a while for
vacuum to remove 600,000 rows from your database. Some have suggested (and I
agree) that vacuum ought to:
1) Estimate the number of rows to be removed
2) If over a certain threshold:
A. drop all indexes on tables
B. vacuum away dead tuples
C. rebuild indexes
Having said that, I must say that my general impression has been that the
major code developers took over code which was probably 50% bug-ridden garbage
and worked away at it with each release performing MAJOR bug fixes. Just read
Bruce Momjian's HISTORY document to get an idea of the monumental tasks they
have undertaken. I normally don't upgrade other software at each minor release
-- but I do with PostgreSQL. You can tell that they've made huge advances
against the otherwise, uncharted, bug-ridden pieces of 1980's Berkley code...
They're getting closer and closer to what one might call "robustness" at an
accelerated pace, so keep the faith! :-)
Merry Christmas,
Mike Mascari
P.S.: We've been running 6.5beta in a production envirnoment with similar
record counts as the ones you've described and only run into trouble twice.
Once was due to aborting a transaction which contained DDL statements, and the
other was, what I believe, a problem with the 2.0.36 Linux kernel. I hope you
can read into this that our eagerness to get to 6.5 meant using 6.5 beta in
production over using 6.4.2....
From bouncefilter Sun Dec 26 19:00:26 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA00677
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 18:59:44 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id SAA03290;
Sun, 26 Dec 1999 18:57:09 -0500
Sender: mascarm@mascari.com
Message-ID: <3866654E.17194711@mascari.com>
Date: Sun, 26 Dec 1999 13:58:23 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris Carbaugh <cjdesigns@sprintmail.com>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Import table from MS Access?
References: <38669E3B.D369BFEB@sprintmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Chris Carbaugh wrote:
What is the best way to import a table from Microsoft Access 2000?
I was able to export to a text file from access, but this was only the
data. Can I export/import the table definition as well?I have been using pgaccess to administer my DB. It seems I can't tell
it to import a comma delimited file? Is there any way around this?Any help is greatly appreciated.
Chris
One way is to use the PostgreSQL ODBC driver from Insight (search
yahoo.com for: postgres Insight ODBC), and use the File->Export function
in Access to export the tables to PostgreSQL. There are a few problems
with this method, though, if I recall correctly:
1. Table and field names will be case-sensitive, so if you have a table
in Access called Employees with a field HireDate, then in PostgreSQL,
you must refer to this as "Employees"."HireDate", not employees.hiredate,
although you could programmatically rename the tables by performing an
update on pg_class and pg_attribute.
2. Column constraints are not exported. If I recall (its been some time),
column constraints are not exported from Access when the tables are
created. And, unfortunately, there's no easy way to add them in
PostgreSQL using an ALTER TABLE statement.
Nevertheless, it might be easier to perform the export in Access using
ODBC, pg_dump the database to a text file, perform whatever cleanup is
necessary, and then reimport.
Also, I rember that there's a PostgreSQL upsizing tool somewhere that
does all this stuff for you. But for the life of me I can't remember
where...
Hope that helps,
Mike Mascari
From bouncefilter Sun Dec 26 15:54:24 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA67587
for <pgsql-general@postgresql.org>;
Sun, 26 Dec 1999 15:53:33 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.57.84]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 26 Dec 1999 14:44:01 -0600
Sender: ed
Message-ID: <3866803B.2A697276@austin.rr.com>
Date: Sun, 26 Dec 1999 14:53:15 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Marc G. Fournier" <scrappy@hub.org>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <Pine.BSF.4.21.9912260211040.13180-100000@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Marc G. Fournier" wrote:
On Sun, 26 Dec 1999, Ed Loehr wrote:
Bruce Momjian wrote:
We don't have roll-forward logging until 7.1, and require vacuum
regularly. Other than that, I don't know of any major issues.
Reliability has always been of primary importance. We wouldn't be where
we are today without reliability.Here's an idea: How about a web poll on www.postgresql.org to assess
the current state of affairs from the user's perspective? That would
have several advantages. First, it's pretty easy to do. Second, if
there are, in fact, few or no outstanding major reliability issues,
that's good to know and provides firmer footing for feature planning
(also great marketing fodder). Third, it could provide a quantitative
baseline for future comparisons, helping everyone to get warm fuzzies
when measurable improvement appears. Most importantly, it would
provide an opportunity for corrective action if by chance current
assumptions are wrong.Feel like writing it? I can provide you with an account, and database
access, if you want to work on this sort of thing?
Sure. Quite swamped right now, but should be able to have something in
January. Please set up an account with DB access...
Cheers,
Ed Loehr
From bouncefilter Sun Dec 26 16:30:25 1999
Received: from co832821-a (cogeco-91-40.cgocable.net [24.141.91.40])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA73737
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 16:29:27 -0500 (EST)
(envelope-from reinke@e-softinc.com)
Received: from e-softinc.com ([10.1.1.4])
by co832821-a (8.8.7/8.8.7) with ESMTP id QAA03220
for <pgsql-general@postgreSQL.org>; Sun, 26 Dec 1999 16:29:25 -0500
Message-ID: <386688D8.C714BDD1@e-softinc.com>
Date: Sun, 26 Dec 1999 16:30:00 -0500
From: Thomas Reinke <reinke@e-softinc.com>
Organization: E-Soft Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Reliabilty, was [GENERAL] Future of PostgreSQL
References: <Pine.BSF.4.21.9912260159340.13180-100000@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
once again. The *perception* remains, however, that pgsql still
leaves a bit to be desired in the areas of reliability and
maintainability. This needs to be remedied. Like I said, progress
has been mad, but it appears pgsql isn't quite out of the woods yet.I keep hearing the old "reliability" argument...there are alot of us using
PostgreSQL for "mission critical" apps, and haven't seen these
problems. Can you provide more details on this? I'm not doubting that
you are hitting a "little known bug" that makes PostgreSQL unreliable for
you, but without details, we have no way of diagnosing and improving it...************
As an org that uses postgres as _THE_ SQL database for our activities,
I'll provide some details about our reliability problems:
1) Up front, I'll state that we use 6.3, so a number of
the technical glitches may have been solved since...
2) We could never reliably use multiple tasks accessing
the database at the same time. I could _reliably_
crash a back-end (and thus cause all back-ends to quit)
by having 3-4 tasks actively doing inserts, updates,
and selects. (Our workaround - a db semaphore built
into our apps that allow only single tasks at a time
to access the db)
3) We cannot use vacuum. Why? Because it takes indefinitely
longer to vacuum a database than it does to dump and
reload. An example case: a table declared as
fld1 varchar(80), fld2 int4, fld3 varchar(32),
fld4 varchar(80), fld5 varchar(20)
with indices
unique index index1 on table(fld1, fl2)
index index on table(fld3)
We have NEVER been able to successfully vacuum the
table after only one day of churn through the database,
churn being defined as 600,000 updates of fld3,fld4 and fld5
in a table with 2 million rows. (Heap assertion error given,
on a system with 128Meg Ram, and 96Meg swap space.)
4) We could never get any answers to reliability related
questions answered by any of the development team or
by anyone else on the various postgres discussion groups. We
would ask the question, post the relevant error log
message, describe the scenario we thought cause the
problem, and it's as if the question disappeared into
a black hole.
Believe it or not, it's actually item #4 that annoys us
the most. Work arounds are a pain, but at least they
accomplish something - the problem no longer occurs.
But when you bang your head against a problem, and no
one seems to have heard of the issue ever, or even
acknowledges the post in question, it definitely
detracts from the value of the product.
Case in point: a long time ago we found a problem affecting
insertions into the database - doing many inserts (I believe
where the record already existed) caused a memory leak when
the insert was rejected due to duplicate index entries.
This forced us to inject a drop/reconnect sequence into the
code to avoid using up all of our memory. We asked about
the problem - no response; we posted the bug in the PR
database - no response; 6 months later, we saw someone
else ask the exact same question (not sure of release,
i thought he was on 6.4, but don't hold me on that one).
It's that kind of non-responsiveness that in our mind makes
the db reliability an issue.
Now don't get me wrong - I realize that you get what you
pay for. But I believe in at the very least responding
to user's questions/problems. A simple "We've seen/not seen
that problem before, and haven't had the time to track down
the root cause and fix it." would have been much
preferable, and gone a long way to making us feel that
problems are being addressed for subsequent releases.
Cheers, Thomas
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
From bouncefilter Sun Dec 26 17:06:25 1999
Received: from kiln.isn.net (root@kiln.isn.net [198.167.161.1])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA82476
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 17:06:19 -0500 (EST)
(envelope-from ctassell@isn.net)
Received: from niki (dunken07.isn.net [198.167.161.33])
by kiln.isn.net (8.9.3/8.9.3) with ESMTP id SAA04014
for <pgsql-general@postgreSQL.org>; Sun, 26 Dec 1999 18:06:16 -0400
Message-Id: <4.2.0.58.19991226175253.009ab960@mailer.isn.net>
X-Sender: ctassell@mailer.isn.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sun, 26 Dec 1999 18:06:29 -0400
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
From: Charles Tassell <ctassell@isn.net>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912260227.VAA01249@candle.pha.pa.us>
References: <Pine.LNX.4.10.9912252042540.4979-100000@cauchy.clarkevans.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 10:27 PM 12/25/99, Bruce Momjian wrote:
[snip]
Plug-in Oracle 7 compatibility.
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?
Replication would be nice, or some other form of clustering so the load can
be easily split among multiple PostGres servers. My personal pet peeves
are the difficulty of the backup/restore process (well, it's not really
difficult, it just takes a while) and the 8k query limit. Also, the
ability to restrict CREATE [ TABLE | INDEX | SEQUENCE ...] would be nice.
From bouncefilter Sun Dec 26 17:28:25 1999
Received: from www.inx.de (exim@www.inx.de [195.21.255.251])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA84241
for <pgsql-general@postgresql.org>;
Sun, 26 Dec 1999 17:27:58 -0500 (EST) (envelope-from plexus@snafu.de)
Received: from n241-94.berlin.snafu.de ([195.21.241.94] helo=snafu.de)
by www.inx.de with smtp (Exim 3.02 #1)
id 122M8p-00069m-00; Sun, 26 Dec 1999 23:27:56 +0100
Date: Sun, 26 Dec 1999 23:30:44 +0100
From: Oliver Fischer <plexus@snafu.de>
Reply-To: Oliver Fischer <plexus@snafu.de>
To: pgman@candle.pha.pa.us
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Future of PostgreSQL
X-Mailer: Fischer Oliver's registered AK-Mail 3.0b [ger]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E122M8p-00069m-00@www.inx.de>
I believe we are adding Oracle compatibility as possible. We
are
working on write-ahead log, long tuples, foreign keys, and
outer
joins.
Anything else?
Yes, PL/SQL compatibility would be nice. ;-)
Bye,
Oliver
#--{ plexus@snafu.de }----------------------------
Oliver Fischer, Gleimstrasse 59, 10437 Berlin, Germany
From bouncefilter Sun Dec 26 17:59:25 1999
Received: from raven.a001.sprintmail.com (raven.prod.itd.earthlink.net
[209.178.63.9]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA89821
for <pgsql-general@postgresql.org>;
Sun, 26 Dec 1999 17:59:12 -0500 (EST)
(envelope-from cjdesigns@sprintmail.com)
Received: from sprintmail.com (chris@1Cust95.tnt4.york.pa.da.uu.net
[63.17.232.95])
by raven.a001.sprintmail.com (8.8.7/8.8.5) with ESMTP id OAA11263
for <pgsql-general@postgresql.org>;
Sun, 26 Dec 1999 14:59:10 -0800 (PST)
Sender: chris@sprintmail.com
Message-ID: <38669E3B.D369BFEB@sprintmail.com>
Date: Sun, 26 Dec 1999 18:01:15 -0500
From: Chris Carbaugh <cjdesigns@sprintmail.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: Import table from MS Access?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
What is the best way to import a table from Microsoft Access 2000?
I was able to export to a text file from access, but this was only the
data. Can I export/import the table definition as well?
I have been using pgaccess to administer my DB. It seems I can't tell
it to import a comma delimited file? Is there any way around this?
Any help is greatly appreciated.
Chris
From bouncefilter Sun Dec 26 21:13:27 1999
Received: from co832821-a (cogeco-91-40.cgocable.net [24.141.91.40])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA29689
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 21:12:55 -0500 (EST)
(envelope-from reinke@e-softinc.com)
Received: from e-softinc.com ([10.1.1.4])
by co832821-a (8.8.7/8.8.7) with ESMTP id VAA04493;
Sun, 26 Dec 1999 21:12:51 -0500
Message-ID: <3866CB46.C6E96587@e-softinc.com>
Date: Sun, 26 Dec 1999 21:13:26 -0500
From: Thomas Reinke <reinke@e-softinc.com>
Organization: E-Soft Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Mascari <mascarm@mascari.com>
CC: pgsql-general@postgreSQL.org
Subject: Re: Reliabilty, was [GENERAL] Future of PostgreSQL
References: <Pine.BSF.4.21.9912260159340.13180-100000@hub.org>
<386688D8.C714BDD1@e-softinc.com> <38666255.BB8DC543@mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mike Mascari wrote:
Thomas Reinke wrote:
1) Up front, I'll state that we use 6.3, so a number of
the technical glitches may have been solved since...6.3 is unbelievably old. Perhaps you weren't getting responses since most
people don't use versions of PostgreSQL that old? I know I tend not to respond
to posts about versions that old. Perhaps that's wrong...
We have for a long time not posted, (since 6.4 was out more than 2-3
months)
because we knew that we'd be told to upgrade. When we posted, 6.3
was current...
Having said that, I must say that my general impression has been that the
major code developers took over code which was probably 50% bug-ridden garbage
and worked away at it with each release performing MAJOR bug fixes. Just read
Bruce Momjian's HISTORY document to get an idea of the monumental tasks they
have undertaken. I normally don't upgrade other software at each minor release
-- but I do with PostgreSQL. You can tell that they've made huge advances
against the otherwise, uncharted, bug-ridden pieces of 1980's Berkley code...
They're getting closer and closer to what one might call "robustness" at an
accelerated pace, so keep the faith! :-)
Yup...and they're doing a damn good job, as far as I'm concerned. (Else
I
would have switched a long time ago.) My post here was simply to point
out
what our perception was on the robustness issue, and that is
that although the code was a problem, it was _not_ the major problem...
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
From bouncefilter Mon Dec 27 03:14:31 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id DAA81811
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 03:13:53 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id DAA04076;
Mon, 27 Dec 1999 03:11:11 -0500
Sender: mascarm@mascari.com
Message-ID: <3866D920.DC726515@mascari.com>
Date: Sun, 26 Dec 1999 22:12:32 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Howie <caffeine@toodarkpark.org>
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] pgsql 7.x...
References: <Pine.LNX.3.96.991227052453.25654m-100000@rabies.toodarkpark.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Howie wrote:
will this function/index problem be fixed in 7.x ?
ircbot=> explain select * from logins where dttime = NOW();
NOTICE: QUERY PLAN:Seq Scan on logins (cost=33530.89 rows=71043 width=52)
EXPLAIN
ircbot=> explain select * from logins where dttime = NOW()::datetime;
NOTICE: QUERY PLAN:Seq Scan on logins (cost=33530.89 rows=71043 width=52)
EXPLAIN
ircbot=> select now();
now
----------------------
1999-12-27 00:23:17-05
(1 row)ircbot=> explain select * from logins where dttime='1999-12-27
00:23:17-05'::datetime;
NOTICE: QUERY PLAN:Index Scan using logins_dttime_idx on logins (cost=2.54 rows=11 width=52)
EXPLAIN
( logins actually has 755,728 rows right now )
I realize this doesn't actually answer your question, but you could always
do:
SELECT * from logins WHERE dttime='now';
Example:
emptoris=> explain select * from sales where saledate = now();
NOTICE: QUERY PLAN:
Seq Scan on sales (cost=75556.68 rows=134187 width=140)
EXPLAIN
emptoris=> select 'now'::datetime;
?column?
----------------------------
Mon Dec 27 03:09:58 1999 EST
(1 row)
emptoris=> explain select * from sales where saledate = 'now'::datetime;
NOTICE: QUERY PLAN:
Index Scan using k_sales4 on sales (cost=2.80 rows=17 width=140)
EXPLAIN
emptoris=> explain select * from sales where saledate='now';
NOTICE: QUERY PLAN:
Index Scan using k_sales4 on sales (cost=2.80 rows=17 width=140)
EXPLAIN
emptoris=>
Hope that helps,
Mike Mascari
From bouncefilter Sun Dec 26 22:40:28 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA45306
for <pgsql-general@postgreSQL.org>;
Sun, 26 Dec 1999 22:39:59 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-17.r15.ncbrvd.InfoAve.Net [206.74.232.147])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id WAA14931;
Sun, 26 Dec 1999 22:39:45 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: "Marc G. Fournier" <scrappy@hub.org>,
"Clark C. Evans" <clark.evans@manhattanproject.com>
Subject: Re: [GENERAL] Future of PostgreSQL
Date: Sun, 26 Dec 1999 22:18:54 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
References: <Pine.BSF.4.21.9912260155210.13180-100000@hub.org>
In-Reply-To: <Pine.BSF.4.21.9912260155210.13180-100000@hub.org>
MIME-Version: 1.0
Message-Id: <99122622434800.00550@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit
On Sun, 26 Dec 1999, Marc G. Fournier wrote:
On Sat, 25 Dec 1999, Clark C. Evans wrote:
Plug-in Oracle 7 compatibility.
I know we have (and have for awhile) a good deal of Oracle
compatibility...what do you mean by 'Plug-In Oracle 7 compatibility'?
Plug in Oracle compatibility would mean being able to drop a PostgreSQL server
as a replacement to an Oracle server and not having to reconfigure any clients,
rewrite any SQL, and basically not even know that the database server has been
changed.
I personally don't think that 100% drop-in Oracle Compatibility is a good goal
-- see Philip Greenspun's Oracle Tips page at
http://photo.net/wtr/oracle-tips.html. He also has some real good points
about LONG types and oracle CLOBs -- tips that are very worth reading, IMO.
I want my long texts to be transparent to my tcl code -- I want to index them
for speed, and I want full functionality -- I don't want CLOBS (a takeoff on
Postgres/Illustra large objects, IIANM).
....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Dec 27 00:19:29 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA62525
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 00:18:35 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
AAA01449; Mon, 27 Dec 1999 00:26:40 -0500
Date: Mon, 27 Dec 1999 05:26:40 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
cc: caffeine@toodarkpark.org
Subject: pgsql 7.x...
Message-ID: <Pine.LNX.3.96.991227052453.25654m-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
will this function/index problem be fixed in 7.x ?
ircbot=> explain select * from logins where dttime = NOW();
NOTICE: QUERY PLAN:
Seq Scan on logins (cost=33530.89 rows=71043 width=52)
EXPLAIN
ircbot=> explain select * from logins where dttime = NOW()::datetime;
NOTICE: QUERY PLAN:
Seq Scan on logins (cost=33530.89 rows=71043 width=52)
EXPLAIN
ircbot=> select now();
now
----------------------
1999-12-27 00:23:17-05
(1 row)
ircbot=> explain select * from logins where dttime='1999-12-27
00:23:17-05'::datetime;
NOTICE: QUERY PLAN:
Index Scan using logins_dttime_idx on logins (cost=2.54 rows=11 width=52)
EXPLAIN
( logins actually has 755,728 rows right now )
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Mon Dec 27 04:31:32 1999
Received: from sopacsun.sopac.org.fj (sopacsun.sopac.org.fj [202.62.0.129])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA37037
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 04:30:35 -0500 (EST)
(envelope-from franck@sopac.org.fj)
Received: from sopac.org.fj (IDENT:root@[202.62.1.23])
by sopacsun.sopac.org.fj (8.9.3/8.8.7) with ESMTP id VAA20332
for <pgsql-general@postgreSQL.org>; Mon, 27 Dec 1999 21:37:59 +1300
Sender: root@sopacsun.sopac.org.fj
Message-ID: <38673260.1F4DE74E@sopac.org.fj>
Date: Mon, 27 Dec 1999 22:33:20 +1300
From: franck <franck@sopac.org.fj>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-22mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <Pine.BSF.4.21.9912260155210.13180-100000@hub.org>
<99122622434800.00550@lorc.wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well,
I like to see replication, at least snapshot type, and later merge type...
Snapshot should allow load balancing while querying db, and allow distributed
web/db server. The replication should work over LAN/WAN and snailmail. The
replication shouldn't be dependent of a transport/network config.
Also, some XML import/export routine to import and export to tables...
Relationships should be hardcoded in the database.
Also, i'm not sure if it is part of current version, but we should be able to
alter a field definition in a table without having to drop the table...
Franck
franck@sopac.org.fj
From bouncefilter Mon Dec 27 04:38:33 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA39527
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 04:37:22 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
EAA02349; Mon, 27 Dec 1999 04:45:16 -0500
Date: Mon, 27 Dec 1999 09:45:16 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: Mike Mascari <mascarm@mascari.com>
cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] pgsql 7.x...
In-Reply-To: <3866D920.DC726515@mascari.com>
Message-ID: <Pine.LNX.3.96.991227092401.1580A-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 26 Dec 1999, Mike Mascari wrote:
Howie wrote:
will this function/index problem be fixed in 7.x ?
ircbot=> explain select * from logins where dttime = NOW();
[SNIP]
emptoris=> explain select * from sales where saledate = 'now'::datetime;
NOTICE: QUERY PLAN:Index Scan using k_sales4 on sales (cost=2.80 rows=17 width=140)
EXPLAIN
emptoris=> explain select * from sales where saledate='now';
NOTICE: QUERY PLAN:Index Scan using k_sales4 on sales (cost=2.80 rows=17 width=140)
[SNIP]
not really; just confuses me a bit more. is 'now()' not the same
datatype as 'now' ?
ircbot=> select now(),'now'::datetime,now()::datetime;
now |?column? |datetime
----------------------+----------------------------+----------------------------
1999-12-27 04:25:35-05|Mon Dec 27 04:25:35 1999 EST|Mon Dec 27 04:25:35 1999 EST
(1 row)
ircbot=> explain select * from logins where dttime = now()::datetime;
Seq Scan on logins (cost=33530.89 rows=71043 width=52)
ircbot=> explain select * from logins where dttime = 'now'::datetime;
Index Scan using logins_dttime_idx on logins (cost=2.54 rows=11 width=52)
ircbot=> select now()::datetime = 'now'::datetime;
?column?
--------
t
isnt 'NOW()' supposed to return a datetime by default? regardless,
shouldnt 'now()::datetime' be a datetime ? if so, why isnt my index on
dttime being used when its a direct comparison ?
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Mon Dec 27 05:00:32 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA43034
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 05:00:24 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id EAA05016;
Mon, 27 Dec 1999 04:57:41 -0500
Message-ID: <38673867.87B7B1EE@mascari.com>
Date: Mon, 27 Dec 1999 04:59:03 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Howie <caffeine@toodarkpark.org>
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] pgsql 7.x...
References: <Pine.LNX.3.96.991227092401.1580A-100000@rabies.toodarkpark.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Howie wrote:
...[other stuff]...
ircbot=> select now(),'now'::datetime,now()::datetime;
now |?column? |datetime
----------------------+----------------------------+----------------------------
1999-12-27 04:25:35-05|Mon Dec 27 04:25:35 1999 EST|Mon Dec 27 04:25:35 1999 EST
(1 row)ircbot=> explain select * from logins where dttime = now()::datetime;
Seq Scan on logins (cost=33530.89 rows=71043 width=52)ircbot=> explain select * from logins where dttime = 'now'::datetime;
Index Scan using logins_dttime_idx on logins (cost=2.54 rows=11 width=52)ircbot=> select now()::datetime = 'now'::datetime;
?column?
--------
tisnt 'NOW()' supposed to return a datetime by default? regardless,
shouldnt 'now()::datetime' be a datetime ? if so, why isnt my index on
dttime being used when its a direct comparison ?
My guess is that the optimizer is viewing now() as a
function which initially cannot be reduced to a constant and
therefore cannot be used for an index scan. Alternatively
'now' is a constant expression which can be coerced before
the index scan to a datetime and thus can be used. I *think*
PostgreSQL came to this point to support the following:
sd=> create table example (
sd-> id int4 not null,
sd-> dttime datetime not null default 'now');
CREATE
sd=> insert into example (id) values (0);
INSERT 40107 1
sd=> insert into example (id) values (1);
INSERT 40108 1
sd=> select * from example;
id|dttime
--+----------------------------
0|Mon Dec 27 04:50:29 1999 EST
1|Mon Dec 27 04:50:29 1999 EST
(2 rows)
Notice that using 'now', having been reduced to the current
date, inserts the creation time of the table into every
record. This is probably not what the user intended. But
with now():
sd=> create table example (
sd-> id int4 not null,
sd-> dttime datetime not null default now());
CREATE
sd=> insert into example (id) values (0);
INSERT 40120 1
sd=> insert into example (id) values (1);
INSERT 40121 1
sd=> select * from example;
id|dttime
--+----------------------------
0|Mon Dec 27 04:52:05 1999 EST
1|Mon Dec 27 04:52:10 1999 EST
(2 rows)
Since now() cannot get reduced to a constant expression, it
allows the default clause of CREATE TABLE to function
properly. I suppose that was the reasoning behind the
difference...
Mike Mascari
From bouncefilter Mon Dec 27 05:43:33 1999
Received: from eureka.etf.ee (eureka.etf.ee [193.40.96.246])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA55472
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 05:43:21 -0500 (EST) (envelope-from tom@etf.ee)
Received: from eureka.etf.ee (eureka [193.40.96.242] (may be forged))
by eureka.etf.ee (8.8.8+Sun/8.8.8) with SMTP id MAA22659
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 12:42:42 +0200 (EET)
Message-Id: <199912271042.MAA22659@eureka.etf.ee>
Date: Mon, 27 Dec 1999 12:42:42 +0200 (EET)
From: Toomas Tamme <tom@etf.ee>
Reply-To: Toomas Tamme <tom@etf.ee>
Subject: compile problem
To: pgsql-general@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 1qVUSF31UIaj7Mr4EXmbNQ==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc
hi
source version postgresql-6.5.3
gcc --version
2.95.2
sparc-sun-solaris2.6
gives error like this:
gcc -I../../include -I../../backend -Wall -Wmissing-prototypes -DFRONTEND
-fPIC -c pqsignal.c -o pqsignal.o
ar crs libpq.a fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o
dllist.o pqsignal.o
ranlib libpq.a
ld -G -o libpq.so.2.0 fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o
fe-lobj.o dllist.o pqsignal.o -lcrypt -ldl -lsocket -lresolv -lnsl -lm -lc
make[2]: *** [libpq.so.2.0] Abort (core dumped)
make[2]: *** Deleting file `libpq.so.2.0'
make[2]: Leaving directory
`/local1/usr/pgsql/postgresql-6.5.3/src/interfaces/libpq'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/local1/usr/pgsql/postgresql-6.5.3/src/interfaces'
make: *** [all] Error 2
how to fix?
tom
From bouncefilter Mon Dec 27 06:50:34 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA67469
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 06:50:18 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA06655;
Mon, 27 Dec 1999 12:33:52 +0100
Date: Mon, 27 Dec 1999 12:33:52 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Sander Steffann <sander@steffann.nl>, Ed Loehr <ELOEHR@austin.rr.com>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912261746.MAA21170@candle.pha.pa.us>
Message-ID: <Pine.LNX.3.96.991227121303.6398B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 26 Dec 1999, Bruce Momjian wrote:
- A dump program that can dump/restore large objects.
Don't get me wrong. I'm not complaining, and we work with PostgreSQL a lot
without any big problems. Just some ideas to make it easier for the
administrator.We are going to do very long tuples in 7.0 and 7.1. This may make large
objects obsolete.
You can try for LO dump:
ftp://ftp2.zf.jcu.cz/users/zakkr/pg/pg_dumplo-0.0.3.tar.gz
I write this program for my private project, but I can continue in this
program development if it is interesting for more PG's uses. (Or add it to
contrib?)
..But as Bruce say, LO API is obsolete. But we don't forget: now exist
application which use LO and rewrite this app. to standard-tuple version
will of long duration - good LO support must be in more next PgSQL
versions too.
Karel
----------------------------------------------------------------------
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------
From bouncefilter Mon Dec 27 06:36:34 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA65630
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 06:35:46 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id GAA05854;
Mon, 27 Dec 1999 06:32:52 -0500
Message-ID: <38674EB6.845C5A71@mascari.com>
Date: Mon, 27 Dec 1999 06:34:14 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Toomas Tamme <tom@etf.ee>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] compile problem
References: <199912271042.MAA22659@eureka.etf.ee>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Toomas Tamme wrote:
hi
source version postgresql-6.5.3
gcc --version
2.95.2
sparc-sun-solaris2.6gives error like this:
gcc -I../../include -I../../backend -Wall -Wmissing-prototypes -DFRONTEND
-fPIC -c pqsignal.c -o pqsignal.o
ar crs libpq.a fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o
dllist.o pqsignal.o
ranlib libpq.a
ld -G -o libpq.so.2.0 fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o
fe-lobj.o dllist.o pqsignal.o -lcrypt -ldl -lsocket -lresolv -lnsl -lm -lc
make[2]: *** [libpq.so.2.0] Abort (core dumped)
make[2]: *** Deleting file `libpq.so.2.0'
make[2]: Leaving directory
`/local1/usr/pgsql/postgresql-6.5.3/src/interfaces/libpq'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/local1/usr/pgsql/postgresql-6.5.3/src/interfaces'
make: *** [all] Error 2how to fix?
tom
Gee. That looks like a bug in your linker, ld. If that is
also GNU, you should report it. According to the GNU ld info
page:
Have you found a bug?
=====================
If you are not sure whether you have found a bug, here
are some
guidelines:
* If the linker gets a fatal signal, for any input
whatever, that is
a `ld' bug. Reliable linkers never crash.
...
How to report bugs
==================
A number of companies and individuals offer support for
GNU
products. If you obtained `ld' from a support organization,
we
recommend you contact that organization first.
You can find contact information for many support
companies and
individuals in the file `etc/SERVICE' in the GNU Emacs
distribution.
In any event, we also recommend that you send bug reports
for `ld'
to `bug-gnu-utils@gnu.org'.
Hope that helps.
Mike Mascari
From bouncefilter Mon Dec 27 07:01:34 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA71256
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 07:00:54 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA06824;
Mon, 27 Dec 1999 12:46:18 +0100
Date: Mon, 27 Dec 1999 12:46:17 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Howie <caffeine@toodarkpark.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.LNX.3.96.991226174444.25654k-100000@rabies.toodarkpark.org>
Message-ID: <Pine.LNX.3.96.991227123408.6398C-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 26 Dec 1999, Howie wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?Plug-in Oracle 7 compatibility.
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?tablespace support ( which isnt a trivial task ), groups ( pgsql has this
sort of functionality already, but i dont think its to the extent that
Oracle does ), some additional grants ( 'grant connect to' ), 'alter table
<table> add constraint <constraint definition>'...tablespace support would put pgsql soooo far ahead of most other rdbmses.
Yes. A tablespace is good feature for robus SQL engine. And (IMHO):
- raw i/o device storage manager
- replication
- privilege for columns, lock
- better speed, speed ... and speed :-)
- on-the-fly backup (from any logs)
Karel
From bouncefilter Mon Dec 27 07:06:34 1999
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA71971
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 07:05:36 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id MAA24682; Mon, 27 Dec 1999 12:05:13 GMT
Sender: a.joubert@albourne.com
Message-ID: <386757A6.E36B1499@albourne.com>
Date: Mon, 27 Dec 1999 14:12:22 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.38 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: john huttley <john@mwk.co.nz>
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <199912260227.VAA01249@candle.pha.pa.us>
<002301bf4f77$39884e40$ca5fa8c0@hisdad.org.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
john huttley wrote:
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?Yes, earlier in the year I was trying to migrate from Pervasive SQL to
posgtres and
came to a screaming halt when it wouldn't do a large view. Exceeded some
sort of internal buffer
or rule area. I dont recall the details, although the mail archive will have
it.
This will be fixed by Jan's new compressed type and the long fields in a second
table. So in about 6 months time.
The one we still need is views on UNION's...
Adriaan
From bouncefilter Mon Dec 27 07:43:34 1999
Received: from sos1.sos.com.pl (sos1.sos.com.pl [195.117.212.2])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA78365
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 07:42:38 -0500 (EST)
(envelope-from XSoftware@internet.pl)
Received: from internet.pl (pa170.warszawa.ppp.tpnet.pl [212.160.52.170])
by sos1.sos.com.pl (8.9.3/8.9.3) with ESMTP id NAA07744
for <pgsql-general@postgresql.org>; Mon, 27 Dec 1999 13:42:25 +0100
Sender: siosion@internet.pl
Message-ID: <386762B5.1AD1E57B@internet.pl>
Date: Mon, 27 Dec 1999 13:59:33 +0100
From: Adam Szeliga <XSoftware@internet.pl>
Organization: X-Software
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.1-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: The process ID of the backend ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
How can I receive the process ID of the backend server handling the
current
connection from SQL function ?
Something similar to: "int PQbackendPID(PGconn *conn);"
Adam
From bouncefilter Mon Dec 27 07:53:34 1999
Received: from cap-ferrat.albourne.com (cap-ferrat.albourne.com
[195.89.178.227]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA79234
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 07:53:12 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from albourne.com (bishop-rock.albourne.com [195.89.178.230])
by cap-ferrat.albourne.com (8.9.3/8.9.3/Albourne/UKS/2.9/MAPS) with
ESMTP id MAA24588
for <pgsql-general@postgreSQL.org>; Mon, 27 Dec 1999 12:53:10 GMT
Sender: a.joubert@albourne.com
Message-ID: <386762E2.635E7F1A@albourne.com>
Date: Mon, 27 Dec 1999 15:00:18 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.38 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <Pine.LNX.3.96.991227121303.6398B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
Yes, I think reliability needs more work. I've had quite a few problems with
system indexes getting corrupted (number of tuples incorrect and some other
bizarre problems). Very hard to pin down as I haven't been able to reproduce any
of these cases. I've got the feeling that there may be problems when you have PL
routines used to enforce consistency constraints between several tables and the
database is being hit hard.
On the whole we are very happy with postgres and it has recently moved from one
of our development systems to a production system.
I think there has been a similar development for quite a few other people and
there are an increasing number of production Postgres systems out there. Several
people have mentioned that they could make some money available for futher
development of postgres. I also noticed that the common list of complaints (large
tuples etc) have mostly moved from the to-do to the done list.
I think there needs to be a new discussion on how best to make use of additional
resources to do things that benefit postgres most. Perhaps it would be an idea to
have the developers put together a list with tasks that are boring and that
nobody wants to do, but that would be of great benefit to the system (for
somebody who doesn't know the internals it is hard to see what may be important
tasks).
I would prefer to contribute time, but we are kind-of short of people, so that
that is pretty hard to do. The next best thing then seems to be to contribute
money in a way that benefits everybody. I'm thinking along the lines of: if a
few companies could provide $500 or $1000 and this could free up some of a
developers time to work on postgres rather than to go contracting and this time
is spent on a part of postgres that is important for production use (Vadim's work
on the transaction logs for example), then this is a good thing.
Any such process should make use of an accumulation of small contributions, as it
is amazingly difficult to explain to a finance director why you want to spend
$1000 without getting anything solid in return (while they are often quite happy
to shell out twice that for an Office licence) and many companies are small
start-ups and perhaps not that flush with cash (which is probably why they are
using postgres in the first place).
And secondly it is very important for the developers to figure out how this is
going to interact with the whole process of collaborative software development.
The last thing we want is competition for funds to impact on a collaborative
development process. I think a system like this can only operate if it is based
on consensus between the main developers.
Please feel free to flame if I'm talking bollox. In the mean-time: happy new year
to everybody!
Adriaan
From bouncefilter Mon Dec 27 08:28:35 1999
Received: from photon.skillbrokers.bg (root@photon.skillbrokers.bg
[195.24.42.194]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA86031
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 08:28:25 -0500 (EST)
(envelope-from nmmm@webfactory.bg)
Received: from niki (proton.skillbrokers.bg [195.24.42.206])
by photon.skillbrokers.bg (8.9.0/8.9.0) with SMTP id QAA02729
for <pgsql-general@postgreSQL.org>; Mon, 27 Dec 1999 16:21:20 +0200
Message-ID: <00e701bf506e$11a4c960$ce2a18c3@skillbrokers.bg>
From: "Nikolay Mijaylov" <nmmm@webfactory.bg>
To: "pgsql-general" <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
Date: Mon, 27 Dec 1999 15:27:05 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00E4_01BF507E.D47C98E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_00E4_01BF507E.D47C98E0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
First of all:
Merry XMas and Happy new Year.
-----------------------------------
Let i tell what i do not like in PGSQL
-----------------------------------
1. Online error submit form. Take a look at PHP error submit form.
2. Large objects. You cant dump/restore them. Every LO is represented by =
2 "two" files. In one moment all running out of control.
3. It would be nice to have large objects thats are represented by =
standard OS/FS files. (There are some words about this in manual)
4. Create table transactions:
begin work;
create table ppl(name int2);
bla bla;
commit work;
this SQL create empty, zero len file into db directory.
after this you cannot table with name like this,
nor you cannot drop it. (only way is to go to delete this file in db =
dir)
5. Nested SQL in parts different than "where" clause.
-----------------------------------
What i think we (you, they) do not need to make
1. XML support. Are someone know what is XML????
Yes it is modern, but I do not think that it must be used as
buffer between everything (like db and client).
XML is nothing more this:
<db>
<addressbook>
<person name=3D"gogo" email=3D"gogo@nmmm.nu"></person>
<person name=3D"pepi" email=3D"pepi@nmmm.nu"></person>
</addressbook>
<some_other_table>
....
</some_other_table>
</db>
Does we need to integrate this into the db, like Oracle or
MsSQL? I do not think SO!!!!!
What Oracle did:
-------------------------------------------------------------------------=
-
WWW client
(browser
^
|
(oracle)
web server
^
| sql
program ------------> db
^ |
| |
+-xml lib,<--- xml ---+
often java
-------------------------------------------------------------------------=
-
I think all this ar bulsheet:)
I use technology like thisdb
|
|
sqlwrapper (http://www.nmmm.nu/linux/a_dbc/)
|
|
cgi ------ www server --------- www client
I;m sure more of us are using something simillar.
and Its faster and clean.
-------------------------------------------------------------------------=
-------
May be we need a tool for convert an XML into SQL, so we
be able to use:
cat db.xml | xml2sql | psql
Like this? And this:
pgdump db | sql2xml > db.xml
I have a technology to write this if we are interested,
and to include this in contribution.
-----------------------------------
2. Oracle / Informix compatibility????? Hey there are standards !!!!!!
lets first make PG full ANSI SQL 92+++ compatible. :)
Dont think that Oracle maniacs will join us, if PG is Oracle compatible.
There i;ve a colegue, that i told her that Postgres is 1000% enought for
our work (power web development with databases 10MB - 100 MB)
and she always told me that she want oracle because she want to
learn SQL.
This is the situation for lamers: Oracle =3D SQL.
Happy XMAS again=20
Happy new Year
Postgres still is the best :)
Nikolay Mijaylov.
--------------------------------------------------------------
The reboots are for hardware upgrades!
"http://www.nmmm.nu; <nmmm@nmmm.nu>
------=_NextPart_000_00E4_01BF507E.D47C98E0
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dkoi8-r" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=3D2>First of all:</FONT></DIV>
<DIV><FONT size=3D2>Merry XMas and Happy new Year.</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV><FONT size=3D2>Let i tell what i do not like in PGSQL</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV><FONT size=3D2>1. Online error submit form. Take a look at PHP =
error submit=20
form.</FONT></DIV>
<DIV><FONT size=3D2>2. Large objects. You cant dump/restore them. Every =
LO is=20
represented by 2 "two" files. In one moment all running out of=20
control.</FONT></DIV>
<DIV><FONT size=3D2>3. It would be nice to have large objects thats are=20
represented by standard OS/FS files. (There are some words about this in =
manual)</FONT></DIV>
<DIV><FONT size=3D2>4. Create table transactions:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>begin work;</FONT></DIV>
<DIV><FONT size=3D2>create table ppl(name int2);</FONT></DIV>
<DIV><FONT size=3D2>bla bla;</FONT></DIV>
<DIV><FONT size=3D2>commit work;</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>this SQL create empty, zero len file into db=20
directory.</FONT></DIV>
<DIV><FONT size=3D2>after this you cannot table with name like =
this,</FONT></DIV>
<DIV><FONT size=3D2>nor you cannot drop it. (only way is to go to delete =
this file=20
in db dir)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>5. Nested SQL in parts different than "where"=20
clause.</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV><FONT size=3D2>What i think we (you, they) do not need to =
make</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>1. XML support. Are someone know what is =
XML????</FONT></DIV>
<DIV><FONT size=3D2>Yes it is modern, but I do not think that it must be =
used=20
as</FONT></DIV>
<DIV><FONT size=3D2>buffer between everything (like db and =
client).</FONT></DIV>
<DIV><FONT size=3D2>XML is nothing more this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2><db></FONT></DIV>
<DIV><FONT size=3D2><addressbook></FONT></DIV>
<DIV><FONT size=3D2><person name=3D"gogo" <A=20
href=3D'mailto:email=3D"gogo@nmmm.nu'>email=3D"gogo@nmmm.nu</A>"></=
person></FONT></DIV>
<DIV><FONT size=3D2><person name=3D"pepi" <A=20
href=3D'mailto:email=3D"pepi@nmmm.nu"></'>email=3D"pepi@nmmm.nu"></=
</A>person><BR></addressbook></FONT></DIV>
<DIV><FONT size=3D2><some_other_table></FONT></DIV>
<DIV><FONT size=3D2>....</FONT></DIV>
<DIV><FONT size=3D2></some_other_table></FONT></DIV>
<DIV><FONT size=3D2></db></FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Does we need to integrate this into the db, like =
Oracle=20
or</FONT></DIV>
<DIV><FONT size=3D2>MsSQL? I do not think SO!!!!!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>What Oracle did:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>
<DIV><FONT=20
face=3DArial>------------------------------------------------------------=
--------------</FONT></DIV>
<DIV>WWW client</DIV>
<DIV>(browser</DIV>
<DIV> ^</DIV>
<DIV> |</DIV>
<DIV>(oracle)</DIV>
<DIV>web server</DIV>
<DIV> ^</DIV>
<DIV><FONT =
size=3D2> | =20
sql</FONT></DIV></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>program ------------> =
db</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2> ^ &nb=
sp; =20
|</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2> | &nb=
sp; |</F=
ONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2> +-xml lib,<--- xml=20
---+</FONT></DIV>
<DIV><FONT size=3D2> often =
java</FONT></DIV>
<DIV><FONT size=3D2><FONT=20
face=3DArial>------------------------------------------------------------=
--------------</FONT></FONT></DIV>
<DIV><FONT size=3D2>I think all this ar bulsheet:)</FONT></DIV>
<DIV><FONT size=3D2>I use technology like this</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>db</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2>sqlwrapper (<A=20
href=3D"http://www.nmmm.nu/linux/a_dbc/">http://www.nmmm.nu/linux/a_dbc/<=
/A>)</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2>cgi ------ www server --------- www =
client</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>I;m sure more of us are using something=20
simillar.</FONT></DIV>
<DIV><FONT size=3D2>and Its faster and clean.</FONT></DIV>
<DIV><FONT=20
size=3D2>----------------------------------------------------------------=
----------------</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>May be we need a tool for convert an XML into SQL, =
so=20
we</FONT></DIV>
<DIV><FONT size=3D2>be able to use:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>cat db.xml | xml2sql | psql</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Like this? And this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>pgdump db | sql2xml > db.xml</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>I have a technology to write this if we are=20
interested,</FONT></DIV>
<DIV><FONT size=3D2>and to include this in contribution.</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>2. Oracle / Informix compatibility????? Hey there =
are=20
standards !!!!!!</FONT></DIV>
<DIV><FONT size=3D2>lets first make PG full ANSI SQL 92+++ compatible.=20
</FONT><FONT size=3D2>:)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Dont think that Oracle maniacs will join us, if PG =
is Oracle=20
compatible.</FONT></DIV>
<DIV><FONT size=3D2>There i;ve a colegue, that i told her that Postgres =
is 1000%=20
enought for</FONT></DIV>
<DIV><FONT size=3D2>our work (power web development with =
databases 10MB - 100=20
MB)</FONT></DIV>
<DIV><FONT size=3D2>and she always told me that she want oracle because =
she want=20
to</FONT></DIV>
<DIV><FONT size=3D2>learn SQL.</FONT></DIV>
<DIV><FONT size=3D2>This is the situation for lamers: Oracle =3D =
SQL.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Happy XMAS again </FONT></DIV>
<DIV><FONT size=3D2>Happy new Year</FONT></DIV>
<DIV><FONT size=3D2>Postgres still is the best :)</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Nikolay Mijaylov.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT=20
size=3D2>--------------------------------------------------------------<B=
R>The=20
reboots are for hardware upgrades!<BR>"<A=20
href=3D"http://www.nmmm.nu">http://www.nmmm.nu</A>; <<A=20
href=3D"mailto:nmmm@nmmm.nu">nmmm@nmmm.nu</A>><BR></FONT></DIV></BODY>=
</HTML>
------=_NextPart_000_00E4_01BF507E.D47C98E0--
From bouncefilter Mon Dec 27 09:16:35 1999
Received: from photon.skillbrokers.bg (root@photon.skillbrokers.bg
[195.24.42.194]) by hub.org (8.9.3/8.9.3) with ESMTP id JAA96748
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 09:15:37 -0500 (EST) (envelope-from nmmm@nmmm.nu)
Received: from niki (proton.skillbrokers.bg [195.24.42.206])
by photon.skillbrokers.bg (8.9.0/8.9.0) with SMTP id RAA02998
for <pgsql-general@postgreSQL.org>; Mon, 27 Dec 1999 17:08:46 +0200
Message-ID: <001001bf5074$b0b8e940$ce2a18c3@skillbrokers.bg>
From: "Nikolay Mijaylov" <nmmm@nmmm.nu>
To: "pgsql-general" <pgsql-general@postgreSQL.org>
Subject: Fw: [GENERAL] Future of PostgreSQL
Date: Mon, 27 Dec 1999 16:14:25 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000D_01BF5085.7160B960"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_000D_01BF5085.7160B960
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
--------------------------------------------------------------
The reboots are for hardware upgrades!
"www.nmmm.nu"; <nmmm@nmmm.nu>
----- Original Message -----=20
From: Nikolay Mijaylov=20
To: pgsql-general=20
Sent: =D0=CF=CE=C5=C4=C5=CC=CE=C9=CB, =E4=C5=CB=C5=CD=D7=D2=C9 27, 1999 =
03:27
Subject: Re: [GENERAL] Future of PostgreSQL
First of all:
Merry XMas and Happy new Year.
-----------------------------------
Let i tell what i do not like in PGSQL
-----------------------------------
1. Online error submit form. Take a look at PHP error submit form.
2. Large objects. You cant dump/restore them. Every LO is represented by =
2 "two" files. In one moment all running out of control.
3. It would be nice to have large objects thats are represented by =
standard OS/FS files. (There are some words about this in manual)
4. Create table transactions:
begin work;
create table ppl(name int2);
bla bla;
commit work;
this SQL create empty, zero len file into db directory.
after this you cannot table with name like this,
nor you cannot drop it. (only way is to go to delete this file in db =
dir)
5. Nested SQL in parts different than "where" clause.
-----------------------------------
What i think we (you, they) do not need to make
=20
1. XML support. Are someone know what is XML????
Yes it is modern, but I do not think that it must be used as
buffer between everything (like db and client).
XML is nothing more this:
<db>
<addressbook>
<person name=3D"gogo" email=3D"gogo@nmmm.nu"></person>
<person name=3D"pepi" email=3D"pepi@nmmm.nu"></person>
</addressbook>
<some_other_table>
....
</some_other_table>
</db>
Does we need to integrate this into the db, like Oracle or
MsSQL? I do not think SO!!!!!
What Oracle did:
-------------------------------------------------------------------------=
-
WWW client
(browser
^
|
(oracle)
web server
^
| sql
program ------------> db
^ |
| |
+-xml lib,<--- xml ---+
often java
-------------------------------------------------------------------------=
-
I think all this ar bulsheet:)
I use technology like thisdb
|
|
sqlwrapper (http://www.nmmm.nu/linux/a_dbc/)
|
|
cgi ------ www server --------- www client
I;m sure more of us are using something simillar.
and Its faster and clean.
-------------------------------------------------------------------------=
-------
May be we need a tool for convert an XML into SQL, so we
be able to use:
cat db.xml | xml2sql | psql
Like this? And this:
pgdump db | sql2xml > db.xml
I have a technology to write this if we are interested,
and to include this in contribution.
-----------------------------------
2. Oracle / Informix compatibility????? Hey there are standards !!!!!!
lets first make PG full ANSI SQL 92+++ compatible. :)
Dont think that Oracle maniacs will join us, if PG is Oracle compatible.
There i;ve a colegue, that i told her that Postgres is 1000% enought for
our work (power web development with databases 10MB - 100 MB)
and she always told me that she want oracle because she want to
learn SQL.
This is the situation for lamers: Oracle =3D SQL.
Happy XMAS again=20
Happy new Year
Postgres still is the best :)
Nikolay Mijaylov.
--------------------------------------------------------------
The reboots are for hardware upgrades!
"http://www.nmmm.nu; <nmmm@nmmm.nu>
------=_NextPart_000_000D_01BF5085.7160B960
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dkoi8-r" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV>
<DIV>--------------------------------------------------------------<BR>Th=
e=20
reboots are for hardware upgrades!<BR>"<A=20
href=3D'http://www.nmmm.nu"'>www.nmmm.nu"</A>; <<A=20
href=3D"mailto:nmmm@nmmm.nu">nmmm@nmmm.nu</A>><BR></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:nmmm@webfactory.bg" title=3Dnmmm@webfactory.bg>Nikolay =
Mijaylov</A>=20
</DIV>
<DIV><B>To:</B> <A href=3D"mailto:pgsql-general@postgreSQL.org"=20
title=3Dpgsql-general@postgreSQL.org>pgsql-general</A> </DIV>
<DIV><B>Sent:</B> =D0=CF=CE=C5=C4=C5=CC=CE=C9=CB, =
=E4=C5=CB=C5=CD=D7=D2=C9 27, 1999 03:27</DIV>
<DIV><B>Subject:</B> Re: [GENERAL] Future of PostgreSQL</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT size=3D2>First of all:</FONT></DIV>
<DIV><FONT size=3D2>Merry XMas and Happy new Year.</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV><FONT size=3D2>Let i tell what i do not like in PGSQL</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV><FONT size=3D2>1. Online error submit form. Take a look at PHP =
error submit=20
form.</FONT></DIV>
<DIV><FONT size=3D2>2. Large objects. You cant dump/restore them. Every =
LO is=20
represented by 2 "two" files. In one moment all running out of=20
control.</FONT></DIV>
<DIV><FONT size=3D2>3. It would be nice to have large objects thats are=20
represented by standard OS/FS files. (There are some words about this in =
manual)</FONT></DIV>
<DIV><FONT size=3D2>4. Create table transactions:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>begin work;</FONT></DIV>
<DIV><FONT size=3D2>create table ppl(name int2);</FONT></DIV>
<DIV><FONT size=3D2>bla bla;</FONT></DIV>
<DIV><FONT size=3D2>commit work;</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>this SQL create empty, zero len file into db=20
directory.</FONT></DIV>
<DIV><FONT size=3D2>after this you cannot table with name like =
this,</FONT></DIV>
<DIV><FONT size=3D2>nor you cannot drop it. (only way is to go to delete =
this file=20
in db dir)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>5. Nested SQL in parts different than "where"=20
clause.</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV><FONT size=3D2>What i think we (you, they) do not need to =
make</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>1. XML support. Are someone know what is =
XML????</FONT></DIV>
<DIV><FONT size=3D2>Yes it is modern, but I do not think that it must be =
used=20
as</FONT></DIV>
<DIV><FONT size=3D2>buffer between everything (like db and =
client).</FONT></DIV>
<DIV><FONT size=3D2>XML is nothing more this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2><db></FONT></DIV>
<DIV><FONT size=3D2><addressbook></FONT></DIV>
<DIV><FONT size=3D2><person name=3D"gogo" <A=20
href=3D'mailto:email=3D"gogo@nmmm.nu'>email=3D"gogo@nmmm.nu</A>"></=
person></FONT></DIV>
<DIV><FONT size=3D2><person name=3D"pepi" <A=20
href=3D'mailto:email=3D"pepi@nmmm.nu"></'>email=3D"pepi@nmmm.nu"></=
</A>person><BR></addressbook></FONT></DIV>
<DIV><FONT size=3D2><some_other_table></FONT></DIV>
<DIV><FONT size=3D2>....</FONT></DIV>
<DIV><FONT size=3D2></some_other_table></FONT></DIV>
<DIV><FONT size=3D2></db></FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Does we need to integrate this into the db, like =
Oracle=20
or</FONT></DIV>
<DIV><FONT size=3D2>MsSQL? I do not think SO!!!!!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>What Oracle did:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>
<DIV><FONT=20
face=3DArial>------------------------------------------------------------=
--------------</FONT></DIV>
<DIV>WWW client</DIV>
<DIV>(browser</DIV>
<DIV> ^</DIV>
<DIV> |</DIV>
<DIV>(oracle)</DIV>
<DIV>web server</DIV>
<DIV> ^</DIV>
<DIV><FONT =
size=3D2> | =20
sql</FONT></DIV></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>program ------------> =
db</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2> ^ &nb=
sp; =20
|</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2> | &nb=
sp; |</F=
ONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2> +-xml lib,<--- xml=20
---+</FONT></DIV>
<DIV><FONT size=3D2> often =
java</FONT></DIV>
<DIV><FONT size=3D2><FONT=20
face=3DArial>------------------------------------------------------------=
--------------</FONT></FONT></DIV>
<DIV><FONT size=3D2>I think all this ar bulsheet:)</FONT></DIV>
<DIV><FONT size=3D2>I use technology like this</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>db</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2>sqlwrapper (<A=20
href=3D"http://www.nmmm.nu/linux/a_dbc/">http://www.nmmm.nu/linux/a_dbc/<=
/A>)</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2> |</FONT></DIV>
<DIV><FONT size=3D2>cgi ------ www server --------- www =
client</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>I;m sure more of us are using something=20
simillar.</FONT></DIV>
<DIV><FONT size=3D2>and Its faster and clean.</FONT></DIV>
<DIV><FONT=20
size=3D2>----------------------------------------------------------------=
----------------</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>May be we need a tool for convert an XML into SQL, =
so=20
we</FONT></DIV>
<DIV><FONT size=3D2>be able to use:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>cat db.xml | xml2sql | psql</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Like this? And this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>pgdump db | sql2xml > db.xml</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>I have a technology to write this if we are=20
interested,</FONT></DIV>
<DIV><FONT size=3D2>and to include this in contribution.</FONT></DIV>
<DIV><FONT size=3D2>-----------------------------------</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>2. Oracle / Informix compatibility????? Hey there =
are=20
standards !!!!!!</FONT></DIV>
<DIV><FONT size=3D2>lets first make PG full ANSI SQL 92+++ compatible.=20
</FONT><FONT size=3D2>:)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Dont think that Oracle maniacs will join us, if PG =
is Oracle=20
compatible.</FONT></DIV>
<DIV><FONT size=3D2>There i;ve a colegue, that i told her that Postgres =
is 1000%=20
enought for</FONT></DIV>
<DIV><FONT size=3D2>our work (power web development with =
databases 10MB - 100=20
MB)</FONT></DIV>
<DIV><FONT size=3D2>and she always told me that she want oracle because =
she want=20
to</FONT></DIV>
<DIV><FONT size=3D2>learn SQL.</FONT></DIV>
<DIV><FONT size=3D2>This is the situation for lamers: Oracle =3D =
SQL.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Happy XMAS again </FONT></DIV>
<DIV><FONT size=3D2>Happy new Year</FONT></DIV>
<DIV><FONT size=3D2>Postgres still is the best :)</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Nikolay Mijaylov.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT=20
size=3D2>--------------------------------------------------------------<B=
R>The=20
reboots are for hardware upgrades!<BR>"<A=20
href=3D"http://www.nmmm.nu">http://www.nmmm.nu</A>; <<A=20
href=3D"mailto:nmmm@nmmm.nu">nmmm@nmmm.nu</A>><BR></FONT></DIV></BODY>=
</HTML>
------=_NextPart_000_000D_01BF5085.7160B960--
From bouncefilter Mon Dec 27 09:48:36 1999
Received: from web2105.mail.yahoo.com (web2105.mail.yahoo.com [128.11.68.249])
by hub.org (8.9.3/8.9.3) with SMTP id JAA02776
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 09:47:52 -0500 (EST)
(envelope-from psrajan@yahoo.com)
Received: (qmail 27755 invoked by uid 60001); 27 Dec 1999 14:47:51 -0000
Message-ID: <19991227144751.27754.qmail@web2105.mail.yahoo.com>
Received: from [205.172.146.55] by web2105.mail.yahoo.com;
Mon, 27 Dec 1999 06:47:51 PST
Date: Mon, 27 Dec 1999 06:47:51 -0800 (PST)
From: soundar rajan <psrajan@yahoo.com>
Subject: Re: [GENERAL] Possible FAQs: single-quote and rename database
To: Bruce Momjian <pgman@candle.pha.pa.us>,
"Nathan L. Cutler" <livingston@iol.cz>
Cc: pgsql-general@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Renaming the directory in the data directory doesn't
work either.
--- Bruce Momjian <pgman@candle.pha.pa.us> wrote:Hello:
I have two questions that might be FAQs (apologies
in advance):
(1) Why does the parser choke on backslashed
single-quote characters? Or,
in other words, why doesn't this work:
testing=> \d bubba
Table = bubba
+--------------------------+----------------------------------+-------+
| Field | Type
| Length|
+--------------------------+----------------------------------+-------+
| litbub | varchar()
| 60 |
+--------------------------+----------------------------------+-------+
testing=> insert '\'' into bubba;
ERROR: parser: parse error at or near "'"INSERT INTO bubba VALUES ('\'');
(2) How does one rename a database? Other than
dump/destroydb/restore,
obviously.
I think you can modify pg_database with new name,
stop postmaster,
rename database directory, and restart. Not sure,
but that may work.-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
=====
Thanks.
Soundar.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From bouncefilter Mon Dec 27 10:12:36 1999
Received: from picasso.realtyideas.com (IDENT:kaiq@207-18-128-210.flex.net
[207.18.128.210]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA07599
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 10:11:38 -0500 (EST)
(envelope-from kaiq@picasso.realtyideas.com)
Received: from localhost (kaiq@localhost)
by picasso.realtyideas.com (8.9.3/8.9.3) with ESMTP id KAA16872;
Mon, 27 Dec 1999 10:06:47 -0600
Date: Mon, 27 Dec 1999 10:06:47 -0600 (CST)
From: <kaiq@realtyideas.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: "Clark C. Evans" <clark.evans@manhattanproject.com>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <199912260227.VAA01249@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.10.9912271003590.15801-100000@picasso.realtyideas.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
data warehouse related capability. e.g., table space, table split, bitmap
index, using multiple indices in one query, star-schema optimization.
On Sat, 25 Dec 1999, Bruce Momjian wrote:
On Sat, 25 Dec 1999, Bruce Momjian wrote:
My big question is, what new challenges will we face as
we become more popular?Plug-in Oracle 7 compatibility.
I believe we are adding Oracle compatibility as possible. We are
working on write-ahead log, long tuples, foreign keys, and outer joins.
Anything else?-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026************
From bouncefilter Mon Dec 27 13:47:38 1999
Received: from web3204.mail.yahoo.com (web3204.mail.yahoo.com
[204.71.202.201])
by hub.org (8.9.3/8.9.3) with SMTP id NAA58080
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 13:47:19 -0500 (EST)
(envelope-from martin_pgsql@yahoo.com)
Message-ID: <19991227184648.18638.qmail@web3204.mail.yahoo.com>
Received: from [24.4.252.36] by web3204.mail.yahoo.com;
Mon, 27 Dec 1999 10:46:48 PST
Date: Mon, 27 Dec 1999 10:46:48 -0800 (PST)
From: Charles Martin <martin_pgsql@yahoo.com>
Subject: Setting up Postgres for production web/db work
To: pgsql-general@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
We are about to set up a production web/db site with
Apache 1.3.9, PHP 3.0.12, and PostgreSQL 6.5.2. The
platform is a single-cpu Dell server running FreeBSD
3.4-STABLE. I have looked but have not seen anything
with recommendations for how to set up Postgres for a
production site.
For example, is:
% postmaster
the preferred invocation? Should we be specifying
something about the memory usage, number of processes,
etc? Is there a FAQ for how to set up cron jobs to do
nightly dumps and etc with maximal efficiency? Should
we be vaccuuming regularly, and do we need to take the
db offline to do so? Etc.
Any help on this issue would be greatly appreciated!
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From bouncefilter Mon Dec 27 14:47:39 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA70738
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 14:46:52 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.93.36.204]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 27 Dec 1999 13:47:11 -0600
Sender: ed
Message-ID: <3867C275.7F636B84@austin.rr.com>
Date: Mon, 27 Dec 1999 13:48:05 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Charles Martin <martin_pgsql@yahoo.com>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Setting up Postgres for production web/db work
References: <19991227184648.18638.qmail@web3204.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
See 'man postmaster' and 'man postgres' for available startup
options on number of servers, memory usage, etc. Also, check out
www.postgresql.org under "Info Central"-->"Documentation" for a
host of pretty decent documents answering many of your
current/future questions. Lots of very useful stuff found at
Deja.com as well (http://www.deja.com/home_ps.shtml)...deja is
archiving *all* pgsql mailing list posts). Memory usage, number
of servers, etc. really depends on tuning for your
application/hardware, but running with defaults seems to be a
good starting point.
Things I wish I'd known about early on (some found in
documentation, some not):
* The -F flag (a 2200% performance boost on inserts for me);
* The -S flag (customizes amount of memory to be used for
sorts);
* Vacuum is needed nightly at least, more often after many
inserts/deletes;
* Vacuum can also fix certain showstoppers;
* Some folks report it cannot be run safely while online with
a load;
* How to turn timestamped db server logging on...
http://www.deja.com/getdoc.xp?AN=562128922
Cheers,
Ed Loehr
Charles Martin wrote:
We are about to set up a production web/db site with
Apache 1.3.9, PHP 3.0.12, and PostgreSQL 6.5.2. The
platform is a single-cpu Dell server running FreeBSD
3.4-STABLE. I have looked but have not seen anything
with recommendations for how to set up Postgres for a
production site.For example, is:
% postmaster
the preferred invocation? Should we be specifying
something about the memory usage, number of processes,
etc? Is there a FAQ for how to set up cron jobs to do
nightly dumps and etc with maximal efficiency? Should
we be vaccuuming regularly, and do we need to take the
db offline to do so? Etc.Any help on this issue would be greatly appreciated!
From bouncefilter Mon Dec 27 17:05:41 1999
Received: from EmergingSolutions.com ([166.90.192.227])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA99733
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 17:05:26 -0500 (EST)
(envelope-from matthew.brown@cordata.net)
Received: from devweb5 ([208.240.219.179]) by EmergingSolutions.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 27 Dec 1999 16:46:20 -0500
Message-ID: <002001bf50b6$a89f5ef0$b3dbf0d0@emergingsolutions.com>
From: "Matthew Brown" <matthew.brown@cordata.net>
To: <pgsql-general@postgresql.org>
Subject: /usr/bin/wish required for install???
Date: Mon, 27 Dec 1999 17:06:42 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001D_01BF508C.BF96FC50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_001D_01BF508C.BF96FC50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I am trying to install pgsql from .RPM on a MIPS box. It gives me an =
error that it needs /usr/bin/wish in order to install.
Where can I get wish? I tried install Tcl as it is supposed to be a =
part of that somehow, but that hasn't worked either.
Best regards,
Matthew Brown
------=_NextPart_000_001D_01BF508C.BF96FC50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I am trying to install pgsql from .RPM =
on a MIPS=20
box. It gives me an error that it needs /usr/bin/wish in order to=20
install.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Where can I get wish? I tried =
install Tcl as=20
it is supposed to be a part of that somehow, but that hasn't worked=20
either.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Matthew =
Brown</FONT></DIV></BODY></HTML>
------=_NextPart_000_001D_01BF508C.BF96FC50--
From bouncefilter Mon Dec 27 17:30:41 1999
Received: from arka.poznan.mtl.pl (IDENT:mazek@arka.poznan.mtl.pl
[195.116.164.132]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA02238
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 17:29:50 -0500 (EST)
(envelope-from m.mazurek@multinet.pl)
Received: from localhost (mazek@localhost)
by arka.poznan.mtl.pl (8.9.3/8.9.2) with SMTP id XAA21549
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 23:29:06 +0100 (CET)
X-Authentication-Warning: arka.poznan.mtl.pl: mazek owned process doing -bs
Date: Mon, 27 Dec 1999 23:29:06 +0100 (CET)
From: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>
X-Sender: mazek@arka
cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] /usr/bin/wish required for install???
In-Reply-To: <002001bf50b6$a89f5ef0$b3dbf0d0@emergingsolutions.com>
Message-ID: <Pine.BSF.3.96.991227232830.27100H-100000@arka>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Matthew Brown wrote:
Where can I get wish? I tried install Tcl as it is supposed to be a
part of that somehow, but that hasn't worked either.
[root@mazek /root]# rpm -qf /usr/bin/wish
tk-8.0.4-29
mazek
From bouncefilter Mon Dec 27 18:10:41 1999
Received: from ga.prestige.net (dns2.prestige.net [208.220.88.11] (may be
forged)) by hub.org (8.9.3/8.9.3) with ESMTP id SAA11963
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 18:10:04 -0500 (EST)
(envelope-from matthew.brown@cordata.net)
Received: from Matthewb [208.220.89.16] by ga.prestige.net
(SMTPD32-6.00) id A18D10C0020E; Mon, 27 Dec 1999 18:09:01 -0500
Message-ID: <000d01bf50bf$ab57d920$1059dcd0@Matthewb>
From: "Matthew Brown" <matthew.brown@cordata.net>
To: "Marcin Mazurek - Multinet SA - Poznan" <m.mazurek@multinet.pl>
Cc: <pgsql-general@postgreSQL.org>
References: <Pine.BSF.3.96.991227232830.27100H-100000@arka>
Subject: Re: [GENERAL] /usr/bin/wish required for install???
Date: Mon, 27 Dec 1999 18:11:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
How strange. Isn't Tk only really used with X?
The machine I'm installing on has no video capabilities at all. Can I still
install X?
<Please pardon me if this is a stupid question>
Best regards,
Matthew Brown
SyteHost
----- Original Message -----
From: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>
Cc: <pgsql-general@postgreSQL.org>
Sent: Monday, December 27, 1999 5:29 PM
Subject: Re: [GENERAL] /usr/bin/wish required for install???
On Mon, 27 Dec 1999, Matthew Brown wrote:
Where can I get wish? I tried install Tcl as it is supposed to be a
part of that somehow, but that hasn't worked either.
[root@mazek /root]# rpm -qf /usr/bin/wish
tk-8.0.4-29
mazek
************
From bouncefilter Mon Dec 27 18:41:42 1999
Received: from geeks.linux.com (root@216.200.201.220.linux.com
[216.200.201.220] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id SAA17799
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 18:41:24 -0500 (EST)
(envelope-from chewie@wookimus.net)
Received: from geeks.linux.com (chewie@geeks.linux.com [216.200.201.219])
by geeks.linux.com (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA15110;
Mon, 27 Dec 1999 15:40:54 -0800
Date: Mon, 27 Dec 1999 15:40:54 -0800 (PST)
From: ^chewie <chewie@wookimus.net>
X-Sender: chewie@geeks.linux.com
To: Matthew Brown <matthew.brown@cordata.net>
cc: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>,
pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] /usr/bin/wish required for install???
In-Reply-To: <000d01bf50bf$ab57d920$1059dcd0@Matthewb>
Message-ID: <Pine.LNX.4.10.9912271540260.14940-100000@geeks.linux.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Matthew Brown wrote:
How strange. Isn't Tk only really used with X?
The machine I'm installing on has no video capabilities at all. Can I
still install X?
Tcl/Tk is cross platform. ;-) Enjoy!
----------------------------------------------------------------
Chad Walstrom mailto:chewie@wookimus.net
a.k.a ^chewie, gunnarr http://wookimus.net/~chewie
Gnupg = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD
----------------------------------------------------------------
From bouncefilter Mon Dec 27 19:06:47 1999
Received: from ga.prestige.net (dns2.prestige.net [208.220.88.11] (may be
forged)) by hub.org (8.9.3/8.9.3) with ESMTP id TAA29167
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 19:06:20 -0500 (EST)
(envelope-from matthew.brown@cordata.net)
Received: from Matthewb [208.220.89.16] by ga.prestige.net
(SMTPD32-6.00) id AED8223301C4; Mon, 27 Dec 1999 19:05:44 -0500
Message-ID: <002901bf50c7$98277560$1059dcd0@Matthewb>
From: "Matthew Brown" <matthew.brown@cordata.net>
To: <pgsql-general@postgreSQL.org>
References: <Pine.LNX.4.10.9912271540260.14940-100000@geeks.linux.com>
Subject: Re: [GENERAL] /usr/bin/wish required for install???
Date: Mon, 27 Dec 1999 19:07:56 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
I realize I am now getting off topic, but I can't cet Tk to install at all
unless it finds the X11 libs...
and I'm not sure I want to install X11 just to get pgsql, as great as it
seems on my i386 box.
Best regards,
Matthew Brown
SyteHost
----- Original Message -----
From: ^chewie <chewie@wookimus.net>
To: Matthew Brown <matthew.brown@cordata.net>
Cc: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>;
<pgsql-general@postgreSQL.org>
Sent: Monday, December 27, 1999 6:40 PM
Subject: Re: [GENERAL] /usr/bin/wish required for install???
On Mon, 27 Dec 1999, Matthew Brown wrote:
How strange. Isn't Tk only really used with X?
The machine I'm installing on has no video capabilities at all. Can I
still install X?
Tcl/Tk is cross platform. ;-) Enjoy!
----------------------------------------------------------------
Chad Walstrom mailto:chewie@wookimus.net
a.k.a ^chewie, gunnarr http://wookimus.net/~chewie
Gnupg = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD
----------------------------------------------------------------
From bouncefilter Mon Dec 27 19:34:42 1999
Received: from arka.poznan.mtl.pl (IDENT:mazek@arka.poznan.mtl.pl
[195.116.164.132]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA34640
for <pgsql-general@postgreSQL.org>;
Mon, 27 Dec 1999 19:33:57 -0500 (EST)
(envelope-from m.mazurek@multinet.pl)
Received: from localhost (mazek@localhost)
by arka.poznan.mtl.pl (8.9.3/8.9.2) with SMTP id BAA07046;
Tue, 28 Dec 1999 01:33:21 +0100 (CET)
X-Authentication-Warning: arka.poznan.mtl.pl: mazek owned process doing -bs
Date: Tue, 28 Dec 1999 01:33:20 +0100 (CET)
From: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>
X-Sender: mazek@arka
To: Matthew Brown <matthew.brown@cordata.net>
cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] /usr/bin/wish required for install???
In-Reply-To: <002901bf50c7$98277560$1059dcd0@Matthewb>
Message-ID: <Pine.BSF.3.96.991228013200.27100I-100000@arka>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Matthew Brown wrote:
I realize I am now getting off topic, but I can't cet Tk to install at all
unless it finds the X11 libs...
and I'm not sure I want to install X11 just to get pgsql, as great as it
seems on my i386 box.
maybe You should try install it from sources and skip everything
concerning X.
mazek
From bouncefilter Mon Dec 27 21:12:43 1999
Received: from abbott.viperlink.net (abbott.viperlink.net [204.181.32.11])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA51092
for <pgsql-general@postgresql.org>;
Mon, 27 Dec 1999 21:12:18 -0500 (EST) (envelope-from jeff@duska.com)
Received: from WIN2000PC (unverified [24.4.121.127]) by abbott.viperlink.net
(Vircom SMTPRS 4.0.179) with SMTP id <B0001582535@abbott.viperlink.net>;
Mon, 27 Dec 1999 21:12:25 -0500
From: "Jeff Duska" <jeff@duska.com>
To: "PostgreSQL-general" <pgsql-general@postgresql.org>
Cc: <alshaver@yahoo.com>
Subject: RE: [GENERAL] Future of PostgreSQL
Date: Mon, 27 Dec 1999 21:14:37 -0500
Message-ID: <NDBBKBPCNJKAIKOJOPJNGEPGCKAA.jeff@duska.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600
In-Reply-To: <199912251600.LAA21597@candle.pha.pa.us>
Just a few questions on the Future of PostgreSQL. I plan to play with
PostgreSQL project in the next few months. Since I am not yet knowledgable
about the internal PostgreSQL code and nor am I an database engine expert, I
thought I could work on projects that are "add-on" to PostgreSQL. All the
projects I mention will be Open Source using GPL or BSD. I've figuring GPL,
just because I have already found a lot code written in GPL. Here are the
projects I was thinking about, yet I was concerned.
Administration Tools? Are the current tools acceptable? Do you want
something more?
I planning on creating add-in to jEdit that would be a Visual Database
designer tool that works with any JDBC database, including PostgreSQL. I was
also think of taking it a step farther and making it know how to talk with
PostgreSQL via a native API.
For those of you familar with Visual Studio or Delphi it would look like one
of these Visual Tools mixed with ideas from Oracle's Designer and
Microsoft's Managment Console. Is this something the group would be
instrested in?
Java support in the database?
Just about all the current db have support for Java in the database. As an
example, Oracle has a JServer option that can be added to Oracle 8i. Would
something like this be of intrest to the group? Or should I look at other
things?
Internet
Oracle, IBM and other have all kinds of different Internet technologies such
as portable version of the database -- XML, HTML export and imports,
CORBA/Application Server type support.
OLAP
Data Warehousing doesn't have to be integrated into the database. The point
is that OLAP - can be applied as an add-in to the system. The key needs is a
good development tool to help your users and yourself understand the
information that you know have access to.
'nough said,
Jeff
From bouncefilter Tue Dec 28 00:33:45 1999
Received: from mail.intercall.com.br (g3i.com.br [200.197.170.2])
by hub.org (8.9.3/8.9.3) with SMTP id AAA99640
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 00:32:57 -0500 (EST)
(envelope-from howe@intercall.com.br)
Received: from SAM (200.197.170.98)
by mail.intercall.com.br with MERCUR-SMTP/POP3/IMAP4-Server (v3.10.16
AS-0098312)
for <pgsql-general@postgresql.org>; Tue, 28 Dec 1999 03:30:34 -0200
Message-ID: <001201bf50fd$79708b30$62aac5c8@SAM>
From: "Fabiano Ralo Monteiro" <howe@intercall.com.br>
To: <pgsql-general@postgresql.org>
Subject: PostgreSQL 6.5.3 ignores date formatting settings ?
Date: Tue, 28 Dec 1999 03:33:31 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000F_01BF50E4.4FD72A90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Reply-To: howe@intercall.com.br
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01BF50E4.4FD72A90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi folks,
I'm using PostgreSQL on RH 6.1 aswell NT. In both I got strange =
behaviours with data formatting and locale settings.
Check this psql dump:
##########################################################
howe=3D> select version();
version =20
-------------------------------------------------------------------
PostgreSQL 6.5.3 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
howe=3D> select now();
now =20
----------------------
1999-12-28 03:16:06-02
(1 row)
howe=3D> set datestyle to 'European';
SET VARIABLE
howe=3D> show datestyle;
NOTICE: DateStyle is Postgres with European conventions
SHOW VARIABLE
howe=3D> select now();
now =20
----------------------
1999-12-28 03:16:44-02
(1 row)
##########################################################
Shouldn't it have changed it's date style in the second "select now()" ?
The locale settings also seem to be completely ignored.
Best Regards,
Howe.
------=_NextPart_000_000F_01BF50E4.4FD72A90
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm using PostgreSQL on RH 6.1 aswell =
NT. In both I=20
got strange behaviours with data formatting and locale =
settings.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Check this psql dump:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial=20
size=3D2>##########################################################</FONT=
</DIV>
<DIV><FONT face=3DArial size=3D2>howe=3D> select=20
version();<BR>version &nbs=
p;  =
; =
&=
nbsp; &n=
bsp; =20
<BR>-------------------------------------------------------------------<B=
R>PostgreSQL=20
6.5.3 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66<BR>(1 =
row)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>howe=3D> select=20
now();<BR>now =
=20
<BR>----------------------<BR>1999-12-28 03:16:06-02<BR>(1 =
row)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>howe=3D> set datestyle to =
'European';<BR>SET=20
VARIABLE<BR>howe=3D> show datestyle;<BR>NOTICE: DateStyle is =
Postgres=20
with European conventions<BR>SHOW VARIABLE<BR>howe=3D> select=20
now();<BR>now =
=20
<BR>----------------------<BR>1999-12-28 03:16:44-02<BR>(1 =
row)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2>##########################################################</FONT=
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Shouldn't it have changed it's date =
style in the=20
second "select now()" ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The locale settings also seem to be =
completely=20
ignored.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Best Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Howe.</FONT></DIV></BODY></HTML>
------=_NextPart_000_000F_01BF50E4.4FD72A90--
From bouncefilter Tue Dec 28 02:34:47 1999
Received: from arka.poznan.mtl.pl (IDENT:mazek@arka.poznan.mtl.pl
[195.116.164.132]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA20283
for <pgsql-general@postgreSQL.org>;
Tue, 28 Dec 1999 02:33:58 -0500 (EST)
(envelope-from m.mazurek@multinet.pl)
Received: from localhost (mazek@localhost)
by arka.poznan.mtl.pl (8.9.3/8.9.2) with SMTP id IAA20254;
Tue, 28 Dec 1999 08:33:34 +0100 (CET)
X-Authentication-Warning: arka.poznan.mtl.pl: mazek owned process doing -bs
Date: Tue, 28 Dec 1999 08:33:34 +0100 (CET)
From: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>
X-Sender: mazek@arka
To: Jeff Duska <jeff@duska.com>
cc: PostgreSQL-general <pgsql-general@postgreSQL.org>, alshaver@yahoo.com
Subject: RE: [GENERAL] Future of PostgreSQL
In-Reply-To: <NDBBKBPCNJKAIKOJOPJNGEPGCKAA.jeff@duska.com>
Message-ID: <Pine.BSF.3.96.991228083230.27100J-100000@arka>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Jeff Duska wrote:
For those of you familar with Visual Studio or Delphi it would look like one
of these Visual Tools mixed with ideas from Oracle's Designer and
Microsoft's Managment Console. Is this something the group would be
instrested in?
yes!:)
Java support in the database?
Just about all the current db have support for Java in the database. As an
example, Oracle has a JServer option that can be added to Oracle 8i. Would
something like this be of intrest to the group? Or should I look at other
things?
yes!:)
Internet
Oracle, IBM and other have all kinds of different Internet technologies such
as portable version of the database -- XML, HTML export and imports,
CORBA/Application Server type support.
yes!:)
mazek
From bouncefilter Tue Dec 28 03:38:48 1999
Received: from rotec.sibnet.ru (IDENT:root@rotec-gw.sibnet.ru
[194.84.102.185])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA37187
for <pgsql-general@postgreSQL.org>;
Tue, 28 Dec 1999 03:38:37 -0500 (EST)
(envelope-from A.S.Zakharov@inp.nsk.su)
Received: from magic (magic.rotec.sibnet.ru [10.1.1.1])
by rotec.sibnet.ru (8.9.3/8.9.3) with SMTP id QAA11243
for <pgsql-general@postgreSQL.org>; Tue, 28 Dec 1999 16:45:48 +0600
Message-ID: <001f01bf510e$f2057860$0101010a@rotec.sibnet.ru>
From: "Alexei Zakharov" <A.S.Zakharov@inp.nsk.su>
To: "PostgreSQL-general" <pgsql-general@postgreSQL.org>
References: <Pine.LNX.3.96.991227121303.6398B-100000@ara.zf.jcu.cz>
Subject: Connection id?
Date: Tue, 28 Dec 1999 14:38:41 +0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Hello,
Being connected to Postgres can I get to know how many connections are
established at the moment and their ids if there are any?
Regargs,
Alexei.
From bouncefilter Tue Dec 28 06:23:49 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA65196
for <pgsql-general@postgreSQL.org>;
Tue, 28 Dec 1999 06:23:24 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
GAA08554; Tue, 28 Dec 1999 06:20:59 -0500
Date: Tue, 28 Dec 1999 11:20:58 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: Jeff Duska <jeff@duska.com>
cc: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: RE: [GENERAL] Future of PostgreSQL
In-Reply-To: <NDBBKBPCNJKAIKOJOPJNGEPGCKAA.jeff@duska.com>
Message-ID: <Pine.LNX.3.96.991228105823.1580I-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Jeff Duska wrote:
[SNIP]
Java support in the database?
Just about all the current db have support for Java in the database.
... which isnt where it belongs. java is (barely) an applications-level
language, not a systems-level language. let your app treat the data it
gets from a rdbms as an object/entity, not vice versa. i think javablend
from Sun does something like this ( creating objects from rdbms data ) and
im positive NeXT/Apple's Enterprise Objects Framework does this. GNUstep's
'DBkit' ( or whatever its called ) does the same thing, but is based on
EOF1.0. its a much, much nicer approach to the whole issue, not to
mention quite a bit more flexible and portable.
[SNIP]
Internet
Oracle, IBM and other have all kinds of different Internet technologies such
as portable version of the database -- XML, HTML export and imports,
CORBA/Application Server type support.
would be rather trivial to write an export app that dumps the data into
html format. in fact, psql does this already.
[SNIP]
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Tue Dec 28 07:18:50 1999
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net
[194.217.242.41]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA75853
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 07:18:17 -0500 (EST)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 122vZv-000NZT-0C; Tue, 28 Dec 1999 12:18:16 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id MAA05065;
Tue, 28 Dec 1999 12:15:06 GMT
Date: Tue, 28 Dec 1999 12:15:06 +0000 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: Jeff Duska <jeff@duska.com>
cc: PostgreSQL-general <pgsql-general@postgresql.org>, alshaver@yahoo.com
Subject: RE: [GENERAL] Future of PostgreSQL
In-Reply-To: <NDBBKBPCNJKAIKOJOPJNGEPGCKAA.jeff@duska.com>
Message-ID: <Pine.LNX.4.10.9912281206200.4876-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Jeff Duska wrote:
Just a few questions on the Future of PostgreSQL. I plan to play with
PostgreSQL project in the next few months. Since I am not yet knowledgable
about the internal PostgreSQL code and nor am I an database engine expert, I
thought I could work on projects that are "add-on" to PostgreSQL. All the
projects I mention will be Open Source using GPL or BSD. I've figuring GPL,
just because I have already found a lot code written in GPL. Here are the
projects I was thinking about, yet I was concerned.Administration Tools? Are the current tools acceptable? Do you want
something more?
I planning on creating add-in to jEdit that would be a Visual Database
designer tool that works with any JDBC database, including PostgreSQL. I was
also think of taking it a step farther and making it know how to talk with
PostgreSQL via a native API.
What's wrong with the existing JDBC driver? It's as close to a native api
as you can get (its internals are based on libpq).
For those of you familar with Visual Studio or Delphi it would look like one
of these Visual Tools mixed with ideas from Oracle's Designer and
Microsoft's Managment Console. Is this something the group would be
instrested in?
We already have pgaccess, but a Java based variant would IMHO be a useful
addition. You should have compatibility with pgaccess (which I believe has
forms? I've not used it, so I'm not certain on this).
I have thought about this myself, but just never had the time.
Java support in the database?
Just about all the current db have support for Java in the database. As an
example, Oracle has a JServer option that can be added to Oracle 8i. Would
something like this be of intrest to the group? Or should I look at other
things?
We did have some discussion (ok brief) a few months ago about what it
would take to implement a "PL/Java" interface for the backend. It's not
going to be an easy thing to do, but it may have some benefits. I do have
some ideas here on that subject.
Internet
Oracle, IBM and other have all kinds of different Internet technologies such
as portable version of the database -- XML, HTML export and imports,
CORBA/Application Server type support.
I'm messing around with XML & Java at the moment for TASS, and it's not
that difficult. HTML can be done as XML (The XML DTD exists for HTML).
Corba has been a common thread recently, but is hindered by which ORB to
use, and that orbs licence and porability.
On the other hand, in the source there's a simple example of using JDBC to
link simple CORBA apps to the backend.
Peter
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
From bouncefilter Tue Dec 28 07:44:50 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id HAA83523
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 07:44:18 -0500 (EST)
(envelope-from peter@retep.org.uk)
Received: from maidast.demon.co.uk ([158.152.22.37] helo=maidast.retep.org.uk)
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 122vz6-000BmJ-0A; Tue, 28 Dec 1999 12:44:16 +0000
Received: from localhost (peter@localhost [127.0.0.1])
by maidast.retep.org.uk (8.9.3/8.9.3) with ESMTP id MAA05167;
Tue, 28 Dec 1999 12:42:14 GMT
Date: Tue, 28 Dec 1999 12:42:14 +0000 (GMT)
From: Peter Mount <peter@retep.org.uk>
To: Howie <caffeine@toodarkpark.org>
cc: Jeff Duska <jeff@duska.com>,
PostgreSQL-general <pgsql-general@postgresql.org>
Subject: RE: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.LNX.3.96.991228105823.1580I-100000@rabies.toodarkpark.org>
Message-ID: <Pine.LNX.4.10.9912281228180.4876-100000@maidast.retep.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 28 Dec 1999, Howie wrote:
On Mon, 27 Dec 1999, Jeff Duska wrote:
[SNIP]
Java support in the database?
Just about all the current db have support for Java in the database.... which isnt where it belongs. java is (barely) an applications-level
language, not a systems-level language.
It's getting better and faster, but I'm not going to start that debate :-)
Lets just say that there are some sites out there that use server side
Java, and it's running virtually at the same speed as native code...
let your app treat the data it gets from a rdbms as an object/entity,
not vice versa. i think javablend from Sun does something like this (
creating objects from rdbms data ) and im positive NeXT/Apple's
Enterprise Objects Framework does this. GNUstep's 'DBkit' ( or
whatever its called ) does the same thing, but is based on EOF1.0.
its a much, much nicer approach to the whole issue, not to mention
quite a bit more flexible and portable.
There are many different techniques available. In our own driver we have a
simple Class Serialization model that maps Java Classes onto PostgreSQL
tables. It's simple, but it works.
However, I think Jeff was thinking of a PL/Java scheme, where you can
write a Java class that was callable from an SQL statement. Not everyone
would want this, but if they do, it would be an option they could compile
in.
The scheme I had in mind was to have a single JVM started by the
postmaster using JNI, and when a backend is started and first requests use
of a Java method, it starts a thread in this JVM and that thread then
remains for the lifetime of the backend servicing requests.
[SNIP]
Internet
Oracle, IBM and other have all kinds of different Internet technologies such
as portable version of the database -- XML, HTML export and imports,
CORBA/Application Server type support.would be rather trivial to write an export app that dumps the data into
html format. in fact, psql does this already.
I'd prefer XML, as its more general, and you could represent HTML as a
subset.
It would be a doddle to write a tool to build an XML DTD based on a
postgresql database.
Peter
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
From bouncefilter Tue Dec 28 08:16:51 1999
Received: from sopacsun.sopac.org.fj (sopacsun.sopac.org.fj [202.62.0.129])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA89492
for <pgsql-general@postgreSQL.org>;
Tue, 28 Dec 1999 08:15:50 -0500 (EST)
(envelope-from franck@sopac.org.fj)
Received: from sopac.org.fj (IDENT:root@[202.62.1.14])
by sopacsun.sopac.org.fj (8.9.3/8.8.7) with ESMTP id BAA13449
for <pgsql-general@postgreSQL.org>; Wed, 29 Dec 1999 01:23:34 +1300
Sender: root@sopacsun.sopac.org.fj
Message-ID: <3868B883.621886F3@sopac.org.fj>
Date: Wed, 29 Dec 1999 02:17:56 +1300
From: franck <franck@sopac.org.fj>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-22mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Arrays
References: <Pine.LNX.4.10.9912281228180.4876-100000@maidast.retep.org.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sorry for such trivia,
I have created a table containing an array, and I want to fill up the value...
create table test ( pl float8[][]); /* works */
insert into test values ('(1,2,3),(3,4,5)'); /* does not work */
does not work.... The answer in psql is array_in need to specify dimension..
help...
franck@sopac.org.fj
From bouncefilter Tue Dec 28 20:23:59 1999
Received: from bridge.penpower.com.tw (IDENT:root@[210.208.104.66])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA26646
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 20:23:10 -0500 (EST)
(envelope-from wuulong@penpower.com)
Received: from penpower.com (IDENT:wuulong@localhost [127.0.0.1])
by bridge.penpower.com.tw (8.9.3/8.9.3) with ESMTP id VAA13160
for <pgsql-general@postgresql.org>; Tue, 28 Dec 1999 21:19:19 +0800
Sender: wuulong@bridge.penpower.com.tw
Message-ID: <3868B8D6.A1822780@penpower.com>
Date: Tue, 28 Dec 1999 21:19:18 +0800
From: wuulong sheu <wuulong@penpower.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15CLE i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: subscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From bouncefilter Tue Dec 28 10:38:52 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA17939
for <pgsql-general@postgreSQL.org>;
Tue, 28 Dec 1999 10:38:17 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-18.r15.ncbrvd.InfoAve.Net [206.74.232.148])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id KAA16971;
Tue, 28 Dec 1999 10:38:10 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: "Matthew Brown" <matthew.brown@cordata.net>,
<pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] /usr/bin/wish required for install???
Date: Tue, 28 Dec 1999 10:23:27 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <002001bf50b6$a89f5ef0$b3dbf0d0@emergingsolutions.com>
In-Reply-To: <002001bf50b6$a89f5ef0$b3dbf0d0@emergingsolutions.com>
MIME-Version: 1.0
Message-Id: <99122810422501.00554@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit
On Mon, 27 Dec 1999, Matthew Brown wrote:
I am trying to install pgsql from .RPM on a MIPS box.
It gives me an error that it needs /usr/bin/wish in order to install.
Where can I get wish? I tried install Tcl as it is supposed to be a part
of that somehow, but that hasn't worked either.
The dependency on wish stems from pgaccess, part of the -tcl RPM in PostgreSQL
RPMS since 6.5. Earlier PostgreSQL RPM's depended upon postgresql-clients,
which depended upon tk being installed, etc.
There are MIPS binaries available for 6.5.3 for Japanese users at
http://alpha.or.jp/Cobalt/index.html
I would say that you could grab the source RPM for this and rebuild -- however,
you'll need to comment out the build and install areas for pgaccess -- and
change the configure options as well. Rebuilding from source requires much
more than installing the binaries.
There may be other MIPS RPM's floating around that I'm not familiar with -- if
anyone knows of these, I'd like to know as well.
I'm going to add a section on my site (http://www.ramifordistat.net/postgres)
on RPM's for non-intel machines.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Tue Dec 28 10:36:52 1999
Received: from caladan.highertech.net (root@uucp.highertech.net
[209.140.48.10]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA17738;
Tue, 28 Dec 1999 10:36:39 -0500 (EST)
(envelope-from jt-kirkpatrick@mpsllc.com)
Received: from kirkpatrickjt (whiteoak-34.highertech.net [209.140.56.34] (may
be forged))
by caladan.highertech.net (8.8.6/8.8.6) with SMTP id LAA04707;
Tue, 28 Dec 1999 11:02:14 -0500
Received: by localhost with Microsoft MAPI; Tue, 28 Dec 1999 10:40:40 -0500
Message-ID: <01BF511F.FBE3A760.jt-kirkpatrick@mpsllc.com>
From: JT Kirkpatrick <jt-kirkpatrick@mpsllc.com>
To: "'pgsql-admin@postgresql.org'" <pgsql-admin@postgresql.org>
Cc: "'pgsql-general@postgresql.org'" <pgsql-general@postgresql.org>
Subject: FW: vacuum problems
Date: Tue, 28 Dec 1999 10:40:38 -0500
Organization: MPS, LLC
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
i have re-named the ssmsact table to ssmsactold, dropped table ssmsact and
associated index, tried vacuuming again and still get the same error. i
then re-created ssmsact table and indexes w/ the SAME NAMES as used
originally, populated it with values from ssmsactold, and checked that all
values were inserted -- they were. but still get the same error message
when vacuuming! help! we need to vacuum!!!
jt
-----Original Message-----
From: JT Kirkpatrick [SMTP:jt-kirkpatrick@mpsllc.com]
Sent: Tuesday, December 28, 1999 10:00 AM
To: 'pgsql.admin@hub.org'
Subject: vacuum problems
any idea how to correct this problem? system seems to be working fine, but
nightly vacuums give us this error message:
works=> vacuum;
NOTICE: BlowawayRelationBuffers(ssmsact, 1533): block 3016 is referenced
(priva
te 0, last 0, global 1)
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally before or
while pr
ocessing the request.
We have lost the connection to the backend, so further processing is
impossible.
Terminating.
any help would be appreciated! postgres 6.4.2, rh linux 5.1 2 w/ kernel
2.2.2
jt kirkpatrick
From bouncefilter Tue Dec 28 12:11:58 1999
Received: from EmergingSolutions.com ([166.90.192.227])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA36107
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 12:11:27 -0500 (EST)
(envelope-from matthew.brown@cordata.net)
Received: from devweb5 ([208.240.219.179]) by EmergingSolutions.com with
Microsoft SMTPSVC(5.5.1877.197.19); Tue, 28 Dec 1999 11:52:27 -0500
Message-ID: <003201bf5156$c6dc31e0$b3dbf0d0@emergingsolutions.com>
From: "Matthew Brown" <matthew.brown@cordata.net>
To: <pgsql-general@postgresql.org>
Subject: Admin / client tools for Win32?
Date: Tue, 28 Dec 1999 12:12:53 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002F_01BF512C.DDD9C2B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
This is a multi-part message in MIME format.
------=_NextPart_000_002F_01BF512C.DDD9C2B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I have a web hosting client who wants SQL support, and is very used to =
using MSAccess with MS SQL Server with all the integration they have.
Can anyone point me to good GUI Win32 tools for manipulating Postgres? =
Mostly what would be needed are database diagramming tools, etc., but =
admin tools would be great, too.
Did I hear a sideways recommendation of dbKit?
Best regards,
Matthew Brown
------=_NextPart_000_002F_01BF512C.DDD9C2B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I have a web hosting client who wants =
SQL support,=20
and is very used to using MSAccess with MS SQL Server with all the =
integration=20
they have.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Can anyone point me to good GUI Win32 =
tools for=20
manipulating Postgres? Mostly what would be needed are database=20
diagramming tools, etc., but admin tools would be great, =
too.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Did I hear a sideways recommendation of =
dbKit?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Matthew =
Brown</FONT></DIV></BODY></HTML>
------=_NextPart_000_002F_01BF512C.DDD9C2B0--
From bouncefilter Tue Dec 28 16:38:56 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA86733
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 16:38:29 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
QAA09607; Tue, 28 Dec 1999 16:46:46 -0500
Date: Tue, 28 Dec 1999 21:46:46 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: Matthew Brown <matthew.brown@cordata.net>
cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Admin / client tools for Win32?
In-Reply-To: <003201bf5156$c6dc31e0$b3dbf0d0@emergingsolutions.com>
Message-ID: <Pine.LNX.3.96.991228214517.1580M-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 28 Dec 1999, Matthew Brown wrote:
I have a web hosting client who wants SQL support, and is very used to
using MSAccess with MS SQL Server with all the integration they have.Can anyone point me to good GUI Win32 tools for manipulating Postgres?
Mostly what would be needed are database diagramming tools, etc., but
admin tools would be great, too.
cant you use MS-Access with the pgsql odbc driver? i could've sworn a
coworker was doing something similar, but i dont run MS products or
operating system(s).
[SNIP]
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Tue Dec 28 21:41:00 1999
Received: from customer.cwhkt.com.tw (customer.cwhkt.com.tw [202.84.146.6])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA42242
for <pgsql-general@postgresql.org>;
Tue, 28 Dec 1999 21:40:57 -0500 (EST)
(envelope-from wuulong@penpower.com.tw)
Received: from penpower.com.tw ([210.208.104.1])
by customer.cwhkt.com.tw (8.9.3/8.9.3) with SMTP id KAA11384
for <pgsql-general@postgresql.org>; Wed, 29 Dec 1999 10:50:54 +0800
Received: from penpower.com.tw [210.208.104.62] by penpower.com.tw
[210.208.104.1] with SMTP (MDaemon.v2.7.SP4.R) for
<pgsql-general@postgresql.org>; Wed, 29 Dec 1999 10:45:46 +0800
Message-ID: <38697430.B3C5F24E@penpower.com.tw>
Date: Wed, 29 Dec 1999 10:38:40 +0800
From: =?iso-8859-1?Q?=AAZ=C0s?= <wuulong@penpower.com.tw>
Organization: penpower
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: postgres <pgsql-general@postgresql.org>
Subject: SQL command Question : Copy from File
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MDaemon-Deliver-To: pgsql-general@postgresql.org
X-Return-Path: wuulong@penpower.com.tw
Does Copy from file Support Chinese ?
I have a file and data like this : ( second row is chinese )
1234,�s�˥�
5678,�x�_��
my table "phrase" schema is ( id int4 , phrase char(30))
my SQL command is
Copy phrase from 'filename' using delimiter ',';
return message is Copy.
and result in data is have same row insert but all empty include first
int4 column ?
my postgresql version is 6.4
Have idea about this question , Please let me know thanks.
--
wuulong Sheu ( �\�Z�s ) - PGP , HTML mail is welcome
�X���� - PEN POWER TECHNOLOGY LTD.(www.penpower.com.tw)
wuulong@penpower.com.tw (O)035722691-362 (M)0923135231 (icq)11934112
From bouncefilter Wed Dec 29 10:24:08 1999
Received: from smtp.access1.net (smtp.access1.net [206.13.101.40])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA90690
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 10:23:35 -0500 (EST)
(envelope-from ccthomas@access1.net)
Received: from bsdone.SAMBA [205.253.113.16] by smtp.access1.net
(SMTPD32-5.01) id A73A859E00D0; Wed, 29 Dec 1999 07:22:34 PDT
Sender: mysql
Message-ID: <38697F48.2781E494@access1.net>
Date: Tue, 28 Dec 1999 22:26:00 -0500
From: Courtney Thomas <ccthomas@access1.net>
X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 3.3-RELEASE i386)
MIME-Version: 1.0
To: Thomas Antepoth <t_antepoth@hamm.netsurf.de>
CC: Matthew Brown <matthew.brown@cordata.net>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Admin / client tools for Win32?
References: <Pine.LNX.4.21.9912290636160.20325-100000@sofa.c-c.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id KAA90753
Greetings !
Where can I get info on "pgaccess" ?
Thanks,
Courtney
-------------------------------------------------------------
Thomas Antepoth wrote:
Hi Mat,
On Tue, 28 Dec 1999, Matthew Brown wrote:
I have a web hosting client who wants SQL support, and is very used
to using MSAccess with MS SQL Server with all the integration they have.read: incompatibility in means of cross platform environments.
Can anyone point me to good GUI Win32 tools for manipulating Postgres?
Mostly what would be needed are database diagramming tools, etc.,
but admin tools would be great, too.You might try using the ODBC Driver kit for Postgres.
It performs well and it does the trick connecting a WIN32
Application to a Postgres Server.One pitfall still exists: If you don�t define your
Primary keys well, MS-Access97 will cast out queries
like:
select blah from blub where
field1=... and field2=... and field3=... and fieldn or
field1=... and ... or
field1=...Imagine what this does to your Postgres Server.
Here in our environment the postmaster inflates up to
40 Megs of Mem-Usage and drains all CPU even if
opening a table just for viewing.SQL7.0 instead seems to optimize these
ridiculous queries quite well.If you want the best cross platform utility you
might try pgaccess (it runs under TCL/TK) and
should run on WIN32 Clients as well.Did I hear a sideways recommendation of dbKit?
Never heard of it. What is it?
t++
--
This mail had been created using Linux. It is therefore free of all
Microsoft(tm) OS based virii, conforms with almost any widely recognized
open standards and is best read with *any* mailclient using fixed fonts.
Spam is processed at the modest price of $500 only at this site.************
From bouncefilter Wed Dec 29 01:02:02 1999
Received: from sofa.c-c.de (line7.hamm.netsurf.de [195.180.80.7])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA84056
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 01:01:56 -0500 (EST)
(envelope-from t_antepoth@hamm.netsurf.de)
Received: from sofa.c-c.de (t_antepoth@sofa.c-c.de [192.168.100.254])
by sofa.c-c.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id
GAA20478; Wed, 29 Dec 1999 06:54:15 +0100
Date: Wed, 29 Dec 1999 06:54:15 +0100 (CET)
From: Thomas Antepoth <t_antepoth@hamm.netsurf.de>
X-Sender: t_antepoth@sofa.c-c.de
To: Matthew Brown <matthew.brown@cordata.net>
cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Admin / client tools for Win32?
In-Reply-To: <003201bf5156$c6dc31e0$b3dbf0d0@emergingsolutions.com>
Message-ID: <Pine.LNX.4.21.9912290636160.20325-100000@sofa.c-c.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id BAA84058
Hi Mat,
On Tue, 28 Dec 1999, Matthew Brown wrote:
I have a web hosting client who wants SQL support, and is very used
to using MSAccess with MS SQL Server with all the integration they have.
read: incompatibility in means of cross platform environments.
Can anyone point me to good GUI Win32 tools for manipulating Postgres?
Mostly what would be needed are database diagramming tools, etc.,
but admin tools would be great, too.
You might try using the ODBC Driver kit for Postgres.
It performs well and it does the trick connecting a WIN32
Application to a Postgres Server.
One pitfall still exists: If you don�t define your
Primary keys well, MS-Access97 will cast out queries
like:
select blah from blub where
field1=... and field2=... and field3=... and fieldn or
field1=... and ... or
field1=...
Imagine what this does to your Postgres Server.
Here in our environment the postmaster inflates up to
40 Megs of Mem-Usage and drains all CPU even if
opening a table just for viewing.
SQL7.0 instead seems to optimize these
ridiculous queries quite well.
If you want the best cross platform utility you
might try pgaccess (it runs under TCL/TK) and
should run on WIN32 Clients as well.
Did I hear a sideways recommendation of dbKit?
Never heard of it. What is it?
t++
--
This mail had been created using Linux. It is therefore free of all
Microsoft(tm) OS based virii, conforms with almost any widely recognized
open standards and is best read with *any* mailclient using fixed fonts.
Spam is processed at the modest price of $500 only at this site.
From bouncefilter Wed Dec 29 02:33:03 1999
Received: from rotec.sibnet.ru (IDENT:root@rotec-gw.sibnet.ru
[194.84.102.185])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA00852
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 02:32:44 -0500 (EST)
(envelope-from A.S.Zakharov@inp.nsk.su)
Received: from magic (magic.rotec.sibnet.ru [10.1.1.1])
by rotec.sibnet.ru (8.9.3/8.9.3) with SMTP id PAA15301;
Wed, 29 Dec 1999 15:40:11 +0600
Message-ID: <001301bf51ce$e2a46280$0101010a@rotec.sibnet.ru>
From: "Alexei Zakharov" <A.S.Zakharov@inp.nsk.su>
To: "soundar rajan" <psrajan@yahoo.com>
Cc: "PostgreSQL-general" <pgsql-general@postgreSQL.org>
References: <19991228150036.4199.qmail@web2103.mail.yahoo.com>
Subject: Re: [GENERAL] Connection id?
Date: Wed, 29 Dec 1999 13:32:38 +0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
----- Original Message -----
From: soundar rajan <psrajan@yahoo.com>
To: Alexei Zakharov <A.S.Zakharov@inp.nsk.su>
Sent: Tuesday, December 28, 1999 9:00 PM
Subject: Re: [GENERAL] Connection id?
When I tried it with (Linux), it says ...
ps -ax | grep psql
But, I don't really know this is what u needed ?
Not quite that. I need the same but with the SQL statement. Suppose I
established a connection to Postgres and I'd like to know who else is
connected. I write 'SELECT ...' (I really don't know what) and get this
information. Is that possible?
Regards,
Alexei.
From bouncefilter Tue Dec 28 19:41:58 1999
Received: from cuaima.ica.luz.ve (vegeta@cuaima.ica.luz.ve [150.185.194.30])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA20168
for <pgsql-general@postgreSQL.org>;
Tue, 28 Dec 1999 19:41:08 -0500 (EST)
(envelope-from vegeta@cuaima.ica.luz.ve)
Received: from localhost (vegeta@localhost)
by cuaima.ica.luz.ve (8.8.8/8.8.8) with ESMTP id EAA03867
for <pgsql-general@postgreSQL.org>; Wed, 29 Dec 1999 04:44:18 -0400
Date: Wed, 29 Dec 1999 04:44:17 -0400 (VET)
From: Vegeta <vegeta@cuaima.ica.luz.ve>
To: pgsql-general@postgreSQL.org
Subject: using password protection in pgtcl
Message-ID: <Pine.LNX.4.05.9912290439420.3859-100000@cuaima.ica.luz.ve>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I want to use the pg_connect function of pgtcl on a database that requires
password authentication. Is there an option of pg_connect that allows
passing a username and password to make the connection?
Thanks,
Vegeta
From bouncefilter Wed Dec 29 08:18:08 1999
Received: from cc.owu.edu (cc.owu.edu [192.68.223.1])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA65938
for <pgsql-general@hub.org>; Wed, 29 Dec 1999 08:18:02 -0500 (EST)
(envelope-from RMBOWATT@CC.OWU.EDU)
Received: from CC.OWU.EDU by CC.OWU.EDU (PMDF V5.1-12 #20255)
id <01JK2FFZZAU8000TU4@CC.OWU.EDU> for pgsql-general@hub.org; Wed,
29 Dec 1999 08:19:14 EDT
Date: Wed, 29 Dec 1999 08:19:14 -0400 (EDT)
From: Vis Bowatte <rmbowatt@CC.OWU.EDU>
Subject: Re: pgsql-general-digest V1 #582
In-reply-to: <199912290402.XAA57472@hub.org>
To: pgsql-general@hub.org
Message-id: <Pine.PMDF.3.95.991229081905.38668E-100000@CC.OWU.EDU>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
unsubscribe
From bouncefilter Wed Dec 29 10:17:15 1999
Received: from 165.201.21.73 (dt99fn22.dot.state.ks.us [165.201.21.73])
by hub.org (8.9.3/8.9.3) with SMTP id KAA89646
for <pgsql-general@postgresql.org>;
Wed, 29 Dec 1999 10:16:11 -0500 (EST)
(envelope-from Steven@ksdot.org)
Received: from DTGATE-Message_Server by 165.201.21.73
with Novell_GroupWise; Wed, 29 Dec 1999 09:14:49 -0600
Message-Id: <s869d109.028@165.201.21.73>
X-Mailer: Novell GroupWise 5.5.2
Date: Wed, 29 Dec 1999 09:14:32 -0600
From: "Steven Pennie" <Steven@ksdot.org>
To: <pgsql-general@postgresql.org>
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id KAA89751
unsubscribe
end
From bouncefilter Wed Dec 29 11:23:09 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA05647
for <pgsql-general@postgresql.org>;
Wed, 29 Dec 1999 11:22:18 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.74.113]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 29 Dec 1999 10:13:24 -0600
Sender: ed
Message-ID: <386A3577.66BCC4B5@austin.rr.com>
Date: Wed, 29 Dec 1999 10:23:19 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jochen Topf <pgsql-general@mail.remote.org>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
References: <19991123085929.A2440@eldorado.remote.org>
<003701bf35d2$5074cf20$040101c0@p2400arcane>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
My question of an earlier posting is still not answered. Does anybody
here,
who reported PostgreSQL to be very stable, use advanced features like
pl/pgsql
procedures, triggers, rules and notifies? Lets have a show of hands. I
would
really like to know, why I am the only one having problems. :-) Although
it might be, because, as this is a PostgreSQL mailing list, most of the
readers are people who are happy with PostgreSQL, because all the others
have left and are on an Oracle list now. :-)
I use triggers, PL/pgSQL procedures/functions, and rules on 6.5.2, and I have
experienced a number of what might be called instability problems for whatever
reason. A review of the posts to the pgsql mailing lists will confirm that you
are not alone in finding some points of instability. But the extent of any
instability is not clear. Watch for a web poll announcement in January to get
a better handle on that data...
Cheers,
Ed Loehr
From bouncefilter Wed Dec 29 12:03:09 1999
Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net
[207.217.120.22]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA17139
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 12:02:28 -0500 (EST)
(envelope-from aardvark@ibm.net)
Received: from fries (1Cust221.tnt2.altoona.pa.da.uu.net [63.24.4.221])
by hawk.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id JAA21391
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 09:02:26 -0800 (PST)
From: "Barnes" <aardvark@ibm.net>
Cc: <pgsql-general@postgreSQL.org>
Subject: RE: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
Date: Wed, 29 Dec 1999 12:04:02 -0500
Message-ID: <001701bf521e$b5860920$0a64a8c0@fries>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <386A3577.66BCC4B5@austin.rr.com>
It would be helpful to me to hear about successful and stable
implementations as well. If some of you who are using PostgreSQL
successfully could comment on your experiences, I think it would shed some
worthwhile light on it's capabilities. I'm considering using it for a
mission critical project, and I would like to know what I am getting into.
Thank you.
David Barnes
-----Original Message-----
From: owner-pgsql-general@postgreSQL.org
[mailto:owner-pgsql-general@postgreSQL.org]On Behalf Of Ed Loehr
Sent: Wednesday, December 29, 1999 11:23 AM
To: Jochen Topf
Cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
My question of an earlier posting is still not answered. Does anybody
here,
who reported PostgreSQL to be very stable, use advanced features like
pl/pgsql
procedures, triggers, rules and notifies? Lets have a show of hands. I
would
really like to know, why I am the only one having problems. :-) Although
it might be, because, as this is a PostgreSQL mailing list, most of the
readers are people who are happy with PostgreSQL, because all the others
have left and are on an Oracle list now. :-)
I use triggers, PL/pgSQL procedures/functions, and rules on 6.5.2, and I
have
experienced a number of what might be called instability problems for
whatever
reason. A review of the posts to the pgsql mailing lists will confirm that
you
are not alone in finding some points of instability. But the extent of any
instability is not clear. Watch for a web poll announcement in January to
get
a better handle on that data...
Cheers,
Ed Loehr
************
From bouncefilter Wed Dec 29 12:44:10 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA25857
for <pgsql-general@postgresql.org>;
Wed, 29 Dec 1999 12:44:06 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.74.113]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 29 Dec 1999 11:35:22 -0600
Sender: ed
Message-ID: <386A48AE.1F4FF6C8@austin.rr.com>
Date: Wed, 29 Dec 1999 11:45:18 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Barnes <aardvark@ibm.net>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
References: <001701bf521e$b5860920$0a64a8c0@fries>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Barnes wrote:
It would be helpful to me to hear about successful and stable
implementations as well. If some of you who are using PostgreSQL
successfully could comment on your experiences, I think it would shed some
worthwhile light on it's capabilities. I'm considering using it for a
mission critical project, and I would like to know what I am getting into.
BTW, I also still think pgsql the best thing going for open source RDBMS if you
need transactions and can't spend $20K-$25K for Oracle. And I have found the
folks on the mailing lists to be critically helpful to working through some
non-trivial issues (as well as a bonehead mistake or two). I also think the
system is rapidly becoming more stable/mature, though I don't think you can
count on problem-free operation (as of 6.5.2/3) just yet. But I'm still
betting on pgsql...
Cheers,
Ed Loehr
From bouncefilter Wed Dec 29 13:47:10 1999
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA38157
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 13:46:16 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id OAA20874;
Wed, 29 Dec 1999 14:45:15 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 29 Dec 1999 14:45:15 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
cc: Howie <caffeine@toodarkpark.org>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.LNX.3.96.991227123408.6398C-100000@ara.zf.jcu.cz>
Message-ID: <Pine.BSF.4.21.9912291436270.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 27 Dec 1999, Karel Zak - Zakkr wrote:
- raw i/o device storage manager
I can't see this ever happening, since it would require having to write
low-level device drivers, vs using what the OS already has ...
One thing someone *did* mention though was that Linux(?) now has (or is
working on?) low level functions to do this...I'm not sure what would be
involved to use this functionatilty though...anyone in the Linux camp able
to respond?
Basically, if "low_level_read()" was found by configure, add in the
functionality? Something like that?
Just curious though...how do you monitor something like that? Say I do
this on a 4gig file system, and it fills up? Then what?
From what I've read in Oracle manuals, the benefits of doing raw-I/O don't
outweigh the headaches of implementing it, but if it is something that
someone wants and can implement cleanly at an *operating system* level
(similar to the Linux function calls someone previously mentioned), then
there appears to be little disadvantages ...
... but if we have to create and maintain our own device drivers, then the
headaches (long term) are definitely not worth it, since if the person
that did the driver decides to bog off, we're left with code that isn't
supported, and in an Open Source project, that means code that will
generally die and get removed :(
- replication
This is something that alot of ppl want/are interested in...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Dec 29 14:21:11 1999
Received: from gtv.ca (h139-142-238-17.cg.fiberone.net [139.142.238.17])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA45280
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 14:20:33 -0500 (EST)
(envelope-from aaron@genisys.ca)
Received: from stilborne (24.67.90.252.ab.wave.home.com [24.67.90.252])
by gtv.ca (8.9.3/8.8.7) with SMTP id NAA05782
for <pgsql-general@postgreSQL.org>; Wed, 29 Dec 1999 13:30:23 -0700
From: "Aaron J. Seigo" <aaron@gtv.ca>
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Future of PostgreSQL
Date: Wed, 29 Dec 1999 11:59:25 -0700
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <Pine.BSF.4.21.9912291436270.18498-100000@thelab.hub.org>
In-Reply-To: <Pine.BSF.4.21.9912291436270.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Message-Id: <99122912183800.13974@stilborne>
Content-Transfer-Encoding: 8bit
hi...
One thing someone *did* mention though was that Linux(?) now has (or is
working on?) low level functions to do this...I'm not sure what would be
involved to use this functionatilty though...anyone in the Linux camp able
to respond?
the latest raw i/o patches for 2.2 and 2.3 were released in august (by Stephen
C. Tweedie).. they are available at:
ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-io/
while these mods were designed w/Linus Torvalds and passed as OK by him, the
big question still remains as to whether this will ever make it into the main
kernel distribution...
and that probably is not going to happen unless/until there is a change of
heart in the kernel development leadership... a direct quote from Linus
Torvalds:
"I do not believe in raw IO - even for streaming audio it's just too common for
the data to have been available in the cache, and by using raw IO you (for
absolutely no good reason) just made the machine do more IO than it should
have.
There are very specific cases where the application knows that its dataset is
larger than physical memory, but those tend to be limited to quite large
problems. And they're getting larger. "
so, while the patches are there and "officially sanctioned" as it were, it
probably won't be a standard issue item and will remain in the form of patches
you have to fetch and apply yourself...
for the people who will benefit from raw io, however, this probably won't be a
huge issue as their installations will probably be highly tuned and tweaked
anyways..
in short: the support is there for raw io in the linux kernel, just not the
standard distribution. it will probably remain for as long as there is interest
(which seems to mostly come from database concerns)..
--
Aaron J. Seigo
From bouncefilter Wed Dec 29 14:08:12 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA43554
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 14:08:08 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id OAA14487;
Wed, 29 Dec 1999 14:04:58 -0500
Message-ID: <386A5BBD.71375361@mascari.com>
Date: Wed, 29 Dec 1999 14:06:37 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Barnes <aardvark@ibm.net>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
References: <001701bf521e$b5860920$0a64a8c0@fries>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Barnes wrote:
It would be helpful to me to hear about successful and stable
implementations as well. If some of you who are using PostgreSQL
successfully could comment on your experiences, I think it would shed some
worthwhile light on it's capabilities. I'm considering using it for a
mission critical project, and I would like to know what I am getting into.
Thank you.David Barnes
We've used it successfully in a production environment (24 x
7) for over a year now. Simply reading the mailing list will
greatly improve your chances of success. The problems with
PostgreSQL can be avoided if you know, in advance, what to
avoid. But must people don't. Here's my list of things which
can get you into trouble:
0. Running with fsync on - There is the probability that
modified records written into kernel buffers but not written
to disk could exist at the moment of an operating system
crash. Therefore, PostgreSQL's default mode is to run with
fsync() on. This slows down the database by (quite
literally) several orders of magnitude. We've run with fsync
off (-o -F) without a problem. Dump/Reload of large
databases with fsync() on really tests one's pain threshold.
If you trust your OS, run with it off.
1. Making use of oids - Problems with dumping/restoring oids
make this development path dangerous. Most people use the
SERIAL data type to generate primary keys. However, SERIAL
itself has some peculiarities, since it just auto-creates a
sequence. Dropping the associated table doesn't drop the
sequence (IIRC), so scripted or automated schema creation
may not be obvious. I prefer to manually use a sequence and
an int4 type for primary keys. In fact, you could use the
same sequence for all of your primary keys, if you aren't
exposing the value to the user in any meaningful way, and
don't plan to hit the 4.2 billion limit of int4 soon, and
don't care about gaps...(although a purist would argue, and
I agree, that IF you are going to use generated keys THEN
the key should have no more meaning then that it refers to
a record).
2. Using views created with large queries - Views use the
rewrite system and rules to rewrite a query against it to
properly fetch data from the underlying tables. Because
there is currently a limit on the size of a single database
record (8192 bytes), the queries associated with views can
only be so big. In addition, you can get into trouble if
views are built on top of user-defined functions, which is a
common thing to do. If you drop/recreate the underlying
function, then the view needs to be dropped and recreated as
well. In addition, I've had trouble with dump/reload of
views in the past, and have always kept my schema in
separate views.sql script, just in case...
3. Using non-standard types - Because of problems with data
comparisons, type coercion and spaces, we avoided types such
as bpchar, char, and even text. We avoided text since ODBC
clients could not determine maximum field width. We also
avoided all of the non-4 byte integer types, such as int2.
This is because the default type coercion (sp?) code in the
past has had trouble being smart enough to use indexes when
given a SELECT such as:
CREATE TABLE y (x text, z int2);
SELECT x FROM y WHERE z = 3;
because the 3 would be coerced to an int4 and, if z was an
int2, would result in a sequential scan, whereas:
SELECT x FROM y WHERE z = '3';
would use the index since it is initially parsed as a string
and coerced properly at a later point. I think much of this
has been fixed, but nevertheless... In addition, our
varchar() types are pretty much under the 255 limit since
some ODBC clients have problems with varchar() types greater
than 255. We only use: int4, varchar, datetime, and float8.
On rare occasion, we'll use text for free-form information,
but we NEVER index it. Although its VERY tempting, (and
PostgreSQL itself uses them), we avoid arrays.
4. Be careful about user-defined functions/triggers -
PostgreSQL keeps track of everything by its oid, not by name
(which would obviously be too slow). But, unfortunately, it
does not yet support the modification of functions, allowing
the function to retain its original oid (or perform a
cascading update - it will be nice when RI is integrated
into the system catalogue!). As a result, odd things can
happen if you drop and recreate a function. For example, you
could have a trigger call a procedural language which, in
turn, could select from a view, from which one of the
attributes is the result of a function. If you
dropped/recreated that function, things go a bit weird and
usually result in an error such as "function not in cache".
5. Using DDL statements in transactions - PostgreSQL has
trouble rolling back transactions which have aborted which
contain DDL statements. As a result, you might find yourself
having to delete a filesystem file, because, even though a
TABLE create might have been rolled back as far as the
system catalogue is concerned, the underlying file might
still manage to exist. Or worse, rollback of index
DROP/CREATE in a transaction yields erroneous results.
6. Using indexes on large fields - Apparently the code
requires 3 tuples per page (or something like that) for the
index to function properly. This can include plpgsql source,
so be careful. We never index on anything larger than 255,
but I believe around 2.8K is the limit before tickling
bugs...
7. Using INSERTS instead of COPY - Even when you have
fsync() off and are running INSERT statements in a
transaction, the processing of individual INSERT statements
by the thousands is also several orders of magnitude slower
than COPY. We have large mainframe datasets which we import
nightly - we first covert them to data appropriate for COPY
and then COPY them in, instead INSERT's record by record.
The problem with COPY is it runs as user postgres, so you
need to have the data files readable by user postgres.
8. Not running VACUUM - PostgreSQL won't use indexes, or
won't optimize correctly unless the record count and
dispersion estimates are up-to-date. People have reported
problems with running vacuum while under heavy load. We
haven't seen it, but we run vacuum each night at 4:05 a.m.
However, if you perform a LARGE number of INSERTS/UPDATES,
it is better for you to do the following:
DROP INDEX index_on_heavilty_used_table;
VACUUM ANALYZE;
CREATE INDEX index_on_heavily_used_table;
Because VACUUM will sit there, and, row by row, essentially
"defragment" your indexes, which can take damn near forever
for any number of updates or deletes greater than, say,
30,000 rows.
9. ALTER TABLE ADD COLUMN - Its better to rebuild the table
by hand then to use this DDL statement. First off, any
column constraints (such as NOT NULL), will silently
ignored, and secondly, inherited relations have problems
with dump/restore.
10. IN, INTERSECT, EXCEPT - When writing your application,
these SQL functions seem nice, particularly since the data
in your design database may be small, initially. But all
three of these SQL expressions (whatever) force a nested
sequential scan on the relation. For example:
emptoris=> explain SELECT employee FROM employees WHERE
employee NOT IN (SELECT webuser FROM webusers);
NOTICE: QUERY PLAN:
Seq Scan on employees (cost=3.95 rows=59 width=12)
SubPlan
-> Seq Scan on webusers (cost=7.78 rows=145 width=12)
EXPLAIN
Since INTERSECT/EXCEPT rewrite the query to use IN, the
problem exists with them as well. And since PostgreSQL does
not yet have outer joins, you should instead write the query
using a correlated sub query (EXISTS):
emptoris=> explain SELECT employee FROM employees WHERE NOT
EXISTS (SELECT webuser FROM webusers WHERE webusers.webuser
= employees.employee);
NOTICE: QUERY PLAN:
Seq Scan on employees (cost=3.95 rows=59 width=12)
SubPlan
-> Index Scan using k_webusers1 on webusers (cost=2.05
rows=1 width=12)
EXPLAIN
There are many more such things which, if avoided, allow
PostgreSQL to work great. But with each release, a lot of
these things become obsolete.
Mike Mascari
From bouncefilter Wed Dec 29 13:24:10 1999
Received: from picasso.realtyideas.com (IDENT:kaiq@207-18-128-210.flex.net
[207.18.128.210]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA32272
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 13:23:14 -0500 (EST)
(envelope-from kaiq@picasso.realtyideas.com)
Received: from localhost (kaiq@localhost)
by picasso.realtyideas.com (8.9.3/8.9.3) with ESMTP id NAA21531
for <pgsql-general@postgreSQL.org>; Wed, 29 Dec 1999 13:16:39 -0600
Date: Wed, 29 Dec 1999 13:16:39 -0600 (CST)
From: <kaiq@realtyideas.com>
To: pgsql-general@postgreSQL.org
Subject: array in PG and M$ SQl server 7
In-Reply-To: <386A3577.66BCC4B5@austin.rr.com>
Message-ID: <Pine.LNX.4.10.9912291216530.20769-100000@picasso.realtyideas.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
hi, there, I have an "ugly" question:
I need to design a table, seems good
for using array (ok, I know I'd better think it twice for using it ;-)
the application should be as portable as possible for Oracle and Sql
server7. I know the difference between oracle's and pg's array, but
I do not know sql server7's. any ideas?
thanks
From bouncefilter Wed Dec 29 14:25:11 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA45900
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 14:24:40 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id OAA14558;
Wed, 29 Dec 1999 14:21:20 -0500
Message-ID: <386A5F94.85976A32@mascari.com>
Date: Wed, 29 Dec 1999 14:23:00 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
CC: Karel Zak - Zakkr <zakkr@zf.jcu.cz>, Howie <caffeine@toodarkpark.org>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <Pine.BSF.4.21.9912291436270.18498-100000@thelab.hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The Hermit Hacker wrote:
On Mon, 27 Dec 1999, Karel Zak - Zakkr wrote:
- raw i/o device storage manager
I can't see this ever happening, since it would require having to write
low-level device drivers, vs using what the OS already has ...One thing someone *did* mention though was that Linux(?) now has (or is
working on?) low level functions to do this...I'm not sure what would be
involved to use this functionatilty though...anyone in the Linux camp able
to respond?Basically, if "low_level_read()" was found by configure, add in the
functionality? Something like that?
I haven't used raw partitions on ORACLE, but I believe its
something like:
CREATE TABLESPACE ADD DATAFILE '/dev/sda1';
instead of:
CREATE TABLESPACE ADD DATAFILE
'/home/oracle7/dbs/moredata.dbs';
so all ORACLE is doing is maintaining its own "filesystem"
on top of either block special devices or filesystem files
using read(), write(), fcntl() and ioctl(). Since you have
to specify before-hand how much data to allocate, ORACLE
will preallocate '/home/oracle/dbs/moredata.dbs' as 100M, or
whatever. In the case of a special block device, it uses the
entire partition. This allows you to put your "HOT" data on,
say a mirrored RAID0+1 partition, and leave the rarely
accessed stuff lie around as files on the filesystem.
Just curious though...how do you monitor something like that? Say I do
this on a 4gig file system, and it fills up? Then what?
You had to SELECT from a system catalogue under version 6.0
- or use monitoring tools. I think ORACLE added
automatically extensible tablespaces in version 7, although
I suppose RAW partitions couldn't work that way. When it
filled up, you would log into SQL*DBA and do a:
ALTER TABLESPACE ADD DATAFILE '/dev/sda2';
to add another partition. That's why DBA's get the big
bucks....right?
Mike Mascari
From bouncefilter Wed Dec 29 14:46:11 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA51512
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 14:45:41 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA08391;
Wed, 29 Dec 1999 14:45:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912291945.OAA08391@candle.pha.pa.us>
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
In-Reply-To: <386A5BBD.71375361@mascari.com> from Mike Mascari at "Dec 29,
1999
02:06:37 pm"
To: Mike Mascari <mascarm@mascari.com>
Date: Wed, 29 Dec 1999 14:45:13 -0500 (EST)
CC: Barnes <aardvark@ibm.net>, pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This is a great list. I have addressed the oid/sequence issue in my
book, chapter 7.
Barnes wrote:
It would be helpful to me to hear about successful and stable
implementations as well. If some of you who are using PostgreSQL
successfully could comment on your experiences, I think it would shed some
worthwhile light on it's capabilities. I'm considering using it for a
mission critical project, and I would like to know what I am getting into.
Thank you.David Barnes
We've used it successfully in a production environment (24 x
7) for over a year now. Simply reading the mailing list will
greatly improve your chances of success. The problems with
PostgreSQL can be avoided if you know, in advance, what to
avoid. But must people don't. Here's my list of things which
can get you into trouble:0. Running with fsync on - There is the probability that
modified records written into kernel buffers but not written
to disk could exist at the moment of an operating system
crash. Therefore, PostgreSQL's default mode is to run with
fsync() on. This slows down the database by (quite
literally) several orders of magnitude. We've run with fsync
off (-o -F) without a problem. Dump/Reload of large
databases with fsync() on really tests one's pain threshold.
If you trust your OS, run with it off.1. Making use of oids - Problems with dumping/restoring oids
make this development path dangerous. Most people use the
SERIAL data type to generate primary keys. However, SERIAL
itself has some peculiarities, since it just auto-creates a
sequence. Dropping the associated table doesn't drop the
sequence (IIRC), so scripted or automated schema creation
may not be obvious. I prefer to manually use a sequence and
an int4 type for primary keys. In fact, you could use the
same sequence for all of your primary keys, if you aren't
exposing the value to the user in any meaningful way, and
don't plan to hit the 4.2 billion limit of int4 soon, and
don't care about gaps...(although a purist would argue, and
I agree, that IF you are going to use generated keys THEN
the key should have no more meaning then that it refers to
a record).2. Using views created with large queries - Views use the
rewrite system and rules to rewrite a query against it to
properly fetch data from the underlying tables. Because
there is currently a limit on the size of a single database
record (8192 bytes), the queries associated with views can
only be so big. In addition, you can get into trouble if
views are built on top of user-defined functions, which is a
common thing to do. If you drop/recreate the underlying
function, then the view needs to be dropped and recreated as
well. In addition, I've had trouble with dump/reload of
views in the past, and have always kept my schema in
separate views.sql script, just in case...3. Using non-standard types - Because of problems with data
comparisons, type coercion and spaces, we avoided types such
as bpchar, char, and even text. We avoided text since ODBC
clients could not determine maximum field width. We also
avoided all of the non-4 byte integer types, such as int2.
This is because the default type coercion (sp?) code in the
past has had trouble being smart enough to use indexes when
given a SELECT such as:CREATE TABLE y (x text, z int2);
SELECT x FROM y WHERE z = 3;
because the 3 would be coerced to an int4 and, if z was an
int2, would result in a sequential scan, whereas:SELECT x FROM y WHERE z = '3';
would use the index since it is initially parsed as a string
and coerced properly at a later point. I think much of this
has been fixed, but nevertheless... In addition, our
varchar() types are pretty much under the 255 limit since
some ODBC clients have problems with varchar() types greater
than 255. We only use: int4, varchar, datetime, and float8.
On rare occasion, we'll use text for free-form information,
but we NEVER index it. Although its VERY tempting, (and
PostgreSQL itself uses them), we avoid arrays.4. Be careful about user-defined functions/triggers -
PostgreSQL keeps track of everything by its oid, not by name
(which would obviously be too slow). But, unfortunately, it
does not yet support the modification of functions, allowing
the function to retain its original oid (or perform a
cascading update - it will be nice when RI is integrated
into the system catalogue!). As a result, odd things can
happen if you drop and recreate a function. For example, you
could have a trigger call a procedural language which, in
turn, could select from a view, from which one of the
attributes is the result of a function. If you
dropped/recreated that function, things go a bit weird and
usually result in an error such as "function not in cache".5. Using DDL statements in transactions - PostgreSQL has
trouble rolling back transactions which have aborted which
contain DDL statements. As a result, you might find yourself
having to delete a filesystem file, because, even though a
TABLE create might have been rolled back as far as the
system catalogue is concerned, the underlying file might
still manage to exist. Or worse, rollback of index
DROP/CREATE in a transaction yields erroneous results.6. Using indexes on large fields - Apparently the code
requires 3 tuples per page (or something like that) for the
index to function properly. This can include plpgsql source,
so be careful. We never index on anything larger than 255,
but I believe around 2.8K is the limit before tickling
bugs...7. Using INSERTS instead of COPY - Even when you have
fsync() off and are running INSERT statements in a
transaction, the processing of individual INSERT statements
by the thousands is also several orders of magnitude slower
than COPY. We have large mainframe datasets which we import
nightly - we first covert them to data appropriate for COPY
and then COPY them in, instead INSERT's record by record.
The problem with COPY is it runs as user postgres, so you
need to have the data files readable by user postgres.8. Not running VACUUM - PostgreSQL won't use indexes, or
won't optimize correctly unless the record count and
dispersion estimates are up-to-date. People have reported
problems with running vacuum while under heavy load. We
haven't seen it, but we run vacuum each night at 4:05 a.m.
However, if you perform a LARGE number of INSERTS/UPDATES,
it is better for you to do the following:DROP INDEX index_on_heavilty_used_table;
VACUUM ANALYZE;
CREATE INDEX index_on_heavily_used_table;Because VACUUM will sit there, and, row by row, essentially
"defragment" your indexes, which can take damn near forever
for any number of updates or deletes greater than, say,
30,000 rows.9. ALTER TABLE ADD COLUMN - Its better to rebuild the table
by hand then to use this DDL statement. First off, any
column constraints (such as NOT NULL), will silently
ignored, and secondly, inherited relations have problems
with dump/restore.10. IN, INTERSECT, EXCEPT - When writing your application,
these SQL functions seem nice, particularly since the data
in your design database may be small, initially. But all
three of these SQL expressions (whatever) force a nested
sequential scan on the relation. For example:emptoris=> explain SELECT employee FROM employees WHERE
employee NOT IN (SELECT webuser FROM webusers);
NOTICE: QUERY PLAN:Seq Scan on employees (cost=3.95 rows=59 width=12)
SubPlan
-> Seq Scan on webusers (cost=7.78 rows=145 width=12)EXPLAIN
Since INTERSECT/EXCEPT rewrite the query to use IN, the
problem exists with them as well. And since PostgreSQL does
not yet have outer joins, you should instead write the query
using a correlated sub query (EXISTS):emptoris=> explain SELECT employee FROM employees WHERE NOT
EXISTS (SELECT webuser FROM webusers WHERE webusers.webuser
= employees.employee);
NOTICE: QUERY PLAN:Seq Scan on employees (cost=3.95 rows=59 width=12)
SubPlan
-> Index Scan using k_webusers1 on webusers (cost=2.05
rows=1 width=12)EXPLAIN
There are many more such things which, if avoided, allow
PostgreSQL to work great. But with each release, a lot of
these things become obsolete.Mike Mascari
************
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Dec 29 15:28:12 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA58750
for <pgsql-general@postgresql.org>;
Wed, 29 Dec 1999 15:27:22 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.28.74.113]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Wed, 29 Dec 1999 14:27:33 -0600
Sender: ed
Message-ID: <386A6EE6.87DD3C82@austin.rr.com>
Date: Wed, 29 Dec 1999 14:28:22 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Mascari <mascarm@mascari.com>
CC: Barnes <aardvark@ibm.net>, pgsql-general@postgresql.org
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
References: <001701bf521e$b5860920$0a64a8c0@fries>
<386A5BBD.71375361@mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thanks, Mike! This is the most lucid, concise explanation of so many
postgresql "gotchas" I've seen yet.
Mike Mascari wrote:
2. Using views created with large queries - Views use the
rewrite system and rules to rewrite a query against it to
properly fetch data from the underlying tables. Because
there is currently a limit on the size of a single database
record (8192 bytes), the queries associated with views can
only be so big. ...
One additional anomaly as of 6.5.2 regarding backup and recovery...
If one simply compares the before/after output of load/dump scripts, it can at
first appear that pg_dump will occasionally convert a view built on non-empty
tables into a table itself with zero records. This happens during the
following backup test sequence for me:
% pg_dump -d mydb > db.out
% destroydb mydb
% createdb mydb
% psql -d mydb < db.out
% pg_dump -d mydb > db2.out
% diff db.out db2.out
This is because a view _is_ actually implemented as a table combined with a
redirecting rule, and thus not a problem. See the following for details.
http://www.deja.com/getdoc.xp?AN=559228857
Cheers,
Ed Loehr
From bouncefilter Wed Dec 29 17:13:13 1999
Received: from web3201.mail.yahoo.com (web3201.mail.yahoo.com
[204.71.202.198])
by hub.org (8.9.3/8.9.3) with SMTP id RAA82029
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 17:12:54 -0500 (EST)
(envelope-from ntwebdeveloper@yahoo.com)
Message-ID: <19991229220211.28987.qmail@web3201.mail.yahoo.com>
Received: from [207.7.33.226] by web3201.mail.yahoo.com;
Wed, 29 Dec 1999 14:02:11 PST
Date: Wed, 29 Dec 1999 14:02:11 -0800 (PST)
From: Peter Landis <ntwebdeveloper@yahoo.com>
To: Barnes <aardvark@ibm.net>, pgsql-general@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Hi-
I'm a newbie at postgresql and created a relational
database with perl. What my question is, how do you
do a string search in postgresql? I know you can
search for string comparisons in oracle but was
wondering if this is possible in postgresql? So far
I've been using the SELECT syntax for finding words in
the database, but this is assuming that the word is
exactly the same. If anyone could advise me on this
minor problem, I would greatly appreciate it.
Peter Landis
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com
From bouncefilter Wed Dec 29 17:24:14 1999
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA83091
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 17:24:08 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id SAA22380;
Wed, 29 Dec 1999 18:24:19 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 29 Dec 1999 18:24:19 -0400 (AST)
From: The Hermit Hacker <scrappy@HUB.ORG>
To: Barnes <aardvark@ibm.net>
cc: pgsql-general@postgreSQL.org
Subject: RE: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
In-Reply-To: <001701bf521e$b5860920$0a64a8c0@fries>
Message-ID: <Pine.BSF.4.21.9912291821340.880-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 29 Dec 1999, Barnes wrote:
It would be helpful to me to hear about successful and stable
implementations as well. If some of you who are using PostgreSQL
successfully could comment on your experiences, I think it would shed some
worthwhile light on it's capabilities. I'm considering using it for a
mission critical project, and I would like to know what I am getting into.
Thank you.
At work, its the backend for our DNS/DHCP tables, servicing over 4000
lap/desktops ...
For business, its the accounting backend for two ISPs that I work with for
their dialup lines, is the backend for the search engine that Vince and I
are currently working on getting online for PostgreSQL...is the backend
for a project I'm working with that deals with, esssentially, resource
management for banks...
The only one above that I don't consider "mission critical" is the
search...
David Barnes
-----Original Message-----
From: owner-pgsql-general@postgreSQL.org
[mailto:owner-pgsql-general@postgreSQL.org]On Behalf Of Ed Loehr
Sent: Wednesday, December 29, 1999 11:23 AM
To: Jochen Topf
Cc: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?My question of an earlier posting is still not answered. Does anybody
here,
who reported PostgreSQL to be very stable, use advanced features like
pl/pgsql
procedures, triggers, rules and notifies? Lets have a show of hands. I
would
really like to know, why I am the only one having problems. :-) Although
it might be, because, as this is a PostgreSQL mailing list, most of the
readers are people who are happy with PostgreSQL, because all the others
have left and are on an Oracle list now. :-)I use triggers, PL/pgSQL procedures/functions, and rules on 6.5.2, and I
have
experienced a number of what might be called instability problems for
whatever
reason. A review of the posts to the pgsql mailing lists will confirm that
you
are not alone in finding some points of instability. But the extent of any
instability is not clear. Watch for a web poll announcement in January to
get
a better handle on that data...Cheers,
Ed Loehr************
************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Dec 29 17:27:14 1999
Received: from web3204.mail.yahoo.com (web3204.mail.yahoo.com
[204.71.202.201])
by hub.org (8.9.3/8.9.3) with SMTP id RAA83328
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 17:26:20 -0500 (EST)
(envelope-from ntwebdeveloper@yahoo.com)
Message-ID: <19991229222549.29674.qmail@web3204.mail.yahoo.com>
Received: from [207.7.33.226] by web3204.mail.yahoo.com;
Wed, 29 Dec 1999 14:25:49 PST
Date: Wed, 29 Dec 1999 14:25:49 -0800 (PST)
From: Peter Landis <ntwebdeveloper@yahoo.com>
Subject: String search?
To: Peter Landis <ntwebdeveloper@yahoo.com>, Barnes <aardvark@ibm.net>,
pgsql-general@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Hi-
I'm a newbie at postgresql and created a relational
database with perl. What my question is, how do you
do a string search in postgresql? I know you can
search for string comparisons in oracle but was
wondering if this is possible in postgresql? So far
I've been using the SELECT syntax for finding words in
the database, but this is assuming that the word is
exactly the same. If anyone could advise me on this
minor problem, I would greatly appreciate it.
Peter Landis
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com
From bouncefilter Wed Dec 29 17:33:13 1999
Received: from co832821-a (cogeco-91-40.cgocable.net [24.141.91.40])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA87154
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 17:32:39 -0500 (EST)
(envelope-from reinke@e-softinc.com)
Received: from e-softinc.com ([10.1.1.4])
by co832821-a (8.8.7/8.8.7) with ESMTP id RAA28166;
Wed, 29 Dec 1999 17:32:30 -0500
Message-ID: <386A8C23.4D590726@e-softinc.com>
Date: Wed, 29 Dec 1999 17:33:07 -0500
From: Thomas Reinke <reinke@e-softinc.com>
Organization: E-Soft Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Landis <ntwebdeveloper@yahoo.com>
CC: pgsql-general@postgreSQL.org
Subject: Re:
References: <19991229220211.28987.qmail@web3201.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Try the "like" operator
E.g. SELECT * from TABLE where FIELD like '%string%';
Don't forget the % signs - they are the wild card.
Peter Landis wrote:
Hi-
I'm a newbie at postgresql and created a relational
database with perl. What my question is, how do you
do a string search in postgresql? I know you can
search for string comparisons in oracle but was
wondering if this is possible in postgresql? So far
I've been using the SELECT syntax for finding words in
the database, but this is assuming that the word is
exactly the same. If anyone could advise me on this
minor problem, I would greatly appreciate it.Peter Landis
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com************
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
From bouncefilter Wed Dec 29 17:37:13 1999
Received: from iodynamics.com (IDENT:root@www.iodynamics.com [206.81.134.150])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA87816
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 17:37:10 -0500 (EST)
(envelope-from fozz@iodynamics.com)
Received: (from fozz@localhost) by iodynamics.com (8.9.3/8.9.3) id PAA11984;
Wed, 29 Dec 1999 15:36:56 -0700
Date: Wed, 29 Dec 1999 15:36:56 -0700
From: "Doran L. Barton" <fozz@iodynamics.com>
To: Peter Landis <ntwebdeveloper@yahoo.com>
Cc: Barnes <aardvark@ibm.net>, pgsql-general@postgreSQL.org
Subject: Re: Search strings
Message-ID: <19991229153655.A11979@iodynamics.com>
References: <19991229220211.28987.qmail@web3201.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <19991229220211.28987.qmail@web3201.mail.yahoo.com>
Not long ago, Peter Landis proclaimed...
I'm a newbie at postgresql and created a relational
database with perl. What my question is, how do you
do a string search in postgresql? I know you can
search for string comparisons in oracle but was
wondering if this is possible in postgresql? So far
I've been using the SELECT syntax for finding words in
the database, but this is assuming that the word is
exactly the same. If anyone could advise me on this
minor problem, I would greatly appreciate it.
Very possible. There are several string operators in PostgreSQL. One of my
favorite is ~* which does a case-insensitive regular expression search.
SELECT * FROM TABLE1 WHERE FIELD1 ~* 'dog';
Hope that helps.
-=Fozz
--
Doran L. Barton <fozz@iodynamics.com>
Iodynamics LLC -- "Internetworking the masses"
<URL:http://www.iodynamics.com/>
From bouncefilter Wed Dec 29 20:51:15 1999
Received: from customer.cwhkt.com.tw (customer.cwhkt.com.tw [202.84.146.6])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA25000
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 20:51:04 -0500 (EST)
(envelope-from wuulong@penpower.com.tw)
Received: from penpower.com.tw ([210.208.104.1])
by customer.cwhkt.com.tw (8.9.3/8.9.3) with SMTP id KAA12703
for <pgsql-general@postgreSQL.org>; Thu, 30 Dec 1999 10:01:00 +0800
Received: from penpower.com.tw [210.208.104.62] by penpower.com.tw
[210.208.104.1] with SMTP (MDaemon.v2.7.SP4.R) for
<pgsql-general@postgreSQL.org>; Thu, 30 Dec 1999 09:41:02 +0800
Message-ID: <386AB6E4.6486DACE@penpower.com.tw>
Date: Thu, 30 Dec 1999 09:35:32 +0800
From: =?big5?B?qlrAcw==?= <wuulong@penpower.com.tw>
Organization: penpower
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Courtney Thomas <ccthomas@access1.net>
CC: Thomas Antepoth <t_antepoth@hamm.netsurf.de>,
Matthew Brown <matthew.brown@cordata.net>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Admin / client tools for Win32?
References: <Pine.LNX.4.21.9912290636160.20325-100000@sofa.c-c.de>
<38697F48.2781E494@access1.net>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
X-MDaemon-Deliver-To: pgsql-general@postgreSQL.org
X-Return-Path: wuulong@penpower.com.tw
In my RedHat 6.0 , it already have pgaccess.
I think when you install postgres 6.4 ( or later ) , you may already have it.
Courtney Thomas wrote:
Greetings !
Where can I get info on "pgaccess" ?
Thanks,
Courtney
-------------------------------------------------------------
Thomas Antepoth wrote:
Hi Mat,
On Tue, 28 Dec 1999, Matthew Brown wrote:
I have a web hosting client who wants SQL support, and is very used
to using MSAccess with MS SQL Server with all the integration they have.read: incompatibility in means of cross platform environments.
Can anyone point me to good GUI Win32 tools for manipulating Postgres?
Mostly what would be needed are database diagramming tools, etc.,
but admin tools would be great, too.You might try using the ODBC Driver kit for Postgres.
It performs well and it does the trick connecting a WIN32
Application to a Postgres Server.One pitfall still exists: If you don�t define your
Primary keys well, MS-Access97 will cast out queries
like:
select blah from blub where
field1=... and field2=... and field3=... and fieldn or
field1=... and ... or
field1=...Imagine what this does to your Postgres Server.
Here in our environment the postmaster inflates up to
40 Megs of Mem-Usage and drains all CPU even if
opening a table just for viewing.SQL7.0 instead seems to optimize these
ridiculous queries quite well.If you want the best cross platform utility you
might try pgaccess (it runs under TCL/TK) and
should run on WIN32 Clients as well.Did I hear a sideways recommendation of dbKit?
Never heard of it. What is it?
t++
--
This mail had been created using Linux. It is therefore free of all
Microsoft(tm) OS based virii, conforms with almost any widely recognized
open standards and is best read with *any* mailclient using fixed fonts.
Spam is processed at the modest price of $500 only at this site.************
************
--
wuulong Sheu ( �\�Z�s ) - PGP , HTML mail is welcome
�X���� - PEN POWER TECHNOLOGY LTD.(www.penpower.com.tw)
wuulong@penpower.com.tw (O)035722691-362 (M)0923135231 (icq)11934112
From bouncefilter Wed Dec 29 21:03:15 1999
Received: from customer.cwhkt.com.tw (customer.cwhkt.com.tw [202.84.146.6])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA29221
for <pgsql-general@postgreSQL.org>;
Wed, 29 Dec 1999 21:02:58 -0500 (EST)
(envelope-from wuulong@penpower.com.tw)
Received: from penpower.com.tw ([210.208.104.1])
by customer.cwhkt.com.tw (8.9.3/8.9.3) with SMTP id KAA12759
for <pgsql-general@postgreSQL.org>; Thu, 30 Dec 1999 10:12:55 +0800
Received: from penpower.com.tw [210.208.104.62] by penpower.com.tw
[210.208.104.1] with SMTP (MDaemon.v2.7.SP4.R) for
<pgsql-general@postgreSQL.org>; Thu, 30 Dec 1999 09:44:24 +0800
Message-ID: <386AB7AF.1AD03872@penpower.com.tw>
Date: Thu, 30 Dec 1999 09:38:55 +0800
From: =?big5?B?qlrAcw==?= <wuulong@penpower.com.tw>
Organization: penpower
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Landis <ntwebdeveloper@yahoo.com>
CC: Barnes <aardvark@ibm.net>, pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] String search?
References: <19991229222549.29674.qmail@web3204.mail.yahoo.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
X-MDaemon-Deliver-To: pgsql-general@postgreSQL.org
X-Return-Path: wuulong@penpower.com.tw
In the postgres document , postgres support regular expression match.
I think this is what you need. but I haven't test it.
so you can reference postgres document. Hope this information is usful
to you.
Peter Landis wrote:
Hi-
I'm a newbie at postgresql and created a relational
database with perl. What my question is, how do you
do a string search in postgresql? I know you can
search for string comparisons in oracle but was
wondering if this is possible in postgresql? So far
I've been using the SELECT syntax for finding words in
the database, but this is assuming that the word is
exactly the same. If anyone could advise me on this
minor problem, I would greatly appreciate it.Peter Landis
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com************
--
wuulong Sheu ( �\�Z�s ) - PGP , HTML mail is welcome
�X���� - PEN POWER TECHNOLOGY LTD.(www.penpower.com.tw)
wuulong@penpower.com.tw (O)035722691-362 (M)0923135231 (icq)11934112
From bouncefilter Thu Dec 30 08:38:24 1999
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA88317
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 08:37:44 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp78.kross.klever.net
[209.203.65.78]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id GAA17389 for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 06:34:40 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <386B601D.D06B955B@ironmountainsystems.com>
Date: Thu, 30 Dec 1999 05:37:33 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
Organization: Iron Mountain Systems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: Web mail list search engine broken?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am not having any luck searching the archives, is the software down?
http://www.PostgreSQL.ORG/mhonarc/pgsql-general/
Steve
From bouncefilter Thu Dec 30 09:40:25 1999
Received: from mail.rdc1.nj.home.com (imail@ha1.rdc1.nj.home.com
[24.3.128.66])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA03061
for <pgsql-general@hub.org>; Thu, 30 Dec 1999 09:40:09 -0500 (EST)
(envelope-from beller@tradeworx.com)
Received: from tradeworx.com ([24.3.202.163]) by mail.rdc1.nj.home.com
(InterMail v4.01.01.00 201-229-111) with ESMTP
id <19991230144008.NBFB18367.mail.rdc1.nj.home.com@tradeworx.com>;
Thu, 30 Dec 1999 06:40:08 -0800
Sender: mike
Message-ID: <386B70B7.605937B0@tradeworx.com>
Date: Thu, 30 Dec 1999 09:48:23 -0500
From: Mike Beller <beller@tradeworx.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@hub.org, aardvark@ibm.net
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission
criticalapplications?
References: <199912292224.RAA83117@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'd like to add one item to Mike Mascari's excellent and
helpful list:
Watch out for queries involving many result rows which include
functions or even aggregates in the select list:
--select f(x) into resulttable from bighugetable;
The way that postgres allocates/frees memory results in
potentially very large memory use by such queries. (Per-
row memory is not freed until the statement completes.)
My reading of the todo list is that this is a known bug
(or feature!).
BTW: Does anyone know if there are plans to fix this one soon?
Mike Beller
Barnes wrote:
It would be helpful to me to hear about successful and stable
implementations as well. If some of you who are using PostgreSQL
successfully could comment on your experiences, I think it would shed some
worthwhile light on it's capabilities. I'm considering using it for a
mission critical project, and I would like to know what I am getting into.
Thank you.David Barnes
We've used it successfully in a production environment (24 x
7) for over a year now. Simply reading the mailing list will
greatly improve your chances of success. The problems with
PostgreSQL can be avoided if you know, in advance, what to
From bouncefilter Thu Dec 30 19:52:32 1999
Received: from hermes.iol.cz (hermes.iol.cz [194.228.2.36])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA50090
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 19:51:52 -0500 (EST)
(envelope-from robert@robert.cz)
Received: from robert.cz ([194.228.143.139]) by hermes.iol.cz
(Post.Office MTA v3.5.3 release 223
ID# 631-64078U55000L55000S0V35) with ESMTP id cz
for <pgsql-general@postgreSQL.org>; Thu, 30 Dec 1999 15:46:34 +0100
Message-ID: <386B715A.550444E0@robert.cz>
Date: Thu, 30 Dec 1999 15:51:06 +0100
From: Robert <robert@robert.cz>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: PostgreSQL Portable Runtime (was Re: [GENERAL] Future of PostgreSQL)
References: <199912251600.LAA21597@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
one of the important factors that contributed to the popularity and success of
Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and
even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite
interesting too and I don't want to tie myself to just one platform. More platforms
will bring in more users, more testers and more hackers and thus much better
Postgres (hopefully).
Bruce M. says Postgres depends so much on Unix that to port it would be about as
hard as port the whole Unix kernel. So here's the idea for the next major release:
how about some kind of 'PostgrSQL Portable Rutime' that would isolate system
dependent stuff and make PostgreSQL reasonably portable? Apache has its 'Apache
Portable Runtime', so has Netscape/Mozilla and while they're clearly very different
applications, I believe it's not impossible.
I understand this would be a LOT of work and most Postgres developers might not be
immediately attracted, but look at it this way: Postgres is currently unique among
db servers with its features, robustness, performance and nice licence, but what if
mSQL/MySQL finally add transactions and other features and/or free their licence? Or
one of the big guys, say IBM, get enlightened/desperade enough to release source?
Suddenly there would be a strong competitor to Postgres and being crossplatform
would give them a great advantage.
I'm web developer and with Apache and Perl (and mod_perl), I'm quite happy. Now that
Mozilla M12 is quite usable I can develop on almost any platform I want... but I
want Postgres and it brings me back to Unix with its beautifull UI, great multimedia
support and Age of Empires running under Wine. *sigh*
- Robert
P.S. Cygwin is definitely one of the options, but RedHat/Cygnus's plans are not very
clear at this point and few months ago there were even some rumors about plans for
'more restrictive licence' for cygwin - and anyway, cygwin wouldn't be of any help
to Mac/BeOS/VAX/mainframe people.
From bouncefilter Thu Dec 30 13:53:27 1999
Received: from hotmail.com (f95.law4.hotmail.com [216.33.149.95])
by hub.org (8.9.3/8.9.3) with SMTP id NAA73648
for <pgsql-general@postgresql.org>;
Thu, 30 Dec 1999 13:52:46 -0500 (EST)
(envelope-from postgresql@hotmail.com)
Received: (qmail 77396 invoked by uid 0); 30 Dec 1999 18:52:15 -0000
Message-ID: <19991230185215.77395.qmail@hotmail.com>
Received: from 200.223.63.99 by www.hotmail.com with HTTP;
Thu, 30 Dec 1999 10:52:15 PST
X-Originating-IP: [200.223.63.99]
From: "postgres sql freeware" <postgresql@hotmail.com>
To: pgsql-general@postgresql.org
Subject: Client for postgres help!!
Date: Thu, 30 Dec 1999 14:52:15 AST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Hi!!
Somebody can help me!!!??? :)
Where can i get information about how to use the client for win32???
i wanna use it with Delphi or some stuff like that ....
very much thanks
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From bouncefilter Thu Dec 30 11:36:26 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA25171
for <pgsql-general@postgresql.org>;
Thu, 30 Dec 1999 11:36:15 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.57.169]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Thu, 30 Dec 1999 10:27:23 -0600
Sender: ed
Message-ID: <386B8A3E.1F1673AF@austin.rr.com>
Date: Thu, 30 Dec 1999 10:37:18 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Birch <sbirch@ironmountainsystems.com>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Web mail list search engine broken?
References: <386B601D.D06B955B@ironmountainsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Birch wrote:
I am not having any luck searching the archives, is the software down?
http://www.PostgreSQL.ORG/mhonarc/pgsql-general/
Steve
Usually down lately. Try www.deja.com...they have all the posts...
Cheers,
Ed Loehr
From bouncefilter Thu Dec 30 15:39:28 1999
Received: from ms.anet.cz (ms.anet.cz [194.50.6.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA01528
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 15:38:32 -0500 (EST)
(envelope-from robert@robert.cz)
Received: from robert.cz (taf9.anet.cz [194.108.189.98])
by ms.anet.cz (Postfix) with ESMTP id 866711098F2
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 21:38:29 +0100 (CET)
Message-ID: <386BC3C7.64570F78@robert.cz>
Date: Thu, 30 Dec 1999 21:42:47 +0100
From: Robert <robert@robert.cz>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: PostgreSQL Portable Runtime (was Re: [GENERAL] Future of PostgreSQL)
References: <199912251600.LAA21597@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
one of the important factors that contributed to the popularity and success of
Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and
even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite
interesting too and I don't want to tie myself to just one platform. More platforms
will bring in more users, more testers and more hackers and thus much better
Postgres (hopefully).
Bruce M. says Postgres depends so much on Unix that to port it would be about as
hard as port the whole Unix kernel. So here's the idea for the next major release:
how about some kind of 'PostgrSQL Portable Rutime' that would isolate system
dependent stuff and make PostgreSQL reasonably portable? Apache has its 'Apache
Portable Runtime', so has Netscape/Mozilla and while they're clearly very different
applications, I believe it's not impossible.
I understand this would be a LOT of work and most Postgres developers might not be
immediately attracted, but look at it this way: Postgres is currently unique among
db servers with its features, robustness, performance and nice licence, but what if
mSQL/MySQL finally add transactions and other features and/or free their licence? Or
one of the big guys, say IBM, get enlightened/desperade enough to release source?
Suddenly there would be a strong competitor to Postgres and being crossplatform
would give them a great advantage.
I'm web developer and with Apache and Perl (and mod_perl), I'm quite happy. Now that
Mozilla M12 is quite usable I can develop on almost any platform I want... but I
want Postgres and it brings me back to Unix with its beautifull UI, great multimedia
support and Age of Empires running under Wine. *sigh*
- Robert
P.S. Cygwin is definitely one of the options, but RedHat/Cygnus's plans are not very
clear at this point and few months ago there were even some rumors about plans for
'more restrictive licence' for cygwin - and anyway, cygwin wouldn't be of any help
to Mac/BeOS/VAX/mainframe people.
From bouncefilter Thu Dec 30 15:46:28 1999
Received: from relay.planetinternet.be (relay.planetinternet.be
[194.119.232.24]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA02217
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 15:45:43 -0500 (EST)
(envelope-from wdemoudt@planetinternet.be)
Received: from planetinternet.be (u212-239-129-132.dialup.planetinternet.be
[212.239.129.132])
by relay.planetinternet.be (8.9.3/8.9.3) with ESMTP id VAA04673;
Thu, 30 Dec 1999 21:43:52 +0100
Message-ID: <386BC59F.E7DCE1A@planetinternet.be>
Date: Thu, 30 Dec 1999 21:50:39 +0100
From: De Moudt Walter <wdemoudt@planetinternet.be>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Landis <ntwebdeveloper@yahoo.com>
CC: Barnes <aardvark@ibm.net>, pgsql-general@postgreSQL.org
Subject: Re:
References: <19991229220211.28987.qmail@web3201.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Peter,
Select is the good way, but use LIKE or ~ instead of = for your
comparison. It enables you to search on substrings of all kind.
SELECT * from my_table where text_field1 like '.....'
or ...text_field1 ~ '.....'
This operator has extensive features. You should consult the manual.
Some examples :
.... ~ '^D' begins with D
.... ~ 'D' contains D
.... ~ '^.D' has D in second place
.... ~* 'D' contains D or d
And so on. Really too much to mention. Hope this helps
Walter De Moudt
Peter Landis wrote:
Hi-
I'm a newbie at postgresql and created a relational
database with perl. What my question is, how do you
do a string search in postgresql? I know you can
search for string comparisons in oracle but was
wondering if this is possible in postgresql? So far
I've been using the SELECT syntax for finding words in
the database, but this is assuming that the word is
exactly the same. If anyone could advise me on this
minor problem, I would greatly appreciate it.Peter Landis
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com************
From bouncefilter Thu Dec 30 16:07:29 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA07396
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 16:07:08 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA26272;
Thu, 30 Dec 1999 16:06:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199912302106.QAA26272@candle.pha.pa.us>
Subject: Re: PostgreSQL Portable Runtime (was Re: [GENERAL] Future of
PostgreSQL)
In-Reply-To: <386BC3C7.64570F78@robert.cz> from Robert at "Dec 30,
1999 09:42:47 pm"
To: Robert <robert@robert.cz>
Date: Thu, 30 Dec 1999 16:06:17 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
P.S. Cygwin is definitely one of the options, but RedHat/Cygnus's plans are not very
clear at this point and few months ago there were even some rumors about plans for
'more restrictive licence' for cygwin - and anyway, cygwin wouldn't be of any help
to Mac/BeOS/VAX/mainframe people.
We have been very lucky to have cgywin to allow us to run on NT with
very few changes. My guess is that we would basically need to re-invent
cgywin on those platforms because we use most/all of the modules.
I guess that is what makes it sound really hard. If Cygnus has problems
doing Win95 or Mac, it would be very hard for us, no?
If we were just passing around bytes or doing network stuff like Apache
or Perl, we would be OK. It is the shared memory and locking stuff that
would really give us trouble. Cgywin gave us that.
We do have _very_ clearly modular code, so someone could easily see
exactly where we do each of these things. Probably the bigest hurdle is
that none of the developers have any interest in these platforms.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Dec 30 19:52:31 1999
Received: from rabies.toodarkpark.org (caffeine@rabies.toodarkpark.org
[207.176.94.148]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA50081
for <pgsql-general@postgreSQL.org>;
Thu, 30 Dec 1999 19:51:33 -0500 (EST)
(envelope-from caffeine@toodarkpark.org)
Received: from localhost (caffeine@localhost)
by rabies.toodarkpark.org (8.8.8/8.8.8/Debian/GNU) with SMTP id
TAA15372; Thu, 30 Dec 1999 19:59:46 -0500
Date: Fri, 31 Dec 1999 00:59:46 +0000 (GMT)
From: Howie <caffeine@toodarkpark.org>
To: Robert <robert@robert.cz>
cc: pgsql-general@postgreSQL.org
Subject: Re: PostgreSQL Portable Runtime (was Re: [GENERAL] Future of
PostgreSQL)
In-Reply-To: <386BC3C7.64570F78@robert.cz>
Message-ID: <Pine.LNX.3.96.991231004922.1580U-100000@rabies.toodarkpark.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 30 Dec 1999, Robert wrote:
Hi,
one of the important factors that contributed to the popularity and success of
Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and
even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite
interesting too and I don't want to tie myself to just one platform.
MacOS X has a Unix core ( Mach 3.0 + FreeBSD ). a few people are looking
into a port to MacOS X DP2 (Developer Preview, heavily NDA'ed), but
they're not sure if the guts are 'feature frozen' yet. MacOS X CR1
(Customer Release) supposidly ships ~feb 2k. id expect that the port
would be relatively painless, but i'm not 100% positive. Mach would be
The Big Hurdle (no pun intended) in getting pgsql to work right on the
MacOS X/OS X Server platform.
David Wetzel ( www.turbocat.de ) has a working EOAdaptor for MacOS X
Server, OPENSTEP/Mach, and OPENSTEP/NT. ive been using it for quite a few
internal projects under MacOS X Server. works great.
[SNIP]
---
Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org
"I've learned that you cannot make someone love you.
All you can do is stalk them and hope they panic and give in."
From bouncefilter Fri Dec 31 16:46:57 1999
Received: from claudius.mgmt-inc.com ([166.82.12.160])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA22074
for <pgsql-general@postgresql.org>;
Fri, 31 Dec 1999 16:45:59 -0500 (EST) (envelope-from me@jimcain.net)
Received: from claudius.mgmt-inc.com (claudius.mgmt-inc.com [166.82.12.160]
(may be forged))
by claudius.mgmt-inc.com (8.9.3/8.9.1) with ESMTP id QAA25695
for <pgsql-general@postgresql.org>; Fri, 31 Dec 1999 16:45:58 -0500
Date: Fri, 31 Dec 1999 16:45:58 -0500 (EST)
From: Jim Cain <me@jimcain.net>
X-Sender: jec@claudius.mgmt-inc.com
To: pgsql-general@postgresql.org
Subject: Using $n in a select statement in PL/pgSQL
Message-ID: <Pine.LNX.4.20.9912311643270.25649-100000@claudius.mgmt-inc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I can't find very many references to PL/pgSQL. Can anyone point me to lots
of examples? In particular, select statements don't appear to like the $n
variables, unless I'm just doing something really wrong.
I can post an example of what I'm doing if necessary, but right now I'd
really just like to find some references to the language.
Cheers,
Jim
From bouncefilter Fri Dec 31 17:22:04 1999
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA27765
for <pgsql-general@postgresql.org>;
Fri, 31 Dec 1999 17:21:29 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id RAA49329
for pgsql-general@postgresql.org; Fri, 31 Dec 1999 17:16:19 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Mike DeFehr" <mdefehr@home.com>
X-Newsgroups: comp.databases.postgresql.questions
References: <945893469.1219290919@news.nyu.edu>
<38613E63.47B6BB22@ix.netcom.com>
Subject: Re: newbie needs help setting up pgsql on linux
Lines: 53
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <cW9b4.5737$pP.95398@news1.rdc1.mb.home.com>
Date: Fri, 31 Dec 1999 22:15:36 GMT
X-Complaints-To: abuse@home.net
X-Trace: news1.rdc1.mb.home.com 946678536 24.66.35.216 (Fri,
31 Dec 1999 14:15:36 PST)
Organization: @Home Network Canada
To: pgsql-questions@postgresql.org
Make sure you have installed the postgresql-server-x.x.x.i386.rpm
I recently ran into similar problems, my solution was to go right to the
website of the guy who packages the rpms: www.ramifordistat.net and
download the latest packages:
postgresql-6.5.3.i386.rpm
postgresql-server-6.5.3.i386.rpm
(I also downloaded test, devel, odbc, perl and python)
then I uninstalled everything that has anything to do with postgresql, then
installed these packages. Everything worked like a charm after that
Note: template1 ended up in /var/lib/pgsql/base
...hope this helps
Steve wrote in message <38613E63.47B6BB22@ix.netcom.com>...
There is a program called 'initdb' you need to run under your postgres
usercode.
See 'man initdb' for details.
Eldad Midan wrote:
Hi everybody,
I am running RedHat Linux 6.1 on a Pentium, and am trying to migrate
existing
databases from Access-Win95 to PostgreSQL on Linux.
I have installed the RPMs retrieved from RedHat's ftp site, read the
relevant
sections in the admin guide, the user's guide and some more, but I can't
get
postmaster to start. It seems that in order to start I need to install a
database with a template (template1) which should be in some ... .../data
directory. However, those files are nowhere to be found. I created a ...
../data directory, ran initlocation -D
the-directory-where-the-data-will-reside
and postmaster claims not to find a file called ...
../data/base/template1/pg_class. I looked around in various directories,
and
found some candidates in /usr/lib/pgsql/* but without instructions on how
to
make that into my template. Finally, when I 'touch' a file to be named
pg_class, postmaster complains that the file PG_VERSION does not exist.Can anyone help me?
ari
From bouncefilter Fri Dec 31 17:14:57 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA27146
for <pgsql-general@postgresql.org>;
Fri, 31 Dec 1999 17:14:44 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Fri, 31 Dec 1999 16:15:07 -0600
Sender: ed
Message-ID: <386D2B15.74214051@austin.rr.com>
Date: Fri, 31 Dec 1999 16:15:49 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Cain <me@jimcain.net>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Using $n in a select statement in PL/pgSQL
References: <Pine.LNX.4.20.9912311643270.25649-100000@claudius.mgmt-inc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jim Cain wrote:
I can't find very many references to PL/pgSQL. Can anyone point me to lots
of examples? In particular, select statements don't appear to like the $n
variables, unless I'm just doing something really wrong.
Try the regression tests in .../src/test/regress/sql/plpgsql....
Cheers,
Ed Loehr
From bouncefilter Fri Dec 31 17:21:58 1999
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA27764
for <pgsql-general@postgresql.org>;
Fri, 31 Dec 1999 17:21:29 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id RAA49692
for pgsql-general@postgresql.org; Fri, 31 Dec 1999 17:21:02 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Mike DeFehr" <mdefehr@home.com>
X-Newsgroups: comp.databases.postgresql.questions
Subject: Access 2000 with PostgreSQL driver?
Lines: 8
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <7%9b4.5738$pP.95348@news1.rdc1.mb.home.com>
Date: Fri, 31 Dec 1999 22:20:51 GMT
X-Complaints-To: abuse@home.net
X-Trace: news1.rdc1.mb.home.com 946678851 24.66.35.216 (Fri,
31 Dec 1999 14:20:51 PST)
Organization: @Home Network Canada
To: pgsql-questions@postgresql.org
I can get Access 97 to access tables on my PostgreSQL server, but with
Access 2000 on the same machine using the same DSN, while it lets me Link to
the tables, when I try to open them it gives me the error "Microsoft Access
can't open the table in Datasheet view"
any ideas?
From bouncefilter Fri Dec 31 19:48:59 1999
Received: from Viola.Opus1.COM (IDENT:unIDENTified@Viola.Opus1.COM
[192.245.12.8]) by hub.org (8.9.3/8.9.3) with ESMTP id TAA52715
for <pgsql-general@postgreSQL.org>;
Fri, 31 Dec 1999 19:48:53 -0500 (EST) (envelope-from ron@Opus1.COM)
Received: from opus1.com ([204.27.149.66]) by Opus1.COM (PMDF V5.2-32 #9830)
with ESMTPS id <01JK5RWUZDG69865TN@Opus1.COM> for
pgsql-general@postgreSQL.org; Fri, 31 Dec 1999 17:48:52 MST
Date: Fri, 31 Dec 1999 17:48:43 -0700
From: Ron Chmara <ron@Opus1.COM>
Subject: Re: PostgreSQL Portable Runtime (was Re: [GENERAL] Future of
PostgreSQL)
To: Robert <robert@robert.cz>
Cc: pgsql-general@postgreSQL.org
Reply-to: ron@Opus1.COM
Message-id: <386D4EF1.16E3A3E8@opus1.com>
Organization: Ronin
MIME-version: 1.0
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <199912251600.LAA21597@candle.pha.pa.us>
<386B715A.550444E0@robert.cz>
Robert wrote:
Hi,
one of the important factors that contributed to the popularity and success of
Apache, Perl, Tcl/Tk etc. was their platform independence. I'm big fan of Unix (and
even bigger of Postgres ;-), but BeOS, MacOS X, even Win2000 all look quite
interesting too and I don't want to tie myself to just one platform.
I share your aspirations, and your pain. :-) Some of the issues that make each platform
good are the same issues that make them potentially poor candidates for certain kinds
of software, until that platform matures in that area... Some things, like perl, lose
some of their features on MacOS, or NT, because the features aren't available
from the platform. Where this leads my thinking is to look at what each platform would
not support, and then use that to determine whether the resulting product would
be worth using... how much of postgres wouldn't be able to survive on other platforms?
If the answer is "the binaries have compile against new libraries, which don't exist
yet", that's a time consuming issue, and requires pressure on the library authors.
If the issue is "memory mapping in Win2k would break all of the relational schema",
that's a bit bigger. :-)
Now that
Mozilla M12 is quite usable I can develop on almost any platform I want... but I
want Postgres and it brings me back to Unix with its beautifull UI, great multimedia
support and Age of Empires running under Wine. *sigh*
You've been away too long, grasshopper. KDE, Gnome, sound/video support, it's all
there... I suggest you talk to the Age of Empires folks about _their_ x-plat
support if you're unhappy with *nix running it under emulation. :-)
-Bop
--
Brought to you from iBoptheMac, a Linux/PPC iMac, currently running MacOS.
Your bopping may vary.
From bouncefilter Sat Jan 1 22:49:17 2000
Received: from public.zz.ha.cn (public.zz.ha.cn [202.102.224.111])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA40618
for <pgsql-general@postgreSQL.org>; Sat, 1 Jan 2000 22:48:16 -0500 (EST)
(envelope-from kfyygs@public.zz.ha.cn)
Received: from lht (pppa231.kfptt.ha.cn [202.111.139.231])
by public.zz.ha.cn (8.9.1a/8.9.1) with SMTP id LAA24714
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 11:52:07 +0800 (CST)
Message-ID: <000701bf540b$3b33fee0$7c19fea9@lht>
From: "alex" <kfyygs@public.zz.ha.cn>
To: <pgsql-general@postgreSQL.org>
Subject: hi
Date: Sat, 1 Jan 2000 11:49:34 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0004_01BF544E.45EFF800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
This is a multi-part message in MIME format.
------=_NextPart_000_0004_01BF544E.45EFF800
Content-Type: text/plain;
charset="big5"
Content-Transfer-Encoding: quoted-printable
subscribe
end
------=_NextPart_000_0004_01BF544E.45EFF800
Content-Type: text/html;
charset="big5"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3612.1706"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>subscribe</DIV>
<DIV>end</DIV></BODY></HTML>
------=_NextPart_000_0004_01BF544E.45EFF800--
From bouncefilter Sat Jan 1 23:01:24 2000
Received: from public.kfptt.ha.cn (public.kfptt.ha.cn [202.102.229.17])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA41363
for <pgsql-general@postgreSQL.org>; Sat, 1 Jan 2000 22:59:57 -0500 (EST)
(envelope-from alexwd@public.kfptt.ha.cn)
Received: from lht (pppa231.kfptt.ha.cn [202.111.139.231])
by public.kfptt.ha.cn (8.9.1a/8.9.1) with SMTP id MAA27496
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 12:02:39 +0800 (CST)
Message-ID: <002801bf540c$de6ba300$7c19fea9@lht>
From: "alex" <alexwd@public.kfptt.ha.cn>
To: <pgsql-general@postgresql.org>
Subject: hi
Date: Sat, 1 Jan 2000 12:01:19 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0025_01BF544F.EA21DAA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
This is a multi-part message in MIME format.
------=_NextPart_000_0025_01BF544F.EA21DAA0
Content-Type: text/plain;
charset="big5"
Content-Transfer-Encoding: quoted-printable
subscribe
end
------=_NextPart_000_0025_01BF544F.EA21DAA0
Content-Type: text/html;
charset="big5"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3612.1706"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>subscribe</DIV>
<DIV>end</DIV></DIV></BODY></HTML>
------=_NextPart_000_0025_01BF544F.EA21DAA0--
From bouncefilter Sat Jan 1 14:28:11 2000
Received: from mail.toppoint.de (bender.toppoint.de [195.244.243.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA48850
for <pgsql-general@postgresql.org>; Sat, 1 Jan 2000 14:27:43 -0500 (EST)
(envelope-from marten@feki.toppoint.de)
Received: (from uucp@localhost) by mail.toppoint.de (8.9.3/8.9.3) id UAA00264
for pgsql-general@postgresql.org; Sat, 1 Jan 2000 20:27:33 +0100 (MET)
Received: (from marten@localhost)
by feki.toppoint.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA06930
for pgsql-general@postgresql.org; Sat, 1 Jan 2000 20:23:35 +0100
From: Marten Feldtmann <marten@feki.toppoint.de>
Message-Id: <200001011923.UAA06930@feki.toppoint.de>
Subject: WIN-client wanted ...
To: pgsql-general@postgresql.org
Date: Sat, 1 Jan 2000 20:23:35 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
I'm in need for a thin libpq library under Win'32.
There has been a libpq-library available on the net with just the
libpq-dll and this worked very well with my application (written
with Borland CBuilder 4).
Some days ago a new compilation has been put on the net (6.5.3)
and I can not use it because it always gives me segamentation
faults - we were unable to use any library, which was build
using the cygnus development kit :-(
Some help out there ?
Marten Feldtmann
From bouncefilter Sat Jan 1 19:33:14 2000
Received: from www.ifrance.com (www.ifrance.com [209.67.249.134] (may be
forged)) by hub.org (8.9.3/8.9.3) with SMTP id TAA06048
for <pgsql-general@postgresql.org>; Sat, 1 Jan 2000 19:33:10 -0500 (EST)
(envelope-from mumu@ifrance.com)
Received: from 193.250.40.181 [193.250.40.181] by www.ifrance.com;
Sun, 2 Jan 2000 00:33:17 GMT
From: Laurent Tourreau <mumu@ifrance.com>
Reply-To: mumu@ifrance.com
To: pgsql-general@postgresql.org
Subject: \dt command displays no tables
Date: Sun, 2 Jan 2000 01:29:39 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00010201325702.00683@laurent>
Content-Transfer-Encoding: 8bit
hello
i have created a new database with one table.
when i type the \dt command to see the list of tables, it displays an error
message which mentions no table found. (but the table really exists!)
anyone can help me?
thanks
___________________________________________________________________________
Message envoye depuis iFrance : http://www.ifrance.com ou 3615 IFRANCE
Gratuit : Hebergement (50 Mo)/Vos emails (POP,HTML,20 Mo, FAX)/Votre agenda
From bouncefilter Sun Jan 2 19:09:31 2000
Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.25.39])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA62539
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 19:08:54 -0500 (EST)
(envelope-from makky@uclink4.berkeley.edu)
Received: from uclink4.berkeley.edu (makky4715390.HIP.Berkeley.EDU
[136.152.29.54])
by uclink4.berkeley.edu (8.8.8/8.8.8) with ESMTP id QAA05866
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 16:08:52 -0800 (PST)
Sender: root@uclink4.berkeley.edu
Message-ID: <386E9CF2.A4B35CF0@uclink4.berkeley.edu>
Date: Sat, 01 Jan 2000 16:33:54 -0800
From: KaYue Mak <makky@uclink4.berkeley.edu>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
help
From bouncefilter Sat Jan 1 21:07:17 2000
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA23137
for <pgsql-general@postgreSQL.org>; Sat, 1 Jan 2000 21:06:57 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.53])
by www.wgcr.org (8.9.3/8.9.3/WGCR) with SMTP id VAA00810;
Sat, 1 Jan 2000 21:06:46 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Robert <robert@robert.cz>
Subject: Re: [GENERAL] Czech Win1250 sorting q
Date: Sat, 1 Jan 2000 21:06:38 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: pgsql-general@postgreSQL.org
References: <38525CB7.5A0DE3A@robert.cz> <38534F22.57EA6E8A@robert.cz>
<m2wvqjpg4n.fsf@chameleon.localdomain>
In-Reply-To: <m2wvqjpg4n.fsf@chameleon.localdomain>
MIME-Version: 1.0
Message-Id: <00010121090100.00550@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit
On Mon, 13 Dec 1999, David Sauer wrote:
Robert> Hmm, what did you say I should write? Well, this is PG6.5.2
Robert> installed from RPM, should it be compiled with some special
Robert> option? Thanks.Yes, postgres must be compiled with --enable-locale and --with-mb=LATIN2.
And, I'am not sure, but may want upgrade to 6.5.3.
The pg_encoding utility is not shipped with any RPM's prior to 6.5.3-3 -- I
would say that upgrading to that would be a good thing. Also, prior to
6.5.3-3, the RPM distribution, while compiled with --enable-locale, was not
compiled with --with-mb= -- thus, while the RPM binaries have locale support,
they don't have multibyte, which may be needed. The 6.5.3-3 RPM's fix that.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
From bouncefilter Mon Jan 3 01:12:35 2000
Received: from mail.toppoint.de (bender.toppoint.de [195.244.243.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA31747
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 01:12:20 -0500 (EST)
(envelope-from marten@feki.toppoint.de)
Received: (from uucp@localhost) by mail.toppoint.de (8.9.3/8.9.3) id HAA26981;
Mon, 3 Jan 2000 07:11:26 +0100 (MET)
Received: (from marten@localhost)
by feki.toppoint.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA09396;
Sun, 2 Jan 2000 21:24:56 +0100
From: Marten Feldtmann <marten@feki.toppoint.de>
Message-Id: <200001022024.VAA09396@feki.toppoint.de>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <38655089.B6D6B5A1@austin.rr.com> from Ed Loehr at "Dec 25, 1999
05:17:29 pm"
To: Ed Loehr <ELOEHR@austin.rr.com>
Date: Sun, 2 Jan 2000 21:24:56 +0100 (CET)
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Bruce Momjian wrote:
My big question is, what new challenges will we face as we become more
popular?The 3 greatest technical/engineering challenges:
1) system reliability
& recoverability,
2) system reliability & recoverability, and
3) system reliability
and recoverability.
Well said ! Some other points I would like to see:
- do not go the way to add features and features and all these
features perhaps only fullfill 90% of the specifications.
- stable sql-standard execution and with all features sql offers
- remember all the groub by - having ...
- remove internal limits
- vacuumdb and the three points above ...
After working now three months with psql the situation has improved,
but I'm still not sure if I can put this database to our customers.
Marten
From bouncefilter Sun Jan 2 17:09:29 2000
Received: from sirius.netdados.com.br (sirius.netdados.com.br [200.241.59.1])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA38466
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 17:08:41 -0500 (EST)
(envelope-from brunomen@netdados.com.br)
Received: from brunomen (marte.netdados.com.br [200.241.59.4])
by sirius.netdados.com.br (8.9.3/8.9.2) with SMTP id UAA13556
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 20:08:34 -0200 (EDT)
Message-ID: <008b01bf556d$4ea20360$aa0110ac@brunomen.viaradio.netdados.com.br>
From: "Bruno Mendonca" <brunomen@netdados.com.br>
To: <pgsql-general@postgreSQL.org>
Subject: Postgres functions
Date: Sun, 2 Jan 2000 20:04:14 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0088_01BF555C.8ACCE820"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
This is a multi-part message in MIME format.
------=_NextPart_000_0088_01BF555C.8ACCE820
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Good evening,
where I find information about postgres =
functions.The command \df d'ont show me anything
bruno mendonca
aracaju-se
brazil
------=_NextPart_000_0088_01BF555C.8ACCE820
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Good evening,</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2> &nbs=
p; =20
where I find information about postgres functions.The command \df d'ont =
show me=20
anything</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>bruno mendonca</FONT></DIV>
<DIV><FONT size=3D2>aracaju-se</FONT></DIV>
<DIV><FONT size=3D2>brazil</FONT></DIV></BODY></HTML>
------=_NextPart_000_0088_01BF555C.8ACCE820--
From bouncefilter Sun Jan 2 18:44:30 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA54929
for <pgsql-general@postgresql.org>; Sun, 2 Jan 2000 18:44:30 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 2 Jan 2000 17:35:30 -0600
Sender: ed
Message-ID: <386FE323.99F271DE@austin.rr.com>
Date: Sun, 02 Jan 2000 17:45:39 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruno Mendonca <brunomen@netdados.com.br>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Postgres functions
References: <008b01bf556d$4ea20360$aa0110ac@brunomen.viaradio.netdados.com.br>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruno Mendonca wrote:
Good evening, where I find information
about postgres functions.The command \df d'ont show me anything
www.postgresql.org under "Info Central"...
Cheers,
Ed Loehr
From bouncefilter Sun Jan 2 19:17:31 2000
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA63165
for <pgsql-general@postgresql.org>; Sun, 2 Jan 2000 19:17:10 -0500 (EST)
(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.27.30.56]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 2 Jan 2000 18:08:20 -0600
Sender: ed
Message-ID: <386FEAD5.5D236ED3@austin.rr.com>
Date: Sun, 02 Jan 2000 18:18:29 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pg-gen <pgsql-general@postgresql.org>
Subject: How 2 shutoff verbose logging...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Could someone remind me of how to shutoff the following log
messages?
! postgres usage stats:
! Shared blocks: 0 read, 0 written,
buffer hit rate = 0.00%
! Local blocks: 0 read, 0 written,
buffer hit rate = 0.00%
! Direct blocks: 0 read, 0 written
! system usage stats:
! 0.000108 elapsed 0.000000 user 0.000000 system sec
! [0.640000 user 0.040000 sys total]
! 0/0 [0/0] filesystem blocks in/out
! 0/0 [163/524] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [0/0] voluntary/involuntary context switches
I started postmaster with the following command: postmaster -i
-o "-F -S 4096 -s"
And I have no pg_options file at all.
Cheers,
Ed Loehr
From bouncefilter Sun Jan 2 22:11:33 2000
Received: from mail.intercall.com.br (shapshore.com.br [200.197.170.2] (may be
forged)) by hub.org (8.9.3/8.9.3) with SMTP id WAA95388
for <pgsql-general@postgreSQL.org>; Sun, 2 Jan 2000 22:10:55 -0500 (EST)
(envelope-from howe@intercall.com.br)
Received: from SAM (200.197.170.115)
by mail.intercall.com.br with MERCUR-SMTP/POP3/IMAP4-Server (v3.10.16
AS-0098312)
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 01:08:29 -0200
Message-ID: <001201bf55a0$ac072160$73aac5c8@SAM>
From: "Steve Howe" <howe@intercall.com.br>
To: <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Web mail list search engine broken?
Date: Mon, 3 Jan 2000 01:11:54 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000F_01BF5587.85C9E410"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Reply-To: howe@intercall.com.br
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01BF5587.85C9E410
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I got the same behaviour. Something must be worng.
Howe
------=_NextPart_000_000F_01BF5587.85C9E410
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I got the same behaviour. Something =
must be=20
worng.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Howe</FONT></DIV></BODY></HTML>
------=_NextPart_000_000F_01BF5587.85C9E410--
From bouncefilter Mon Jan 3 03:40:36 2000
Received: from innocence.interface-business.de ([193.101.57.202])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA64519
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 03:40:23 -0500 (EST)
(envelope-from gerald@mauz.interface-business.de)
Received: from mauz.interface-business.de (mauz.interface-business.de
[193.101.57.233])
by innocence.interface-business.de with ESMTP id JAA43618;
Mon, 3 Jan 2000 09:40:20 +0100 (CET)
Received: (from gerald@localhost)
by mauz.interface-business.de (8.8.8/8.8.8) id JAA28396;
Mon, 3 Jan 2000 09:40:19 +0100 (CET) (envelope-from gerald)
Message-ID: <XFMail.000103094019.postgres@taifun.interface.business.de>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.05.9912290439420.3859-100000@cuaima.ica.luz.ve>
Date: Mon, 03 Jan 2000 09:40:19 +0100 (CET)
Reply-To: gerald@interface-business.de
Organization: Interface Business
Sender: gerald@mauz.interface-business.de
From: postgres@taifun.interface.business.de
To: Vegeta <vegeta@cuaima.ica.luz.ve>
Subject: RE: [GENERAL] using password protection in pgtcl
Cc: pgsql-general@postgreSQL.org
Hi Vegeta,
I want to use the pg_connect function of pgtcl on a database that requires
password authentication. Is there an option of pg_connect that allows
passing a username and password to make the connection?
Try: pg_connect -conninfo "user=$user password=$password"
Gerald
From bouncefilter Mon Jan 3 06:23:38 2000
Received: from bbs.myhome.com (IDENT:root@[164.100.16.147])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA92903
for <pgsql-interfaces@postgreSQL.org>;
Mon, 3 Jan 2000 06:22:48 -0500 (EST)
(envelope-from tusar@netshooter.com)
Received: from localhost (tusar@localhost)
by bbs.myhome.com (8.9.3/8.8.7) with ESMTP id QAA16022;
Mon, 3 Jan 2000 16:58:35 +0530
Date: Mon, 3 Jan 2000 16:58:22 +0530 (IST)
From: Tusar <tusar@netshooter.com>
Sender: tusar@bbs.myhome.com
To: Kevin Lo <kevlo@hello.com.tw>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Announce: PostgreSQL-6.5.3 binaries available for
Windows NT
In-Reply-To: <385F9F03.D9C199A0@hello.com.tw>
Message-ID: <Pine.LNX.4.10.10001031656240.15999-100000@bbs.myhome.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I think there is one file ipc-daemon.exe is missing in those binary
archieve..can u please send that by mail?(only that single binary) .. I
have loaded evrything else ...
Tusar
Tusar>Hi,
Tusar>
Tusar>Some people asked me to build PostgreSQL binaries for Windows NT.
Tusar>The binaries(PostgreSQL-6.5.3) are now available at:
Tusar>
Tusar>ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Tusar>
From bouncefilter Mon Jan 3 10:26:41 2000
Received: from datmail03.dat.com ([209.241.199.3])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA39281
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 10:26:25 -0500 (EST)
(envelope-from philip.culberson@dat.com)
Received: by datmail03.dat.com with Internet Mail Service (5.5.2448.0)
id <XF5BYA8A>; Mon, 3 Jan 2000 07:25:19 -0800
Message-ID: <A95EFC3B707BD311986C00A0C9E95B6A04B3A7@datmail03.dat.com>
From: "Culberson, Philip" <philip.culberson@dat.com>
To: "'Ed Loehr'" <eloehr@austin.rr.com>, pg-gen <pgsql-general@postgreSQL.org>
Subject: RE: [GENERAL] How 2 shutoff verbose logging...
Date: Mon, 3 Jan 2000 07:25:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
postmaster -i -o "-F -S 4096 -s"
Remove the "-s" from the backend options.
Happy New Year
Phil Culberson
-----Original Message-----
From: Ed Loehr [mailto:eloehr@austin.rr.com]
Sent: Sunday, January 02, 2000 4:18 PM
To: pg-gen
Subject: [GENERAL] How 2 shutoff verbose logging...
Could someone remind me of how to shutoff the following log
messages?
! postgres usage stats:
! Shared blocks: 0 read, 0 written,
buffer hit rate = 0.00%
! Local blocks: 0 read, 0 written,
buffer hit rate = 0.00%
! Direct blocks: 0 read, 0 written
! system usage stats:
! 0.000108 elapsed 0.000000 user 0.000000 system sec
! [0.640000 user 0.040000 sys total]
! 0/0 [0/0] filesystem blocks in/out
! 0/0 [163/524] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
! 0/0 [0/0] voluntary/involuntary context switches
I started postmaster with the following command: postmaster -i
-o "-F -S 4096 -s"
And I have no pg_options file at all.
Cheers,
Ed Loehr
************
From bouncefilter Mon Jan 3 14:44:45 2000
Received: from hermes.iol.cz (hermes.iol.cz [194.228.2.36])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA03757
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 14:44:11 -0500 (EST)
(envelope-from robert@robert.cz)
Received: from robert.cz ([194.228.143.69]) by hermes.iol.cz
(Post.Office MTA v3.5.3 release 223
ID# 631-64078U55000L55000S0V35) with ESMTP id cz
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 20:43:23 +0100
Message-ID: <3870FCF1.E7E026B0@robert.cz>
Date: Mon, 03 Jan 2000 20:48:01 +0100
From: Robert <robert@robert.cz>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Announce: PostgreSQL-6.5.3 binaries available for
Windows NT
References: <385F9F03.D9C199A0@hello.com.tw>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kevin Lo wrote:
Some people asked me to build PostgreSQL binaries for Windows NT.
The binaries(PostgreSQL-6.5.3) are now available at:ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Hi,
I'm trying this on Win98 (cygwin b20.1): initdb creates template1 just
fine (I had to run it as sh initdb), but whenever I try to run
postgres.exe,
it complains
FATAL 1: Database system does not exist. PGDATA
directory '/usr/local/pgsql/data' not found
even if two minutes ago it worked and the directory is there of course.
Some funny problem with mount? Any help will be greatly apreciated.
- Robert
.
From bouncefilter Mon Jan 3 22:55:49 2000
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA33765
for <pgsql-interfaces@postgreSQL.org>;
Mon, 3 Jan 2000 22:54:11 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id LAA33419;
Tue, 4 Jan 2000 11:52:40 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <38716E88.C6E61AD4@hello.com.tw>
Date: Tue, 04 Jan 2000 11:52:40 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Tusar <tusar@netshooter.com>
CC: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Announce: PostgreSQL-6.5.3 binaries available
forWindows NT
References: <Pine.LNX.4.10.10001031656240.15999-100000@bbs.myhome.com>
Content-Type: multipart/mixed; boundary="------------6219841FA783F8BA8815471E"
This is a multi-part message in MIME format.
--------------6219841FA783F8BA8815471E
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Tusar wrote:
I think there is one file ipc-daemon.exe is missing in those binary
archieve..
It's easy to compile and install ipc-daemon, that's why I didn't
include that file :)
can u please send that by mail?(only that single binary) .. I
have loaded evrything else ...
Sure.
Tusar
- Kevin
--------------6219841FA783F8BA8815471E
Content-Type: application/octet-stream;
name="ipc-daemon.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ipc-daemon.exe"
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEGAMZPcTgAigQA0AEAAOAABwELAQI3ABAAAAAG
AAAAAgAAHBwAAAAQAAAAIAAAAABAAAAQAAAAAgAABAAAAAEAAAAEAAAAAAAAAADABAAABAAA
AAAAAAIAAAAAAAACABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAABAAAAgAwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50
ZXh0AAAAcA8AAAAQAAAAEAAAAAQAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAABQAAAAAIAAA
AAIAAAAUAAAAAAAAAAAAAAAAAABAAADALmJzcwAAAAAwAQAAADAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAwC5pZGF0YQAAIAMAAABAAAAABAAAABYAAAAAAAAAAAAAAAAAAEAAAMAuc3Rh
YgAAAMheAAAAUAAAAGAAAAAaAAAAAAAAAAAAAAAAAAACAgBSLnN0YWJzdHIsDwQAALAAAAAQ
BAAAegAAAAAAAAAAAAAAAAAAAgIAUgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWJ
5YPsEIM9ACBAAAB0AczZff5mi0X+JcDw//9miUX+ZotF/g0/AwAAZolF/tlt/miAE0AA6O4N
AACJ7F3DAABVieWD7CBXVlOLdQiLfQgx24PGaIl1/IPHKMdF7AAAAACLdQiLVfzHBJ7/////
A1XsjYfwCwAAuZUAAACNdCYAicYrdQiJMoPCFAUAAgAASXnugcfwNwEAgUXs8DcBAEOD+wR+
vIt1CMdGIAAAAABmx0YcAACNZdTHRhgAAAAAx0YUAAAAAFteX4nsXcONdgBVieWD7CBXVjHJ
U4t1CDHbjb48AgAAiX38jb5AAgAAiX34jb5EAgAAiX3skI10JgDHBI7/////MdKJ2JCNdCYA
i338xwQ4AAAAAIt9+McEOAAAAACLfezHBDgAAAAAg8AMQoP6f37ZgcMsBgAAQYP5f369x4YI
AgAAAAAAAI1l1GbHhgwCAAAAAMeGAAIAAAAAAABbXl+J7F3DifZVieUx0lOLTQhmx4EMRAAA
AADHgQhEAAAAAAAAx4EERAAAAAAAAMeBAEQAAAAAAACNmQACAACNBJUAAAAAxwQYAAAAAMcE
CP////9Cg/p/fuWLXfyJ7F3DLXEATXVsdGlTZW1DdGwASVBDIERBRU1PTiAlLjAyZgBVbmFi
bGUgdG8gY3JlYXRlIHNlbWFwaG9yZQoATXVsdGlTZW1TZW0AkJCQkJCQkJCQkJCQkJCQkJCQ
kJBVbmFibGUgdG8gY3JlYXRlICJTZW0iIHNlbWFwaG9yZQoATXVsdGlTZW1TaG0AkJCQkJCQ
kJCQkJCQkJCQkJCQVW5hYmxlIHRvIGNyZWF0ZSAiU2htIiBzZW1hcGhvcmUKAE11bHRpU2Vt
TXNnAJCQkJCQkJCQkJCQkJCQkJCQkFVuYWJsZSB0byBjcmVhdGUgIk1zZyIgc2VtYXBob3Jl
CgAvdG1wL011bHRpRmlsZVNlbQAvdG1wL011bHRpRmlsZVNobQAvdG1wL011bHRpRmlsZU1z
ZwBJUEMtZGVhbW9uIGlzIG5vdyBydW5uaW5nLi4uCgCNdgCNvCcAAAAASVBDLWRhZW1vbiBp
cyBhbHJlYWR5IHN0YXJ0ZWQgISEKAJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkAoK
VW5hYmxlIHRvIHN0YXJ0IElQQy1kYWVtb24gIQoAVYnlgewQAwAAV1ZTi10I6AwLAADHhXT9
//8AAAAAg/sBfmDHhXz9//8BAAAAOZ18/f//fU6LRQy6xBFAAIPABImFHP3//4uNHP3//4nX
izHHhfz8//8DAAAAi438/P///KgA86Z1B8YFBCBAAACDhRz9//8E/4V8/f//OZ18/f//fMNo
xxFAAGoAaAMAHwDoHAsAAInChdIPhYIHAABoxxFAAGoBagBqAOgKCwAAicKF0nU/gD0EIEAA
AA+E0wcAAGjhevA/aHsUrkdo0xFAAI2dkP3//1PonAoAAGoAU2jkEUAAagDovQoAAIPEEOmh
BwAAaAASQABqAGgDAB8A6KwKAACJwokV4DBAAIXSdAZS6KoKAABoABJAAGoBagFqAOiSCgAA
o+AwQACFwHU3vtMRQACKFQQgQACE0g+EHgcAAGjhevA/aHsUrkdWjZ2Q/f//U+gfCgAAagBT
aCASQADp7QAAAGhCEkAAagBoAwAfAOg5CgAAicKJFfAwQACF0nQGUug3CgAAaEISQABqAWoB
agDoHwoAAKPwMEAAgz3gMEAAAHU5vtMRQACKFQQgQACE0g+EpgYAAGjhevA/aHsUrkdWjZ2Q
/f//U+inCQAAagBTaGASQADreJCNdCYAaIISQABqAGgDAB8A6L8JAACJwokVwDBAAIXSdAZS
6L0JAABoghJAAGoBagFqAOilCQAAo8AwQACDPeAwQAAAdUe+0xFAAIoVBCBAAITSD4QsBgAA
aOF68D9oexSuR1aNnZD9//9T6C0JAABqAFNooBJAAGoA6E4JAACDxBCKFQQgQADp+AUAAGgB
BgAAaMISQADo+QgAAInDaBBWAADo5QgAAInHiT0AMUAAMfaJ8Py5hBUAAPOraBBWAAChADFA
AFBT6LgIAACLDQAxQABR6KQIAABT6JYIAACDxCBqAmjCEkAA6KcIAABqAInDU2oBagNoEFYA
AGoA6GoIAACJhYj9//+DxCBQ6P/6//9oAQYAAGjUEkAA6HQIAACJw2gQGAMA6GAIAACJx4k9
0DBAAInw/LkExgAA86toEBgDAKHQMEAAUFPoNQgAAIsN0DBAAFHoIQgAAIPEIFPoEAgAAGoC
aNQSQADoJAgAAGoAicNTagFqA2gQGAMAagDo5wcAAImFhP3//4PEJFDo4Pn//2gBBgAAaOYS
QADo8QcAAInDaNgXBgDo3QcAAInHiT2wMEAAifD8ufaFAQDzq2jYFwYAobAwQABQU+iyBwAA
iw2wMEAAUeieBwAAg8QgU+iNBwAAagJo5hJAAOihBwAAagCJw1NqAWoDaNgXBgBqAOhkBwAA
icKDxCRS6NH4//+DxASAPQQgQAAAdC1o4XrwP2h7FK5HaNMRQACNnZD9//9T6GIHAABqAFNo
+BJAAGoA6IMHAACDxBCLhYj9//+LjYj9//+BwQAEAACJjVj9//+LjYT9//8FAAIAAImFXP3/
/42FjP3//4mFTP3//4uFhP3//4HBPAIAAImNUP3//4uNhP3//4HBQAIAAImNSP3//4uNWP3/
/wUgAgAAiYVU/f//jUWQiYVw/f//i4WE/f//iY1s/f//BUQCAACJhWT9//9o4JMEAOiEBgAA
av+LDeAwQABR6P4GAACLhVz9//+LjYj9///HhXz9//8AAAAAg8QEx4U4/f//AAAAAImFNP3/
/4mNMP3//420JgAAAACLhTD9//+LEIP6/w+ERgEAAIuNNP3//wOViP3//4mVeP3//4M5AQ+F
2wAAADH/ZoN6IAAPhLQAAACLtXz9//+LhVj9///B5gcB8ImFPP3//4uNcP3//1GLhTj9//8B
+FDoWwMAAIuNcP3//1FqAGgDAB8A6DgGAACJhYD9//+LhTz9//+DxAiDOAB+NonzifZqAIuN
gP3//1HoKgYAAIuFbP3//4uNbP3//4sEA4mFHP3//0iJBAuLhRz9//9IhcB/zouNgP3//1Ho
8gUAAIuFeP3//4PGBIOFPP3//wRHMclmi0ggOc8PjGP///+LhTD9//+LjTT9///HAP/////H
AQAAAADrUIuFeP3//zH/ZoN4IAB0QYudOP3//410JgCLjXD9//9RjQQfUOiQAgAAi41w/f//
UWoAaAMAHwDobQUAAIuFeP3//4PECEcxyWaLSCA5z3zJg4U4/f//ZIOFNP3//wSDhTD9//8E
/4V8/f//g718/f//fw+Ogf7//4uFTP3//1BqAYsN4DBAAFHoPAUAAIO9dP3//woPhW8BAADH
hXT9//8AAAAAav+h8DBAAFDoEAUAAIuNUP3//4uFhP3//4mNaP3//4uNSP3//8eFfP3//wAA
AAAFNAIAAImFRP3//8eFQP3//wAAAACJjWD9//+LhXz9//+LjYT9//+DPIH/D4S+AAAAi7Vg
/f//i51k/f//i4VQ/f//i41o/f//Mf8DtUD9//8DnUD9//8DhUD9//+JhSz9//8DjUD9//+J
jSj9//+NtCYAAAAAi4Uo/f//ixCF0nRTagBS6NQDAACDxAiFwHRei41A/f//i4VU/f//iwwI
UYsDUOitAwAAi41E/f//Zv8JiwZQ6LwDAACLjSz9///HAQAAAADHAwAAAADHBgAAAACDxAyD
xgyDwwyDhSz9//8Mg4Uo/f//DEeD/39+h4GFRP3//ywGAACBhUD9//8sBgAA/4V8/f//g718
/f//fw+OBf///4uFTP3//1BqAYsN8DBAAFHoywMAAOmo/P//jbYAAAAA/4V0/f//6Zf8//+Q
jXQmAIA9BCBAAAB0LWjhevA/aHsUrkdo0xFAAI2dkP3//1PoNAMAAGoAU2ggE0AAagDoVQMA
AIPEEGoC6MsCAACNdgCNnZD9//+E0nQjaOF68D9oexSuR1ZT6P0CAABqAFNoYBNAAGoA6B4D
AACDxBBqAeiUAgAAagDojQIAAJBVieXo3PP//4nsXcMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABVieWD7BBXVlOLTQiLfQyJzoX2fQL32THbjbQmAAAAALhnZmZm9+mJTfzBffwfwfoCK1X8
jQSSAcApwYDBMIgMO0OJ0YXJf9iF9n0FxgQ7LUPGBDsAV+gVAAAAjWXkW15fiexdwwAAAAAA
AAAAAAAAVYnlU4tdCInZidiD4AN0FnoPg/gCdAU4IXQvQTghdCpBOCF0JUGLAYTgdQiEwHQa
hOR0FakAAP8AdA2DwQSpAAAA/3Xhg+kDQUE5y3MQifZJihOKAYgDQ4gROcty8otd/InsXcMA
AAAAAAAAAAAAAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vd2luc3VwL3dp
bnN1cC5oAJBVieWD7BCLRQjHBQQwQACoAAAAxwUIMEAAFAAAAMcFDDBAAAEAAADHBYAwQAAA
AAAAxwUsMEAAYB9AAMcFMDBAAGgfQADHBRQwQAAMIEAAxwUQMEAACCBAAKMoMEAAxwUkMEAA
ECBAAI1V/IkVADBAAMcFGDBAAOgeQADHBRwwQADYHkAAxwUgMEAAIB9AAMcFRDBAABgfQABq
AOhkAQAAo3wwQADHBTQwQAAAIEAAxwU4MEAAFCBAAMcFPDBAAAAwQADHBUAwQAAwMUAAiexd
w412AFWJ5YtFCFDoIP///2gAMEAA6NIAAACJ7F3DifZVieVTi10Ii0UMUOgA////aAAwQABT
6KkAAACLXfyJ7F3DifZVieVTi10Ii0UMUOjc/v//aAAwQABT6H0AAACLXfyJ7F3DAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP8l7EBAAJCQ/yXgQEAAkJD/JfhAQACQkP8l6EBAAJCQ/yUIQUAA
kJD/JfRAQACQkP8l0EBAAJCQ/yXkQEAAkJD/JQxBQACQkP8l8EBAAJCQ/yX8QEAAkJD/JQRB
QACQkP8l3EBAAJCQ/yXYQEAAkJD/JdRAQACQkP8lzEBAAJCQ/yUAQUAAkJD/JThBQACQkP8l
IEFAAJCQ/yUsQUAAkJD/JRhBQACQkP8lKEFAAJCQ/yUkQUAAkJD/JRxBQACQkP////8AAAAA
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAFRAAAAAAAAAAAAAANxCAADMQAAAoEAAAAAAAAAAAAAAAEMAABhB
AADAQAAAAAAAAAAAAAAUQwAAOEEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBBAABMQQAA
VEEAAHBBAACAQQAAmEEAAKBBAACoQQAAsEEAALxBAADIQQAA0EEAANxBAADkQQAA8EEAAPxB
AAAIQgAAAAAAAAAAAAAQQgAAIEIAADRCAABIQgAAXEIAAHRCAAAAAAAAAAAAAIhCAAAAAAAA
AAAAAEBBAABMQQAAVEEAAHBBAACAQQAAmEEAAKBBAACoQQAAsEEAALxBAADIQQAA0EEAANxB
AADkQQAA8EEAAPxBAAAIQgAAAAAAAAAAAAAQQgAAIEIAADRCAABIQgAAXEIAAHRCAAAAAAAA
AAAAAIhCAAAAAAAAywFjYWxsb2MAAAAA2wFjbG9zZQANAmRsbF9jcnQwX19GUDExcGVyX3By
b2Nlc3MADgJkbGxfZGxsY3J0MAAAABACZGxsX25vbmN5Z3dpbl9kbGxjcnQwACgCZXhpdAAA
TAJmcmVlAACzAmtpbGwAAAcAX19tYWluAAAAAMoCbWFsbG9jAAAAANoCbW1hcAAA4AJtdW5t
YXAAAAAA6AJvcGVuAAADA3JlYWxsb2MAAABeA3NwcmludGYAAACqA3VzbGVlcAAAAAC8A3dy
aXRlABYAQ2xvc2VIYW5kbGUAAADtAEdldE1vZHVsZUhhbmRsZUEAAKEBT3BlblNlbWFwaG9y
ZUEAAAAAwwFSZWxlYXNlU2VtYXBob3JlAABCAldhaXRGb3JTaW5nbGVPYmplY3QAAAA6AENy
ZWF0ZVNlbWFwaG9yZUEAAHcBTWVzc2FnZUJveEEAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABA
AAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAGN5Z3dpbjEu
ZGxsABRAAAAUQAAAFEAAABRAAAAUQAAAFEAAAGtlcm5lbDMyLmRsbAAAAAAoQAAAdXNlcjMy
LmRsbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAD/BywPBAAHAAAAZAAAAAAQQABvAAAAZAAAAAAQQACyAAAA
gAAAAAAAAADhAAAAgAAAAAAAAAD7AAAAgAAAAAAAAAAvAQAAgAAAAAAAAABnAQAAgAAAAAAA
AACkAQAAgAAAAAAAAADwAQAAgAAAAAAAAAA8AgAAgAAAAAAAAABiAgAAgAAAAAAAAACMAgAA
gAAAAAAAAACyAgAAgAAAAAAAAADXAgAAgAAAAAAAAADxAgAAgAAAAAAAAAAMAwAAgAAAAAAA
AAAtAwAAgAAAAAAAAABmAwAAgAAAAAAAAACJAwAAgAAAAAAAAACtAwAAgAAAAAAAAADXAwAA
gAAAAAAAAADrAwAAIAAVAAAAAAADBAAAJAAcAAAQQAAaBAAARAAcAAAAAAAaBAAARAAeAAYA
AAAaBAAARAAfAA8AAAAaBAAARAAiABAAAAAaBAAARAAlABAAAAAaBAAARAAoABMAAAAaBAAA
RAApACAAAAAaBAAARAAsAC0AAAAaBAAARAAwADAAAAAaBAAARAAxADoAAAAaBAAAwAAAAAAA
AAAbBAAAgAAiAP7///8aBAAAwAAAABAAAAAaBAAA4AAAABAAAAAaBAAA4AAAABAAAAAaBAAA
JAAAAD4AAAAaBAAAZAAAAD4QQAAkBAAAZAAAACAdQAB6BAAAZAAAACAdQACyAAAAgAAAAAAA
AADhAAAAgAAAAAAAAAD7AAAAgAAAAAAAAAAvAQAAgAAAAAAAAABnAQAAgAAAAAAAAACkAQAA
gAAAAAAAAADwAQAAgAAAAAAAAAA8AgAAgAAAAAAAAABiAgAAgAAAAAAAAACMAgAAgAAAAAAA
AACyAgAAgAAAAAAAAADXAgAAgAAAAAAAAADxAgAAgAAAAAAAAAAMAwAAgAAAAAAAAAAtAwAA
gAAAAAAAAABmAwAAgAAAAAAAAACJAwAAgAAAAAAAAACtAwAAgAAAAAAAAACwBAAAgAAAAAAA
AADGBAAAgAAAAAAAAADaBAAAgAAAAAAAAAD9BAAAgAAAAAAAAABwBQAAggAAALn4BgCjBQAA
ggAAAMnhAADmBQAAggAAAMMPAABiBgAAgAB2AAAAAAB5BgAAgACqAAAAAACNBgAAgAAYAQAA
AAAaBAAAogAAAAAAAAChBgAAggAAAAAAAAAaBAAAogAAAAAAAADoBgAAgAAxAAAAAAD9BgAA
gAAyAAAAAAASBwAAgAAzAAAAAAAlBwAAgAA0AAAAAAA5BwAAgAA3AAAAAABNBwAAgAA4AAAA
AABfBwAAgAA8AAAAAABzBwAAgABAAAAAAACIBwAAgABBAAAAAAClBwAAgABEAAAAAAC5BwAA
gABOAAAAAADTBwAAgABPAAAAAADrBwAAgABTAAAAAAAACAAAgABUAAAAAAAYCAAAgABVAAAA
AAAuCAAAgABWAAAAAABGCAAAgABXAAAAAABcCAAAgABYAAAAAAB0CAAAgABZAAAAAACKCAAA
gABaAAAAAACiCAAAgABbAAAAAAC8CAAAgABlAAAAAADQCAAAgABnAAAAAADkCAAAgABpAAAA
AAD4CAAAgABqAAAAAAAMCQAAgABrAAAAAAAgCQAAgABsAAAAAAA0CQAAgABtAAAAAABKCQAA
gABwAAAAAABgCQAAgABxAAAAAAB1CQAAgAB+AAAAAACLCQAAgACSAAAAAAChCQAAgAAAAAAA
AABqCgAAgACcAAAAAAAaBAAAogAAAAAAAACBCgAAggAAAAAAAAAaBAAAogAAAAAAAADACgAA
ggAAAM6AAAABCwAAggAAAMuJAABDCwAAggAAAAAAAACCCwAAggAAAIkLAADGCwAAgABnAAAA
AADdCwAAgABoAAAAAAAaBAAAogAAAAAAAAAaBAAAogAAAAAAAAD1CwAAgAASAAAAAACbDAAA
gAAXAAAAAABUDQAAggAAAAAAAACTDQAAggAAAAAAAAAaBAAAogAAAAAAAAABCwAAggAAAAAA
AAAaBAAAogAAAAAAAADRDQAAggAAAAlLAAAPDgAAggAAAAAAAAAaBAAAogAAAAAAAADmBQAA
ggAAAAAAAAAaBAAAogAAAAAAAABVDgAAgAAkAAAAAABrDgAAgAA4AAAAAAAaBAAAogAAAAAA
AAAaBAAAogAAAAAAAACXDwAAgAAmAAAAAAAaBAAAogAAAAAAAABVEAAAgAAfAAAAAAAaBAAA
ogAAAAAAAAA8EgAAggAAAAAAAAB8EgAAggAAAAUTAADEEgAAgACGAAAAAADuEgAAggAAAOUO
AAAuEwAAggAAAIQ7AAByEwAAgAANAAAAAACJEwAAgAATAAAAAAAaBAAAogAAAAAAAABsFAAA
gAAKAAAAAACHFAAAgAAQAAAAAAAaBAAAogAAAAAAAACkFAAAgACNAAAAAAAaBAAAogAAAAAA
AAAaBAAAogAAAAAAAADRFAAAggAAAAAAAADmBQAAwgAAAAAAAAAaBAAAogAAAAAAAAARFQAA
ggAAAAAAAABNFQAAggAAAAAAAAAaBAAAogAAAAAAAACIFQAAggAAAHENAAAEFgAAgABGAAAA
AAAiFgAAgAC1AAAAAAAaBAAAogAAAAAAAAA5FgAAggAAAAfXBgB8FgAAgAA+AAAAAACPFgAA
gABGAAAAAAClFgAAgABJAAAAAAC5FgAAgABMAAAAAADQFgAAgABNAAAAAADkFgAAgABOAAAA
AAD6FgAAgABPAAAAAAAOFwAAgABQAAAAAAAiFwAAgABRAAAAAAA5FwAAgABaAAAAAABPFwAA
gABgAAAAAABjFwAAgABhAAAAAAB4FwAAgABiAAAAAACMFwAAgABpAAAAAAChFwAAgABqAAAA
AAC7FwAAgABqAAAAAADfFwAAgAByAAAAAAD1FwAAgAB0AAAAAAAMGAAAgAB1AAAAAAAkGAAA
gAB2AAAAAAA9GAAAgAB3AAAAAABVGAAAgAB4AAAAAAByGAAAgAB5AAAAAACJGAAAgAB6AAAA
AACkGAAAgAB7AAAAAAC9GAAAgAB8AAAAAADTGAAAgAB9AAAAAADoGAAAgAB+AAAAAAACGQAA
gAB/AAAAAAAZGQAAgACAAAAAAAAwGQAAgACBAAAAAABGGQAAgACCAAAAAABkGQAAgACDAAAA
AAB6GQAAgACEAAAAAACPGQAAgACJAAAAAACmGQAAgACKAAAAAAC/GQAAgACLAAAAAADYGQAA
gACMAAAAAADvGQAAgACNAAAAAAAGGgAAgACOAAAAAAAdGgAAgACPAAAAAAA5GgAAgACQAAAA
AABUGgAAgACRAAAAAABqGgAAgACRAAAAAACKGgAAgACSAAAAAACfGgAAgACTAAAAAAC3GgAA
gACUAAAAAADOGgAAgACVAAAAAADpGgAAgACWAAAAAAACGwAAgACXAAAAAAAcGwAAgACYAAAA
AAAyGwAAgACZAAAAAABMGwAAgACaAAAAAABjGwAAgACbAAAAAAB5GwAAgACcAAAAAACQGwAA
gACdAAAAAACnGwAAgACeAAAAAAC8GwAAgACfAAAAAADVGwAAgACgAAAAAADrGwAAgAChAAAA
AAD+GwAAgACiAAAAAAAUHAAAgACjAAAAAAAqHAAAgACkAAAAAABCHAAAgACmAAAAAABbHAAA
gACmAAAAAAB2HAAAgACnAAAAAACRHAAAgACoAAAAAACnHAAAgACpAAAAAADHHAAAgACqAAAA
AADnHAAAgACrAAAAAAAHHQAAgACsAAAAAAAmHQAAgACtAAAAAABKHQAAgACuAAAAAABpHQAA
gACzAAAAAACCHQAAgAC2AAAAAACjHQAAgAC3AAAAAAC8HQAAgAC4AAAAAADeHQAAgAC6AAAA
AAD4HQAAgAC8AAAAAAAWHgAAgAC9AAAAAAA1HgAAgAC+AAAAAABLHgAAgADEAAAAAABhHgAA
gADFAAAAAAB4HgAAgADIAAAAAACPHgAAgADJAAAAAACmHgAAgADKAAAAAADIHgAAgADLAAAA
AADqHgAAgADMAAAAAAADHwAAgADNAAAAAAAdHwAAgADPAAAAAAA2HwAAgADQAAAAAABRHwAA
gADRAAAAAABsHwAAgADSAAAAAACEHwAAgADTAAAAAACbHwAAgADUAAAAAACxHwAAgADVAAAA
AADJHwAAgADWAAAAAADhHwAAgADXAAAAAAD5HwAAgADYAAAAAAASIAAAgADZAAAAAAArIAAA
gADaAAAAAABNIAAAgADbAAAAAABnIAAAgADdAAAAAAB+IAAAgADfAAAAAACWIAAAgADgAAAA
AAC3IAAAgADiAAAAAADNIAAAgADjAAAAAADiIAAAgADrAAAAAAAEIQAAgADsAAAAAAAaIQAA
gADtAAAAAAAyIQAAgADuAAAAAABJIQAAgADxAAAAAABjIQAAgADyAAAAAACDIQAAgADzAAAA
AACkIQAAgAD0AAAAAAC+IQAAgAD1AAAAAADVIQAAgAD2AAAAAADtIQAAgAD3AAAAAAAHIgAA
gAD4AAAAAAAfIgAAgAD+AAAAAAA3IgAAgAAAAQAAAABTIgAAgAABAQAAAABtIgAAgAACAQAA
AACWIgAAgAADAQAAAAC+IgAAgAALAQAAAADVIgAAgAAMAQAAAADrIgAAgAANAQAAAAACIwAA
gAAQAQAAAAAZIwAAgAARAQAAAAAuIwAAgAASAQAAAABEIwAAgAATAQAAAABbIwAAgAAVAQAA
AABwIwAAgAAWAQAAAACHIwAAgAA1AQAAAADZIwAAgAA3AQAAAAACJAAAgAA6AQAAAADQJAAA
gABHAQAAAADuJAAAgABRAQAAAACaJwAAgABwAQAAAAC6JwAAgABzAQAAAAAaKAAAgAB3AQAA
AAA7KAAAgAB6AQAAAADAKAAAgAB+AQAAAADwKAAAgACBAQAAAACZKQAAgACJAQAAAAC5KQAA
gACJAQAAAADkKQAAgACMAQAAAACxKgAAgACWAQAAAADcKgAAgACZAQAAAAAbKwAAgACbAQAA
AAA5KwAAgAD1AQAAAABpKwAAgAD2AQAAAACdKwAAgAD3AQAAAAC9KwAAgAD4AQAAAAD5KwAA
gAD5AQAAAAAjLAAAgAD6AQAAAABcLAAAgAD7AQAAAAB8LAAAgAD8AQAAAACdLAAAgAD9AQAA
AADALAAAgAD+AQAAAADjLAAAgAD/AQAAAAAQLQAAgAAAAgAAAABJLQAAgAABAgAAAACGLQAA
gAACAgAAAAC3LQAAgAADAgAAAADlLQAAgAAEAgAAAAARLgAAgAAFAgAAAAApLgAAgAAGAgAA
AABeLgAAgAAHAgAAAACTLgAAgAAIAgAAAADILgAAgAAJAgAAAADrLgAAgAAKAgAAAAAgLwAA
gAALAgAAAABbLwAAgAAMAgAAAACOLwAAgAANAgAAAAC9LwAAgAAOAgAAAADfLwAAgAAPAgAA
AAASMAAAgAAQAgAAAABGMAAAgAARAgAAAAB4MAAAgAASAgAAAACnMAAAgAATAgAAAADcMAAA
gAAUAgAAAAANMQAAgAAVAgAAAAA8MQAAgAAWAgAAAABfMQAAgAAXAgAAAACCMQAAgAAYAgAA
AACyMQAAgAAZAgAAAADsMQAAgAAaAgAAAAAMMgAAgAAbAgAAAABBMgAAgAAcAgAAAABmMgAA
gAAdAgAAAACKMgAAgAAeAgAAAACuMgAAgAAfAgAAAADSMgAAgAAgAgAAAAAIMwAAgAAhAgAA
AAAuMwAAgAAiAgAAAABnMwAAgAAjAgAAAACiMwAAgAAkAgAAAADaMwAAgABgAgAAAAAFNAAA
gABhAgAAAAAkNAAAgABjAgAAAABUNAAAgABoAgAAAABzNAAAgABpAgAAAACUNAAAgABqAgAA
AACuNAAAgABqAgAAAADJNAAAgABqAgAAAADlNAAAgABrAgAAAAAENQAAgABrAgAAAAAkNQAA
gABrAgAAAAAaBAAAogAAAAAAAABFNQAAggAAAAAAAAAaBAAAogAAAAAAAACMNQAAggAAAAAA
AAAaBAAAogAAAAAAAADSNQAAggAAAMkhwwAbNgAAgAAuAAAAAADONgAAgAAuAAAAAADhNgAA
gAAuAAAAAAD2NgAAgAA0AAAAAADJNwAAgAA0AAAAAADiNwAAgAA0AAAAAAD+NwAAgAA6AAAA
AADLOAAAgAA6AAAAAADiOAAAgAA6AAAAAAD7OAAAgABAAAAAAADdOQAAgABAAAAAAAD5OQAA
gABCAAAAAAAWOgAAgABDAAAAAAAuOgAAgABJAAAAAAAxOwAAgABJAAAAAABVOwAAgABPAAAA
AABUPAAAgABPAAAAAAB3PAAAgABVAAAAAAB2PQAAgABVAAAAAACVPQAAgABdAAAAAACFPgAA
gABdAAAAAACaPgAAgABdAAAAAACwPgAAgABhAAAAAAClPwAAgABhAAAAAADPPwAAgABnAAAA
AADpQAAAgABnAAAAAAAPQQAAgABtAAAAAAANQgAAgABtAAAAAAAsQgAAgACLAAAAAADmRQAA
gACLAAAAAAAGRgAAgACQAAAAAADcRgAAgACQAAAAAAD7RgAAgACVAAAAAADmRwAAgACVAAAA
AAAGSAAAgACVAAAAAAApSAAAgACcAAAAAAAKSQAAgACcAAAAAAAiSQAAgACcAAAAAAA8SQAA
gACcAAAAAABVSQAAgACjAAAAAAA6SgAAgACjAAAAAABTSgAAgACsAAAAAACHSwAAgACsAAAA
AAClSwAAgACsAAAAAADESwAAgAC3AAAAAAAPTQAAgAC3AAAAAAApTQAAgAC3AAAAAABETQAA
gAC3AAAAAABgTQAAgAC3AAAAAAB8TQAAgAC/AAAAAAC/TgAAgAC/AAAAAADjTgAAgAC/AAAA
AAAITwAAgAC/AAAAAAAuTwAAgADFAAAAAAAcUAAAgADFAAAAAAA5UAAAgADFAAAAAABXUAAA
gADFAAAAAAB2UAAAgADKAAAAAACEUQAAgADKAAAAAACmUQAAgADKAAAAAADJUQAAgADKAAAA
AADtUQAAgADSAAAAAAAzUwAAgADSAAAAAABXUwAAgADgAAAAAABGVQAAgADgAAAAAABqVQAA
gADgAAAAAACQVQAAgADgAAAAAAC1VQAAgADnAAAAAACwVgAAgADnAAAAAADLVgAAgADnAAAA
AADnVgAAgADnAAAAAAAEVwAAgADsAAAAAAACWAAAgADsAAAAAAAgWAAAgADsAAAAAABAWAAA
gADsAAAAAABfWAAAgADxAAAAAABnWQAAgADxAAAAAACJWQAAgADxAAAAAACtWQAAgADxAAAA
AADQWQAAgADzAAAAAADrWQAAgADzAAAAAAAKWgAAgAD6AAAAAADyWgAAgAD6AAAAAAAMWwAA
gAD6AAAAAAAoWwAAgAABAQAAAAA0XAAAgAABAQAAAABUXAAAgAABAQAAAAB2XAAAgAAYAQAA
AAAvYgAAgAAYAQAAAABTYgAAgAAYAQAAAAB2YgAAgAAdAQAAAAA2YwAAgAAdAQAAAABOYwAA
gAAiAQAAAAAoZAAAgAAiAQAAAABEZAAAgAAiAQAAAABiZAAAgAAjAQAAAACLZAAAgAAnAQAA
AABLZQAAgAAnAQAAAABpZQAAgAAnAQAAAACJZQAAgAAoAQAAAAC0ZQAAgAAzAQAAAAAdZwAA
gAAzAQAAAAA7ZwAAgAAzAQAAAABaZwAAgAAzAQAAAAB6ZwAAgAA4AQAAAABVaAAAgAA4AQAA
AABxaAAAgAA4AQAAAACPaAAAgAA4AQAAAACsaAAAgABFAQAAAADMagAAgABFAQAAAAD6agAA
gABFAQAAAAAqawAAgABKAQAAAADnawAAgABKAQAAAAAAbAAAgABPAQAAAAC+bAAAgABPAQAA
AADXbAAAgABPAQAAAADybAAAgABPAQAAAAAMbQAAgABUAQAAAADWbQAAgABUAQAAAADxbQAA
gABZAQAAAACrbgAAgABZAQAAAADFbgAAgABeAQAAAACHbwAAgABeAQAAAAChbwAAgABlAQAA
AADGcAAAgABlAQAAAADncAAAgABlAQAAAAAKcQAAgABvAQAAAACKcgAAgABvAQAAAACrcgAA
gABvAQAAAADOcgAAgAB+AQAAAACKdAAAgAB+AQAAAACqdAAAgAB+AQAAAADMdAAAgACDAQAA
AAC+dQAAgACDAQAAAADfdQAAgACIAQAAAADcdgAAgACIAQAAAAABdwAAgACQAQAAAABCeQAA
gACQAQAAAABfeQAAgACQAQAAAAB9eQAAgACcAQAAAAAWewAAgACcAQAAAAA0ewAAgAChAQAA
AAAEfAAAgAChAQAAAAAhfAAAgACmAQAAAAD3fAAAgACmAQAAAAASfQAAgACrAQAAAAAjfgAA
gACrAQAAAABEfgAAgACrAQAAAABnfgAAgACxAQAAAABPgAAAgACxAQAAAABwgAAAgAC9AQAA
AACagwAAgAC9AQAAAAC7gwAAgADOAQAAAADNhQAAgADOAQAAAADphQAAgADOAQAAAAAHhgAA
gADOAQAAAAAkhgAAgADfAQAAAABKiAAAgADfAQAAAABmiAAAgADfAQAAAACEiAAAgADfAQAA
AAChiAAAgADkAQAAAAC8iAAAgADnAQAAAADiiAAAgADoAQAAAAD/iAAAgADpAQAAAAAciQAA
gAD8AQAAAACxjQAAgAD8AQAAAADRjQAAgAABAgAAAACKjgAAgAABAgAAAACijgAAgAABAgAA
AAC7jgAAgAAGAgAAAADFjwAAgAAGAgAAAADrjwAAgAAIAgAAAAAdkAAAgAAUAgAAAAC2kQAA
gAAUAgAAAADdkQAAgAAUAgAAAAAGkgAAgAAjAgAAAAAhlAAAgAAjAgAAAABElAAAgAAjAgAA
AABplAAAgAAoAgAAAAAtlQAAgAAoAgAAAABJlQAAgAAoAgAAAABnlQAAgABHAgAAAAB8mAAA
gABHAgAAAACTmAAAgABHAgAAAACsmAAAgABSAgAAAABImgAAgABSAgAAAABmmgAAgABSAgAA
AACGmgAAgABnAgAAAAA6nQAAgABnAgAAAABWnQAAgABnAgAAAAB0nQAAgABvAgAAAADungAA
gABvAgAAAAAOnwAAgABvAgAAAAAwnwAAgAB5AgAAAACloAAAgAB5AgAAAADKoAAAgAB/AgAA
AAC6ogAAgACFAgAAAADQowAAgACFAgAAAADzowAAgACFAgAAAAAYpAAAgACSAgAAAACLpQAA
gACSAgAAAACmpQAAgACSAgAAAADDpQAAgACXAgAAAAC+pgAAgACXAgAAAADlpgAAgACXAgAA
AAANpwAAgACcAgAAAADDpwAAgACcAgAAAADcpwAAgACjAgAAAADWqAAAgACjAgAAAAD0qAAA
gACjAgAAAAATqQAAgACrAgAAAACNqgAAgACrAgAAAAC7qgAAgACrAgAAAADqqgAAgAC5AgAA
AAC7rAAAgAC5AgAAAADhrAAAgADZAgAAAAB1rwAAgADZAgAAAACQrwAAgADZAgAAAACsrwAA
gADZAgAAAADJrwAAgABAAwAAAACfsAAAgABAAwAAAAC9sAAAgABAAwAAAADcsAAAgABLAwAA
AADRsgAAgABLAwAAAAD7sgAAgABLAwAAAAAmswAAgABUAwAAAAB/tAAAgABUAwAAAACjtAAA
gABUAwAAAADItAAAgABUAwAAAADutAAAgABcAwAAAABRtgAAgABcAwAAAACAtgAAgABmAwAA
AADYtwAAgABmAwAAAAD3twAAgABoAwAAAAAhuAAAgAB7AwAAAABPugAAgAB7AwAAAABrugAA
gACBAwAAAABwuwAAgACBAwAAAACSuwAAgACHAwAAAACivAAAgACHAwAAAAC8vAAAgACHAwAA
AADYvAAAgACOAwAAAADOvQAAgACOAwAAAADpvQAAgACbAwAAAADmvwAAgACbAwAAAAATwAAA
gAChAwAAAABMwQAAgAChAwAAAAB4wQAAgAC9AwAAAAAJwwAAgAC9AwAAAAAowwAAgADHAwAA
AABpxAAAgADHAwAAAACIxAAAgADHAwAAAACpxAAAgADPAwAAAADRxQAAgADPAwAAAADxxQAA
gADWAwAAAAD3xgAAgADWAwAAAAAUxwAAgADaAwAAAADsxwAAgADaAwAAAAAQyAAAgADhAwAA
AAALygAAgADoAwAAAAARzAAAgADyAwAAAACJzgAAgAD6AwAAAACv0AAAgAABBAAAAADs0QAA
gAABBAAAAAAT0gAAgAAJBAAAAABJ1AAAgAATBAAAAAC/1gAAgAAcBAAAAABV2AAAgAAcBAAA
AAB52AAAgAAcBAAAAACe2AAAgAAcBAAAAADE2AAAgAAhBAAAAADW2QAAgAAhBAAAAAD+2QAA
gAAlBAAAAAD32gAAgAAlBAAAAAAi2wAAgAApBAAAAAAX3AAAgAApBAAAAABB3AAAgAAyBAAA
AAC13QAAgAAyBAAAAADc3QAAgAA2BAAAAADO3gAAgAA2BAAAAAD33gAAgAA8BAAAAAA14AAA
gAA8BAAAAABh4AAAgABBBAAAAAAu4QAAgABBBAAAAABK4QAAgABSBAAAAACT5AAAgABSBAAA
AACy5AAAgABSBAAAAADT5AAAgABaBAAAAAAI5gAAgABaBAAAAAAp5gAAgABiBAAAAABo5wAA
gABiBAAAAACM5wAAgABoBAAAAACq6AAAgABoBAAAAADP6AAAgABpBAAAAAD/6AAAgABxBAAA
AABa6gAAgABxBAAAAAB/6gAAgAByBAAAAACv6gAAgAB5BAAAAAD76wAAgAB5BAAAAAAh7AAA
gAB6BAAAAABS7AAAgACABAAAAACQ7QAAgACIBAAAAADy7gAAgACIBAAAAAAa7wAAgACJBAAA
AABN7wAAgACsBAAAAABx8wAAgACsBAAAAACM8wAAgACsBAAAAACo8wAAgACsBAAAAADF8wAA
gACsBAAAAADi8wAAgAC0BAAAAAD+8wAAgAC1BAAAAAAb9AAAgAC2BAAAAAA59AAAgAC3BAAA
AABX9AAAgAC/BAAAAABy9QAAgAC/BAAAAACO9QAAgAC/BAAAAACs9QAAgADHBAAAAADc9gAA
gADHBAAAAAD69gAAgADMBAAAAADf9wAAgADMBAAAAAAA+AAAgADMBAAAAAAi+AAAgADUBAAA
AABq+QAAgADUBAAAAACL+QAAgADeBAAAAAAF+wAAgADeBAAAAAAp+wAAgADoBAAAAABy/AAA
gADoBAAAAACV/AAAgADoBAAAAAC6/AAAgADoBAAAAADe/AAAgADyBAAAAAAZ/gAAgADyBAAA
AAA5/gAAgADyBAAAAABb/gAAgADyBAAAAAB+/gAAgAD4BAAAAAB9/wAAgAD4BAAAAACd/wAA
gAAABQAAAADGAAEAgAAABQAAAADmAAEAgAAIBQAAAABXAwEAgAAIBQAAAAB2AwEAgAAOBQAA
AACOBQEAgAAOBQAAAACyBQEAgAAaBQAAAABRBwEAgAAaBQAAAAB1BwEAgAAaBQAAAACbBwEA
gAAaBQAAAADABwEAgAAiBQAAAABCCgEAgAAiBQAAAABoCgEAgAAsBQAAAAAVDAEAgAAsBQAA
AABADAEAgAAyBQAAAACZDQEAgAAyBQAAAADHDQEAgAA2BQAAAACcDgEAgAA2BQAAAAC/DgEA
gAA/BQAAAAAVEAEAgAA/BQAAAAA4EAEAgABMBQAAAAACEgEAgABMBQAAAAAlEgEAgABSBQAA
AAAjEwEAgABSBQAAAABDEwEAgABYBQAAAAAKFAEAgABYBQAAAAAjFAEAgABYBQAAAAA9FAEA
gABhBQAAAAB5FQEAgABhBQAAAACaFQEAgABhBQAAAAC8FQEAgABpBQAAAADDFgEAgABpBQAA
AADfFgEAgABpBQAAAAD8FgEAgABqBQAAAAAaFwEAgABqBQAAAAA5FwEAgABrBQAAAABXFwEA
gABrBQAAAAB2FwEAgABsBQAAAACSFwEAgABsBQAAAACvFwEAgAB2BQAAAADBGAEAgAB2BQAA
AADcGAEAgAB2BQAAAAD4GAEAgAB2BQAAAAAVGQEAgACJBQAAAAArGwEAgACJBQAAAABKGwEA
gACJBQAAAABqGwEAgACPBQAAAABiHAEAgACPBQAAAACAHAEAgACWBQAAAACrHQEAgACWBQAA
AADXHQEAgACWBQAAAAAEHgEAgACYBQAAAAAhHgEAgACZBQAAAABCHgEAgACnBQAAAAAxIAEA
gACnBQAAAABUIAEAgACnBQAAAAB5IAEAgACuBQAAAACZIQEAgACuBQAAAADCIQEAgACuBQAA
AADsIQEAgAC5BQAAAACBIwEAgAC5BQAAAACxIwEAgAC5BQAAAADiIwEAgADEBQAAAABXJQEA
gADEBQAAAAB/JQEAgADEBQAAAACoJQEAgADLBQAAAAC5JgEAgADLBQAAAADbJgEAgADLBQAA
AAD/JgEAgADLBQAAAAAiJwEAgADRBQAAAABIKAEAgADRBQAAAABoKAEAgADRBQAAAACKKAEA
gADRBQAAAACrKAEAgADYBQAAAAC+KQEAgADYBQAAAADkKQEAgADYBQAAAAALKgEAgADeBQAA
AAAAKwEAgADeBQAAAAAcKwEAgADlBQAAAAAgLAEAgADlBQAAAABCLAEAgADlBQAAAABlLAEA
gADrBQAAAABOLQEAgADrBQAAAABuLQEAgADrBQAAAACPLQEAgADsBQAAAACxLQEAgADsBQAA
AADULQEAgAD0BQAAAADjLgEAgAD0BQAAAAD/LgEAgAD0BQAAAAAcLwEAgAD6BQAAAAAmMAEA
gAD6BQAAAABOMAEAgAD6BQAAAAB3MAEAgAD7BQAAAAChMAEAgAD7BQAAAADMMAEAgAAIBgAA
AABeMgEAgAAIBgAAAAB6MgEAgAAVBgAAAAB1NAEAgAAVBgAAAACVNAEAgAAcBgAAAADQNQEA
gAAcBgAAAAD/NQEAgAAcBgAAAAAvNgEAgAAmBgAAAACiNwEAgAAmBgAAAADBNwEAgAAxBgAA
AAAoOQEAgAAxBgAAAABNOQEAgAAxBgAAAABzOQEAgAA5BgAAAACcOgEAgAA5BgAAAADBOgEA
gAA5BgAAAADnOgEAgABBBgAAAAAgPAEAgABBBgAAAABJPAEAgABBBgAAAABzPAEAgABLBgAA
AACwPQEAgABLBgAAAADNPQEAgABLBgAAAADrPQEAgABVBgAAAABMPwEAgABVBgAAAABwPwEA
gABVBgAAAACVPwEAgABWBgAAAAC5PwEAgABWBgAAAADePwEAgABcBgAAAADOQAEAgABcBgAA
AADvQAEAgABcBgAAAAARQQEAgABdBgAAAAA7QQEAgABdBgAAAABmQQEAgABeBgAAAACJQQEA
gABeBgAAAACtQQEAgABnBgAAAADgQgEAgABnBgAAAAAAQwEAgABnBgAAAAAhQwEAgABuBgAA
AAA2RAEAgABuBgAAAABVRAEAgABzBgAAAAAaRQEAgABzBgAAAAA0RQEAgABzBgAAAABPRQEA
gABzBgAAAABrRQEAgABzBgAAAACGRQEAgABzBgAAAACiRQEAgABzBgAAAAC/RQEAgAB9BgAA
AAARRwEAgAB9BgAAAAAyRwEAgAB9BgAAAABURwEAgACEBgAAAABaSAEAgACEBgAAAAB9SAEA
gACEBgAAAAChSAEAgACMBgAAAADFSQEAgACMBgAAAADnSQEAgACMBgAAAAAKSgEAgACNBgAA
AAArSgEAgACNBgAAAABNSgEAgACTBgAAAAAuSwEAgACTBgAAAABNSwEAgACTBgAAAABtSwEA
gACUBgAAAACOSwEAgACUBgAAAACwSwEAgACvBgAAAACPTgEAgACvBgAAAACvTgEAgACvBgAA
AADQTgEAgAC2BgAAAAACUAEAgAC2BgAAAAAvUAEAgAC2BgAAAABdUAEAgAC8BgAAAABgUQEA
gAC8BgAAAACGUQEAgAC8BgAAAACtUQEAgADVBgAAAAB6VAEAgADVBgAAAACZVAEAgADVBgAA
AAC5VAEAgADeBgAAAAD/VQEAgADeBgAAAAAgVgEAgADeBgAAAABCVgEAgADnBgAAAACQVwEA
gADnBgAAAACzVwEAgADnBgAAAADXVwEAgADvBgAAAADxWAEAgADvBgAAAAASWQEAgADvBgAA
AAA0WQEAgADwBgAAAABXWQEAgADwBgAAAAB7WQEAgADxBgAAAACbWQEAgADxBgAAAAC8WQEA
gADyBgAAAADhWQEAgADyBgAAAAAHWgEAgADzBgAAAAAqWgEAgADzBgAAAABOWgEAgAD7BgAA
AABwWwEAgAD7BgAAAACTWwEAgAD7BgAAAAC3WwEAgAD8BgAAAADcWwEAgAD8BgAAAAACXAEA
gAD9BgAAAAAkXAEAgAD9BgAAAABHXAEAgAD+BgAAAABuXAEAgAD+BgAAAACWXAEAgAD/BgAA
AAC7XAEAgAD/BgAAAADhXAEAgAAJBwAAAAA9XgEAgAAJBwAAAABiXgEAgAAJBwAAAACIXgEA
gAAKBwAAAACsXgEAgAAKBwAAAADRXgEAgAAUBwAAAAA1YAEAgAAUBwAAAABcYAEAgAAUBwAA
AACEYAEAgAAVBwAAAACqYAEAgAAVBwAAAADRYAEAgAAgBwAAAABlYgEAgAAgBwAAAACKYgEA
gAAgBwAAAACwYgEAgAAhBwAAAADVYgEAgAAhBwAAAAD7YgEAgAAoBwAAAAAQZAEAgAAoBwAA
AAA2ZAEAgAAoBwAAAABdZAEAgAAuBwAAAABPZQEAgAAuBwAAAABxZQEAgAAuBwAAAACUZQEA
gAA1BwAAAACgZgEAgAA1BwAAAADCZgEAgAA1BwAAAADlZgEAgAA+BwAAAAA1aAEAgAA+BwAA
AABgaAEAgAA+BwAAAACMaAEAgAA/BwAAAAC1aAEAgAA/BwAAAADfaAEAgABFBwAAAADoaQEA
gABFBwAAAAARagEAgABFBwAAAAA7agEAgABGBwAAAABkagEAgABGBwAAAACOagEAgABLBwAA
AACLawEAgABLBwAAAACwawEAgABLBwAAAADWawEAgABMBwAAAAD7awEAgABMBwAAAAAhbAEA
gABSBwAAAAAfbQEAgABSBwAAAABFbQEAgABSBwAAAABsbQEAgABYBwAAAAB6bgEAgABYBwAA
AACibgEAgABYBwAAAADLbgEAgABeBwAAAADGbwEAgABeBwAAAADpbwEAgABeBwAAAAANcAEA
gABfBwAAAAAycAEAgABfBwAAAABYcAEAgABlBwAAAAB2cQEAgABlBwAAAAChcQEAgABlBwAA
AADNcQEAgAB4BwAAAAAKdAEAgAB4BwAAAAA0dAEAgAB4BwAAAABfdAEAgAB+BwAAAABjdQEA
gAB+BwAAAACKdQEAgAB+BwAAAACydQEAgACEBwAAAAC2dgEAgACEBwAAAADcdgEAgACEBwAA
AAADdwEAgACNBwAAAABbeAEAgACNBwAAAACFeAEAgACNBwAAAACweAEAgACUBwAAAAC4eQEA
gACUBwAAAADaeQEAgACUBwAAAAD9eQEAgACaBwAAAAANewEAgACaBwAAAAA2ewEAgACaBwAA
AABgewEAgACbBwAAAACHewEAgACbBwAAAACvewEAgAChBwAAAAC+fAEAgAChBwAAAADnfAEA
gAChBwAAAAARfQEAgACiBwAAAAA4fQEAgACiBwAAAABgfQEAgACjBwAAAACGfQEAgACjBwAA
AACtfQEAgACpBwAAAAC+fgEAgACpBwAAAADofgEAgACpBwAAAAATfwEAgAC/BwAAAAB8gQEA
gAC/BwAAAACfgQEAgAC/BwAAAADDgQEAgADTBwAAAAABhAEAgADTBwAAAAAnhAEAgADTBwAA
AABOhAEAgADYBwAAAAAbhQEAgADYBwAAAAA9hQEAgADYBwAAAABghQEAgADZBwAAAACChQEA
gADZBwAAAAClhQEAgADaBwAAAADFhQEAgADaBwAAAADmhQEAgADbBwAAAAAKhgEAgADbBwAA
AAAvhgEAgADcBwAAAABThgEAgADcBwAAAAB4hgEAgADdBwAAAACahgEAgADdBwAAAAC9hgEA
gADeBwAAAADghgEAgADeBwAAAAAEhwEAgADfBwAAAAAjhwEAgADfBwAAAABDhwEAgADgBwAA
AABqhwEAgADgBwAAAACShwEAgADmBwAAAACUiAEAgADmBwAAAAC7iAEAgADmBwAAAADjiAEA
gADnBwAAAAAFiQEAgADnBwAAAAAoiQEAgADoBwAAAABLiQEAgADoBwAAAABviQEAgADpBwAA
AACXiQEAgADpBwAAAADAiQEAgADqBwAAAADgiQEAgADqBwAAAAABigEAgADrBwAAAAArigEA
gADrBwAAAABWigEAgADsBwAAAAB7igEAgADsBwAAAAChigEAgADtBwAAAADDigEAgADtBwAA
AADmigEAgADzBwAAAADPiwEAgADzBwAAAADqiwEAgADzBwAAAAAGjAEAgADzBwAAAAAjjAEA
gAD5BwAAAAAmjQEAgAD5BwAAAABJjQEAgAAACAAAAABYjgEAgAAACAAAAAB5jgEAgAAGCAAA
AACMkAEAgAANCAAAAACzkgEAgAAfCAAAAAD8lAEAgAAfCAAAAAAflQEAgAAfCAAAAABElQEA
gAAlCAAAAABLlgEAgAAlCAAAAABulgEAgAAlCAAAAACSlgEAgAAlCAAAAAC3lgEAgAAtCAAA
AADclwEAgAAtCAAAAAD9lwEAgAA3CAAAAACamQEAgAA3CAAAAAC+mQEAgAA3CAAAAADkmQEA
gAA9CAAAAAAVmwEAgAA9CAAAAAA+mwEAgAA9CAAAAABpmwEAgABDCAAAAAB/nAEAgABDCAAA
AACgnAEAgABKCAAAAADanQEAgABKCAAAAAD9nQEAgABqCAAAAAB2oAEAgABqCAAAAACaoAEA
gAByCAAAAAC6oQEAgAByCAAAAADYoQEAgAB3CAAAAADpogEAgAB3CAAAAAARowEAgAB3CAAA
AAA6owEAgAB3CAAAAABkowEAgAB9CAAAAABgpAEAgAB9CAAAAACApAEAgAB9CAAAAACipAEA
gACGCAAAAADzpQEAgACGCAAAAAATpgEAgACPCAAAAACapwEAgACPCAAAAADApwEAgACVCAAA
AADZqAEAgACVCAAAAAD/qAEAgACjCAAAAADWrAEAgACjCAAAAAD5rAEAgACoCAAAAADRrQEA
gACoCAAAAADvrQEAgACuCAAAAADprgEAgACuCAAAAAAJrwEAgAC2CAAAAACFsAEAgAC2CAAA
AACrsAEAgAC9CAAAAADJsQEAgAC9CAAAAADtsQEAgADECAAAAAANswEAgADECAAAAAArswEA
gADNCAAAAACDtAEAgADNCAAAAACotAEAgADRCAAAAACUtQEAgADRCAAAAAC8tQEAgADYCAAA
AADStgEAgADYCAAAAADztgEAgADgCAAAAABbuAEAgADgCAAAAACCuAEAgADoCAAAAACmuQEA
gADoCAAAAADHuQEAgAD0CAAAAAB6uwEAgAD0CAAAAACbuwEAgAD0CAAAAAC+uwEAgAD7CAAA
AADzvAEAgAD7CAAAAAAYvQEAgAD7CAAAAAA+vQEAgAADCQAAAACBvgEAgAADCQAAAACjvgEA
gAADCQAAAADHvgEAgAAHCQAAAAC4vwEAgAAHCQAAAADZvwEAgAAHCQAAAAD8vwEAgAANCQAA
AAD7wAEAgAANCQAAAAAfwQEAgAAXCQAAAABSwgEAgAAXCQAAAABvwgEAgAAhCQAAAACkwwEA
gAAhCQAAAADDwwEAgAAhCQAAAADjwwEAgAAhCQAAAAAExAEAgAAmCQAAAAD0xAEAgAAmCQAA
AAATxQEAgAAtCQAAAAAixgEAgAAtCQAAAABBxgEAgAA2CQAAAACIxwEAgAA2CQAAAACmxwEA
gAA2CQAAAADGxwEAgABACQAAAABhygEAgABGCQAAAABzywEAgABGCQAAAACVywEAgABGCQAA
AAC5ywEAgABLCQAAAACWzAEAgABLCQAAAACzzAEAgABTCQAAAADOzQEAgABTCQAAAADszQEA
gABTCQAAAAALzgEAgABbCQAAAABEzwEAgABbCQAAAABlzwEAgABbCQAAAACIzwEAgABjCQAA
AACo0AEAgABjCQAAAADH0AEAgABvCQAAAADh0wEAgABvCQAAAAAH1AEAgAB2CQAAAABT1QEA
gAB2CQAAAAB71QEAgAB6CQAAAACC1gEAgAB6CQAAAACx1gEAgAB+CQAAAACd1wEAgAB+CQAA
AADE1wEAgAB+CQAAAADs1wEAgACJCQAAAADJ2gEAgACJCQAAAADr2gEAgACJCQAAAAAO2wEA
gACUCQAAAAB+3AEAgACUCQAAAACe3AEAgACUCQAAAADA3AEAgACkCQAAAAC53gEAgACkCQAA
AADZ3gEAgACoCQAAAADa3wEAgACoCQAAAAAI4AEAgACoCQAAAAA34AEAgACpCQAAAABn4AEA
gACwCQAAAABx4QEAgACwCQAAAACK4QEAgACwCQAAAACk4QEAgACyCQAAAADU4QEAgACyCQAA
AAAQ4gEAgAC8CQAAAAB64wEAgAC8CQAAAACj4wEAgAC8CQAAAADN4wEAgADWCQAAAADP5gEA
gADWCQAAAADv5gEAgADcCQAAAAD15wEAgADcCQAAAAAW6AEAgADcCQAAAAA56AEAgADhCQAA
AAAs6QEAgADhCQAAAABL6QEAgAD6CQAAAACv7wEAgAD6CQAAAADO7wEAgAD6CQAAAADu7wEA
gAD6CQAAAAAP8AEAgAAACgAAAAAz8QEAgAAACgAAAABY8QEAgAAECgAAAABk8gEAgAAECgAA
AACT8gEAgAAICgAAAACo8wEAgAAICgAAAADX8wEAgAAKCgAAAAD08wEAgAAKCgAAAAAV9AEA
gAAMCgAAAAAu9AEAgAAMCgAAAABT9AEAgAARCgAAAABb9QEAgAARCgAAAACE9QEAgAATCgAA
AADJ9QEAgAAUCgAAAAAE9gEAgAAdCgAAAAAt9wEAgAAdCgAAAABM9wEAgAApCgAAAAC3+AEA
gAApCgAAAADU+AEAgAAuCgAAAADA+QEAgAAuCgAAAADh+QEAgAA2CgAAAAAF+wEAgAA2CgAA
AAAm+wEAgAA8CgAAAAAl/AEAgAA8CgAAAABJ/AEAgABCCgAAAABG/QEAgABCCgAAAABm/QEA
gABJCgAAAABS/gEAgABJCgAAAABs/gEAgABVCgAAAADn/wEAgABVCgAAAAAMAAIAgABXCgAA
AAA+AAIAgABgCgAAAACmAQIAgABgCgAAAADNAQIAgABgCgAAAAD2AQIAgABqCgAAAACWAwIA
gABqCgAAAADEAwIAgABrCgAAAAD+AwIAgAB2CgAAAACcBQIAgAB2CgAAAAC+BQIAgAB2CgAA
AADiBQIAgAB8CgAAAAD+BwIAgACFCgAAAACSCgIAgACTCgAAAABaDAIAgACTCgAAAAB8DAIA
gACTCgAAAACgDAIAgACUCgAAAADQDAIAgACaCgAAAADiDgIAgACfCgAAAADYEAIAgACgCgAA
AAD3EAIAgACgCgAAAAAYEQIAgACnCgAAAAAnEgIAgACnCgAAAABJEgIAgACnCgAAAABsEgIA
gACnCgAAAACQEgIAgACxCgAAAAACFAIAgACxCgAAAAAiFAIAgAC3CgAAAAA3FQIAgAC3CgAA
AABXFQIAgAC3CgAAAAB5FQIAgAC/CgAAAAC4FgIAgAC/CgAAAADeFgIAgAC/CgAAAAAGFwIA
gADHCgAAAABTGAIAgADHCgAAAABzGAIAgADHCgAAAACVGAIAgADhCgAAAADuGwIAgADhCgAA
AAAQHAIAgADhCgAAAAAzHAIAgADhCgAAAABXHAIAgADzCgAAAAC1HgIAgADzCgAAAADYHgIA
gADzCgAAAAD8HgIAgADzCgAAAAAhHwIAgAAFCwAAAAAeIQIAgAAFCwAAAAA/IQIAgAAQCwAA
AAC+IgIAgAAQCwAAAADhIgIAgAAXCwAAAAD8IwIAgAAXCwAAAAAeJAIAgAAgCwAAAABbJQIA
gAAgCwAAAAB9JQIAgAAkCwAAAABWJgIAgAAkCwAAAAB6JgIAgAAqCwAAAACGJwIAgAAqCwAA
AACqJwIAgAA5CwAAAACFKQIAgAA5CwAAAACoKQIAgABECwAAAAAWKwIAgABECwAAAAA4KwIA
gABLCwAAAABmLAIAgABLCwAAAACLLAIAgABLCwAAAACxLAIAgABLCwAAAADYLAIAgABVCwAA
AAA7LgIAgABVCwAAAABaLgIAgABeCwAAAAB2LwIAgABeCwAAAACPLwIAgABeCwAAAACqLwIA
gABgCwAAAADhLwIAgABtCwAAAAB1MwIAgABtCwAAAACYMwIAgABtCwAAAAC8MwIAgAB0CwAA
AADENAIAgAB0CwAAAADjNAIAgAB6CwAAAADvNQIAgAB6CwAAAAARNgIAgACACwAAAAAnNwIA
gACACwAAAABINwIAgACSCwAAAACIOQIAgACSCwAAAAChOQIAgACXCwAAAAC1OgIAgACXCwAA
AADcOgIAgAClCwAAAAC/PAIAgAClCwAAAADiPAIAgACwCwAAAABjPgIAgACwCwAAAACEPgIA
gACwCwAAAACnPgIAgAC7CwAAAAA4QAIAgAC7CwAAAABYQAIAgADWCwAAAACyQwIAgADWCwAA
AADVQwIAgADcCwAAAADjRAIAgADcCwAAAAAIRQIAgADnCwAAAACCRgIAgADnCwAAAACjRgIA
gADpCwAAAADaRgIAgAD2CwAAAABmSAIAgAD2CwAAAACDSAIAgAD2CwAAAACiSAIAgAD+CwAA
AADSSQIAgAD+CwAAAADzSQIAgAD/CwAAAAAhSgIAgAAFDAAAAAAMSwIAgAAFDAAAAAAsSwIA
gAAXDAAAAACmTQIAgAAXDAAAAADMTQIAgAAXDAAAAAD0TQIAgAAgDAAAAABpTwIAgAAgDAAA
AACOTwIAgAAlDAAAAACuUAIAgAAlDAAAAADVUAIAgAAlDAAAAAD+UAIAgAAtDAAAAAD5UQIA
gAAtDAAAAAATUgIAgAAtDAAAAAAvUgIAgAAuDAAAAABKUgIAgAAuDAAAAAByUgIAgAA7DAAA
AABIVAIAgAA7DAAAAABqVAIAgABADAAAAABrVQIAgABADAAAAACQVQIAgABJDAAAAADkVgIA
gABJDAAAAAADVwIAgABSDAAAAABAWAIAgABSDAAAAABeWAIAgABSDAAAAAB+WAIAgABpDAAA
AABBWwIAgABpDAAAAABkWwIAgABpDAAAAACJWwIAgACADAAAAABPXgIAgACADAAAAAByXgIA
gACADAAAAACXXgIAgACFDAAAAAC5XgIAgACHDAAAAADoXgIAgACODAAAAADVXwIAgACODAAA
AADzXwIAgACODAAAAAATYAIAgACXDAAAAACKYQIAgACXDAAAAACtYQIAgACXDAAAAADRYQIA
gACXDAAAAAD2YQIAgACuDAAAAADYZAIAgACuDAAAAAD4ZAIAgACuDAAAAAAaZQIAgADRDAAA
AADGaQIAgADRDAAAAADtaQIAgADRDAAAAAAWagIAgADZDAAAAABCawIAgADZDAAAAABiawIA
gADZDAAAAACEawIAgADqDAAAAACsbQIAgADqDAAAAADObQIAgADqDAAAAADybQIAgADzDAAA
AAA/bwIAgADzDAAAAABgbwIAgADzDAAAAACDbwIAgAAADQAAAABLcQIAgAAADQAAAABrcQIA
gAAEDQAAAABZcgIAgAAEDQAAAACBcgIAgAARDQAAAACXdAIAgAARDQAAAADEdAIAgAAiDQAA
AAApdwIAgAAiDQAAAABOdwIAgAArDQAAAADoeAIAgAArDQAAAAAWeQIAgAA8DQAAAAB9ewIA
gAA8DQAAAACjewIAgABGDQAAAADQfAIAgABGDQAAAADufAIAgABKDQAAAAC7fQIAgABKDQAA
AADcfQIAgABSDQAAAAAUfwIAgABSDQAAAAA1fwIAgABWDQAAAAA2gAIAgABWDQAAAABhgAIA
gABsDQAAAADyggIAgABsDQAAAAAQgwIAgABsDQAAAAAwgwIAgAByDQAAAABKhAIAgAByDQAA
AABwhAIAgAByDQAAAACXhAIAgAByDQAAAAC/hAIAgAB5DQAAAADmhAIAgAB6DQAAAAAOhQIA
gAB7DQAAAAA3hQIAgACDDQAAAABXhgIAgACDDQAAAAB7hgIAgACDDQAAAACghgIAgACDDQAA
AADGhgIAgACbDQAAAACviQIAgACbDQAAAADTiQIAgACfDQAAAAC8igIAgACfDQAAAADgigIA
gAClDQAAAAD0iwIAgAClDQAAAAAYjAIAgACtDQAAAAB5jQIAgACtDQAAAACdjQIAgAC7DQAA
AACckgIAgAC7DQAAAADKkgIAgADCDQAAAAAPlAIAgADCDQAAAAA4lAIAgADLDQAAAAC7lQIA
gADLDQAAAADslQIAgADLDQAAAAAelgIAgADSDQAAAABZlwIAgADSDQAAAACFlwIAgADWDQAA
AAB6mAIAgADWDQAAAAClmAIAgADcDQAAAAC0mQIAgADcDQAAAADXmQIAgADcDQAAAAD7mQIA
gADcDQAAAAAgmgIAgADpDQAAAADxmwIAgADpDQAAAAAYnAIAgADpDQAAAABCnAIAgADwDQAA
AAB8nQIAgADwDQAAAAClnQIAgADwDQAAAADQnQIAgADyDQAAAAAKngIAgAAFDgAAAADhogIA
gAAFDgAAAAAEowIAgAAFDgAAAAApowIAgAAGDgAAAABaowIAgAAIDgAAAACRowIAgAAdDgAA
AAAhqgIAgAAdDgAAAABGqgIAgAAdDgAAAABtqgIAgAAeDgAAAACgqgIAgAAhDgAAAADdqgIA
gAAkDgAAAAAbqwIAgAAvDgAAAAC4rAIAgAAvDgAAAADbrAIAgAA1DgAAAADrrQIAgAA1DgAA
AAAQrgIAgAA6DgAAAADrrgIAgAA6DgAAAAAKrwIAgAA6DgAAAAArrwIAgAA/DgAAAAAVsAIA
gAA/DgAAAAA2sAIAgABLDgAAAAAasgIAgABLDgAAAABEsgIAgABLDgAAAABwsgIAgABRDgAA
AACxswIAgABRDgAAAADgswIAgABRDgAAAAARtAIAgABYDgAAAAAmtQIAgABYDgAAAABCtQIA
gABhDgAAAACetgIAgABhDgAAAAC7tgIAgABpDgAAAAADuAIAgABpDgAAAAAmuAIAgABwDgAA
AABWuQIAgABwDgAAAAB9uQIAgAB6DgAAAAAouwIAgAB6DgAAAABLuwIAgAB/DgAAAAA9vAIA
gAB/DgAAAABfvAIAgACFDgAAAABTvQIAgACFDgAAAABxvQIAgACLDgAAAAB/vgIAgACLDgAA
AACevgIAgACUDgAAAADvvwIAgACUDgAAAAAOwAIAgACaDgAAAAAcwQIAgACaDgAAAABDwQIA
gACaDgAAAABswQIAgACgDgAAAAB9wgIAgACgDgAAAACiwgIAgACmDgAAAADLwwIAgACmDgAA
AADxwwIAgAC7DgAAAADjxAIAgAC7DgAAAAAHxQIAgADADgAAAADixQIAgADADgAAAAABxgIA
gADIDgAAAAAxxwIAgADIDgAAAABUxwIAgADNDgAAAAAnyAIAgADNDgAAAABEyAIAgADNDgAA
AABjyAIAgADXDgAAAACtyQIAgADXDgAAAADNyQIAgADXDgAAAADvyQIAgADYDgAAAAAdygIA
gADeDgAAAABMywIAgADeDgAAAAB1ywIAgADeDgAAAACgywIAgADgDgAAAADIywIAgADgDgAA
AADxywIAgADmDgAAAADkzAIAgADmDgAAAAADzQIAgADvDgAAAABTzgIAgADvDgAAAABzzgIA
gADvDgAAAACVzgIAgAD0DgAAAACnzwIAgAD0DgAAAADQzwIAgAD0DgAAAAD7zwIAgAD8DgAA
AABh0QIAgAD8DgAAAACN0QIAgAACDwAAAADR0gIAgAACDwAAAAD80gIAgAALDwAAAABi1AIA
gAALDwAAAACG1AIAgAASDwAAAAC81QIAgAASDwAAAADg1QIAgAAWDwAAAADr1gIAgAAWDwAA
AAAa1wIAgAAZDwAAAAB21wIAgAAcDwAAAACT1wIAgAAkDwAAAADc2AIAgAAkDwAAAAD82AIA
gAAmDwAAAAAd2QIAgAAwDwAAAACr2gIAgAAwDwAAAADP2gIAgAAwDwAAAAD12gIAgAAzDwAA
AABD2wIAgAA2DwAAAABe2wIAgAA9DwAAAACA3AIAgAA9DwAAAACj3AIAgAA9DwAAAADI3AIA
gABCDwAAAADK3QIAgABCDwAAAADy3QIAgABEDwAAAAA23gIAgABFDwAAAABw3gIAgABJDwAA
AABW3wIAgABJDwAAAAB93wIAgABYDwAAAAC24QIAgABYDwAAAADX4QIAgABYDwAAAAD64QIA
gABtDwAAAAB75AIAgABtDwAAAACd5AIAgABtDwAAAADA5AIAgABtDwAAAADk5AIAgACCDwAA
AABo5wIAgACCDwAAAACK5wIAgACCDwAAAACt5wIAgACCDwAAAADR5wIAgACJDwAAAADy5wIA
gACKDwAAAAAU6AIAgACLDwAAAAA36AIAgACRDwAAAAAf6QIAgACRDwAAAAA/6QIAgACRDwAA
AABh6QIAgACbDwAAAAC/6wIAgACbDwAAAADb6wIAgACbDwAAAAD56wIAgACgDwAAAADn7AIA
gACgDwAAAAAF7QIAgACgDwAAAAAl7QIAgAClDwAAAAAU7gIAgAClDwAAAAA17gIAgAClDwAA
AABY7gIAgACrDwAAAABl7wIAgACrDwAAAACL7wIAgADDDwAAAADN9AIAgADDDwAAAADu9AIA
gADDDwAAAAAR9QIAgADMDwAAAACQ9gIAgADMDwAAAAC59gIAgADMDwAAAADk9gIAgADQDwAA
AACt9wIAgADQDwAAAADN9wIAgADeDwAAAAD7+QIAgADeDwAAAAAq+gIAgADnDwAAAADN+wIA
gADnDwAAAAD8+wIAgADuDwAAAAAu/QIAgADuDwAAAABV/QIAgADyDwAAAAAr/gIAgADyDwAA
AABN/gIAgAD6DwAAAAC6/wIAgAD6DwAAAADp/wIAgAD+DwAAAADzAAMAgAD+DwAAAAAiAQMA
gAAFEAAAAABWAgMAgAAFEAAAAAB9AgMAgAAKEAAAAABzAwMAgAAKEAAAAACZAwMAgAAPEAAA
AABsBQMAgAAPEAAAAACPBQMAgAAYEAAAAAC3BgMAgAAYEAAAAADVBgMAgAAYEAAAAAD0BgMA
gAAYEAAAAAAUBwMAgAAZEAAAAABABwMAgAAhEAAAAACeCQMAgAAhEAAAAAC+CQMAgAAnEAAA
AADQCwMAgAAsEAAAAAC9DAMAgAAsEAAAAADhDAMAgAA2EAAAAAArDgMAgAA2EAAAAABIDgMA
gAA/EAAAAACWDwMAgAA/EAAAAAC5DwMAgABFEAAAAACuEAMAgABFEAAAAADOEAMAgABKEAAA
AACsEQMAgABKEAAAAADLEQMAgABUEAAAAAB0EwMAgABUEAAAAACfEwMAgABUEAAAAADMEwMA
gABZEAAAAAC0FAMAgABZEAAAAADUFAMAgABeEAAAAADgFQMAgABeEAAAAAACFgMAgABlEAAA
AAA3FwMAgABlEAAAAABaFwMAgABpEAAAAABJGAMAgABpEAAAAABxGAMAgABuEAAAAABfGQMA
gABuEAAAAACBGQMAgABuEAAAAACkGQMAgABuEAAAAADIGQMAgAByEAAAAACXGgMAgAByEAAA
AAC4GgMAgAB2EAAAAACuGwMAgAB2EAAAAADXGwMAgAB7EAAAAADdHAMAgAB7EAAAAAADHQMA
gAB7EAAAAAAqHQMAgAB7EAAAAABSHQMAgACIEAAAAABHHwMAgACIEAAAAABtHwMAgACMEAAA
AAA3IAMAgACMEAAAAABXIAMAgACWEAAAAAAFIwMAgACWEAAAAAAkIwMAgACWEAAAAABEIwMA
gACeEAAAAACtJQMAgACeEAAAAADQJQMAgACjEAAAAAC6JgMAgACjEAAAAADZJgMAgACjEAAA
AAD6JgMAgACqEAAAAAA2KAMAgACqEAAAAABhKAMAgACwEAAAAABgKQMAgACwEAAAAACDKQMA
gACwEAAAAACmKQMAgAC2EAAAAAC7KgMAgAC2EAAAAADcKgMAgAC2EAAAAAD/KgMAgAC8EAAA
AAAHLAMAgAC8EAAAAAAsLAMAgAC8EAAAAABTLAMAgADBEAAAAAA3LQMAgADBEAAAAABYLQMA
gADHEAAAAABXLgMAgADHEAAAAAB7LgMAgADHEAAAAAChLgMAgADNEAAAAAC2LwMAgADNEAAA
AADbLwMAgADNEAAAAAACMAMAgADTEAAAAAD3MAMAgADTEAAAAAAXMQMAgADZEAAAAAARMgMA
gADZEAAAAAAwMgMAgADZEAAAAABRMgMAgADeEAAAAAAiNAMAgADjEAAAAAAUNQMAgADjEAAA
AAA4NQMAgADjEAAAAABdNQMAgADnEAAAAABUNgMAgADnEAAAAAB9NgMAgADtEAAAAACSNwMA
gADtEAAAAAC3NwMAgAD0EAAAAADIOAMAgAD0EAAAAADkOAMAgAD0EAAAAAABOQMAgAD5EAAA
AAAKOgMAgAD5EAAAAAAyOgMAgAAJEQAAAAB4PAMAgAAJEQAAAACePAMAgAAWEQAAAACcPgMA
gAAWEQAAAADCPgMAgAAWEQAAAADqPgMAgAAWEQAAAAARPwMAgAAjEQAAAAA4QQMAgAAjEQAA
AABeQQMAgAAjEQAAAACGQQMAgAAjEQAAAACtQQMAgAAoEQAAAADSQQMAgAAqEQAAAAAEQgMA
gAAqEQAAAAAqQgMAgAAzEQAAAAB+QwMAgAAzEQAAAACjQwMAgAA8EQAAAAAMRQMAgAA8EQAA
AAAxRQMAgABJEQAAAADcRgMAgABJEQAAAAD7RgMAgABJEQAAAAAcRwMAgABWEQAAAADHSAMA
gABWEQAAAADmSAMAgABWEQAAAAAHSQMAgABbEQAAAAAlSQMAgABdEQAAAABQSQMAgABsEQAA
AAAxSwMAgABsEQAAAABSSwMAgABsEQAAAAB1SwMAgAB7EQAAAABWTQMAgAB7EQAAAAB3TQMA
gAB7EQAAAACaTQMAgACAEQAAAAC6TQMAgACAEQAAAADnTQMAgACJEQAAAAAvTwMAgACJEQAA
AABVTwMAgACJEQAAAAB9TwMAgACREQAAAAC9UAMAgACREQAAAADgUAMAgACREQAAAAAFUQMA
gACcEQAAAACbUgMAgACcEQAAAAC+UgMAgACcEQAAAADjUgMAgACkEQAAAAA6VAMAgACkEQAA
AABkVAMAgACkEQAAAACQVAMAgACnEQAAAADIVAMAgACpEQAAAAD/VAMAgACrEQAAAAA0VQMA
gACtEQAAAABoVQMAgACvEQAAAACeVQMAgACyEQAAAADmVQMAgAC7EQAAAAC7VgMAgAC7EQAA
AADbVgMAgAC7EQAAAAD8VgMAgADEEQAAAABbWAMAgADEEQAAAACCWAMAgADEEQAAAACqWAMA
gADEEQAAAADTWAMAgADgEQAAAAAFXAMAgADgEQAAAAAvXAMAgADgEQAAAABaXAMAgADgEQAA
AACGXAMAgAD+EQAAAADzXwMAgAD+EQAAAAAeYAMAgAD+EQAAAABKYAMAgAD+EQAAAAB3YAMA
gAAaEgAAAAD4ZwMAgAAaEgAAAAAaaAMAgAAaEgAAAAA9aAMAgAAfEgAAAAD2aQMAgAAfEgAA
AAAYagMAgAAfEgAAAAA7agMAgABAEgAAAAAWcwMAgABAEgAAAAA4cwMAgABAEgAAAABbcwMA
gABIEgAAAADJdQMAgABIEgAAAADsdQMAgABNEgAAAACtdwMAgABNEgAAAADVdwMAgABNEgAA
AAD+dwMAgABmEgAAAACxegMAgABmEgAAAADXegMAgABmEgAAAAD+egMAgACIEgAAAADNfgMA
gACIEgAAAADzfgMAgACIEgAAAAAafwMAgAC/EgAAAABShQMAgAC/EgAAAAB4hQMAgAC/EgAA
AAAaBAAAogAAAAAAAACfhQMAggAAAAAAAADnhQMAggAAAM4VAAA1hgMAgABDAgAAAAByhgMA
gADeGgAAAAAaBAAAogAAAAAAAACfhgMAggAAAAAAAAAaBAAAogAAAAAAAADuhgMAggAAAAAA
AAAaBAAAogAAAAAAAAAaBAAAogAAAAAAAAA7hwMAggAAAAAAAAAaBAAAogAAAAAAAAAaBAAA
ogAAAAAAAACAhwMAgAAdAAAAAAC9hwMAggAAAApQDwDyhwMAggAAAAAAAAAaBAAAogAAAAAA
AAAwiAMAgAAJAQAAAACrlgMAgAAdAQAAAADYmQMAgAAqAQAAAAAbnAMAgAAyAQAAAAB3nQMA
gAA6AQAAAADJngMAgABNAQAAAABZoQMAgABxAQAAAADxpQMAgADJAQAAAACHrQMAgADoAQAA
AAB5sQMAgAAKAgAAAAAttgMAgAAtAgAAAADrugMAgAA4AgAAAAB1vAMAgABDAgAAAAB9vgMA
gABaAgAAAAA/wgMAgAB5AgAAAACKxAMAgACIAgAAAAAaBAAAogAAAAAAAACtxgMAggAAAIPb
AQDexgMAgAAQAAAAAAChxwMAgAAUAAAAAAADyAMAgAA0AAAAAABcygMAgABTAAAAAADeywMA
gAB6AAAAAAAaBAAAogAAAAAAAABEzgMAggAAACWXAQB9zgMAggAAAMeNAAC9zgMAgAC4AAAA
AADRzgMAgAC5AAAAAADozgMAgAC6AAAAAAD/zgMAgADFAAAAAAAw0AMAgADiAAAAAAAaBAAA
ogAAAAAAAAAT0QMAgABQAAAAAABo1gMAgABbAAAAAAAaBAAAogAAAAAAAADG1wMAggAAAJZZ
AAD71wMAgAAjAAAAAAAaBAAAogAAAAAAAABy2QMAggAAAAAAAAAaBAAAogAAAAAAAACk2QMA
ggAAAAAAAAAaBAAAogAAAAAAAADn2QMAggAAAFhsAAAb2gMAgAARAAAAAACI2gMAgAAhAAAA
AACw2wMAgAAhAAAAAAAaBAAAogAAAAAAAADF2wMAgACGAAAAAADk3wMAgACpAAAAAAAn4wMA
gAC9AAAAAAA+5AMAgAAIAQAAAABG5wMAgAAzAQAAAAAT6QMAgABMAQAAAAAp6gMAgABYAQAA
AACL6wMAgAB3AQAAAAAU7QMAgACOAQAAAACg7gMAgACmAQAAAACI8AMAgACvAQAAAADO8QMA
gAC7AQAAAABL8wMAggAAAMQKAgCO8wMAgAAUAAAAAABb9AMAgAAbAAAAAABp9QMAgAAnAAAA
AABK9gMAgAAzAAAAAAD+9gMAgAA6AAAAAAAV9wMAgAB4AAAAAACN+QMAgACzAAAAAAAaBAAA
ogAAAAAAAACS/AMAgACmAgAAAAA+/gMAgADEAgAAAABs/wMAgADRAgAAAAAaBAAAogAAAAAA
AABzAAQAggAAAAAAAACyAAQAggAAAGAKAAD2AAQAgAAMAAAAAAALAQQAgAANAAAAAAAaBAAA
ogAAAAAAAADmBQAAwgAAAAAAAAAaBAAAogAAAAAAAAAiAQQAggAAAAueAADmBQAAwgAAAAAA
AABiAQQAgAAZAAAAAADkAgQAgAAfAAAAAAAaBAAAogAAAAAAAAB2BAQAgAAPAAAAAACOBAQA
JAAjAFQdQAC3BAQAoAAjAAgAAAAaBAAARAAjAAAAAAAaBAAARAAqAAkAAAAaBAAARAAtABMA
AAAaBAAARAAuAB0AAAAaBAAARAAvACcAAAAaBAAARAAxADEAAAAaBAAARAAyADsAAAAaBAAA
RAAzAEUAAAAaBAAARAA0AE8AAAAaBAAARAA1AFkAAAAaBAAARAA2AF4AAAAaBAAARAA3AGgA
AAAaBAAARAA7AHEAAAAaBAAARAA8AHsAAAAaBAAARAA9AIUAAAAaBAAARAA+AI8AAAAaBAAA
RABBAJkAAAAaBAAARABEAKUAAAAaBAAARABFAK8AAAAaBAAARABGALkAAAAaBAAARABHAMMA
AAAaBAAARABIAM0AAADBBAQAQAAjAAAAAADLBAQAgAAmAPz///8aBAAAwAAAAAAAAAAaBAAA
4AAAAAAAAAAaBAAAJAAAANEAAADZBAQAJABNACgeQAC3BAQAoABNAAgAAAAaBAAARABNAAAA
AAAaBAAARABOAAYAAAAaBAAARABRAAwAAAAaBAAARABSABYAAADBBAQAQABNAAAAAAAaBAAA
wAAAAAAAAAAaBAAA4AAAAAAAAAAaBAAAJAAAABoAAADtBAQAJABXAEQeQAAGBQQAoABXAAgA
AAC3BAQAoABXAAwAAAAaBAAARABXAAAAAAAaBAAARABYAAoAAAAaBAAARABbABAAAAAaBAAA
RABcABsAAAARBQQAQABXAAMAAADBBAQAQABXAAAAAAAaBAAAwAAAAAAAAAAaBAAA4AAAAAAA
AAAaBAAAJAAAACIAAAAcBQQAJABhAGgeQAAGBQQAoABhAAgAAAC3BAQAoABhAAwAAAAaBAAA
RABhAAAAAAAaBAAARABiAAoAAAAaBAAARABlABAAAAAaBAAARABmABsAAAARBQQAQABhAAMA
AADBBAQAQABhAAAAAAAaBAAAwAAAAAAAAAAaBAAA4AAAAAAAAAAaBAAAJAAAACIAAAA/BQQA
IAAYAAAAAABSBQQAIAATAAAAAABhBQQAIAAZAAAAAABvBQQAKAAcAAAwQAAaBAAAZAAAAIoe
QACABQQAZAAAAGAfQACxBQQAZAAAAGAfQACyAAAAgAAAAAAAAADhAAAAgAAAAAAAAAD7AAAA
gAAAAAAAAAAvAQAAgAAAAAAAAABnAQAAgAAAAAAAAACkAQAAgAAAAAAAAADwAQAAgAAAAAAA
AAA8AgAAgAAAAAAAAABiAgAAgAAAAAAAAACMAgAAgAAAAAAAAACyAgAAgAAAAAAAAADXAgAA
gAAAAAAAAADxAgAAgAAAAAAAAAAMAwAAgAAAAAAAAAAtAwAAgAAAAAAAAABmAwAAgAAAAAAA
AACJAwAAgAAAAAAAAACtAwAAgAAAAAAAAADXAwAAgAAAAAAAAADiBQQAggAAAAAAAADsBQQA
ggAAAAAAAAApBgQAggAAAAAAAAAuBgQAggAAAAAAAABsBgQAggAAAAAAAAClBgQAggAAAEKf
AADfBgQAgAAAAAAAAACJBwQAgAAAAAAAAAD+BwQAgAAAAAAAAADECAQAgAAAAAAAAAAPCQQA
gAArBAAAAAAaBAAAogAAAAAAAAAsCQQAggAAAAAAAABlCQQAggAAAAAAAAAaBAAAogAAAAAA
AAAaBAAAogAAAAAAAAAaBAAAogAAAAAAAACfCQQAggAAAAAAAAAaBAAAogAAAAAAAAAaBAAA
ogAAAAAAAAAaBAAAogAAAAAAAAAaBAAAogAAAAAAAADXCQQAggAAAAAAAAAaBAAAogAAAAAA
AAAaBAAAogAAAAAAAAAYCgQAggAAAJWcAABKCgQAggAAAAAAAAAaBAAAogAAAAAAAAB9CgQA
ggAAAAAAAAAaBAAAogAAAAAAAACxCgQAgAAAAAAAAAAvDAQAgAAAAAAAAAAaBAAAogAAAAAA
AADBDAQAggAAAAAAAAAaBAAAogAAAAAAAADzDAQAggAAAP0UAAAEDQQAgAB2AAAAAAAcDQQA
gACqAAAAAAAxDQQAgAD/AAAAAABHDQQAgAAYAQAAAAAaBAAAogAAAAAAAABcDQQAgABUAAAA
AABzDQQAgABVAAAAAACIDQQAgABWAAAAAACeDQQAgABXAAAAAACzDQQAgABYAAAAAADJDQQA
gABaAAAAAADfDQQAgABbAAAAAAD1DQQAgABeAAAAAAALDgQAgABkAAAAAAAjDgQAgAAAAAAA
AABaDgQAgACHAAAAAACSDgQAggAAAEoIAADFDgQAgAA1AAAAAAAaBAAAogAAAAAAAADtDgQA
IABfCwAAAAAWDwQAIABgCwAAAAAaBAAAZAAAAGAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABjcnQwLmMAL2xvZ29wb2xpcy9tb25pdG9yL25vZXIvYjIw
L2J1aWxkL2k1ODYtY3lnd2luMzIteC1pNTg2LWN5Z3dpbjMyL2k1ODYtY3lnd2luMzIvbmV3
bGliL2xpYmMvc3lzL2N5Z3dpbjMyLwAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9k
ZXZvL25ld2xpYi9saWJjL3N5cy9jeWd3aW4zMi9jcnQwLmMAaW50OnQoMCwxKT1yKDAsMSk7
MDAyMDAwMDAwMDAwMDswMDE3Nzc3Nzc3Nzc3OwBjaGFyOnQoMCwyKT1yKDAsMik7MDsxMjc7
AGxvbmcgaW50OnQoMCwzKT1yKDAsMSk7MDAyMDAwMDAwMDAwMDswMDE3Nzc3Nzc3Nzc3OwB1
bnNpZ25lZCBpbnQ6dCgwLDQpPXIoMCwxKTswMDAwMDAwMDAwMDAwOzAwMzc3Nzc3Nzc3Nzc7
AGxvbmcgdW5zaWduZWQgaW50OnQoMCw1KT1yKDAsMSk7MDAwMDAwMDAwMDAwMDswMDM3Nzc3
Nzc3Nzc3OwBsb25nIGxvbmcgaW50OnQoMCw2KT1yKDAsMSk7MDEwMDAwMDAwMDAwMDAwMDAw
MDAwMDA7MDc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3NzsAbG9uZyBsb25nIHVuc2lnbmVkIGludDp0
KDAsNyk9cigwLDEpOzAwMDAwMDAwMDAwMDA7MDE3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc7AHNo
b3J0IGludDp0KDAsOCk9cigwLDgpOy0zMjc2ODszMjc2NzsAc2hvcnQgdW5zaWduZWQgaW50
OnQoMCw5KT1yKDAsOSk7MDs2NTUzNTsAc2lnbmVkIGNoYXI6dCgwLDEwKT1yKDAsMTApOy0x
Mjg7MTI3OwB1bnNpZ25lZCBjaGFyOnQoMCwxMSk9cigwLDExKTswOzI1NTsAZmxvYXQ6dCgw
LDEyKT1yKDAsMSk7NDswOwBkb3VibGU6dCgwLDEzKT1yKDAsMSk7ODswOwBsb25nIGRvdWJs
ZTp0KDAsMTQpPXIoMCwxKTsxMjswOwBjb21wbGV4IGludDp0KDAsMTUpPXM4cmVhbDooMCwx
KSwwLDMyO2ltYWc6KDAsMSksMzIsMzI7OwBjb21wbGV4IGZsb2F0OnQoMCwxNik9cigwLDE2
KTs0OzA7AGNvbXBsZXggZG91YmxlOnQoMCwxNyk9cigwLDE3KTs4OzA7AGNvbXBsZXggbG9u
ZyBkb3VibGU6dCgwLDE4KT1yKDAsMTgpOzEyOzA7AHZvaWQ6dCgwLDE5KT0oMCwxOSkAX19j
eWd3aW5fY3J0MF9icDpHKDAsMSkAbWFpbkNSVFN0YXJ0dXA6RigwLDE5KQAAY3c6KDAsOSkA
L2xvZ29wb2xpcy9tb25pdG9yL25vZXIvYjIwL2J1aWxkL2k1ODYtY3lnd2luMzIteC1pNTg2
LWN5Z3dpbjMyL2k1ODYtY3lnd2luMzIvd2luc3VwLwAvaG9tZS9ub2VyL3NyYy9iMjAvY29t
cC10b29scy9kZXZvL3dpbnN1cC9saWJjY3J0MC5jYwBib29sOnQoMCwxOSk9QHM4Oy0xNjsA
dm9pZDp0KDAsMjApPSgwLDIwKQBfX3djaGFyX3Q6dCgwLDIxKT1yKDAsMjEpOzA7NjU1MzU7
AF9fdnRibF9wdHJfdHlwZTp0KDAsMjIpPXM4X19kZWx0YTooMCw4KSwwLDE2O19faW5kZXg6
KDAsOCksMTYsMTY7X19wZm46KDAsMjMpPSooMCwyMCksMzIsMzI7X19kZWx0YTI6KDAsOCks
MzIsMTY7OwAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL3dpbnN1cC93aW5z
dXAuaAAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL25ld2xpYi9saWJjL2lu
Y2x1ZGUvc3lzL3R5cGVzLmgAL2xvZ29wb2xpcy9tb25pdG9yL25vZXIvYjIwL2luc3RhbGwv
SC1pNTg2LXBjLWxpbnV4LWdudWxpYmMxL2Jpbi8uLi9saWIvZ2NjLWxpYi9pNTg2LWN5Z3dp
bjMyL2VnY3MtMi45MS41Ny9pbmNsdWRlL3N0ZGRlZi5oAHB0cmRpZmZfdDp0KDMsMSk9KDAs
MSkAc2l6ZV90OnQoMywyKT0oMCw0KQB3aW50X3Q6dCgzLDMpPSgwLDQpAC9ob21lL25vZXIv
c3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vbmV3bGliL2xpYmMvaW5jbHVkZS9tYWNoaW5lL3R5
cGVzLmgAdV9jaGFyOnQoMiwxKT0oMCwxMSkAdV9zaG9ydDp0KDIsMik9KDAsOSkAdV9pbnQ6
dCgyLDMpPSgwLDQpAHVfbG9uZzp0KDIsNCk9KDAsNSkAdXNob3J0OnQoMiw1KT0oMCw5KQB1
aW50OnQoMiw2KT0oMCw0KQB0aW1lX3Q6dCgyLDcpPSgwLDMpAGRhZGRyX3Q6dCgyLDgpPSgw
LDMpAGNhZGRyX3Q6dCgyLDkpPSgyLDEwKT0qKDAsMikAaW5vX3Q6dCgyLDExKT0oMCw1KQB2
bV9vZmZzZXRfdDp0KDIsMTIpPSgwLDUpAHZtX3NpemVfdDp0KDIsMTMpPSgwLDUpAGludDhf
dDp0KDIsMTQpPSgwLDIpAHVfaW50OF90OnQoMiwxNSk9KDAsMTEpAGludDE2X3Q6dCgyLDE2
KT0oMCw4KQB1X2ludDE2X3Q6dCgyLDE3KT0oMCw5KQBpbnQzMl90OnQoMiwxOCk9KDAsMSkA
dV9pbnQzMl90OnQoMiwxOSk9KDAsNCkAaW50NjRfdDp0KDIsMjApPSgwLDYpAHVfaW50NjRf
dDp0KDIsMjEpPSgwLDcpAHJlZ2lzdGVyX3Q6dCgyLDIyKT0oMiwxOCkAZGV2X3Q6dCgyLDIz
KT0oMCw4KQBvZmZfdDp0KDIsMjQpPSgwLDMpAHVpZF90OnQoMiwyNSk9KDAsOSkAZ2lkX3Q6
dCgyLDI2KT0oMCw5KQBwaWRfdDp0KDIsMjcpPSgwLDEpAGtleV90OnQoMiwyOCk9KDAsMykA
c3NpemVfdDp0KDIsMjkpPSgwLDMpAGFkZHJfdDp0KDIsMzApPSgyLDEwKQBtb2RlX3Q6dCgy
LDMxKT0oMCwxKQBubGlua190OnQoMiwzMik9KDAsOSkAZmRfbWFzazp0KDIsMzMpPSgwLDMp
AF90eXBlc19mZF9zZXQ6VCgyLDM0KT1zOGZkc19iaXRzOigyLDM1KT1hcigwLDEpOzA7MTso
MCwzKSwwLDY0O19fYXM6OigyLDM2KT0jIygyLDM3KT0mKDIsMzQpOzpSQzEzX3R5cGVzX2Zk
X3NldDsyQS47X3R5cGVzX2ZkX3NldDo6KDIsMzgpPSMjKDIsMzkpPSooMiwzNCk7OlJDMTNf
dHlwZXNfZmRfc2V0OzJBLigyLDQwKT0jIygyLDM5KTs6OzJBLjs7AF90eXBlc19mZF9zZXQ6
VHQoMiwzNCkAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvaW5j
bHVkZS9zeXMvc3RyYWNlLmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93
aW5zdXAvaW5jbHVkZS9zeXMvcmVzb3VyY2UuaAAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10
b29scy9kZXZvL25ld2xpYi9saWJjL2luY2x1ZGUvc3lzL3RpbWUuaAAvaG9tZS9ub2VyL3Ny
Yy9iMjAvY29tcC10b29scy9kZXZvL25ld2xpYi9saWJjL2luY2x1ZGUvX2Fuc2kuaAAvaG9t
ZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL25ld2xpYi9saWJjL2luY2x1ZGUvc3lz
L2NvbmZpZy5oAF9faW50MzJfdDp0KDksMSk9KDAsMSkAX191aW50MzJfdDp0KDksMik9KDAs
NCkAdGltZXZhbDpUdCg3LDEpPXM4dHZfc2VjOigwLDMpLDAsMzI7dHZfdXNlYzooMCwzKSwz
MiwzMjtfX2FzOjooNywyKT0jIyg3LDMpPSYoNywxKTs6UkM3dGltZXZhbDsyQS47dGltZXZh
bDo6KDcsNCk9IyMoNyw1KT0qKDcsMSk7OlJDN3RpbWV2YWw7MkEuKDcsNik9IyMoNyw1KTs6
OzJBLjs7AHRpbWV6b25lOlR0KDcsNyk9czh0el9taW51dGVzd2VzdDooMCwxKSwwLDMyO3R6
X2RzdHRpbWU6KDAsMSksMzIsMzI7X19hczo6KDcsOCk9IyMoNyw5KT0mKDcsNyk7OlJDOHRp
bWV6b25lOzJBLjt0aW1lem9uZTo6KDcsMTApPSMjKDcsMTEpPSooNyw3KTs6UkM4dGltZXpv
bmU7MkEuKDcsMTIpPSMjKDcsMTEpOzo7MkEuOzsAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAt
dG9vbHMvZGV2by93aW5zdXAvaW5jbHVkZS9zeXMvc2VsZWN0LmgAL2hvbWUvbm9lci9zcmMv
YjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvaW5jbHVkZS9zeXMvY2RlZnMuaAAvaG9tZS9u
b2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL25ld2xpYi9saWJjL2luY2x1ZGUvdGltZS5o
AC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vbmV3bGliL2xpYmMvaW5jbHVk
ZS9tYWNoaW5lL3RpbWUuaABjbG9ja190OnQoMTMsMSk9KDAsNSkAdG06VHQoMTMsMik9czM2
dG1fc2VjOigwLDEpLDAsMzI7dG1fbWluOigwLDEpLDMyLDMyO3RtX2hvdXI6KDAsMSksNjQs
MzI7dG1fbWRheTooMCwxKSw5NiwzMjt0bV9tb246KDAsMSksMTI4LDMyO3RtX3llYXI6KDAs
MSksMTYwLDMyO3RtX3dkYXk6KDAsMSksMTkyLDMyO3RtX3lkYXk6KDAsMSksMjI0LDMyO3Rt
X2lzZHN0OigwLDEpLDI1NiwzMjtfX2FzOjooMTMsMyk9IyMoMTMsNCk9JigxMywyKTs6UkMy
dG07MkEuO3RtOjooMTMsNSk9IyMoMTMsNik9KigxMywyKTs6UkMydG07MkEuKDEzLDcpPSMj
KDEzLDYpOzo7MkEuOzsAaXRpbWVydmFsOlR0KDcsMTMpPXMxNml0X2ludGVydmFsOig3LDEp
LDAsNjQ7aXRfdmFsdWU6KDcsMSksNjQsNjQ7X19hczo6KDcsMTQpPSMjKDcsMTUpPSYoNywx
Myk7OlJDOWl0aW1lcnZhbDsyQS47aXRpbWVydmFsOjooNywxNik9IyMoNywxNyk9Kig3LDEz
KTs6UkM5aXRpbWVydmFsOzJBLig3LDE4KT0jIyg3LDE3KTs6OzJBLjs7AHJ1c2FnZTpUdCg2
LDEpPXM3MnJ1X3V0aW1lOig3LDEpLDAsNjQ7cnVfc3RpbWU6KDcsMSksNjQsNjQ7cnVfbWF4
cnNzOigwLDMpLDEyOCwzMjtydV9peHJzczooMCwzKSwxNjAsMzI7cnVfaWRyc3M6KDAsMyks
MTkyLDMyO3J1X2lzcnNzOigwLDMpLDIyNCwzMjtydV9taW5mbHQ6KDAsMyksMjU2LDMyO3J1
X21hamZsdDooMCwzKSwyODgsMzI7cnVfbnN3YXA6KDAsMyksMzIwLDMyO3J1X2luYmxvY2s6
KDAsMyksMzUyLDMyO3J1X291YmxvY2s6KDAsMyksMzg0LDMyO3J1X21zZ3NuZDooMCwzKSw0
MTYsMzI7cnVfbXNncmN2OigwLDMpLDQ0OCwzMjtydV9uc2lnbmFsczooMCwzKSw0ODAsMzI7
cnVfbnZjc3c6KDAsMyksNTEyLDMyO3J1X25pdmNzdzooMCwzKSw1NDQsMzI7X19hczo6KDYs
Mik9IyMoNiwzKT0mKDYsMSk7OlJDNnJ1c2FnZTsyQS47cnVzYWdlOjooNiw0KT0jIyg2LDUp
PSooNiwxKTs6UkM2cnVzYWdlOzJBLig2LDYpPSMjKDYsNSk7OjsyQS47OwAvaG9tZS9ub2Vy
L3NyYy9iMjAvY29tcC10b29scy9kZXZvL25ld2xpYi9saWJjL2luY2x1ZGUvc2V0am1wLmgA
L2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by9uZXdsaWIvbGliYy9pbmNsdWRl
L21hY2hpbmUvc2V0am1wLmgAam1wX2J1Zjp0KDE3LDEpPSgxNywyKT1hcigwLDEpOzA7NTE7
KDAsMSkAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by9uZXdsaWIvbGliYy9p
bmNsdWRlL3NpZ25hbC5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vbmV3
bGliL2xpYmMvaW5jbHVkZS9zeXMvc2lnbmFsLmgAc2lnc2V0X3Q6dCgxOSwxKT0oMCw1KQBz
aWdhY3Rpb246VHQoMTksMik9czEyc2FfaGFuZGxlcjooMTksMyk9KigxOSw0KT1mKDAsMjAp
LDAsMzI7c2FfbWFzazooMTksMSksMzIsMzI7c2FfZmxhZ3M6KDAsMSksNjQsMzI7X19hczo6
KDE5LDUpPSMjKDE5LDYpPSYoMTksMik7OlJDOXNpZ2FjdGlvbjsyQS47c2lnYWN0aW9uOjoo
MTksNyk9IyMoMTksOCk9KigxOSwyKTs6UkM5c2lnYWN0aW9uOzJBLigxOSw5KT0jIygxOSw4
KTs6OzJBLjs7AHNpZ19hdG9taWNfdDp0KDE4LDEpPSgwLDEpAF9zaWdfZnVuY19wdHI6dCgx
OCwyKT0oMTksMykAc2lnam1wX2J1Zjp0KDE3LDMpPSgxNyw0KT1hcigwLDEpOzA7NTM7KDAs
MSkAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by9uZXdsaWIvbGliYy9pbmNs
dWRlL3N0cmluZy5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vd2luc3Vw
L2luY2x1ZGUvd2luZG93cy5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8v
d2luc3VwL2luY2x1ZGUvbGltaXRzLmgAL2xvZ29wb2xpcy9tb25pdG9yL25vZXIvYjIwL2lu
c3RhbGwvSC1pNTg2LXBjLWxpbnV4LWdudWxpYmMxL2Jpbi8uLi9saWIvZ2NjLWxpYi9pNTg2
LWN5Z3dpbjMyL2VnY3MtMi45MS41Ny9pbmNsdWRlL3N0ZGFyZy5oAF9fZ251Y192YV9saXN0
OnQoMjQsMSk9KDAsMjMpAHZhX2xpc3Q6dCgyNCwyKT0oMjQsMSkAL2hvbWUvbm9lci9zcmMv
YjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvaW5jbHVkZS9XaW5kb3dzMzIvQmFzZS5oAEFU
T006dCgyNSwxKT0oMCw5KQBXSU5CT09MOnQoMjUsMik9KDAsMSkAQk9PTDp0KDI1LDMpPSgy
NSwyKQBCT09MRUFOOnQoMjUsNCk9KDAsMTEpAEJZVEU6dCgyNSw1KT0oMCwxMSkAQ0FMVFlQ
RTp0KDI1LDYpPSgwLDUpAENBTElEOnQoMjUsNyk9KDAsNSkAQ0NIQVI6dCgyNSw4KT0oMCwy
KQBDT0xPUlJFRjp0KDI1LDkpPSgwLDUpAFdDSEFSOnQoMjUsMTApPSgwLDIxKQBDSEFSOnQo
MjUsMTEpPSgwLDIpAFNIT1JUOnQoMjUsMTIpPSgwLDgpAExPTkc6dCgyNSwxMyk9KDAsMykA
RFdPUkQ6dCgyNSwxNCk9KDAsNCkARFdPUkRMT05HOnQoMjUsMTUpPSgwLDEzKQBQRFdPUkRM
T05HOnQoMjUsMTYpPSgyNSwxNyk9KigwLDEzKQBGTE9BVDp0KDI1LDE4KT0oMCwxMikASEFO
RExFOnQoMjUsMTkpPSgwLDIzKQBIQUNDRUw6dCgyNSwyMCk9KDI1LDE5KQBIQklUTUFQOnQo
MjUsMjEpPSgyNSwxOSkASEJSVVNIOnQoMjUsMjIpPSgyNSwxOSkASENPTE9SU1BBQ0U6dCgy
NSwyMyk9KDI1LDE5KQBIQ09OVjp0KDI1LDI0KT0oMjUsMTkpAEhDT05WTElTVDp0KDI1LDI1
KT0oMjUsMTkpAEhDVVJTT1I6dCgyNSwyNik9KDI1LDE5KQBIREJDOnQoMjUsMjcpPSgyNSwx
OSkASERDOnQoMjUsMjgpPSgyNSwxOSkASERERURBVEE6dCgyNSwyOSk9KDI1LDE5KQBIREVT
Szp0KDI1LDMwKT0oMjUsMTkpAEhEUk9QOnQoMjUsMzEpPSgyNSwxOSkASERXUDp0KDI1LDMy
KT0oMjUsMTkpAEhFTkhNRVRBRklMRTp0KDI1LDMzKT0oMjUsMTkpAEhFTlY6dCgyNSwzNCk9
KDI1LDE5KQBIRklMRTp0KDI1LDM1KT0oMCwxKQBIRk9OVDp0KDI1LDM2KT0oMjUsMTkpAEhH
RElPQko6dCgyNSwzNyk9KDI1LDE5KQBIR0xPQkFMOnQoMjUsMzgpPSgyNSwxOSkASEdMUkM6
dCgyNSwzOSk9KDI1LDE5KQBISE9PSzp0KDI1LDQwKT0oMjUsMTkpAEhJQ09OOnQoMjUsNDEp
PSgyNSwxOSkASElNQUdFTElTVDp0KDI1LDQyKT0oMjUsMTkpAEhJTlNUQU5DRTp0KDI1LDQz
KT0oMjUsMTkpAEhLRVk6dCgyNSw0NCk9KDI1LDE5KQBQSEtFWTp0KDI1LDQ1KT0oMjUsNDYp
PSooMjUsMTkpAEhLTDp0KDI1LDQ3KT0oMjUsMTkpAEhMT0NBTDp0KDI1LDQ4KT0oMjUsMTkp
AEhNRU5VOnQoMjUsNDkpPSgyNSwxOSkASE1FVEFGSUxFOnQoMjUsNTApPSgyNSwxOSkASE1P
RFVMRTp0KDI1LDUxKT0oMjUsMTkpAEhQQUxFVFRFOnQoMjUsNTIpPSgyNSwxOSkASFBFTjp0
KDI1LDUzKT0oMjUsMTkpAEhSQVNDT05OOnQoMjUsNTQpPSgyNSwxOSkASFJFU1VMVDp0KDI1
LDU1KT0oMCwzKQBIUkdOOnQoMjUsNTYpPSgyNSwxOSkASFJTUkM6dCgyNSw1Nyk9KDI1LDE5
KQBIU1RNVDp0KDI1LDU4KT0oMjUsMTkpAEhTWjp0KDI1LDU5KT0oMjUsMTkpAEhXSU5TVEE6
dCgyNSw2MCk9KDI1LDE5KQBIV05EOnQoMjUsNjEpPSgyNSwxOSkASU5UOnQoMjUsNjIpPSgw
LDEpAExBTkdJRDp0KDI1LDYzKT0oMCw5KQBMQ0lEOnQoMjUsNjQpPSgyNSwxNCkATENUWVBF
OnQoMjUsNjUpPSgyNSwxNCkATE9OR0xPTkc6dCgyNSw2Nik9KDAsMTMpAFBMT05HTE9ORzp0
KDI1LDY3KT0oMjUsMTcpAExQOnQoMjUsNjgpPSgyNSw2OSk9KigwLDkpAExQQVJBTTp0KDI1
LDcwKT0oMCwzKQBMUEJPT0w6dCgyNSw3MSk9KDI1LDcyKT0qKDI1LDIpAExQQllURTp0KDI1
LDczKT0oMjUsNzQpPSooMjUsNSkATFBDQ0g6dCgyNSw3NSk9KDI1LDc2KT0qKDI1LDExKQBM
UENIOnQoMjUsNzcpPSgyNSw3OCk9KigyNSwxMSkATFBDT0xPUlJFRjp0KDI1LDc5KT0oMjUs
ODApPSooMjUsOSkATFBDU1RSOnQoMjUsODEpPSgyNSw4Mik9KigwLDIpAExQQ1RTVFI6dCgy
NSw4Myk9KDI1LDgyKQBMUENXQ0g6dCgyNSw4NCk9KDI1LDg1KT0qKDI1LDEwKQBMUENXU1RS
OnQoMjUsODYpPSgyNSw4NSkATFBEV09SRDp0KDI1LDg3KT0oMjUsODgpPSooMjUsMTQpAExQ
SEFORExFOnQoMjUsODkpPSgyNSw0NikATFBJTlQ6dCgyNSw5MCk9KDI1LDkxKT0qKDAsMSkA
TFBMT05HOnQoMjUsOTIpPSgyNSw5Myk9KigwLDMpAExQU1RSOnQoMjUsOTQpPSgyLDEwKQBM
UFRDSDp0KDI1LDk1KT0oMiwxMCkATFBUU1RSOnQoMjUsOTYpPSgyLDEwKQBMUkVTVUxUOnQo
MjUsOTcpPSgwLDMpAExQVk9JRDp0KDI1LDk4KT0oMCwyMykATFBDVk9JRDp0KDI1LDk5KT0o
MjUsMTAwKT0qKDAsMjApAExQV0NIOnQoMjUsMTAxKT0oMjUsMTAyKT0qKDI1LDEwKQBMUFdP
UkQ6dCgyNSwxMDMpPSgyNSw2OSkATFBXU1RSOnQoMjUsMTA0KT0oMjUsMTAyKQBOV1BTVFI6
dCgyNSwxMDUpPSgyNSw2OSkAUFdJTkJPT0w6dCgyNSwxMDYpPSgyNSw3MikAUEJPT0xFQU46
dCgyNSwxMDcpPSgyNSw3NCkAUEJZVEU6dCgyNSwxMDgpPSgyNSw3NCkAUENDSDp0KDI1LDEw
OSk9KDI1LDc2KQBQQ0g6dCgyNSwxMTApPSgyNSw3OCkAUENIQVI6dCgyNSwxMTEpPSgyNSw3
OCkAUENTVFI6dCgyNSwxMTIpPSgyNSw4MikAUENXQ0g6dCgyNSwxMTMpPSgyNSw4NSkAUENX
U1RSOnQoMjUsMTE0KT0oMjUsODUpAFBEV09SRDp0KDI1LDExNSk9KDI1LDg4KQBQRkxPQVQ6
dCgyNSwxMTYpPSgyNSwxMTcpPSooMCwxMikAUEhBTkRMRTp0KDI1LDExOCk9KDI1LDQ2KQBQ
SU5UOnQoMjUsMTE5KT0oMjUsOTEpAFBMT05HOnQoMjUsMTIwKT0oMjUsOTMpAFBTSE9SVDp0
KDI1LDEyMSk9KDI1LDEyMik9KigwLDgpAFBTVFI6dCgyNSwxMjMpPSgyLDEwKQBQU1o6dCgy
NSwxMjQpPSgyLDEwKQBQVEJZVEU6dCgyNSwxMjUpPSgyNSwxMjYpPSooMCwxMSkAUFRDSDp0
KDI1LDEyNyk9KDIsMTApAFBUQ0hBUjp0KDI1LDEyOCk9KDIsMTApAFBUU1RSOnQoMjUsMTI5
KT0oMiwxMCkAUFVDSEFSOnQoMjUsMTMwKT0oMjUsMTI2KQBQVUlOVDp0KDI1LDEzMSk9KDI1
LDEzMik9KigwLDQpAFBVTE9ORzp0KDI1LDEzMyk9KDI1LDEzNCk9KigwLDUpAFBVU0hPUlQ6
dCgyNSwxMzUpPSgyNSw2OSkAUFZPSUQ6dCgyNSwxMzYpPSgwLDIzKQBQV0NIOnQoMjUsMTM3
KT0oMjUsMTAyKQBQV0NIQVI6dCgyNSwxMzgpPSgyNSwxMDIpAFBXT1JEOnQoMjUsMTM5KT0o
MjUsNjkpAFJFVENPREU6dCgyNSwxNDApPSgwLDgpAFNDX0hBTkRMRTp0KDI1LDE0MSk9KDI1
LDE5KQBTQ19MT0NLOnQoMjUsMTQyKT0oMjUsOTgpAExQU0NfSEFORExFOnQoMjUsMTQzKT0o
MjUsMTQ0KT0qKDI1LDE0MSkAU0VSVklDRV9TVEFUVVNfSEFORExFOnQoMjUsMTQ1KT0oMjUs
MTQpAFRCWVRFOnQoMjUsMTQ2KT0oMCwxMSkAVENIQVI6dCgyNSwxNDcpPSgwLDIpAEJDSEFS
OnQoMjUsMTQ4KT0oMjUsNSkAVUNIQVI6dCgyNSwxNDkpPSgwLDExKQBVSU5UOnQoMjUsMTUw
KT0oMCw0KQBVTE9ORzp0KDI1LDE1MSk9KDAsNSkAVVNIT1JUOnQoMjUsMTUyKT0oMCw5KQBX
T1JEOnQoMjUsMTUzKT0oMCw5KQBXUEFSQU06dCgyNSwxNTQpPSgwLDQpAF9BQ0xfSU5GT1JN
QVRJT05fQ0xBU1M6dCgyNSwxNTUpPWVBY2xSZXZpc2lvbkluZm9ybWF0aW9uOjEsQWNsU2l6
ZUluZm9ybWF0aW9uOjIsOwBBQ0xfSU5GT1JNQVRJT05fQ0xBU1M6dCgyNSwxNTYpPSgyNSwx
NTUpAF9NRURJQV9UWVBFOnQoMjUsMTU3KT1lVW5rbm93bjowLEY1XzFQdDJfNTEyOjEsRjNf
MVB0NDRfNTEyOjIsRjNfMlB0ODhfNTEyOjMsRjNfMjBQdDhfNTEyOjQsRjNfNzIwXzUxMjo1
LEY1XzM2MF81MTI6NixGNV8zMjBfNTEyOjcsRjVfMzIwXzEwMjQ6OCxGNV8xODBfNTEyOjks
RjVfMTYwXzUxMjoxMCxSZW1vdmFibGVNZWRpYToxMSxGaXhlZE1lZGlhOjEyLDsATUVESUFf
VFlQRTp0KDI1LDE1OCk9KDI1LDE1NykAX1JBU0NPTk5TVEFURTp0KDI1LDE1OSk9ZVJBU0NT
X09wZW5Qb3J0OjAsUkFTQ1NfUG9ydE9wZW5lZDoxLFJBU0NTX0Nvbm5lY3REZXZpY2U6MixS
QVNDU19EZXZpY2VDb25uZWN0ZWQ6MyxSQVNDU19BbGxEZXZpY2VzQ29ubmVjdGVkOjQsUkFT
Q1NfQXV0aGVudGljYXRlOjUsUkFTQ1NfQXV0aE5vdGlmeTo2LFJBU0NTX0F1dGhSZXRyeTo3
LFJBU0NTX0F1dGhDYWxsYmFjazo4LFJBU0NTX0F1dGhDaGFuZ2VQYXNzd29yZDo5LFJBU0NT
X0F1dGhQcm9qZWN0OjEwLFJBU0NTX0F1dGhMaW5rU3BlZWQ6MTEsUkFTQ1NfQXV0aEFjazox
MixSQVNDU19SZUF1dGhlbnRpY2F0ZToxMyxSQVNDU19BdXRoZW50aWNhdGVkOjE0LFJBU0NT
X1ByZXBhcmVGb3JDYWxsYmFjazoxNSxSQVNDU19XYWl0Rm9yTW9kZW1SZXNldDoxNixSQVND
U19XYWl0Rm9yQ2FsbGJhY2s6MTcsUkFTQ1NfUHJvamVjdGVkOjE4LFJBU0NTX1N0YXJ0QXV0
aGVudGljYXRpb246MTksUkFTQ1NfQ2FsbGJhY2tDb21wbGV0ZToyMCxSQVNDU19Mb2dvbk5l
dHdvcms6MjEsUkFTQ1NfSW50ZXJhY3RpdmU6NDA5NixSQVNDU19SZXRyeUF1dGhlbnRpY2F0
aW9uOjQwOTcsUkFTQ1NfQ2FsbGJhY2tTZXRCeUNhbGxlcjo0MDk4LFJBU0NTX1Bhc3N3b3Jk
RXhwaXJlZDo0MDk5LFJBU0NTX0Nvbm5lY3RlZDo4MTkyLFJBU0NTX0Rpc2Nvbm5lY3RlZDo4
MTkzLDsAUkFTQ09OTlNUQVRFOnQoMjUsMTYwKT0oMjUsMTU5KQBfUkFTUFJPSkVDVElPTjp0
KDI1LDE2MSk9ZVJBU1BfQW1iOjY1NTM2LFJBU1BfUHBwTmJmOjMyODMxLFJBU1BfUHBwSXB4
OjMyODExLFJBU1BfUHBwSXA6MzI4MDEsOwBSQVNQUk9KRUNUSU9OOnQoMjUsMTYyKT0oMjUs
MTYxKQBfU0VDVVJJVFlfSU1QRVJTT05BVElPTl9MRVZFTDp0KDI1LDE2Myk9ZVNlY3VyaXR5
QW5vbnltb3VzOjAsU2VjdXJpdHlJZGVudGlmaWNhdGlvbjoxLFNlY3VyaXR5SW1wZXJzb25h
dGlvbjoyLFNlY3VyaXR5RGVsZWdhdGlvbjozLDsAU0VDVVJJVFlfSU1QRVJTT05BVElPTl9M
RVZFTDp0KDI1LDE2NCk9KDI1LDE2MykAX1NJRF9OQU1FX1VTRTp0KDI1LDE2NSk9ZVNpZFR5
cGVVc2VyOjEsU2lkVHlwZUdyb3VwOjIsU2lkVHlwZURvbWFpbjozLFNpZFR5cGVBbGlhczo0
LFNpZFR5cGVXZWxsS25vd25Hcm91cDo1LFNpZFR5cGVEZWxldGVkQWNjb3VudDo2LFNpZFR5
cGVJbnZhbGlkOjcsU2lkVHlwZVVua25vd246OCw7AFNJRF9OQU1FX1VTRTp0KDI1LDE2Nik9
KDI1LDE2NSkAUFNJRF9OQU1FX1VTRTp0KDI1LDE2Nyk9KDI1LDE2OCk9KigyNSwxNjUpAF9U
T0tFTl9JTkZPUk1BVElPTl9DTEFTUzp0KDI1LDE2OSk9ZVRva2VuVXNlcjoxLFRva2VuR3Jv
dXBzOjIsVG9rZW5Qcml2aWxlZ2VzOjMsVG9rZW5Pd25lcjo0LFRva2VuUHJpbWFyeUdyb3Vw
OjUsVG9rZW5EZWZhdWx0RGFjbDo2LFRva2VuU291cmNlOjcsVG9rZW5UeXBlOjgsVG9rZW5J
bXBlcnNvbmF0aW9uTGV2ZWw6OSxUb2tlblN0YXRpc3RpY3M6MTAsOwBUT0tFTl9JTkZPUk1B
VElPTl9DTEFTUzp0KDI1LDE3MCk9KDI1LDE2OSkAdGFnVE9LRU5fVFlQRTp0KDI1LDE3MSk9
ZVRva2VuUHJpbWFyeToxLFRva2VuSW1wZXJzb25hdGlvbjoyLDsAVE9LRU5fVFlQRTp0KDI1
LDE3Mik9KDI1LDE3MSkAQkZGQ0FMTEJBQ0s6dCgyNSwxNzMpPSgyNSwxNzQpPSooMjUsMTc1
KT1mKDAsMSkATFBDQ0hPT0tQUk9DOnQoMjUsMTc2KT0oMjUsMTc3KT0qKDI1LDE3OCk9Zigy
NSwxNTApAExQQ0ZIT09LUFJPQzp0KDI1LDE3OSk9KDI1LDE3NykAUFRIUkVBRF9TVEFSVF9S
T1VUSU5FOnQoMjUsMTgwKT0oMjUsMTgxKT0qKDI1LDE4Mik9ZigyNSwxNCkATFBUSFJFQURf
U1RBUlRfUk9VVElORTp0KDI1LDE4Myk9KDI1LDE4MCkARURJVFNUUkVBTUNBTExCQUNLOnQo
MjUsMTg0KT0oMjUsMTg1KT0qKDI1LDE4Nik9ZigyNSwxNCkATFBGUkhPT0tQUk9DOnQoMjUs
MTg3KT0oMjUsMTc3KQBMUE9GTkhPT0tQUk9DOnQoMjUsMTg4KT0oMjUsMTc3KQBMUFBSSU5U
SE9PS1BST0M6dCgyNSwxODkpPSgyNSwxNzcpAExQU0VUVVBIT09LUFJPQzp0KDI1LDE5MCk9
KDI1LDE3NykARExHUFJPQzp0KDI1LDE5MSk9KDI1LDE5Mik9KigyNSwxOTMpPWYoMjUsMikA
UEZOUFJPUFNIRUVUQ0FMTEJBQ0s6dCgyNSwxOTQpPSgyNSwxOTUpPSooMjUsMTk2KT1mKDAs
MSkATFBTRVJWSUNFX01BSU5fRlVOQ1RJT046dCgyNSwxOTcpPSgyNSwxOTgpPSooMjUsMTk5
KT1mKDAsMjApAFBGTlRWQ09NUEFSRTp0KDI1LDIwMCk9KDI1LDIwMSk9KigyNSwyMDIpPWYo
MCwxKQBXTkRQUk9DOnQoMjUsMjAzKT0oMjUsMjA0KT0qKDI1LDIwNSk9ZigyNSw5NykARkFS
UFJPQzp0KDI1LDIwNik9KDI1LDIwNyk9KigyNSwyMDgpPWYoMCwxKQBQUk9DOnQoMjUsMjA5
KT0oMjUsMjA2KQBFTlVNUkVTVFlQRVBST0M6dCgyNSwyMTApPSgyNSwyMTEpPSooMjUsMjEy
KT1mKDI1LDIpAEVOVU1SRVNOQU1FUFJPQzp0KDI1LDIxMyk9KDI1LDIxNCk9KigyNSwyMTUp
PWYoMjUsMikARU5VTVJFU0xBTkdQUk9DOnQoMjUsMjE2KT0oMjUsMjE3KT0qKDI1LDIxOCk9
ZigyNSwyKQBERVNLVE9QRU5VTVBST0M6dCgyNSwyMTkpPSgyNSwyMDYpAEVOVU1XSU5ET1dT
UFJPQzp0KDI1LDIyMCk9KDI1LDIyMSk9KigyNSwyMjIpPWYoMjUsMikARU5VTVdJTkRPV1NU
QVRJT05QUk9DOnQoMjUsMjIzKT0oMjUsMjI0KT0qKDI1LDIyNSk9ZigyNSwyKQBTRU5EQVNZ
TkNQUk9DOnQoMjUsMjI2KT0oMjUsMjI3KT0qKDI1LDIyOCk9ZigwLDIwKQBUSU1FUlBST0M6
dCgyNSwyMjkpPSgyNSwyMzApPSooMjUsMjMxKT1mKDAsMjApAEdSQVlTVFJJTkdQUk9DOnQo
MjUsMjMyKT0oMjUsMjA2KQBEUkFXU1RBVEVQUk9DOnQoMjUsMjMzKT0oMjUsMjM0KT0qKDI1
LDIzNSk9ZigyNSwyKQBQUk9QRU5VTVBST0NFWDp0KDI1LDIzNik9KDI1LDIzNyk9KigyNSwy
MzgpPWYoMjUsMikAUFJPUEVOVU1QUk9DOnQoMjUsMjM5KT0oMjUsMjQwKT0qKDI1LDI0MSk9
ZigyNSwyKQBIT09LUFJPQzp0KDI1LDI0Mik9KDI1LDI0Myk9KigyNSwyNDQpPWYoMjUsOTcp
AEVOVU1PQkpFQ1RTUFJPQzp0KDI1LDI0NSk9KDI1LDI0Nik9KigyNSwyNDcpPWYoMCwyMCkA
TElORUREQVBST0M6dCgyNSwyNDgpPSgyNSwyNDkpPSooMjUsMjUwKT1mKDAsMjApAEFCT1JU
UFJPQzp0KDI1LDI1MSk9KDI1LDI1Mik9KigyNSwyNTMpPWYoMjUsMikATFBQQUdFUEFJTlRI
T09LOnQoMjUsMjU0KT0oMjUsMTc3KQBMUFBBR0VTRVRVUEhPT0s6dCgyNSwyNTUpPSgyNSwx
NzcpAElDTUVOVU1QUk9DOnQoMjUsMjU2KT0oMjUsMjU3KT0qKDI1LDI1OCk9ZigwLDEpAEVE
SVRXT1JEQlJFQUtQUk9DRVg6dCgyNSwyNTkpPSgyNSwyNjApPSooMjUsMjYxKT1mKDI1LDEz
KQBQRk5MVkNPTVBBUkU6dCgyNSwyNjIpPSgyNSwyMDEpAExPQ0FMRV9FTlVNUFJPQzp0KDI1
LDI2Myk9KDI1LDI2NCk9KigyNSwyNjUpPWYoMjUsMikAQ09ERVBBR0VfRU5VTVBST0M6dCgy
NSwyNjYpPSgyNSwyNjQpAERBVEVGTVRfRU5VTVBST0M6dCgyNSwyNjcpPSgyNSwyNjQpAFRJ
TUVGTVRfRU5VTVBST0M6dCgyNSwyNjgpPSgyNSwyNjQpAENBTElORk9fRU5VTVBST0M6dCgy
NSwyNjkpPSgyNSwyNjQpAFBIQU5ETEVSX1JPVVRJTkU6dCgyNSwyNzApPSgyNSwyNzEpPSoo
MjUsMjcyKT1mKDI1LDIpAExQSEFORExFUl9GVU5DVElPTjp0KDI1LDI3Myk9KDI1LDI3MSkA
UEZOR0VUUFJPRklMRVBBVEg6dCgyNSwyNzQpPSgyNSwyNzUpPSooMjUsMjc2KT1mKDI1LDE1
MCkAUEZOUkVDT05DSUxFUFJPRklMRTp0KDI1LDI3Nyk9KDI1LDI3OCk9KigyNSwyNzkpPWYo
MjUsMTUwKQBQRk5QUk9DRVNTUE9MSUNJRVM6dCgyNSwyODApPSgyNSwyODEpPSooMjUsMjgy
KT1mKDI1LDIpAENBTExCOnQoMjUsMjgzKT0oMjUsMjg0KT0qKDI1LDI4NSk9ZigwLDIwKQBQ
Rk5DQUxMQkFDSzp0KDI1LDI4Nik9KDI1LDI4MykAU0VDVVJJVFlfQ09OVEVYVF9UUkFDS0lO
R19NT0RFOnQoMjUsMjg3KT0oMjUsMikAV05ERU5VTVBST0M6dCgyNSwyODgpPSgyNSwyMDYp
AEVOSE1GRU5VTVBST0M6dCgyNSwyODkpPSgyNSwyMDYpAENDU1RZTEU6dCgyNSwyOTApPSgy
NSwxNCkAUENDU1RZTEU6dCgyNSwyOTEpPSgyNSw4OCkATFBDQ1NUWUxFOnQoMjUsMjkyKT0o
MjUsODgpAENDU1RZTEVGTEFHQTp0KDI1LDI5Myk9KDI1LDE0KQBQQ0NTVFlMRUZMQUdBOnQo
MjUsMjk0KT0oMjUsODgpAExQQ0NTVFlMRUZMQUdBOnQoMjUsMjk1KT0oMjUsODgpAC9ob21l
L25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vd2luc3VwL2luY2x1ZGUvV2luZG93czMy
L01lc3NhZ2VzLmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAv
aW5jbHVkZS9XaW5kb3dzMzIvRGVmaW5lcy5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRv
b2xzL2Rldm8vd2luc3VwL2luY2x1ZGUvV2luZG93czMyL1N0cnVjdHVyZXMuaABfQUJDOlR0
KDI4LDEpPXMxMmFiY0E6KDAsMSksMCwzMjthYmNCOigyNSwxNTApLDMyLDMyO2FiY0M6KDAs
MSksNjQsMzI7X19hczo6KDI4LDIpPSMjKDI4LDMpPSYoMjgsMSk7OlJDNF9BQkM7MkEuO19B
QkM6OigyOCw0KT0jIygyOCw1KT0qKDI4LDEpOzpSQzRfQUJDOzJBLigyOCw2KT0jIygyOCw1
KTs6OzJBLjs7AEFCQzp0KDI4LDcpPSgyOCwxKQBMUEFCQzp0KDI4LDgpPSgyOCw1KQBfQUJD
RkxPQVQ6VHQoMjgsOSk9czEyYWJjZkE6KDI1LDE4KSwwLDMyO2FiY2ZCOigyNSwxOCksMzIs
MzI7YWJjZkM6KDI1LDE4KSw2NCwzMjtfX2FzOjooMjgsMTApPSMjKDI4LDExKT0mKDI4LDkp
OzpSQzlfQUJDRkxPQVQ7MkEuO19BQkNGTE9BVDo6KDI4LDEyKT0jIygyOCwxMyk9KigyOCw5
KTs6UkM5X0FCQ0ZMT0FUOzJBLigyOCwxNCk9IyMoMjgsMTMpOzo7MkEuOzsAQUJDRkxPQVQ6
dCgyOCwxNSk9KDI4LDkpAExQQUJDRkxPQVQ6dCgyOCwxNik9KDI4LDEzKQB0YWdBQ0NFTDpU
dCgyOCwxNyk9czZmVmlydDooMjUsNSksMCw4O2tleTooMjUsMTUzKSwxNiwxNjtjbWQ6KDI1
LDE1MyksMzIsMTY7X19hczo6KDI4LDE4KT0jIygyOCwxOSk9JigyOCwxNyk7OlJDOHRhZ0FD
Q0VMOzJBLjt0YWdBQ0NFTDo6KDI4LDIwKT0jIygyOCwyMSk9KigyOCwxNyk7OlJDOHRhZ0FD
Q0VMOzJBLigyOCwyMik9IyMoMjgsMjEpOzo7MkEuOzsAQUNDRUw6dCgyOCwyMyk9KDI4LDE3
KQBMUEFDQ0VMOnQoMjgsMjQpPSgyOCwyMSkAX0FDRV9IRUFERVI6VHQoMjgsMjUpPXM0QWNl
VHlwZTooMjUsNSksMCw4O0FjZUZsYWdzOigyNSw1KSw4LDg7QWNlU2l6ZTooMjUsMTUzKSwx
NiwxNjtfX2FzOjooMjgsMjYpPSMjKDI4LDI3KT0mKDI4LDI1KTs6UkMxMV9BQ0VfSEVBREVS
OzJBLjtfQUNFX0hFQURFUjo6KDI4LDI4KT0jIygyOCwyOSk9KigyOCwyNSk7OlJDMTFfQUNF
X0hFQURFUjsyQS4oMjgsMzApPSMjKDI4LDI5KTs6OzJBLjs7AEFDRV9IRUFERVI6dCgyOCwz
MSk9KDI4LDI1KQBBQ0NFU1NfTUFTSzp0KDI4LDMyKT0oMjUsMTQpAFJFR1NBTTp0KDI4LDMz
KT0oMjgsMzIpAF9BQ0NFU1NfQUxMT1dFRF9BQ0U6VHQoMjgsMzQpPXMxMkhlYWRlcjooMjgs
MzEpLDAsMzI7TWFzazooMjgsMzIpLDMyLDMyO1NpZFN0YXJ0OigyNSwxNCksNjQsMzI7X19h
czo6KDI4LDM1KT0jIygyOCwzNik9JigyOCwzNCk7OlJDMTlfQUNDRVNTX0FMTE9XRURfQUNF
OzJBLjtfQUNDRVNTX0FMTE9XRURfQUNFOjooMjgsMzcpPSMjKDI4LDM4KT0qKDI4LDM0KTs6
UkMxOV9BQ0NFU1NfQUxMT1dFRF9BQ0U7MkEuKDI4LDM5KT0jIygyOCwzOCk7OjsyQS47OwBB
Q0NFU1NfQUxMT1dFRF9BQ0U6dCgyOCw0MCk9KDI4LDM0KQBfQUNDRVNTX0RFTklFRF9BQ0U6
VHQoMjgsNDEpPXMxMkhlYWRlcjooMjgsMzEpLDAsMzI7TWFzazooMjgsMzIpLDMyLDMyO1Np
ZFN0YXJ0OigyNSwxNCksNjQsMzI7X19hczo6KDI4LDQyKT0jIygyOCw0Myk9JigyOCw0MSk7
OlJDMThfQUNDRVNTX0RFTklFRF9BQ0U7MkEuO19BQ0NFU1NfREVOSUVEX0FDRTo6KDI4LDQ0
KT0jIygyOCw0NSk9KigyOCw0MSk7OlJDMThfQUNDRVNTX0RFTklFRF9BQ0U7MkEuKDI4LDQ2
KT0jIygyOCw0NSk7OjsyQS47OwBBQ0NFU1NfREVOSUVEX0FDRTp0KDI4LDQ3KT0oMjgsNDEp
AHRhZ0FDQ0VTU1RJTUVPVVQ6VHQoMjgsNDgpPXMxMmNiU2l6ZTooMjUsMTUwKSwwLDMyO2R3
RmxhZ3M6KDI1LDE0KSwzMiwzMjtpVGltZU91dE1TZWM6KDI1LDE0KSw2NCwzMjtfX2FzOjoo
MjgsNDkpPSMjKDI4LDUwKT0mKDI4LDQ4KTs6UkMxNnRhZ0FDQ0VTU1RJTUVPVVQ7MkEuO3Rh
Z0FDQ0VTU1RJTUVPVVQ6OigyOCw1MSk9IyMoMjgsNTIpPSooMjgsNDgpOzpSQzE2dGFnQUND
RVNTVElNRU9VVDsyQS4oMjgsNTMpPSMjKDI4LDUyKTs6OzJBLjs7AEFDQ0VTU1RJTUVPVVQ6
dCgyOCw1NCk9KDI4LDQ4KQBfQUNMOlR0KDI4LDU1KT1zOEFjbFJldmlzaW9uOigyNSw1KSww
LDg7U2J6MTooMjUsNSksOCw4O0FjbFNpemU6KDI1LDE1MyksMTYsMTY7QWNlQ291bnQ6KDI1
LDE1MyksMzIsMTY7U2J6MjooMjUsMTUzKSw0OCwxNjtfX2FzOjooMjgsNTYpPSMjKDI4LDU3
KT0mKDI4LDU1KTs6UkM0X0FDTDsyQS47X0FDTDo6KDI4LDU4KT0jIygyOCw1OSk9KigyOCw1
NSk7OlJDNF9BQ0w7MkEuKDI4LDYwKT0jIygyOCw1OSk7OjsyQS47OwBBQ0w6dCgyOCw2MSk9
KDI4LDU1KQBQQUNMOnQoMjgsNjIpPSgyOCw1OSkAX0FDTF9SRVZJU0lPTl9JTkZPUk1BVElP
TjpUdCgyOCw2Myk9czRBY2xSZXZpc2lvbjooMjUsMTQpLDAsMzI7X19hczo6KDI4LDY0KT0j
IygyOCw2NSk9JigyOCw2Myk7OlJDMjVfQUNMX1JFVklTSU9OX0lORk9STUFUSU9OOzJBLjtf
QUNMX1JFVklTSU9OX0lORk9STUFUSU9OOjooMjgsNjYpPSMjKDI4LDY3KT0qKDI4LDYzKTs6
UkMyNV9BQ0xfUkVWSVNJT05fSU5GT1JNQVRJT047MkEuKDI4LDY4KT0jIygyOCw2Nyk7Ojsy
QS47OwBBQ0xfUkVWSVNJT05fSU5GT1JNQVRJT046dCgyOCw2OSk9KDI4LDYzKQBfQUNMX1NJ
WkVfSU5GT1JNQVRJT046VHQoMjgsNzApPXMxMkFjZUNvdW50OigyNSwxNCksMCwzMjtBY2xC
eXRlc0luVXNlOigyNSwxNCksMzIsMzI7QWNsQnl0ZXNGcmVlOigyNSwxNCksNjQsMzI7X19h
czo6KDI4LDcxKT0jIygyOCw3Mik9JigyOCw3MCk7OlJDMjFfQUNMX1NJWkVfSU5GT1JNQVRJ
T047MkEuO19BQ0xfU0laRV9JTkZPUk1BVElPTjo6KDI4LDczKT0jIygyOCw3NCk9KigyOCw3
MCk7OlJDMjFfQUNMX1NJWkVfSU5GT1JNQVRJT047MkEuKDI4LDc1KT0jIygyOCw3NCk7Ojsy
QS47OwBBQ0xfU0laRV9JTkZPUk1BVElPTjp0KDI4LDc2KT0oMjgsNzApAF9BQ1RJT05fSEVB
REVSOlR0KDI4LDc3KT1zOHRyYW5zcG9ydF9pZDooMjUsMTUxKSwwLDMyO2FjdGlvbl9jb2Rl
OigyNSwxNTIpLDMyLDE2O3Jlc2VydmVkOigyNSwxNTIpLDQ4LDE2O19fYXM6OigyOCw3OCk9
IyMoMjgsNzkpPSYoMjgsNzcpOzpSQzE0X0FDVElPTl9IRUFERVI7MkEuO19BQ1RJT05fSEVB
REVSOjooMjgsODApPSMjKDI4LDgxKT0qKDI4LDc3KTs6UkMxNF9BQ1RJT05fSEVBREVSOzJB
LigyOCw4Mik9IyMoMjgsODEpOzo7MkEuOzsAQUNUSU9OX0hFQURFUjp0KDI4LDgzKT0oMjgs
NzcpAF9BREFQVEVSX1NUQVRVUzpUdCgyOCw4NCk9czYwYWRhcHRlcl9hZGRyZXNzOigyOCw4
NSk9YXIoMCwxKTswOzU7KDAsMTEpLDAsNDg7cmV2X21ham9yOigyNSwxNDkpLDQ4LDg7cmVz
ZXJ2ZWQwOigyNSwxNDkpLDU2LDg7YWRhcHRlcl90eXBlOigyNSwxNDkpLDY0LDg7cmV2X21p
bm9yOigyNSwxNDkpLDcyLDg7ZHVyYXRpb246KDI1LDE1MyksODAsMTY7ZnJtcl9yZWN2Oigy
NSwxNTMpLDk2LDE2O2ZybXJfeG1pdDooMjUsMTUzKSwxMTIsMTY7aWZyYW1lX3JlY3ZfZXJy
OigyNSwxNTMpLDEyOCwxNjt4bWl0X2Fib3J0czooMjUsMTUzKSwxNDQsMTY7eG1pdF9zdWNj
ZXNzOigyNSwxNCksMTYwLDMyO3JlY3Zfc3VjY2VzczooMjUsMTQpLDE5MiwzMjtpZnJhbWVf
eG1pdF9lcnI6KDI1LDE1MyksMjI0LDE2O3JlY3ZfYnVmZl91bmF2YWlsOigyNSwxNTMpLDI0
MCwxNjt0MV90aW1lb3V0czooMjUsMTUzKSwyNTYsMTY7dGlfdGltZW91dHM6KDI1LDE1Myks
MjcyLDE2O3Jlc2VydmVkMTooMjUsMTQpLDI4OCwzMjtmcmVlX25jYnM6KDI1LDE1MyksMzIw
LDE2O21heF9jZmdfbmNiczooMjUsMTUzKSwzMzYsMTY7bWF4X25jYnM6KDI1LDE1MyksMzUy
LDE2O3htaXRfYnVmX3VuYXZhaWw6KDI1LDE1MyksMzY4LDE2O21heF9kZ3JhbV9zaXplOigy
NSwxNTMpLDM4NCwxNjtwZW5kaW5nX3Nlc3M6KDI1LDE1MyksNDAwLDE2O21heF9jZmdfc2Vz
czooMjUsMTUzKSw0MTYsMTY7bWF4X3Nlc3M6KDI1LDE1MyksNDMyLDE2O21heF9zZXNzX3Br
dF9zaXplOigyNSwxNTMpLDQ0OCwxNjtuYW1lX2NvdW50OigyNSwxNTMpLDQ2NCwxNjtfX2Fz
OjooMjgsODYpPSMjKDI4LDg3KT0mKDI4LDg0KTs6UkMxNV9BREFQVEVSX1NUQVRVUzsyQS47
X0FEQVBURVJfU1RBVFVTOjooMjgsODgpPSMjKDI4LDg5KT0qKDI4LDg0KTs6UkMxNV9BREFQ
VEVSX1NUQVRVUzsyQS4oMjgsOTApPSMjKDI4LDg5KTs6OzJBLjs7AEFEQVBURVJfU1RBVFVT
OnQoMjgsOTEpPSgyOCw4NCkAX0FEREpPQl9JTkZPXzE6VHQoMjgsOTIpPXM4UGF0aDooMjUs
OTYpLDAsMzI7Sm9iSWQ6KDI1LDE0KSwzMiwzMjtfX2FzOjooMjgsOTMpPSMjKDI4LDk0KT0m
KDI4LDkyKTs6UkMxNF9BRERKT0JfSU5GT18xOzJBLjtfQURESk9CX0lORk9fMTo6KDI4LDk1
KT0jIygyOCw5Nik9KigyOCw5Mik7OlJDMTRfQURESk9CX0lORk9fMTsyQS4oMjgsOTcpPSMj
KDI4LDk2KTs6OzJBLjs7AEFEREpPQl9JTkZPXzE6dCgyOCw5OCk9KDI4LDkyKQB0YWdBTklN
QVRJT05JTkZPOlR0KDI4LDk5KT1zOGNiU2l6ZTooMjUsMTUwKSwwLDMyO2lNaW5BbmltYXRl
OigwLDEpLDMyLDMyO19fYXM6OigyOCwxMDApPSMjKDI4LDEwMSk9JigyOCw5OSk7OlJDMTZ0
YWdBTklNQVRJT05JTkZPOzJBLjt0YWdBTklNQVRJT05JTkZPOjooMjgsMTAyKT0jIygyOCwx
MDMpPSooMjgsOTkpOzpSQzE2dGFnQU5JTUFUSU9OSU5GTzsyQS4oMjgsMTA0KT0jIygyOCwx
MDMpOzo7MkEuOzsAQU5JTUFUSU9OSU5GTzp0KDI4LDEwNSk9KDI4LDk5KQBMUEFOSU1BVElP
TklORk86dCgyOCwxMDYpPSgyOCwxMDMpAF9SRUNUOlR0KDI4LDEwNyk9czE2bGVmdDooMjUs
MTMpLDAsMzI7dG9wOigyNSwxMyksMzIsMzI7cmlnaHQ6KDI1LDEzKSw2NCwzMjtib3R0b206
KDI1LDEzKSw5NiwzMjtfX2FzOjooMjgsMTA4KT0jIygyOCwxMDkpPSYoMjgsMTA3KTs6UkM1
X1JFQ1Q7MkEuO19SRUNUOjooMjgsMTEwKT0jIygyOCwxMTEpPSooMjgsMTA3KTs6UkM1X1JF
Q1Q7MkEuKDI4LDExMik9IyMoMjgsMTExKTs6OzJBLjs7AFJFQ1Q6dCgyOCwxMTMpPSgyOCwx
MDcpAExQUkVDVDp0KDI4LDExNCk9KDI4LDExMSkAUFJFQ1Q6dCgyOCwxMTUpPSgyOCwxMTEp
AF9SRUNUTDpUdCgyOCwxMTYpPXMxNmxlZnQ6KDI1LDEzKSwwLDMyO3RvcDooMjUsMTMpLDMy
LDMyO3JpZ2h0OigyNSwxMyksNjQsMzI7Ym90dG9tOigyNSwxMyksOTYsMzI7X19hczo6KDI4
LDExNyk9IyMoMjgsMTE4KT0mKDI4LDExNik7OlJDNl9SRUNUTDsyQS47X1JFQ1RMOjooMjgs
MTE5KT0jIygyOCwxMjApPSooMjgsMTE2KTs6UkM2X1JFQ1RMOzJBLigyOCwxMjEpPSMjKDI4
LDEyMCk7OjsyQS47OwBSRUNUTDp0KDI4LDEyMik9KDI4LDExNikAX0FwcEJhckRhdGE6VHQo
MjgsMTIzKT1zMzZjYlNpemU6KDI1LDE0KSwwLDMyO2hXbmQ6KDI1LDYxKSwzMiwzMjt1Q2Fs
bGJhY2tNZXNzYWdlOigyNSwxNTApLDY0LDMyO3VFZGdlOigyNSwxNTApLDk2LDMyO3JjOigy
OCwxMTMpLDEyOCwxMjg7bFBhcmFtOigyNSw3MCksMjU2LDMyO19fYXM6OigyOCwxMjQpPSMj
KDI4LDEyNSk9JigyOCwxMjMpOzpSQzExX0FwcEJhckRhdGE7MkEuO19BcHBCYXJEYXRhOjoo
MjgsMTI2KT0jIygyOCwxMjcpPSooMjgsMTIzKTs6UkMxMV9BcHBCYXJEYXRhOzJBLigyOCwx
MjgpPSMjKDI4LDEyNyk7OjsyQS47OwBBUFBCQVJEQVRBOnQoMjgsMTI5KT0oMjgsMTIzKQBQ
QVBQQkFSREFUQTp0KDI4LDEzMCk9KDI4LDEyNykAdGFnQklUTUFQOlR0KDI4LDEzMSk9czI0
Ym1UeXBlOigyNSwxMyksMCwzMjtibVdpZHRoOigyNSwxMyksMzIsMzI7Ym1IZWlnaHQ6KDI1
LDEzKSw2NCwzMjtibVdpZHRoQnl0ZXM6KDI1LDEzKSw5NiwzMjtibVBsYW5lczooMjUsMTUz
KSwxMjgsMTY7Ym1CaXRzUGl4ZWw6KDI1LDE1MyksMTQ0LDE2O2JtQml0czooMjUsOTgpLDE2
MCwzMjtfX2FzOjooMjgsMTMyKT0jIygyOCwxMzMpPSYoMjgsMTMxKTs6UkM5dGFnQklUTUFQ
OzJBLjt0YWdCSVRNQVA6OigyOCwxMzQpPSMjKDI4LDEzNSk9KigyOCwxMzEpOzpSQzl0YWdC
SVRNQVA7MkEuKDI4LDEzNik9IyMoMjgsMTM1KTs6OzJBLjs7AEJJVE1BUDp0KDI4LDEzNyk9
KDI4LDEzMSkAUEJJVE1BUDp0KDI4LDEzOCk9KDI4LDEzNSkATlBCSVRNQVA6dCgyOCwxMzkp
PSgyOCwxMzUpAExQQklUTUFQOnQoMjgsMTQwKT0oMjgsMTM1KQB0YWdCSVRNQVBDT1JFSEVB
REVSOlR0KDI4LDE0MSk9czEyYmNTaXplOigyNSwxNCksMCwzMjtiY1dpZHRoOigyNSwxNTMp
LDMyLDE2O2JjSGVpZ2h0OigyNSwxNTMpLDQ4LDE2O2JjUGxhbmVzOigyNSwxNTMpLDY0LDE2
O2JjQml0Q291bnQ6KDI1LDE1MyksODAsMTY7X19hczo6KDI4LDE0Mik9IyMoMjgsMTQzKT0m
KDI4LDE0MSk7OlJDMTl0YWdCSVRNQVBDT1JFSEVBREVSOzJBLjt0YWdCSVRNQVBDT1JFSEVB
REVSOjooMjgsMTQ0KT0jIygyOCwxNDUpPSooMjgsMTQxKTs6UkMxOXRhZ0JJVE1BUENPUkVI
RUFERVI7MkEuKDI4LDE0Nik9IyMoMjgsMTQ1KTs6OzJBLjs7AEJJVE1BUENPUkVIRUFERVI6
dCgyOCwxNDcpPSgyOCwxNDEpAFBCSVRNQVBDT1JFSEVBREVSOnQoMjgsMTQ4KT0oMjgsMTQ1
KQBMUEJJVE1BUENPUkVIRUFERVI6dCgyOCwxNDkpPSgyOCwxNDUpAHRhZ1JHQlRSSVBMRTpU
dCgyOCwxNTApPXMzcmdidEJsdWU6KDI1LDUpLDAsODtyZ2J0R3JlZW46KDI1LDUpLDgsODty
Z2J0UmVkOigyNSw1KSwxNiw4O19fYXM6OigyOCwxNTEpPSMjKDI4LDE1Mik9JigyOCwxNTAp
OzpSQzEydGFnUkdCVFJJUExFOzJBLjt0YWdSR0JUUklQTEU6OigyOCwxNTMpPSMjKDI4LDE1
NCk9KigyOCwxNTApOzpSQzEydGFnUkdCVFJJUExFOzJBLigyOCwxNTUpPSMjKDI4LDE1NCk7
OjsyQS47OwBSR0JUUklQTEU6dCgyOCwxNTYpPSgyOCwxNTApAFBSR0JUUklQTEU6dCgyOCwx
NTcpPSgyOCwxNTQpAExQUkdCVFJJUExFOnQoMjgsMTU4KT0oMjgsMTU0KQB0YWdCSVRNQVBD
T1JFSU5GTzpUdCgyOCwxNTkpPXMxNWJtY2lIZWFkZXI6KDI4LDE0NyksMCw5NjtibWNpQ29s
b3JzOigyOCwxNjApPWFyKDAsMSk7MDswOygyOCwxNTApLDk2LDI0O19fYXM6OigyOCwxNjEp
PSMjKDI4LDE2Mik9JigyOCwxNTkpOzpSQzE3dGFnQklUTUFQQ09SRUlORk87MkEuO3RhZ0JJ
VE1BUENPUkVJTkZPOjooMjgsMTYzKT0jIygyOCwxNjQpPSooMjgsMTU5KTs6UkMxN3RhZ0JJ
VE1BUENPUkVJTkZPOzJBLigyOCwxNjUpPSMjKDI4LDE2NCk7OjsyQS47OwBCSVRNQVBDT1JF
SU5GTzp0KDI4LDE2Nik9KDI4LDE1OSkAUEJJVE1BUENPUkVJTkZPOnQoMjgsMTY3KT0oMjgs
MTY0KQBMUEJJVE1BUENPUkVJTkZPOnQoMjgsMTY4KT0oMjgsMTY0KQB0YWdCSVRNQVBGSUxF
SEVBREVSOlR0KDI4LDE2OSk9czE0YmZUeXBlOigyNSwxNTMpLDAsMTY7YmZTaXplOigyNSwx
NCksMTYsMzI7YmZSZXNlcnZlZDE6KDI1LDE1MyksNDgsMTY7YmZSZXNlcnZlZDI6KDI1LDE1
MyksNjQsMTY7YmZPZmZCaXRzOigyNSwxNCksODAsMzI7X19hczo6KDI4LDE3MCk9IyMoMjgs
MTcxKT0mKDI4LDE2OSk7OlJDMTl0YWdCSVRNQVBGSUxFSEVBREVSOzJBLjt0YWdCSVRNQVBG
SUxFSEVBREVSOjooMjgsMTcyKT0jIygyOCwxNzMpPSooMjgsMTY5KTs6UkMxOXRhZ0JJVE1B
UEZJTEVIRUFERVI7MkEuKDI4LDE3NCk9IyMoMjgsMTczKTs6OzJBLjs7AEJJVE1BUEZJTEVI
RUFERVI6dCgyOCwxNzUpPSgyOCwxNjkpAHRhZ0JJVE1BUElORk9IRUFERVI6VHQoMjgsMTc2
KT1zNDBiaVNpemU6KDI1LDE0KSwwLDMyO2JpV2lkdGg6KDI1LDEzKSwzMiwzMjtiaUhlaWdo
dDooMjUsMTMpLDY0LDMyO2JpUGxhbmVzOigyNSwxNTMpLDk2LDE2O2JpQml0Q291bnQ6KDI1
LDE1MyksMTEyLDE2O2JpQ29tcHJlc3Npb246KDI1LDE0KSwxMjgsMzI7YmlTaXplSW1hZ2U6
KDI1LDE0KSwxNjAsMzI7YmlYUGVsc1Blck1ldGVyOigyNSwxMyksMTkyLDMyO2JpWVBlbHNQ
ZXJNZXRlcjooMjUsMTMpLDIyNCwzMjtiaUNsclVzZWQ6KDI1LDE0KSwyNTYsMzI7YmlDbHJJ
bXBvcnRhbnQ6KDI1LDE0KSwyODgsMzI7X19hczo6KDI4LDE3Nyk9IyMoMjgsMTc4KT0mKDI4
LDE3Nik7OlJDMTl0YWdCSVRNQVBJTkZPSEVBREVSOzJBLjt0YWdCSVRNQVBJTkZPSEVBREVS
OjooMjgsMTc5KT0jIygyOCwxODApPSooMjgsMTc2KTs6UkMxOXRhZ0JJVE1BUElORk9IRUFE
RVI7MkEuKDI4LDE4MSk9IyMoMjgsMTgwKTs6OzJBLjs7AEJJVE1BUElORk9IRUFERVI6dCgy
OCwxODIpPSgyOCwxNzYpAExQQklUTUFQSU5GT0hFQURFUjp0KDI4LDE4Myk9KDI4LDE4MCkA
UEJJVE1BUElORk9IRUFERVI6dCgyOCwxODQpPSgyOCwxODApAHRhZ1JHQlFVQUQ6VHQoMjgs
MTg1KT1zNHJnYkJsdWU6KDI1LDUpLDAsODtyZ2JHcmVlbjooMjUsNSksOCw4O3JnYlJlZDoo
MjUsNSksMTYsODtyZ2JSZXNlcnZlZDooMjUsNSksMjQsODtfX2FzOjooMjgsMTg2KT0jIygy
OCwxODcpPSYoMjgsMTg1KTs6UkMxMHRhZ1JHQlFVQUQ7MkEuO3RhZ1JHQlFVQUQ6OigyOCwx
ODgpPSMjKDI4LDE4OSk9KigyOCwxODUpOzpSQzEwdGFnUkdCUVVBRDsyQS4oMjgsMTkwKT0j
IygyOCwxODkpOzo7MkEuOzsAUkdCUVVBRDp0KDI4LDE5MSk9KDI4LDE4NSkAUFJHQlFVQUQ6
dCgyOCwxOTIpPSgyOCwxODkpAExQUkdCUVVBRDp0KDI4LDE5Myk9KDI4LDE4OSkAdGFnQklU
TUFQSU5GTzpUdCgyOCwxOTQpPXM0NGJtaUhlYWRlcjooMjgsMTgyKSwwLDMyMDtibWlDb2xv
cnM6KDI4LDE5NSk9YXIoMCwxKTswOzA7KDI4LDE4NSksMzIwLDMyO19fYXM6OigyOCwxOTYp
PSMjKDI4LDE5Nyk9JigyOCwxOTQpOzpSQzEzdGFnQklUTUFQSU5GTzsyQS47dGFnQklUTUFQ
SU5GTzo6KDI4LDE5OCk9IyMoMjgsMTk5KT0qKDI4LDE5NCk7OlJDMTN0YWdCSVRNQVBJTkZP
OzJBLigyOCwyMDApPSMjKDI4LDE5OSk7OjsyQS47OwBCSVRNQVBJTkZPOnQoMjgsMjAxKT0o
MjgsMTk0KQBMUEJJVE1BUElORk86dCgyOCwyMDIpPSgyOCwxOTkpAFBCSVRNQVBJTkZPOnQo
MjgsMjAzKT0oMjgsMTk5KQB0YWdCSVRNQVBJTkZPTUFTSzpUdCgyOCwyMDQpPXM1MmJtaUhl
YWRlcjooMjgsMTgyKSwwLDMyMDtkd01hc2s6KDI4LDIwNSk9YXIoMCwxKTswOzI7KDAsNCks
MzIwLDk2O19fYXM6OigyOCwyMDYpPSMjKDI4LDIwNyk9JigyOCwyMDQpOzpSQzE3dGFnQklU
TUFQSU5GT01BU0s7MkEuO3RhZ0JJVE1BUElORk9NQVNLOjooMjgsMjA4KT0jIygyOCwyMDkp
PSooMjgsMjA0KTs6UkMxN3RhZ0JJVE1BUElORk9NQVNLOzJBLigyOCwyMTApPSMjKDI4LDIw
OSk7OjsyQS47OwBCSVRNQVBJTkZPTUFTSzp0KDI4LDIxMSk9KDI4LDIwNCkATFBCSVRNQVBJ
TkZPTUFTSzp0KDI4LDIxMik9KDI4LDIwNCkAUEJJVE1BUElORk9NQVNLOnQoMjgsMjEzKT0o
MjgsMjA5KQBGWFBUMkRPVDMwOnQoMjgsMjE0KT0oMCwzKQBMUEZYUFQyRE9UMzA6dCgyOCwy
MTUpPSgyNSw5MykAdGFnQ0lFWFlaOlR0KDI4LDIxNik9czEyY2lleHl6WDooMjgsMjE0KSww
LDMyO2NpZXh5elk6KDI4LDIxNCksMzIsMzI7Y2lleHl6WjooMjgsMjE0KSw2NCwzMjtfX2Fz
OjooMjgsMjE3KT0jIygyOCwyMTgpPSYoMjgsMjE2KTs6UkM5dGFnQ0lFWFlaOzJBLjt0YWdD
SUVYWVo6OigyOCwyMTkpPSMjKDI4LDIyMCk9KigyOCwyMTYpOzpSQzl0YWdDSUVYWVo7MkEu
KDI4LDIyMSk9IyMoMjgsMjIwKTs6OzJBLjs7AENJRVhZWjp0KDI4LDIyMik9KDI4LDIxNikA
TFBDSUVYWVo6dCgyOCwyMjMpPSgyOCwyMjApAHRhZ0NJRVhZWlRSSVBMRTpUdCgyOCwyMjQp
PXMzNmNpZXh5elJlZDooMjgsMjIyKSwwLDk2O2NpZXh5ekdyZWVuOigyOCwyMjIpLDk2LDk2
O2NpZXh5ekJsdWU6KDI4LDIyMiksMTkyLDk2O19fYXM6OigyOCwyMjUpPSMjKDI4LDIyNik9
JigyOCwyMjQpOzpSQzE1dGFnQ0lFWFlaVFJJUExFOzJBLjt0YWdDSUVYWVpUUklQTEU6Oigy
OCwyMjcpPSMjKDI4LDIyOCk9KigyOCwyMjQpOzpSQzE1dGFnQ0lFWFlaVFJJUExFOzJBLigy
OCwyMjkpPSMjKDI4LDIyOCk7OjsyQS47OwBDSUVYWVpUUklQTEU6dCgyOCwyMzApPSgyOCwy
MjQpAExQQ0lFWFlaVFJJUExFOnQoMjgsMjMxKT0oMjgsMjI4KQBCSVRNQVBWNEhFQURFUjp0
KDI4LDIzMik9czEwOGJWNFNpemU6KDI1LDE0KSwwLDMyO2JWNFdpZHRoOigyNSwxMyksMzIs
MzI7YlY0SGVpZ2h0OigyNSwxMyksNjQsMzI7YlY0UGxhbmVzOigyNSwxNTMpLDk2LDE2O2JW
NEJpdENvdW50OigyNSwxNTMpLDExMiwxNjtiVjRWNENvbXByZXNzaW9uOigyNSwxNCksMTI4
LDMyO2JWNFNpemVJbWFnZTooMjUsMTQpLDE2MCwzMjtiVjRYUGVsc1Blck1ldGVyOigyNSwx
MyksMTkyLDMyO2JWNFlQZWxzUGVyTWV0ZXI6KDI1LDEzKSwyMjQsMzI7YlY0Q2xyVXNlZDoo
MjUsMTQpLDI1NiwzMjtiVjRDbHJJbXBvcnRhbnQ6KDI1LDE0KSwyODgsMzI7YlY0UmVkTWFz
azooMjUsMTQpLDMyMCwzMjtiVjRHcmVlbk1hc2s6KDI1LDE0KSwzNTIsMzI7YlY0Qmx1ZU1h
c2s6KDI1LDE0KSwzODQsMzI7YlY0QWxwaGFNYXNrOigyNSwxNCksNDE2LDMyO2JWNENTVHlw
ZTooMjUsMTQpLDQ0OCwzMjtiVjRFbmRwb2ludHM6KDI4LDIzMCksNDgwLDI4ODtiVjRHYW1t
YVJlZDooMjUsMTQpLDc2OCwzMjtiVjRHYW1tYUdyZWVuOigyNSwxNCksODAwLDMyO2JWNEdh
bW1hQmx1ZTooMjUsMTQpLDgzMiwzMjtfX2FzOjooMjgsMjMzKT0jKDI4LDIzMiksKDI4LDIz
NCk9JigyOCwyMzIpLCgyOCwyMzUpPSooMjgsMjMyKSwoMjgsMjM2KT0mKDI4LDIzNyk9czEw
OGJWNFNpemU6KDI1LDE0KSwwLDMyO2JWNFdpZHRoOigyNSwxMyksMzIsMzI7YlY0SGVpZ2h0
OigyNSwxMyksNjQsMzI7YlY0UGxhbmVzOigyNSwxNTMpLDk2LDE2O2JWNEJpdENvdW50Oigy
NSwxNTMpLDExMiwxNjtiVjRWNENvbXByZXNzaW9uOigyNSwxNCksMTI4LDMyO2JWNFNpemVJ
bWFnZTooMjUsMTQpLDE2MCwzMjtiVjRYUGVsc1Blck1ldGVyOigyNSwxMyksMTkyLDMyO2JW
NFlQZWxzUGVyTWV0ZXI6KDI1LDEzKSwyMjQsMzI7YlY0Q2xyVXNlZDooMjUsMTQpLDI1Niwz
MjtiVjRDbHJJbXBvcnRhbnQ6KDI1LDE0KSwyODgsMzI7YlY0UmVkTWFzazooMjUsMTQpLDMy
MCwzMjtiVjRHcmVlbk1hc2s6KDI1LDE0KSwzNTIsMzI7YlY0Qmx1ZU1hc2s6KDI1LDE0KSwz
ODQsMzI7YlY0QWxwaGFNYXNrOigyNSwxNCksNDE2LDMyO2JWNENTVHlwZTooMjUsMTQpLDQ0
OCwzMjtiVjRFbmRwb2ludHM6KDI4LDIzMCksNDgwLDI4ODtiVjRHYW1tYVJlZDooMjUsMTQp
LDc2OCwzMjtiVjRHYW1tYUdyZWVuOigyNSwxNCksODAwLDMyO2JWNEdhbW1hQmx1ZTooMjUs
MTQpLDgzMiwzMjtfX2FzOjooMjgsMjMzKTpfX2FzX18zJF8wUkMzJF8wOzJBLjskXzA6Oigy
OCwyMzgpPSMoMjgsMjMyKSwoMjgsMjM1KSwoMjgsMjM1KSwoMjgsMjM2KSwoMCwyMCk7Ol9f
MyRfMFJDMyRfMDsyQS4oMjgsMjM5KT0jKDI4LDIzMiksKDI4LDIzNSksKDI4LDIzNSksKDAs
MjApOzpfXzMkXzA7MkEuOzssKDAsMjApOzpfX2FzX18zJF8wUkMzJF8wOzJBLjskXzA6Oigy
OCwyMzgpOl9fMyRfMFJDMyRfMDsyQS4oMjgsMjM5KTpfXzMkXzA7MkEuOzsATFBCSVRNQVBW
NEhFQURFUjp0KDI4LDI0MCk9KDI4LDIzNSkAUEJJVE1BUFY0SEVBREVSOnQoMjgsMjQxKT0o
MjgsMjM1KQBfQkxPQjpUdCgyOCwyNDIpPXM4Y2JTaXplOigyNSwxNTEpLDAsMzI7cEJsb2JE
YXRhOigyNSw3NCksMzIsMzI7X19hczo6KDI4LDI0Myk9IyMoMjgsMjQ0KT0mKDI4LDI0Mik7
OlJDNV9CTE9COzJBLjtfQkxPQjo6KDI4LDI0NSk9IyMoMjgsMjQ2KT0qKDI4LDI0Mik7OlJD
NV9CTE9COzJBLigyOCwyNDcpPSMjKDI4LDI0Nik7OjsyQS47OwBCTE9COnQoMjgsMjQ4KT0o
MjgsMjQyKQBfU0hJVEVNSUQ6VHQoMjgsMjQ5KT1zNGNiOigyNSwxNTIpLDAsMTY7YWJJRDoo
MjgsMjUwKT1hcigwLDEpOzA7MDsoMCwxMSksMTYsODtfX2FzOjooMjgsMjUxKT0jIygyOCwy
NTIpPSYoMjgsMjQ5KTs6UkM5X1NISVRFTUlEOzJBLjtfU0hJVEVNSUQ6OigyOCwyNTMpPSMj
KDI4LDI1NCk9KigyOCwyNDkpOzpSQzlfU0hJVEVNSUQ7MkEuKDI4LDI1NSk9IyMoMjgsMjU0
KTs6OzJBLjs7AFNISVRFTUlEOnQoMjgsMjU2KT0oMjgsMjQ5KQBMUFNISVRFTUlEOnQoMjgs
MjU3KT0oMjgsMjU0KQBMUENTSElURU1JRDp0KDI4LDI1OCk9KDI4LDI1OSk9KigyOCwyNTYp
AF9JVEVNSURMSVNUOlR0KDI4LDI2MCk9czRta2lkOigyOCwyNTYpLDAsMzI7X19hczo6KDI4
LDI2MSk9IyMoMjgsMjYyKT0mKDI4LDI2MCk7OlJDMTFfSVRFTUlETElTVDsyQS47X0lURU1J
RExJU1Q6OigyOCwyNjMpPSMjKDI4LDI2NCk9KigyOCwyNjApOzpSQzExX0lURU1JRExJU1Q7
MkEuKDI4LDI2NSk9IyMoMjgsMjY0KTs6OzJBLjs7AElURU1JRExJU1Q6dCgyOCwyNjYpPSgy
OCwyNjApAExQSVRFTUlETElTVDp0KDI4LDI2Nyk9KDI4LDI2NCkATFBDSVRFTUlETElTVDp0
KDI4LDI2OCk9KDI4LDI2OSk9KigyOCwyNjYpAF9icm93c2VpbmZvOlR0KDI4LDI3MCk9czMy
aHduZE93bmVyOigyNSw2MSksMCwzMjtwaWRsUm9vdDooMjgsMjY4KSwzMiwzMjtwc3pEaXNw
bGF5TmFtZTooMjUsOTQpLDY0LDMyO2xwc3pUaXRsZTooMjUsODEpLDk2LDMyO3VsRmxhZ3M6
KDI1LDE1MCksMTI4LDMyO2xwZm46KDI1LDE3MyksMTYwLDMyO2xQYXJhbTooMjUsNzApLDE5
MiwzMjtpSW1hZ2U6KDAsMSksMjI0LDMyO19fYXM6OigyOCwyNzEpPSMjKDI4LDI3Mik9Jigy
OCwyNzApOzpSQzExX2Jyb3dzZWluZm87MkEuO19icm93c2VpbmZvOjooMjgsMjczKT0jIygy
OCwyNzQpPSooMjgsMjcwKTs6UkMxMV9icm93c2VpbmZvOzJBLigyOCwyNzUpPSMjKDI4LDI3
NCk7OjsyQS47OwBCUk9XU0VJTkZPOnQoMjgsMjc2KT0oMjgsMjcwKQBQQlJPV1NFSU5GTzp0
KDI4LDI3Nyk9KDI4LDI3NCkATFBCUk9XU0VJTkZPOnQoMjgsMjc4KT0oMjgsMjc0KQBfRklM
RVRJTUU6VHQoMjgsMjc5KT1zOGR3TG93RGF0ZVRpbWU6KDI1LDE0KSwwLDMyO2R3SGlnaERh
dGVUaW1lOigyNSwxNCksMzIsMzI7X19hczo6KDI4LDI4MCk9IyMoMjgsMjgxKT0mKDI4LDI3
OSk7OlJDOV9GSUxFVElNRTsyQS47X0ZJTEVUSU1FOjooMjgsMjgyKT0jIygyOCwyODMpPSoo
MjgsMjc5KTs6UkM5X0ZJTEVUSU1FOzJBLigyOCwyODQpPSMjKDI4LDI4Myk7OjsyQS47OwBG
SUxFVElNRTp0KDI4LDI4NSk9KDI4LDI3OSkATFBGSUxFVElNRTp0KDI4LDI4Nik9KDI4LDI4
MykAUEZJTEVUSU1FOnQoMjgsMjg3KT0oMjgsMjgzKQBfQllfSEFORExFX0ZJTEVfSU5GT1JN
QVRJT046VHQoMjgsMjg4KT1zNTJkd0ZpbGVBdHRyaWJ1dGVzOigyNSwxNCksMCwzMjtmdENy
ZWF0aW9uVGltZTooMjgsMjg1KSwzMiw2NDtmdExhc3RBY2Nlc3NUaW1lOigyOCwyODUpLDk2
LDY0O2Z0TGFzdFdyaXRlVGltZTooMjgsMjg1KSwxNjAsNjQ7ZHdWb2x1bWVTZXJpYWxOdW1i
ZXI6KDI1LDE0KSwyMjQsMzI7bkZpbGVTaXplSGlnaDooMjUsMTQpLDI1NiwzMjtuRmlsZVNp
emVMb3c6KDI1LDE0KSwyODgsMzI7bk51bWJlck9mTGlua3M6KDI1LDE0KSwzMjAsMzI7bkZp
bGVJbmRleEhpZ2g6KDI1LDE0KSwzNTIsMzI7bkZpbGVJbmRleExvdzooMjUsMTQpLDM4NCwz
MjtfX2FzOjooMjgsMjg5KT0jIygyOCwyOTApPSYoMjgsMjg4KTs6UkMyN19CWV9IQU5ETEVf
RklMRV9JTkZPUk1BVElPTjsyQS47X0JZX0hBTkRMRV9GSUxFX0lORk9STUFUSU9OOjooMjgs
MjkxKT0jIygyOCwyOTIpPSooMjgsMjg4KTs6UkMyN19CWV9IQU5ETEVfRklMRV9JTkZPUk1B
VElPTjsyQS4oMjgsMjkzKT0jIygyOCwyOTIpOzo7MkEuOzsAQllfSEFORExFX0ZJTEVfSU5G
T1JNQVRJT046dCgyOCwyOTQpPSgyOCwyODgpAExQQllfSEFORExFX0ZJTEVfSU5GT1JNQVRJ
T046dCgyOCwyOTUpPSgyOCwyOTIpAF9GSVhFRDpUdCgyOCwyOTYpPXM0ZnJhY3Q6KDI1LDE1
MyksMCwxNjt2YWx1ZTooMCw4KSwxNiwxNjtfX2FzOjooMjgsMjk3KT0jIygyOCwyOTgpPSYo
MjgsMjk2KTs6UkM2X0ZJWEVEOzJBLjtfRklYRUQ6OigyOCwyOTkpPSMjKDI4LDMwMCk9Kigy
OCwyOTYpOzpSQzZfRklYRUQ7MkEuKDI4LDMwMSk9IyMoMjgsMzAwKTs6OzJBLjs7AEZJWEVE
OnQoMjgsMzAyKT0oMjgsMjk2KQB0YWdQT0lOVDpUdCgyOCwzMDMpPXM4eDooMjUsMTMpLDAs
MzI7eTooMjUsMTMpLDMyLDMyO19fYXM6OigyOCwzMDQpPSMjKDI4LDMwNSk9JigyOCwzMDMp
OzpSQzh0YWdQT0lOVDsyQS47dGFnUE9JTlQ6OigyOCwzMDYpPSMjKDI4LDMwNyk9KigyOCwz
MDMpOzpSQzh0YWdQT0lOVDsyQS4oMjgsMzA4KT0jIygyOCwzMDcpOzo7MkEuOzsAUE9JTlQ6
dCgyOCwzMDkpPSgyOCwzMDMpAExQUE9JTlQ6dCgyOCwzMTApPSgyOCwzMDcpAFBQT0lOVDp0
KDI4LDMxMSk9KDI4LDMwNykAdGFnUE9JTlRGWDpUdCgyOCwzMTIpPXM4eDooMjgsMzAyKSww
LDMyO3k6KDI4LDMwMiksMzIsMzI7X19hczo6KDI4LDMxMyk9IyMoMjgsMzE0KT0mKDI4LDMx
Mik7OlJDMTB0YWdQT0lOVEZYOzJBLjt0YWdQT0lOVEZYOjooMjgsMzE1KT0jIygyOCwzMTYp
PSooMjgsMzEyKTs6UkMxMHRhZ1BPSU5URlg7MkEuKDI4LDMxNyk9IyMoMjgsMzE2KTs6OzJB
Ljs7AFBPSU5URlg6dCgyOCwzMTgpPSgyOCwzMTIpAF9QT0lOVEw6VHQoMjgsMzE5KT1zOHg6
KDI1LDEzKSwwLDMyO3k6KDI1LDEzKSwzMiwzMjtfX2FzOjooMjgsMzIwKT0jIygyOCwzMjEp
PSYoMjgsMzE5KTs6UkM3X1BPSU5UTDsyQS47X1BPSU5UTDo6KDI4LDMyMik9IyMoMjgsMzIz
KT0qKDI4LDMxOSk7OlJDN19QT0lOVEw7MkEuKDI4LDMyNCk9IyMoMjgsMzIzKTs6OzJBLjs7
AFBPSU5UTDp0KDI4LDMyNSk9KDI4LDMxOSkAdGFnUE9JTlRTOlR0KDI4LDMyNik9czR4Oigy
NSwxMiksMCwxNjt5OigyNSwxMiksMTYsMTY7X19hczo6KDI4LDMyNyk9IyMoMjgsMzI4KT0m
KDI4LDMyNik7OlJDOXRhZ1BPSU5UUzsyQS47dGFnUE9JTlRTOjooMjgsMzI5KT0jIygyOCwz
MzApPSooMjgsMzI2KTs6UkM5dGFnUE9JTlRTOzJBLigyOCwzMzEpPSMjKDI4LDMzMCk7Ojsy
QS47OwBQT0lOVFM6dCgyOCwzMzIpPSgyOCwzMjYpAF90YWdDQU5ESURBVEVGT1JNOlR0KDI4
LDMzMyk9czMyZHdJbmRleDooMjUsMTQpLDAsMzI7ZHdTdHlsZTooMjUsMTQpLDMyLDMyO3B0
Q3VycmVudFBvczooMjgsMzA5KSw2NCw2NDtyY0FyZWE6KDI4LDExMyksMTI4LDEyODtfX2Fz
OjooMjgsMzM0KT0jIygyOCwzMzUpPSYoMjgsMzMzKTs6UkMxN190YWdDQU5ESURBVEVGT1JN
OzJBLjtfdGFnQ0FORElEQVRFRk9STTo6KDI4LDMzNik9IyMoMjgsMzM3KT0qKDI4LDMzMyk7
OlJDMTdfdGFnQ0FORElEQVRFRk9STTsyQS4oMjgsMzM4KT0jIygyOCwzMzcpOzo7MkEuOzsA
Q0FORElEQVRFRk9STTp0KDI4LDMzOSk9KDI4LDMzMykATFBDQU5ESURBVEVGT1JNOnQoMjgs
MzQwKT0oMjgsMzM3KQBfdGFnQ0FORElEQVRFTElTVDpUdCgyOCwzNDEpPXMyOGR3U2l6ZToo
MjUsMTQpLDAsMzI7ZHdTdHlsZTooMjUsMTQpLDMyLDMyO2R3Q291bnQ6KDI1LDE0KSw2NCwz
Mjtkd1NlbGVjdGlvbjooMjUsMTQpLDk2LDMyO2R3UGFnZVN0YXJ0OigyNSwxNCksMTI4LDMy
O2R3UGFnZVNpemU6KDI1LDE0KSwxNjAsMzI7ZHdPZmZzZXQ6KDI4LDM0Mik9YXIoMCwxKTsw
OzA7KDAsNCksMTkyLDMyO19fYXM6OigyOCwzNDMpPSMjKDI4LDM0NCk9JigyOCwzNDEpOzpS
QzE3X3RhZ0NBTkRJREFURUxJU1Q7MkEuO190YWdDQU5ESURBVEVMSVNUOjooMjgsMzQ1KT0j
IygyOCwzNDYpPSooMjgsMzQxKTs6UkMxN190YWdDQU5ESURBVEVMSVNUOzJBLigyOCwzNDcp
PSMjKDI4LDM0Nik7OjsyQS47OwBDQU5ESURBVEVMSVNUOnQoMjgsMzQ4KT0oMjgsMzQxKQBM
UENBTkRJREFURUxJU1Q6dCgyOCwzNDkpPSgyOCwzNDYpAHRhZ0NSRUFURVNUUlVDVDpUdCgy
OCwzNTApPXM0OGxwQ3JlYXRlUGFyYW1zOigyNSw5OCksMCwzMjtoSW5zdGFuY2U6KDI1LDQz
KSwzMiwzMjtoTWVudTooMjUsNDkpLDY0LDMyO2h3bmRQYXJlbnQ6KDI1LDYxKSw5NiwzMjtj
eTooMCwxKSwxMjgsMzI7Y3g6KDAsMSksMTYwLDMyO3k6KDAsMSksMTkyLDMyO3g6KDAsMSks
MjI0LDMyO3N0eWxlOigyNSwxMyksMjU2LDMyO2xwc3pOYW1lOigyNSw4MyksMjg4LDMyO2xw
c3pDbGFzczooMjUsODMpLDMyMCwzMjtkd0V4U3R5bGU6KDI1LDE0KSwzNTIsMzI7X19hczo6
KDI4LDM1MSk9IyMoMjgsMzUyKT0mKDI4LDM1MCk7OlJDMTV0YWdDUkVBVEVTVFJVQ1Q7MkEu
O3RhZ0NSRUFURVNUUlVDVDo6KDI4LDM1Myk9IyMoMjgsMzU0KT0qKDI4LDM1MCk7OlJDMTV0
YWdDUkVBVEVTVFJVQ1Q7MkEuKDI4LDM1NSk9IyMoMjgsMzU0KTs6OzJBLjs7AENSRUFURVNU
UlVDVDp0KDI4LDM1Nik9KDI4LDM1MCkATFBDUkVBVEVTVFJVQ1Q6dCgyOCwzNTcpPSgyOCwz
NTQpAHRhZ0NCVF9DUkVBVEVXTkQ6VHQoMjgsMzU4KT1zOGxwY3M6KDI4LDM1NyksMCwzMjto
d25kSW5zZXJ0QWZ0ZXI6KDI1LDYxKSwzMiwzMjtfX2FzOjooMjgsMzU5KT0jIygyOCwzNjAp
PSYoMjgsMzU4KTs6UkMxNnRhZ0NCVF9DUkVBVEVXTkQ7MkEuO3RhZ0NCVF9DUkVBVEVXTkQ6
OigyOCwzNjEpPSMjKDI4LDM2Mik9KigyOCwzNTgpOzpSQzE2dGFnQ0JUX0NSRUFURVdORDsy
QS4oMjgsMzYzKT0jIygyOCwzNjIpOzo7MkEuOzsAQ0JUX0NSRUFURVdORDp0KDI4LDM2NCk9
KDI4LDM1OCkAdGFnQ0JUQUNUSVZBVEVTVFJVQ1Q6VHQoMjgsMzY1KT1zOGZNb3VzZTooMjUs
MiksMCwzMjtoV25kQWN0aXZlOigyNSw2MSksMzIsMzI7X19hczo6KDI4LDM2Nik9IyMoMjgs
MzY3KT0mKDI4LDM2NSk7OlJDMjB0YWdDQlRBQ1RJVkFURVNUUlVDVDsyQS47dGFnQ0JUQUNU
SVZBVEVTVFJVQ1Q6OigyOCwzNjgpPSMjKDI4LDM2OSk9KigyOCwzNjUpOzpSQzIwdGFnQ0JU
QUNUSVZBVEVTVFJVQ1Q7MkEuKDI4LDM3MCk9IyMoMjgsMzY5KTs6OzJBLjs7AENCVEFDVElW
QVRFU1RSVUNUOnQoMjgsMzcxKT0oMjgsMzY1KQBfQ0hBUl9JTkZPOlR0KDI4LDM3Mik9czRD
aGFyOigyOCwzNzMpPXUyVW5pY29kZUNoYXI6KDI1LDEwKSwwLDE2O0FzY2lpQ2hhcjooMjUs
MTEpLDAsODtfX2FzOjooMjgsMzc0KT0jKDI4LDM3MyksKDI4LDM3NSk9JigyOCwzNzMpLCgy
OCwzNzYpPSooMjgsMzczKSwoMjgsMzc3KT0mKDI4LDM3MyksKDAsMjApOzpfX2FzX19RMjEw
X0NIQVJfSU5GTzMkXzFSQ1EyMTBfQ0hBUl9JTkZPMyRfMTsyQS47JF8xOjooMjgsMzc4KT0j
KDI4LDM3MyksKDI4LDM3NiksKDI4LDM3NiksKDI4LDM3NyksKDAsMjApOzpfX1EyMTBfQ0hB
Ul9JTkZPMyRfMVJDUTIxMF9DSEFSX0lORk8zJF8xOzJBLigyOCwzNzkpPSMoMjgsMzczKSwo
MjgsMzc2KSwoMjgsMzc2KSwoMCwyMCk7Ol9fUTIxMF9DSEFSX0lORk8zJF8xOzJBLjs7LDAs
MTY7QXR0cmlidXRlczooMjUsMTUzKSwxNiwxNjtfX2FzOjooMjgsMzgwKT0jIygyOCwzODEp
PSYoMjgsMzcyKTs6UkMxMF9DSEFSX0lORk87MkEuO19DSEFSX0lORk86OigyOCwzODIpPSMj
KDI4LDM4Myk9KigyOCwzNzIpOzpSQzEwX0NIQVJfSU5GTzsyQS4oMjgsMzg0KT0jIygyOCwz
ODMpOzo7MkEuOzsAQ0hBUl9JTkZPOnQoMjgsMzg1KT0oMjgsMzcyKQBQQ0hBUl9JTkZPOnQo
MjgsMzg2KT0oMjgsMzgzKQBfY2hhcmZvcm1hdDpUdCgyOCwzODcpPXM2MGNiU2l6ZTooMjUs
MTUwKSwwLDMyO2R3TWFzazooMjUsMTQpLDMyLDMyO2R3RWZmZWN0czooMjUsMTQpLDY0LDMy
O3lIZWlnaHQ6KDI1LDEzKSw5NiwzMjt5T2Zmc2V0OigyNSwxMyksMTI4LDMyO2NyVGV4dENv
bG9yOigyNSw5KSwxNjAsMzI7YkNoYXJTZXQ6KDI1LDUpLDE5Miw4O2JQaXRjaEFuZEZhbWls
eTooMjUsNSksMjAwLDg7c3pGYWNlTmFtZTooMjgsMzg4KT1hcigwLDEpOzA7MzE7KDAsMiks
MjA4LDI1NjtfX2FzOjooMjgsMzg5KT0jIygyOCwzOTApPSYoMjgsMzg3KTs6UkMxMV9jaGFy
Zm9ybWF0OzJBLjtfY2hhcmZvcm1hdDo6KDI4LDM5MSk9IyMoMjgsMzkyKT0qKDI4LDM4Nyk7
OlJDMTFfY2hhcmZvcm1hdDsyQS4oMjgsMzkzKT0jIygyOCwzOTIpOzo7MkEuOzsAQ0hBUkZP
Uk1BVDp0KDI4LDM5NCk9KDI4LDM4NykAX2NoYXJyYW5nZTpUdCgyOCwzOTUpPXM4Y3BNaW46
KDI1LDEzKSwwLDMyO2NwTWF4OigyNSwxMyksMzIsMzI7X19hczo6KDI4LDM5Nik9IyMoMjgs
Mzk3KT0mKDI4LDM5NSk7OlJDMTBfY2hhcnJhbmdlOzJBLjtfY2hhcnJhbmdlOjooMjgsMzk4
KT0jIygyOCwzOTkpPSooMjgsMzk1KTs6UkMxMF9jaGFycmFuZ2U7MkEuKDI4LDQwMCk9IyMo
MjgsMzk5KTs6OzJBLjs7AENIQVJSQU5HRTp0KDI4LDQwMSk9KDI4LDM5NSkAdGFnQ0hBUlNF
VDpUdCgyOCw0MDIpPXMxNmFmbEJsb2NrOigyOCwyMDUpLDAsOTY7ZmxMYW5nOigyNSwxNCks
OTYsMzI7X19hczo6KDI4LDQwMyk9IyMoMjgsNDA0KT0mKDI4LDQwMik7OlJDMTB0YWdDSEFS
U0VUOzJBLjt0YWdDSEFSU0VUOjooMjgsNDA1KT0jIygyOCw0MDYpPSooMjgsNDAyKTs6UkMx
MHRhZ0NIQVJTRVQ7MkEuKDI4LDQwNyk9IyMoMjgsNDA2KTs6OzJBLjs7AENIQVJTRVQ6dCgy
OCw0MDgpPSgyOCw0MDIpAHRhZ0ZPTlRTSUdOQVRVUkU6VHQoMjgsNDA5KT1zMjRmc1VzYjoo
MjgsNDEwKT1hcigwLDEpOzA7MzsoMCw0KSwwLDEyODtmc0NzYjooMjgsNDExKT1hcigwLDEp
OzA7MTsoMCw0KSwxMjgsNjQ7X19hczo6KDI4LDQxMik9IyMoMjgsNDEzKT0mKDI4LDQwOSk7
OlJDMTZ0YWdGT05UU0lHTkFUVVJFOzJBLjt0YWdGT05UU0lHTkFUVVJFOjooMjgsNDE0KT0j
IygyOCw0MTUpPSooMjgsNDA5KTs6UkMxNnRhZ0ZPTlRTSUdOQVRVUkU7MkEuKDI4LDQxNik9
IyMoMjgsNDE1KTs6OzJBLjs7AEZPTlRTSUdOQVRVUkU6dCgyOCw0MTcpPSgyOCw0MDkpAExQ
Rk9OVFNJR05BVFVSRTp0KDI4LDQxOCk9KDI4LDQxNSkAQ0hBUlNFVElORk86dCgyOCw0MTkp
PXMzMmNpQ2hhcnNldDooMjUsMTUwKSwwLDMyO2NpQUNQOigyNSwxNTApLDMyLDMyO2ZzOigy
OCw0MTcpLDY0LDE5MjtfX2FzOjooMjgsNDIwKT0jKDI4LDQxOSksKDI4LDQyMSk9JigyOCw0
MTkpLCgyOCw0MjIpPSooMjgsNDE5KSwoMjgsNDIzKT0mKDI4LDQyNCk9czMyY2lDaGFyc2V0
OigyNSwxNTApLDAsMzI7Y2lBQ1A6KDI1LDE1MCksMzIsMzI7ZnM6KDI4LDQxNyksNjQsMTky
O19fYXM6OigyOCw0MjApOl9fYXNfXzMkXzJSQzMkXzI7MkEuOyRfMjo6KDI4LDQyNSk9Iygy
OCw0MTkpLCgyOCw0MjIpLCgyOCw0MjIpLCgyOCw0MjMpLCgwLDIwKTs6X18zJF8yUkMzJF8y
OzJBLigyOCw0MjYpPSMoMjgsNDE5KSwoMjgsNDIyKSwoMjgsNDIyKSwoMCwyMCk7Ol9fMyRf
MjsyQS47OywoMCwyMCk7Ol9fYXNfXzMkXzJSQzMkXzI7MkEuOyRfMjo6KDI4LDQyNSk6X18z
JF8yUkMzJF8yOzJBLigyOCw0MjYpOl9fMyRfMjsyQS47OwBMUENIQVJTRVRJTkZPOnQoMjgs
NDI3KT0oMjgsNDIyKQBDSE9PU0VDT0xPUjp0KDI4LDQyOCk9czM2bFN0cnVjdFNpemU6KDI1
LDE0KSwwLDMyO2h3bmRPd25lcjooMjUsNjEpLDMyLDMyO2hJbnN0YW5jZTooMjUsNjEpLDY0
LDMyO3JnYlJlc3VsdDooMjUsOSksOTYsMzI7bHBDdXN0Q29sb3JzOigyNSw4MCksMTI4LDMy
O0ZsYWdzOigyNSwxNCksMTYwLDMyO2xDdXN0RGF0YTooMjUsNzApLDE5MiwzMjtscGZuSG9v
azooMjUsMTc2KSwyMjQsMzI7bHBUZW1wbGF0ZU5hbWU6KDI1LDgzKSwyNTYsMzI7X19hczo6
KDI4LDQyOSk9IygyOCw0MjgpLCgyOCw0MzApPSYoMjgsNDI4KSwoMjgsNDMxKT0qKDI4LDQy
OCksKDI4LDQzMik9JigyOCw0MzMpPXMzNmxTdHJ1Y3RTaXplOigyNSwxNCksMCwzMjtod25k
T3duZXI6KDI1LDYxKSwzMiwzMjtoSW5zdGFuY2U6KDI1LDYxKSw2NCwzMjtyZ2JSZXN1bHQ6
KDI1LDkpLDk2LDMyO2xwQ3VzdENvbG9yczooMjUsODApLDEyOCwzMjtGbGFnczooMjUsMTQp
LDE2MCwzMjtsQ3VzdERhdGE6KDI1LDcwKSwxOTIsMzI7bHBmbkhvb2s6KDI1LDE3NiksMjI0
LDMyO2xwVGVtcGxhdGVOYW1lOigyNSw4MyksMjU2LDMyO19fYXM6OigyOCw0MjkpOl9fYXNf
XzMkXzNSQzMkXzM7MkEuOyRfMzo6KDI4LDQzNCk9IygyOCw0MjgpLCgyOCw0MzEpLCgyOCw0
MzEpLCgyOCw0MzIpLCgwLDIwKTs6X18zJF8zUkMzJF8zOzJBLigyOCw0MzUpPSMoMjgsNDI4
KSwoMjgsNDMxKSwoMjgsNDMxKSwoMCwyMCk7Ol9fMyRfMzsyQS47OywoMCwyMCk7Ol9fYXNf
XzMkXzNSQzMkXzM7MkEuOyRfMzo6KDI4LDQzNCk6X18zJF8zUkMzJF8zOzJBLigyOCw0MzUp
Ol9fMyRfMzsyQS47OwBMUENIT09TRUNPTE9SOnQoMjgsNDM2KT0oMjgsNDMxKQB0YWdMT0dG
T05UQTpUdCgyOCw0MzcpPXM2MGxmSGVpZ2h0OigyNSwxMyksMCwzMjtsZldpZHRoOigyNSwx
MyksMzIsMzI7bGZFc2NhcGVtZW50OigyNSwxMyksNjQsMzI7bGZPcmllbnRhdGlvbjooMjUs
MTMpLDk2LDMyO2xmV2VpZ2h0OigyNSwxMyksMTI4LDMyO2xmSXRhbGljOigyNSw1KSwxNjAs
ODtsZlVuZGVybGluZTooMjUsNSksMTY4LDg7bGZTdHJpa2VPdXQ6KDI1LDUpLDE3Niw4O2xm
Q2hhclNldDooMjUsNSksMTg0LDg7bGZPdXRQcmVjaXNpb246KDI1LDUpLDE5Miw4O2xmQ2xp
cFByZWNpc2lvbjooMjUsNSksMjAwLDg7bGZRdWFsaXR5OigyNSw1KSwyMDgsODtsZlBpdGNo
QW5kRmFtaWx5OigyNSw1KSwyMTYsODtsZkZhY2VOYW1lOigyOCwzODgpLDIyNCwyNTY7X19h
czo6KDI4LDQzOCk9IyMoMjgsNDM5KT0mKDI4LDQzNyk7OlJDMTF0YWdMT0dGT05UQTsyQS47
dGFnTE9HRk9OVEE6OigyOCw0NDApPSMjKDI4LDQ0MSk9KigyOCw0MzcpOzpSQzExdGFnTE9H
Rk9OVEE7MkEuKDI4LDQ0Mik9IyMoMjgsNDQxKTs6OzJBLjs7AExPR0ZPTlRBOnQoMjgsNDQz
KT0oMjgsNDM3KQBMUExPR0ZPTlRBOnQoMjgsNDQ0KT0oMjgsNDQxKQBQTE9HRk9OVEE6dCgy
OCw0NDUpPSgyOCw0NDEpAHRhZ0xPR0ZPTlRXOlR0KDI4LDQ0Nik9czkybGZIZWlnaHQ6KDI1
LDEzKSwwLDMyO2xmV2lkdGg6KDI1LDEzKSwzMiwzMjtsZkVzY2FwZW1lbnQ6KDI1LDEzKSw2
NCwzMjtsZk9yaWVudGF0aW9uOigyNSwxMyksOTYsMzI7bGZXZWlnaHQ6KDI1LDEzKSwxMjgs
MzI7bGZJdGFsaWM6KDI1LDUpLDE2MCw4O2xmVW5kZXJsaW5lOigyNSw1KSwxNjgsODtsZlN0
cmlrZU91dDooMjUsNSksMTc2LDg7bGZDaGFyU2V0OigyNSw1KSwxODQsODtsZk91dFByZWNp
c2lvbjooMjUsNSksMTkyLDg7bGZDbGlwUHJlY2lzaW9uOigyNSw1KSwyMDAsODtsZlF1YWxp
dHk6KDI1LDUpLDIwOCw4O2xmUGl0Y2hBbmRGYW1pbHk6KDI1LDUpLDIxNiw4O2xmRmFjZU5h
bWU6KDI4LDQ0Nyk9YXIoMCwxKTswOzMxOygwLDIxKSwyMjQsNTEyO19fYXM6OigyOCw0NDgp
PSMjKDI4LDQ0OSk9JigyOCw0NDYpOzpSQzExdGFnTE9HRk9OVFc7MkEuO3RhZ0xPR0ZPTlRX
OjooMjgsNDUwKT0jIygyOCw0NTEpPSooMjgsNDQ2KTs6UkMxMXRhZ0xPR0ZPTlRXOzJBLigy
OCw0NTIpPSMjKDI4LDQ1MSk7OjsyQS47OwBMT0dGT05UVzp0KDI4LDQ1Myk9KDI4LDQ0NikA
TFBMT0dGT05UVzp0KDI4LDQ1NCk9KDI4LDQ1MSkAUExPR0ZPTlRXOnQoMjgsNDU1KT0oMjgs
NDUxKQBMT0dGT05UOnQoMjgsNDU2KT0oMjgsNDQzKQBQTE9HRk9OVDp0KDI4LDQ1Nyk9KDI4
LDQ1OCk9KigyOCw0NTYpAE5QTE9HRk9OVDp0KDI4LDQ1OSk9KDI4LDQ1OCkATFBMT0dGT05U
OnQoMjgsNDYwKT0oMjgsNDU4KQBDSE9PU0VGT05UOnQoMjgsNDYxKT1zNjBsU3RydWN0U2l6
ZTooMjUsMTQpLDAsMzI7aHduZE93bmVyOigyNSw2MSksMzIsMzI7aERDOigyNSwyOCksNjQs
MzI7bHBMb2dGb250OigyOCw0NjApLDk2LDMyO2lQb2ludFNpemU6KDI1LDYyKSwxMjgsMzI7
RmxhZ3M6KDI1LDE0KSwxNjAsMzI7cmdiQ29sb3JzOigyNSwxNCksMTkyLDMyO2xDdXN0RGF0
YTooMjUsNzApLDIyNCwzMjtscGZuSG9vazooMjUsMTc5KSwyNTYsMzI7bHBUZW1wbGF0ZU5h
bWU6KDI1LDgzKSwyODgsMzI7aEluc3RhbmNlOigyNSw0MyksMzIwLDMyO2xwc3pTdHlsZToo
MjUsOTYpLDM1MiwzMjtuRm9udFR5cGU6KDI1LDE1MyksMzg0LDE2O19fX01JU1NJTkdfQUxJ
R05NRU5UX186KDI1LDE1MyksNDAwLDE2O25TaXplTWluOigyNSw2MiksNDE2LDMyO25TaXpl
TWF4OigyNSw2MiksNDQ4LDMyO19fYXM6OigyOCw0NjIpPSMoMjgsNDYxKSwoMjgsNDYzKT0m
KDI4LDQ2MSksKDI4LDQ2NCk9KigyOCw0NjEpLCgyOCw0NjUpPSYoMjgsNDY2KT1zNjBsU3Ry
dWN0U2l6ZTooMjUsMTQpLDAsMzI7aHduZE93bmVyOigyNSw2MSksMzIsMzI7aERDOigyNSwy
OCksNjQsMzI7bHBMb2dGb250OigyOCw0NjApLDk2LDMyO2lQb2ludFNpemU6KDI1LDYyKSwx
MjgsMzI7RmxhZ3M6KDI1LDE0KSwxNjAsMzI7cmdiQ29sb3JzOigyNSwxNCksMTkyLDMyO2xD
dXN0RGF0YTooMjUsNzApLDIyNCwzMjtscGZuSG9vazooMjUsMTc5KSwyNTYsMzI7bHBUZW1w
bGF0ZU5hbWU6KDI1LDgzKSwyODgsMzI7aEluc3RhbmNlOigyNSw0MyksMzIwLDMyO2xwc3pT
dHlsZTooMjUsOTYpLDM1MiwzMjtuRm9udFR5cGU6KDI1LDE1MyksMzg0LDE2O19fX01JU1NJ
TkdfQUxJR05NRU5UX186KDI1LDE1MyksNDAwLDE2O25TaXplTWluOigyNSw2MiksNDE2LDMy
O25TaXplTWF4OigyNSw2MiksNDQ4LDMyO19fYXM6OigyOCw0NjIpOl9fYXNfXzMkXzRSQzMk
XzQ7MkEuOyRfNDo6KDI4LDQ2Nyk9IygyOCw0NjEpLCgyOCw0NjQpLCgyOCw0NjQpLCgyOCw0
NjUpLCgwLDIwKTs6X18zJF80UkMzJF80OzJBLigyOCw0NjgpPSMoMjgsNDYxKSwoMjgsNDY0
KSwoMjgsNDY0KSwoMCwyMCk7Ol9fMyRfNDsyQS47OywoMCwyMCk7Ol9fYXNfXzMkXzRSQzMk
XzQ7MkEuOyRfNDo6KDI4LDQ2Nyk6X18zJF80UkMzJF80OzJBLigyOCw0NjgpOl9fMyRfNDsy
QS47OwBMUENIT09TRUZPTlQ6dCgyOCw0NjkpPSgyOCw0NjQpAF9JREE6VHQoMjgsNDcwKT1z
OGNpZGw6KDI1LDE1MCksMCwzMjthb2Zmc2V0OigyOCwzNDIpLDMyLDMyO19fYXM6OigyOCw0
NzEpPSMjKDI4LDQ3Mik9JigyOCw0NzApOzpSQzRfSURBOzJBLjtfSURBOjooMjgsNDczKT0j
IygyOCw0NzQpPSooMjgsNDcwKTs6UkM0X0lEQTsyQS4oMjgsNDc1KT0jIygyOCw0NzQpOzo7
MkEuOzsAQ0lEQTp0KDI4LDQ3Nik9KDI4LDQ3MCkATFBJREE6dCgyOCw0NzcpPSgyOCw0NzQp
AHRhZ0NMSUVOVENSRUFURVNUUlVDVDpUdCgyOCw0NzgpPXM4aFdpbmRvd01lbnU6KDI1LDE5
KSwwLDMyO2lkRmlyc3RDaGlsZDooMjUsMTUwKSwzMiwzMjtfX2FzOjooMjgsNDc5KT0jIygy
OCw0ODApPSYoMjgsNDc4KTs6UkMyMXRhZ0NMSUVOVENSRUFURVNUUlVDVDsyQS47dGFnQ0xJ
RU5UQ1JFQVRFU1RSVUNUOjooMjgsNDgxKT0jIygyOCw0ODIpPSooMjgsNDc4KTs6UkMyMXRh
Z0NMSUVOVENSRUFURVNUUlVDVDsyQS4oMjgsNDgzKT0jIygyOCw0ODIpOzo7MkEuOzsAQ0xJ
RU5UQ1JFQVRFU1RSVUNUOnQoMjgsNDg0KT0oMjgsNDc4KQBMUENMSUVOVENSRUFURVNUUlVD
VDp0KDI4LDQ4NSk9KDI4LDQ4Nik9KigyOCw0ODQpAF9DTUludm9rZUNvbW1hbmRJbmZvOlR0
KDI4LDQ4Nyk9czM2Y2JTaXplOigyNSwxNCksMCwzMjtmTWFzazooMjUsMTQpLDMyLDMyO2h3
bmQ6KDI1LDYxKSw2NCwzMjtscFZlcmI6KDI1LDgxKSw5NiwzMjtscFBhcmFtZXRlcnM6KDI1
LDgxKSwxMjgsMzI7bHBEaXJlY3Rvcnk6KDI1LDgxKSwxNjAsMzI7blNob3c6KDAsMSksMTky
LDMyO2R3SG90S2V5OigyNSwxNCksMjI0LDMyO2hJY29uOigyNSwxOSksMjU2LDMyO19fYXM6
OigyOCw0ODgpPSMjKDI4LDQ4OSk9JigyOCw0ODcpOzpSQzIwX0NNSW52b2tlQ29tbWFuZElu
Zm87MkEuO19DTUludm9rZUNvbW1hbmRJbmZvOjooMjgsNDkwKT0jIygyOCw0OTEpPSooMjgs
NDg3KTs6UkMyMF9DTUludm9rZUNvbW1hbmRJbmZvOzJBLigyOCw0OTIpPSMjKDI4LDQ5MSk7
OjsyQS47OwBDTUlOVk9LRUNPTU1BTkRJTkZPOnQoMjgsNDkzKT0oMjgsNDg3KQBMUENNSU5W
T0tFQ09NTUFORElORk86dCgyOCw0OTQpPSgyOCw0OTEpAHRhZ0NPTE9SQURKVVNUTUVOVDpU
dCgyOCw0OTUpPXMyNGNhU2l6ZTooMjUsMTUzKSwwLDE2O2NhRmxhZ3M6KDI1LDE1MyksMTYs
MTY7Y2FJbGx1bWluYW50SW5kZXg6KDI1LDE1MyksMzIsMTY7Y2FSZWRHYW1tYTooMjUsMTUz
KSw0OCwxNjtjYUdyZWVuR2FtbWE6KDI1LDE1MyksNjQsMTY7Y2FCbHVlR2FtbWE6KDI1LDE1
MyksODAsMTY7Y2FSZWZlcmVuY2VCbGFjazooMjUsMTUzKSw5NiwxNjtjYVJlZmVyZW5jZVdo
aXRlOigyNSwxNTMpLDExMiwxNjtjYUNvbnRyYXN0OigyNSwxMiksMTI4LDE2O2NhQnJpZ2h0
bmVzczooMjUsMTIpLDE0NCwxNjtjYUNvbG9yZnVsbmVzczooMjUsMTIpLDE2MCwxNjtjYVJl
ZEdyZWVuVGludDooMjUsMTIpLDE3NiwxNjtfX2FzOjooMjgsNDk2KT0jIygyOCw0OTcpPSYo
MjgsNDk1KTs6UkMxOHRhZ0NPTE9SQURKVVNUTUVOVDsyQS47dGFnQ09MT1JBREpVU1RNRU5U
OjooMjgsNDk4KT0jIygyOCw0OTkpPSooMjgsNDk1KTs6UkMxOHRhZ0NPTE9SQURKVVNUTUVO
VDsyQS4oMjgsNTAwKT0jIygyOCw0OTkpOzo7MkEuOzsAQ09MT1JBREpVU1RNRU5UOnQoMjgs
NTAxKT0oMjgsNDk1KQBMUENPTE9SQURKVVNUTUVOVDp0KDI4LDUwMik9KDI4LDQ5OSkAX0NP
TE9STUFQOlR0KDI4LDUwMyk9czhmcm9tOigyNSw5KSwwLDMyO3RvOigyNSw5KSwzMiwzMjtf
X2FzOjooMjgsNTA0KT0jIygyOCw1MDUpPSYoMjgsNTAzKTs6UkM5X0NPTE9STUFQOzJBLjtf
Q09MT1JNQVA6OigyOCw1MDYpPSMjKDI4LDUwNyk9KigyOCw1MDMpOzpSQzlfQ09MT1JNQVA7
MkEuKDI4LDUwOCk9IyMoMjgsNTA3KTs6OzJBLjs7AENPTE9STUFQOnQoMjgsNTA5KT0oMjgs
NTAzKQBMUENPTE9STUFQOnQoMjgsNTEwKT0oMjgsNTA3KQBfRENCOlR0KDI4LDUxMSk9czI4
RENCbGVuZ3RoOigyNSwxNCksMCwzMjtCYXVkUmF0ZTooMjUsMTQpLDMyLDMyO2ZCaW5hcnk6
KDI1LDE0KSw2NCwxO2ZQYXJpdHk6KDI1LDE0KSw2NSwxO2ZPdXR4Q3RzRmxvdzooMjUsMTQp
LDY2LDE7Zk91dHhEc3JGbG93OigyNSwxNCksNjcsMTtmRHRyQ29udHJvbDooMjUsMTQpLDY4
LDI7ZkRzclNlbnNpdGl2aXR5OigyNSwxNCksNzAsMTtmVFhDb250aW51ZU9uWG9mZjooMjUs
MTQpLDcxLDE7Zk91dFg6KDI1LDE0KSw3MiwxO2ZJblg6KDI1LDE0KSw3MywxO2ZFcnJvckNo
YXI6KDI1LDE0KSw3NCwxO2ZOdWxsOigyNSwxNCksNzUsMTtmUnRzQ29udHJvbDooMjUsMTQp
LDc2LDI7ZkFib3J0T25FcnJvcjooMjUsMTQpLDc4LDE7ZkR1bW15MjooMjUsMTQpLDc5LDE3
O3dSZXNlcnZlZDooMjUsMTUzKSw5NiwxNjtYb25MaW06KDI1LDE1MyksMTEyLDE2O1hvZmZM
aW06KDI1LDE1MyksMTI4LDE2O0J5dGVTaXplOigyNSw1KSwxNDQsODtQYXJpdHk6KDI1LDUp
LDE1Miw4O1N0b3BCaXRzOigyNSw1KSwxNjAsODtYb25DaGFyOigwLDIpLDE2OCw4O1hvZmZD
aGFyOigwLDIpLDE3Niw4O0Vycm9yQ2hhcjooMCwyKSwxODQsODtFb2ZDaGFyOigwLDIpLDE5
Miw4O0V2dENoYXI6KDAsMiksMjAwLDg7d1Jlc2VydmVkMTooMjUsMTUzKSwyMDgsMTY7X19h
czo6KDI4LDUxMik9IyMoMjgsNTEzKT0mKDI4LDUxMSk7OlJDNF9EQ0I7MkEuO19EQ0I6Oigy
OCw1MTQpPSMjKDI4LDUxNSk9KigyOCw1MTEpOzpSQzRfRENCOzJBLigyOCw1MTYpPSMjKDI4
LDUxNSk7OjsyQS47OwBEQ0I6dCgyOCw1MTcpPSgyOCw1MTEpAExQRENCOnQoMjgsNTE4KT0o
MjgsNTE1KQBfQ09NTV9DT05GSUc6VHQoMjgsNTE5KT1zNTJkd1NpemU6KDI1LDE0KSwwLDMy
O3dWZXJzaW9uOigyNSwxNTMpLDMyLDE2O3dSZXNlcnZlZDooMjUsMTUzKSw0OCwxNjtkY2I6
KDI4LDUxNyksNjQsMjI0O2R3UHJvdmlkZXJTdWJUeXBlOigyNSwxNCksMjg4LDMyO2R3UHJv
dmlkZXJPZmZzZXQ6KDI1LDE0KSwzMjAsMzI7ZHdQcm92aWRlclNpemU6KDI1LDE0KSwzNTIs
MzI7d2NQcm92aWRlckRhdGE6KDI4LDUyMCk9YXIoMCwxKTswOzA7KDAsMjEpLDM4NCwxNjtf
X2FzOjooMjgsNTIxKT0jIygyOCw1MjIpPSYoMjgsNTE5KTs6UkMxMl9DT01NX0NPTkZJRzsy
QS47X0NPTU1fQ09ORklHOjooMjgsNTIzKT0jIygyOCw1MjQpPSooMjgsNTE5KTs6UkMxMl9D
T01NX0NPTkZJRzsyQS4oMjgsNTI1KT0jIygyOCw1MjQpOzo7MkEuOzsAQ09NTUNPTkZJRzp0
KDI4LDUyNik9KDI4LDUxOSkATFBDT01NQ09ORklHOnQoMjgsNTI3KT0oMjgsNTI0KQBfQ09N
TVBST1A6VHQoMjgsNTI4KT1zNjR3UGFja2V0TGVuZ3RoOigyNSwxNTMpLDAsMTY7d1BhY2tl
dFZlcnNpb246KDI1LDE1MyksMTYsMTY7ZHdTZXJ2aWNlTWFzazooMjUsMTQpLDMyLDMyO2R3
UmVzZXJ2ZWQxOigyNSwxNCksNjQsMzI7ZHdNYXhUeFF1ZXVlOigyNSwxNCksOTYsMzI7ZHdN
YXhSeFF1ZXVlOigyNSwxNCksMTI4LDMyO2R3TWF4QmF1ZDooMjUsMTQpLDE2MCwzMjtkd1By
b3ZTdWJUeXBlOigyNSwxNCksMTkyLDMyO2R3UHJvdkNhcGFiaWxpdGllczooMjUsMTQpLDIy
NCwzMjtkd1NldHRhYmxlUGFyYW1zOigyNSwxNCksMjU2LDMyO2R3U2V0dGFibGVCYXVkOigy
NSwxNCksMjg4LDMyO3dTZXR0YWJsZURhdGE6KDI1LDE1MyksMzIwLDE2O3dTZXR0YWJsZVN0
b3BQYXJpdHk6KDI1LDE1MyksMzM2LDE2O2R3Q3VycmVudFR4UXVldWU6KDI1LDE0KSwzNTIs
MzI7ZHdDdXJyZW50UnhRdWV1ZTooMjUsMTQpLDM4NCwzMjtkd1Byb3ZTcGVjMTooMjUsMTQp
LDQxNiwzMjtkd1Byb3ZTcGVjMjooMjUsMTQpLDQ0OCwzMjt3Y1Byb3ZDaGFyOigyOCw1MjAp
LDQ4MCwxNjtfX2FzOjooMjgsNTI5KT0jIygyOCw1MzApPSYoMjgsNTI4KTs6UkM5X0NPTU1Q
Uk9QOzJBLjtfQ09NTVBST1A6OigyOCw1MzEpPSMjKDI4LDUzMik9KigyOCw1MjgpOzpSQzlf
Q09NTVBST1A7MkEuKDI4LDUzMyk9IyMoMjgsNTMyKTs6OzJBLjs7AENPTU1QUk9QOnQoMjgs
NTM0KT0oMjgsNTI4KQBMUENPTU1QUk9QOnQoMjgsNTM1KT0oMjgsNTMyKQBfQ09NTVRJTUVP
VVRTOlR0KDI4LDUzNik9czIwUmVhZEludGVydmFsVGltZW91dDooMjUsMTQpLDAsMzI7UmVh
ZFRvdGFsVGltZW91dE11bHRpcGxpZXI6KDI1LDE0KSwzMiwzMjtSZWFkVG90YWxUaW1lb3V0
Q29uc3RhbnQ6KDI1LDE0KSw2NCwzMjtXcml0ZVRvdGFsVGltZW91dE11bHRpcGxpZXI6KDI1
LDE0KSw5NiwzMjtXcml0ZVRvdGFsVGltZW91dENvbnN0YW50OigyNSwxNCksMTI4LDMyO19f
YXM6OigyOCw1MzcpPSMjKDI4LDUzOCk9JigyOCw1MzYpOzpSQzEzX0NPTU1USU1FT1VUUzsy
QS47X0NPTU1USU1FT1VUUzo6KDI4LDUzOSk9IyMoMjgsNTQwKT0qKDI4LDUzNik7OlJDMTNf
Q09NTVRJTUVPVVRTOzJBLigyOCw1NDEpPSMjKDI4LDU0MCk7OjsyQS47OwBDT01NVElNRU9V
VFM6dCgyOCw1NDIpPSgyOCw1MzYpAExQQ09NTVRJTUVPVVRTOnQoMjgsNTQzKT0oMjgsNTQw
KQB0YWdDT01QQVJFSVRFTVNUUlVDVDpUdCgyOCw1NDQpPXMyOEN0bFR5cGU6KDI1LDE1MCks
MCwzMjtDdGxJRDooMjUsMTUwKSwzMiwzMjtod25kSXRlbTooMjUsNjEpLDY0LDMyO2l0ZW1J
RDE6KDI1LDE1MCksOTYsMzI7aXRlbURhdGExOigyNSwxNCksMTI4LDMyO2l0ZW1JRDI6KDI1
LDE1MCksMTYwLDMyO2l0ZW1EYXRhMjooMjUsMTQpLDE5MiwzMjtfX2FzOjooMjgsNTQ1KT0j
IygyOCw1NDYpPSYoMjgsNTQ0KTs6UkMyMHRhZ0NPTVBBUkVJVEVNU1RSVUNUOzJBLjt0YWdD
T01QQVJFSVRFTVNUUlVDVDo6KDI4LDU0Nyk9IyMoMjgsNTQ4KT0qKDI4LDU0NCk7OlJDMjB0
YWdDT01QQVJFSVRFTVNUUlVDVDsyQS4oMjgsNTQ5KT0jIygyOCw1NDgpOzo7MkEuOzsAQ09N
UEFSRUlURU1TVFJVQ1Q6dCgyOCw1NTApPSgyOCw1NDQpAENPTVBDT0xPUjp0KDI4LDU1MSk9
czEyY3JUZXh0OigyNSw5KSwwLDMyO2NyQmFja2dyb3VuZDooMjUsOSksMzIsMzI7ZHdFZmZl
Y3RzOigyNSwxNCksNjQsMzI7X19hczo6KDI4LDU1Mik9IygyOCw1NTEpLCgyOCw1NTMpPSYo
MjgsNTUxKSwoMjgsNTU0KT0qKDI4LDU1MSksKDI4LDU1NSk9JigyOCw1NTYpPXMxMmNyVGV4
dDooMjUsOSksMCwzMjtjckJhY2tncm91bmQ6KDI1LDkpLDMyLDMyO2R3RWZmZWN0czooMjUs
MTQpLDY0LDMyO19fYXM6OigyOCw1NTIpOl9fYXNfXzMkXzVSQzMkXzU7MkEuOyRfNTo6KDI4
LDU1Nyk9IygyOCw1NTEpLCgyOCw1NTQpLCgyOCw1NTQpLCgyOCw1NTUpLCgwLDIwKTs6X18z
JF81UkMzJF81OzJBLigyOCw1NTgpPSMoMjgsNTUxKSwoMjgsNTU0KSwoMjgsNTU0KSwoMCwy
MCk7Ol9fMyRfNTsyQS47OywoMCwyMCk7Ol9fYXNfXzMkXzVSQzMkXzU7MkEuOyRfNTo6KDI4
LDU1Nyk6X18zJF81UkMzJF81OzJBLigyOCw1NTgpOl9fMyRfNTsyQS47OwBfdGFnQ09NUE9T
SVRJT05GT1JNOlR0KDI4LDU1OSk9czI4ZHdTdHlsZTooMjUsMTQpLDAsMzI7cHRDdXJyZW50
UG9zOigyOCwzMDkpLDMyLDY0O3JjQXJlYTooMjgsMTEzKSw5NiwxMjg7X19hczo6KDI4LDU2
MCk9IyMoMjgsNTYxKT0mKDI4LDU1OSk7OlJDMTlfdGFnQ09NUE9TSVRJT05GT1JNOzJBLjtf
dGFnQ09NUE9TSVRJT05GT1JNOjooMjgsNTYyKT0jIygyOCw1NjMpPSooMjgsNTU5KTs6UkMx
OV90YWdDT01QT1NJVElPTkZPUk07MkEuKDI4LDU2NCk9IyMoMjgsNTYzKTs6OzJBLjs7AENP
TVBPU0lUSU9ORk9STTp0KDI4LDU2NSk9KDI4LDU1OSkATFBDT01QT1NJVElPTkZPUk06dCgy
OCw1NjYpPSgyOCw1NjMpAF9DT01TVEFUOlR0KDI4LDU2Nyk9czEyZkN0c0hvbGQ6KDI1LDE0
KSwwLDE7ZkRzckhvbGQ6KDI1LDE0KSwxLDE7ZlJsc2RIb2xkOigyNSwxNCksMiwxO2ZYb2Zm
SG9sZDooMjUsMTQpLDMsMTtmWG9mZlNlbnQ6KDI1LDE0KSw0LDE7ZkVvZjooMjUsMTQpLDUs
MTtmVHhpbTooMjUsMTQpLDYsMTtmUmVzZXJ2ZWQ6KDI1LDE0KSw3LDI1O2NiSW5RdWU6KDI1
LDE0KSwzMiwzMjtjYk91dFF1ZTooMjUsMTQpLDY0LDMyO19fYXM6OigyOCw1NjgpPSMjKDI4
LDU2OSk9JigyOCw1NjcpOzpSQzhfQ09NU1RBVDsyQS47X0NPTVNUQVQ6OigyOCw1NzApPSMj
KDI4LDU3MSk9KigyOCw1NjcpOzpSQzhfQ09NU1RBVDsyQS4oMjgsNTcyKT0jIygyOCw1NzEp
Ozo7MkEuOzsAQ09NU1RBVDp0KDI4LDU3Myk9KDI4LDU2NykATFBDT01TVEFUOnQoMjgsNTc0
KT0oMjgsNTcxKQBfQ09OU09MRV9DVVJTT1JfSU5GTzpUdCgyOCw1NzUpPXM4ZHdTaXplOigy
NSwxNCksMCwzMjtiVmlzaWJsZTooMjUsMiksMzIsMzI7X19hczo6KDI4LDU3Nik9IyMoMjgs
NTc3KT0mKDI4LDU3NSk7OlJDMjBfQ09OU09MRV9DVVJTT1JfSU5GTzsyQS47X0NPTlNPTEVf
Q1VSU09SX0lORk86OigyOCw1NzgpPSMjKDI4LDU3OSk9KigyOCw1NzUpOzpSQzIwX0NPTlNP
TEVfQ1VSU09SX0lORk87MkEuKDI4LDU4MCk9IyMoMjgsNTc5KTs6OzJBLjs7AENPTlNPTEVf
Q1VSU09SX0lORk86dCgyOCw1ODEpPSgyOCw1NzUpAFBDT05TT0xFX0NVUlNPUl9JTkZPOnQo
MjgsNTgyKT0oMjgsNTc5KQBfQ09PUkQ6VHQoMjgsNTgzKT1zNFg6KDI1LDEyKSwwLDE2O1k6
KDI1LDEyKSwxNiwxNjtfX2FzOjooMjgsNTg0KT0jIygyOCw1ODUpPSYoMjgsNTgzKTs6UkM2
X0NPT1JEOzJBLjtfQ09PUkQ6OigyOCw1ODYpPSMjKDI4LDU4Nyk9KigyOCw1ODMpOzpSQzZf
Q09PUkQ7MkEuKDI4LDU4OCk9IyMoMjgsNTg3KTs6OzJBLjs7AENPT1JEOnQoMjgsNTg5KT0o
MjgsNTgzKQBfU01BTExfUkVDVDpUdCgyOCw1OTApPXM4TGVmdDooMjUsMTIpLDAsMTY7VG9w
OigyNSwxMiksMTYsMTY7UmlnaHQ6KDI1LDEyKSwzMiwxNjtCb3R0b206KDI1LDEyKSw0OCwx
NjtfX2FzOjooMjgsNTkxKT0jIygyOCw1OTIpPSYoMjgsNTkwKTs6UkMxMV9TTUFMTF9SRUNU
OzJBLjtfU01BTExfUkVDVDo6KDI4LDU5Myk9IyMoMjgsNTk0KT0qKDI4LDU5MCk7OlJDMTFf
U01BTExfUkVDVDsyQS4oMjgsNTk1KT0jIygyOCw1OTQpOzo7MkEuOzsAU01BTExfUkVDVDp0
KDI4LDU5Nik9KDI4LDU5MCkAUFNNQUxMX1JFQ1Q6dCgyOCw1OTcpPSgyOCw1OTQpAF9DT05T
T0xFX1NDUkVFTl9CVUZGRVJfSU5GTzpUdCgyOCw1OTgpPXMyMmR3U2l6ZTooMjgsNTg5KSww
LDMyO2R3Q3Vyc29yUG9zaXRpb246KDI4LDU4OSksMzIsMzI7d0F0dHJpYnV0ZXM6KDI1LDE1
MyksNjQsMTY7c3JXaW5kb3c6KDI4LDU5NiksODAsNjQ7ZHdNYXhpbXVtV2luZG93U2l6ZToo
MjgsNTg5KSwxNDQsMzI7X19hczo6KDI4LDU5OSk9IyMoMjgsNjAwKT0mKDI4LDU5OCk7OlJD
MjdfQ09OU09MRV9TQ1JFRU5fQlVGRkVSX0lORk87MkEuO19DT05TT0xFX1NDUkVFTl9CVUZG
RVJfSU5GTzo6KDI4LDYwMSk9IyMoMjgsNjAyKT0qKDI4LDU5OCk7OlJDMjdfQ09OU09MRV9T
Q1JFRU5fQlVGRkVSX0lORk87MkEuKDI4LDYwMyk9IyMoMjgsNjAyKTs6OzJBLjs7AENPTlNP
TEVfU0NSRUVOX0JVRkZFUl9JTkZPOnQoMjgsNjA0KT0oMjgsNTk4KQBQQ09OU09MRV9TQ1JF
RU5fQlVGRkVSX0lORk86dCgyOCw2MDUpPSgyOCw2MDIpAF9GTE9BVElOR19TQVZFX0FSRUE6
VHQoMjgsNjA2KT1zMTEyQ29udHJvbFdvcmQ6KDI1LDE0KSwwLDMyO1N0YXR1c1dvcmQ6KDI1
LDE0KSwzMiwzMjtUYWdXb3JkOigyNSwxNCksNjQsMzI7RXJyb3JPZmZzZXQ6KDI1LDE0KSw5
NiwzMjtFcnJvclNlbGVjdG9yOigyNSwxNCksMTI4LDMyO0RhdGFPZmZzZXQ6KDI1LDE0KSwx
NjAsMzI7RGF0YVNlbGVjdG9yOigyNSwxNCksMTkyLDMyO1JlZ2lzdGVyQXJlYTooMjgsNjA3
KT1hcigwLDEpOzA7Nzk7KDAsMTEpLDIyNCw2NDA7Q3IwTnB4U3RhdGU6KDI1LDE0KSw4NjQs
MzI7X19hczo6KDI4LDYwOCk9IyMoMjgsNjA5KT0mKDI4LDYwNik7OlJDMTlfRkxPQVRJTkdf
U0FWRV9BUkVBOzJBLjtfRkxPQVRJTkdfU0FWRV9BUkVBOjooMjgsNjEwKT0jIygyOCw2MTEp
PSooMjgsNjA2KTs6UkMxOV9GTE9BVElOR19TQVZFX0FSRUE7MkEuKDI4LDYxMik9IyMoMjgs
NjExKTs6OzJBLjs7AEZMT0FUSU5HX1NBVkVfQVJFQTp0KDI4LDYxMyk9KDI4LDYwNikAX0NP
TlRFWFQ6VHQoMjgsNjE0KT1zMjA0Q29udGV4dEZsYWdzOigyNSwxNCksMCwzMjtEcjA6KDI1
LDE0KSwzMiwzMjtEcjE6KDI1LDE0KSw2NCwzMjtEcjI6KDI1LDE0KSw5NiwzMjtEcjM6KDI1
LDE0KSwxMjgsMzI7RHI2OigyNSwxNCksMTYwLDMyO0RyNzooMjUsMTQpLDE5MiwzMjtGbG9h
dFNhdmU6KDI4LDYxMyksMjI0LDg5NjtTZWdHczooMjUsMTQpLDExMjAsMzI7U2VnRnM6KDI1
LDE0KSwxMTUyLDMyO1NlZ0VzOigyNSwxNCksMTE4NCwzMjtTZWdEczooMjUsMTQpLDEyMTYs
MzI7RWRpOigyNSwxNCksMTI0OCwzMjtFc2k6KDI1LDE0KSwxMjgwLDMyO0VieDooMjUsMTQp
LDEzMTIsMzI7RWR4OigyNSwxNCksMTM0NCwzMjtFY3g6KDI1LDE0KSwxMzc2LDMyO0VheDoo
MjUsMTQpLDE0MDgsMzI7RWJwOigyNSwxNCksMTQ0MCwzMjtFaXA6KDI1LDE0KSwxNDcyLDMy
O1NlZ0NzOigyNSwxNCksMTUwNCwzMjtFRmxhZ3M6KDI1LDE0KSwxNTM2LDMyO0VzcDooMjUs
MTQpLDE1NjgsMzI7U2VnU3M6KDI1LDE0KSwxNjAwLDMyO19fYXM6OigyOCw2MTUpPSMjKDI4
LDYxNik9JigyOCw2MTQpOzpSQzhfQ09OVEVYVDsyQS47X0NPTlRFWFQ6OigyOCw2MTcpPSMj
KDI4LDYxOCk9KigyOCw2MTQpOzpSQzhfQ09OVEVYVDsyQS4oMjgsNjE5KT0jIygyOCw2MTgp
Ozo7MkEuOzsAQ09OVEVYVDp0KDI4LDYyMCk9KDI4LDYxNCkAUENPTlRFWFQ6dCgyOCw2MjEp
PSgyOCw2MTgpAExQQ09OVEVYVDp0KDI4LDYyMik9KDI4LDYxOCkAX0xJU1RfRU5UUlk6VHQo
MjgsNjIzKT1zOEZsaW5rOigyOCw2MjQpPSooMjgsNjIzKSwwLDMyO0JsaW5rOigyOCw2MjQp
LDMyLDMyO19fYXM6OigyOCw2MjUpPSMjKDI4LDYyNik9JigyOCw2MjMpOzpSQzExX0xJU1Rf
RU5UUlk7MkEuO19MSVNUX0VOVFJZOjooMjgsNjI3KT0jIygyOCw2MjQpOzpSQzExX0xJU1Rf
RU5UUlk7MkEuKDI4LDYyOCk9IyMoMjgsNjI0KTs6OzJBLjs7AExJU1RfRU5UUlk6dCgyOCw2
MjkpPSgyOCw2MjMpAFBMSVNUX0VOVFJZOnQoMjgsNjMwKT0oMjgsNjI0KQBfQ1JJVElDQUxf
U0VDVElPTl9ERUJVRzpUdCgyOCw2MzEpPXM0OFR5cGU6KDI1LDE1MyksMCwxNjtDcmVhdG9y
QmFja1RyYWNlSW5kZXg6KDI1LDE1MyksMTYsMTY7Q3JpdGljYWxTZWN0aW9uOigyOCw2MzIp
PSooMjgsNjMzKT14c19DUklUSUNBTF9TRUNUSU9OOiwzMiwzMjtQcm9jZXNzTG9ja3NMaXN0
OigyOCw2MjkpLDY0LDY0O0VudHJ5Q291bnQ6KDI1LDE0KSwxMjgsMzI7Q29udGVudGlvbkNv
dW50OigyNSwxNCksMTYwLDMyO0RlcHRoOigyNSwxNCksMTkyLDMyO093bmVyQmFja1RyYWNl
OigyOCw2MzQpPWFyKDAsMSk7MDs0OygwLDIzKSwyMjQsMTYwO19fYXM6OigyOCw2MzUpPSMj
KDI4LDYzNik9JigyOCw2MzEpOzpSQzIzX0NSSVRJQ0FMX1NFQ1RJT05fREVCVUc7MkEuO19D
UklUSUNBTF9TRUNUSU9OX0RFQlVHOjooMjgsNjM3KT0jIygyOCw2MzgpPSooMjgsNjMxKTs6
UkMyM19DUklUSUNBTF9TRUNUSU9OX0RFQlVHOzJBLigyOCw2MzkpPSMjKDI4LDYzOCk7Ojsy
QS47OwBDUklUSUNBTF9TRUNUSU9OX0RFQlVHOnQoMjgsNjQwKT0oMjgsNjMxKQBQQ1JJVElD
QUxfU0VDVElPTl9ERUJVRzp0KDI4LDY0MSk9KDI4LDYzOCkAX0NSSVRJQ0FMX1NFQ1RJT046
VHQoMjgsNjMzKT1zMjREZWJ1Z0luZm86KDI4LDY0MSksMCwzMjtMb2NrQ291bnQ6KDI1LDEz
KSwzMiwzMjtSZWN1cnNpb25Db3VudDooMjUsMTMpLDY0LDMyO093bmluZ1RocmVhZDooMjUs
MTkpLDk2LDMyO0xvY2tTZW1hcGhvcmU6KDI1LDE5KSwxMjgsMzI7UmVzZXJ2ZWQ6KDI1LDE0
KSwxNjAsMzI7X19hczo6KDI4LDY0Mik9IyMoMjgsNjQzKT0mKDI4LDYzMyk7OlJDMTdfQ1JJ
VElDQUxfU0VDVElPTjsyQS47X0NSSVRJQ0FMX1NFQ1RJT046OigyOCw2NDQpPSMjKDI4LDYz
Mik7OlJDMTdfQ1JJVElDQUxfU0VDVElPTjsyQS4oMjgsNjQ1KT0jIygyOCw2MzIpOzo7MkEu
OzsAQ1JJVElDQUxfU0VDVElPTjp0KDI4LDY0Nik9KDI4LDYzMykAUENSSVRJQ0FMX1NFQ1RJ
T046dCgyOCw2NDcpPSgyOCw2MzIpAExQQ1JJVElDQUxfU0VDVElPTjp0KDI4LDY0OCk9KDI4
LDYzMikAX1NFQ1VSSVRZX1FVQUxJVFlfT0ZfU0VSVklDRTpUdCgyOCw2NDkpPXMxNkxlbmd0
aDooMjUsMTQpLDAsMzI7SW1wZXJzb25hdGlvbkxldmVsOigyNSwxNjQpLDMyLDMyO0NvbnRl
eHRUcmFja2luZ01vZGU6KDI1LDIpLDY0LDMyO0VmZmVjdGl2ZU9ubHk6KDI1LDQpLDk2LDg7
X19hczo6KDI4LDY1MCk9IyMoMjgsNjUxKT0mKDI4LDY0OSk7OlJDMjhfU0VDVVJJVFlfUVVB
TElUWV9PRl9TRVJWSUNFOzJBLjtfU0VDVVJJVFlfUVVBTElUWV9PRl9TRVJWSUNFOjooMjgs
NjUyKT0jIygyOCw2NTMpPSooMjgsNjQ5KTs6UkMyOF9TRUNVUklUWV9RVUFMSVRZX09GX1NF
UlZJQ0U7MkEuKDI4LDY1NCk9IyMoMjgsNjUzKTs6OzJBLjs7AFNFQ1VSSVRZX1FVQUxJVFlf
T0ZfU0VSVklDRTp0KDI4LDY1NSk9KDI4LDY0OSkAdGFnQ09OVkNPTlRFWFQ6VHQoMjgsNjU2
KT1zNDBjYjooMjUsMTUwKSwwLDMyO3dGbGFnczooMjUsMTUwKSwzMiwzMjt3Q291bnRyeUlE
OigyNSwxNTApLDY0LDMyO2lDb2RlUGFnZTooMCwxKSw5NiwzMjtkd0xhbmdJRDooMjUsMTQp
LDEyOCwzMjtkd1NlY3VyaXR5OigyNSwxNCksMTYwLDMyO3FvczooMjgsNjU1KSwxOTIsMTI4
O19fYXM6OigyOCw2NTcpPSMjKDI4LDY1OCk9JigyOCw2NTYpOzpSQzE0dGFnQ09OVkNPTlRF
WFQ7MkEuO3RhZ0NPTlZDT05URVhUOjooMjgsNjU5KT0jIygyOCw2NjApPSooMjgsNjU2KTs6
UkMxNHRhZ0NPTlZDT05URVhUOzJBLigyOCw2NjEpPSMjKDI4LDY2MCk7OjsyQS47OwBDT05W
Q09OVEVYVDp0KDI4LDY2Mik9KDI4LDY1NikAUENPTlZDT05URVhUOnQoMjgsNjYzKT0oMjgs
NjY0KT0qKDI4LDY2MikAdGFnQ09OVklORk86VHQoMjgsNjY1KT1zMTAwY2I6KDI1LDE0KSww
LDMyO2hVc2VyOigyNSwxNCksMzIsMzI7aENvbnZQYXJ0bmVyOigyNSwyNCksNjQsMzI7aHN6
U3ZjUGFydG5lcjooMjUsNTkpLDk2LDMyO2hzelNlcnZpY2VSZXE6KDI1LDU5KSwxMjgsMzI7
aHN6VG9waWM6KDI1LDU5KSwxNjAsMzI7aHN6SXRlbTooMjUsNTkpLDE5MiwzMjt3Rm10Oigy
NSwxNTApLDIyNCwzMjt3VHlwZTooMjUsMTUwKSwyNTYsMzI7d1N0YXR1czooMjUsMTUwKSwy
ODgsMzI7d0NvbnZzdDooMjUsMTUwKSwzMjAsMzI7d0xhc3RFcnJvcjooMjUsMTUwKSwzNTIs
MzI7aENvbnZMaXN0OigyNSwyNSksMzg0LDMyO0NvbnZDdHh0OigyOCw2NjIpLDQxNiwzMjA7
aHduZDooMjUsNjEpLDczNiwzMjtod25kUGFydG5lcjooMjUsNjEpLDc2OCwzMjtfX2FzOjoo
MjgsNjY2KT0jIygyOCw2NjcpPSYoMjgsNjY1KTs6UkMxMXRhZ0NPTlZJTkZPOzJBLjt0YWdD
T05WSU5GTzo6KDI4LDY2OCk9IyMoMjgsNjY5KT0qKDI4LDY2NSk7OlJDMTF0YWdDT05WSU5G
TzsyQS4oMjgsNjcwKT0jIygyOCw2NjkpOzo7MkEuOzsAQ09OVklORk86dCgyOCw2NzEpPSgy
OCw2NjUpAHRhZ0NPUFlEQVRBU1RSVUNUOlR0KDI4LDY3Mik9czEyZHdEYXRhOigyNSwxNCks
MCwzMjtjYkRhdGE6KDI1LDE0KSwzMiwzMjtscERhdGE6KDI1LDEzNiksNjQsMzI7X19hczo6
KDI4LDY3Myk9IyMoMjgsNjc0KT0mKDI4LDY3Mik7OlJDMTd0YWdDT1BZREFUQVNUUlVDVDsy
QS47dGFnQ09QWURBVEFTVFJVQ1Q6OigyOCw2NzUpPSMjKDI4LDY3Nik9KigyOCw2NzIpOzpS
QzE3dGFnQ09QWURBVEFTVFJVQ1Q7MkEuKDI4LDY3Nyk9IyMoMjgsNjc2KTs6OzJBLjs7AENP
UFlEQVRBU1RSVUNUOnQoMjgsNjc4KT0oMjgsNjcyKQBfY3BpbmZvOlR0KDI4LDY3OSk9czIw
TWF4Q2hhclNpemU6KDI1LDE1MCksMCwzMjtEZWZhdWx0Q2hhcjooMjgsNjgwKT1hcigwLDEp
OzA7MTsoMCwxMSksMzIsMTY7TGVhZEJ5dGU6KDI4LDY4MSk9YXIoMCwxKTswOzExOygwLDEx
KSw0OCw5NjtfX2FzOjooMjgsNjgyKT0jIygyOCw2ODMpPSYoMjgsNjc5KTs6UkM3X2NwaW5m
bzsyQS47X2NwaW5mbzo6KDI4LDY4NCk9IyMoMjgsNjg1KT0qKDI4LDY3OSk7OlJDN19jcGlu
Zm87MkEuKDI4LDY4Nik9IyMoMjgsNjg1KTs6OzJBLjs7AENQSU5GTzp0KDI4LDY4Nyk9KDI4
LDY3OSkATFBDUElORk86dCgyOCw2ODgpPSgyOCw2ODUpAHRhZ0NQTElORk86VHQoMjgsNjg5
KT1zMTZpZEljb246KDAsMSksMCwzMjtpZE5hbWU6KDAsMSksMzIsMzI7aWRJbmZvOigwLDEp
LDY0LDMyO2xEYXRhOigyNSwxMyksOTYsMzI7X19hczo6KDI4LDY5MCk9IyMoMjgsNjkxKT0m
KDI4LDY4OSk7OlJDMTB0YWdDUExJTkZPOzJBLjt0YWdDUExJTkZPOjooMjgsNjkyKT0jIygy
OCw2OTMpPSooMjgsNjg5KTs6UkMxMHRhZ0NQTElORk87MkEuKDI4LDY5NCk9IyMoMjgsNjkz
KTs6OzJBLjs7AENQTElORk86dCgyOCw2OTUpPSgyOCw2ODkpAF9DUkVBVEVfUFJPQ0VTU19E
RUJVR19JTkZPOlR0KDI4LDY5Nik9czQwaEZpbGU6KDI1LDE5KSwwLDMyO2hQcm9jZXNzOigy
NSwxOSksMzIsMzI7aFRocmVhZDooMjUsMTkpLDY0LDMyO2xwQmFzZU9mSW1hZ2U6KDI1LDk4
KSw5NiwzMjtkd0RlYnVnSW5mb0ZpbGVPZmZzZXQ6KDI1LDE0KSwxMjgsMzI7bkRlYnVnSW5m
b1NpemU6KDI1LDE0KSwxNjAsMzI7bHBUaHJlYWRMb2NhbEJhc2U6KDI1LDk4KSwxOTIsMzI7
bHBTdGFydEFkZHJlc3M6KDI1LDE4MyksMjI0LDMyO2xwSW1hZ2VOYW1lOigyNSw5OCksMjU2
LDMyO2ZVbmljb2RlOigyNSwxNTMpLDI4OCwxNjtfX2FzOjooMjgsNjk3KT0jIygyOCw2OTgp
PSYoMjgsNjk2KTs6UkMyNl9DUkVBVEVfUFJPQ0VTU19ERUJVR19JTkZPOzJBLjtfQ1JFQVRF
X1BST0NFU1NfREVCVUdfSU5GTzo6KDI4LDY5OSk9IyMoMjgsNzAwKT0qKDI4LDY5Nik7OlJD
MjZfQ1JFQVRFX1BST0NFU1NfREVCVUdfSU5GTzsyQS4oMjgsNzAxKT0jIygyOCw3MDApOzo7
MkEuOzsAQ1JFQVRFX1BST0NFU1NfREVCVUdfSU5GTzp0KDI4LDcwMik9KDI4LDY5NikAX0NS
RUFURV9USFJFQURfREVCVUdfSU5GTzpUdCgyOCw3MDMpPXMxMmhUaHJlYWQ6KDI1LDE5KSww
LDMyO2xwVGhyZWFkTG9jYWxCYXNlOigyNSw5OCksMzIsMzI7bHBTdGFydEFkZHJlc3M6KDI1
LDE4MyksNjQsMzI7X19hczo6KDI4LDcwNCk9IyMoMjgsNzA1KT0mKDI4LDcwMyk7OlJDMjVf
Q1JFQVRFX1RIUkVBRF9ERUJVR19JTkZPOzJBLjtfQ1JFQVRFX1RIUkVBRF9ERUJVR19JTkZP
OjooMjgsNzA2KT0jIygyOCw3MDcpPSooMjgsNzAzKTs6UkMyNV9DUkVBVEVfVEhSRUFEX0RF
QlVHX0lORk87MkEuKDI4LDcwOCk9IyMoMjgsNzA3KTs6OzJBLjs7AENSRUFURV9USFJFQURf
REVCVUdfSU5GTzp0KDI4LDcwOSk9KDI4LDcwMykAX2N1cnJlbmN5Zm10OlR0KDI4LDcxMCk9
czMyTnVtRGlnaXRzOigyNSwxNTApLDAsMzI7TGVhZGluZ1plcm86KDI1LDE1MCksMzIsMzI7
R3JvdXBpbmc6KDI1LDE1MCksNjQsMzI7bHBEZWNpbWFsU2VwOigyNSw5NiksOTYsMzI7bHBU
aG91c2FuZFNlcDooMjUsOTYpLDEyOCwzMjtOZWdhdGl2ZU9yZGVyOigyNSwxNTApLDE2MCwz
MjtQb3NpdGl2ZU9yZGVyOigyNSwxNTApLDE5MiwzMjtscEN1cnJlbmN5U3ltYm9sOigyNSw5
NiksMjI0LDMyO19fYXM6OigyOCw3MTEpPSMjKDI4LDcxMik9JigyOCw3MTApOzpSQzEyX2N1
cnJlbmN5Zm10OzJBLjtfY3VycmVuY3lmbXQ6OigyOCw3MTMpPSMjKDI4LDcxNCk9KigyOCw3
MTApOzpSQzEyX2N1cnJlbmN5Zm10OzJBLigyOCw3MTUpPSMjKDI4LDcxNCk7OjsyQS47OwBD
VVJSRU5DWUZNVDp0KDI4LDcxNik9KDI4LDcxMCkAdGFnQ1VSU09SU0hBUEU6VHQoMjgsNzE3
KT1zMjR4SG90U3BvdDooMCwxKSwwLDMyO3lIb3RTcG90OigwLDEpLDMyLDMyO2N4OigwLDEp
LDY0LDMyO2N5OigwLDEpLDk2LDMyO2NiV2lkdGg6KDAsMSksMTI4LDMyO1BsYW5lczooMjUs
NSksMTYwLDg7Qml0c1BpeGVsOigyNSw1KSwxNjgsODtfX2FzOjooMjgsNzE4KT0jIygyOCw3
MTkpPSYoMjgsNzE3KTs6UkMxNHRhZ0NVUlNPUlNIQVBFOzJBLjt0YWdDVVJTT1JTSEFQRTo6
KDI4LDcyMCk9IyMoMjgsNzIxKT0qKDI4LDcxNyk7OlJDMTR0YWdDVVJTT1JTSEFQRTsyQS4o
MjgsNzIyKT0jIygyOCw3MjEpOzo7MkEuOzsAQ1VSU09SU0hBUEU6dCgyOCw3MjMpPSgyOCw3
MTcpAExQQ1VSU09SU0hBUEU6dCgyOCw3MjQpPSgyOCw3MjEpAHRhZ0NXUFJFVFNUUlVDVDpU
dCgyOCw3MjUpPXMyMGxSZXN1bHQ6KDI1LDk3KSwwLDMyO2xQYXJhbTooMjUsNzApLDMyLDMy
O3dQYXJhbTooMjUsMTU0KSw2NCwzMjttZXNzYWdlOigyNSwxNCksOTYsMzI7aHduZDooMjUs
NjEpLDEyOCwzMjtfX2FzOjooMjgsNzI2KT0jIygyOCw3MjcpPSYoMjgsNzI1KTs6UkMxNXRh
Z0NXUFJFVFNUUlVDVDsyQS47dGFnQ1dQUkVUU1RSVUNUOjooMjgsNzI4KT0jIygyOCw3Mjkp
PSooMjgsNzI1KTs6UkMxNXRhZ0NXUFJFVFNUUlVDVDsyQS4oMjgsNzMwKT0jIygyOCw3Mjkp
Ozo7MkEuOzsAQ1dQUkVUU1RSVUNUOnQoMjgsNzMxKT0oMjgsNzI1KQB0YWdDV1BTVFJVQ1Q6
VHQoMjgsNzMyKT1zMTZsUGFyYW06KDI1LDcwKSwwLDMyO3dQYXJhbTooMjUsMTU0KSwzMiwz
MjttZXNzYWdlOigyNSwxNTApLDY0LDMyO2h3bmQ6KDI1LDYxKSw5NiwzMjtfX2FzOjooMjgs
NzMzKT0jIygyOCw3MzQpPSYoMjgsNzMyKTs6UkMxMnRhZ0NXUFNUUlVDVDsyQS47dGFnQ1dQ
U1RSVUNUOjooMjgsNzM1KT0jIygyOCw3MzYpPSooMjgsNzMyKTs6UkMxMnRhZ0NXUFNUUlVD
VDsyQS4oMjgsNzM3KT0jIygyOCw3MzYpOzo7MkEuOzsAQ1dQU1RSVUNUOnQoMjgsNzM4KT0o
MjgsNzMyKQBfREFUQVRZUEVTX0lORk9fMTpUdCgyOCw3MzkpPXM0cE5hbWU6KDI1LDk2KSww
LDMyO19fYXM6OigyOCw3NDApPSMjKDI4LDc0MSk9JigyOCw3MzkpOzpSQzE3X0RBVEFUWVBF
U19JTkZPXzE7MkEuO19EQVRBVFlQRVNfSU5GT18xOjooMjgsNzQyKT0jIygyOCw3NDMpPSoo
MjgsNzM5KTs6UkMxN19EQVRBVFlQRVNfSU5GT18xOzJBLigyOCw3NDQpPSMjKDI4LDc0Myk7
OjsyQS47OwBEQVRBVFlQRVNfSU5GT18xOnQoMjgsNzQ1KT0oMjgsNzM5KQBEREVBQ0s6dCgy
OCw3NDYpPXMyYkFwcFJldHVybkNvZGU6KDAsOSksMCw4O3Jlc2VydmVkOigwLDkpLDgsNjtm
QnVzeTooMCw5KSwxNCwxO2ZBY2s6KDAsOSksMTUsMTtfX2FzOjooMjgsNzQ3KT0jKDI4LDc0
NiksKDI4LDc0OCk9JigyOCw3NDYpLCgyOCw3NDkpPSooMjgsNzQ2KSwoMjgsNzUwKT0mKDI4
LDc1MSk9czJiQXBwUmV0dXJuQ29kZTooMCw5KSwwLDg7cmVzZXJ2ZWQ6KDAsOSksOCw2O2ZC
dXN5OigwLDkpLDE0LDE7ZkFjazooMCw5KSwxNSwxO19fYXM6OigyOCw3NDcpOl9fYXNfXzMk
XzZSQzMkXzY7MkEuOyRfNjo6KDI4LDc1Mik9IygyOCw3NDYpLCgyOCw3NDkpLCgyOCw3NDkp
LCgyOCw3NTApLCgwLDIwKTs6X18zJF82UkMzJF82OzJBLigyOCw3NTMpPSMoMjgsNzQ2KSwo
MjgsNzQ5KSwoMjgsNzQ5KSwoMCwyMCk7Ol9fMyRfNjsyQS47OywoMCwyMCk7Ol9fYXNfXzMk
XzZSQzMkXzY7MkEuOyRfNjo6KDI4LDc1Mik6X18zJF82UkMzJF82OzJBLigyOCw3NTMpOl9f
MyRfNjsyQS47OwBEREVBRFZJU0U6dCgyOCw3NTQpPXM0cmVzZXJ2ZWQ6KDAsOSksMCwxNDtm
RGVmZXJVcGQ6KDAsOSksMTQsMTtmQWNrUmVxOigwLDkpLDE1LDE7Y2ZGb3JtYXQ6KDAsOCks
MTYsMTY7X19hczo6KDI4LDc1NSk9IygyOCw3NTQpLCgyOCw3NTYpPSYoMjgsNzU0KSwoMjgs
NzU3KT0qKDI4LDc1NCksKDI4LDc1OCk9JigyOCw3NTkpPXM0cmVzZXJ2ZWQ6KDAsOSksMCwx
NDtmRGVmZXJVcGQ6KDAsOSksMTQsMTtmQWNrUmVxOigwLDkpLDE1LDE7Y2ZGb3JtYXQ6KDAs
OCksMTYsMTY7X19hczo6KDI4LDc1NSk6X19hc19fMyRfN1JDMyRfNzsyQS47JF83OjooMjgs
NzYwKT0jKDI4LDc1NCksKDI4LDc1NyksKDI4LDc1NyksKDI4LDc1OCksKDAsMjApOzpfXzMk
XzdSQzMkXzc7MkEuKDI4LDc2MSk9IygyOCw3NTQpLCgyOCw3NTcpLCgyOCw3NTcpLCgwLDIw
KTs6X18zJF83OzJBLjs7LCgwLDIwKTs6X19hc19fMyRfN1JDMyRfNzsyQS47JF83OjooMjgs
NzYwKTpfXzMkXzdSQzMkXzc7MkEuKDI4LDc2MSk6X18zJF83OzJBLjs7AERERURBVEE6dCgy
OCw3NjIpPXM2dW51c2VkOigwLDkpLDAsMTI7ZlJlc3BvbnNlOigwLDkpLDEyLDE7ZlJlbGVh
c2U6KDAsOSksMTMsMTtyZXNlcnZlZDooMCw5KSwxNCwxO2ZBY2tSZXE6KDAsOSksMTUsMTtj
ZkZvcm1hdDooMCw4KSwxNiwxNjtWYWx1ZTooMjgsMjUwKSwzMiw4O19fYXM6OigyOCw3NjMp
PSMoMjgsNzYyKSwoMjgsNzY0KT0mKDI4LDc2MiksKDI4LDc2NSk9KigyOCw3NjIpLCgyOCw3
NjYpPSYoMjgsNzY3KT1zNnVudXNlZDooMCw5KSwwLDEyO2ZSZXNwb25zZTooMCw5KSwxMiwx
O2ZSZWxlYXNlOigwLDkpLDEzLDE7cmVzZXJ2ZWQ6KDAsOSksMTQsMTtmQWNrUmVxOigwLDkp
LDE1LDE7Y2ZGb3JtYXQ6KDAsOCksMTYsMTY7VmFsdWU6KDI4LDI1MCksMzIsODtfX2FzOjoo
MjgsNzYzKTpfX2FzX18zJF84UkMzJF84OzJBLjskXzg6OigyOCw3NjgpPSMoMjgsNzYyKSwo
MjgsNzY1KSwoMjgsNzY1KSwoMjgsNzY2KSwoMCwyMCk7Ol9fMyRfOFJDMyRfODsyQS4oMjgs
NzY5KT0jKDI4LDc2MiksKDI4LDc2NSksKDI4LDc2NSksKDAsMjApOzpfXzMkXzg7MkEuOzss
KDAsMjApOzpfX2FzX18zJF84UkMzJF84OzJBLjskXzg6OigyOCw3NjgpOl9fMyRfOFJDMyRf
ODsyQS4oMjgsNzY5KTpfXzMkXzg7MkEuOzsARERFTE46dCgyOCw3NzApPXM0dW51c2VkOigw
LDkpLDAsMTM7ZlJlbGVhc2U6KDAsOSksMTMsMTtmRGVmZXJVcGQ6KDAsOSksMTQsMTtmQWNr
UmVxOigwLDkpLDE1LDE7Y2ZGb3JtYXQ6KDAsOCksMTYsMTY7X19hczo6KDI4LDc3MSk9Iygy
OCw3NzApLCgyOCw3NzIpPSYoMjgsNzcwKSwoMjgsNzczKT0qKDI4LDc3MCksKDI4LDc3NCk9
JigyOCw3NzUpPXM0dW51c2VkOigwLDkpLDAsMTM7ZlJlbGVhc2U6KDAsOSksMTMsMTtmRGVm
ZXJVcGQ6KDAsOSksMTQsMTtmQWNrUmVxOigwLDkpLDE1LDE7Y2ZGb3JtYXQ6KDAsOCksMTYs
MTY7X19hczo6KDI4LDc3MSk6X19hc19fMyRfOVJDMyRfOTsyQS47JF85OjooMjgsNzc2KT0j
KDI4LDc3MCksKDI4LDc3MyksKDI4LDc3MyksKDI4LDc3NCksKDAsMjApOzpfXzMkXzlSQzMk
Xzk7MkEuKDI4LDc3Nyk9IygyOCw3NzApLCgyOCw3NzMpLCgyOCw3NzMpLCgwLDIwKTs6X18z
JF85OzJBLjs7LCgwLDIwKTs6X19hc19fMyRfOVJDMyRfOTsyQS47JF85OjooMjgsNzc2KTpf
XzMkXzlSQzMkXzk7MkEuKDI4LDc3Nyk6X18zJF85OzJBLjs7AHRhZ0RERU1MX01TR19IT09L
X0RBVEE6VHQoMjgsNzc4KT1zNDR1aUxvOigyNSwxNTApLDAsMzI7dWlIaTooMjUsMTUwKSwz
MiwzMjtjYkRhdGE6KDI1LDE0KSw2NCwzMjtEYXRhOigyOCw3NzkpPWFyKDAsMSk7MDs3Oygw
LDQpLDk2LDI1NjtfX2FzOjooMjgsNzgwKT0jIygyOCw3ODEpPSYoMjgsNzc4KTs6UkMyMnRh
Z0RERU1MX01TR19IT09LX0RBVEE7MkEuO3RhZ0RERU1MX01TR19IT09LX0RBVEE6OigyOCw3
ODIpPSMjKDI4LDc4Myk9KigyOCw3NzgpOzpSQzIydGFnRERFTUxfTVNHX0hPT0tfREFUQTsy
QS4oMjgsNzg0KT0jIygyOCw3ODMpOzo7MkEuOzsARERFTUxfTVNHX0hPT0tfREFUQTp0KDI4
LDc4NSk9KDI4LDc3OCkARERFUE9LRTp0KDI4LDc4Nik9czZ1bnVzZWQ6KDAsOSksMCwxMztm
UmVsZWFzZTooMCw5KSwxMywxO2ZSZXNlcnZlZDooMCw5KSwxNCwyO2NmRm9ybWF0OigwLDgp
LDE2LDE2O1ZhbHVlOigyOCwyNTApLDMyLDg7X19hczo6KDI4LDc4Nyk9IygyOCw3ODYpLCgy
OCw3ODgpPSYoMjgsNzg2KSwoMjgsNzg5KT0qKDI4LDc4NiksKDI4LDc5MCk9JigyOCw3OTEp
PXM2dW51c2VkOigwLDkpLDAsMTM7ZlJlbGVhc2U6KDAsOSksMTMsMTtmUmVzZXJ2ZWQ6KDAs
OSksMTQsMjtjZkZvcm1hdDooMCw4KSwxNiwxNjtWYWx1ZTooMjgsMjUwKSwzMiw4O19fYXM6
OigyOCw3ODcpOl9fYXNfXzQkXzEwUkM0JF8xMDsyQS47JF8xMDo6KDI4LDc5Mik9IygyOCw3
ODYpLCgyOCw3ODkpLCgyOCw3ODkpLCgyOCw3OTApLCgwLDIwKTs6X180JF8xMFJDNCRfMTA7
MkEuKDI4LDc5Myk9IygyOCw3ODYpLCgyOCw3ODkpLCgyOCw3ODkpLCgwLDIwKTs6X180JF8x
MDsyQS47OywoMCwyMCk7Ol9fYXNfXzQkXzEwUkM0JF8xMDsyQS47JF8xMDo6KDI4LDc5Mik6
X180JF8xMFJDNCRfMTA7MkEuKDI4LDc5Myk6X180JF8xMDsyQS47OwBEREVVUDp0KDI4LDc5
NCk9czZ1bnVzZWQ6KDAsOSksMCwxMjtmQWNrOigwLDkpLDEyLDE7ZlJlbGVhc2U6KDAsOSks
MTMsMTtmUmVzZXJ2ZWQ6KDAsOSksMTQsMTtmQWNrUmVxOigwLDkpLDE1LDE7Y2ZGb3JtYXQ6
KDAsOCksMTYsMTY7cmdiOigyOCwyNTApLDMyLDg7X19hczo6KDI4LDc5NSk9IygyOCw3OTQp
LCgyOCw3OTYpPSYoMjgsNzk0KSwoMjgsNzk3KT0qKDI4LDc5NCksKDI4LDc5OCk9JigyOCw3
OTkpPXM2dW51c2VkOigwLDkpLDAsMTI7ZkFjazooMCw5KSwxMiwxO2ZSZWxlYXNlOigwLDkp
LDEzLDE7ZlJlc2VydmVkOigwLDkpLDE0LDE7ZkFja1JlcTooMCw5KSwxNSwxO2NmRm9ybWF0
OigwLDgpLDE2LDE2O3JnYjooMjgsMjUwKSwzMiw4O19fYXM6OigyOCw3OTUpOl9fYXNfXzQk
XzExUkM0JF8xMTsyQS47JF8xMTo6KDI4LDgwMCk9IygyOCw3OTQpLCgyOCw3OTcpLCgyOCw3
OTcpLCgyOCw3OTgpLCgwLDIwKTs6X180JF8xMVJDNCRfMTE7MkEuKDI4LDgwMSk9IygyOCw3
OTQpLCgyOCw3OTcpLCgyOCw3OTcpLCgwLDIwKTs6X180JF8xMTsyQS47OywoMCwyMCk7Ol9f
YXNfXzQkXzExUkM0JF8xMTsyQS47JF8xMTo6KDI4LDgwMCk6X180JF8xMVJDNCRfMTE7MkEu
KDI4LDgwMSk6X180JF8xMTsyQS47OwBfRVhDRVBUSU9OX1JFQ09SRDpUdCgyOCw4MDIpPXM4
MEV4Y2VwdGlvbkNvZGU6KDI1LDE0KSwwLDMyO0V4Y2VwdGlvbkZsYWdzOigyNSwxNCksMzIs
MzI7RXhjZXB0aW9uUmVjb3JkOigyOCw4MDMpPSooMjgsODAyKSw2NCwzMjtFeGNlcHRpb25B
ZGRyZXNzOigyNSwxMzYpLDk2LDMyO051bWJlclBhcmFtZXRlcnM6KDI1LDE0KSwxMjgsMzI7
RXhjZXB0aW9uSW5mb3JtYXRpb246KDI4LDgwNCk9YXIoMCwxKTswOzE0OygwLDQpLDE2MCw0
ODA7X19hczo6KDI4LDgwNSk9IyMoMjgsODA2KT0mKDI4LDgwMik7OlJDMTdfRVhDRVBUSU9O
X1JFQ09SRDsyQS47X0VYQ0VQVElPTl9SRUNPUkQ6OigyOCw4MDcpPSMjKDI4LDgwMyk7OlJD
MTdfRVhDRVBUSU9OX1JFQ09SRDsyQS4oMjgsODA4KT0jIygyOCw4MDMpOzo7MkEuOzsARVhD
RVBUSU9OX1JFQ09SRDp0KDI4LDgwOSk9KDI4LDgwMikAUEVYQ0VQVElPTl9SRUNPUkQ6dCgy
OCw4MTApPSgyOCw4MDMpAExQRVhDRVBUSU9OX1JFQ09SRDp0KDI4LDgxMSk9KDI4LDgwMykA
X0VYQ0VQVElPTl9ERUJVR19JTkZPOlR0KDI4LDgxMik9czg0RXhjZXB0aW9uUmVjb3JkOigy
OCw4MDkpLDAsNjQwO2R3Rmlyc3RDaGFuY2U6KDI1LDE0KSw2NDAsMzI7X19hczo6KDI4LDgx
Myk9IyMoMjgsODE0KT0mKDI4LDgxMik7OlJDMjFfRVhDRVBUSU9OX0RFQlVHX0lORk87MkEu
O19FWENFUFRJT05fREVCVUdfSU5GTzo6KDI4LDgxNSk9IyMoMjgsODE2KT0qKDI4LDgxMik7
OlJDMjFfRVhDRVBUSU9OX0RFQlVHX0lORk87MkEuKDI4LDgxNyk9IyMoMjgsODE2KTs6OzJB
Ljs7AEVYQ0VQVElPTl9ERUJVR19JTkZPOnQoMjgsODE4KT0oMjgsODEyKQBfRVhJVF9QUk9D
RVNTX0RFQlVHX0lORk86VHQoMjgsODE5KT1zNGR3RXhpdENvZGU6KDI1LDE0KSwwLDMyO19f
YXM6OigyOCw4MjApPSMjKDI4LDgyMSk9JigyOCw4MTkpOzpSQzI0X0VYSVRfUFJPQ0VTU19E
RUJVR19JTkZPOzJBLjtfRVhJVF9QUk9DRVNTX0RFQlVHX0lORk86OigyOCw4MjIpPSMjKDI4
LDgyMyk9KigyOCw4MTkpOzpSQzI0X0VYSVRfUFJPQ0VTU19ERUJVR19JTkZPOzJBLigyOCw4
MjQpPSMjKDI4LDgyMyk7OjsyQS47OwBFWElUX1BST0NFU1NfREVCVUdfSU5GTzp0KDI4LDgy
NSk9KDI4LDgxOSkAX0VYSVRfVEhSRUFEX0RFQlVHX0lORk86VHQoMjgsODI2KT1zNGR3RXhp
dENvZGU6KDI1LDE0KSwwLDMyO19fYXM6OigyOCw4MjcpPSMjKDI4LDgyOCk9JigyOCw4MjYp
OzpSQzIzX0VYSVRfVEhSRUFEX0RFQlVHX0lORk87MkEuO19FWElUX1RIUkVBRF9ERUJVR19J
TkZPOjooMjgsODI5KT0jIygyOCw4MzApPSooMjgsODI2KTs6UkMyM19FWElUX1RIUkVBRF9E
RUJVR19JTkZPOzJBLigyOCw4MzEpPSMjKDI4LDgzMCk7OjsyQS47OwBFWElUX1RIUkVBRF9E
RUJVR19JTkZPOnQoMjgsODMyKT0oMjgsODI2KQBfTE9BRF9ETExfREVCVUdfSU5GTzpUdCgy
OCw4MzMpPXMyNGhGaWxlOigyNSwxOSksMCwzMjtscEJhc2VPZkRsbDooMjUsOTgpLDMyLDMy
O2R3RGVidWdJbmZvRmlsZU9mZnNldDooMjUsMTQpLDY0LDMyO25EZWJ1Z0luZm9TaXplOigy
NSwxNCksOTYsMzI7bHBJbWFnZU5hbWU6KDI1LDk4KSwxMjgsMzI7ZlVuaWNvZGU6KDI1LDE1
MyksMTYwLDE2O19fYXM6OigyOCw4MzQpPSMjKDI4LDgzNSk9JigyOCw4MzMpOzpSQzIwX0xP
QURfRExMX0RFQlVHX0lORk87MkEuO19MT0FEX0RMTF9ERUJVR19JTkZPOjooMjgsODM2KT0j
IygyOCw4MzcpPSooMjgsODMzKTs6UkMyMF9MT0FEX0RMTF9ERUJVR19JTkZPOzJBLigyOCw4
MzgpPSMjKDI4LDgzNyk7OjsyQS47OwBMT0FEX0RMTF9ERUJVR19JTkZPOnQoMjgsODM5KT0o
MjgsODMzKQBfVU5MT0FEX0RMTF9ERUJVR19JTkZPOlR0KDI4LDg0MCk9czRscEJhc2VPZkRs
bDooMjUsOTgpLDAsMzI7X19hczo6KDI4LDg0MSk9IyMoMjgsODQyKT0mKDI4LDg0MCk7OlJD
MjJfVU5MT0FEX0RMTF9ERUJVR19JTkZPOzJBLjtfVU5MT0FEX0RMTF9ERUJVR19JTkZPOjoo
MjgsODQzKT0jIygyOCw4NDQpPSooMjgsODQwKTs6UkMyMl9VTkxPQURfRExMX0RFQlVHX0lO
Rk87MkEuKDI4LDg0NSk9IyMoMjgsODQ0KTs6OzJBLjs7AFVOTE9BRF9ETExfREVCVUdfSU5G
Tzp0KDI4LDg0Nik9KDI4LDg0MCkAX09VVFBVVF9ERUJVR19TVFJJTkdfSU5GTzpUdCgyOCw4
NDcpPXM4bHBEZWJ1Z1N0cmluZ0RhdGE6KDI1LDk0KSwwLDMyO2ZVbmljb2RlOigyNSwxNTMp
LDMyLDE2O25EZWJ1Z1N0cmluZ0xlbmd0aDooMjUsMTUzKSw0OCwxNjtfX2FzOjooMjgsODQ4
KT0jIygyOCw4NDkpPSYoMjgsODQ3KTs6UkMyNV9PVVRQVVRfREVCVUdfU1RSSU5HX0lORk87
MkEuO19PVVRQVVRfREVCVUdfU1RSSU5HX0lORk86OigyOCw4NTApPSMjKDI4LDg1MSk9Kigy
OCw4NDcpOzpSQzI1X09VVFBVVF9ERUJVR19TVFJJTkdfSU5GTzsyQS4oMjgsODUyKT0jIygy
OCw4NTEpOzo7MkEuOzsAT1VUUFVUX0RFQlVHX1NUUklOR19JTkZPOnQoMjgsODUzKT0oMjgs
ODQ3KQBfUklQX0lORk86VHQoMjgsODU0KT1zOGR3RXJyb3I6KDI1LDE0KSwwLDMyO2R3VHlw
ZTooMjUsMTQpLDMyLDMyO19fYXM6OigyOCw4NTUpPSMjKDI4LDg1Nik9JigyOCw4NTQpOzpS
QzlfUklQX0lORk87MkEuO19SSVBfSU5GTzo6KDI4LDg1Nyk9IyMoMjgsODU4KT0qKDI4LDg1
NCk7OlJDOV9SSVBfSU5GTzsyQS4oMjgsODU5KT0jIygyOCw4NTgpOzo7MkEuOzsAUklQX0lO
Rk86dCgyOCw4NjApPSgyOCw4NTQpAF9ERUJVR19FVkVOVDpUdCgyOCw4NjEpPXM5NmR3RGVi
dWdFdmVudENvZGU6KDI1LDE0KSwwLDMyO2R3UHJvY2Vzc0lkOigyNSwxNCksMzIsMzI7ZHdU
aHJlYWRJZDooMjUsMTQpLDY0LDMyO3U6KDI4LDg2Mik9dTg0RXhjZXB0aW9uOigyOCw4MTgp
LDAsNjcyO0NyZWF0ZVRocmVhZDooMjgsNzA5KSwwLDk2O0NyZWF0ZVByb2Nlc3NJbmZvOigy
OCw3MDIpLDAsMzIwO0V4aXRUaHJlYWQ6KDI4LDgzMiksMCwzMjtFeGl0UHJvY2VzczooMjgs
ODI1KSwwLDMyO0xvYWREbGw6KDI4LDgzOSksMCwxOTI7VW5sb2FkRGxsOigyOCw4NDYpLDAs
MzI7RGVidWdTdHJpbmc6KDI4LDg1MyksMCw2NDtSaXBJbmZvOigyOCw4NjApLDAsNjQ7X19h
czo6KDI4LDg2Myk9IygyOCw4NjIpLCgyOCw4NjQpPSYoMjgsODYyKSwoMjgsODY1KT0qKDI4
LDg2MiksKDI4LDg2Nik9JigyOCw4NjIpLCgwLDIwKTs6X19hc19fUTIxMl9ERUJVR19FVkVO
VDQkXzEyUkNRMjEyX0RFQlVHX0VWRU5UNCRfMTI7MkEuOyRfMTI6OigyOCw4NjcpPSMoMjgs
ODYyKSwoMjgsODY1KSwoMjgsODY1KSwoMjgsODY2KSwoMCwyMCk7Ol9fUTIxMl9ERUJVR19F
VkVOVDQkXzEyUkNRMjEyX0RFQlVHX0VWRU5UNCRfMTI7MkEuKDI4LDg2OCk9IygyOCw4NjIp
LCgyOCw4NjUpLCgyOCw4NjUpLCgwLDIwKTs6X19RMjEyX0RFQlVHX0VWRU5UNCRfMTI7MkEu
OzssOTYsNjcyO19fYXM6OigyOCw4NjkpPSMjKDI4LDg3MCk9JigyOCw4NjEpOzpSQzEyX0RF
QlVHX0VWRU5UOzJBLjtfREVCVUdfRVZFTlQ6OigyOCw4NzEpPSMjKDI4LDg3Mik9KigyOCw4
NjEpOzpSQzEyX0RFQlVHX0VWRU5UOzJBLigyOCw4NzMpPSMjKDI4LDg3Mik7OjsyQS47OwBE
RUJVR19FVkVOVDp0KDI4LDg3NCk9KDI4LDg2MSkATFBERUJVR19FVkVOVDp0KDI4LDg3NSk9
KDI4LDg3MikAdGFnREVCVUdIT09LSU5GTzpUdCgyOCw4NzYpPXMyMGlkVGhyZWFkOigyNSwx
NCksMCwzMjtpZFRocmVhZEluc3RhbGxlcjooMjUsMTQpLDMyLDMyO2xQYXJhbTooMjUsNzAp
LDY0LDMyO3dQYXJhbTooMjUsMTU0KSw5NiwzMjtjb2RlOigwLDEpLDEyOCwzMjtfX2FzOjoo
MjgsODc3KT0jIygyOCw4NzgpPSYoMjgsODc2KTs6UkMxNnRhZ0RFQlVHSE9PS0lORk87MkEu
O3RhZ0RFQlVHSE9PS0lORk86OigyOCw4NzkpPSMjKDI4LDg4MCk9KigyOCw4NzYpOzpSQzE2
dGFnREVCVUdIT09LSU5GTzsyQS4oMjgsODgxKT0jIygyOCw4ODApOzo7MkEuOzsAREVCVUdI
T09LSU5GTzp0KDI4LDg4Mik9KDI4LDg3NikAdGFnREVMRVRFSVRFTVNUUlVDVDpUdCgyOCw4
ODMpPXMyMEN0bFR5cGU6KDI1LDE1MCksMCwzMjtDdGxJRDooMjUsMTUwKSwzMiwzMjtpdGVt
SUQ6KDI1LDE1MCksNjQsMzI7aHduZEl0ZW06KDI1LDYxKSw5NiwzMjtpdGVtRGF0YTooMjUs
MTUwKSwxMjgsMzI7X19hczo6KDI4LDg4NCk9IyMoMjgsODg1KT0mKDI4LDg4Myk7OlJDMTl0
YWdERUxFVEVJVEVNU1RSVUNUOzJBLjt0YWdERUxFVEVJVEVNU1RSVUNUOjooMjgsODg2KT0j
IygyOCw4ODcpPSooMjgsODgzKTs6UkMxOXRhZ0RFTEVURUlURU1TVFJVQ1Q7MkEuKDI4LDg4
OCk9IyMoMjgsODg3KTs6OzJBLjs7AERFTEVURUlURU1TVFJVQ1Q6dCgyOCw4ODkpPSgyOCw4
ODMpAF9ERVZfQlJPQURDQVNUX0hEUjpUdCgyOCw4OTApPXMxMmRiY2hfc2l6ZTooMjUsMTUx
KSwwLDMyO2RiY2hfZGV2aWNldHlwZTooMjUsMTUxKSwzMiwzMjtkYmNoX3Jlc2VydmVkOigy
NSwxNTEpLDY0LDMyO19fYXM6OigyOCw4OTEpPSMjKDI4LDg5Mik9JigyOCw4OTApOzpSQzE4
X0RFVl9CUk9BRENBU1RfSERSOzJBLjtfREVWX0JST0FEQ0FTVF9IRFI6OigyOCw4OTMpPSMj
KDI4LDg5NCk9KigyOCw4OTApOzpSQzE4X0RFVl9CUk9BRENBU1RfSERSOzJBLigyOCw4OTUp
PSMjKDI4LDg5NCk7OjsyQS47OwBERVZfQlJPQURDQVNUX0hEUjp0KDI4LDg5Nik9KDI4LDg5
MCkAUERFVl9CUk9BRENBU1RfSERSOnQoMjgsODk3KT0oMjgsODk4KT0qKDI4LDg5NikAX0RF
Vl9CUk9BRENBU1RfT0VNOlR0KDI4LDg5OSk9czIwZGJjb19zaXplOigyNSwxNTEpLDAsMzI7
ZGJjb19kZXZpY2V0eXBlOigyNSwxNTEpLDMyLDMyO2RiY29fcmVzZXJ2ZWQ6KDI1LDE1MSks
NjQsMzI7ZGJjb19pZGVudGlmaWVyOigyNSwxNTEpLDk2LDMyO2RiY29fc3VwcGZ1bmM6KDI1
LDE1MSksMTI4LDMyO19fYXM6OigyOCw5MDApPSMjKDI4LDkwMSk9JigyOCw4OTkpOzpSQzE4
X0RFVl9CUk9BRENBU1RfT0VNOzJBLjtfREVWX0JST0FEQ0FTVF9PRU06OigyOCw5MDIpPSMj
KDI4LDkwMyk9KigyOCw4OTkpOzpSQzE4X0RFVl9CUk9BRENBU1RfT0VNOzJBLigyOCw5MDQp
PSMjKDI4LDkwMyk7OjsyQS47OwBERVZfQlJPQURDQVNUX09FTTp0KDI4LDkwNSk9KDI4LDg5
OSkAUERFVl9CUk9BRENBU1RfT0VNOnQoMjgsOTA2KT0oMjgsOTA3KT0qKDI4LDkwNSkAX0RF
Vl9CUk9BRENBU1RfUE9SVDpUdCgyOCw5MDgpPXMxNmRiY3Bfc2l6ZTooMjUsMTUxKSwwLDMy
O2RiY3BfZGV2aWNldHlwZTooMjUsMTUxKSwzMiwzMjtkYmNwX3Jlc2VydmVkOigyNSwxNTEp
LDY0LDMyO2RiY3BfbmFtZTooMjgsOTA5KT1hcigwLDEpOzA7MDsoMCwyKSw5Niw4O19fYXM6
OigyOCw5MTApPSMjKDI4LDkxMSk9JigyOCw5MDgpOzpSQzE5X0RFVl9CUk9BRENBU1RfUE9S
VDsyQS47X0RFVl9CUk9BRENBU1RfUE9SVDo6KDI4LDkxMik9IyMoMjgsOTEzKT0qKDI4LDkw
OCk7OlJDMTlfREVWX0JST0FEQ0FTVF9QT1JUOzJBLigyOCw5MTQpPSMjKDI4LDkxMyk7Ojsy
QS47OwBERVZfQlJPQURDQVNUX1BPUlQ6dCgyOCw5MTUpPSgyOCw5MDgpAFBERVZfQlJPQURD
QVNUX1BPUlQ6dCgyOCw5MTYpPSgyOCw5MTcpPSooMjgsOTE1KQBfREVWX0JST0FEQ0FTVF9V
U0VSREVGSU5FRDpUdCgyOCw5MTgpPXMxNmRidWRfZGJoOigyOCw4OTApLDAsOTY7ZGJ1ZF9z
ek5hbWU6KDI4LDkwOSksOTYsODtkYnVkX3JnYlVzZXJEZWZpbmVkOigyOCwyNTApLDEwNCw4
O19fYXM6OigyOCw5MTkpPSMjKDI4LDkyMCk9JigyOCw5MTgpOzpSQzI2X0RFVl9CUk9BRENB
U1RfVVNFUkRFRklORUQ7MkEuO19ERVZfQlJPQURDQVNUX1VTRVJERUZJTkVEOjooMjgsOTIx
KT0jIygyOCw5MjIpPSooMjgsOTE4KTs6UkMyNl9ERVZfQlJPQURDQVNUX1VTRVJERUZJTkVE
OzJBLigyOCw5MjMpPSMjKDI4LDkyMik7OjsyQS47OwBfREVWX0JST0FEQ0FTVF9WT0xVTUU6
VHQoMjgsOTI0KT1zMjBkYmN2X3NpemU6KDI1LDE1MSksMCwzMjtkYmN2X2RldmljZXR5cGU6
KDI1LDE1MSksMzIsMzI7ZGJjdl9yZXNlcnZlZDooMjUsMTUxKSw2NCwzMjtkYmN2X3VuaXRt
YXNrOigyNSwxNTEpLDk2LDMyO2RiY3ZfZmxhZ3M6KDI1LDE1MiksMTI4LDE2O19fYXM6Oigy
OCw5MjUpPSMjKDI4LDkyNik9JigyOCw5MjQpOzpSQzIxX0RFVl9CUk9BRENBU1RfVk9MVU1F
OzJBLjtfREVWX0JST0FEQ0FTVF9WT0xVTUU6OigyOCw5MjcpPSMjKDI4LDkyOCk9KigyOCw5
MjQpOzpSQzIxX0RFVl9CUk9BRENBU1RfVk9MVU1FOzJBLigyOCw5MjkpPSMjKDI4LDkyOCk7
OjsyQS47OwBERVZfQlJPQURDQVNUX1ZPTFVNRTp0KDI4LDkzMCk9KDI4LDkyNCkAUERFVl9C
Uk9BRENBU1RfVk9MVU1FOnQoMjgsOTMxKT0oMjgsOTMyKT0qKDI4LDkzMCkAX2RldmljZW1v
ZGU6VHQoMjgsOTMzKT1zMTQ4ZG1EZXZpY2VOYW1lOigyOCw5MzQpPWFyKDAsMSk7MDszMTso
MCwxMSksMCwyNTY7ZG1TcGVjVmVyc2lvbjooMjUsMTUzKSwyNTYsMTY7ZG1Ecml2ZXJWZXJz
aW9uOigyNSwxNTMpLDI3MiwxNjtkbVNpemU6KDI1LDE1MyksMjg4LDE2O2RtRHJpdmVyRXh0
cmE6KDI1LDE1MyksMzA0LDE2O2RtRmllbGRzOigyNSwxNCksMzIwLDMyO2RtT3JpZW50YXRp
b246KDAsOCksMzUyLDE2O2RtUGFwZXJTaXplOigwLDgpLDM2OCwxNjtkbVBhcGVyTGVuZ3Ro
OigwLDgpLDM4NCwxNjtkbVBhcGVyV2lkdGg6KDAsOCksNDAwLDE2O2RtU2NhbGU6KDAsOCks
NDE2LDE2O2RtQ29waWVzOigwLDgpLDQzMiwxNjtkbURlZmF1bHRTb3VyY2U6KDAsOCksNDQ4
LDE2O2RtUHJpbnRRdWFsaXR5OigwLDgpLDQ2NCwxNjtkbUNvbG9yOigwLDgpLDQ4MCwxNjtk
bUR1cGxleDooMCw4KSw0OTYsMTY7ZG1ZUmVzb2x1dGlvbjooMCw4KSw1MTIsMTY7ZG1UVE9w
dGlvbjooMCw4KSw1MjgsMTY7ZG1Db2xsYXRlOigwLDgpLDU0NCwxNjtkbUZvcm1OYW1lOigy
OCw5MzQpLDU2MCwyNTY7ZG1Mb2dQaXhlbHM6KDI1LDE1MyksODE2LDE2O2RtQml0c1BlclBl
bDooMjUsMTQpLDgzMiwzMjtkbVBlbHNXaWR0aDooMjUsMTQpLDg2NCwzMjtkbVBlbHNIZWln
aHQ6KDI1LDE0KSw4OTYsMzI7ZG1EaXNwbGF5RmxhZ3M6KDI1LDE0KSw5MjgsMzI7ZG1EaXNw
bGF5RnJlcXVlbmN5OigyNSwxNCksOTYwLDMyO2RtSUNNTWV0aG9kOigyNSwxNCksOTkyLDMy
O2RtSUNNSW50ZW50OigyNSwxNCksMTAyNCwzMjtkbU1lZGlhVHlwZTooMjUsMTQpLDEwNTYs
MzI7ZG1EaXRoZXJUeXBlOigyNSwxNCksMTA4OCwzMjtkbUlDQ01hbnVmYWN0dXJlcjooMjUs
MTQpLDExMjAsMzI7ZG1JQ0NNb2RlbDooMjUsMTQpLDExNTIsMzI7X19hczo6KDI4LDkzNSk9
IyMoMjgsOTM2KT0mKDI4LDkzMyk7OlJDMTFfZGV2aWNlbW9kZTsyQS47X2RldmljZW1vZGU6
OigyOCw5MzcpPSMjKDI4LDkzOCk9KigyOCw5MzMpOzpSQzExX2RldmljZW1vZGU7MkEuKDI4
LDkzOSk9IyMoMjgsOTM4KTs6OzJBLjs7AERFVk1PREU6dCgyOCw5NDApPSgyOCw5MzMpAFBE
RVZNT0RFOnQoMjgsOTQxKT0oMjgsOTM4KQBOUERFVk1PREU6dCgyOCw5NDIpPSgyOCw5Mzgp
AExQREVWTU9ERTp0KDI4LDk0Myk9KDI4LDkzOCkAREVWTU9ERUE6dCgyOCw5NDQpPSgyOCw5
NDApAFBERVZNT0RFQTp0KDI4LDk0NSk9KDI4LDk0MSkATlBERVZNT0RFQTp0KDI4LDk0Nik9
KDI4LDk0MikATFBERVZNT0RFQTp0KDI4LDk0Nyk9KDI4LDk0MykAdGFnREVWTkFNRVM6VHQo
MjgsOTQ4KT1zOHdEcml2ZXJPZmZzZXQ6KDI1LDE1MyksMCwxNjt3RGV2aWNlT2Zmc2V0Oigy
NSwxNTMpLDE2LDE2O3dPdXRwdXRPZmZzZXQ6KDI1LDE1MyksMzIsMTY7d0RlZmF1bHQ6KDI1
LDE1MyksNDgsMTY7X19hczo6KDI4LDk0OSk9IyMoMjgsOTUwKT0mKDI4LDk0OCk7OlJDMTF0
YWdERVZOQU1FUzsyQS47dGFnREVWTkFNRVM6OigyOCw5NTEpPSMjKDI4LDk1Mik9KigyOCw5
NDgpOzpSQzExdGFnREVWTkFNRVM7MkEuKDI4LDk1Myk9IyMoMjgsOTUyKTs6OzJBLjs7AERF
Vk5BTUVTOnQoMjgsOTU0KT0oMjgsOTQ4KQBMUERFVk5BTUVTOnQoMjgsOTU1KT0oMjgsOTUy
KQB0YWdESUJTRUNUSU9OOlR0KDI4LDk1Nik9czg0ZHNCbTooMjgsMTM3KSwwLDE5Mjtkc0Jt
aWg6KDI4LDE4MiksMTkyLDMyMDtkc0JpdGZpZWxkczooMjgsMjA1KSw1MTIsOTY7ZHNoU2Vj
dGlvbjooMjUsMTkpLDYwOCwzMjtkc09mZnNldDooMjUsMTQpLDY0MCwzMjtfX2FzOjooMjgs
OTU3KT0jIygyOCw5NTgpPSYoMjgsOTU2KTs6UkMxM3RhZ0RJQlNFQ1RJT047MkEuO3RhZ0RJ
QlNFQ1RJT046OigyOCw5NTkpPSMjKDI4LDk2MCk9KigyOCw5NTYpOzpSQzEzdGFnRElCU0VD
VElPTjsyQS4oMjgsOTYxKT0jIygyOCw5NjApOzo7MkEuOzsARElCU0VDVElPTjp0KDI4LDk2
Mik9KDI4LDk1NikAX0xBUkdFX0lOVEVHRVI6VHQoMjgsOTYzKT1zOExvd1BhcnQ6KDI1LDE0
KSwwLDMyO0hpZ2hQYXJ0OigyNSwxMyksMzIsMzI7X19hczo6KDI4LDk2NCk9IyMoMjgsOTY1
KT0mKDI4LDk2Myk7OlJDMTRfTEFSR0VfSU5URUdFUjsyQS47X0xBUkdFX0lOVEVHRVI6Oigy
OCw5NjYpPSMjKDI4LDk2Nyk9KigyOCw5NjMpOzpSQzE0X0xBUkdFX0lOVEVHRVI7MkEuKDI4
LDk2OCk9IyMoMjgsOTY3KTs6OzJBLjs7AExBUkdFX0lOVEVHRVI6dCgyOCw5NjkpPSgyOCw5
NjMpAFBMQVJHRV9JTlRFR0VSOnQoMjgsOTcwKT0oMjgsOTY3KQBfRElTS19HRU9NRVRSWTpU
dCgyOCw5NzEpPXMyNEN5bGluZGVyczooMjgsOTY5KSwwLDY0O01lZGlhVHlwZTooMjUsMTU4
KSw2NCwzMjtUcmFja3NQZXJDeWxpbmRlcjooMjUsMTQpLDk2LDMyO1NlY3RvcnNQZXJUcmFj
azooMjUsMTQpLDEyOCwzMjtCeXRlc1BlclNlY3RvcjooMjUsMTQpLDE2MCwzMjtfX2FzOjoo
MjgsOTcyKT0jIygyOCw5NzMpPSYoMjgsOTcxKTs6UkMxNF9ESVNLX0dFT01FVFJZOzJBLjtf
RElTS19HRU9NRVRSWTo6KDI4LDk3NCk9IyMoMjgsOTc1KT0qKDI4LDk3MSk7OlJDMTRfRElT
S19HRU9NRVRSWTsyQS4oMjgsOTc2KT0jIygyOCw5NzUpOzo7MkEuOzsARElTS19HRU9NRVRS
WTp0KDI4LDk3Nyk9KDI4LDk3MSkAX0RJU0tfUEVSRk9STUFOQ0U6VHQoMjgsOTc4KT1zNDRC
eXRlc1JlYWQ6KDI4LDk2OSksMCw2NDtCeXRlc1dyaXR0ZW46KDI4LDk2OSksNjQsNjQ7UmVh
ZFRpbWU6KDI4LDk2OSksMTI4LDY0O1dyaXRlVGltZTooMjgsOTY5KSwxOTIsNjQ7UmVhZENv
dW50OigyNSwxNCksMjU2LDMyO1dyaXRlQ291bnQ6KDI1LDE0KSwyODgsMzI7UXVldWVEZXB0
aDooMjUsMTQpLDMyMCwzMjtfX2FzOjooMjgsOTc5KT0jIygyOCw5ODApPSYoMjgsOTc4KTs6
UkMxN19ESVNLX1BFUkZPUk1BTkNFOzJBLjtfRElTS19QRVJGT1JNQU5DRTo6KDI4LDk4MSk9
IyMoMjgsOTgyKT0qKDI4LDk3OCk7OlJDMTdfRElTS19QRVJGT1JNQU5DRTsyQS4oMjgsOTgz
KT0jIygyOCw5ODIpOzo7MkEuOzsARElTS19QRVJGT1JNQU5DRTp0KDI4LDk4NCk9KDI4LDk3
OCkAdGFnRExHSVRFTVRFTVBMQVRFOlR0KDI4LDk4NSk9czE4c3R5bGU6KDI1LDE0KSwwLDMy
O2R3RXh0ZW5kZWRTdHlsZTooMjUsMTQpLDMyLDMyO3g6KDAsOCksNjQsMTY7eTooMCw4KSw4
MCwxNjtjeDooMCw4KSw5NiwxNjtjeTooMCw4KSwxMTIsMTY7aWQ6KDI1LDE1MyksMTI4LDE2
O19fYXM6OigyOCw5ODYpPSMjKDI4LDk4Nyk9JigyOCw5ODUpOzpSQzE4dGFnRExHSVRFTVRF
TVBMQVRFOzJBLjt0YWdETEdJVEVNVEVNUExBVEU6OigyOCw5ODgpPSMjKDI4LDk4OSk9Kigy
OCw5ODUpOzpSQzE4dGFnRExHSVRFTVRFTVBMQVRFOzJBLigyOCw5OTApPSMjKDI4LDk4OSk7
OjsyQS47OwBETEdJVEVNVEVNUExBVEU6dCgyOCw5OTEpPSgyOCw5ODUpAExQRExHSVRFTVRF
TVBMQVRFOnQoMjgsOTkyKT0oMjgsOTg5KQBQRExHSVRFTVRFTVBMQVRFOnQoMjgsOTkzKT0o
MjgsOTg5KQB0YWdETEdURU1QTEFURTpUdCgyOCw5OTQpPXMxOHN0eWxlOigyNSwxNCksMCwz
Mjtkd0V4dGVuZGVkU3R5bGU6KDI1LDE0KSwzMiwzMjtjZGl0OigyNSwxNTMpLDY0LDE2O3g6
KDAsOCksODAsMTY7eTooMCw4KSw5NiwxNjtjeDooMCw4KSwxMTIsMTY7Y3k6KDAsOCksMTI4
LDE2O19fYXM6OigyOCw5OTUpPSMjKDI4LDk5Nik9JigyOCw5OTQpOzpSQzE0dGFnRExHVEVN
UExBVEU7MkEuO3RhZ0RMR1RFTVBMQVRFOjooMjgsOTk3KT0jIygyOCw5OTgpPSooMjgsOTk0
KTs6UkMxNHRhZ0RMR1RFTVBMQVRFOzJBLigyOCw5OTkpPSMjKDI4LDk5OCk7OjsyQS47OwBE
TEdURU1QTEFURTp0KDI4LDEwMDApPSgyOCw5OTQpAExQRExHVEVNUExBVEU6dCgyOCwxMDAx
KT0oMjgsOTk4KQBMUENETEdURU1QTEFURTp0KDI4LDEwMDIpPSgyOCw5OTgpAF9ET0NfSU5G
T18xOlR0KDI4LDEwMDMpPXMxMnBEb2NOYW1lOigyNSw5NiksMCwzMjtwT3V0cHV0RmlsZToo
MjUsOTYpLDMyLDMyO3BEYXRhdHlwZTooMjUsOTYpLDY0LDMyO19fYXM6OigyOCwxMDA0KT0j
IygyOCwxMDA1KT0mKDI4LDEwMDMpOzpSQzExX0RPQ19JTkZPXzE7MkEuO19ET0NfSU5GT18x
OjooMjgsMTAwNik9IyMoMjgsMTAwNyk9KigyOCwxMDAzKTs6UkMxMV9ET0NfSU5GT18xOzJB
LigyOCwxMDA4KT0jIygyOCwxMDA3KTs6OzJBLjs7AERPQ19JTkZPXzE6dCgyOCwxMDA5KT0o
MjgsMTAwMykAX0RPQ19JTkZPXzI6VHQoMjgsMTAxMCk9czIwcERvY05hbWU6KDI1LDk2KSww
LDMyO3BPdXRwdXRGaWxlOigyNSw5NiksMzIsMzI7cERhdGF0eXBlOigyNSw5NiksNjQsMzI7
ZHdNb2RlOigyNSwxNCksOTYsMzI7Sm9iSWQ6KDI1LDE0KSwxMjgsMzI7X19hczo6KDI4LDEw
MTEpPSMjKDI4LDEwMTIpPSYoMjgsMTAxMCk7OlJDMTFfRE9DX0lORk9fMjsyQS47X0RPQ19J
TkZPXzI6OigyOCwxMDEzKT0jIygyOCwxMDE0KT0qKDI4LDEwMTApOzpSQzExX0RPQ19JTkZP
XzI7MkEuKDI4LDEwMTUpPSMjKDI4LDEwMTQpOzo7MkEuOzsARE9DX0lORk9fMjp0KDI4LDEw
MTYpPSgyOCwxMDEwKQBET0NJTkZPOnQoMjgsMTAxNyk9czIwY2JTaXplOigwLDEpLDAsMzI7
bHBzekRvY05hbWU6KDI1LDgzKSwzMiwzMjtscHN6T3V0cHV0OigyNSw4MyksNjQsMzI7bHBz
ekRhdGF0eXBlOigyNSw4MyksOTYsMzI7ZndUeXBlOigyNSwxNCksMTI4LDMyO19fYXM6Oigy
OCwxMDE4KT0jKDI4LDEwMTcpLCgyOCwxMDE5KT0mKDI4LDEwMTcpLCgyOCwxMDIwKT0qKDI4
LDEwMTcpLCgyOCwxMDIxKT0mKDI4LDEwMjIpPXMyMGNiU2l6ZTooMCwxKSwwLDMyO2xwc3pE
b2NOYW1lOigyNSw4MyksMzIsMzI7bHBzek91dHB1dDooMjUsODMpLDY0LDMyO2xwc3pEYXRh
dHlwZTooMjUsODMpLDk2LDMyO2Z3VHlwZTooMjUsMTQpLDEyOCwzMjtfX2FzOjooMjgsMTAx
OCk6X19hc19fNCRfMTNSQzQkXzEzOzJBLjskXzEzOjooMjgsMTAyMyk9IygyOCwxMDE3KSwo
MjgsMTAyMCksKDI4LDEwMjApLCgyOCwxMDIxKSwoMCwyMCk7Ol9fNCRfMTNSQzQkXzEzOzJB
LigyOCwxMDI0KT0jKDI4LDEwMTcpLCgyOCwxMDIwKSwoMjgsMTAyMCksKDAsMjApOzpfXzQk
XzEzOzJBLjs7LCgwLDIwKTs6X19hc19fNCRfMTNSQzQkXzEzOzJBLjskXzEzOjooMjgsMTAy
Myk6X180JF8xM1JDNCRfMTM7MkEuKDI4LDEwMjQpOl9fNCRfMTM7MkEuOzsATFBET0NJTkZP
OnQoMjgsMTAyNSk9KDI4LDEwMjApAERSQUdMSVNUSU5GTzp0KDI4LDEwMjYpPXMxNnVOb3Rp
ZmljYXRpb246KDI1LDE1MCksMCwzMjtoV25kOigyNSw2MSksMzIsMzI7cHRDdXJzb3I6KDI4
LDMwOSksNjQsNjQ7X19hczo6KDI4LDEwMjcpPSMoMjgsMTAyNiksKDI4LDEwMjgpPSYoMjgs
MTAyNiksKDI4LDEwMjkpPSooMjgsMTAyNiksKDI4LDEwMzApPSYoMjgsMTAzMSk9czE2dU5v
dGlmaWNhdGlvbjooMjUsMTUwKSwwLDMyO2hXbmQ6KDI1LDYxKSwzMiwzMjtwdEN1cnNvcjoo
MjgsMzA5KSw2NCw2NDtfX2FzOjooMjgsMTAyNyk6X19hc19fNCRfMTRSQzQkXzE0OzJBLjsk
XzE0OjooMjgsMTAzMik9IygyOCwxMDI2KSwoMjgsMTAyOSksKDI4LDEwMjkpLCgyOCwxMDMw
KSwoMCwyMCk7Ol9fNCRfMTRSQzQkXzE0OzJBLigyOCwxMDMzKT0jKDI4LDEwMjYpLCgyOCwx
MDI5KSwoMjgsMTAyOSksKDAsMjApOzpfXzQkXzE0OzJBLjs7LCgwLDIwKTs6X19hc19fNCRf
MTRSQzQkXzE0OzJBLjskXzE0OjooMjgsMTAzMik6X180JF8xNFJDNCRfMTQ7MkEuKDI4LDEw
MzMpOl9fNCRfMTQ7MkEuOzsATFBEUkFHTElTVElORk86dCgyOCwxMDM0KT0oMjgsMTAyOSkA
dGFnRFJBV0lURU1TVFJVQ1Q6VHQoMjgsMTAzNSk9czQ4Q3RsVHlwZTooMjUsMTUwKSwwLDMy
O0N0bElEOigyNSwxNTApLDMyLDMyO2l0ZW1JRDooMjUsMTUwKSw2NCwzMjtpdGVtQWN0aW9u
OigyNSwxNTApLDk2LDMyO2l0ZW1TdGF0ZTooMjUsMTUwKSwxMjgsMzI7aHduZEl0ZW06KDI1
LDYxKSwxNjAsMzI7aERDOigyNSwyOCksMTkyLDMyO3JjSXRlbTooMjgsMTEzKSwyMjQsMTI4
O2l0ZW1EYXRhOigyNSwxNCksMzUyLDMyO19fYXM6OigyOCwxMDM2KT0jIygyOCwxMDM3KT0m
KDI4LDEwMzUpOzpSQzE3dGFnRFJBV0lURU1TVFJVQ1Q7MkEuO3RhZ0RSQVdJVEVNU1RSVUNU
OjooMjgsMTAzOCk9IyMoMjgsMTAzOSk9KigyOCwxMDM1KTs6UkMxN3RhZ0RSQVdJVEVNU1RS
VUNUOzJBLigyOCwxMDQwKT0jIygyOCwxMDM5KTs6OzJBLjs7AERSQVdJVEVNU1RSVUNUOnQo
MjgsMTA0MSk9KDI4LDEwMzUpAExQRFJBV0lURU1TVFJVQ1Q6dCgyOCwxMDQyKT0oMjgsMTAz
OSkAUERSQVdJVEVNU1RSVUNUOnQoMjgsMTA0Myk9KDI4LDEwMzkpAERSQVdURVhUUEFSQU1T
OnQoMjgsMTA0NCk9czIwY2JTaXplOigyNSwxNTApLDAsMzI7aVRhYkxlbmd0aDooMCwxKSwz
MiwzMjtpTGVmdE1hcmdpbjooMCwxKSw2NCwzMjtpUmlnaHRNYXJnaW46KDAsMSksOTYsMzI7
dWlMZW5ndGhEcmF3bjooMjUsMTUwKSwxMjgsMzI7X19hczo6KDI4LDEwNDUpPSMoMjgsMTA0
NCksKDI4LDEwNDYpPSYoMjgsMTA0NCksKDI4LDEwNDcpPSooMjgsMTA0NCksKDI4LDEwNDgp
PSYoMjgsMTA0OSk9czIwY2JTaXplOigyNSwxNTApLDAsMzI7aVRhYkxlbmd0aDooMCwxKSwz
MiwzMjtpTGVmdE1hcmdpbjooMCwxKSw2NCwzMjtpUmlnaHRNYXJnaW46KDAsMSksOTYsMzI7
dWlMZW5ndGhEcmF3bjooMjUsMTUwKSwxMjgsMzI7X19hczo6KDI4LDEwNDUpOl9fYXNfXzQk
XzE1UkM0JF8xNTsyQS47JF8xNTo6KDI4LDEwNTApPSMoMjgsMTA0NCksKDI4LDEwNDcpLCgy
OCwxMDQ3KSwoMjgsMTA0OCksKDAsMjApOzpfXzQkXzE1UkM0JF8xNTsyQS4oMjgsMTA1MSk9
IygyOCwxMDQ0KSwoMjgsMTA0NyksKDI4LDEwNDcpLCgwLDIwKTs6X180JF8xNTsyQS47Oywo
MCwyMCk7Ol9fYXNfXzQkXzE1UkM0JF8xNTsyQS47JF8xNTo6KDI4LDEwNTApOl9fNCRfMTVS
QzQkXzE1OzJBLigyOCwxMDUxKTpfXzQkXzE1OzJBLjs7AExQRFJBV1RFWFRQQVJBTVM6dCgy
OCwxMDUyKT0oMjgsMTA0NykAX1BBUlRJVElPTl9JTkZPUk1BVElPTjpUdCgyOCwxMDUzKT1z
MjhQYXJ0aXRpb25UeXBlOigyNSw1KSwwLDg7Qm9vdEluZGljYXRvcjooMjUsNCksOCw4O1Jl
Y29nbml6ZWRQYXJ0aXRpb246KDI1LDQpLDE2LDg7UmV3cml0ZVBhcnRpdGlvbjooMjUsNCks
MjQsODtTdGFydGluZ09mZnNldDooMjgsOTY5KSwzMiw2NDtQYXJ0aXRpb25MZW5ndGg6KDI4
LDk2OSksOTYsNjQ7SGlkZGVuU2VjdG9yczooMjgsOTY5KSwxNjAsNjQ7X19hczo6KDI4LDEw
NTQpPSMjKDI4LDEwNTUpPSYoMjgsMTA1Myk7OlJDMjJfUEFSVElUSU9OX0lORk9STUFUSU9O
OzJBLjtfUEFSVElUSU9OX0lORk9STUFUSU9OOjooMjgsMTA1Nik9IyMoMjgsMTA1Nyk9Kigy
OCwxMDUzKTs6UkMyMl9QQVJUSVRJT05fSU5GT1JNQVRJT047MkEuKDI4LDEwNTgpPSMjKDI4
LDEwNTcpOzo7MkEuOzsAUEFSVElUSU9OX0lORk9STUFUSU9OOnQoMjgsMTA1OSk9KDI4LDEw
NTMpAF9EUklWRV9MQVlPVVRfSU5GT1JNQVRJT046VHQoMjgsMTA2MCk9czM2UGFydGl0aW9u
Q291bnQ6KDI1LDE0KSwwLDMyO1NpZ25hdHVyZTooMjUsMTQpLDMyLDMyO1BhcnRpdGlvbkVu
dHJ5OigyOCwxMDYxKT1hcigwLDEpOzA7MDsoMjgsMTA1MyksNjQsMjI0O19fYXM6OigyOCwx
MDYyKT0jIygyOCwxMDYzKT0mKDI4LDEwNjApOzpSQzI1X0RSSVZFX0xBWU9VVF9JTkZPUk1B
VElPTjsyQS47X0RSSVZFX0xBWU9VVF9JTkZPUk1BVElPTjo6KDI4LDEwNjQpPSMjKDI4LDEw
NjUpPSooMjgsMTA2MCk7OlJDMjVfRFJJVkVfTEFZT1VUX0lORk9STUFUSU9OOzJBLigyOCwx
MDY2KT0jIygyOCwxMDY1KTs6OzJBLjs7AERSSVZFX0xBWU9VVF9JTkZPUk1BVElPTjp0KDI4
LDEwNjcpPSgyOCwxMDYwKQBfRFJJVkVSX0lORk9fMTpUdCgyOCwxMDY4KT1zNHBOYW1lOigy
NSw5NiksMCwzMjtfX2FzOjooMjgsMTA2OSk9IyMoMjgsMTA3MCk9JigyOCwxMDY4KTs6UkMx
NF9EUklWRVJfSU5GT18xOzJBLjtfRFJJVkVSX0lORk9fMTo6KDI4LDEwNzEpPSMjKDI4LDEw
NzIpPSooMjgsMTA2OCk7OlJDMTRfRFJJVkVSX0lORk9fMTsyQS4oMjgsMTA3Myk9IyMoMjgs
MTA3Mik7OjsyQS47OwBEUklWRVJfSU5GT18xOnQoMjgsMTA3NCk9KDI4LDEwNjgpAF9EUklW
RVJfSU5GT18yOlR0KDI4LDEwNzUpPXMyNGNWZXJzaW9uOigyNSwxNCksMCwzMjtwTmFtZToo
MjUsOTYpLDMyLDMyO3BFbnZpcm9ubWVudDooMjUsOTYpLDY0LDMyO3BEcml2ZXJQYXRoOigy
NSw5NiksOTYsMzI7cERhdGFGaWxlOigyNSw5NiksMTI4LDMyO3BDb25maWdGaWxlOigyNSw5
NiksMTYwLDMyO19fYXM6OigyOCwxMDc2KT0jIygyOCwxMDc3KT0mKDI4LDEwNzUpOzpSQzE0
X0RSSVZFUl9JTkZPXzI7MkEuO19EUklWRVJfSU5GT18yOjooMjgsMTA3OCk9IyMoMjgsMTA3
OSk9KigyOCwxMDc1KTs6UkMxNF9EUklWRVJfSU5GT18yOzJBLigyOCwxMDgwKT0jIygyOCwx
MDc5KTs6OzJBLjs7AERSSVZFUl9JTkZPXzI6dCgyOCwxMDgxKT0oMjgsMTA3NSkAX0RSSVZF
Ul9JTkZPXzM6VHQoMjgsMTA4Mik9czQwY1ZlcnNpb246KDI1LDE0KSwwLDMyO3BOYW1lOigy
NSw5NiksMzIsMzI7cEVudmlyb25tZW50OigyNSw5NiksNjQsMzI7cERyaXZlclBhdGg6KDI1
LDk2KSw5NiwzMjtwRGF0YUZpbGU6KDI1LDk2KSwxMjgsMzI7cENvbmZpZ0ZpbGU6KDI1LDk2
KSwxNjAsMzI7cEhlbHBGaWxlOigyNSw5NiksMTkyLDMyO3BEZXBlbmRlbnRGaWxlczooMjUs
OTYpLDIyNCwzMjtwTW9uaXRvck5hbWU6KDI1LDk2KSwyNTYsMzI7cERlZmF1bHREYXRhVHlw
ZTooMjUsOTYpLDI4OCwzMjtfX2FzOjooMjgsMTA4Myk9IyMoMjgsMTA4NCk9JigyOCwxMDgy
KTs6UkMxNF9EUklWRVJfSU5GT18zOzJBLjtfRFJJVkVSX0lORk9fMzo6KDI4LDEwODUpPSMj
KDI4LDEwODYpPSooMjgsMTA4Mik7OlJDMTRfRFJJVkVSX0lORk9fMzsyQS4oMjgsMTA4Nyk9
IyMoMjgsMTA4Nik7OjsyQS47OwBEUklWRVJfSU5GT18zOnQoMjgsMTA4OCk9KDI4LDEwODIp
AF9lZGl0c3RyZWFtOlR0KDI4LDEwODkpPXMxMmR3Q29va2llOigyNSwxNCksMCwzMjtkd0Vy
cm9yOigyNSwxNCksMzIsMzI7cGZuQ2FsbGJhY2s6KDI1LDE4NCksNjQsMzI7X19hczo6KDI4
LDEwOTApPSMjKDI4LDEwOTEpPSYoMjgsMTA4OSk7OlJDMTFfZWRpdHN0cmVhbTsyQS47X2Vk
aXRzdHJlYW06OigyOCwxMDkyKT0jIygyOCwxMDkzKT0qKDI4LDEwODkpOzpSQzExX2VkaXRz
dHJlYW07MkEuKDI4LDEwOTQpPSMjKDI4LDEwOTMpOzo7MkEuOzsARURJVFNUUkVBTTp0KDI4
LDEwOTUpPSgyOCwxMDg5KQB0YWdFTVI6VHQoMjgsMTA5Nik9czhpVHlwZTooMjUsMTQpLDAs
MzI7blNpemU6KDI1LDE0KSwzMiwzMjtfX2FzOjooMjgsMTA5Nyk9IyMoMjgsMTA5OCk9Jigy
OCwxMDk2KTs6UkM2dGFnRU1SOzJBLjt0YWdFTVI6OigyOCwxMDk5KT0jIygyOCwxMTAwKT0q
KDI4LDEwOTYpOzpSQzZ0YWdFTVI7MkEuKDI4LDExMDEpPSMjKDI4LDExMDApOzo7MkEuOzsA
RU1SOnQoMjgsMTEwMik9KDI4LDEwOTYpAFBFTVI6dCgyOCwxMTAzKT0oMjgsMTEwMCkAdGFn
RU1SQU5HTEVBUkM6VHQoMjgsMTEwNCk9czI4ZW1yOigyOCwxMTAyKSwwLDY0O3B0bENlbnRl
cjooMjgsMzI1KSw2NCw2NDtuUmFkaXVzOigyNSwxNCksMTI4LDMyO2VTdGFydEFuZ2xlOigy
NSwxOCksMTYwLDMyO2VTd2VlcEFuZ2xlOigyNSwxOCksMTkyLDMyO19fYXM6OigyOCwxMTA1
KT0jIygyOCwxMTA2KT0mKDI4LDExMDQpOzpSQzE0dGFnRU1SQU5HTEVBUkM7MkEuO3RhZ0VN
UkFOR0xFQVJDOjooMjgsMTEwNyk9IyMoMjgsMTEwOCk9KigyOCwxMTA0KTs6UkMxNHRhZ0VN
UkFOR0xFQVJDOzJBLigyOCwxMTA5KT0jIygyOCwxMTA4KTs6OzJBLjs7AEVNUkFOR0xFQVJD
OnQoMjgsMTExMCk9KDI4LDExMDQpAFBFTVJBTkdMRUFSQzp0KDI4LDExMTEpPSgyOCwxMTA4
KQB0YWdFTVJBUkM6VHQoMjgsMTExMik9czQwZW1yOigyOCwxMTAyKSwwLDY0O3JjbEJveDoo
MjgsMTIyKSw2NCwxMjg7cHRsU3RhcnQ6KDI4LDMyNSksMTkyLDY0O3B0bEVuZDooMjgsMzI1
KSwyNTYsNjQ7X19hczo6KDI4LDExMTMpPSMjKDI4LDExMTQpPSYoMjgsMTExMik7OlJDOXRh
Z0VNUkFSQzsyQS47dGFnRU1SQVJDOjooMjgsMTExNSk9IyMoMjgsMTExNik9KigyOCwxMTEy
KTs6UkM5dGFnRU1SQVJDOzJBLigyOCwxMTE3KT0jIygyOCwxMTE2KTs6OzJBLjs7AEVNUkFS
Qzp0KDI4LDExMTgpPSgyOCwxMTEyKQBQRU1SQVJDOnQoMjgsMTExOSk9KDI4LDExMTYpAEVN
UkFSQ1RPOnQoMjgsMTEyMCk9KDI4LDExMTIpAFBFTVJBUkNUTzp0KDI4LDExMjEpPSgyOCwx
MTE2KQBFTVJDSE9SRDp0KDI4LDExMjIpPSgyOCwxMTEyKQBQRU1SQ0hPUkQ6dCgyOCwxMTIz
KT0oMjgsMTExNikARU1SUElFOnQoMjgsMTEyNCk9KDI4LDExMTIpAFBFTVJQSUU6dCgyOCwx
MTI1KT0oMjgsMTExNikAX1hGT1JNOlR0KDI4LDExMjYpPXMyNGVNMTE6KDI1LDE4KSwwLDMy
O2VNMTI6KDI1LDE4KSwzMiwzMjtlTTIxOigyNSwxOCksNjQsMzI7ZU0yMjooMjUsMTgpLDk2
LDMyO2VEeDooMjUsMTgpLDEyOCwzMjtlRHk6KDI1LDE4KSwxNjAsMzI7X19hczo6KDI4LDEx
MjcpPSMjKDI4LDExMjgpPSYoMjgsMTEyNik7OlJDNl9YRk9STTsyQS47X1hGT1JNOjooMjgs
MTEyOSk9IyMoMjgsMTEzMCk9KigyOCwxMTI2KTs6UkM2X1hGT1JNOzJBLigyOCwxMTMxKT0j
IygyOCwxMTMwKTs6OzJBLjs7AFhGT1JNOnQoMjgsMTEzMik9KDI4LDExMjYpAFBYRk9STTp0
KDI4LDExMzMpPSgyOCwxMTMwKQBMUFhGT1JNOnQoMjgsMTEzNCk9KDI4LDExMzApAHRhZ0VN
UkJJVEJMVDpUdCgyOCwxMTM1KT1zOTZlbXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigy
OCwxMjIpLDY0LDEyODt4RGVzdDooMjUsMTMpLDE5MiwzMjt5RGVzdDooMjUsMTMpLDIyNCwz
MjtjeERlc3Q6KDI1LDEzKSwyNTYsMzI7Y3lEZXN0OigyNSwxMyksMjg4LDMyO2R3Um9wOigy
NSwxNCksMzIwLDMyO3hTcmM6KDI1LDEzKSwzNTIsMzI7eVNyYzooMjUsMTMpLDM4NCwzMjt4
Zm9ybVNyYzooMjgsMTEzMiksNDE2LDE5MjtjckJrQ29sb3JTcmM6KDI1LDkpLDYwOCwzMjtp
VXNhZ2VTcmM6KDI1LDE0KSw2NDAsMzI7b2ZmQm1pU3JjOigyNSwxNCksNjcyLDMyO29mZkJp
dHNTcmM6KDI1LDE0KSw3MDQsMzI7Y2JCaXRzU3JjOigyNSwxNCksNzM2LDMyO19fYXM6Oigy
OCwxMTM2KT0jIygyOCwxMTM3KT0mKDI4LDExMzUpOzpSQzEydGFnRU1SQklUQkxUOzJBLjt0
YWdFTVJCSVRCTFQ6OigyOCwxMTM4KT0jIygyOCwxMTM5KT0qKDI4LDExMzUpOzpSQzEydGFn
RU1SQklUQkxUOzJBLigyOCwxMTQwKT0jIygyOCwxMTM5KTs6OzJBLjs7AEVNUkJJVEJMVDp0
KDI4LDExNDEpPSgyOCwxMTM1KQBQRU1SQklUQkxUOnQoMjgsMTE0Mik9KDI4LDExMzkpAHRh
Z0xPR0JSVVNIOlR0KDI4LDExNDMpPXMxMmxiU3R5bGU6KDI1LDE1MCksMCwzMjtsYkNvbG9y
OigyNSw5KSwzMiwzMjtsYkhhdGNoOigyNSwxMyksNjQsMzI7X19hczo6KDI4LDExNDQpPSMj
KDI4LDExNDUpPSYoMjgsMTE0Myk7OlJDMTF0YWdMT0dCUlVTSDsyQS47dGFnTE9HQlJVU0g6
OigyOCwxMTQ2KT0jIygyOCwxMTQ3KT0qKDI4LDExNDMpOzpSQzExdGFnTE9HQlJVU0g7MkEu
KDI4LDExNDgpPSMjKDI4LDExNDcpOzo7MkEuOzsATE9HQlJVU0g6dCgyOCwxMTQ5KT0oMjgs
MTE0MykAdGFnRU1SQ1JFQVRFQlJVU0hJTkRJUkVDVDpUdCgyOCwxMTUwKT1zMjRlbXI6KDI4
LDExMDIpLDAsNjQ7aWhCcnVzaDooMjUsMTQpLDY0LDMyO2xiOigyOCwxMTQ5KSw5Niw5Njtf
X2FzOjooMjgsMTE1MSk9IyMoMjgsMTE1Mik9JigyOCwxMTUwKTs6UkMyNXRhZ0VNUkNSRUFU
RUJSVVNISU5ESVJFQ1Q7MkEuO3RhZ0VNUkNSRUFURUJSVVNISU5ESVJFQ1Q6OigyOCwxMTUz
KT0jIygyOCwxMTU0KT0qKDI4LDExNTApOzpSQzI1dGFnRU1SQ1JFQVRFQlJVU0hJTkRJUkVD
VDsyQS4oMjgsMTE1NSk9IyMoMjgsMTE1NCk7OjsyQS47OwBFTVJDUkVBVEVCUlVTSElORElS
RUNUOnQoMjgsMTE1Nik9KDI4LDExNTApAFBFTVJDUkVBVEVCUlVTSElORElSRUNUOnQoMjgs
MTE1Nyk9KDI4LDExNTQpAExDU0NTVFlQRTp0KDI4LDExNTgpPSgyNSwxMykATENTR0FNVVRN
QVRDSDp0KDI4LDExNTkpPSgyNSwxMykAdGFnTE9HQ09MT1JTUEFDRTpUdCgyOCwxMTYwKT1z
MzI4bGNzU2lnbmF0dXJlOigyNSwxNCksMCwzMjtsY3NWZXJzaW9uOigyNSwxNCksMzIsMzI7
bGNzU2l6ZTooMjUsMTQpLDY0LDMyO2xjc0NTVHlwZTooMjgsMTE1OCksOTYsMzI7bGNzSW50
ZW50OigyOCwxMTU5KSwxMjgsMzI7bGNzRW5kcG9pbnRzOigyOCwyMzApLDE2MCwyODg7bGNz
R2FtbWFSZWQ6KDI1LDE0KSw0NDgsMzI7bGNzR2FtbWFHcmVlbjooMjUsMTQpLDQ4MCwzMjts
Y3NHYW1tYUJsdWU6KDI1LDE0KSw1MTIsMzI7bGNzRmlsZW5hbWU6KDI4LDExNjEpPWFyKDAs
MSk7MDsyNTk7KDAsMiksNTQ0LDIwODA7X19hczo6KDI4LDExNjIpPSMjKDI4LDExNjMpPSYo
MjgsMTE2MCk7OlJDMTZ0YWdMT0dDT0xPUlNQQUNFOzJBLjt0YWdMT0dDT0xPUlNQQUNFOjoo
MjgsMTE2NCk9IyMoMjgsMTE2NSk9KigyOCwxMTYwKTs6UkMxNnRhZ0xPR0NPTE9SU1BBQ0U7
MkEuKDI4LDExNjYpPSMjKDI4LDExNjUpOzo7MkEuOzsATE9HQ09MT1JTUEFDRTp0KDI4LDEx
NjcpPSgyOCwxMTYwKQBMUExPR0NPTE9SU1BBQ0U6dCgyOCwxMTY4KT0oMjgsMTE2NSkAdGFn
RU1SQ1JFQVRFQ09MT1JTUEFDRTpUdCgyOCwxMTY5KT1zMzQwZW1yOigyOCwxMTAyKSwwLDY0
O2loQ1M6KDI1LDE0KSw2NCwzMjtsY3M6KDI4LDExNjcpLDk2LDI2MjQ7X19hczo6KDI4LDEx
NzApPSMjKDI4LDExNzEpPSYoMjgsMTE2OSk7OlJDMjJ0YWdFTVJDUkVBVEVDT0xPUlNQQUNF
OzJBLjt0YWdFTVJDUkVBVEVDT0xPUlNQQUNFOjooMjgsMTE3Mik9IyMoMjgsMTE3Myk9Kigy
OCwxMTY5KTs6UkMyMnRhZ0VNUkNSRUFURUNPTE9SU1BBQ0U7MkEuKDI4LDExNzQpPSMjKDI4
LDExNzMpOzo7MkEuOzsARU1SQ1JFQVRFQ09MT1JTUEFDRTp0KDI4LDExNzUpPSgyOCwxMTY5
KQBQRU1SQ1JFQVRFQ09MT1JTUEFDRTp0KDI4LDExNzYpPSgyOCwxMTczKQB0YWdFTVJDUkVB
VEVESUJQQVRURVJOQlJVU0hQVDpUdCgyOCwxMTc3KT1zMzJlbXI6KDI4LDExMDIpLDAsNjQ7
aWhCcnVzaDooMjUsMTQpLDY0LDMyO2lVc2FnZTooMjUsMTQpLDk2LDMyO29mZkJtaTooMjUs
MTQpLDEyOCwzMjtjYkJtaTooMjUsMTQpLDE2MCwzMjtvZmZCaXRzOigyNSwxNCksMTkyLDMy
O2NiQml0czooMjUsMTQpLDIyNCwzMjtfX2FzOjooMjgsMTE3OCk9IyMoMjgsMTE3OSk9Jigy
OCwxMTc3KTs6UkMyOXRhZ0VNUkNSRUFURURJQlBBVFRFUk5CUlVTSFBUOzJBLjt0YWdFTVJD
UkVBVEVESUJQQVRURVJOQlJVU0hQVDo6KDI4LDExODApPSMjKDI4LDExODEpPSooMjgsMTE3
Nyk7OlJDMjl0YWdFTVJDUkVBVEVESUJQQVRURVJOQlJVU0hQVDsyQS4oMjgsMTE4Mik9IyMo
MjgsMTE4MSk7OjsyQS47OwBFTVJDUkVBVEVESUJQQVRURVJOQlJVU0hQVDp0KDI4LDExODMp
PSgyOCwxMTc3KQBQRU1SQ1JFQVRFRElCUEFUVEVSTkJSVVNIUFQ6dCgyOCwxMTg0KT0oMjgs
MTE4MSkAdGFnRU1SQ1JFQVRFTU9OT0JSVVNIOlR0KDI4LDExODUpPXMzMmVtcjooMjgsMTEw
MiksMCw2NDtpaEJydXNoOigyNSwxNCksNjQsMzI7aVVzYWdlOigyNSwxNCksOTYsMzI7b2Zm
Qm1pOigyNSwxNCksMTI4LDMyO2NiQm1pOigyNSwxNCksMTYwLDMyO29mZkJpdHM6KDI1LDE0
KSwxOTIsMzI7Y2JCaXRzOigyNSwxNCksMjI0LDMyO19fYXM6OigyOCwxMTg2KT0jIygyOCwx
MTg3KT0mKDI4LDExODUpOzpSQzIxdGFnRU1SQ1JFQVRFTU9OT0JSVVNIOzJBLjt0YWdFTVJD
UkVBVEVNT05PQlJVU0g6OigyOCwxMTg4KT0jIygyOCwxMTg5KT0qKDI4LDExODUpOzpSQzIx
dGFnRU1SQ1JFQVRFTU9OT0JSVVNIOzJBLigyOCwxMTkwKT0jIygyOCwxMTg5KTs6OzJBLjs7
AEVNUkNSRUFURU1PTk9CUlVTSDp0KDI4LDExOTEpPSgyOCwxMTg1KQBQRU1SQ1JFQVRFTU9O
T0JSVVNIOnQoMjgsMTE5Mik9KDI4LDExODkpAHRhZ1BBTEVUVEVFTlRSWTpUdCgyOCwxMTkz
KT1zNHBlUmVkOigyNSw1KSwwLDg7cGVHcmVlbjooMjUsNSksOCw4O3BlQmx1ZTooMjUsNSks
MTYsODtwZUZsYWdzOigyNSw1KSwyNCw4O19fYXM6OigyOCwxMTk0KT0jIygyOCwxMTk1KT0m
KDI4LDExOTMpOzpSQzE1dGFnUEFMRVRURUVOVFJZOzJBLjt0YWdQQUxFVFRFRU5UUlk6Oigy
OCwxMTk2KT0jIygyOCwxMTk3KT0qKDI4LDExOTMpOzpSQzE1dGFnUEFMRVRURUVOVFJZOzJB
LigyOCwxMTk4KT0jIygyOCwxMTk3KTs6OzJBLjs7AFBBTEVUVEVFTlRSWTp0KDI4LDExOTkp
PSgyOCwxMTkzKQBMUFBBTEVUVEVFTlRSWTp0KDI4LDEyMDApPSgyOCwxMTk3KQBQUEFMRVRU
RUVOVFJZOnQoMjgsMTIwMSk9KDI4LDExOTcpAHRhZ0xPR1BBTEVUVEU6VHQoMjgsMTIwMik9
czhwYWxWZXJzaW9uOigyNSwxNTMpLDAsMTY7cGFsTnVtRW50cmllczooMjUsMTUzKSwxNiwx
NjtwYWxQYWxFbnRyeTooMjgsMTIwMyk9YXIoMCwxKTswOzA7KDI4LDExOTMpLDMyLDMyO19f
YXM6OigyOCwxMjA0KT0jIygyOCwxMjA1KT0mKDI4LDEyMDIpOzpSQzEzdGFnTE9HUEFMRVRU
RTsyQS47dGFnTE9HUEFMRVRURTo6KDI4LDEyMDYpPSMjKDI4LDEyMDcpPSooMjgsMTIwMik7
OlJDMTN0YWdMT0dQQUxFVFRFOzJBLigyOCwxMjA4KT0jIygyOCwxMjA3KTs6OzJBLjs7AExP
R1BBTEVUVEU6dCgyOCwxMjA5KT0oMjgsMTIwMikATFBMT0dQQUxFVFRFOnQoMjgsMTIxMCk9
KDI4LDEyMDcpAFBMT0dQQUxFVFRFOnQoMjgsMTIxMSk9KDI4LDEyMDcpAHRhZ0VNUkNSRUFU
RVBBTEVUVEU6VHQoMjgsMTIxMik9czIwZW1yOigyOCwxMTAyKSwwLDY0O2loUGFsOigyNSwx
NCksNjQsMzI7bGdwbDooMjgsMTIwOSksOTYsNjQ7X19hczo6KDI4LDEyMTMpPSMjKDI4LDEy
MTQpPSYoMjgsMTIxMik7OlJDMTl0YWdFTVJDUkVBVEVQQUxFVFRFOzJBLjt0YWdFTVJDUkVB
VEVQQUxFVFRFOjooMjgsMTIxNSk9IyMoMjgsMTIxNik9KigyOCwxMjEyKTs6UkMxOXRhZ0VN
UkNSRUFURVBBTEVUVEU7MkEuKDI4LDEyMTcpPSMjKDI4LDEyMTYpOzo7MkEuOzsARU1SQ1JF
QVRFUEFMRVRURTp0KDI4LDEyMTgpPSgyOCwxMjEyKQBQRU1SQ1JFQVRFUEFMRVRURTp0KDI4
LDEyMTkpPSgyOCwxMjE2KQB0YWdMT0dQRU46VHQoMjgsMTIyMCk9czE2bG9wblN0eWxlOigy
NSwxNTApLDAsMzI7bG9wbldpZHRoOigyOCwzMDkpLDMyLDY0O2xvcG5Db2xvcjooMjUsOSks
OTYsMzI7X19hczo6KDI4LDEyMjEpPSMjKDI4LDEyMjIpPSYoMjgsMTIyMCk7OlJDOXRhZ0xP
R1BFTjsyQS47dGFnTE9HUEVOOjooMjgsMTIyMyk9IyMoMjgsMTIyNCk9KigyOCwxMjIwKTs6
UkM5dGFnTE9HUEVOOzJBLigyOCwxMjI1KT0jIygyOCwxMjI0KTs6OzJBLjs7AExPR1BFTjp0
KDI4LDEyMjYpPSgyOCwxMjIwKQB0YWdFTVJDUkVBVEVQRU46VHQoMjgsMTIyNyk9czI4ZW1y
OigyOCwxMTAyKSwwLDY0O2loUGVuOigyNSwxNCksNjQsMzI7bG9wbjooMjgsMTIyNiksOTYs
MTI4O19fYXM6OigyOCwxMjI4KT0jIygyOCwxMjI5KT0mKDI4LDEyMjcpOzpSQzE1dGFnRU1S
Q1JFQVRFUEVOOzJBLjt0YWdFTVJDUkVBVEVQRU46OigyOCwxMjMwKT0jIygyOCwxMjMxKT0q
KDI4LDEyMjcpOzpSQzE1dGFnRU1SQ1JFQVRFUEVOOzJBLigyOCwxMjMyKT0jIygyOCwxMjMx
KTs6OzJBLjs7AEVNUkNSRUFURVBFTjp0KDI4LDEyMzMpPSgyOCwxMjI3KQBQRU1SQ1JFQVRF
UEVOOnQoMjgsMTIzNCk9KDI4LDEyMzEpAHRhZ0VNUkVMTElQU0U6VHQoMjgsMTIzNSk9czI0
ZW1yOigyOCwxMTAyKSwwLDY0O3JjbEJveDooMjgsMTIyKSw2NCwxMjg7X19hczo6KDI4LDEy
MzYpPSMjKDI4LDEyMzcpPSYoMjgsMTIzNSk7OlJDMTN0YWdFTVJFTExJUFNFOzJBLjt0YWdF
TVJFTExJUFNFOjooMjgsMTIzOCk9IyMoMjgsMTIzOSk9KigyOCwxMjM1KTs6UkMxM3RhZ0VN
UkVMTElQU0U7MkEuKDI4LDEyNDApPSMjKDI4LDEyMzkpOzo7MkEuOzsARU1SRUxMSVBTRTp0
KDI4LDEyNDEpPSgyOCwxMjM1KQBQRU1SRUxMSVBTRTp0KDI4LDEyNDIpPSgyOCwxMjM5KQBF
TVJSRUNUQU5HTEU6dCgyOCwxMjQzKT0oMjgsMTIzNSkAUEVNUlJFQ1RBTkdMRTp0KDI4LDEy
NDQpPSgyOCwxMjM5KQB0YWdFTVJFT0Y6VHQoMjgsMTI0NSk9czIwZW1yOigyOCwxMTAyKSww
LDY0O25QYWxFbnRyaWVzOigyNSwxNCksNjQsMzI7b2ZmUGFsRW50cmllczooMjUsMTQpLDk2
LDMyO25TaXplTGFzdDooMjUsMTQpLDEyOCwzMjtfX2FzOjooMjgsMTI0Nik9IyMoMjgsMTI0
Nyk9JigyOCwxMjQ1KTs6UkM5dGFnRU1SRU9GOzJBLjt0YWdFTVJFT0Y6OigyOCwxMjQ4KT0j
IygyOCwxMjQ5KT0qKDI4LDEyNDUpOzpSQzl0YWdFTVJFT0Y7MkEuKDI4LDEyNTApPSMjKDI4
LDEyNDkpOzo7MkEuOzsARU1SRU9GOnQoMjgsMTI1MSk9KDI4LDEyNDUpAFBFTVJFT0Y6dCgy
OCwxMjUyKT0oMjgsMTI0OSkAdGFnRU1SRVhDTFVERUNMSVBSRUNUOlR0KDI4LDEyNTMpPXMy
NGVtcjooMjgsMTEwMiksMCw2NDtyY2xDbGlwOigyOCwxMjIpLDY0LDEyODtfX2FzOjooMjgs
MTI1NCk9IyMoMjgsMTI1NSk9JigyOCwxMjUzKTs6UkMyMXRhZ0VNUkVYQ0xVREVDTElQUkVD
VDsyQS47dGFnRU1SRVhDTFVERUNMSVBSRUNUOjooMjgsMTI1Nik9IyMoMjgsMTI1Nyk9Kigy
OCwxMjUzKTs6UkMyMXRhZ0VNUkVYQ0xVREVDTElQUkVDVDsyQS4oMjgsMTI1OCk9IyMoMjgs
MTI1Nyk7OjsyQS47OwBFTVJFWENMVURFQ0xJUFJFQ1Q6dCgyOCwxMjU5KT0oMjgsMTI1MykA
UEVNUkVYQ0xVREVDTElQUkVDVDp0KDI4LDEyNjApPSgyOCwxMjU3KQBFTVJJTlRFUlNFQ1RD
TElQUkVDVDp0KDI4LDEyNjEpPSgyOCwxMjUzKQBQRU1SSU5URVJTRUNUQ0xJUFJFQ1Q6dCgy
OCwxMjYyKT0oMjgsMTI1NykAdGFnUEFOT1NFOlR0KDI4LDEyNjMpPXMxMGJGYW1pbHlUeXBl
OigyNSw1KSwwLDg7YlNlcmlmU3R5bGU6KDI1LDUpLDgsODtiV2VpZ2h0OigyNSw1KSwxNiw4
O2JQcm9wb3J0aW9uOigyNSw1KSwyNCw4O2JDb250cmFzdDooMjUsNSksMzIsODtiU3Ryb2tl
VmFyaWF0aW9uOigyNSw1KSw0MCw4O2JBcm1TdHlsZTooMjUsNSksNDgsODtiTGV0dGVyZm9y
bTooMjUsNSksNTYsODtiTWlkbGluZTooMjUsNSksNjQsODtiWEhlaWdodDooMjUsNSksNzIs
ODtfX2FzOjooMjgsMTI2NCk9IyMoMjgsMTI2NSk9JigyOCwxMjYzKTs6UkM5dGFnUEFOT1NF
OzJBLjt0YWdQQU5PU0U6OigyOCwxMjY2KT0jIygyOCwxMjY3KT0qKDI4LDEyNjMpOzpSQzl0
YWdQQU5PU0U7MkEuKDI4LDEyNjgpPSMjKDI4LDEyNjcpOzo7MkEuOzsAUEFOT1NFOnQoMjgs
MTI2OSk9KDI4LDEyNjMpAHRhZ0VYVExPR0ZPTlQ6VHQoMjgsMTI3MCk9czE5MmVsZkxvZ0Zv
bnQ6KDI4LDQ1NiksMCw0ODA7ZWxmRnVsbE5hbWU6KDI4LDEyNzEpPWFyKDAsMSk7MDs2Mzso
MCwxMSksNDgwLDUxMjtlbGZTdHlsZTooMjgsOTM0KSw5OTIsMjU2O2VsZlZlcnNpb246KDI1
LDE0KSwxMjQ4LDMyO2VsZlN0eWxlU2l6ZTooMjUsMTQpLDEyODAsMzI7ZWxmTWF0Y2g6KDI1
LDE0KSwxMzEyLDMyO2VsZlJlc2VydmVkOigyNSwxNCksMTM0NCwzMjtlbGZWZW5kb3JJZDoo
MjgsMTI3Mik9YXIoMCwxKTswOzM7KDAsMTEpLDEzNzYsMzI7ZWxmQ3VsdHVyZTooMjUsMTQp
LDE0MDgsMzI7ZWxmUGFub3NlOigyOCwxMjY5KSwxNDQwLDgwO19fYXM6OigyOCwxMjczKT0j
IygyOCwxMjc0KT0mKDI4LDEyNzApOzpSQzEzdGFnRVhUTE9HRk9OVDsyQS47dGFnRVhUTE9H
Rk9OVDo6KDI4LDEyNzUpPSMjKDI4LDEyNzYpPSooMjgsMTI3MCk7OlJDMTN0YWdFWFRMT0dG
T05UOzJBLigyOCwxMjc3KT0jIygyOCwxMjc2KTs6OzJBLjs7AEVYVExPR0ZPTlQ6dCgyOCwx
Mjc4KT0oMjgsMTI3MCkAdGFnRU1SRVhUQ1JFQVRFRk9OVElORElSRUNUVzpUdCgyOCwxMjc5
KT1zMjA0ZW1yOigyOCwxMTAyKSwwLDY0O2loRm9udDooMjUsMTQpLDY0LDMyO2VsZnc6KDI4
LDEyNzgpLDk2LDE1MzY7X19hczo6KDI4LDEyODApPSMjKDI4LDEyODEpPSYoMjgsMTI3OSk7
OlJDMjh0YWdFTVJFWFRDUkVBVEVGT05USU5ESVJFQ1RXOzJBLjt0YWdFTVJFWFRDUkVBVEVG
T05USU5ESVJFQ1RXOjooMjgsMTI4Mik9IyMoMjgsMTI4Myk9KigyOCwxMjc5KTs6UkMyOHRh
Z0VNUkVYVENSRUFURUZPTlRJTkRJUkVDVFc7MkEuKDI4LDEyODQpPSMjKDI4LDEyODMpOzo7
MkEuOzsARU1SRVhUQ1JFQVRFRk9OVElORElSRUNUVzp0KDI4LDEyODUpPSgyOCwxMjc5KQBQ
RU1SRVhUQ1JFQVRFRk9OVElORElSRUNUVzp0KDI4LDEyODYpPSgyOCwxMjgzKQB0YWdFWFRM
T0dQRU46VHQoMjgsMTI4Nyk9czI4ZWxwUGVuU3R5bGU6KDI1LDE1MCksMCwzMjtlbHBXaWR0
aDooMjUsMTUwKSwzMiwzMjtlbHBCcnVzaFN0eWxlOigyNSwxNTApLDY0LDMyO2VscENvbG9y
OigyNSw5KSw5NiwzMjtlbHBIYXRjaDooMjUsMTMpLDEyOCwzMjtlbHBOdW1FbnRyaWVzOigy
NSwxNCksMTYwLDMyO2VscFN0eWxlRW50cnk6KDI4LDM0MiksMTkyLDMyO19fYXM6OigyOCwx
Mjg4KT0jIygyOCwxMjg5KT0mKDI4LDEyODcpOzpSQzEydGFnRVhUTE9HUEVOOzJBLjt0YWdF
WFRMT0dQRU46OigyOCwxMjkwKT0jIygyOCwxMjkxKT0qKDI4LDEyODcpOzpSQzEydGFnRVhU
TE9HUEVOOzJBLigyOCwxMjkyKT0jIygyOCwxMjkxKTs6OzJBLjs7AEVYVExPR1BFTjp0KDI4
LDEyOTMpPSgyOCwxMjg3KQB0YWdFTVJFWFRDUkVBVEVQRU46VHQoMjgsMTI5NCk9czU2ZW1y
OigyOCwxMTAyKSwwLDY0O2loUGVuOigyNSwxNCksNjQsMzI7b2ZmQm1pOigyNSwxNCksOTYs
MzI7Y2JCbWk6KDI1LDE0KSwxMjgsMzI7b2ZmQml0czooMjUsMTQpLDE2MCwzMjtjYkJpdHM6
KDI1LDE0KSwxOTIsMzI7ZWxwOigyOCwxMjkzKSwyMjQsMjI0O19fYXM6OigyOCwxMjk1KT0j
IygyOCwxMjk2KT0mKDI4LDEyOTQpOzpSQzE4dGFnRU1SRVhUQ1JFQVRFUEVOOzJBLjt0YWdF
TVJFWFRDUkVBVEVQRU46OigyOCwxMjk3KT0jIygyOCwxMjk4KT0qKDI4LDEyOTQpOzpSQzE4
dGFnRU1SRVhUQ1JFQVRFUEVOOzJBLigyOCwxMjk5KT0jIygyOCwxMjk4KTs6OzJBLjs7AEVN
UkVYVENSRUFURVBFTjp0KDI4LDEzMDApPSgyOCwxMjk0KQBQRU1SRVhUQ1JFQVRFUEVOOnQo
MjgsMTMwMSk9KDI4LDEyOTgpAHRhZ0VNUkVYVEZMT09ERklMTDpUdCgyOCwxMzAyKT1zMjRl
bXI6KDI4LDExMDIpLDAsNjQ7cHRsU3RhcnQ6KDI4LDMyNSksNjQsNjQ7Y3JDb2xvcjooMjUs
OSksMTI4LDMyO2lNb2RlOigyNSwxNCksMTYwLDMyO19fYXM6OigyOCwxMzAzKT0jIygyOCwx
MzA0KT0mKDI4LDEzMDIpOzpSQzE4dGFnRU1SRVhURkxPT0RGSUxMOzJBLjt0YWdFTVJFWFRG
TE9PREZJTEw6OigyOCwxMzA1KT0jIygyOCwxMzA2KT0qKDI4LDEzMDIpOzpSQzE4dGFnRU1S
RVhURkxPT0RGSUxMOzJBLigyOCwxMzA3KT0jIygyOCwxMzA2KTs6OzJBLjs7AEVNUkVYVEZM
T09ERklMTDp0KDI4LDEzMDgpPSgyOCwxMzAyKQBQRU1SRVhURkxPT0RGSUxMOnQoMjgsMTMw
OSk9KDI4LDEzMDYpAHRhZ0VNUkVYVFNFTEVDVENMSVBSR046VHQoMjgsMTMxMCk9czIwZW1y
OigyOCwxMTAyKSwwLDY0O2NiUmduRGF0YTooMjUsMTQpLDY0LDMyO2lNb2RlOigyNSwxNCks
OTYsMzI7UmduRGF0YTooMjgsMjUwKSwxMjgsODtfX2FzOjooMjgsMTMxMSk9IyMoMjgsMTMx
Mik9JigyOCwxMzEwKTs6UkMyMnRhZ0VNUkVYVFNFTEVDVENMSVBSR047MkEuO3RhZ0VNUkVY
VFNFTEVDVENMSVBSR046OigyOCwxMzEzKT0jIygyOCwxMzE0KT0qKDI4LDEzMTApOzpSQzIy
dGFnRU1SRVhUU0VMRUNUQ0xJUFJHTjsyQS4oMjgsMTMxNSk9IyMoMjgsMTMxNCk7OjsyQS47
OwBFTVJFWFRTRUxFQ1RDTElQUkdOOnQoMjgsMTMxNik9KDI4LDEzMTApAFBFTVJFWFRTRUxF
Q1RDTElQUkdOOnQoMjgsMTMxNyk9KDI4LDEzMTQpAHRhZ0VNUlRFWFQ6VHQoMjgsMTMxOCk9
czQwcHRsUmVmZXJlbmNlOigyOCwzMjUpLDAsNjQ7bkNoYXJzOigyNSwxNCksNjQsMzI7b2Zm
U3RyaW5nOigyNSwxNCksOTYsMzI7Zk9wdGlvbnM6KDI1LDE0KSwxMjgsMzI7cmNsOigyOCwx
MjIpLDE2MCwxMjg7b2ZmRHg6KDI1LDE0KSwyODgsMzI7X19hczo6KDI4LDEzMTkpPSMjKDI4
LDEzMjApPSYoMjgsMTMxOCk7OlJDMTB0YWdFTVJURVhUOzJBLjt0YWdFTVJURVhUOjooMjgs
MTMyMSk9IyMoMjgsMTMyMik9KigyOCwxMzE4KTs6UkMxMHRhZ0VNUlRFWFQ7MkEuKDI4LDEz
MjMpPSMjKDI4LDEzMjIpOzo7MkEuOzsARU1SVEVYVDp0KDI4LDEzMjQpPSgyOCwxMzE4KQBQ
RU1SVEVYVDp0KDI4LDEzMjUpPSgyOCwxMzIyKQB0YWdFTVJFWFRURVhUT1VUQTpUdCgyOCwx
MzI2KT1zNzZlbXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEyODtp
R3JhcGhpY3NNb2RlOigyNSwxNCksMTkyLDMyO2V4U2NhbGU6KDI1LDE4KSwyMjQsMzI7ZXlT
Y2FsZTooMjUsMTgpLDI1NiwzMjtlbXJ0ZXh0OigyOCwxMzI0KSwyODgsMzIwO19fYXM6Oigy
OCwxMzI3KT0jIygyOCwxMzI4KT0mKDI4LDEzMjYpOzpSQzE3dGFnRU1SRVhUVEVYVE9VVEE7
MkEuO3RhZ0VNUkVYVFRFWFRPVVRBOjooMjgsMTMyOSk9IyMoMjgsMTMzMCk9KigyOCwxMzI2
KTs6UkMxN3RhZ0VNUkVYVFRFWFRPVVRBOzJBLigyOCwxMzMxKT0jIygyOCwxMzMwKTs6OzJB
Ljs7AEVNUkVYVFRFWFRPVVRBOnQoMjgsMTMzMik9KDI4LDEzMjYpAFBFTVJFWFRURVhUT1VU
QTp0KDI4LDEzMzMpPSgyOCwxMzMwKQBFTVJFWFRURVhUT1VUVzp0KDI4LDEzMzQpPSgyOCwx
MzI2KQBQRU1SRVhUVEVYVE9VVFc6dCgyOCwxMzM1KT0oMjgsMTMzMCkAdGFnRU1SRklMTFBB
VEg6VHQoMjgsMTMzNik9czI0ZW1yOigyOCwxMTAyKSwwLDY0O3JjbEJvdW5kczooMjgsMTIy
KSw2NCwxMjg7X19hczo6KDI4LDEzMzcpPSMjKDI4LDEzMzgpPSYoMjgsMTMzNik7OlJDMTR0
YWdFTVJGSUxMUEFUSDsyQS47dGFnRU1SRklMTFBBVEg6OigyOCwxMzM5KT0jIygyOCwxMzQw
KT0qKDI4LDEzMzYpOzpSQzE0dGFnRU1SRklMTFBBVEg7MkEuKDI4LDEzNDEpPSMjKDI4LDEz
NDApOzo7MkEuOzsARU1SRklMTFBBVEg6dCgyOCwxMzQyKT0oMjgsMTMzNikAUEVNUkZJTExQ
QVRIOnQoMjgsMTM0Myk9KDI4LDEzNDApAEVNUlNUUk9LRUFOREZJTExQQVRIOnQoMjgsMTM0
NCk9KDI4LDEzMzYpAFBFTVJTVFJPS0VBTkRGSUxMUEFUSDp0KDI4LDEzNDUpPSgyOCwxMzQw
KQBFTVJTVFJPS0VQQVRIOnQoMjgsMTM0Nik9KDI4LDEzMzYpAFBFTVJTVFJPS0VQQVRIOnQo
MjgsMTM0Nyk9KDI4LDEzNDApAHRhZ0VNUkZJTExSR046VHQoMjgsMTM0OCk9czM2ZW1yOigy
OCwxMTAyKSwwLDY0O3JjbEJvdW5kczooMjgsMTIyKSw2NCwxMjg7Y2JSZ25EYXRhOigyNSwx
NCksMTkyLDMyO2loQnJ1c2g6KDI1LDE0KSwyMjQsMzI7UmduRGF0YTooMjgsMjUwKSwyNTYs
ODtfX2FzOjooMjgsMTM0OSk9IyMoMjgsMTM1MCk9JigyOCwxMzQ4KTs6UkMxM3RhZ0VNUkZJ
TExSR047MkEuO3RhZ0VNUkZJTExSR046OigyOCwxMzUxKT0jIygyOCwxMzUyKT0qKDI4LDEz
NDgpOzpSQzEzdGFnRU1SRklMTFJHTjsyQS4oMjgsMTM1Myk9IyMoMjgsMTM1Mik7OjsyQS47
OwBFTVJGSUxMUkdOOnQoMjgsMTM1NCk9KDI4LDEzNDgpAFBFTVJGSUxMUkdOOnQoMjgsMTM1
NSk9KDI4LDEzNTIpAHRhZ0VNUkZPUk1BVDpUdCgyOCwxMzU2KT1zMTZkU2lnbmF0dXJlOigy
NSwxNCksMCwzMjtuVmVyc2lvbjooMjUsMTQpLDMyLDMyO2NiRGF0YTooMjUsMTQpLDY0LDMy
O29mZkRhdGE6KDI1LDE0KSw5NiwzMjtfX2FzOjooMjgsMTM1Nyk9IyMoMjgsMTM1OCk9Jigy
OCwxMzU2KTs6UkMxMnRhZ0VNUkZPUk1BVDsyQS47dGFnRU1SRk9STUFUOjooMjgsMTM1OSk9
IyMoMjgsMTM2MCk9KigyOCwxMzU2KTs6UkMxMnRhZ0VNUkZPUk1BVDsyQS4oMjgsMTM2MSk9
IyMoMjgsMTM2MCk7OjsyQS47OwBFTVJGT1JNQVQ6dCgyOCwxMzYyKT0oMjgsMTM1NikAdGFn
U0laRTpUdCgyOCwxMzYzKT1zOGN4OigyNSwxMyksMCwzMjtjeTooMjUsMTMpLDMyLDMyO19f
YXM6OigyOCwxMzY0KT0jIygyOCwxMzY1KT0mKDI4LDEzNjMpOzpSQzd0YWdTSVpFOzJBLjt0
YWdTSVpFOjooMjgsMTM2Nik9IyMoMjgsMTM2Nyk9KigyOCwxMzYzKTs6UkM3dGFnU0laRTsy
QS4oMjgsMTM2OCk9IyMoMjgsMTM2Nyk7OjsyQS47OwBTSVpFOnQoMjgsMTM2OSk9KDI4LDEz
NjMpAFBTSVpFOnQoMjgsMTM3MCk9KDI4LDEzNjcpAExQU0laRTp0KDI4LDEzNzEpPSgyOCwx
MzY3KQBTSVpFTDp0KDI4LDEzNzIpPSgyOCwxMzYzKQBQU0laRUw6dCgyOCwxMzczKT0oMjgs
MTM2NykATFBTSVpFTDp0KDI4LDEzNzQpPSgyOCwxMzY3KQB0YWdFTVJGUkFNRVJHTjpUdCgy
OCwxMzc1KT1zNDRlbXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEy
ODtjYlJnbkRhdGE6KDI1LDE0KSwxOTIsMzI7aWhCcnVzaDooMjUsMTQpLDIyNCwzMjtzemxT
dHJva2U6KDI4LDEzNzIpLDI1Niw2NDtSZ25EYXRhOigyOCwyNTApLDMyMCw4O19fYXM6Oigy
OCwxMzc2KT0jIygyOCwxMzc3KT0mKDI4LDEzNzUpOzpSQzE0dGFnRU1SRlJBTUVSR047MkEu
O3RhZ0VNUkZSQU1FUkdOOjooMjgsMTM3OCk9IyMoMjgsMTM3OSk9KigyOCwxMzc1KTs6UkMx
NHRhZ0VNUkZSQU1FUkdOOzJBLigyOCwxMzgwKT0jIygyOCwxMzc5KTs6OzJBLjs7AEVNUkZS
QU1FUkdOOnQoMjgsMTM4MSk9KDI4LDEzNzUpAFBFTVJGUkFNRVJHTjp0KDI4LDEzODIpPSgy
OCwxMzc5KQB0YWdFTVJHRElDT01NRU5UOlR0KDI4LDEzODMpPXMxNmVtcjooMjgsMTEwMiks
MCw2NDtjYkRhdGE6KDI1LDE0KSw2NCwzMjtEYXRhOigyOCwyNTApLDk2LDg7X19hczo6KDI4
LDEzODQpPSMjKDI4LDEzODUpPSYoMjgsMTM4Myk7OlJDMTZ0YWdFTVJHRElDT01NRU5UOzJB
Ljt0YWdFTVJHRElDT01NRU5UOjooMjgsMTM4Nik9IyMoMjgsMTM4Nyk9KigyOCwxMzgzKTs6
UkMxNnRhZ0VNUkdESUNPTU1FTlQ7MkEuKDI4LDEzODgpPSMjKDI4LDEzODcpOzo7MkEuOzsA
RU1SR0RJQ09NTUVOVDp0KDI4LDEzODkpPSgyOCwxMzgzKQBQRU1SR0RJQ09NTUVOVDp0KDI4
LDEzOTApPSgyOCwxMzg3KQB0YWdFTVJJTlZFUlRSR046VHQoMjgsMTM5MSk9czMyZW1yOigy
OCwxMTAyKSwwLDY0O3JjbEJvdW5kczooMjgsMTIyKSw2NCwxMjg7Y2JSZ25EYXRhOigyNSwx
NCksMTkyLDMyO1JnbkRhdGE6KDI4LDI1MCksMjI0LDg7X19hczo6KDI4LDEzOTIpPSMjKDI4
LDEzOTMpPSYoMjgsMTM5MSk7OlJDMTV0YWdFTVJJTlZFUlRSR047MkEuO3RhZ0VNUklOVkVS
VFJHTjo6KDI4LDEzOTQpPSMjKDI4LDEzOTUpPSooMjgsMTM5MSk7OlJDMTV0YWdFTVJJTlZF
UlRSR047MkEuKDI4LDEzOTYpPSMjKDI4LDEzOTUpOzo7MkEuOzsARU1SSU5WRVJUUkdOOnQo
MjgsMTM5Nyk9KDI4LDEzOTEpAFBFTVJJTlZFUlRSR046dCgyOCwxMzk4KT0oMjgsMTM5NSkA
RU1SUEFJTlRSR046dCgyOCwxMzk5KT0oMjgsMTM5MSkAUEVNUlBBSU5UUkdOOnQoMjgsMTQw
MCk9KDI4LDEzOTUpAHRhZ0VNUkxJTkVUTzpUdCgyOCwxNDAxKT1zMTZlbXI6KDI4LDExMDIp
LDAsNjQ7cHRsOigyOCwzMjUpLDY0LDY0O19fYXM6OigyOCwxNDAyKT0jIygyOCwxNDAzKT0m
KDI4LDE0MDEpOzpSQzEydGFnRU1STElORVRPOzJBLjt0YWdFTVJMSU5FVE86OigyOCwxNDA0
KT0jIygyOCwxNDA1KT0qKDI4LDE0MDEpOzpSQzEydGFnRU1STElORVRPOzJBLigyOCwxNDA2
KT0jIygyOCwxNDA1KTs6OzJBLjs7AEVNUkxJTkVUTzp0KDI4LDE0MDcpPSgyOCwxNDAxKQBQ
RU1STElORVRPOnQoMjgsMTQwOCk9KDI4LDE0MDUpAEVNUk1PVkVUT0VYOnQoMjgsMTQwOSk9
KDI4LDE0MDEpAFBFTVJNT1ZFVE9FWDp0KDI4LDE0MTApPSgyOCwxNDA1KQB0YWdFTVJNQVNL
QkxUOlR0KDI4LDE0MTEpPXMxMjhlbXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigyOCwx
MjIpLDY0LDEyODt4RGVzdDooMjUsMTMpLDE5MiwzMjt5RGVzdDooMjUsMTMpLDIyNCwzMjtj
eERlc3Q6KDI1LDEzKSwyNTYsMzI7Y3lEZXN0OigyNSwxMyksMjg4LDMyO2R3Um9wOigyNSwx
NCksMzIwLDMyO3hTcmM6KDI1LDEzKSwzNTIsMzI7eVNyYzooMjUsMTMpLDM4NCwzMjt4Zm9y
bVNyYzooMjgsMTEzMiksNDE2LDE5MjtjckJrQ29sb3JTcmM6KDI1LDkpLDYwOCwzMjtpVXNh
Z2VTcmM6KDI1LDE0KSw2NDAsMzI7b2ZmQm1pU3JjOigyNSwxNCksNjcyLDMyO2NiQm1pU3Jj
OigyNSwxNCksNzA0LDMyO29mZkJpdHNTcmM6KDI1LDE0KSw3MzYsMzI7Y2JCaXRzU3JjOigy
NSwxNCksNzY4LDMyO3hNYXNrOigyNSwxMyksODAwLDMyO3lNYXNrOigyNSwxMyksODMyLDMy
O2lVc2FnZU1hc2s6KDI1LDE0KSw4NjQsMzI7b2ZmQm1pTWFzazooMjUsMTQpLDg5NiwzMjtj
YkJtaU1hc2s6KDI1LDE0KSw5MjgsMzI7b2ZmQml0c01hc2s6KDI1LDE0KSw5NjAsMzI7Y2JC
aXRzTWFzazooMjUsMTQpLDk5MiwzMjtfX2FzOjooMjgsMTQxMik9IyMoMjgsMTQxMyk9Jigy
OCwxNDExKTs6UkMxM3RhZ0VNUk1BU0tCTFQ7MkEuO3RhZ0VNUk1BU0tCTFQ6OigyOCwxNDE0
KT0jIygyOCwxNDE1KT0qKDI4LDE0MTEpOzpSQzEzdGFnRU1STUFTS0JMVDsyQS4oMjgsMTQx
Nik9IyMoMjgsMTQxNSk7OjsyQS47OwBFTVJNQVNLQkxUOnQoMjgsMTQxNyk9KDI4LDE0MTEp
AFBFTVJNQVNLQkxUOnQoMjgsMTQxOCk9KDI4LDE0MTUpAHRhZ0VNUk1PRElGWVdPUkxEVFJB
TlNGT1JNOlR0KDI4LDE0MTkpPXMzNmVtcjooMjgsMTEwMiksMCw2NDt4Zm9ybTooMjgsMTEz
MiksNjQsMTkyO2lNb2RlOigyNSwxNCksMjU2LDMyO19fYXM6OigyOCwxNDIwKT0jIygyOCwx
NDIxKT0mKDI4LDE0MTkpOzpSQzI2dGFnRU1STU9ESUZZV09STERUUkFOU0ZPUk07MkEuO3Rh
Z0VNUk1PRElGWVdPUkxEVFJBTlNGT1JNOjooMjgsMTQyMik9IyMoMjgsMTQyMyk9KigyOCwx
NDE5KTs6UkMyNnRhZ0VNUk1PRElGWVdPUkxEVFJBTlNGT1JNOzJBLigyOCwxNDI0KT0jIygy
OCwxNDIzKTs6OzJBLjs7AEVNUk1PRElGWVdPUkxEVFJBTlNGT1JNOnQoMjgsMTQyNSk9KDI4
LDE0MTkpAFBFTVJNT0RJRllXT1JMRFRSQU5TRk9STTp0KDI4LDE0MjYpPSgyOCwxNDIzKQB0
YWdFTVJPRkZTRVRDTElQUkdOOlR0KDI4LDE0MjcpPXMxNmVtcjooMjgsMTEwMiksMCw2NDtw
dGxPZmZzZXQ6KDI4LDMyNSksNjQsNjQ7X19hczo6KDI4LDE0MjgpPSMjKDI4LDE0MjkpPSYo
MjgsMTQyNyk7OlJDMTl0YWdFTVJPRkZTRVRDTElQUkdOOzJBLjt0YWdFTVJPRkZTRVRDTElQ
UkdOOjooMjgsMTQzMCk9IyMoMjgsMTQzMSk9KigyOCwxNDI3KTs6UkMxOXRhZ0VNUk9GRlNF
VENMSVBSR047MkEuKDI4LDE0MzIpPSMjKDI4LDE0MzEpOzo7MkEuOzsARU1ST0ZGU0VUQ0xJ
UFJHTjp0KDI4LDE0MzMpPSgyOCwxNDI3KQBQRU1ST0ZGU0VUQ0xJUFJHTjp0KDI4LDE0MzQp
PSgyOCwxNDMxKQB0YWdFTVJQTEdCTFQ6VHQoMjgsMTQzNSk9czE0MGVtcjooMjgsMTEwMiks
MCw2NDtyY2xCb3VuZHM6KDI4LDEyMiksNjQsMTI4O2FwdGxEZXN0OigyOCwxNDM2KT1hcigw
LDEpOzA7MjsoMjgsMzE5KSwxOTIsMTkyO3hTcmM6KDI1LDEzKSwzODQsMzI7eVNyYzooMjUs
MTMpLDQxNiwzMjtjeFNyYzooMjUsMTMpLDQ0OCwzMjtjeVNyYzooMjUsMTMpLDQ4MCwzMjt4
Zm9ybVNyYzooMjgsMTEzMiksNTEyLDE5MjtjckJrQ29sb3JTcmM6KDI1LDkpLDcwNCwzMjtp
VXNhZ2VTcmM6KDI1LDE0KSw3MzYsMzI7b2ZmQm1pU3JjOigyNSwxNCksNzY4LDMyO2NiQm1p
U3JjOigyNSwxNCksODAwLDMyO29mZkJpdHNTcmM6KDI1LDE0KSw4MzIsMzI7Y2JCaXRzU3Jj
OigyNSwxNCksODY0LDMyO3hNYXNrOigyNSwxMyksODk2LDMyO3lNYXNrOigyNSwxMyksOTI4
LDMyO2lVc2FnZU1hc2s6KDI1LDE0KSw5NjAsMzI7b2ZmQm1pTWFzazooMjUsMTQpLDk5Miwz
MjtjYkJtaU1hc2s6KDI1LDE0KSwxMDI0LDMyO29mZkJpdHNNYXNrOigyNSwxNCksMTA1Niwz
MjtjYkJpdHNNYXNrOigyNSwxNCksMTA4OCwzMjtfX2FzOjooMjgsMTQzNyk9IyMoMjgsMTQz
OCk9JigyOCwxNDM1KTs6UkMxMnRhZ0VNUlBMR0JMVDsyQS47dGFnRU1SUExHQkxUOjooMjgs
MTQzOSk9IyMoMjgsMTQ0MCk9KigyOCwxNDM1KTs6UkMxMnRhZ0VNUlBMR0JMVDsyQS4oMjgs
MTQ0MSk9IyMoMjgsMTQ0MCk7OjsyQS47OwBFTVJQTEdCTFQ6dCgyOCwxNDQyKT0oMjgsMTQz
NSkAUEVNUlBMR0JMVDp0KDI4LDE0NDMpPSgyOCwxNDQwKQB0YWdFTVJQT0xZRFJBVzpUdCgy
OCwxNDQ0KT1zNDBlbXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEy
ODtjcHRsOigyNSwxNCksMTkyLDMyO2FwdGw6KDI4LDE0NDUpPWFyKDAsMSk7MDswOygyOCwz
MTkpLDIyNCw2NDthYlR5cGVzOigyOCwyNTApLDI4OCw4O19fYXM6OigyOCwxNDQ2KT0jIygy
OCwxNDQ3KT0mKDI4LDE0NDQpOzpSQzE0dGFnRU1SUE9MWURSQVc7MkEuO3RhZ0VNUlBPTFlE
UkFXOjooMjgsMTQ0OCk9IyMoMjgsMTQ0OSk9KigyOCwxNDQ0KTs6UkMxNHRhZ0VNUlBPTFlE
UkFXOzJBLigyOCwxNDUwKT0jIygyOCwxNDQ5KTs6OzJBLjs7AEVNUlBPTFlEUkFXOnQoMjgs
MTQ1MSk9KDI4LDE0NDQpAFBFTVJQT0xZRFJBVzp0KDI4LDE0NTIpPSgyOCwxNDQ5KQB0YWdF
TVJQT0xZRFJBVzE2OlR0KDI4LDE0NTMpPXMzNmVtcjooMjgsMTEwMiksMCw2NDtyY2xCb3Vu
ZHM6KDI4LDEyMiksNjQsMTI4O2NwdHM6KDI1LDE0KSwxOTIsMzI7YXB0czooMjgsMTQ1NCk9
YXIoMCwxKTswOzA7KDI4LDMyNiksMjI0LDMyO2FiVHlwZXM6KDI4LDI1MCksMjU2LDg7X19h
czo6KDI4LDE0NTUpPSMjKDI4LDE0NTYpPSYoMjgsMTQ1Myk7OlJDMTZ0YWdFTVJQT0xZRFJB
VzE2OzJBLjt0YWdFTVJQT0xZRFJBVzE2OjooMjgsMTQ1Nyk9IyMoMjgsMTQ1OCk9KigyOCwx
NDUzKTs6UkMxNnRhZ0VNUlBPTFlEUkFXMTY7MkEuKDI4LDE0NTkpPSMjKDI4LDE0NTgpOzo7
MkEuOzsARU1SUE9MWURSQVcxNjp0KDI4LDE0NjApPSgyOCwxNDUzKQBQRU1SUE9MWURSQVcx
Njp0KDI4LDE0NjEpPSgyOCwxNDU4KQB0YWdFTVJQT0xZTElORTpUdCgyOCwxNDYyKT1zMzZl
bXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEyODtjcHRsOigyNSwx
NCksMTkyLDMyO2FwdGw6KDI4LDE0NDUpLDIyNCw2NDtfX2FzOjooMjgsMTQ2Myk9IyMoMjgs
MTQ2NCk9JigyOCwxNDYyKTs6UkMxNHRhZ0VNUlBPTFlMSU5FOzJBLjt0YWdFTVJQT0xZTElO
RTo6KDI4LDE0NjUpPSMjKDI4LDE0NjYpPSooMjgsMTQ2Mik7OlJDMTR0YWdFTVJQT0xZTElO
RTsyQS4oMjgsMTQ2Nyk9IyMoMjgsMTQ2Nik7OjsyQS47OwBFTVJQT0xZTElORTp0KDI4LDE0
NjgpPSgyOCwxNDYyKQBQRU1SUE9MWUxJTkU6dCgyOCwxNDY5KT0oMjgsMTQ2NikARU1SUE9M
WUJFWklFUjp0KDI4LDE0NzApPSgyOCwxNDYyKQBQRU1SUE9MWUJFWklFUjp0KDI4LDE0NzEp
PSgyOCwxNDY2KQBFTVJQT0xZR09OOnQoMjgsMTQ3Mik9KDI4LDE0NjIpAFBFTVJQT0xZR09O
OnQoMjgsMTQ3Myk9KDI4LDE0NjYpAEVNUlBPTFlCRVpJRVJUTzp0KDI4LDE0NzQpPSgyOCwx
NDYyKQBQRU1SUE9MWUJFWklFUlRPOnQoMjgsMTQ3NSk9KDI4LDE0NjYpAEVNUlBPTFlMSU5F
VE86dCgyOCwxNDc2KT0oMjgsMTQ2MikAUEVNUlBPTFlMSU5FVE86dCgyOCwxNDc3KT0oMjgs
MTQ2NikAdGFnRU1SUE9MWUxJTkUxNjpUdCgyOCwxNDc4KT1zMzZlbXI6KDI4LDExMDIpLDAs
NjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEyODtjcHRzOigyNSwxNCksMTkyLDMyO2FwdHM6
KDI4LDE0NDUpLDIyNCw2NDtfX2FzOjooMjgsMTQ3OSk9IyMoMjgsMTQ4MCk9JigyOCwxNDc4
KTs6UkMxNnRhZ0VNUlBPTFlMSU5FMTY7MkEuO3RhZ0VNUlBPTFlMSU5FMTY6OigyOCwxNDgx
KT0jIygyOCwxNDgyKT0qKDI4LDE0NzgpOzpSQzE2dGFnRU1SUE9MWUxJTkUxNjsyQS4oMjgs
MTQ4Myk9IyMoMjgsMTQ4Mik7OjsyQS47OwBFTVJQT0xZTElORTE2OnQoMjgsMTQ4NCk9KDI4
LDE0NzgpAFBFTVJQT0xZTElORTE2OnQoMjgsMTQ4NSk9KDI4LDE0ODIpAEVNUlBPTFlCRVpJ
RVIxNjp0KDI4LDE0ODYpPSgyOCwxNDc4KQBQRU1SUE9MWUJFWklFUjE2OnQoMjgsMTQ4Nyk9
KDI4LDE0ODIpAEVNUlBPTFlHT04xNjp0KDI4LDE0ODgpPSgyOCwxNDc4KQBQRU1SUE9MWUdP
TjE2OnQoMjgsMTQ4OSk9KDI4LDE0ODIpAEVNUlBPTFlCRVpJRVJUTzE2OnQoMjgsMTQ5MCk9
KDI4LDE0NzgpAFBFTVJQT0xZQkVaSUVSVE8xNjp0KDI4LDE0OTEpPSgyOCwxNDgyKQBFTVJQ
T0xZTElORVRPMTY6dCgyOCwxNDkyKT0oMjgsMTQ3OCkAUEVNUlBPTFlMSU5FVE8xNjp0KDI4
LDE0OTMpPSgyOCwxNDgyKQB0YWdFTVJQT0xZUE9MWUxJTkU6VHQoMjgsMTQ5NCk9czQ0ZW1y
OigyOCwxMTAyKSwwLDY0O3JjbEJvdW5kczooMjgsMTIyKSw2NCwxMjg7blBvbHlzOigyNSwx
NCksMTkyLDMyO2NwdGw6KDI1LDE0KSwyMjQsMzI7YVBvbHlDb3VudHM6KDI4LDM0MiksMjU2
LDMyO2FwdGw6KDI4LDE0NDUpLDI4OCw2NDtfX2FzOjooMjgsMTQ5NSk9IyMoMjgsMTQ5Nik9
JigyOCwxNDk0KTs6UkMxOHRhZ0VNUlBPTFlQT0xZTElORTsyQS47dGFnRU1SUE9MWVBPTFlM
SU5FOjooMjgsMTQ5Nyk9IyMoMjgsMTQ5OCk9KigyOCwxNDk0KTs6UkMxOHRhZ0VNUlBPTFlQ
T0xZTElORTsyQS4oMjgsMTQ5OSk9IyMoMjgsMTQ5OCk7OjsyQS47OwBFTVJQT0xZUE9MWUxJ
TkU6dCgyOCwxNTAwKT0oMjgsMTQ5NCkAUEVNUlBPTFlQT0xZTElORTp0KDI4LDE1MDEpPSgy
OCwxNDk4KQBFTVJQT0xZUE9MWUdPTjp0KDI4LDE1MDIpPSgyOCwxNDk0KQBQRU1SUE9MWVBP
TFlHT046dCgyOCwxNTAzKT0oMjgsMTQ5OCkAdGFnRU1SUE9MWVBPTFlMSU5FMTY6VHQoMjgs
MTUwNCk9czQwZW1yOigyOCwxMTAyKSwwLDY0O3JjbEJvdW5kczooMjgsMTIyKSw2NCwxMjg7
blBvbHlzOigyNSwxNCksMTkyLDMyO2NwdHM6KDI1LDE0KSwyMjQsMzI7YVBvbHlDb3VudHM6
KDI4LDM0MiksMjU2LDMyO2FwdHM6KDI4LDE0NTQpLDI4OCwzMjtfX2FzOjooMjgsMTUwNSk9
IyMoMjgsMTUwNik9JigyOCwxNTA0KTs6UkMyMHRhZ0VNUlBPTFlQT0xZTElORTE2OzJBLjt0
YWdFTVJQT0xZUE9MWUxJTkUxNjo6KDI4LDE1MDcpPSMjKDI4LDE1MDgpPSooMjgsMTUwNCk7
OlJDMjB0YWdFTVJQT0xZUE9MWUxJTkUxNjsyQS4oMjgsMTUwOSk9IyMoMjgsMTUwOCk7Ojsy
QS47OwBFTVJQT0xZUE9MWUxJTkUxNjp0KDI4LDE1MTApPSgyOCwxNTA0KQBQRU1SUE9MWVBP
TFlMSU5FMTY6dCgyOCwxNTExKT0oMjgsMTUwOCkARU1SUE9MWVBPTFlHT04xNjp0KDI4LDE1
MTIpPSgyOCwxNTA0KQBQRU1SUE9MWVBPTFlHT04xNjp0KDI4LDE1MTMpPSgyOCwxNTA4KQB0
YWdFTVJQT0xZVEVYVE9VVEE6VHQoMjgsMTUxNCk9czgwZW1yOigyOCwxMTAyKSwwLDY0O3Jj
bEJvdW5kczooMjgsMTIyKSw2NCwxMjg7aUdyYXBoaWNzTW9kZTooMjUsMTQpLDE5MiwzMjtl
eFNjYWxlOigyNSwxOCksMjI0LDMyO2V5U2NhbGU6KDI1LDE4KSwyNTYsMzI7Y1N0cmluZ3M6
KDI1LDEzKSwyODgsMzI7YWVtcnRleHQ6KDI4LDE1MTUpPWFyKDAsMSk7MDswOygyOCwxMzE4
KSwzMjAsMzIwO19fYXM6OigyOCwxNTE2KT0jIygyOCwxNTE3KT0mKDI4LDE1MTQpOzpSQzE4
dGFnRU1SUE9MWVRFWFRPVVRBOzJBLjt0YWdFTVJQT0xZVEVYVE9VVEE6OigyOCwxNTE4KT0j
IygyOCwxNTE5KT0qKDI4LDE1MTQpOzpSQzE4dGFnRU1SUE9MWVRFWFRPVVRBOzJBLigyOCwx
NTIwKT0jIygyOCwxNTE5KTs6OzJBLjs7AEVNUlBPTFlURVhUT1VUQTp0KDI4LDE1MjEpPSgy
OCwxNTE0KQBQRU1SUE9MWVRFWFRPVVRBOnQoMjgsMTUyMik9KDI4LDE1MTkpAEVNUlBPTFlU
RVhUT1VUVzp0KDI4LDE1MjMpPSgyOCwxNTE0KQBQRU1SUE9MWVRFWFRPVVRXOnQoMjgsMTUy
NCk9KDI4LDE1MTkpAHRhZ0VNUlJFU0laRVBBTEVUVEU6VHQoMjgsMTUyNSk9czE2ZW1yOigy
OCwxMTAyKSwwLDY0O2loUGFsOigyNSwxNCksNjQsMzI7Y0VudHJpZXM6KDI1LDE0KSw5Niwz
MjtfX2FzOjooMjgsMTUyNik9IyMoMjgsMTUyNyk9JigyOCwxNTI1KTs6UkMxOXRhZ0VNUlJF
U0laRVBBTEVUVEU7MkEuO3RhZ0VNUlJFU0laRVBBTEVUVEU6OigyOCwxNTI4KT0jIygyOCwx
NTI5KT0qKDI4LDE1MjUpOzpSQzE5dGFnRU1SUkVTSVpFUEFMRVRURTsyQS4oMjgsMTUzMCk9
IyMoMjgsMTUyOSk7OjsyQS47OwBFTVJSRVNJWkVQQUxFVFRFOnQoMjgsMTUzMSk9KDI4LDE1
MjUpAFBFTVJSRVNJWkVQQUxFVFRFOnQoMjgsMTUzMik9KDI4LDE1MjkpAHRhZ0VNUlJFU1RP
UkVEQzpUdCgyOCwxNTMzKT1zMTJlbXI6KDI4LDExMDIpLDAsNjQ7aVJlbGF0aXZlOigyNSwx
MyksNjQsMzI7X19hczo6KDI4LDE1MzQpPSMjKDI4LDE1MzUpPSYoMjgsMTUzMyk7OlJDMTV0
YWdFTVJSRVNUT1JFREM7MkEuO3RhZ0VNUlJFU1RPUkVEQzo6KDI4LDE1MzYpPSMjKDI4LDE1
MzcpPSooMjgsMTUzMyk7OlJDMTV0YWdFTVJSRVNUT1JFREM7MkEuKDI4LDE1MzgpPSMjKDI4
LDE1MzcpOzo7MkEuOzsARU1SUkVTVE9SRURDOnQoMjgsMTUzOSk9KDI4LDE1MzMpAFBFTVJS
RVNUT1JFREM6dCgyOCwxNTQwKT0oMjgsMTUzNykAdGFnRU1SUk9VTkRSRUNUOlR0KDI4LDE1
NDEpPXMzMmVtcjooMjgsMTEwMiksMCw2NDtyY2xCb3g6KDI4LDEyMiksNjQsMTI4O3N6bENv
cm5lcjooMjgsMTM3MiksMTkyLDY0O19fYXM6OigyOCwxNTQyKT0jIygyOCwxNTQzKT0mKDI4
LDE1NDEpOzpSQzE1dGFnRU1SUk9VTkRSRUNUOzJBLjt0YWdFTVJST1VORFJFQ1Q6OigyOCwx
NTQ0KT0jIygyOCwxNTQ1KT0qKDI4LDE1NDEpOzpSQzE1dGFnRU1SUk9VTkRSRUNUOzJBLigy
OCwxNTQ2KT0jIygyOCwxNTQ1KTs6OzJBLjs7AEVNUlJPVU5EUkVDVDp0KDI4LDE1NDcpPSgy
OCwxNTQxKQBQRU1SUk9VTkRSRUNUOnQoMjgsMTU0OCk9KDI4LDE1NDUpAHRhZ0VNUlNDQUxF
VklFV1BPUlRFWFRFWDpUdCgyOCwxNTQ5KT1zMjRlbXI6KDI4LDExMDIpLDAsNjQ7eE51bToo
MjUsMTMpLDY0LDMyO3hEZW5vbTooMjUsMTMpLDk2LDMyO3lOdW06KDI1LDEzKSwxMjgsMzI7
eURlbm9tOigyNSwxMyksMTYwLDMyO19fYXM6OigyOCwxNTUwKT0jIygyOCwxNTUxKT0mKDI4
LDE1NDkpOzpSQzI0dGFnRU1SU0NBTEVWSUVXUE9SVEVYVEVYOzJBLjt0YWdFTVJTQ0FMRVZJ
RVdQT1JURVhURVg6OigyOCwxNTUyKT0jIygyOCwxNTUzKT0qKDI4LDE1NDkpOzpSQzI0dGFn
RU1SU0NBTEVWSUVXUE9SVEVYVEVYOzJBLigyOCwxNTU0KT0jIygyOCwxNTUzKTs6OzJBLjs7
AEVNUlNDQUxFVklFV1BPUlRFWFRFWDp0KDI4LDE1NTUpPSgyOCwxNTQ5KQBQRU1SU0NBTEVW
SUVXUE9SVEVYVEVYOnQoMjgsMTU1Nik9KDI4LDE1NTMpAEVNUlNDQUxFV0lORE9XRVhURVg6
dCgyOCwxNTU3KT0oMjgsMTU0OSkAUEVNUlNDQUxFV0lORE9XRVhURVg6dCgyOCwxNTU4KT0o
MjgsMTU1MykAdGFnRU1SU0VMRUNUQ09MT1JTUEFDRTpUdCgyOCwxNTU5KT1zMTJlbXI6KDI4
LDExMDIpLDAsNjQ7aWhDUzooMjUsMTQpLDY0LDMyO19fYXM6OigyOCwxNTYwKT0jIygyOCwx
NTYxKT0mKDI4LDE1NTkpOzpSQzIydGFnRU1SU0VMRUNUQ09MT1JTUEFDRTsyQS47dGFnRU1S
U0VMRUNUQ09MT1JTUEFDRTo6KDI4LDE1NjIpPSMjKDI4LDE1NjMpPSooMjgsMTU1OSk7OlJD
MjJ0YWdFTVJTRUxFQ1RDT0xPUlNQQUNFOzJBLigyOCwxNTY0KT0jIygyOCwxNTYzKTs6OzJB
Ljs7AEVNUlNFTEVDVENPTE9SU1BBQ0U6dCgyOCwxNTY1KT0oMjgsMTU1OSkAUEVNUlNFTEVD
VENPTE9SU1BBQ0U6dCgyOCwxNTY2KT0oMjgsMTU2MykARU1SREVMRVRFQ09MT1JTUEFDRTp0
KDI4LDE1NjcpPSgyOCwxNTU5KQBQRU1SREVMRVRFQ09MT1JTUEFDRTp0KDI4LDE1NjgpPSgy
OCwxNTYzKQB0YWdFTVJTRUxFQ1RPQkpFQ1Q6VHQoMjgsMTU2OSk9czEyZW1yOigyOCwxMTAy
KSwwLDY0O2loT2JqZWN0OigyNSwxNCksNjQsMzI7X19hczo6KDI4LDE1NzApPSMjKDI4LDE1
NzEpPSYoMjgsMTU2OSk7OlJDMTh0YWdFTVJTRUxFQ1RPQkpFQ1Q7MkEuO3RhZ0VNUlNFTEVD
VE9CSkVDVDo6KDI4LDE1NzIpPSMjKDI4LDE1NzMpPSooMjgsMTU2OSk7OlJDMTh0YWdFTVJT
RUxFQ1RPQkpFQ1Q7MkEuKDI4LDE1NzQpPSMjKDI4LDE1NzMpOzo7MkEuOzsARU1SU0VMRUNU
T0JKRUNUOnQoMjgsMTU3NSk9KDI4LDE1NjkpAFBFTVJTRUxFQ1RPQkpFQ1Q6dCgyOCwxNTc2
KT0oMjgsMTU3MykARU1SREVMRVRFT0JKRUNUOnQoMjgsMTU3Nyk9KDI4LDE1NjkpAFBFTVJE
RUxFVEVPQkpFQ1Q6dCgyOCwxNTc4KT0oMjgsMTU3MykAdGFnRU1SU0VMRUNUUEFMRVRURTpU
dCgyOCwxNTc5KT1zMTJlbXI6KDI4LDExMDIpLDAsNjQ7aWhQYWw6KDI1LDE0KSw2NCwzMjtf
X2FzOjooMjgsMTU4MCk9IyMoMjgsMTU4MSk9JigyOCwxNTc5KTs6UkMxOXRhZ0VNUlNFTEVD
VFBBTEVUVEU7MkEuO3RhZ0VNUlNFTEVDVFBBTEVUVEU6OigyOCwxNTgyKT0jIygyOCwxNTgz
KT0qKDI4LDE1NzkpOzpSQzE5dGFnRU1SU0VMRUNUUEFMRVRURTsyQS4oMjgsMTU4NCk9IyMo
MjgsMTU4Myk7OjsyQS47OwBFTVJTRUxFQ1RQQUxFVFRFOnQoMjgsMTU4NSk9KDI4LDE1Nzkp
AFBFTVJTRUxFQ1RQQUxFVFRFOnQoMjgsMTU4Nik9KDI4LDE1ODMpAHRhZ0VNUlNFVEFSQ0RJ
UkVDVElPTjpUdCgyOCwxNTg3KT1zMTJlbXI6KDI4LDExMDIpLDAsNjQ7aUFyY0RpcmVjdGlv
bjooMjUsMTQpLDY0LDMyO19fYXM6OigyOCwxNTg4KT0jIygyOCwxNTg5KT0mKDI4LDE1ODcp
OzpSQzIxdGFnRU1SU0VUQVJDRElSRUNUSU9OOzJBLjt0YWdFTVJTRVRBUkNESVJFQ1RJT046
OigyOCwxNTkwKT0jIygyOCwxNTkxKT0qKDI4LDE1ODcpOzpSQzIxdGFnRU1SU0VUQVJDRElS
RUNUSU9OOzJBLigyOCwxNTkyKT0jIygyOCwxNTkxKTs6OzJBLjs7AEVNUlNFVEFSQ0RJUkVD
VElPTjp0KDI4LDE1OTMpPSgyOCwxNTg3KQBQRU1SU0VUQVJDRElSRUNUSU9OOnQoMjgsMTU5
NCk9KDI4LDE1OTEpAHRhZ0VNUlNFVFRFWFRDT0xPUjpUdCgyOCwxNTk1KT1zMTJlbXI6KDI4
LDExMDIpLDAsNjQ7Y3JDb2xvcjooMjUsOSksNjQsMzI7X19hczo6KDI4LDE1OTYpPSMjKDI4
LDE1OTcpPSYoMjgsMTU5NSk7OlJDMTh0YWdFTVJTRVRURVhUQ09MT1I7MkEuO3RhZ0VNUlNF
VFRFWFRDT0xPUjo6KDI4LDE1OTgpPSMjKDI4LDE1OTkpPSooMjgsMTU5NSk7OlJDMTh0YWdF
TVJTRVRURVhUQ09MT1I7MkEuKDI4LDE2MDApPSMjKDI4LDE1OTkpOzo7MkEuOzsARU1SU0VU
QktDT0xPUjp0KDI4LDE2MDEpPSgyOCwxNTk1KQBQRU1SU0VUQktDT0xPUjp0KDI4LDE2MDIp
PSgyOCwxNTk5KQBFTVJTRVRURVhUQ09MT1I6dCgyOCwxNjAzKT0oMjgsMTU5NSkAUEVNUlNF
VFRFWFRDT0xPUjp0KDI4LDE2MDQpPSgyOCwxNTk5KQB0YWdFTVJTRVRDT0xPUkFESlVTVE1F
TlQ6VHQoMjgsMTYwNSk9czMyZW1yOigyOCwxMTAyKSwwLDY0O0NvbG9yQWRqdXN0bWVudDoo
MjgsNTAxKSw2NCwxOTI7X19hczo6KDI4LDE2MDYpPSMjKDI4LDE2MDcpPSYoMjgsMTYwNSk7
OlJDMjR0YWdFTVJTRVRDT0xPUkFESlVTVE1FTlQ7MkEuO3RhZ0VNUlNFVENPTE9SQURKVVNU
TUVOVDo6KDI4LDE2MDgpPSMjKDI4LDE2MDkpPSooMjgsMTYwNSk7OlJDMjR0YWdFTVJTRVRD
T0xPUkFESlVTVE1FTlQ7MkEuKDI4LDE2MTApPSMjKDI4LDE2MDkpOzo7MkEuOzsARU1SU0VU
Q09MT1JBREpVU1RNRU5UOnQoMjgsMTYxMSk9KDI4LDE2MDUpAFBFTVJTRVRDT0xPUkFESlVT
VE1FTlQ6dCgyOCwxNjEyKT0oMjgsMTYwOSkAdGFnRU1SU0VURElCSVRTVE9ERVZJQ0U6VHQo
MjgsMTYxMyk9czc2ZW1yOigyOCwxMTAyKSwwLDY0O3JjbEJvdW5kczooMjgsMTIyKSw2NCwx
Mjg7eERlc3Q6KDI1LDEzKSwxOTIsMzI7eURlc3Q6KDI1LDEzKSwyMjQsMzI7eFNyYzooMjUs
MTMpLDI1NiwzMjt5U3JjOigyNSwxMyksMjg4LDMyO2N4U3JjOigyNSwxMyksMzIwLDMyO2N5
U3JjOigyNSwxMyksMzUyLDMyO29mZkJtaVNyYzooMjUsMTQpLDM4NCwzMjtjYkJtaVNyYzoo
MjUsMTQpLDQxNiwzMjtvZmZCaXRzU3JjOigyNSwxNCksNDQ4LDMyO2NiQml0c1NyYzooMjUs
MTQpLDQ4MCwzMjtpVXNhZ2VTcmM6KDI1LDE0KSw1MTIsMzI7aVN0YXJ0U2NhbjooMjUsMTQp
LDU0NCwzMjtjU2NhbnM6KDI1LDE0KSw1NzYsMzI7X19hczo6KDI4LDE2MTQpPSMjKDI4LDE2
MTUpPSYoMjgsMTYxMyk7OlJDMjN0YWdFTVJTRVRESUJJVFNUT0RFVklDRTsyQS47dGFnRU1S
U0VURElCSVRTVE9ERVZJQ0U6OigyOCwxNjE2KT0jIygyOCwxNjE3KT0qKDI4LDE2MTMpOzpS
QzIzdGFnRU1SU0VURElCSVRTVE9ERVZJQ0U7MkEuKDI4LDE2MTgpPSMjKDI4LDE2MTcpOzo7
MkEuOzsARU1SU0VURElCSVRTVE9ERVZJQ0U6dCgyOCwxNjE5KT0oMjgsMTYxMykAUEVNUlNF
VERJQklUU1RPREVWSUNFOnQoMjgsMTYyMCk9KDI4LDE2MTcpAHRhZ0VNUlNFVE1BUFBFUkZM
QUdTOlR0KDI4LDE2MjEpPXMxMmVtcjooMjgsMTEwMiksMCw2NDtkd0ZsYWdzOigyNSwxNCks
NjQsMzI7X19hczo6KDI4LDE2MjIpPSMjKDI4LDE2MjMpPSYoMjgsMTYyMSk7OlJDMjB0YWdF
TVJTRVRNQVBQRVJGTEFHUzsyQS47dGFnRU1SU0VUTUFQUEVSRkxBR1M6OigyOCwxNjI0KT0j
IygyOCwxNjI1KT0qKDI4LDE2MjEpOzpSQzIwdGFnRU1SU0VUTUFQUEVSRkxBR1M7MkEuKDI4
LDE2MjYpPSMjKDI4LDE2MjUpOzo7MkEuOzsARU1SU0VUTUFQUEVSRkxBR1M6dCgyOCwxNjI3
KT0oMjgsMTYyMSkAUEVNUlNFVE1BUFBFUkZMQUdTOnQoMjgsMTYyOCk9KDI4LDE2MjUpAHRh
Z0VNUlNFVE1JVEVSTElNSVQ6VHQoMjgsMTYyOSk9czEyZW1yOigyOCwxMTAyKSwwLDY0O2VN
aXRlckxpbWl0OigyNSwxOCksNjQsMzI7X19hczo6KDI4LDE2MzApPSMjKDI4LDE2MzEpPSYo
MjgsMTYyOSk7OlJDMTl0YWdFTVJTRVRNSVRFUkxJTUlUOzJBLjt0YWdFTVJTRVRNSVRFUkxJ
TUlUOjooMjgsMTYzMik9IyMoMjgsMTYzMyk9KigyOCwxNjI5KTs6UkMxOXRhZ0VNUlNFVE1J
VEVSTElNSVQ7MkEuKDI4LDE2MzQpPSMjKDI4LDE2MzMpOzo7MkEuOzsARU1SU0VUTUlURVJM
SU1JVDp0KDI4LDE2MzUpPSgyOCwxNjI5KQBQRU1SU0VUTUlURVJMSU1JVDp0KDI4LDE2MzYp
PSgyOCwxNjMzKQB0YWdFTVJTRVRQQUxFVFRFRU5UUklFUzpUdCgyOCwxNjM3KT1zMjRlbXI6
KDI4LDExMDIpLDAsNjQ7aWhQYWw6KDI1LDE0KSw2NCwzMjtpU3RhcnQ6KDI1LDE0KSw5Niwz
MjtjRW50cmllczooMjUsMTQpLDEyOCwzMjthUGFsRW50cmllczooMjgsMTIwMyksMTYwLDMy
O19fYXM6OigyOCwxNjM4KT0jIygyOCwxNjM5KT0mKDI4LDE2MzcpOzpSQzIzdGFnRU1SU0VU
UEFMRVRURUVOVFJJRVM7MkEuO3RhZ0VNUlNFVFBBTEVUVEVFTlRSSUVTOjooMjgsMTY0MCk9
IyMoMjgsMTY0MSk9KigyOCwxNjM3KTs6UkMyM3RhZ0VNUlNFVFBBTEVUVEVFTlRSSUVTOzJB
LigyOCwxNjQyKT0jIygyOCwxNjQxKTs6OzJBLjs7AEVNUlNFVFBBTEVUVEVFTlRSSUVTOnQo
MjgsMTY0Myk9KDI4LDE2MzcpAFBFTVJTRVRQQUxFVFRFRU5UUklFUzp0KDI4LDE2NDQpPSgy
OCwxNjQxKQB0YWdFTVJTRVRQSVhFTFY6VHQoMjgsMTY0NSk9czIwZW1yOigyOCwxMTAyKSww
LDY0O3B0bFBpeGVsOigyOCwzMjUpLDY0LDY0O2NyQ29sb3I6KDI1LDkpLDEyOCwzMjtfX2Fz
OjooMjgsMTY0Nik9IyMoMjgsMTY0Nyk9JigyOCwxNjQ1KTs6UkMxNXRhZ0VNUlNFVFBJWEVM
VjsyQS47dGFnRU1SU0VUUElYRUxWOjooMjgsMTY0OCk9IyMoMjgsMTY0OSk9KigyOCwxNjQ1
KTs6UkMxNXRhZ0VNUlNFVFBJWEVMVjsyQS4oMjgsMTY1MCk9IyMoMjgsMTY0OSk7OjsyQS47
OwBFTVJTRVRQSVhFTFY6dCgyOCwxNjUxKT0oMjgsMTY0NSkAUEVNUlNFVFBJWEVMVjp0KDI4
LDE2NTIpPSgyOCwxNjQ5KQB0YWdFTVJTRVRWSUVXUE9SVEVYVEVYOlR0KDI4LDE2NTMpPXMx
NmVtcjooMjgsMTEwMiksMCw2NDtzemxFeHRlbnQ6KDI4LDEzNzIpLDY0LDY0O19fYXM6Oigy
OCwxNjU0KT0jIygyOCwxNjU1KT0mKDI4LDE2NTMpOzpSQzIydGFnRU1SU0VUVklFV1BPUlRF
WFRFWDsyQS47dGFnRU1SU0VUVklFV1BPUlRFWFRFWDo6KDI4LDE2NTYpPSMjKDI4LDE2NTcp
PSooMjgsMTY1Myk7OlJDMjJ0YWdFTVJTRVRWSUVXUE9SVEVYVEVYOzJBLigyOCwxNjU4KT0j
IygyOCwxNjU3KTs6OzJBLjs7AEVNUlNFVFZJRVdQT1JURVhURVg6dCgyOCwxNjU5KT0oMjgs
MTY1MykAUEVNUlNFVFZJRVdQT1JURVhURVg6dCgyOCwxNjYwKT0oMjgsMTY1NykARU1SU0VU
V0lORE9XRVhURVg6dCgyOCwxNjYxKT0oMjgsMTY1MykAUEVNUlNFVFdJTkRPV0VYVEVYOnQo
MjgsMTY2Mik9KDI4LDE2NTcpAHRhZ0VNUlNFVFZJRVdQT1JUT1JHRVg6VHQoMjgsMTY2Myk9
czE2ZW1yOigyOCwxMTAyKSwwLDY0O3B0bE9yaWdpbjooMjgsMzI1KSw2NCw2NDtfX2FzOjoo
MjgsMTY2NCk9IyMoMjgsMTY2NSk9JigyOCwxNjYzKTs6UkMyMnRhZ0VNUlNFVFZJRVdQT1JU
T1JHRVg7MkEuO3RhZ0VNUlNFVFZJRVdQT1JUT1JHRVg6OigyOCwxNjY2KT0jIygyOCwxNjY3
KT0qKDI4LDE2NjMpOzpSQzIydGFnRU1SU0VUVklFV1BPUlRPUkdFWDsyQS4oMjgsMTY2OCk9
IyMoMjgsMTY2Nyk7OjsyQS47OwBFTVJTRVRWSUVXUE9SVE9SR0VYOnQoMjgsMTY2OSk9KDI4
LDE2NjMpAFBFTVJTRVRWSUVXUE9SVE9SR0VYOnQoMjgsMTY3MCk9KDI4LDE2NjcpAEVNUlNF
VFdJTkRPV09SR0VYOnQoMjgsMTY3MSk9KDI4LDE2NjMpAFBFTVJTRVRXSU5ET1dPUkdFWDp0
KDI4LDE2NzIpPSgyOCwxNjY3KQBFTVJTRVRCUlVTSE9SR0VYOnQoMjgsMTY3Myk9KDI4LDE2
NjMpAFBFTVJTRVRCUlVTSE9SR0VYOnQoMjgsMTY3NCk9KDI4LDE2NjcpAHRhZ0VNUlNFVFdP
UkxEVFJBTlNGT1JNOlR0KDI4LDE2NzUpPXMzMmVtcjooMjgsMTEwMiksMCw2NDt4Zm9ybToo
MjgsMTEzMiksNjQsMTkyO19fYXM6OigyOCwxNjc2KT0jIygyOCwxNjc3KT0mKDI4LDE2NzUp
OzpSQzIzdGFnRU1SU0VUV09STERUUkFOU0ZPUk07MkEuO3RhZ0VNUlNFVFdPUkxEVFJBTlNG
T1JNOjooMjgsMTY3OCk9IyMoMjgsMTY3OSk9KigyOCwxNjc1KTs6UkMyM3RhZ0VNUlNFVFdP
UkxEVFJBTlNGT1JNOzJBLigyOCwxNjgwKT0jIygyOCwxNjc5KTs6OzJBLjs7AEVNUlNFVFdP
UkxEVFJBTlNGT1JNOnQoMjgsMTY4MSk9KDI4LDE2NzUpAFBFTVJTRVRXT1JMRFRSQU5TRk9S
TTp0KDI4LDE2ODIpPSgyOCwxNjc5KQB0YWdFTVJTVFJFVENIQkxUOlR0KDI4LDE2ODMpPXMx
MDhlbXI6KDI4LDExMDIpLDAsNjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEyODt4RGVzdDoo
MjUsMTMpLDE5MiwzMjt5RGVzdDooMjUsMTMpLDIyNCwzMjtjeERlc3Q6KDI1LDEzKSwyNTYs
MzI7Y3lEZXN0OigyNSwxMyksMjg4LDMyO2R3Um9wOigyNSwxNCksMzIwLDMyO3hTcmM6KDI1
LDEzKSwzNTIsMzI7eVNyYzooMjUsMTMpLDM4NCwzMjt4Zm9ybVNyYzooMjgsMTEzMiksNDE2
LDE5MjtjckJrQ29sb3JTcmM6KDI1LDkpLDYwOCwzMjtpVXNhZ2VTcmM6KDI1LDE0KSw2NDAs
MzI7b2ZmQm1pU3JjOigyNSwxNCksNjcyLDMyO2NiQm1pU3JjOigyNSwxNCksNzA0LDMyO29m
ZkJpdHNTcmM6KDI1LDE0KSw3MzYsMzI7Y2JCaXRzU3JjOigyNSwxNCksNzY4LDMyO2N4U3Jj
OigyNSwxMyksODAwLDMyO2N5U3JjOigyNSwxMyksODMyLDMyO19fYXM6OigyOCwxNjg0KT0j
IygyOCwxNjg1KT0mKDI4LDE2ODMpOzpSQzE2dGFnRU1SU1RSRVRDSEJMVDsyQS47dGFnRU1S
U1RSRVRDSEJMVDo6KDI4LDE2ODYpPSMjKDI4LDE2ODcpPSooMjgsMTY4Myk7OlJDMTZ0YWdF
TVJTVFJFVENIQkxUOzJBLigyOCwxNjg4KT0jIygyOCwxNjg3KTs6OzJBLjs7AEVNUlNUUkVU
Q0hCTFQ6dCgyOCwxNjg5KT0oMjgsMTY4MykAUEVNUlNUUkVUQ0hCTFQ6dCgyOCwxNjkwKT0o
MjgsMTY4NykAdGFnRU1SU1RSRVRDSERJQklUUzpUdCgyOCwxNjkxKT1zODBlbXI6KDI4LDEx
MDIpLDAsNjQ7cmNsQm91bmRzOigyOCwxMjIpLDY0LDEyODt4RGVzdDooMjUsMTMpLDE5Miwz
Mjt5RGVzdDooMjUsMTMpLDIyNCwzMjt4U3JjOigyNSwxMyksMjU2LDMyO3lTcmM6KDI1LDEz
KSwyODgsMzI7Y3hTcmM6KDI1LDEzKSwzMjAsMzI7Y3lTcmM6KDI1LDEzKSwzNTIsMzI7b2Zm
Qm1pU3JjOigyNSwxNCksMzg0LDMyO2NiQm1pU3JjOigyNSwxNCksNDE2LDMyO29mZkJpdHNT
cmM6KDI1LDE0KSw0NDgsMzI7Y2JCaXRzU3JjOigyNSwxNCksNDgwLDMyO2lVc2FnZVNyYzoo
MjUsMTQpLDUxMiwzMjtkd1JvcDooMjUsMTQpLDU0NCwzMjtjeERlc3Q6KDI1LDEzKSw1NzYs
MzI7Y3lEZXN0OigyNSwxMyksNjA4LDMyO19fYXM6OigyOCwxNjkyKT0jIygyOCwxNjkzKT0m
KDI4LDE2OTEpOzpSQzE5dGFnRU1SU1RSRVRDSERJQklUUzsyQS47dGFnRU1SU1RSRVRDSERJ
QklUUzo6KDI4LDE2OTQpPSMjKDI4LDE2OTUpPSooMjgsMTY5MSk7OlJDMTl0YWdFTVJTVFJF
VENIRElCSVRTOzJBLigyOCwxNjk2KT0jIygyOCwxNjk1KTs6OzJBLjs7AEVNUlNUUkVUQ0hE
SUJJVFM6dCgyOCwxNjk3KT0oMjgsMTY5MSkAUEVNUlNUUkVUQ0hESUJJVFM6dCgyOCwxNjk4
KT0oMjgsMTY5NSkAdGFnQUJPUlRQQVRIOlR0KDI4LDE2OTkpPXM4ZW1yOigyOCwxMTAyKSww
LDY0O19fYXM6OigyOCwxNzAwKT0jIygyOCwxNzAxKT0mKDI4LDE2OTkpOzpSQzEydGFnQUJP
UlRQQVRIOzJBLjt0YWdBQk9SVFBBVEg6OigyOCwxNzAyKT0jIygyOCwxNzAzKT0qKDI4LDE2
OTkpOzpSQzEydGFnQUJPUlRQQVRIOzJBLigyOCwxNzA0KT0jIygyOCwxNzAzKTs6OzJBLjs7
AEVNUkFCT1JUUEFUSDp0KDI4LDE3MDUpPSgyOCwxNjk5KQBQRU1SQUJPUlRQQVRIOnQoMjgs
MTcwNik9KDI4LDE3MDMpAEVNUkJFR0lOUEFUSDp0KDI4LDE3MDcpPSgyOCwxNjk5KQBQRU1S
QkVHSU5QQVRIOnQoMjgsMTcwOCk9KDI4LDE3MDMpAEVNUkVORFBBVEg6dCgyOCwxNzA5KT0o
MjgsMTY5OSkAUEVNUkVORFBBVEg6dCgyOCwxNzEwKT0oMjgsMTcwMykARU1SQ0xPU0VGSUdV
UkU6dCgyOCwxNzExKT0oMjgsMTY5OSkAUEVNUkNMT1NFRklHVVJFOnQoMjgsMTcxMik9KDI4
LDE3MDMpAEVNUkZMQVRURU5QQVRIOnQoMjgsMTcxMyk9KDI4LDE2OTkpAFBFTVJGTEFUVEVO
UEFUSDp0KDI4LDE3MTQpPSgyOCwxNzAzKQBFTVJXSURFTlBBVEg6dCgyOCwxNzE1KT0oMjgs
MTY5OSkAUEVNUldJREVOUEFUSDp0KDI4LDE3MTYpPSgyOCwxNzAzKQBFTVJTRVRNRVRBUkdO
OnQoMjgsMTcxNyk9KDI4LDE2OTkpAFBFTVJTRVRNRVRBUkdOOnQoMjgsMTcxOCk9KDI4LDE3
MDMpAEVNUlNBVkVEQzp0KDI4LDE3MTkpPSgyOCwxNjk5KQBQRU1SU0FWRURDOnQoMjgsMTcy
MCk9KDI4LDE3MDMpAEVNUlJFQUxJWkVQQUxFVFRFOnQoMjgsMTcyMSk9KDI4LDE2OTkpAFBF
TVJSRUFMSVpFUEFMRVRURTp0KDI4LDE3MjIpPSgyOCwxNzAzKQB0YWdFTVJTRUxFQ1RDTElQ
UEFUSDpUdCgyOCwxNzIzKT1zMTJlbXI6KDI4LDExMDIpLDAsNjQ7aU1vZGU6KDI1LDE0KSw2
NCwzMjtfX2FzOjooMjgsMTcyNCk9IyMoMjgsMTcyNSk9JigyOCwxNzIzKTs6UkMyMHRhZ0VN
UlNFTEVDVENMSVBQQVRIOzJBLjt0YWdFTVJTRUxFQ1RDTElQUEFUSDo6KDI4LDE3MjYpPSMj
KDI4LDE3MjcpPSooMjgsMTcyMyk7OlJDMjB0YWdFTVJTRUxFQ1RDTElQUEFUSDsyQS4oMjgs
MTcyOCk9IyMoMjgsMTcyNyk7OjsyQS47OwBFTVJTRUxFQ1RDTElQUEFUSDp0KDI4LDE3Mjkp
PSgyOCwxNzIzKQBQRU1SU0VMRUNUQ0xJUFBBVEg6dCgyOCwxNzMwKT0oMjgsMTcyNykARU1S
U0VUQktNT0RFOnQoMjgsMTczMSk9KDI4LDE3MjMpAFBFTVJTRVRCS01PREU6dCgyOCwxNzMy
KT0oMjgsMTcyNykARU1SU0VUTUFQTU9ERTp0KDI4LDE3MzMpPSgyOCwxNzIzKQBQRU1SU0VU
TUFQTU9ERTp0KDI4LDE3MzQpPSgyOCwxNzI3KQBFTVJTRVRQT0xZRklMTE1PREU6dCgyOCwx
NzM1KT0oMjgsMTcyMykAUEVNUlNFVFBPTFlGSUxMTU9ERTp0KDI4LDE3MzYpPSgyOCwxNzI3
KQBFTVJTRVRST1AyOnQoMjgsMTczNyk9KDI4LDE3MjMpAFBFTVJTRVRST1AyOnQoMjgsMTcz
OCk9KDI4LDE3MjcpAEVNUlNFVFNUUkVUQ0hCTFRNT0RFOnQoMjgsMTczOSk9KDI4LDE3MjMp
AFBFTVJTRVRTVFJFVENIQkxUTU9ERTp0KDI4LDE3NDApPSgyOCwxNzI3KQBFTVJTRVRURVhU
QUxJR046dCgyOCwxNzQxKT0oMjgsMTcyMykAUEVNUlNFVFRFWFRBTElHTjp0KDI4LDE3NDIp
PSgyOCwxNzI3KQBFTVJFTkFCTEVJQ006dCgyOCwxNzQzKT0oMjgsMTcyMykAUEVNUkVOQUJM
RUlDTTp0KDI4LDE3NDQpPSgyOCwxNzI3KQB0YWdOTUhEUjpUdCgyOCwxNzQ1KT1zMTJod25k
RnJvbTooMjUsNjEpLDAsMzI7aWRGcm9tOigyNSwxNTApLDMyLDMyO2NvZGU6KDI1LDE1MCks
NjQsMzI7X19hczo6KDI4LDE3NDYpPSMjKDI4LDE3NDcpPSYoMjgsMTc0NSk7OlJDOHRhZ05N
SERSOzJBLjt0YWdOTUhEUjo6KDI4LDE3NDgpPSMjKDI4LDE3NDkpPSooMjgsMTc0NSk7OlJD
OHRhZ05NSERSOzJBLigyOCwxNzUwKT0jIygyOCwxNzQ5KTs6OzJBLjs7AE5NSERSOnQoMjgs
MTc1MSk9KDI4LDE3NDUpAFBOTUhEUjp0KDI4LDE3NTIpPSgyOCwxNzQ5KQBMUE5NSERSOnQo
MjgsMTc1Myk9KDI4LDE3NDkpAF9lbmNvcnJlY3R0ZXh0OlR0KDI4LDE3NTQpPXMyNG5taGRy
OigyOCwxNzUxKSwwLDk2O2Nocmc6KDI4LDQwMSksOTYsNjQ7c2VsdHlwOigyNSwxNTMpLDE2
MCwxNjtfX2FzOjooMjgsMTc1NSk9IyMoMjgsMTc1Nik9JigyOCwxNzU0KTs6UkMxNF9lbmNv
cnJlY3R0ZXh0OzJBLjtfZW5jb3JyZWN0dGV4dDo6KDI4LDE3NTcpPSMjKDI4LDE3NTgpPSoo
MjgsMTc1NCk7OlJDMTRfZW5jb3JyZWN0dGV4dDsyQS4oMjgsMTc1OSk9IyMoMjgsMTc1OCk7
OjsyQS47OwBFTkNPUlJFQ1RURVhUOnQoMjgsMTc2MCk9KDI4LDE3NTQpAF9lbmRyb3BmaWxl
czpUdCgyOCwxNzYxKT1zMjRubWhkcjooMjgsMTc1MSksMCw5NjtoRHJvcDooMjUsMTkpLDk2
LDMyO2NwOigyNSwxMyksMTI4LDMyO2ZQcm90ZWN0ZWQ6KDI1LDIpLDE2MCwzMjtfX2FzOjoo
MjgsMTc2Mik9IyMoMjgsMTc2Myk9JigyOCwxNzYxKTs6UkMxMl9lbmRyb3BmaWxlczsyQS47
X2VuZHJvcGZpbGVzOjooMjgsMTc2NCk9IyMoMjgsMTc2NSk9KigyOCwxNzYxKTs6UkMxMl9l
bmRyb3BmaWxlczsyQS4oMjgsMTc2Nik9IyMoMjgsMTc2NSk7OjsyQS47OwBFTkRST1BGSUxF
Uzp0KDI4LDE3NjcpPSgyOCwxNzYxKQBFTlNBVkVDTElQQk9BUkQ6dCgyOCwxNzY4KT1zMjBu
bWhkcjooMjgsMTc1MSksMCw5NjtjT2JqZWN0Q291bnQ6KDI1LDEzKSw5NiwzMjtjY2g6KDI1
LDEzKSwxMjgsMzI7X19hczo6KDI4LDE3NjkpPSMoMjgsMTc2OCksKDI4LDE3NzApPSYoMjgs
MTc2OCksKDI4LDE3NzEpPSooMjgsMTc2OCksKDI4LDE3NzIpPSYoMjgsMTc3Myk9czIwbm1o
ZHI6KDI4LDE3NTEpLDAsOTY7Y09iamVjdENvdW50OigyNSwxMyksOTYsMzI7Y2NoOigyNSwx
MyksMTI4LDMyO19fYXM6OigyOCwxNzY5KTpfX2FzX180JF8xNlJDNCRfMTY7MkEuOyRfMTY6
OigyOCwxNzc0KT0jKDI4LDE3NjgpLCgyOCwxNzcxKSwoMjgsMTc3MSksKDI4LDE3NzIpLCgw
LDIwKTs6X180JF8xNlJDNCRfMTY7MkEuKDI4LDE3NzUpPSMoMjgsMTc2OCksKDI4LDE3NzEp
LCgyOCwxNzcxKSwoMCwyMCk7Ol9fNCRfMTY7MkEuOzssKDAsMjApOzpfX2FzX180JF8xNlJD
NCRfMTY7MkEuOyRfMTY6OigyOCwxNzc0KTpfXzQkXzE2UkM0JF8xNjsyQS4oMjgsMTc3NSk6
X180JF8xNjsyQS47OwBFTk9MRU9QRkFJTEVEOnQoMjgsMTc3Nik9czI0bm1oZHI6KDI4LDE3
NTEpLDAsOTY7aW9iOigyNSwxMyksOTYsMzI7bE9wZXI6KDI1LDEzKSwxMjgsMzI7aHI6KDI1
LDU1KSwxNjAsMzI7X19hczo6KDI4LDE3NzcpPSMoMjgsMTc3NiksKDI4LDE3NzgpPSYoMjgs
MTc3NiksKDI4LDE3NzkpPSooMjgsMTc3NiksKDI4LDE3ODApPSYoMjgsMTc4MSk9czI0bm1o
ZHI6KDI4LDE3NTEpLDAsOTY7aW9iOigyNSwxMyksOTYsMzI7bE9wZXI6KDI1LDEzKSwxMjgs
MzI7aHI6KDI1LDU1KSwxNjAsMzI7X19hczo6KDI4LDE3NzcpOl9fYXNfXzQkXzE3UkM0JF8x
NzsyQS47JF8xNzo6KDI4LDE3ODIpPSMoMjgsMTc3NiksKDI4LDE3NzkpLCgyOCwxNzc5KSwo
MjgsMTc4MCksKDAsMjApOzpfXzQkXzE3UkM0JF8xNzsyQS4oMjgsMTc4Myk9IygyOCwxNzc2
KSwoMjgsMTc3OSksKDI4LDE3NzkpLCgwLDIwKTs6X180JF8xNzsyQS47OywoMCwyMCk7Ol9f
YXNfXzQkXzE3UkM0JF8xNzsyQS47JF8xNzo6KDI4LDE3ODIpOl9fNCRfMTdSQzQkXzE3OzJB
LigyOCwxNzgzKTpfXzQkXzE3OzJBLjs7AHRhZ0VOSE1FVEFIRUFERVI6VHQoMjgsMTc4NCk9
czg4aVR5cGU6KDI1LDE0KSwwLDMyO25TaXplOigyNSwxNCksMzIsMzI7cmNsQm91bmRzOigy
OCwxMjIpLDY0LDEyODtyY2xGcmFtZTooMjgsMTIyKSwxOTIsMTI4O2RTaWduYXR1cmU6KDI1
LDE0KSwzMjAsMzI7blZlcnNpb246KDI1LDE0KSwzNTIsMzI7bkJ5dGVzOigyNSwxNCksMzg0
LDMyO25SZWNvcmRzOigyNSwxNCksNDE2LDMyO25IYW5kbGVzOigyNSwxNTMpLDQ0OCwxNjtz
UmVzZXJ2ZWQ6KDI1LDE1MyksNDY0LDE2O25EZXNjcmlwdGlvbjooMjUsMTQpLDQ4MCwzMjtv
ZmZEZXNjcmlwdGlvbjooMjUsMTQpLDUxMiwzMjtuUGFsRW50cmllczooMjUsMTQpLDU0NCwz
MjtzemxEZXZpY2U6KDI4LDEzNzIpLDU3Niw2NDtzemxNaWxsaW1ldGVyczooMjgsMTM3Miks
NjQwLDY0O19fYXM6OigyOCwxNzg1KT0jIygyOCwxNzg2KT0mKDI4LDE3ODQpOzpSQzE2dGFn
RU5ITUVUQUhFQURFUjsyQS47dGFnRU5ITUVUQUhFQURFUjo6KDI4LDE3ODcpPSMjKDI4LDE3
ODgpPSooMjgsMTc4NCk7OlJDMTZ0YWdFTkhNRVRBSEVBREVSOzJBLigyOCwxNzg5KT0jIygy
OCwxNzg4KTs6OzJBLjs7AEVOSE1FVEFIRUFERVI6dCgyOCwxNzkwKT0oMjgsMTc4NCkATFBF
TkhNRVRBSEVBREVSOnQoMjgsMTc5MSk9KDI4LDE3ODgpAHRhZ0VOSE1FVEFSRUNPUkQ6VHQo
MjgsMTc5Mik9czEyaVR5cGU6KDI1LDE0KSwwLDMyO25TaXplOigyNSwxNCksMzIsMzI7ZFBh
cm06KDI4LDM0MiksNjQsMzI7X19hczo6KDI4LDE3OTMpPSMjKDI4LDE3OTQpPSYoMjgsMTc5
Mik7OlJDMTZ0YWdFTkhNRVRBUkVDT1JEOzJBLjt0YWdFTkhNRVRBUkVDT1JEOjooMjgsMTc5
NSk9IyMoMjgsMTc5Nik9KigyOCwxNzkyKTs6UkMxNnRhZ0VOSE1FVEFSRUNPUkQ7MkEuKDI4
LDE3OTcpPSMjKDI4LDE3OTYpOzo7MkEuOzsARU5ITUVUQVJFQ09SRDp0KDI4LDE3OTgpPSgy
OCwxNzkyKQBQRU5ITUVUQVJFQ09SRDp0KDI4LDE3OTkpPSgyOCwxNzk2KQBMUEVOSE1FVEFS
RUNPUkQ6dCgyOCwxODAwKT0oMjgsMTc5NikAX2VucHJvdGVjdGVkOlR0KDI4LDE4MDEpPXMz
Mm5taGRyOigyOCwxNzUxKSwwLDk2O21zZzooMjUsMTUwKSw5NiwzMjt3UGFyYW06KDI1LDE1
NCksMTI4LDMyO2xQYXJhbTooMjUsNzApLDE2MCwzMjtjaHJnOigyOCw0MDEpLDE5Miw2NDtf
X2FzOjooMjgsMTgwMik9IyMoMjgsMTgwMyk9JigyOCwxODAxKTs6UkMxMl9lbnByb3RlY3Rl
ZDsyQS47X2VucHJvdGVjdGVkOjooMjgsMTgwNCk9IyMoMjgsMTgwNSk9KigyOCwxODAxKTs6
UkMxMl9lbnByb3RlY3RlZDsyQS4oMjgsMTgwNik9IyMoMjgsMTgwNSk7OjsyQS47OwBFTlBS
T1RFQ1RFRDp0KDI4LDE4MDcpPSgyOCwxODAxKQBfU0VSVklDRV9TVEFUVVM6VHQoMjgsMTgw
OCk9czI4ZHdTZXJ2aWNlVHlwZTooMjUsMTQpLDAsMzI7ZHdDdXJyZW50U3RhdGU6KDI1LDE0
KSwzMiwzMjtkd0NvbnRyb2xzQWNjZXB0ZWQ6KDI1LDE0KSw2NCwzMjtkd1dpbjMyRXhpdENv
ZGU6KDI1LDE0KSw5NiwzMjtkd1NlcnZpY2VTcGVjaWZpY0V4aXRDb2RlOigyNSwxNCksMTI4
LDMyO2R3Q2hlY2tQb2ludDooMjUsMTQpLDE2MCwzMjtkd1dhaXRIaW50OigyNSwxNCksMTky
LDMyO19fYXM6OigyOCwxODA5KT0jIygyOCwxODEwKT0mKDI4LDE4MDgpOzpSQzE1X1NFUlZJ
Q0VfU1RBVFVTOzJBLjtfU0VSVklDRV9TVEFUVVM6OigyOCwxODExKT0jIygyOCwxODEyKT0q
KDI4LDE4MDgpOzpSQzE1X1NFUlZJQ0VfU1RBVFVTOzJBLigyOCwxODEzKT0jIygyOCwxODEy
KTs6OzJBLjs7AFNFUlZJQ0VfU1RBVFVTOnQoMjgsMTgxNCk9KDI4LDE4MDgpAExQU0VSVklD
RV9TVEFUVVM6dCgyOCwxODE1KT0oMjgsMTgxMikAX0VOVU1fU0VSVklDRV9TVEFUVVM6VHQo
MjgsMTgxNik9czM2bHBTZXJ2aWNlTmFtZTooMjUsOTYpLDAsMzI7bHBEaXNwbGF5TmFtZToo
MjUsOTYpLDMyLDMyO1NlcnZpY2VTdGF0dXM6KDI4LDE4MTQpLDY0LDIyNDtfX2FzOjooMjgs
MTgxNyk9IyMoMjgsMTgxOCk9JigyOCwxODE2KTs6UkMyMF9FTlVNX1NFUlZJQ0VfU1RBVFVT
OzJBLjtfRU5VTV9TRVJWSUNFX1NUQVRVUzo6KDI4LDE4MTkpPSMjKDI4LDE4MjApPSooMjgs
MTgxNik7OlJDMjBfRU5VTV9TRVJWSUNFX1NUQVRVUzsyQS4oMjgsMTgyMSk9IyMoMjgsMTgy
MCk7OjsyQS47OwBFTlVNX1NFUlZJQ0VfU1RBVFVTOnQoMjgsMTgyMik9KDI4LDE4MTYpAExQ
RU5VTV9TRVJWSUNFX1NUQVRVUzp0KDI4LDE4MjMpPSgyOCwxODIwKQB0YWdFTlVNTE9HRk9O
VDpUdCgyOCwxODI0KT1zMTU2ZWxmTG9nRm9udDooMjgsNDU2KSwwLDQ4MDtlbGZGdWxsTmFt
ZTooMjgsMTI3MSksNDgwLDUxMjtlbGZTdHlsZTooMjgsOTM0KSw5OTIsMjU2O19fYXM6Oigy
OCwxODI1KT0jIygyOCwxODI2KT0mKDI4LDE4MjQpOzpSQzE0dGFnRU5VTUxPR0ZPTlQ7MkEu
O3RhZ0VOVU1MT0dGT05UOjooMjgsMTgyNyk9IyMoMjgsMTgyOCk9KigyOCwxODI0KTs6UkMx
NHRhZ0VOVU1MT0dGT05UOzJBLigyOCwxODI5KT0jIygyOCwxODI4KTs6OzJBLjs7AEVOVU1M
T0dGT05UOnQoMjgsMTgzMCk9KDI4LDE4MjQpAHRhZ0VOVU1MT0dGT05URVg6VHQoMjgsMTgz
MSk9czE4OGVsZkxvZ0ZvbnQ6KDI4LDQ1NiksMCw0ODA7ZWxmRnVsbE5hbWU6KDI4LDEyNzEp
LDQ4MCw1MTI7ZWxmU3R5bGU6KDI4LDkzNCksOTkyLDI1NjtlbGZTY3JpcHQ6KDI4LDkzNCks
MTI0OCwyNTY7X19hczo6KDI4LDE4MzIpPSMjKDI4LDE4MzMpPSYoMjgsMTgzMSk7OlJDMTZ0
YWdFTlVNTE9HRk9OVEVYOzJBLjt0YWdFTlVNTE9HRk9OVEVYOjooMjgsMTgzNCk9IyMoMjgs
MTgzNSk9KigyOCwxODMxKTs6UkMxNnRhZ0VOVU1MT0dGT05URVg7MkEuKDI4LDE4MzYpPSMj
KDI4LDE4MzUpOzo7MkEuOzsARU5VTUxPR0ZPTlRFWDp0KDI4LDE4MzcpPSgyOCwxODMxKQBf
RVZFTlRMT0dSRUNPUkQ6VHQoMjgsMTgzOCk9czU2TGVuZ3RoOigyNSwxNCksMCwzMjtSZXNl
cnZlZDooMjUsMTQpLDMyLDMyO1JlY29yZE51bWJlcjooMjUsMTQpLDY0LDMyO1RpbWVHZW5l
cmF0ZWQ6KDI1LDE0KSw5NiwzMjtUaW1lV3JpdHRlbjooMjUsMTQpLDEyOCwzMjtFdmVudElE
OigyNSwxNCksMTYwLDMyO0V2ZW50VHlwZTooMjUsMTUzKSwxOTIsMTY7TnVtU3RyaW5nczoo
MjUsMTUzKSwyMDgsMTY7RXZlbnRDYXRlZ29yeTooMjUsMTUzKSwyMjQsMTY7UmVzZXJ2ZWRG
bGFnczooMjUsMTUzKSwyNDAsMTY7Q2xvc2luZ1JlY29yZE51bWJlcjooMjUsMTQpLDI1Niwz
MjtTdHJpbmdPZmZzZXQ6KDI1LDE0KSwyODgsMzI7VXNlclNpZExlbmd0aDooMjUsMTQpLDMy
MCwzMjtVc2VyU2lkT2Zmc2V0OigyNSwxNCksMzUyLDMyO0RhdGFMZW5ndGg6KDI1LDE0KSwz
ODQsMzI7RGF0YU9mZnNldDooMjUsMTQpLDQxNiwzMjtfX2FzOjooMjgsMTgzOSk9IyMoMjgs
MTg0MCk9JigyOCwxODM4KTs6UkMxNV9FVkVOVExPR1JFQ09SRDsyQS47X0VWRU5UTE9HUkVD
T1JEOjooMjgsMTg0MSk9IyMoMjgsMTg0Mik9KigyOCwxODM4KTs6UkMxNV9FVkVOVExPR1JF
Q09SRDsyQS4oMjgsMTg0Myk9IyMoMjgsMTg0Mik7OjsyQS47OwBFVkVOVExPR1JFQ09SRDp0
KDI4LDE4NDQpPSgyOCwxODM4KQB0YWdFVkVOVE1TRzpUdCgyOCwxODQ1KT1zMjBtZXNzYWdl
OigyNSwxNTApLDAsMzI7cGFyYW1MOigyNSwxNTApLDMyLDMyO3BhcmFtSDooMjUsMTUwKSw2
NCwzMjt0aW1lOigyNSwxNCksOTYsMzI7aHduZDooMjUsNjEpLDEyOCwzMjtfX2FzOjooMjgs
MTg0Nik9IyMoMjgsMTg0Nyk9JigyOCwxODQ1KTs6UkMxMXRhZ0VWRU5UTVNHOzJBLjt0YWdF
VkVOVE1TRzo6KDI4LDE4NDgpPSMjKDI4LDE4NDkpPSooMjgsMTg0NSk7OlJDMTF0YWdFVkVO
VE1TRzsyQS4oMjgsMTg1MCk9IyMoMjgsMTg0OSk7OjsyQS47OwBFVkVOVE1TRzp0KDI4LDE4
NTEpPSgyOCwxODQ1KQBfRVhDRVBUSU9OX1BPSU5URVJTOlR0KDI4LDE4NTIpPXM4RXhjZXB0
aW9uUmVjb3JkOigyOCw4MTApLDAsMzI7Q29udGV4dFJlY29yZDooMjgsNjIxKSwzMiwzMjtf
X2FzOjooMjgsMTg1Myk9IyMoMjgsMTg1NCk9JigyOCwxODUyKTs6UkMxOV9FWENFUFRJT05f
UE9JTlRFUlM7MkEuO19FWENFUFRJT05fUE9JTlRFUlM6OigyOCwxODU1KT0jIygyOCwxODU2
KT0qKDI4LDE4NTIpOzpSQzE5X0VYQ0VQVElPTl9QT0lOVEVSUzsyQS4oMjgsMTg1Nyk9IyMo
MjgsMTg1Nik7OjsyQS47OwBFWENFUFRJT05fUE9JTlRFUlM6dCgyOCwxODU4KT0oMjgsMTg1
MikAUEVYQ0VQVElPTl9QT0lOVEVSUzp0KDI4LDE4NTkpPSgyOCwxODU2KQBMUEVYQ0VQVElP
Tl9QT0lOVEVSUzp0KDI4LDE4NjApPSgyOCwxODU2KQBfRVhUX0JVVFRPTjpUdCgyOCwxODYx
KT1zNmlkQ29tbWFuZDooMjUsMTUzKSwwLDE2O2lkc0hlbHA6KDI1LDE1MyksMTYsMTY7ZnNT
dHlsZTooMjUsMTUzKSwzMiwxNjtfX2FzOjooMjgsMTg2Mik9IyMoMjgsMTg2Myk9JigyOCwx
ODYxKTs6UkMxMV9FWFRfQlVUVE9OOzJBLjtfRVhUX0JVVFRPTjo6KDI4LDE4NjQpPSMjKDI4
LDE4NjUpPSooMjgsMTg2MSk7OlJDMTFfRVhUX0JVVFRPTjsyQS4oMjgsMTg2Nik9IyMoMjgs
MTg2NSk7OjsyQS47OwBFWFRfQlVUVE9OOnQoMjgsMTg2Nyk9KDI4LDE4NjEpAExQRVhUX0JV
VFRPTjp0KDI4LDE4NjgpPSgyOCwxODY1KQB0YWdGSUxURVJLRVlTOlR0KDI4LDE4NjkpPXMy
NGNiU2l6ZTooMjUsMTUwKSwwLDMyO2R3RmxhZ3M6KDI1LDE0KSwzMiwzMjtpV2FpdE1TZWM6
KDI1LDE0KSw2NCwzMjtpRGVsYXlNU2VjOigyNSwxNCksOTYsMzI7aVJlcGVhdE1TZWM6KDI1
LDE0KSwxMjgsMzI7aUJvdW5jZU1TZWM6KDI1LDE0KSwxNjAsMzI7X19hczo6KDI4LDE4NzAp
PSMjKDI4LDE4NzEpPSYoMjgsMTg2OSk7OlJDMTN0YWdGSUxURVJLRVlTOzJBLjt0YWdGSUxU
RVJLRVlTOjooMjgsMTg3Mik9IyMoMjgsMTg3Myk9KigyOCwxODY5KTs6UkMxM3RhZ0ZJTFRF
UktFWVM7MkEuKDI4LDE4NzQpPSMjKDI4LDE4NzMpOzo7MkEuOzsARklMVEVSS0VZUzp0KDI4
LDE4NzUpPSgyOCwxODY5KQBfRklORF9OQU1FX0JVRkZFUjpUdCgyOCwxODc2KT1zMzNsZW5n
dGg6KDI1LDE0OSksMCw4O2FjY2Vzc19jb250cm9sOigyNSwxNDkpLDgsODtmcmFtZV9jb250
cm9sOigyNSwxNDkpLDE2LDg7ZGVzdGluYXRpb25fYWRkcjooMjgsODUpLDI0LDQ4O3NvdXJj
ZV9hZGRyOigyOCw4NSksNzIsNDg7cm91dGluZ19pbmZvOigyOCwxODc3KT1hcigwLDEpOzA7
MTc7KDAsMTEpLDEyMCwxNDQ7X19hczo6KDI4LDE4NzgpPSMjKDI4LDE4NzkpPSYoMjgsMTg3
Nik7OlJDMTdfRklORF9OQU1FX0JVRkZFUjsyQS47X0ZJTkRfTkFNRV9CVUZGRVI6OigyOCwx
ODgwKT0jIygyOCwxODgxKT0qKDI4LDE4NzYpOzpSQzE3X0ZJTkRfTkFNRV9CVUZGRVI7MkEu
KDI4LDE4ODIpPSMjKDI4LDE4ODEpOzo7MkEuOzsARklORF9OQU1FX0JVRkZFUjp0KDI4LDE4
ODMpPSgyOCwxODc2KQBfRklORF9OQU1FX0hFQURFUjpUdCgyOCwxODg0KT1zNG5vZGVfY291
bnQ6KDI1LDE1MyksMCwxNjtyZXNlcnZlZDooMjUsMTQ5KSwxNiw4O3VuaXF1ZV9ncm91cDoo
MjUsMTQ5KSwyNCw4O19fYXM6OigyOCwxODg1KT0jIygyOCwxODg2KT0mKDI4LDE4ODQpOzpS
QzE3X0ZJTkRfTkFNRV9IRUFERVI7MkEuO19GSU5EX05BTUVfSEVBREVSOjooMjgsMTg4Nyk9
IyMoMjgsMTg4OCk9KigyOCwxODg0KTs6UkMxN19GSU5EX05BTUVfSEVBREVSOzJBLigyOCwx
ODg5KT0jIygyOCwxODg4KTs6OzJBLjs7AEZJTkRfTkFNRV9IRUFERVI6dCgyOCwxODkwKT0o
MjgsMTg4NCkARklORFJFUExBQ0U6dCgyOCwxODkxKT1zNDBsU3RydWN0U2l6ZTooMjUsMTQp
LDAsMzI7aHduZE93bmVyOigyNSw2MSksMzIsMzI7aEluc3RhbmNlOigyNSw0MyksNjQsMzI7
RmxhZ3M6KDI1LDE0KSw5NiwzMjtscHN0ckZpbmRXaGF0OigyNSw5NiksMTI4LDMyO2xwc3Ry
UmVwbGFjZVdpdGg6KDI1LDk2KSwxNjAsMzI7d0ZpbmRXaGF0TGVuOigyNSwxNTMpLDE5Miwx
Njt3UmVwbGFjZVdpdGhMZW46KDI1LDE1MyksMjA4LDE2O2xDdXN0RGF0YTooMjUsNzApLDIy
NCwzMjtscGZuSG9vazooMjUsMTg3KSwyNTYsMzI7bHBUZW1wbGF0ZU5hbWU6KDI1LDgzKSwy
ODgsMzI7X19hczo6KDI4LDE4OTIpPSMoMjgsMTg5MSksKDI4LDE4OTMpPSYoMjgsMTg5MSks
KDI4LDE4OTQpPSooMjgsMTg5MSksKDI4LDE4OTUpPSYoMjgsMTg5Nik9czQwbFN0cnVjdFNp
emU6KDI1LDE0KSwwLDMyO2h3bmRPd25lcjooMjUsNjEpLDMyLDMyO2hJbnN0YW5jZTooMjUs
NDMpLDY0LDMyO0ZsYWdzOigyNSwxNCksOTYsMzI7bHBzdHJGaW5kV2hhdDooMjUsOTYpLDEy
OCwzMjtscHN0clJlcGxhY2VXaXRoOigyNSw5NiksMTYwLDMyO3dGaW5kV2hhdExlbjooMjUs
MTUzKSwxOTIsMTY7d1JlcGxhY2VXaXRoTGVuOigyNSwxNTMpLDIwOCwxNjtsQ3VzdERhdGE6
KDI1LDcwKSwyMjQsMzI7bHBmbkhvb2s6KDI1LDE4NyksMjU2LDMyO2xwVGVtcGxhdGVOYW1l
OigyNSw4MyksMjg4LDMyO19fYXM6OigyOCwxODkyKTpfX2FzX180JF8xOFJDNCRfMTg7MkEu
OyRfMTg6OigyOCwxODk3KT0jKDI4LDE4OTEpLCgyOCwxODk0KSwoMjgsMTg5NCksKDI4LDE4
OTUpLCgwLDIwKTs6X180JF8xOFJDNCRfMTg7MkEuKDI4LDE4OTgpPSMoMjgsMTg5MSksKDI4
LDE4OTQpLCgyOCwxODk0KSwoMCwyMCk7Ol9fNCRfMTg7MkEuOzssKDAsMjApOzpfX2FzX180
JF8xOFJDNCRfMTg7MkEuOyRfMTg6OigyOCwxODk3KTpfXzQkXzE4UkM0JF8xODsyQS4oMjgs
MTg5OCk6X180JF8xODsyQS47OwBMUEZJTkRSRVBMQUNFOnQoMjgsMTg5OSk9KDI4LDE4OTQp
AF9maW5kdGV4dDpUdCgyOCwxOTAwKT1zMTJjaHJnOigyOCw0MDEpLDAsNjQ7bHBzdHJUZXh0
OigyNSw5NCksNjQsMzI7X19hczo6KDI4LDE5MDEpPSMjKDI4LDE5MDIpPSYoMjgsMTkwMCk7
OlJDOV9maW5kdGV4dDsyQS47X2ZpbmR0ZXh0OjooMjgsMTkwMyk9IyMoMjgsMTkwNCk9Kigy
OCwxOTAwKTs6UkM5X2ZpbmR0ZXh0OzJBLigyOCwxOTA1KT0jIygyOCwxOTA0KTs6OzJBLjs7
AEZJTkRURVhUOnQoMjgsMTkwNik9KDI4LDE5MDApAF9maW5kdGV4dGV4OlR0KDI4LDE5MDcp
PXMyMGNocmc6KDI4LDQwMSksMCw2NDtscHN0clRleHQ6KDI1LDk0KSw2NCwzMjtjaHJnVGV4
dDooMjgsNDAxKSw5Niw2NDtfX2FzOjooMjgsMTkwOCk9IyMoMjgsMTkwOSk9JigyOCwxOTA3
KTs6UkMxMV9maW5kdGV4dGV4OzJBLjtfZmluZHRleHRleDo6KDI4LDE5MTApPSMjKDI4LDE5
MTEpPSooMjgsMTkwNyk7OlJDMTFfZmluZHRleHRleDsyQS4oMjgsMTkxMik9IyMoMjgsMTkx
MSk7OjsyQS47OwBGSU5EVEVYVEVYOnQoMjgsMTkxMyk9KDI4LDE5MDcpAF9GTVNfR0VURFJJ
VkVJTkZPOlR0KDI4LDE5MTQpPXM0MTJkd1RvdGFsU3BhY2U6KDI1LDE0KSwwLDMyO2R3RnJl
ZVNwYWNlOigyNSwxNCksMzIsMzI7c3pQYXRoOigyOCwxMTYxKSw2NCwyMDgwO3N6Vm9sdW1l
OigyOCwxOTE1KT1hcigwLDEpOzA7MTM7KDAsMiksMjE0NCwxMTI7c3pTaGFyZTooMjgsMTkx
Nik9YXIoMCwxKTswOzEyNzsoMCwyKSwyMjU2LDEwMjQ7X19hczo6KDI4LDE5MTcpPSMjKDI4
LDE5MTgpPSYoMjgsMTkxNCk7OlJDMTdfRk1TX0dFVERSSVZFSU5GTzsyQS47X0ZNU19HRVRE
UklWRUlORk86OigyOCwxOTE5KT0jIygyOCwxOTIwKT0qKDI4LDE5MTQpOzpSQzE3X0ZNU19H
RVREUklWRUlORk87MkEuKDI4LDE5MjEpPSMjKDI4LDE5MjApOzo7MkEuOzsARk1TX0dFVERS
SVZFSU5GTzp0KDI4LDE5MjIpPSgyOCwxOTE0KQBfRk1TX0dFVEZJTEVTRUw6VHQoMjgsMTky
Myk9czI3NmZ0VGltZTooMjgsMjg1KSwwLDY0O2R3U2l6ZTooMjUsMTQpLDY0LDMyO2JBdHRy
OigyNSw1KSw5Niw4O3N6TmFtZTooMjgsMTE2MSksMTA0LDIwODA7X19hczo6KDI4LDE5MjQp
PSMjKDI4LDE5MjUpPSYoMjgsMTkyMyk7OlJDMTVfRk1TX0dFVEZJTEVTRUw7MkEuO19GTVNf
R0VURklMRVNFTDo6KDI4LDE5MjYpPSMjKDI4LDE5MjcpPSooMjgsMTkyMyk7OlJDMTVfRk1T
X0dFVEZJTEVTRUw7MkEuKDI4LDE5MjgpPSMjKDI4LDE5MjcpOzo7MkEuOzsARk1TX0dFVEZJ
TEVTRUw6dCgyOCwxOTI5KT0oMjgsMTkyMykAX0ZNU19MT0FEOlR0KDI4LDE5MzApPXM1MmR3
U2l6ZTooMjUsMTQpLDAsMzI7c3pNZW51TmFtZTooMjgsMTkzMSk9YXIoMCwxKTswOzM5Oygw
LDIpLDMyLDMyMDtoTWVudTooMjUsNDkpLDM1MiwzMjt3TWVudURlbHRhOigyNSwxNTApLDM4
NCwzMjtfX2FzOjooMjgsMTkzMik9IyMoMjgsMTkzMyk9JigyOCwxOTMwKTs6UkM5X0ZNU19M
T0FEOzJBLjtfRk1TX0xPQUQ6OigyOCwxOTM0KT0jIygyOCwxOTM1KT0qKDI4LDE5MzApOzpS
QzlfRk1TX0xPQUQ7MkEuKDI4LDE5MzYpPSMjKDI4LDE5MzUpOzo7MkEuOzsARk1TX0xPQUQ6
dCgyOCwxOTM3KT0oMjgsMTkzMCkAX0ZNU19UT09MQkFSTE9BRDpUdCgyOCwxOTM4KT1zMjBk
d1NpemU6KDI1LDE0KSwwLDMyO2xwQnV0dG9uczooMjgsMTg2OCksMzIsMzI7Y0J1dHRvbnM6
KDI1LDE1MyksNjQsMTY7Y0JpdG1hcHM6KDI1LDE1MyksODAsMTY7aWRCaXRtYXA6KDI1LDE1
MyksOTYsMTY7aEJpdG1hcDooMjUsMjEpLDEyOCwzMjtfX2FzOjooMjgsMTkzOSk9IyMoMjgs
MTk0MCk9JigyOCwxOTM4KTs6UkMxNl9GTVNfVE9PTEJBUkxPQUQ7MkEuO19GTVNfVE9PTEJB
UkxPQUQ6OigyOCwxOTQxKT0jIygyOCwxOTQyKT0qKDI4LDE5MzgpOzpSQzE2X0ZNU19UT09M
QkFSTE9BRDsyQS4oMjgsMTk0Myk9IyMoMjgsMTk0Mik7OjsyQS47OwBGTVNfVE9PTEJBUkxP
QUQ6dCgyOCwxOTQ0KT0oMjgsMTkzOCkAX0ZPQ1VTX0VWRU5UX1JFQ09SRDpUdCgyOCwxOTQ1
KT1zNGJTZXRGb2N1czooMjUsMiksMCwzMjtfX2FzOjooMjgsMTk0Nik9IyMoMjgsMTk0Nyk9
JigyOCwxOTQ1KTs6UkMxOV9GT0NVU19FVkVOVF9SRUNPUkQ7MkEuO19GT0NVU19FVkVOVF9S
RUNPUkQ6OigyOCwxOTQ4KT0jIygyOCwxOTQ5KT0qKDI4LDE5NDUpOzpSQzE5X0ZPQ1VTX0VW
RU5UX1JFQ09SRDsyQS4oMjgsMTk1MCk9IyMoMjgsMTk0OSk7OjsyQS47OwBGT0NVU19FVkVO
VF9SRUNPUkQ6dCgyOCwxOTUxKT0oMjgsMTk0NSkAX0ZPUk1fSU5GT18xOlR0KDI4LDE5NTIp
PXMzMkZsYWdzOigyNSwxNCksMCwzMjtwTmFtZTooMjUsOTYpLDMyLDMyO1NpemU6KDI4LDEz
NzIpLDY0LDY0O0ltYWdlYWJsZUFyZWE6KDI4LDEyMiksMTI4LDEyODtfX2FzOjooMjgsMTk1
Myk9IyMoMjgsMTk1NCk9JigyOCwxOTUyKTs6UkMxMl9GT1JNX0lORk9fMTsyQS47X0ZPUk1f
SU5GT18xOjooMjgsMTk1NSk9IyMoMjgsMTk1Nik9KigyOCwxOTUyKTs6UkMxMl9GT1JNX0lO
Rk9fMTsyQS4oMjgsMTk1Nyk9IyMoMjgsMTk1Nik7OjsyQS47OwBGT1JNX0lORk9fMTp0KDI4
LDE5NTgpPSgyOCwxOTUyKQBfRk9STUFUX1BBUkFNRVRFUlM6VHQoMjgsMTk1OSk9czIwTWVk
aWFUeXBlOigyNSwxNTgpLDAsMzI7U3RhcnRDeWxpbmRlck51bWJlcjooMjUsMTQpLDMyLDMy
O0VuZEN5bGluZGVyTnVtYmVyOigyNSwxNCksNjQsMzI7U3RhcnRIZWFkTnVtYmVyOigyNSwx
NCksOTYsMzI7RW5kSGVhZE51bWJlcjooMjUsMTQpLDEyOCwzMjtfX2FzOjooMjgsMTk2MCk9
IyMoMjgsMTk2MSk9JigyOCwxOTU5KTs6UkMxOF9GT1JNQVRfUEFSQU1FVEVSUzsyQS47X0ZP
Uk1BVF9QQVJBTUVURVJTOjooMjgsMTk2Mik9IyMoMjgsMTk2Myk9KigyOCwxOTU5KTs6UkMx
OF9GT1JNQVRfUEFSQU1FVEVSUzsyQS4oMjgsMTk2NCk9IyMoMjgsMTk2Myk7OjsyQS47OwBG
T1JNQVRfUEFSQU1FVEVSUzp0KDI4LDE5NjUpPSgyOCwxOTU5KQBfZm9ybWF0cmFuZ2U6VHQo
MjgsMTk2Nik9czQ4aGRjOigyNSwyOCksMCwzMjtoZGNUYXJnZXQ6KDI1LDI4KSwzMiwzMjty
YzooMjgsMTEzKSw2NCwxMjg7cmNQYWdlOigyOCwxMTMpLDE5MiwxMjg7Y2hyZzooMjgsNDAx
KSwzMjAsNjQ7X19hczo6KDI4LDE5NjcpPSMjKDI4LDE5NjgpPSYoMjgsMTk2Nik7OlJDMTJf
Zm9ybWF0cmFuZ2U7MkEuO19mb3JtYXRyYW5nZTo6KDI4LDE5NjkpPSMjKDI4LDE5NzApPSoo
MjgsMTk2Nik7OlJDMTJfZm9ybWF0cmFuZ2U7MkEuKDI4LDE5NzEpPSMjKDI4LDE5NzApOzo7
MkEuOzsARk9STUFUUkFOR0U6dCgyOCwxOTcyKT0oMjgsMTk2NikAdGFnR0NQX1JFU1VMVFM6
VHQoMjgsMTk3Myk9czM2bFN0cnVjdFNpemU6KDI1LDE0KSwwLDMyO2xwT3V0U3RyaW5nOigy
NSw5NiksMzIsMzI7bHBPcmRlcjooMjgsMTk3NCk9KigyNSwxNTApLDY0LDMyO2xwRHg6KDI4
LDE5NzUpPSooMjUsNjIpLDk2LDMyO2xwQ2FyZXRQb3M6KDI4LDE5NzUpLDEyOCwzMjtscENs
YXNzOigyNSw5NiksMTYwLDMyO2xwR2x5cGhzOigyOCwxOTc0KSwxOTIsMzI7bkdseXBoczoo
MjUsMTUwKSwyMjQsMzI7bk1heEZpdDooMjUsMTUwKSwyNTYsMzI7X19hczo6KDI4LDE5NzYp
PSMjKDI4LDE5NzcpPSYoMjgsMTk3Myk7OlJDMTR0YWdHQ1BfUkVTVUxUUzsyQS47dGFnR0NQ
X1JFU1VMVFM6OigyOCwxOTc4KT0jIygyOCwxOTc5KT0qKDI4LDE5NzMpOzpSQzE0dGFnR0NQ
X1JFU1VMVFM7MkEuKDI4LDE5ODApPSMjKDI4LDE5NzkpOzo7MkEuOzsAR0NQX1JFU1VMVFM6
dCgyOCwxOTgxKT0oMjgsMTk3MykATFBHQ1BfUkVTVUxUUzp0KDI4LDE5ODIpPSgyOCwxOTc5
KQBfR0VORVJJQ19NQVBQSU5HOlR0KDI4LDE5ODMpPXMxNkdlbmVyaWNSZWFkOigyOCwzMiks
MCwzMjtHZW5lcmljV3JpdGU6KDI4LDMyKSwzMiwzMjtHZW5lcmljRXhlY3V0ZTooMjgsMzIp
LDY0LDMyO0dlbmVyaWNBbGw6KDI4LDMyKSw5NiwzMjtfX2FzOjooMjgsMTk4NCk9IyMoMjgs
MTk4NSk9JigyOCwxOTgzKTs6UkMxNl9HRU5FUklDX01BUFBJTkc7MkEuO19HRU5FUklDX01B
UFBJTkc6OigyOCwxOTg2KT0jIygyOCwxOTg3KT0qKDI4LDE5ODMpOzpSQzE2X0dFTkVSSUNf
TUFQUElORzsyQS4oMjgsMTk4OCk9IyMoMjgsMTk4Nyk7OjsyQS47OwBHRU5FUklDX01BUFBJ
Tkc6dCgyOCwxOTg5KT0oMjgsMTk4MykAUEdFTkVSSUNfTUFQUElORzp0KDI4LDE5OTApPSgy
OCwxOTg3KQBfR0xZUEhNRVRSSUNTOlR0KDI4LDE5OTEpPXMyMGdtQmxhY2tCb3hYOigyNSwx
NTApLDAsMzI7Z21CbGFja0JveFk6KDI1LDE1MCksMzIsMzI7Z21wdEdseXBoT3JpZ2luOigy
OCwzMDkpLDY0LDY0O2dtQ2VsbEluY1g6KDAsOCksMTI4LDE2O2dtQ2VsbEluY1k6KDAsOCks
MTQ0LDE2O19fYXM6OigyOCwxOTkyKT0jIygyOCwxOTkzKT0mKDI4LDE5OTEpOzpSQzEzX0dM
WVBITUVUUklDUzsyQS47X0dMWVBITUVUUklDUzo6KDI4LDE5OTQpPSMjKDI4LDE5OTUpPSoo
MjgsMTk5MSk7OlJDMTNfR0xZUEhNRVRSSUNTOzJBLigyOCwxOTk2KT0jIygyOCwxOTk1KTs6
OzJBLjs7AEdMWVBITUVUUklDUzp0KDI4LDE5OTcpPSgyOCwxOTkxKQBMUEdMWVBITUVUUklD
Uzp0KDI4LDE5OTgpPSgyOCwxOTk1KQB0YWdIQU5ETEVUQUJMRTpUdCgyOCwxOTk5KT1zNG9i
amVjdEhhbmRsZTooMjgsMjAwMCk9YXIoMCwxKTswOzA7KDAsMjMpLDAsMzI7X19hczo6KDI4
LDIwMDEpPSMjKDI4LDIwMDIpPSYoMjgsMTk5OSk7OlJDMTR0YWdIQU5ETEVUQUJMRTsyQS47
dGFnSEFORExFVEFCTEU6OigyOCwyMDAzKT0jIygyOCwyMDA0KT0qKDI4LDE5OTkpOzpSQzE0
dGFnSEFORExFVEFCTEU7MkEuKDI4LDIwMDUpPSMjKDI4LDIwMDQpOzo7MkEuOzsASEFORExF
VEFCTEU6dCgyOCwyMDA2KT0oMjgsMTk5OSkATFBIQU5ETEVUQUJMRTp0KDI4LDIwMDcpPSgy
OCwyMDA0KQBfSERfSElUVEVTVElORk86VHQoMjgsMjAwOCk9czE2cHQ6KDI4LDMwOSksMCw2
NDtmbGFnczooMjUsMTUwKSw2NCwzMjtpSXRlbTooMCwxKSw5NiwzMjtfX2FzOjooMjgsMjAw
OSk9IyMoMjgsMjAxMCk9JigyOCwyMDA4KTs6UkMxNV9IRF9ISVRURVNUSU5GTzsyQS47X0hE
X0hJVFRFU1RJTkZPOjooMjgsMjAxMSk9IyMoMjgsMjAxMik9KigyOCwyMDA4KTs6UkMxNV9I
RF9ISVRURVNUSU5GTzsyQS4oMjgsMjAxMyk9IyMoMjgsMjAxMik7OjsyQS47OwBIRF9ISVRU
RVNUSU5GTzp0KDI4LDIwMTQpPSgyOCwyMDA4KQBfSERfSVRFTTpUdCgyOCwyMDE1KT1zMjht
YXNrOigyNSwxNTApLDAsMzI7Y3h5OigwLDEpLDMyLDMyO3BzelRleHQ6KDI1LDk2KSw2NCwz
MjtoYm06KDI1LDIxKSw5NiwzMjtjY2hUZXh0TWF4OigwLDEpLDEyOCwzMjtmbXQ6KDAsMSks
MTYwLDMyO2xQYXJhbTooMjUsNzApLDE5MiwzMjtfX2FzOjooMjgsMjAxNik9IyMoMjgsMjAx
Nyk9JigyOCwyMDE1KTs6UkM4X0hEX0lURU07MkEuO19IRF9JVEVNOjooMjgsMjAxOCk9IyMo
MjgsMjAxOSk9KigyOCwyMDE1KTs6UkM4X0hEX0lURU07MkEuKDI4LDIwMjApPSMjKDI4LDIw
MTkpOzo7MkEuOzsASERfSVRFTTp0KDI4LDIwMjEpPSgyOCwyMDE1KQBfV0lORE9XUE9TOlR0
KDI4LDIwMjIpPXMyOGh3bmQ6KDI1LDYxKSwwLDMyO2h3bmRJbnNlcnRBZnRlcjooMjUsNjEp
LDMyLDMyO3g6KDAsMSksNjQsMzI7eTooMCwxKSw5NiwzMjtjeDooMCwxKSwxMjgsMzI7Y3k6
KDAsMSksMTYwLDMyO2ZsYWdzOigyNSwxNTApLDE5MiwzMjtfX2FzOjooMjgsMjAyMyk9IyMo
MjgsMjAyNCk9JigyOCwyMDIyKTs6UkMxMF9XSU5ET1dQT1M7MkEuO19XSU5ET1dQT1M6Oigy
OCwyMDI1KT0jIygyOCwyMDI2KT0qKDI4LDIwMjIpOzpSQzEwX1dJTkRPV1BPUzsyQS4oMjgs
MjAyNyk9IyMoMjgsMjAyNik7OjsyQS47OwBXSU5ET1dQT1M6dCgyOCwyMDI4KT0oMjgsMjAy
MikAUFdJTkRPV1BPUzp0KDI4LDIwMjkpPSgyOCwyMDI2KQBMUFdJTkRPV1BPUzp0KDI4LDIw
MzApPSgyOCwyMDI2KQBfSERfTEFZT1VUOlR0KDI4LDIwMzEpPXM4cHJjOigyOCwyMDMyKT0q
KDI4LDExMyksMCwzMjtwd3BvczooMjgsMjAzMyk9KigyOCwyMDI4KSwzMiwzMjtfX2FzOjoo
MjgsMjAzNCk9IyMoMjgsMjAzNSk9JigyOCwyMDMxKTs6UkMxMF9IRF9MQVlPVVQ7MkEuO19I
RF9MQVlPVVQ6OigyOCwyMDM2KT0jIygyOCwyMDM3KT0qKDI4LDIwMzEpOzpSQzEwX0hEX0xB
WU9VVDsyQS4oMjgsMjAzOCk9IyMoMjgsMjAzNyk7OjsyQS47OwBIRF9MQVlPVVQ6dCgyOCwy
MDM5KT0oMjgsMjAzMSkAX0hEX05PVElGWTpUdCgyOCwyMDQwKT1zMjRoZHI6KDI4LDE3NTEp
LDAsOTY7aUl0ZW06KDAsMSksOTYsMzI7aUJ1dHRvbjooMCwxKSwxMjgsMzI7cGl0ZW06KDI4
LDIwNDEpPSooMjgsMjAyMSksMTYwLDMyO19fYXM6OigyOCwyMDQyKT0jIygyOCwyMDQzKT0m
KDI4LDIwNDApOzpSQzEwX0hEX05PVElGWTsyQS47X0hEX05PVElGWTo6KDI4LDIwNDQpPSMj
KDI4LDIwNDUpPSooMjgsMjA0MCk7OlJDMTBfSERfTk9USUZZOzJBLigyOCwyMDQ2KT0jIygy
OCwyMDQ1KTs6OzJBLjs7AEhEX05PVElGWTp0KDI4LDIwNDcpPSgyOCwyMDQwKQB0YWdIRUxQ
SU5GTzpUdCgyOCwyMDQ4KT1zMjhjYlNpemU6KDI1LDE1MCksMCwzMjtpQ29udGV4dFR5cGU6
KDAsMSksMzIsMzI7aUN0cmxJZDooMCwxKSw2NCwzMjtoSXRlbUhhbmRsZTooMjUsMTkpLDk2
LDMyO2R3Q29udGV4dElkOigyNSwxNCksMTI4LDMyO01vdXNlUG9zOigyOCwzMDkpLDE2MCw2
NDtfX2FzOjooMjgsMjA0OSk9IyMoMjgsMjA1MCk9JigyOCwyMDQ4KTs6UkMxMXRhZ0hFTFBJ
TkZPOzJBLjt0YWdIRUxQSU5GTzo6KDI4LDIwNTEpPSMjKDI4LDIwNTIpPSooMjgsMjA0OCk7
OlJDMTF0YWdIRUxQSU5GTzsyQS4oMjgsMjA1Myk9IyMoMjgsMjA1Mik7OjsyQS47OwBIRUxQ
SU5GTzp0KDI4LDIwNTQpPSgyOCwyMDQ4KQBMUEhFTFBJTkZPOnQoMjgsMjA1NSk9KDI4LDIw
NTIpAEhFTFBXSU5JTkZPOnQoMjgsMjA1Nik9czI4d1N0cnVjdFNpemU6KDAsMSksMCwzMjt4
OigwLDEpLDMyLDMyO3k6KDAsMSksNjQsMzI7ZHg6KDAsMSksOTYsMzI7ZHk6KDAsMSksMTI4
LDMyO3dNYXg6KDAsMSksMTYwLDMyO3JnY2hNZW1iZXI6KDI4LDIwNTcpPWFyKDAsMSk7MDsx
OygwLDIpLDE5MiwxNjtfX2FzOjooMjgsMjA1OCk9IygyOCwyMDU2KSwoMjgsMjA1OSk9Jigy
OCwyMDU2KSwoMjgsMjA2MCk9KigyOCwyMDU2KSwoMjgsMjA2MSk9JigyOCwyMDYyKT1zMjh3
U3RydWN0U2l6ZTooMCwxKSwwLDMyO3g6KDAsMSksMzIsMzI7eTooMCwxKSw2NCwzMjtkeDoo
MCwxKSw5NiwzMjtkeTooMCwxKSwxMjgsMzI7d01heDooMCwxKSwxNjAsMzI7cmdjaE1lbWJl
cjooMjgsMjA1NyksMTkyLDE2O19fYXM6OigyOCwyMDU4KTpfX2FzX180JF8xOVJDNCRfMTk7
MkEuOyRfMTk6OigyOCwyMDYzKT0jKDI4LDIwNTYpLCgyOCwyMDYwKSwoMjgsMjA2MCksKDI4
LDIwNjEpLCgwLDIwKTs6X180JF8xOVJDNCRfMTk7MkEuKDI4LDIwNjQpPSMoMjgsMjA1Niks
KDI4LDIwNjApLCgyOCwyMDYwKSwoMCwyMCk7Ol9fNCRfMTk7MkEuOzssKDAsMjApOzpfX2Fz
X180JF8xOVJDNCRfMTk7MkEuOyRfMTk6OigyOCwyMDYzKTpfXzQkXzE5UkM0JF8xOTsyQS4o
MjgsMjA2NCk6X180JF8xOTsyQS47OwB0YWdISUdIQ09OVFJBU1Q6VHQoMjgsMjA2NSk9czEy
Y2JTaXplOigyNSwxNTApLDAsMzI7ZHdGbGFnczooMjUsMTQpLDMyLDMyO2xwc3pEZWZhdWx0
U2NoZW1lOigyNSw5NiksNjQsMzI7X19hczo6KDI4LDIwNjYpPSMjKDI4LDIwNjcpPSYoMjgs
MjA2NSk7OlJDMTV0YWdISUdIQ09OVFJBU1Q7MkEuO3RhZ0hJR0hDT05UUkFTVDo6KDI4LDIw
NjgpPSMjKDI4LDIwNjkpPSooMjgsMjA2NSk7OlJDMTV0YWdISUdIQ09OVFJBU1Q7MkEuKDI4
LDIwNzApPSMjKDI4LDIwNjkpOzo7MkEuOzsASElHSENPTlRSQVNUOnQoMjgsMjA3MSk9KDI4
LDIwNjUpAExQSElHSENPTlRSQVNUOnQoMjgsMjA3Mik9KDI4LDIwNjkpAHRhZ0hTWlBBSVI6
VHQoMjgsMjA3Myk9czhoc3pTdmM6KDI1LDU5KSwwLDMyO2hzelRvcGljOigyNSw1OSksMzIs
MzI7X19hczo6KDI4LDIwNzQpPSMjKDI4LDIwNzUpPSYoMjgsMjA3Myk7OlJDMTB0YWdIU1pQ
QUlSOzJBLjt0YWdIU1pQQUlSOjooMjgsMjA3Nik9IyMoMjgsMjA3Nyk9KigyOCwyMDczKTs6
UkMxMHRhZ0hTWlBBSVI7MkEuKDI4LDIwNzgpPSMjKDI4LDIwNzcpOzo7MkEuOzsASFNaUEFJ
Ujp0KDI4LDIwNzkpPSgyOCwyMDczKQBfSUNPTklORk86VHQoMjgsMjA4MCk9czIwZkljb246
KDI1LDIpLDAsMzI7eEhvdHNwb3Q6KDI1LDE0KSwzMiwzMjt5SG90c3BvdDooMjUsMTQpLDY0
LDMyO2hibU1hc2s6KDI1LDIxKSw5NiwzMjtoYm1Db2xvcjooMjUsMjEpLDEyOCwzMjtfX2Fz
OjooMjgsMjA4MSk9IyMoMjgsMjA4Mik9JigyOCwyMDgwKTs6UkM5X0lDT05JTkZPOzJBLjtf
SUNPTklORk86OigyOCwyMDgzKT0jIygyOCwyMDg0KT0qKDI4LDIwODApOzpSQzlfSUNPTklO
Rk87MkEuKDI4LDIwODUpPSMjKDI4LDIwODQpOzo7MkEuOzsASUNPTklORk86dCgyOCwyMDg2
KT0oMjgsMjA4MCkAUElDT05JTkZPOnQoMjgsMjA4Nyk9KDI4LDIwODQpAHRhZ0lDT05NRVRS
SUNTOlR0KDI4LDIwODgpPXM3NmNiU2l6ZTooMjUsMTUwKSwwLDMyO2lIb3J6U3BhY2luZzoo
MCwxKSwzMiwzMjtpVmVydFNwYWNpbmc6KDAsMSksNjQsMzI7aVRpdGxlV3JhcDooMCwxKSw5
NiwzMjtsZkZvbnQ6KDI4LDQ1NiksMTI4LDQ4MDtfX2FzOjooMjgsMjA4OSk9IyMoMjgsMjA5
MCk9JigyOCwyMDg4KTs6UkMxNHRhZ0lDT05NRVRSSUNTOzJBLjt0YWdJQ09OTUVUUklDUzo6
KDI4LDIwOTEpPSMjKDI4LDIwOTIpPSooMjgsMjA4OCk7OlJDMTR0YWdJQ09OTUVUUklDUzsy
QS4oMjgsMjA5Myk9IyMoMjgsMjA5Mik7OjsyQS47OwBJQ09OTUVUUklDUzp0KDI4LDIwOTQp
PSgyOCwyMDg4KQBMUElDT05NRVRSSUNTOnQoMjgsMjA5NSk9KDI4LDIwOTIpAF9JTUFHRUlO
Rk86VHQoMjgsMjA5Nik9czMyaGJtSW1hZ2U6KDI1LDIxKSwwLDMyO2hibU1hc2s6KDI1LDIx
KSwzMiwzMjtVbnVzZWQxOigwLDEpLDY0LDMyO1VudXNlZDI6KDAsMSksOTYsMzI7cmNJbWFn
ZTooMjgsMTEzKSwxMjgsMTI4O19fYXM6OigyOCwyMDk3KT0jIygyOCwyMDk4KT0mKDI4LDIw
OTYpOzpSQzEwX0lNQUdFSU5GTzsyQS47X0lNQUdFSU5GTzo6KDI4LDIwOTkpPSMjKDI4LDIx
MDApPSooMjgsMjA5Nik7OlJDMTBfSU1BR0VJTkZPOzJBLigyOCwyMTAxKT0jIygyOCwyMTAw
KTs6OzJBLjs7AElNQUdFSU5GTzp0KDI4LDIxMDIpPSgyOCwyMDk2KQBfS0VZX0VWRU5UX1JF
Q09SRDpUdCgyOCwyMTAzKT1zMTZiS2V5RG93bjooMjUsMiksMCwzMjt3UmVwZWF0Q291bnQ6
KDI1LDE1MyksMzIsMTY7d1ZpcnR1YWxLZXlDb2RlOigyNSwxNTMpLDQ4LDE2O3dWaXJ0dWFs
U2NhbkNvZGU6KDI1LDE1MyksNjQsMTY7dUNoYXI6KDI4LDIxMDQpPXUyVW5pY29kZUNoYXI6
KDI1LDEwKSwwLDE2O0FzY2lpQ2hhcjooMjUsMTEpLDAsODtfX2FzOjooMjgsMjEwNSk9Iygy
OCwyMTA0KSwoMjgsMjEwNik9JigyOCwyMTA0KSwoMjgsMjEwNyk9KigyOCwyMTA0KSwoMjgs
MjEwOCk9JigyOCwyMTA0KSwoMCwyMCk7Ol9fYXNfX1EyMTdfS0VZX0VWRU5UX1JFQ09SRDQk
XzIwUkNRMjE3X0tFWV9FVkVOVF9SRUNPUkQ0JF8yMDsyQS47JF8yMDo6KDI4LDIxMDkpPSMo
MjgsMjEwNCksKDI4LDIxMDcpLCgyOCwyMTA3KSwoMjgsMjEwOCksKDAsMjApOzpfX1EyMTdf
S0VZX0VWRU5UX1JFQ09SRDQkXzIwUkNRMjE3X0tFWV9FVkVOVF9SRUNPUkQ0JF8yMDsyQS4o
MjgsMjExMCk9IygyOCwyMTA0KSwoMjgsMjEwNyksKDI4LDIxMDcpLCgwLDIwKTs6X19RMjE3
X0tFWV9FVkVOVF9SRUNPUkQ0JF8yMDsyQS47Oyw4MCwxNjtkd0NvbnRyb2xLZXlTdGF0ZToo
MjUsMTQpLDk2LDMyO19fYXM6OigyOCwyMTExKT0jIygyOCwyMTEyKT0mKDI4LDIxMDMpOzpS
QzE3X0tFWV9FVkVOVF9SRUNPUkQ7MkEuO19LRVlfRVZFTlRfUkVDT1JEOjooMjgsMjExMyk9
IyMoMjgsMjExNCk9KigyOCwyMTAzKTs6UkMxN19LRVlfRVZFTlRfUkVDT1JEOzJBLigyOCwy
MTE1KT0jIygyOCwyMTE0KTs6OzJBLjs7AEtFWV9FVkVOVF9SRUNPUkQ6dCgyOCwyMTE2KT0o
MjgsMjEwMykAX01PVVNFX0VWRU5UX1JFQ09SRDpUdCgyOCwyMTE3KT1zMTZkd01vdXNlUG9z
aXRpb246KDI4LDU4OSksMCwzMjtkd0J1dHRvblN0YXRlOigyNSwxNCksMzIsMzI7ZHdDb250
cm9sS2V5U3RhdGU6KDI1LDE0KSw2NCwzMjtkd0V2ZW50RmxhZ3M6KDI1LDE0KSw5NiwzMjtf
X2FzOjooMjgsMjExOCk9IyMoMjgsMjExOSk9JigyOCwyMTE3KTs6UkMxOV9NT1VTRV9FVkVO
VF9SRUNPUkQ7MkEuO19NT1VTRV9FVkVOVF9SRUNPUkQ6OigyOCwyMTIwKT0jIygyOCwyMTIx
KT0qKDI4LDIxMTcpOzpSQzE5X01PVVNFX0VWRU5UX1JFQ09SRDsyQS4oMjgsMjEyMik9IyMo
MjgsMjEyMSk7OjsyQS47OwBNT1VTRV9FVkVOVF9SRUNPUkQ6dCgyOCwyMTIzKT0oMjgsMjEx
NykAX1dJTkRPV19CVUZGRVJfU0laRV9SRUNPUkQ6VHQoMjgsMjEyNCk9czRkd1NpemU6KDI4
LDU4OSksMCwzMjtfX2FzOjooMjgsMjEyNSk9IyMoMjgsMjEyNik9JigyOCwyMTI0KTs6UkMy
Nl9XSU5ET1dfQlVGRkVSX1NJWkVfUkVDT1JEOzJBLjtfV0lORE9XX0JVRkZFUl9TSVpFX1JF
Q09SRDo6KDI4LDIxMjcpPSMjKDI4LDIxMjgpPSooMjgsMjEyNCk7OlJDMjZfV0lORE9XX0JV
RkZFUl9TSVpFX1JFQ09SRDsyQS4oMjgsMjEyOSk9IyMoMjgsMjEyOCk7OjsyQS47OwBXSU5E
T1dfQlVGRkVSX1NJWkVfUkVDT1JEOnQoMjgsMjEzMCk9KDI4LDIxMjQpAF9NRU5VX0VWRU5U
X1JFQ09SRDpUdCgyOCwyMTMxKT1zNGR3Q29tbWFuZElkOigyNSwxNTApLDAsMzI7X19hczo6
KDI4LDIxMzIpPSMjKDI4LDIxMzMpPSYoMjgsMjEzMSk7OlJDMThfTUVOVV9FVkVOVF9SRUNP
UkQ7MkEuO19NRU5VX0VWRU5UX1JFQ09SRDo6KDI4LDIxMzQpPSMjKDI4LDIxMzUpPSooMjgs
MjEzMSk7OlJDMThfTUVOVV9FVkVOVF9SRUNPUkQ7MkEuKDI4LDIxMzYpPSMjKDI4LDIxMzUp
Ozo7MkEuOzsATUVOVV9FVkVOVF9SRUNPUkQ6dCgyOCwyMTM3KT0oMjgsMjEzMSkAUE1FTlVf
RVZFTlRfUkVDT1JEOnQoMjgsMjEzOCk9KDI4LDIxMzUpAF9JTlBVVF9SRUNPUkQ6VHQoMjgs
MjEzOSk9czIwRXZlbnRUeXBlOigyNSwxNTMpLDAsMTY7RXZlbnQ6KDI4LDIxNDApPXUxNktl
eUV2ZW50OigyOCwyMTE2KSwwLDEyODtNb3VzZUV2ZW50OigyOCwyMTIzKSwwLDEyODtXaW5k
b3dCdWZmZXJTaXplRXZlbnQ6KDI4LDIxMzApLDAsMzI7TWVudUV2ZW50OigyOCwyMTM3KSww
LDMyO0ZvY3VzRXZlbnQ6KDI4LDE5NTEpLDAsMzI7X19hczo6KDI4LDIxNDEpPSMoMjgsMjE0
MCksKDI4LDIxNDIpPSYoMjgsMjE0MCksKDI4LDIxNDMpPSooMjgsMjE0MCksKDI4LDIxNDQp
PSYoMjgsMjE0MCksKDAsMjApOzpfX2FzX19RMjEzX0lOUFVUX1JFQ09SRDQkXzIxUkNRMjEz
X0lOUFVUX1JFQ09SRDQkXzIxOzJBLjskXzIxOjooMjgsMjE0NSk9IygyOCwyMTQwKSwoMjgs
MjE0MyksKDI4LDIxNDMpLCgyOCwyMTQ0KSwoMCwyMCk7Ol9fUTIxM19JTlBVVF9SRUNPUkQ0
JF8yMVJDUTIxM19JTlBVVF9SRUNPUkQ0JF8yMTsyQS4oMjgsMjE0Nik9IygyOCwyMTQwKSwo
MjgsMjE0MyksKDI4LDIxNDMpLCgwLDIwKTs6X19RMjEzX0lOUFVUX1JFQ09SRDQkXzIxOzJB
Ljs7LDMyLDEyODtfX2FzOjooMjgsMjE0Nyk9IyMoMjgsMjE0OCk9JigyOCwyMTM5KTs6UkMx
M19JTlBVVF9SRUNPUkQ7MkEuO19JTlBVVF9SRUNPUkQ6OigyOCwyMTQ5KT0jIygyOCwyMTUw
KT0qKDI4LDIxMzkpOzpSQzEzX0lOUFVUX1JFQ09SRDsyQS4oMjgsMjE1MSk9IyMoMjgsMjE1
MCk7OjsyQS47OwBJTlBVVF9SRUNPUkQ6dCgyOCwyMTUyKT0oMjgsMjEzOSkAUElOUFVUX1JF
Q09SRDp0KDI4LDIxNTMpPSgyOCwyMTUwKQBfU1lTVEVNVElNRTpUdCgyOCwyMTU0KT1zMTZ3
WWVhcjooMjUsMTUzKSwwLDE2O3dNb250aDooMjUsMTUzKSwxNiwxNjt3RGF5T2ZXZWVrOigy
NSwxNTMpLDMyLDE2O3dEYXk6KDI1LDE1MyksNDgsMTY7d0hvdXI6KDI1LDE1MyksNjQsMTY7
d01pbnV0ZTooMjUsMTUzKSw4MCwxNjt3U2Vjb25kOigyNSwxNTMpLDk2LDE2O3dNaWxsaXNl
Y29uZHM6KDI1LDE1MyksMTEyLDE2O19fYXM6OigyOCwyMTU1KT0jIygyOCwyMTU2KT0mKDI4
LDIxNTQpOzpSQzExX1NZU1RFTVRJTUU7MkEuO19TWVNURU1USU1FOjooMjgsMjE1Nyk9IyMo
MjgsMjE1OCk9KigyOCwyMTU0KTs6UkMxMV9TWVNURU1USU1FOzJBLigyOCwyMTU5KT0jIygy
OCwyMTU4KTs6OzJBLjs7AFNZU1RFTVRJTUU6dCgyOCwyMTYwKT0oMjgsMjE1NCkATFBTWVNU
RU1USU1FOnQoMjgsMjE2MSk9KDI4LDIxNTgpAF9KT0JfSU5GT18xOlR0KDI4LDIxNjIpPXM2
NEpvYklkOigyNSwxNCksMCwzMjtwUHJpbnRlck5hbWU6KDI1LDk2KSwzMiwzMjtwTWFjaGlu
ZU5hbWU6KDI1LDk2KSw2NCwzMjtwVXNlck5hbWU6KDI1LDk2KSw5NiwzMjtwRG9jdW1lbnQ6
KDI1LDk2KSwxMjgsMzI7cERhdGF0eXBlOigyNSw5NiksMTYwLDMyO3BTdGF0dXM6KDI1LDk2
KSwxOTIsMzI7U3RhdHVzOigyNSwxNCksMjI0LDMyO1ByaW9yaXR5OigyNSwxNCksMjU2LDMy
O1Bvc2l0aW9uOigyNSwxNCksMjg4LDMyO1RvdGFsUGFnZXM6KDI1LDE0KSwzMjAsMzI7UGFn
ZXNQcmludGVkOigyNSwxNCksMzUyLDMyO1N1Ym1pdHRlZDooMjgsMjE2MCksMzg0LDEyODtf
X2FzOjooMjgsMjE2Myk9IyMoMjgsMjE2NCk9JigyOCwyMTYyKTs6UkMxMV9KT0JfSU5GT18x
OzJBLjtfSk9CX0lORk9fMTo6KDI4LDIxNjUpPSMjKDI4LDIxNjYpPSooMjgsMjE2Mik7OlJD
MTFfSk9CX0lORk9fMTsyQS4oMjgsMjE2Nyk9IyMoMjgsMjE2Nik7OjsyQS47OwBKT0JfSU5G
T18xOnQoMjgsMjE2OCk9KDI4LDIxNjIpAF9TSURfSURFTlRJRklFUl9BVVRIT1JJVFk6VHQo
MjgsMjE2OSk9czZWYWx1ZTooMjgsODUpLDAsNDg7X19hczo6KDI4LDIxNzApPSMjKDI4LDIx
NzEpPSYoMjgsMjE2OSk7OlJDMjVfU0lEX0lERU5USUZJRVJfQVVUSE9SSVRZOzJBLjtfU0lE
X0lERU5USUZJRVJfQVVUSE9SSVRZOjooMjgsMjE3Mik9IyMoMjgsMjE3Myk9KigyOCwyMTY5
KTs6UkMyNV9TSURfSURFTlRJRklFUl9BVVRIT1JJVFk7MkEuKDI4LDIxNzQpPSMjKDI4LDIx
NzMpOzo7MkEuOzsAU0lEX0lERU5USUZJRVJfQVVUSE9SSVRZOnQoMjgsMjE3NSk9KDI4LDIx
NjkpAFBTSURfSURFTlRJRklFUl9BVVRIT1JJVFk6dCgyOCwyMTc2KT0oMjgsMjE3MykATFBT
SURfSURFTlRJRklFUl9BVVRIT1JJVFk6dCgyOCwyMTc3KT0oMjgsMjE3MykAX1NJRDpUdCgy
OCwyMTc4KT1zMTJSZXZpc2lvbjooMjUsNSksMCw4O1N1YkF1dGhvcml0eUNvdW50OigyNSw1
KSw4LDg7SWRlbnRpZmllckF1dGhvcml0eTooMjgsMjE3NSksMTYsNDg7U3ViQXV0aG9yaXR5
OigyOCwzNDIpLDY0LDMyO19fYXM6OigyOCwyMTc5KT0jIygyOCwyMTgwKT0mKDI4LDIxNzgp
OzpSQzRfU0lEOzJBLjtfU0lEOjooMjgsMjE4MSk9IyMoMjgsMjE4Mik9KigyOCwyMTc4KTs6
UkM0X1NJRDsyQS4oMjgsMjE4Myk9IyMoMjgsMjE4Mik7OjsyQS47OwBTSUQ6dCgyOCwyMTg0
KT0oMjgsMjE3OCkAUFNJRDp0KDI4LDIxODUpPSgyOCwyMTgyKQBTRUNVUklUWV9ERVNDUklQ
VE9SX0NPTlRST0w6dCgyOCwyMTg2KT0oMjUsMTUzKQBQU0VDVVJJVFlfREVTQ1JJUFRPUl9D
T05UUk9MOnQoMjgsMjE4Nyk9KDI4LDIxODgpPSooMjUsMTUzKQBfU0VDVVJJVFlfREVTQ1JJ
UFRPUjpUdCgyOCwyMTg5KT1zMjBSZXZpc2lvbjooMjUsNSksMCw4O1NiejE6KDI1LDUpLDgs
ODtDb250cm9sOigyOCwyMTg2KSwxNiwxNjtPd25lcjooMjgsMjE4NSksMzIsMzI7R3JvdXA6
KDI4LDIxODUpLDY0LDMyO1NhY2w6KDI4LDYyKSw5NiwzMjtEYWNsOigyOCw2MiksMTI4LDMy
O19fYXM6OigyOCwyMTkwKT0jIygyOCwyMTkxKT0mKDI4LDIxODkpOzpSQzIwX1NFQ1VSSVRZ
X0RFU0NSSVBUT1I7MkEuO19TRUNVUklUWV9ERVNDUklQVE9SOjooMjgsMjE5Mik9IyMoMjgs
MjE5Myk9KigyOCwyMTg5KTs6UkMyMF9TRUNVUklUWV9ERVNDUklQVE9SOzJBLigyOCwyMTk0
KT0jIygyOCwyMTkzKTs6OzJBLjs7AFNFQ1VSSVRZX0RFU0NSSVBUT1I6dCgyOCwyMTk1KT0o
MjgsMjE4OSkAUFNFQ1VSSVRZX0RFU0NSSVBUT1I6dCgyOCwyMTk2KT0oMjgsMjE5MykAX0pP
Ql9JTkZPXzI6VHQoMjgsMjE5Nyk9czEwNEpvYklkOigyNSwxNCksMCwzMjtwUHJpbnRlck5h
bWU6KDI1LDk2KSwzMiwzMjtwTWFjaGluZU5hbWU6KDI1LDk2KSw2NCwzMjtwVXNlck5hbWU6
KDI1LDk2KSw5NiwzMjtwRG9jdW1lbnQ6KDI1LDk2KSwxMjgsMzI7cE5vdGlmeU5hbWU6KDI1
LDk2KSwxNjAsMzI7cERhdGF0eXBlOigyNSw5NiksMTkyLDMyO3BQcmludFByb2Nlc3Nvcjoo
MjUsOTYpLDIyNCwzMjtwUGFyYW1ldGVyczooMjUsOTYpLDI1NiwzMjtwRHJpdmVyTmFtZToo
MjUsOTYpLDI4OCwzMjtwRGV2TW9kZTooMjgsOTQzKSwzMjAsMzI7cFN0YXR1czooMjUsOTYp
LDM1MiwzMjtwU2VjdXJpdHlEZXNjcmlwdG9yOigyOCwyMTk2KSwzODQsMzI7U3RhdHVzOigy
NSwxNCksNDE2LDMyO1ByaW9yaXR5OigyNSwxNCksNDQ4LDMyO1Bvc2l0aW9uOigyNSwxNCks
NDgwLDMyO1N0YXJ0VGltZTooMjUsMTQpLDUxMiwzMjtVbnRpbFRpbWU6KDI1LDE0KSw1NDQs
MzI7VG90YWxQYWdlczooMjUsMTQpLDU3NiwzMjtTaXplOigyNSwxNCksNjA4LDMyO1N1Ym1p
dHRlZDooMjgsMjE2MCksNjQwLDEyODtUaW1lOigyNSwxNCksNzY4LDMyO1BhZ2VzUHJpbnRl
ZDooMjUsMTQpLDgwMCwzMjtfX2FzOjooMjgsMjE5OCk9IyMoMjgsMjE5OSk9JigyOCwyMTk3
KTs6UkMxMV9KT0JfSU5GT18yOzJBLjtfSk9CX0lORk9fMjo6KDI4LDIyMDApPSMjKDI4LDIy
MDEpPSooMjgsMjE5Nyk7OlJDMTFfSk9CX0lORk9fMjsyQS4oMjgsMjIwMik9IyMoMjgsMjIw
MSk7OjsyQS47OwBKT0JfSU5GT18yOnQoMjgsMjIwMyk9KDI4LDIxOTcpAHRhZ0tFUk5JTkdQ
QUlSOlR0KDI4LDIyMDQpPXM4d0ZpcnN0OigyNSwxNTMpLDAsMTY7d1NlY29uZDooMjUsMTUz
KSwxNiwxNjtpS2VybkFtb3VudDooMCwxKSwzMiwzMjtfX2FzOjooMjgsMjIwNSk9IyMoMjgs
MjIwNik9JigyOCwyMjA0KTs6UkMxNHRhZ0tFUk5JTkdQQUlSOzJBLjt0YWdLRVJOSU5HUEFJ
Ujo6KDI4LDIyMDcpPSMjKDI4LDIyMDgpPSooMjgsMjIwNCk7OlJDMTR0YWdLRVJOSU5HUEFJ
UjsyQS4oMjgsMjIwOSk9IyMoMjgsMjIwOCk7OjsyQS47OwBLRVJOSU5HUEFJUjp0KDI4LDIy
MTApPSgyOCwyMjA0KQBMUEtFUk5JTkdQQUlSOnQoMjgsMjIxMSk9KDI4LDIyMDgpAF9MQU5B
X0VOVU06VHQoMjgsMjIxMik9czI1NWxlbmd0aDooMjUsMTQ5KSwwLDg7bGFuYTooMjgsMjIx
Myk9YXIoMCwxKTswOzI1MzsoMCwxMSksOCwyMDMyO19fYXM6OigyOCwyMjE0KT0jIygyOCwy
MjE1KT0mKDI4LDIyMTIpOzpSQzEwX0xBTkFfRU5VTTsyQS47X0xBTkFfRU5VTTo6KDI4LDIy
MTYpPSMjKDI4LDIyMTcpPSooMjgsMjIxMik7OlJDMTBfTEFOQV9FTlVNOzJBLigyOCwyMjE4
KT0jIygyOCwyMjE3KTs6OzJBLjs7AExBTkFfRU5VTTp0KDI4LDIyMTkpPSgyOCwyMjEyKQBf
TERUX0VOVFJZOlR0KDI4LDIyMjApPXM4TGltaXRMb3c6KDI1LDE1MyksMCwxNjtCYXNlTG93
OigyNSwxNTMpLDE2LDE2O0hpZ2hXb3JkOigyOCwyMjIxKT11NEJ5dGVzOigyOCwyMjIyKT1z
NEJhc2VNaWQ6KDI1LDUpLDAsODtGbGFnczE6KDI1LDUpLDgsODtGbGFnczI6KDI1LDUpLDE2
LDg7QmFzZUhpOigyNSw1KSwyNCw4O19fYXM6OigyOCwyMjIzKT0jKDI4LDIyMjIpLCgyOCwy
MjI0KT0mKDI4LDIyMjIpLCgyOCwyMjI1KT0qKDI4LDIyMjIpLCgyOCwyMjI2KT0mKDI4LDIy
MjIpLCgwLDIwKTs6X19hc19fUTMxMF9MRFRfRU5UUlk0JF8yMjQkXzIzUkNRMzEwX0xEVF9F
TlRSWTQkXzIyNCRfMjM7MkEuOyRfMjM6OigyOCwyMjI3KT0jKDI4LDIyMjIpLCgyOCwyMjI1
KSwoMjgsMjIyNSksKDI4LDIyMjYpLCgwLDIwKTs6X19RMzEwX0xEVF9FTlRSWTQkXzIyNCRf
MjNSQ1EzMTBfTERUX0VOVFJZNCRfMjI0JF8yMzsyQS4oMjgsMjIyOCk9IygyOCwyMjIyKSwo
MjgsMjIyNSksKDI4LDIyMjUpLCgwLDIwKTs6X19RMzEwX0xEVF9FTlRSWTQkXzIyNCRfMjM7
MkEuOzssMCwzMjtCaXRzOigyOCwyMjI5KT1zNEJhc2VNaWQ6KDI1LDE0KSwwLDg7VHlwZToo
MjUsMTQpLDgsNTtEcGw6KDI1LDE0KSwxMywyO1ByZXM6KDI1LDE0KSwxNSwxO0xpbWl0SGk6
KDI1LDE0KSwxNiw0O1N5czooMjUsMTQpLDIwLDE7UmVzZXJ2ZWRfMDooMjUsMTQpLDIxLDE7
RGVmYXVsdF9CaWc6KDI1LDE0KSwyMiwxO0dyYW51bGFyaXR5OigyNSwxNCksMjMsMTtCYXNl
SGk6KDI1LDE0KSwyNCw4O19fYXM6OigyOCwyMjMwKT0jKDI4LDIyMjkpLCgyOCwyMjMxKT0m
KDI4LDIyMjkpLCgyOCwyMjMyKT0qKDI4LDIyMjkpLCgyOCwyMjMzKT0mKDI4LDIyMjkpLCgw
LDIwKTs6X19hc19fUTMxMF9MRFRfRU5UUlk0JF8yMjQkXzI0UkNRMzEwX0xEVF9FTlRSWTQk
XzIyNCRfMjQ7MkEuOyRfMjQ6OigyOCwyMjM0KT0jKDI4LDIyMjkpLCgyOCwyMjMyKSwoMjgs
MjIzMiksKDI4LDIyMzMpLCgwLDIwKTs6X19RMzEwX0xEVF9FTlRSWTQkXzIyNCRfMjRSQ1Ez
MTBfTERUX0VOVFJZNCRfMjI0JF8yNDsyQS4oMjgsMjIzNSk9IygyOCwyMjI5KSwoMjgsMjIz
MiksKDI4LDIyMzIpLCgwLDIwKTs6X19RMzEwX0xEVF9FTlRSWTQkXzIyNCRfMjQ7MkEuOzss
MCwzMjtfX2FzOjooMjgsMjIzNik9IygyOCwyMjIxKSwoMjgsMjIzNyk9JigyOCwyMjIxKSwo
MjgsMjIzOCk9KigyOCwyMjIxKSwoMjgsMjIzOSk9JigyOCwyMjIxKSwoMCwyMCk7Ol9fYXNf
X1EyMTBfTERUX0VOVFJZNCRfMjJSQ1EyMTBfTERUX0VOVFJZNCRfMjI7MkEuOyRfMjI6Oigy
OCwyMjQwKT0jKDI4LDIyMjEpLCgyOCwyMjM4KSwoMjgsMjIzOCksKDI4LDIyMzkpLCgwLDIw
KTs6X19RMjEwX0xEVF9FTlRSWTQkXzIyUkNRMjEwX0xEVF9FTlRSWTQkXzIyOzJBLigyOCwy
MjQxKT0jKDI4LDIyMjEpLCgyOCwyMjM4KSwoMjgsMjIzOCksKDAsMjApOzpfX1EyMTBfTERU
X0VOVFJZNCRfMjI7MkEuOzssMzIsMzI7X19hczo6KDI4LDIyNDIpPSMjKDI4LDIyNDMpPSYo
MjgsMjIyMCk7OlJDMTBfTERUX0VOVFJZOzJBLjtfTERUX0VOVFJZOjooMjgsMjI0NCk9IyMo
MjgsMjI0NSk9KigyOCwyMjIwKTs6UkMxMF9MRFRfRU5UUlk7MkEuKDI4LDIyNDYpPSMjKDI4
LDIyNDUpOzo7MkEuOzsATERUX0VOVFJZOnQoMjgsMjI0Nyk9KDI4LDIyMjApAFBMRFRfRU5U
Ulk6dCgyOCwyMjQ4KT0oMjgsMjI0NSkATFBMRFRfRU5UUlk6dCgyOCwyMjQ5KT0oMjgsMjI0
NSkAdGFnTE9DQUxFU0lHTkFUVVJFOlR0KDI4LDIyNTApPXMzMmxzVXNiOigyOCw0MTApLDAs
MTI4O2xzQ3NiRGVmYXVsdDooMjgsNDExKSwxMjgsNjQ7bHNDc2JTdXBwb3J0ZWQ6KDI4LDQx
MSksMTkyLDY0O19fYXM6OigyOCwyMjUxKT0jIygyOCwyMjUyKT0mKDI4LDIyNTApOzpSQzE4
dGFnTE9DQUxFU0lHTkFUVVJFOzJBLjt0YWdMT0NBTEVTSUdOQVRVUkU6OigyOCwyMjUzKT0j
IygyOCwyMjU0KT0qKDI4LDIyNTApOzpSQzE4dGFnTE9DQUxFU0lHTkFUVVJFOzJBLigyOCwy
MjU1KT0jIygyOCwyMjU0KTs6OzJBLjs7AExPQ0FMRVNJR05BVFVSRTp0KDI4LDIyNTYpPSgy
OCwyMjUwKQBfTE9DQUxHUk9VUF9NRU1CRVJTX0lORk9fMDpUdCgyOCwyMjU3KT1zNGxncm1p
MF9zaWQ6KDI4LDIxODUpLDAsMzI7X19hczo6KDI4LDIyNTgpPSMjKDI4LDIyNTkpPSYoMjgs
MjI1Nyk7OlJDMjZfTE9DQUxHUk9VUF9NRU1CRVJTX0lORk9fMDsyQS47X0xPQ0FMR1JPVVBf
TUVNQkVSU19JTkZPXzA6OigyOCwyMjYwKT0jIygyOCwyMjYxKT0qKDI4LDIyNTcpOzpSQzI2
X0xPQ0FMR1JPVVBfTUVNQkVSU19JTkZPXzA7MkEuKDI4LDIyNjIpPSMjKDI4LDIyNjEpOzo7
MkEuOzsATE9DQUxHUk9VUF9NRU1CRVJTX0lORk9fMDp0KDI4LDIyNjMpPSgyOCwyMjU3KQBf
TE9DQUxHUk9VUF9NRU1CRVJTX0lORk9fMzpUdCgyOCwyMjY0KT1zNGxncm1pM19kb21haW5h
bmRuYW1lOigyNSwxMDQpLDAsMzI7X19hczo6KDI4LDIyNjUpPSMjKDI4LDIyNjYpPSYoMjgs
MjI2NCk7OlJDMjZfTE9DQUxHUk9VUF9NRU1CRVJTX0lORk9fMzsyQS47X0xPQ0FMR1JPVVBf
TUVNQkVSU19JTkZPXzM6OigyOCwyMjY3KT0jIygyOCwyMjY4KT0qKDI4LDIyNjQpOzpSQzI2
X0xPQ0FMR1JPVVBfTUVNQkVSU19JTkZPXzM7MkEuKDI4LDIyNjkpPSMjKDI4LDIyNjgpOzo7
MkEuOzsATE9DQUxHUk9VUF9NRU1CRVJTX0lORk9fMzp0KDI4LDIyNzApPSgyOCwyMjY0KQBG
WFBUMTZET1QxNjp0KDI4LDIyNzEpPSgwLDMpAExQRlhQVDE2RE9UMTY6dCgyOCwyMjcyKT0o
MjUsOTMpAExVSUQ6dCgyOCwyMjczKT0oMjgsOTY5KQBQTFVJRDp0KDI4LDIyNzQpPSgyOCwy
Mjc1KT0qKDI4LDk2OSkAX0xVSURfQU5EX0FUVFJJQlVURVM6VHQoMjgsMjI3Nik9czEyTHVp
ZDooMjgsMjI3MyksMCw2NDtBdHRyaWJ1dGVzOigyNSwxNCksNjQsMzI7X19hczo6KDI4LDIy
NzcpPSMjKDI4LDIyNzgpPSYoMjgsMjI3Nik7OlJDMjBfTFVJRF9BTkRfQVRUUklCVVRFUzsy
QS47X0xVSURfQU5EX0FUVFJJQlVURVM6OigyOCwyMjc5KT0jIygyOCwyMjgwKT0qKDI4LDIy
NzYpOzpSQzIwX0xVSURfQU5EX0FUVFJJQlVURVM7MkEuKDI4LDIyODEpPSMjKDI4LDIyODAp
Ozo7MkEuOzsATFVJRF9BTkRfQVRUUklCVVRFUzp0KDI4LDIyODIpPSgyOCwyMjc2KQBMVUlE
X0FORF9BVFRSSUJVVEVTX0FSUkFZOnQoMjgsMjI4Myk9KDI4LDIyODQpPWFyKDAsMSk7MDsw
OygyOCwyMjc2KQBQTFVJRF9BTkRfQVRUUklCVVRFU19BUlJBWTp0KDI4LDIyODUpPSgyOCwy
Mjg2KT0qKDI4LDIyODMpAF9MVl9DT0xVTU46VHQoMjgsMjI4Nyk9czI0bWFzazooMjUsMTUw
KSwwLDMyO2ZtdDooMCwxKSwzMiwzMjtjeDooMCwxKSw2NCwzMjtwc3pUZXh0OigyNSw5Niks
OTYsMzI7Y2NoVGV4dE1heDooMCwxKSwxMjgsMzI7aVN1Ykl0ZW06KDAsMSksMTYwLDMyO19f
YXM6OigyOCwyMjg4KT0jIygyOCwyMjg5KT0mKDI4LDIyODcpOzpSQzEwX0xWX0NPTFVNTjsy
QS47X0xWX0NPTFVNTjo6KDI4LDIyOTApPSMjKDI4LDIyOTEpPSooMjgsMjI4Nyk7OlJDMTBf
TFZfQ09MVU1OOzJBLigyOCwyMjkyKT0jIygyOCwyMjkxKTs6OzJBLjs7AExWX0NPTFVNTjp0
KDI4LDIyOTMpPSgyOCwyMjg3KQBfTFZfSVRFTTpUdCgyOCwyMjk0KT1zMzZtYXNrOigyNSwx
NTApLDAsMzI7aUl0ZW06KDAsMSksMzIsMzI7aVN1Ykl0ZW06KDAsMSksNjQsMzI7c3RhdGU6
KDI1LDE1MCksOTYsMzI7c3RhdGVNYXNrOigyNSwxNTApLDEyOCwzMjtwc3pUZXh0OigyNSw5
NiksMTYwLDMyO2NjaFRleHRNYXg6KDAsMSksMTkyLDMyO2lJbWFnZTooMCwxKSwyMjQsMzI7
bFBhcmFtOigyNSw3MCksMjU2LDMyO19fYXM6OigyOCwyMjk1KT0jIygyOCwyMjk2KT0mKDI4
LDIyOTQpOzpSQzhfTFZfSVRFTTsyQS47X0xWX0lURU06OigyOCwyMjk3KT0jIygyOCwyMjk4
KT0qKDI4LDIyOTQpOzpSQzhfTFZfSVRFTTsyQS4oMjgsMjI5OSk9IyMoMjgsMjI5OCk7Ojsy
QS47OwBMVl9JVEVNOnQoMjgsMjMwMCk9KDI4LDIyOTQpAHRhZ0xWX0RJU1BJTkZPOlR0KDI4
LDIzMDEpPXM0OGhkcjooMjgsMTc1MSksMCw5NjtpdGVtOigyOCwyMzAwKSw5NiwyODg7X19h
czo6KDI4LDIzMDIpPSMjKDI4LDIzMDMpPSYoMjgsMjMwMSk7OlJDMTR0YWdMVl9ESVNQSU5G
TzsyQS47dGFnTFZfRElTUElORk86OigyOCwyMzA0KT0jIygyOCwyMzA1KT0qKDI4LDIzMDEp
OzpSQzE0dGFnTFZfRElTUElORk87MkEuKDI4LDIzMDYpPSMjKDI4LDIzMDUpOzo7MkEuOzsA
TFZfRElTUElORk86dCgyOCwyMzA3KT0oMjgsMjMwMSkAX0xWX0ZJTkRJTkZPOlR0KDI4LDIz
MDgpPXMyNGZsYWdzOigyNSwxNTApLDAsMzI7cHN6OigyNSw4MyksMzIsMzI7bFBhcmFtOigy
NSw3MCksNjQsMzI7cHQ6KDI4LDMwOSksOTYsNjQ7dmtEaXJlY3Rpb246KDI1LDE1MCksMTYw
LDMyO19fYXM6OigyOCwyMzA5KT0jIygyOCwyMzEwKT0mKDI4LDIzMDgpOzpSQzEyX0xWX0ZJ
TkRJTkZPOzJBLjtfTFZfRklORElORk86OigyOCwyMzExKT0jIygyOCwyMzEyKT0qKDI4LDIz
MDgpOzpSQzEyX0xWX0ZJTkRJTkZPOzJBLigyOCwyMzEzKT0jIygyOCwyMzEyKTs6OzJBLjs7
AExWX0ZJTkRJTkZPOnQoMjgsMjMxNCk9KDI4LDIzMDgpAF9MVl9ISVRURVNUSU5GTzpUdCgy
OCwyMzE1KT1zMTZwdDooMjgsMzA5KSwwLDY0O2ZsYWdzOigyNSwxNTApLDY0LDMyO2lJdGVt
OigwLDEpLDk2LDMyO19fYXM6OigyOCwyMzE2KT0jIygyOCwyMzE3KT0mKDI4LDIzMTUpOzpS
QzE1X0xWX0hJVFRFU1RJTkZPOzJBLjtfTFZfSElUVEVTVElORk86OigyOCwyMzE4KT0jIygy
OCwyMzE5KT0qKDI4LDIzMTUpOzpSQzE1X0xWX0hJVFRFU1RJTkZPOzJBLigyOCwyMzIwKT0j
IygyOCwyMzE5KTs6OzJBLjs7AExWX0hJVFRFU1RJTkZPOnQoMjgsMjMyMSk9KDI4LDIzMTUp
AHRhZ0xWX0tFWURPV046VHQoMjgsMjMyMik9czIwaGRyOigyOCwxNzUxKSwwLDk2O3dWS2V5
OigyNSwxNTMpLDk2LDE2O2ZsYWdzOigyNSwxNTApLDEyOCwzMjtfX2FzOjooMjgsMjMyMyk9
IyMoMjgsMjMyNCk9JigyOCwyMzIyKTs6UkMxM3RhZ0xWX0tFWURPV047MkEuO3RhZ0xWX0tF
WURPV046OigyOCwyMzI1KT0jIygyOCwyMzI2KT0qKDI4LDIzMjIpOzpSQzEzdGFnTFZfS0VZ
RE9XTjsyQS4oMjgsMjMyNyk9IyMoMjgsMjMyNik7OjsyQS47OwBMVl9LRVlET1dOOnQoMjgs
MjMyOCk9KDI4LDIzMjIpAF9NQVQyOlR0KDI4LDIzMjkpPXMxNmVNMTE6KDI4LDMwMiksMCwz
MjtlTTEyOigyOCwzMDIpLDMyLDMyO2VNMjE6KDI4LDMwMiksNjQsMzI7ZU0yMjooMjgsMzAy
KSw5NiwzMjtfX2FzOjooMjgsMjMzMCk9IyMoMjgsMjMzMSk9JigyOCwyMzI5KTs6UkM1X01B
VDI7MkEuO19NQVQyOjooMjgsMjMzMik9IyMoMjgsMjMzMyk9KigyOCwyMzI5KTs6UkM1X01B
VDI7MkEuKDI4LDIzMzQpPSMjKDI4LDIzMzMpOzo7MkEuOzsATUFUMjp0KDI4LDIzMzUpPSgy
OCwyMzI5KQB0YWdNRElDUkVBVEVTVFJVQ1Q6VHQoMjgsMjMzNik9czM2c3pDbGFzczooMjUs
ODMpLDAsMzI7c3pUaXRsZTooMjUsODMpLDMyLDMyO2hPd25lcjooMjUsMTkpLDY0LDMyO3g6
KDAsMSksOTYsMzI7eTooMCwxKSwxMjgsMzI7Y3g6KDAsMSksMTYwLDMyO2N5OigwLDEpLDE5
MiwzMjtzdHlsZTooMjUsMTQpLDIyNCwzMjtsUGFyYW06KDI1LDcwKSwyNTYsMzI7X19hczo6
KDI4LDIzMzcpPSMjKDI4LDIzMzgpPSYoMjgsMjMzNik7OlJDMTh0YWdNRElDUkVBVEVTVFJV
Q1Q7MkEuO3RhZ01ESUNSRUFURVNUUlVDVDo6KDI4LDIzMzkpPSMjKDI4LDIzNDApPSooMjgs
MjMzNik7OlJDMTh0YWdNRElDUkVBVEVTVFJVQ1Q7MkEuKDI4LDIzNDEpPSMjKDI4LDIzNDAp
Ozo7MkEuOzsATURJQ1JFQVRFU1RSVUNUOnQoMjgsMjM0Mik9KDI4LDIzMzYpAExQTURJQ1JF
QVRFU1RSVUNUOnQoMjgsMjM0Myk9KDI4LDIzNDQpPSooMjgsMjM0MikAdGFnTUVBU1VSRUlU
RU1TVFJVQ1Q6VHQoMjgsMjM0NSk9czI0Q3RsVHlwZTooMjUsMTUwKSwwLDMyO0N0bElEOigy
NSwxNTApLDMyLDMyO2l0ZW1JRDooMjUsMTUwKSw2NCwzMjtpdGVtV2lkdGg6KDI1LDE1MCks
OTYsMzI7aXRlbUhlaWdodDooMjUsMTUwKSwxMjgsMzI7aXRlbURhdGE6KDI1LDE0KSwxNjAs
MzI7X19hczo6KDI4LDIzNDYpPSMjKDI4LDIzNDcpPSYoMjgsMjM0NSk7OlJDMjB0YWdNRUFT
VVJFSVRFTVNUUlVDVDsyQS47dGFnTUVBU1VSRUlURU1TVFJVQ1Q6OigyOCwyMzQ4KT0jIygy
OCwyMzQ5KT0qKDI4LDIzNDUpOzpSQzIwdGFnTUVBU1VSRUlURU1TVFJVQ1Q7MkEuKDI4LDIz
NTApPSMjKDI4LDIzNDkpOzo7MkEuOzsATUVBU1VSRUlURU1TVFJVQ1Q6dCgyOCwyMzUxKT0o
MjgsMjM0NSkATFBNRUFTVVJFSVRFTVNUUlVDVDp0KDI4LDIzNTIpPSgyOCwyMzQ5KQBfTUVN
T1JZX0JBU0lDX0lORk9STUFUSU9OOlR0KDI4LDIzNTMpPXMyOEJhc2VBZGRyZXNzOigyNSwx
MzYpLDAsMzI7QWxsb2NhdGlvbkJhc2U6KDI1LDEzNiksMzIsMzI7QWxsb2NhdGlvblByb3Rl
Y3Q6KDI1LDE0KSw2NCwzMjtSZWdpb25TaXplOigyNSwxNCksOTYsMzI7U3RhdGU6KDI1LDE0
KSwxMjgsMzI7UHJvdGVjdDooMjUsMTQpLDE2MCwzMjtUeXBlOigyNSwxNCksMTkyLDMyO19f
YXM6OigyOCwyMzU0KT0jIygyOCwyMzU1KT0mKDI4LDIzNTMpOzpSQzI1X01FTU9SWV9CQVNJ
Q19JTkZPUk1BVElPTjsyQS47X01FTU9SWV9CQVNJQ19JTkZPUk1BVElPTjo6KDI4LDIzNTYp
PSMjKDI4LDIzNTcpPSooMjgsMjM1Myk7OlJDMjVfTUVNT1JZX0JBU0lDX0lORk9STUFUSU9O
OzJBLigyOCwyMzU4KT0jIygyOCwyMzU3KTs6OzJBLjs7AE1FTU9SWV9CQVNJQ19JTkZPUk1B
VElPTjp0KDI4LDIzNTkpPSgyOCwyMzUzKQBQTUVNT1JZX0JBU0lDX0lORk9STUFUSU9OOnQo
MjgsMjM2MCk9KDI4LDIzNjEpPSooMjgsMjM1OSkAX01FTU9SWVNUQVRVUzpUdCgyOCwyMzYy
KT1zMzJkd0xlbmd0aDooMjUsMTQpLDAsMzI7ZHdNZW1vcnlMb2FkOigyNSwxNCksMzIsMzI7
ZHdUb3RhbFBoeXM6KDI1LDE0KSw2NCwzMjtkd0F2YWlsUGh5czooMjUsMTQpLDk2LDMyO2R3
VG90YWxQYWdlRmlsZTooMjUsMTQpLDEyOCwzMjtkd0F2YWlsUGFnZUZpbGU6KDI1LDE0KSwx
NjAsMzI7ZHdUb3RhbFZpcnR1YWw6KDI1LDE0KSwxOTIsMzI7ZHdBdmFpbFZpcnR1YWw6KDI1
LDE0KSwyMjQsMzI7X19hczo6KDI4LDIzNjMpPSMjKDI4LDIzNjQpPSYoMjgsMjM2Mik7OlJD
MTNfTUVNT1JZU1RBVFVTOzJBLjtfTUVNT1JZU1RBVFVTOjooMjgsMjM2NSk9IyMoMjgsMjM2
Nik9KigyOCwyMzYyKTs6UkMxM19NRU1PUllTVEFUVVM7MkEuKDI4LDIzNjcpPSMjKDI4LDIz
NjYpOzo7MkEuOzsATUVNT1JZU1RBVFVTOnQoMjgsMjM2OCk9KDI4LDIzNjIpAExQTUVNT1JZ
U1RBVFVTOnQoMjgsMjM2OSk9KDI4LDIzNjYpAE1FTlVFWF9URU1QTEFURV9IRUFERVI6dCgy
OCwyMzcwKT1zOHdWZXJzaW9uOigyNSwxNTMpLDAsMTY7d09mZnNldDooMjUsMTUzKSwxNiwx
Njtkd0hlbHBJZDooMjUsMTQpLDMyLDMyO19fYXM6OigyOCwyMzcxKT0jKDI4LDIzNzApLCgy
OCwyMzcyKT0mKDI4LDIzNzApLCgyOCwyMzczKT0qKDI4LDIzNzApLCgyOCwyMzc0KT0mKDI4
LDIzNzUpPXM4d1ZlcnNpb246KDI1LDE1MyksMCwxNjt3T2Zmc2V0OigyNSwxNTMpLDE2LDE2
O2R3SGVscElkOigyNSwxNCksMzIsMzI7X19hczo6KDI4LDIzNzEpOl9fYXNfXzQkXzI1UkM0
JF8yNTsyQS47JF8yNTo6KDI4LDIzNzYpPSMoMjgsMjM3MCksKDI4LDIzNzMpLCgyOCwyMzcz
KSwoMjgsMjM3NCksKDAsMjApOzpfXzQkXzI1UkM0JF8yNTsyQS4oMjgsMjM3Nyk9IygyOCwy
MzcwKSwoMjgsMjM3MyksKDI4LDIzNzMpLCgwLDIwKTs6X180JF8yNTsyQS47OywoMCwyMCk7
Ol9fYXNfXzQkXzI1UkM0JF8yNTsyQS47JF8yNTo6KDI4LDIzNzYpOl9fNCRfMjVSQzQkXzI1
OzJBLigyOCwyMzc3KTpfXzQkXzI1OzJBLjs7AE1FTlVFWF9URU1QTEFURV9JVEVNOnQoMjgs
MjM3OCk9czIwZHdUeXBlOigyNSwxNCksMCwzMjtkd1N0YXRlOigyNSwxNCksMzIsMzI7dUlk
OigyNSwxNTApLDY0LDMyO2JSZXNJbmZvOigyNSw1KSw5Niw4O3N6VGV4dDooMjgsNTIwKSwx
MTIsMTY7ZHdIZWxwSWQ6KDI1LDE0KSwxMjgsMzI7X19hczo6KDI4LDIzNzkpPSMoMjgsMjM3
OCksKDI4LDIzODApPSYoMjgsMjM3OCksKDI4LDIzODEpPSooMjgsMjM3OCksKDI4LDIzODIp
PSYoMjgsMjM4Myk9czIwZHdUeXBlOigyNSwxNCksMCwzMjtkd1N0YXRlOigyNSwxNCksMzIs
MzI7dUlkOigyNSwxNTApLDY0LDMyO2JSZXNJbmZvOigyNSw1KSw5Niw4O3N6VGV4dDooMjgs
NTIwKSwxMTIsMTY7ZHdIZWxwSWQ6KDI1LDE0KSwxMjgsMzI7X19hczo6KDI4LDIzNzkpOl9f
YXNfXzQkXzI2UkM0JF8yNjsyQS47JF8yNjo6KDI4LDIzODQpPSMoMjgsMjM3OCksKDI4LDIz
ODEpLCgyOCwyMzgxKSwoMjgsMjM4MiksKDAsMjApOzpfXzQkXzI2UkM0JF8yNjsyQS4oMjgs
MjM4NSk9IygyOCwyMzc4KSwoMjgsMjM4MSksKDI4LDIzODEpLCgwLDIwKTs6X180JF8yNjsy
QS47OywoMCwyMCk7Ol9fYXNfXzQkXzI2UkM0JF8yNjsyQS47JF8yNjo6KDI4LDIzODQpOl9f
NCRfMjZSQzQkXzI2OzJBLigyOCwyMzg1KTpfXzQkXzI2OzJBLjs7AHRhZ01FTlVJVEVNSU5G
TzpUdCgyOCwyMzg2KT1zNDRjYlNpemU6KDI1LDE1MCksMCwzMjtmTWFzazooMjUsMTUwKSwz
MiwzMjtmVHlwZTooMjUsMTUwKSw2NCwzMjtmU3RhdGU6KDI1LDE1MCksOTYsMzI7d0lEOigy
NSwxNTApLDEyOCwzMjtoU3ViTWVudTooMjUsNDkpLDE2MCwzMjtoYm1wQ2hlY2tlZDooMjUs
MjEpLDE5MiwzMjtoYm1wVW5jaGVja2VkOigyNSwyMSksMjI0LDMyO2R3SXRlbURhdGE6KDI1
LDE0KSwyNTYsMzI7ZHdUeXBlRGF0YTooMjUsOTYpLDI4OCwzMjtjY2g6KDI1LDE1MCksMzIw
LDMyO19fYXM6OigyOCwyMzg3KT0jIygyOCwyMzg4KT0mKDI4LDIzODYpOzpSQzE1dGFnTUVO
VUlURU1JTkZPOzJBLjt0YWdNRU5VSVRFTUlORk86OigyOCwyMzg5KT0jIygyOCwyMzkwKT0q
KDI4LDIzODYpOzpSQzE1dGFnTUVOVUlURU1JTkZPOzJBLigyOCwyMzkxKT0jIygyOCwyMzkw
KTs6OzJBLjs7AE1FTlVJVEVNSU5GTzp0KDI4LDIzOTIpPSgyOCwyMzg2KQBMUE1FTlVJVEVN
SU5GTzp0KDI4LDIzOTMpPSgyOCwyMzkwKQBMUENNRU5VSVRFTUlORk86dCgyOCwyMzk0KT0o
MjgsMjM5NSk9KigyOCwyMzkyKQBNRU5VSVRFTVRFTVBMQVRFOnQoMjgsMjM5Nik9czZtdE9w
dGlvbjooMjUsMTUzKSwwLDE2O210SUQ6KDI1LDE1MyksMTYsMTY7bXRTdHJpbmc6KDI4LDUy
MCksMzIsMTY7X19hczo6KDI4LDIzOTcpPSMoMjgsMjM5NiksKDI4LDIzOTgpPSYoMjgsMjM5
NiksKDI4LDIzOTkpPSooMjgsMjM5NiksKDI4LDI0MDApPSYoMjgsMjQwMSk9czZtdE9wdGlv
bjooMjUsMTUzKSwwLDE2O210SUQ6KDI1LDE1MyksMTYsMTY7bXRTdHJpbmc6KDI4LDUyMCks
MzIsMTY7X19hczo6KDI4LDIzOTcpOl9fYXNfXzQkXzI3UkM0JF8yNzsyQS47JF8yNzo6KDI4
LDI0MDIpPSMoMjgsMjM5NiksKDI4LDIzOTkpLCgyOCwyMzk5KSwoMjgsMjQwMCksKDAsMjAp
OzpfXzQkXzI3UkM0JF8yNzsyQS4oMjgsMjQwMyk9IygyOCwyMzk2KSwoMjgsMjM5OSksKDI4
LDIzOTkpLCgwLDIwKTs6X180JF8yNzsyQS47OywoMCwyMCk7Ol9fYXNfXzQkXzI3UkM0JF8y
NzsyQS47JF8yNzo6KDI4LDI0MDIpOl9fNCRfMjdSQzQkXzI3OzJBLigyOCwyNDAzKTpfXzQk
XzI3OzJBLjs7AE1FTlVJVEVNVEVNUExBVEVIRUFERVI6dCgyOCwyNDA0KT1zNHZlcnNpb25O
dW1iZXI6KDI1LDE1MyksMCwxNjtvZmZzZXQ6KDI1LDE1MyksMTYsMTY7X19hczo6KDI4LDI0
MDUpPSMoMjgsMjQwNCksKDI4LDI0MDYpPSYoMjgsMjQwNCksKDI4LDI0MDcpPSooMjgsMjQw
NCksKDI4LDI0MDgpPSYoMjgsMjQwOSk9czR2ZXJzaW9uTnVtYmVyOigyNSwxNTMpLDAsMTY7
b2Zmc2V0OigyNSwxNTMpLDE2LDE2O19fYXM6OigyOCwyNDA1KTpfX2FzX180JF8yOFJDNCRf
Mjg7MkEuOyRfMjg6OigyOCwyNDEwKT0jKDI4LDI0MDQpLCgyOCwyNDA3KSwoMjgsMjQwNyks
KDI4LDI0MDgpLCgwLDIwKTs6X180JF8yOFJDNCRfMjg7MkEuKDI4LDI0MTEpPSMoMjgsMjQw
NCksKDI4LDI0MDcpLCgyOCwyNDA3KSwoMCwyMCk7Ol9fNCRfMjg7MkEuOzssKDAsMjApOzpf
X2FzX180JF8yOFJDNCRfMjg7MkEuOyRfMjg6OigyOCwyNDEwKTpfXzQkXzI4UkM0JF8yODsy
QS4oMjgsMjQxMSk6X180JF8yODsyQS47OwBNRU5VVEVNUExBVEU6dCgyOCwyNDEyKT0oMCwy
MCkATFBNRU5VVEVNUExBVEU6dCgyOCwyNDEzKT0oMCwyMykAdGFnTUVUQUZJTEVQSUNUOlR0
KDI4LDI0MTQpPXMxNm1tOigyNSwxMyksMCwzMjt4RXh0OigyNSwxMyksMzIsMzI7eUV4dDoo
MjUsMTMpLDY0LDMyO2hNRjooMjUsNTApLDk2LDMyO19fYXM6OigyOCwyNDE1KT0jIygyOCwy
NDE2KT0mKDI4LDI0MTQpOzpSQzE1dGFnTUVUQUZJTEVQSUNUOzJBLjt0YWdNRVRBRklMRVBJ
Q1Q6OigyOCwyNDE3KT0jIygyOCwyNDE4KT0qKDI4LDI0MTQpOzpSQzE1dGFnTUVUQUZJTEVQ
SUNUOzJBLigyOCwyNDE5KT0jIygyOCwyNDE4KTs6OzJBLjs7AE1FVEFGSUxFUElDVDp0KDI4
LDI0MjApPSgyOCwyNDE0KQBQTUVUQUZJTEVQSUNUOnQoMjgsMjQyMSk9KDI4LDI0MTgpAExQ
TUVUQUZJTEVQSUNUOnQoMjgsMjQyMik9KDI4LDI0MTgpAHRhZ01FVEFIRUFERVI6VHQoMjgs
MjQyMyk9czE4bXRUeXBlOigyNSwxNTMpLDAsMTY7bXRIZWFkZXJTaXplOigyNSwxNTMpLDE2
LDE2O210VmVyc2lvbjooMjUsMTUzKSwzMiwxNjttdFNpemU6KDI1LDE0KSw0OCwzMjttdE5v
T2JqZWN0czooMjUsMTUzKSw4MCwxNjttdE1heFJlY29yZDooMjUsMTQpLDk2LDMyO210Tm9Q
YXJhbWV0ZXJzOigyNSwxNTMpLDEyOCwxNjtfX2FzOjooMjgsMjQyNCk9IyMoMjgsMjQyNSk9
JigyOCwyNDIzKTs6UkMxM3RhZ01FVEFIRUFERVI7MkEuO3RhZ01FVEFIRUFERVI6OigyOCwy
NDI2KT0jIygyOCwyNDI3KT0qKDI4LDI0MjMpOzpSQzEzdGFnTUVUQUhFQURFUjsyQS4oMjgs
MjQyOCk9IyMoMjgsMjQyNyk7OjsyQS47OwBNRVRBSEVBREVSOnQoMjgsMjQyOSk9KDI4LDI0
MjMpAHRhZ01FVEFSRUNPUkQ6VHQoMjgsMjQzMCk9czhyZFNpemU6KDI1LDE0KSwwLDMyO3Jk
RnVuY3Rpb246KDI1LDE1MyksMzIsMTY7cmRQYXJtOigyOCwyNDMxKT1hcigwLDEpOzA7MDso
MCw5KSw0OCwxNjtfX2FzOjooMjgsMjQzMik9IyMoMjgsMjQzMyk9JigyOCwyNDMwKTs6UkMx
M3RhZ01FVEFSRUNPUkQ7MkEuO3RhZ01FVEFSRUNPUkQ6OigyOCwyNDM0KT0jIygyOCwyNDM1
KT0qKDI4LDI0MzApOzpSQzEzdGFnTUVUQVJFQ09SRDsyQS4oMjgsMjQzNik9IyMoMjgsMjQz
NSk7OjsyQS47OwBNRVRBUkVDT1JEOnQoMjgsMjQzNyk9KDI4LDI0MzApAExQTUVUQVJFQ09S
RDp0KDI4LDI0MzgpPSgyOCwyNDM1KQB0YWdNSU5JTUlaRURNRVRSSUNTOlR0KDI4LDI0Mzkp
PXMyMGNiU2l6ZTooMjUsMTUwKSwwLDMyO2lXaWR0aDooMCwxKSwzMiwzMjtpSG9yekdhcDoo
MCwxKSw2NCwzMjtpVmVydEdhcDooMCwxKSw5NiwzMjtpQXJyYW5nZTooMCwxKSwxMjgsMzI7
X19hczo6KDI4LDI0NDApPSMjKDI4LDI0NDEpPSYoMjgsMjQzOSk7OlJDMTl0YWdNSU5JTUla
RURNRVRSSUNTOzJBLjt0YWdNSU5JTUlaRURNRVRSSUNTOjooMjgsMjQ0Mik9IyMoMjgsMjQ0
Myk9KigyOCwyNDM5KTs6UkMxOXRhZ01JTklNSVpFRE1FVFJJQ1M7MkEuKDI4LDI0NDQpPSMj
KDI4LDI0NDMpOzo7MkEuOzsATUlOSU1JWkVETUVUUklDUzp0KDI4LDI0NDUpPSgyOCwyNDM5
KQBMUE1JTklNSVpFRE1FVFJJQ1M6dCgyOCwyNDQ2KT0oMjgsMjQ0MykAdGFnTUlOTUFYSU5G
TzpUdCgyOCwyNDQ3KT1zNDBwdFJlc2VydmVkOigyOCwzMDkpLDAsNjQ7cHRNYXhTaXplOigy
OCwzMDkpLDY0LDY0O3B0TWF4UG9zaXRpb246KDI4LDMwOSksMTI4LDY0O3B0TWluVHJhY2tT
aXplOigyOCwzMDkpLDE5Miw2NDtwdE1heFRyYWNrU2l6ZTooMjgsMzA5KSwyNTYsNjQ7X19h
czo6KDI4LDI0NDgpPSMjKDI4LDI0NDkpPSYoMjgsMjQ0Nyk7OlJDMTN0YWdNSU5NQVhJTkZP
OzJBLjt0YWdNSU5NQVhJTkZPOjooMjgsMjQ1MCk9IyMoMjgsMjQ1MSk9KigyOCwyNDQ3KTs6
UkMxM3RhZ01JTk1BWElORk87MkEuKDI4LDI0NTIpPSMjKDI4LDI0NTEpOzo7MkEuOzsATUlO
TUFYSU5GTzp0KDI4LDI0NTMpPSgyOCwyNDQ3KQBMUE1JTk1BWElORk86dCgyOCwyNDU0KT0o
MjgsMjQ1MSkAbW9kZW1kZXZjYXBzX3RhZzpUdCgyOCwyNDU1KT1zODBkd0FjdHVhbFNpemU6
KDI1LDE0KSwwLDMyO2R3UmVxdWlyZWRTaXplOigyNSwxNCksMzIsMzI7ZHdEZXZTcGVjaWZp
Y09mZnNldDooMjUsMTQpLDY0LDMyO2R3RGV2U3BlY2lmaWNTaXplOigyNSwxNCksOTYsMzI7
ZHdNb2RlbVByb3ZpZGVyVmVyc2lvbjooMjUsMTQpLDEyOCwzMjtkd01vZGVtTWFudWZhY3R1
cmVyT2Zmc2V0OigyNSwxNCksMTYwLDMyO2R3TW9kZW1NYW51ZmFjdHVyZXJTaXplOigyNSwx
NCksMTkyLDMyO2R3TW9kZW1Nb2RlbE9mZnNldDooMjUsMTQpLDIyNCwzMjtkd01vZGVtTW9k
ZWxTaXplOigyNSwxNCksMjU2LDMyO2R3TW9kZW1WZXJzaW9uT2Zmc2V0OigyNSwxNCksMjg4
LDMyO2R3TW9kZW1WZXJzaW9uU2l6ZTooMjUsMTQpLDMyMCwzMjtkd0RpYWxPcHRpb25zOigy
NSwxNCksMzUyLDMyO2R3Q2FsbFNldHVwRmFpbFRpbWVyOigyNSwxNCksMzg0LDMyO2R3SW5h
Y3Rpdml0eVRpbWVvdXQ6KDI1LDE0KSw0MTYsMzI7ZHdTcGVha2VyVm9sdW1lOigyNSwxNCks
NDQ4LDMyO2R3U3BlYWtlck1vZGU6KDI1LDE0KSw0ODAsMzI7ZHdNb2RlbU9wdGlvbnM6KDI1
LDE0KSw1MTIsMzI7ZHdNYXhEVEVSYXRlOigyNSwxNCksNTQ0LDMyO2R3TWF4RENFUmF0ZToo
MjUsMTQpLDU3NiwzMjthYlZhcmlhYmxlUG9ydGlvbjooMjgsMjUwKSw2MDgsODtfX2FzOjoo
MjgsMjQ1Nik9IyMoMjgsMjQ1Nyk9JigyOCwyNDU1KTs6UkMxNm1vZGVtZGV2Y2Fwc190YWc7
MkEuO21vZGVtZGV2Y2Fwc190YWc6OigyOCwyNDU4KT0jIygyOCwyNDU5KT0qKDI4LDI0NTUp
OzpSQzE2bW9kZW1kZXZjYXBzX3RhZzsyQS4oMjgsMjQ2MCk9IyMoMjgsMjQ1OSk7OjsyQS47
OwBNT0RFTURFVkNBUFM6dCgyOCwyNDYxKT0oMjgsMjQ1NSkAUE1PREVNREVWQ0FQUzp0KDI4
LDI0NjIpPSgyOCwyNDU5KQBMUE1PREVNREVWQ0FQUzp0KDI4LDI0NjMpPSgyOCwyNDU5KQBt
b2RlbXNldHRpbmdzX3RhZzpUdCgyOCwyNDY0KT1zNDhkd0FjdHVhbFNpemU6KDI1LDE0KSww
LDMyO2R3UmVxdWlyZWRTaXplOigyNSwxNCksMzIsMzI7ZHdEZXZTcGVjaWZpY09mZnNldDoo
MjUsMTQpLDY0LDMyO2R3RGV2U3BlY2lmaWNTaXplOigyNSwxNCksOTYsMzI7ZHdDYWxsU2V0
dXBGYWlsVGltZXI6KDI1LDE0KSwxMjgsMzI7ZHdJbmFjdGl2aXR5VGltZW91dDooMjUsMTQp
LDE2MCwzMjtkd1NwZWFrZXJWb2x1bWU6KDI1LDE0KSwxOTIsMzI7ZHdTcGVha2VyTW9kZToo
MjUsMTQpLDIyNCwzMjtkd1ByZWZlcnJlZE1vZGVtT3B0aW9uczooMjUsMTQpLDI1NiwzMjtk
d05lZ290aWF0ZWRNb2RlbU9wdGlvbnM6KDI1LDE0KSwyODgsMzI7ZHdOZWdvdGlhdGVkRENF
UmF0ZTooMjUsMTQpLDMyMCwzMjthYlZhcmlhYmxlUG9ydGlvbjooMjgsMjUwKSwzNTIsODtf
X2FzOjooMjgsMjQ2NSk9IyMoMjgsMjQ2Nik9JigyOCwyNDY0KTs6UkMxN21vZGVtc2V0dGlu
Z3NfdGFnOzJBLjttb2RlbXNldHRpbmdzX3RhZzo6KDI4LDI0NjcpPSMjKDI4LDI0NjgpPSoo
MjgsMjQ2NCk7OlJDMTdtb2RlbXNldHRpbmdzX3RhZzsyQS4oMjgsMjQ2OSk9IyMoMjgsMjQ2
OCk7OjsyQS47OwBNT0RFTVNFVFRJTkdTOnQoMjgsMjQ3MCk9KDI4LDI0NjQpAFBNT0RFTVNF
VFRJTkdTOnQoMjgsMjQ3MSk9KDI4LDI0NjgpAExQTU9ERU1TRVRUSU5HUzp0KDI4LDI0NzIp
PSgyOCwyNDY4KQB0YWdNT05DQlNUUlVDVDpUdCgyOCwyNDczKT1zMTI0Y2I6KDI1LDE1MCks
MCwzMjtkd1RpbWU6KDI1LDE0KSwzMiwzMjtoVGFzazooMjUsMTkpLDY0LDMyO2R3UmV0Oigy
NSwxNCksOTYsMzI7d1R5cGU6KDI1LDE1MCksMTI4LDMyO3dGbXQ6KDI1LDE1MCksMTYwLDMy
O2hDb252OigyNSwyNCksMTkyLDMyO2hzejE6KDI1LDU5KSwyMjQsMzI7aHN6MjooMjUsNTkp
LDI1NiwzMjtoRGF0YTooMjUsMjkpLDI4OCwzMjtkd0RhdGExOigyNSwxNCksMzIwLDMyO2R3
RGF0YTI6KDI1LDE0KSwzNTIsMzI7Y2M6KDI4LDY2MiksMzg0LDMyMDtjYkRhdGE6KDI1LDE0
KSw3MDQsMzI7RGF0YTooMjgsNzc5KSw3MzYsMjU2O19fYXM6OigyOCwyNDc0KT0jIygyOCwy
NDc1KT0mKDI4LDI0NzMpOzpSQzE0dGFnTU9OQ0JTVFJVQ1Q7MkEuO3RhZ01PTkNCU1RSVUNU
OjooMjgsMjQ3Nik9IyMoMjgsMjQ3Nyk9KigyOCwyNDczKTs6UkMxNHRhZ01PTkNCU1RSVUNU
OzJBLigyOCwyNDc4KT0jIygyOCwyNDc3KTs6OzJBLjs7AE1PTkNCU1RSVUNUOnQoMjgsMjQ3
OSk9KDI4LDI0NzMpAHRhZ01PTkNPTlZTVFJVQ1Q6VHQoMjgsMjQ4MCk9czMyY2I6KDI1LDE1
MCksMCwzMjtmQ29ubmVjdDooMjUsMiksMzIsMzI7ZHdUaW1lOigyNSwxNCksNjQsMzI7aFRh
c2s6KDI1LDE5KSw5NiwzMjtoc3pTdmM6KDI1LDU5KSwxMjgsMzI7aHN6VG9waWM6KDI1LDU5
KSwxNjAsMzI7aENvbnZDbGllbnQ6KDI1LDI0KSwxOTIsMzI7aENvbnZTZXJ2ZXI6KDI1LDI0
KSwyMjQsMzI7X19hczo6KDI4LDI0ODEpPSMjKDI4LDI0ODIpPSYoMjgsMjQ4MCk7OlJDMTZ0
YWdNT05DT05WU1RSVUNUOzJBLjt0YWdNT05DT05WU1RSVUNUOjooMjgsMjQ4Myk9IyMoMjgs
MjQ4NCk9KigyOCwyNDgwKTs6UkMxNnRhZ01PTkNPTlZTVFJVQ1Q7MkEuKDI4LDI0ODUpPSMj
KDI4LDI0ODQpOzo7MkEuOzsATU9OQ09OVlNUUlVDVDp0KDI4LDI0ODYpPSgyOCwyNDgwKQB0
YWdNT05FUlJTVFJVQ1Q6VHQoMjgsMjQ4Nyk9czE2Y2I6KDI1LDE1MCksMCwzMjt3TGFzdEVy
cm9yOigyNSwxNTApLDMyLDMyO2R3VGltZTooMjUsMTQpLDY0LDMyO2hUYXNrOigyNSwxOSks
OTYsMzI7X19hczo6KDI4LDI0ODgpPSMjKDI4LDI0ODkpPSYoMjgsMjQ4Nyk7OlJDMTV0YWdN
T05FUlJTVFJVQ1Q7MkEuO3RhZ01PTkVSUlNUUlVDVDo6KDI4LDI0OTApPSMjKDI4LDI0OTEp
PSooMjgsMjQ4Nyk7OlJDMTV0YWdNT05FUlJTVFJVQ1Q7MkEuKDI4LDI0OTIpPSMjKDI4LDI0
OTEpOzo7MkEuOzsATU9ORVJSU1RSVUNUOnQoMjgsMjQ5Myk9KDI4LDI0ODcpAHRhZ01PTkhT
WlNUUlVDVDpUdCgyOCwyNDk0KT1zMjRjYjooMjUsMTUwKSwwLDMyO2ZzQWN0aW9uOigyNSwy
KSwzMiwzMjtkd1RpbWU6KDI1LDE0KSw2NCwzMjtoc3o6KDI1LDU5KSw5NiwzMjtoVGFzazoo
MjUsMTkpLDEyOCwzMjtzdHI6KDI4LDkwOSksMTYwLDg7X19hczo6KDI4LDI0OTUpPSMjKDI4
LDI0OTYpPSYoMjgsMjQ5NCk7OlJDMTV0YWdNT05IU1pTVFJVQ1Q7MkEuO3RhZ01PTkhTWlNU
UlVDVDo6KDI4LDI0OTcpPSMjKDI4LDI0OTgpPSooMjgsMjQ5NCk7OlJDMTV0YWdNT05IU1pT
VFJVQ1Q7MkEuKDI4LDI0OTkpPSMjKDI4LDI0OTgpOzo7MkEuOzsATU9OSFNaU1RSVUNUOnQo
MjgsMjUwMCk9KDI4LDI0OTQpAF9NT05JVE9SX0lORk9fMTpUdCgyOCwyNTAxKT1zNHBOYW1l
OigyNSw5NiksMCwzMjtfX2FzOjooMjgsMjUwMik9IyMoMjgsMjUwMyk9JigyOCwyNTAxKTs6
UkMxNV9NT05JVE9SX0lORk9fMTsyQS47X01PTklUT1JfSU5GT18xOjooMjgsMjUwNCk9IyMo
MjgsMjUwNSk9KigyOCwyNTAxKTs6UkMxNV9NT05JVE9SX0lORk9fMTsyQS4oMjgsMjUwNik9
IyMoMjgsMjUwNSk7OjsyQS47OwBNT05JVE9SX0lORk9fMTp0KDI4LDI1MDcpPSgyOCwyNTAx
KQBfTU9OSVRPUl9JTkZPXzI6VHQoMjgsMjUwOCk9czEycE5hbWU6KDI1LDk2KSwwLDMyO3BF
bnZpcm9ubWVudDooMjUsOTYpLDMyLDMyO3BETExOYW1lOigyNSw5NiksNjQsMzI7X19hczo6
KDI4LDI1MDkpPSMjKDI4LDI1MTApPSYoMjgsMjUwOCk7OlJDMTVfTU9OSVRPUl9JTkZPXzI7
MkEuO19NT05JVE9SX0lORk9fMjo6KDI4LDI1MTEpPSMjKDI4LDI1MTIpPSooMjgsMjUwOCk7
OlJDMTVfTU9OSVRPUl9JTkZPXzI7MkEuKDI4LDI1MTMpPSMjKDI4LDI1MTIpOzo7MkEuOzsA
TU9OSVRPUl9JTkZPXzI6dCgyOCwyNTE0KT0oMjgsMjUwOCkAdGFnTU9OTElOS1NUUlVDVDpU
dCgyOCwyNTE1KT1zNDhjYjooMjUsMTUwKSwwLDMyO2R3VGltZTooMjUsMTQpLDMyLDMyO2hU
YXNrOigyNSwxOSksNjQsMzI7ZkVzdGFibGlzaGVkOigyNSwyKSw5NiwzMjtmTm9EYXRhOigy
NSwyKSwxMjgsMzI7aHN6U3ZjOigyNSw1OSksMTYwLDMyO2hzelRvcGljOigyNSw1OSksMTky
LDMyO2hzekl0ZW06KDI1LDU5KSwyMjQsMzI7d0ZtdDooMjUsMTUwKSwyNTYsMzI7ZlNlcnZl
cjooMjUsMiksMjg4LDMyO2hDb252U2VydmVyOigyNSwyNCksMzIwLDMyO2hDb252Q2xpZW50
OigyNSwyNCksMzUyLDMyO19fYXM6OigyOCwyNTE2KT0jIygyOCwyNTE3KT0mKDI4LDI1MTUp
OzpSQzE2dGFnTU9OTElOS1NUUlVDVDsyQS47dGFnTU9OTElOS1NUUlVDVDo6KDI4LDI1MTgp
PSMjKDI4LDI1MTkpPSooMjgsMjUxNSk7OlJDMTZ0YWdNT05MSU5LU1RSVUNUOzJBLigyOCwy
NTIwKT0jIygyOCwyNTE5KTs6OzJBLjs7AE1PTkxJTktTVFJVQ1Q6dCgyOCwyNTIxKT0oMjgs
MjUxNSkAdGFnTU9OTVNHU1RSVUNUOlR0KDI4LDI1MjIpPXM3MmNiOigyNSwxNTApLDAsMzI7
aHduZFRvOigyNSw2MSksMzIsMzI7ZHdUaW1lOigyNSwxNCksNjQsMzI7aFRhc2s6KDI1LDE5
KSw5NiwzMjt3TXNnOigyNSwxNTApLDEyOCwzMjt3UGFyYW06KDI1LDE1NCksMTYwLDMyO2xQ
YXJhbTooMjUsNzApLDE5MiwzMjtkbWhkOigyOCw3ODUpLDIyNCwzNTI7X19hczo6KDI4LDI1
MjMpPSMjKDI4LDI1MjQpPSYoMjgsMjUyMik7OlJDMTV0YWdNT05NU0dTVFJVQ1Q7MkEuO3Rh
Z01PTk1TR1NUUlVDVDo6KDI4LDI1MjUpPSMjKDI4LDI1MjYpPSooMjgsMjUyMik7OlJDMTV0
YWdNT05NU0dTVFJVQ1Q7MkEuKDI4LDI1MjcpPSMjKDI4LDI1MjYpOzo7MkEuOzsATU9OTVNH
U1RSVUNUOnQoMjgsMjUyOCk9KDI4LDI1MjIpAHRhZ01PVVNFSE9PS1NUUlVDVDpUdCgyOCwy
NTI5KT1zMjBwdDooMjgsMzA5KSwwLDY0O2h3bmQ6KDI1LDYxKSw2NCwzMjt3SGl0VGVzdENv
ZGU6KDI1LDE1MCksOTYsMzI7ZHdFeHRyYUluZm86KDI1LDE0KSwxMjgsMzI7X19hczo6KDI4
LDI1MzApPSMjKDI4LDI1MzEpPSYoMjgsMjUyOSk7OlJDMTh0YWdNT1VTRUhPT0tTVFJVQ1Q7
MkEuO3RhZ01PVVNFSE9PS1NUUlVDVDo6KDI4LDI1MzIpPSMjKDI4LDI1MzMpPSooMjgsMjUy
OSk7OlJDMTh0YWdNT1VTRUhPT0tTVFJVQ1Q7MkEuKDI4LDI1MzQpPSMjKDI4LDI1MzMpOzo7
MkEuOzsATU9VU0VIT09LU1RSVUNUOnQoMjgsMjUzNSk9KDI4LDI1MjkpAFBNT1VTRUhPT0tT
VFJVQ1Q6dCgyOCwyNTM2KT0oMjgsMjUzMykATFBNT1VTRUhPT0tTVFJVQ1Q6dCgyOCwyNTM3
KT0oMjgsMjUzMykAX01PVVNFS0VZUzpUdCgyOCwyNTM4KT1zMjhjYlNpemU6KDI1LDE0KSww
LDMyO2R3RmxhZ3M6KDI1LDE0KSwzMiwzMjtpTWF4U3BlZWQ6KDI1LDE0KSw2NCwzMjtpVGlt
ZVRvTWF4U3BlZWQ6KDI1LDE0KSw5NiwzMjtpQ3RybFNwZWVkOigyNSwxNCksMTI4LDMyO2R3
UmVzZXJ2ZWQxOigyNSwxNCksMTYwLDMyO2R3UmVzZXJ2ZWQyOigyNSwxNCksMTkyLDMyO19f
YXM6OigyOCwyNTM5KT0jIygyOCwyNTQwKT0mKDI4LDI1MzgpOzpSQzEwX01PVVNFS0VZUzsy
QS47X01PVVNFS0VZUzo6KDI4LDI1NDEpPSMjKDI4LDI1NDIpPSooMjgsMjUzOCk7OlJDMTBf
TU9VU0VLRVlTOzJBLigyOCwyNTQzKT0jIygyOCwyNTQyKTs6OzJBLjs7AE1PVVNFS0VZUzp0
KDI4LDI1NDQpPSgyOCwyNTM4KQB0YWdNU0c6VHQoMjgsMjU0NSk9czI4aHduZDooMjUsNjEp
LDAsMzI7bWVzc2FnZTooMjUsMTUwKSwzMiwzMjt3UGFyYW06KDI1LDE1NCksNjQsMzI7bFBh
cmFtOigyNSw3MCksOTYsMzI7dGltZTooMjUsMTQpLDEyOCwzMjtwdDooMjgsMzA5KSwxNjAs
NjQ7X19hczo6KDI4LDI1NDYpPSMjKDI4LDI1NDcpPSYoMjgsMjU0NSk7OlJDNnRhZ01TRzsy
QS47dGFnTVNHOjooMjgsMjU0OCk9IyMoMjgsMjU0OSk9KigyOCwyNTQ1KTs6UkM2dGFnTVNH
OzJBLigyOCwyNTUwKT0jIygyOCwyNTQ5KTs6OzJBLjs7AE1TRzp0KDI4LDI1NTEpPSgyOCwy
NTQ1KQBMUE1TRzp0KDI4LDI1NTIpPSgyOCwyNTQ5KQBNU0dCT1hDQUxMQkFDSzp0KDI4LDI1
NTMpPSgyOCwyNTU0KT0qKDI4LDI1NTUpPWYoMCwyMCkATVNHQk9YUEFSQU1TOnQoMjgsMjU1
Nik9czQwY2JTaXplOigyNSwxNTApLDAsMzI7aHduZE93bmVyOigyNSw2MSksMzIsMzI7aElu
c3RhbmNlOigyNSw0MyksNjQsMzI7bHBzelRleHQ6KDI1LDgxKSw5NiwzMjtscHN6Q2FwdGlv
bjooMjUsODEpLDEyOCwzMjtkd1N0eWxlOigyNSwxNCksMTYwLDMyO2xwc3pJY29uOigyNSw4
MSksMTkyLDMyO2R3Q29udGV4dEhlbHBJZDooMjUsMTQpLDIyNCwzMjtscGZuTXNnQm94Q2Fs
bGJhY2s6KDI4LDI1NTMpLDI1NiwzMjtkd0xhbmd1YWdlSWQ6KDI1LDE0KSwyODgsMzI7X19h
czo6KDI4LDI1NTcpPSMoMjgsMjU1NiksKDI4LDI1NTgpPSYoMjgsMjU1NiksKDI4LDI1NTkp
PSooMjgsMjU1NiksKDI4LDI1NjApPSYoMjgsMjU2MSk9czQwY2JTaXplOigyNSwxNTApLDAs
MzI7aHduZE93bmVyOigyNSw2MSksMzIsMzI7aEluc3RhbmNlOigyNSw0MyksNjQsMzI7bHBz
elRleHQ6KDI1LDgxKSw5NiwzMjtscHN6Q2FwdGlvbjooMjUsODEpLDEyOCwzMjtkd1N0eWxl
OigyNSwxNCksMTYwLDMyO2xwc3pJY29uOigyNSw4MSksMTkyLDMyO2R3Q29udGV4dEhlbHBJ
ZDooMjUsMTQpLDIyNCwzMjtscGZuTXNnQm94Q2FsbGJhY2s6KDI4LDI1NTMpLDI1NiwzMjtk
d0xhbmd1YWdlSWQ6KDI1LDE0KSwyODgsMzI7X19hczo6KDI4LDI1NTcpOl9fYXNfXzQkXzI5
UkM0JF8yOTsyQS47JF8yOTo6KDI4LDI1NjIpPSMoMjgsMjU1NiksKDI4LDI1NTkpLCgyOCwy
NTU5KSwoMjgsMjU2MCksKDAsMjApOzpfXzQkXzI5UkM0JF8yOTsyQS4oMjgsMjU2Myk9Iygy
OCwyNTU2KSwoMjgsMjU1OSksKDI4LDI1NTkpLCgwLDIwKTs6X180JF8yOTsyQS47OywoMCwy
MCk7Ol9fYXNfXzQkXzI5UkM0JF8yOTsyQS47JF8yOTo6KDI4LDI1NjIpOl9fNCRfMjlSQzQk
XzI5OzJBLigyOCwyNTYzKTpfXzQkXzI5OzJBLjs7AFBNU0dCT1hQQVJBTVM6dCgyOCwyNTY0
KT0oMjgsMjU1OSkATFBNU0dCT1hQQVJBTVM6dCgyOCwyNTY1KT0oMjgsMjU1OSkAX21zZ2Zp
bHRlcjpUdCgyOCwyNTY2KT1zMjRubWhkcjooMjgsMTc1MSksMCw5Njttc2c6KDI1LDE1MCks
OTYsMzI7d1BhcmFtOigyNSwxNTQpLDEyOCwzMjtsUGFyYW06KDI1LDcwKSwxNjAsMzI7X19h
czo6KDI4LDI1NjcpPSMjKDI4LDI1NjgpPSYoMjgsMjU2Nik7OlJDMTBfbXNnZmlsdGVyOzJB
LjtfbXNnZmlsdGVyOjooMjgsMjU2OSk9IyMoMjgsMjU3MCk9KigyOCwyNTY2KTs6UkMxMF9t
c2dmaWx0ZXI7MkEuKDI4LDI1NzEpPSMjKDI4LDI1NzApOzo7MkEuOzsATVNHRklMVEVSOnQo
MjgsMjU3Mik9KDI4LDI1NjYpAHRhZ01VTFRJS0VZSEVMUDpUdCgyOCwyNTczKT1zOG1rU2l6
ZTooMjUsMTQpLDAsMzI7bWtLZXlsaXN0OigyNSwxNDcpLDMyLDg7c3pLZXlwaHJhc2U6KDI4
LDkwOSksNDAsODtfX2FzOjooMjgsMjU3NCk9IyMoMjgsMjU3NSk9JigyOCwyNTczKTs6UkMx
NXRhZ01VTFRJS0VZSEVMUDsyQS47dGFnTVVMVElLRVlIRUxQOjooMjgsMjU3Nik9IyMoMjgs
MjU3Nyk9KigyOCwyNTczKTs6UkMxNXRhZ01VTFRJS0VZSEVMUDsyQS4oMjgsMjU3OCk9IyMo
MjgsMjU3Nyk7OjsyQS47OwBNVUxUSUtFWUhFTFA6dCgyOCwyNTc5KT0oMjgsMjU3MykAX05B
TUVfQlVGRkVSOlR0KDI4LDI1ODApPXMxOG5hbWU6KDI4LDI1ODEpPWFyKDAsMSk7MDsxNTso
MCwxMSksMCwxMjg7bmFtZV9udW06KDI1LDE0OSksMTI4LDg7bmFtZV9mbGFnczooMjUsMTQ5
KSwxMzYsODtfX2FzOjooMjgsMjU4Mik9IyMoMjgsMjU4Myk9JigyOCwyNTgwKTs6UkMxMl9O
QU1FX0JVRkZFUjsyQS47X05BTUVfQlVGRkVSOjooMjgsMjU4NCk9IyMoMjgsMjU4NSk9Kigy
OCwyNTgwKTs6UkMxMl9OQU1FX0JVRkZFUjsyQS4oMjgsMjU4Nik9IyMoMjgsMjU4NSk7Ojsy
QS47OwBOQU1FX0JVRkZFUjp0KDI4LDI1ODcpPSgyOCwyNTgwKQBfTkNCOlR0KDI4LDI1ODgp
PXM2NG5jYl9jb21tYW5kOigyNSwxNDkpLDAsODtuY2JfcmV0Y29kZTooMjUsMTQ5KSw4LDg7
bmNiX2xzbjooMjUsMTQ5KSwxNiw4O25jYl9udW06KDI1LDE0OSksMjQsODtuY2JfYnVmZmVy
OigyNSwxMzApLDMyLDMyO25jYl9sZW5ndGg6KDI1LDE1MyksNjQsMTY7bmNiX2NhbGxuYW1l
OigyOCwyNTgxKSw4MCwxMjg7bmNiX25hbWU6KDI4LDI1ODEpLDIwOCwxMjg7bmNiX3J0bzoo
MjUsMTQ5KSwzMzYsODtuY2Jfc3RvOigyNSwxNDkpLDM0NCw4O25jYl9wb3N0OigyOCwyNTg5
KT0qKDI4LDI1OTApPWYoMCwyMCksMzUyLDMyO25jYl9sYW5hX251bTooMjUsMTQ5KSwzODQs
ODtuY2JfY21kX2NwbHQ6KDI1LDE0OSksMzkyLDg7bmNiX3Jlc2VydmU6KDI4LDI1OTEpPWFy
KDAsMSk7MDs5OygwLDExKSw0MDAsODA7bmNiX2V2ZW50OigyNSwxOSksNDgwLDMyO19fYXM6
OigyOCwyNTkyKT0jIygyOCwyNTkzKT0mKDI4LDI1ODgpOzpSQzRfTkNCOzJBLjtfTkNCOjoo
MjgsMjU5NCk9IyMoMjgsMjU5NSk9KigyOCwyNTg4KTs6UkM0X05DQjsyQS4oMjgsMjU5Nik9
IyMoMjgsMjU5NSk7OjsyQS47OwBOQ0I6dCgyOCwyNTk3KT0oMjgsMjU4OCkAX05DQ0FMQ1NJ
WkVfUEFSQU1TOlR0KDI4LDI1OTgpPXM1MnJncmM6KDI4LDI1OTkpPWFyKDAsMSk7MDsyOygy
OCwxMDcpLDAsMzg0O2xwcG9zOigyOCwyMDI5KSwzODQsMzI7X19hczo6KDI4LDI2MDApPSMj
KDI4LDI2MDEpPSYoMjgsMjU5OCk7OlJDMThfTkNDQUxDU0laRV9QQVJBTVM7MkEuO19OQ0NB
TENTSVpFX1BBUkFNUzo6KDI4LDI2MDIpPSMjKDI4LDI2MDMpPSooMjgsMjU5OCk7OlJDMThf
TkNDQUxDU0laRV9QQVJBTVM7MkEuKDI4LDI2MDQpPSMjKDI4LDI2MDMpOzo7MkEuOzsATkND
QUxDU0laRV9QQVJBTVM6dCgyOCwyNjA1KT0oMjgsMjU5OCkAX05EREVTSEFSRUlORk86VHQo
MjgsMjYwNik9czQ4bFJldmlzaW9uOigyNSwxMyksMCwzMjtscHN6U2hhcmVOYW1lOigyNSw5
NiksMzIsMzI7bFNoYXJlVHlwZTooMjUsMTMpLDY0LDMyO2xwc3pBcHBUb3BpY0xpc3Q6KDI1
LDk2KSw5NiwzMjtmU2hhcmVkRmxhZzooMjUsMTMpLDEyOCwzMjtmU2VydmljZTooMjUsMTMp
LDE2MCwzMjtmU3RhcnRBcHBGbGFnOigyNSwxMyksMTkyLDMyO25DbWRTaG93OigyNSwxMyks
MjI0LDMyO3FNb2RpZnlJZDooMiwzNSksMjU2LDY0O2NOdW1JdGVtczooMjUsMTMpLDMyMCwz
MjtscHN6SXRlbUxpc3Q6KDI1LDk2KSwzNTIsMzI7X19hczo6KDI4LDI2MDcpPSMjKDI4LDI2
MDgpPSYoMjgsMjYwNik7OlJDMTRfTkRERVNIQVJFSU5GTzsyQS47X05EREVTSEFSRUlORk86
OigyOCwyNjA5KT0jIygyOCwyNjEwKT0qKDI4LDI2MDYpOzpSQzE0X05EREVTSEFSRUlORk87
MkEuKDI4LDI2MTEpPSMjKDI4LDI2MTApOzo7MkEuOzsATkRERVNIQVJFSU5GTzp0KDI4LDI2
MTIpPSgyOCwyNjA2KQBfTkVUUkVTT1VSQ0U6VHQoMjgsMjYxMyk9czMyZHdTY29wZTooMjUs
MTQpLDAsMzI7ZHdUeXBlOigyNSwxNCksMzIsMzI7ZHdEaXNwbGF5VHlwZTooMjUsMTQpLDY0
LDMyO2R3VXNhZ2U6KDI1LDE0KSw5NiwzMjtscExvY2FsTmFtZTooMjUsOTYpLDEyOCwzMjts
cFJlbW90ZU5hbWU6KDI1LDk2KSwxNjAsMzI7bHBDb21tZW50OigyNSw5NiksMTkyLDMyO2xw
UHJvdmlkZXI6KDI1LDk2KSwyMjQsMzI7X19hczo6KDI4LDI2MTQpPSMjKDI4LDI2MTUpPSYo
MjgsMjYxMyk7OlJDMTJfTkVUUkVTT1VSQ0U7MkEuO19ORVRSRVNPVVJDRTo6KDI4LDI2MTYp
PSMjKDI4LDI2MTcpPSooMjgsMjYxMyk7OlJDMTJfTkVUUkVTT1VSQ0U7MkEuKDI4LDI2MTgp
PSMjKDI4LDI2MTcpOzo7MkEuOzsATkVUUkVTT1VSQ0U6dCgyOCwyNjE5KT0oMjgsMjYxMykA
TFBORVRSRVNPVVJDRTp0KDI4LDI2MjApPSgyOCwyNjE3KQB0YWdORVdDUExJTkZPOlR0KDI4
LDI2MjEpPXMyNDRkd1NpemU6KDI1LDE0KSwwLDMyO2R3RmxhZ3M6KDI1LDE0KSwzMiwzMjtk
d0hlbHBDb250ZXh0OigyNSwxNCksNjQsMzI7bERhdGE6KDI1LDEzKSw5NiwzMjtoSWNvbjoo
MjUsNDEpLDEyOCwzMjtzek5hbWU6KDI4LDM4OCksMTYwLDI1NjtzekluZm86KDI4LDI2MjIp
PWFyKDAsMSk7MDs2MzsoMCwyKSw0MTYsNTEyO3N6SGVscEZpbGU6KDI4LDE5MTYpLDkyOCwx
MDI0O19fYXM6OigyOCwyNjIzKT0jIygyOCwyNjI0KT0mKDI4LDI2MjEpOzpSQzEzdGFnTkVX
Q1BMSU5GTzsyQS47dGFnTkVXQ1BMSU5GTzo6KDI4LDI2MjUpPSMjKDI4LDI2MjYpPSooMjgs
MjYyMSk7OlJDMTN0YWdORVdDUExJTkZPOzJBLigyOCwyNjI3KT0jIygyOCwyNjI2KTs6OzJB
Ljs7AE5FV0NQTElORk86dCgyOCwyNjI4KT0oMjgsMjYyMSkAdGFnTkVXVEVYVE1FVFJJQzpU
dCgyOCwyNjI5KT1zNzJ0bUhlaWdodDooMjUsMTMpLDAsMzI7dG1Bc2NlbnQ6KDI1LDEzKSwz
MiwzMjt0bURlc2NlbnQ6KDI1LDEzKSw2NCwzMjt0bUludGVybmFsTGVhZGluZzooMjUsMTMp
LDk2LDMyO3RtRXh0ZXJuYWxMZWFkaW5nOigyNSwxMyksMTI4LDMyO3RtQXZlQ2hhcldpZHRo
OigyNSwxMyksMTYwLDMyO3RtTWF4Q2hhcldpZHRoOigyNSwxMyksMTkyLDMyO3RtV2VpZ2h0
OigyNSwxMyksMjI0LDMyO3RtT3Zlcmhhbmc6KDI1LDEzKSwyNTYsMzI7dG1EaWdpdGl6ZWRB
c3BlY3RYOigyNSwxMyksMjg4LDMyO3RtRGlnaXRpemVkQXNwZWN0WTooMjUsMTMpLDMyMCwz
Mjt0bUZpcnN0Q2hhcjooMjUsMTQ4KSwzNTIsODt0bUxhc3RDaGFyOigyNSwxNDgpLDM2MCw4
O3RtRGVmYXVsdENoYXI6KDI1LDE0OCksMzY4LDg7dG1CcmVha0NoYXI6KDI1LDE0OCksMzc2
LDg7dG1JdGFsaWM6KDI1LDUpLDM4NCw4O3RtVW5kZXJsaW5lZDooMjUsNSksMzkyLDg7dG1T
dHJ1Y2tPdXQ6KDI1LDUpLDQwMCw4O3RtUGl0Y2hBbmRGYW1pbHk6KDI1LDUpLDQwOCw4O3Rt
Q2hhclNldDooMjUsNSksNDE2LDg7bnRtRmxhZ3M6KDI1LDE0KSw0NDgsMzI7bnRtU2l6ZUVN
OigyNSwxNTApLDQ4MCwzMjtudG1DZWxsSGVpZ2h0OigyNSwxNTApLDUxMiwzMjtudG1BdmdX
aWR0aDooMjUsMTUwKSw1NDQsMzI7X19hczo6KDI4LDI2MzApPSMjKDI4LDI2MzEpPSYoMjgs
MjYyOSk7OlJDMTZ0YWdORVdURVhUTUVUUklDOzJBLjt0YWdORVdURVhUTUVUUklDOjooMjgs
MjYzMik9IyMoMjgsMjYzMyk9KigyOCwyNjI5KTs6UkMxNnRhZ05FV1RFWFRNRVRSSUM7MkEu
KDI4LDI2MzQpPSMjKDI4LDI2MzMpOzo7MkEuOzsATkVXVEVYVE1FVFJJQzp0KDI4LDI2MzUp
PSgyOCwyNjI5KQB0YWdORVdURVhUTUVUUklDRVg6VHQoMjgsMjYzNik9czk2bnRtZW50bToo
MjgsMjYzNSksMCw1NzY7bnRtZUZvbnRTaWduYXR1cmU6KDI4LDQxNyksNTc2LDE5MjtfX2Fz
OjooMjgsMjYzNyk9IyMoMjgsMjYzOCk9JigyOCwyNjM2KTs6UkMxOHRhZ05FV1RFWFRNRVRS
SUNFWDsyQS47dGFnTkVXVEVYVE1FVFJJQ0VYOjooMjgsMjYzOSk9IyMoMjgsMjY0MCk9Kigy
OCwyNjM2KTs6UkMxOHRhZ05FV1RFWFRNRVRSSUNFWDsyQS4oMjgsMjY0MSk9IyMoMjgsMjY0
MCk7OjsyQS47OwBORVdURVhUTUVUUklDRVg6dCgyOCwyNjQyKT0oMjgsMjYzNikAdGFnTk1f
TElTVFZJRVc6VHQoMjgsMjY0Myk9czQ0aGRyOigyOCwxNzUxKSwwLDk2O2lJdGVtOigwLDEp
LDk2LDMyO2lTdWJJdGVtOigwLDEpLDEyOCwzMjt1TmV3U3RhdGU6KDI1LDE1MCksMTYwLDMy
O3VPbGRTdGF0ZTooMjUsMTUwKSwxOTIsMzI7dUNoYW5nZWQ6KDI1LDE1MCksMjI0LDMyO3B0
QWN0aW9uOigyOCwzMDkpLDI1Niw2NDtsUGFyYW06KDI1LDcwKSwzMjAsMzI7X19hczo6KDI4
LDI2NDQpPSMjKDI4LDI2NDUpPSYoMjgsMjY0Myk7OlJDMTR0YWdOTV9MSVNUVklFVzsyQS47
dGFnTk1fTElTVFZJRVc6OigyOCwyNjQ2KT0jIygyOCwyNjQ3KT0qKDI4LDI2NDMpOzpSQzE0
dGFnTk1fTElTVFZJRVc7MkEuKDI4LDI2NDgpPSMjKDI4LDI2NDcpOzo7MkEuOzsATk1fTElT
VFZJRVc6dCgyOCwyNjQ5KT0oMjgsMjY0MykASFRSRUVJVEVNOnQoMjgsMjY1MCk9KDI4LDI2
NTEpPSooMjgsMjY1Mik9eHNfVFJFRUlURU06AF9UVl9JVEVNOlR0KDI4LDI2NTMpPXM0MG1h
c2s6KDI1LDE1MCksMCwzMjtoSXRlbTooMjgsMjY1MCksMzIsMzI7c3RhdGU6KDI1LDE1MCks
NjQsMzI7c3RhdGVNYXNrOigyNSwxNTApLDk2LDMyO3BzelRleHQ6KDI1LDk2KSwxMjgsMzI7
Y2NoVGV4dE1heDooMCwxKSwxNjAsMzI7aUltYWdlOigwLDEpLDE5MiwzMjtpU2VsZWN0ZWRJ
bWFnZTooMCwxKSwyMjQsMzI7Y0NoaWxkcmVuOigwLDEpLDI1NiwzMjtsUGFyYW06KDI1LDcw
KSwyODgsMzI7X19hczo6KDI4LDI2NTQpPSMjKDI4LDI2NTUpPSYoMjgsMjY1Myk7OlJDOF9U
Vl9JVEVNOzJBLjtfVFZfSVRFTTo6KDI4LDI2NTYpPSMjKDI4LDI2NTcpPSooMjgsMjY1Myk7
OlJDOF9UVl9JVEVNOzJBLigyOCwyNjU4KT0jIygyOCwyNjU3KTs6OzJBLjs7AFRWX0lURU06
dCgyOCwyNjU5KT0oMjgsMjY1MykATFBUVl9JVEVNOnQoMjgsMjY2MCk9KDI4LDI2NTcpAF9O
TV9UUkVFVklFVzpUdCgyOCwyNjYxKT1zMTA0aGRyOigyOCwxNzUxKSwwLDk2O2FjdGlvbjoo
MjUsMTUwKSw5NiwzMjtpdGVtT2xkOigyOCwyNjU5KSwxMjgsMzIwO2l0ZW1OZXc6KDI4LDI2
NTkpLDQ0OCwzMjA7cHREcmFnOigyOCwzMDkpLDc2OCw2NDtfX2FzOjooMjgsMjY2Mik9IyMo
MjgsMjY2Myk9JigyOCwyNjYxKTs6UkMxMl9OTV9UUkVFVklFVzsyQS47X05NX1RSRUVWSUVX
OjooMjgsMjY2NCk9IyMoMjgsMjY2NSk9KigyOCwyNjYxKTs6UkMxMl9OTV9UUkVFVklFVzsy
QS4oMjgsMjY2Nik9IyMoMjgsMjY2NSk7OjsyQS47OwBOTV9UUkVFVklFVzp0KDI4LDI2Njcp
PSgyOCwyNjYxKQBMUE5NX1RSRUVWSUVXOnQoMjgsMjY2OCk9KDI4LDI2NjkpPSooMjgsMjY2
NykAX05NX1VQRE9XTjpUdCgyOCwyNjcwKT1zMjBoZHI6KDI4LDE3NTEpLDAsOTY7aVBvczoo
MCwxKSw5NiwzMjtpRGVsdGE6KDAsMSksMTI4LDMyO19fYXM6OigyOCwyNjcxKT0jIygyOCwy
NjcyKT0mKDI4LDI2NzApOzpSQzEwX05NX1VQRE9XTjsyQS47X05NX1VQRE9XTjo6KDI4LDI2
NzMpPSMjKDI4LDI2NzQpPSooMjgsMjY3MCk7OlJDMTBfTk1fVVBET1dOOzJBLigyOCwyNjc1
KT0jIygyOCwyNjc0KTs6OzJBLjs7AE5NX1VQRE9XTlc6dCgyOCwyNjc2KT0oMjgsMjY3MCkA
dGFnTk9OQ0xJRU5UTUVUUklDUzpUdCgyOCwyNjc3KT1zMzQwY2JTaXplOigyNSwxNTApLDAs
MzI7aUJvcmRlcldpZHRoOigwLDEpLDMyLDMyO2lTY3JvbGxXaWR0aDooMCwxKSw2NCwzMjtp
U2Nyb2xsSGVpZ2h0OigwLDEpLDk2LDMyO2lDYXB0aW9uV2lkdGg6KDAsMSksMTI4LDMyO2lD
YXB0aW9uSGVpZ2h0OigwLDEpLDE2MCwzMjtsZkNhcHRpb25Gb250OigyOCw0NTYpLDE5Miw0
ODA7aVNtQ2FwdGlvbldpZHRoOigwLDEpLDY3MiwzMjtpU21DYXB0aW9uSGVpZ2h0OigwLDEp
LDcwNCwzMjtsZlNtQ2FwdGlvbkZvbnQ6KDI4LDQ1NiksNzM2LDQ4MDtpTWVudVdpZHRoOigw
LDEpLDEyMTYsMzI7aU1lbnVIZWlnaHQ6KDAsMSksMTI0OCwzMjtsZk1lbnVGb250OigyOCw0
NTYpLDEyODAsNDgwO2xmU3RhdHVzRm9udDooMjgsNDU2KSwxNzYwLDQ4MDtsZk1lc3NhZ2VG
b250OigyOCw0NTYpLDIyNDAsNDgwO19fYXM6OigyOCwyNjc4KT0jIygyOCwyNjc5KT0mKDI4
LDI2NzcpOzpSQzE5dGFnTk9OQ0xJRU5UTUVUUklDUzsyQS47dGFnTk9OQ0xJRU5UTUVUUklD
Uzo6KDI4LDI2ODApPSMjKDI4LDI2ODEpPSooMjgsMjY3Nyk7OlJDMTl0YWdOT05DTElFTlRN
RVRSSUNTOzJBLigyOCwyNjgyKT0jIygyOCwyNjgxKTs6OzJBLjs7AE5PTkNMSUVOVE1FVFJJ
Q1M6dCgyOCwyNjgzKT0oMjgsMjY3NykATFBOT05DTElFTlRNRVRSSUNTOnQoMjgsMjY4NCk9
KDI4LDI2ODEpAF9TRVJWSUNFX0FERFJFU1M6VHQoMjgsMjY4NSk9czI0ZHdBZGRyZXNzVHlw
ZTooMjUsMTQpLDAsMzI7ZHdBZGRyZXNzRmxhZ3M6KDI1LDE0KSwzMiwzMjtkd0FkZHJlc3NM
ZW5ndGg6KDI1LDE0KSw2NCwzMjtkd1ByaW5jaXBhbExlbmd0aDooMjUsMTQpLDk2LDMyO2xw
QWRkcmVzczooMjUsNzQpLDEyOCwzMjtscFByaW5jaXBhbDooMjUsNzQpLDE2MCwzMjtfX2Fz
OjooMjgsMjY4Nik9IyMoMjgsMjY4Nyk9JigyOCwyNjg1KTs6UkMxNl9TRVJWSUNFX0FERFJF
U1M7MkEuO19TRVJWSUNFX0FERFJFU1M6OigyOCwyNjg4KT0jIygyOCwyNjg5KT0qKDI4LDI2
ODUpOzpSQzE2X1NFUlZJQ0VfQUREUkVTUzsyQS4oMjgsMjY5MCk9IyMoMjgsMjY4OSk7Ojsy
QS47OwBTRVJWSUNFX0FERFJFU1M6dCgyOCwyNjkxKT0oMjgsMjY4NSkAX1NFUlZJQ0VfQURE
UkVTU0VTOlR0KDI4LDI2OTIpPXMyOGR3QWRkcmVzc0NvdW50OigyNSwxNCksMCwzMjtBZGRy
ZXNzZXM6KDI4LDI2OTMpPWFyKDAsMSk7MDswOygyOCwyNjg1KSwzMiwxOTI7X19hczo6KDI4
LDI2OTQpPSMjKDI4LDI2OTUpPSYoMjgsMjY5Mik7OlJDMThfU0VSVklDRV9BRERSRVNTRVM7
MkEuO19TRVJWSUNFX0FERFJFU1NFUzo6KDI4LDI2OTYpPSMjKDI4LDI2OTcpPSooMjgsMjY5
Mik7OlJDMThfU0VSVklDRV9BRERSRVNTRVM7MkEuKDI4LDI2OTgpPSMjKDI4LDI2OTcpOzo7
MkEuOzsAU0VSVklDRV9BRERSRVNTRVM6dCgyOCwyNjk5KT0oMjgsMjY5MikATFBTRVJWSUNF
X0FERFJFU1NFUzp0KDI4LDI3MDApPSgyOCwyNjk3KQBfR1VJRDpUdCgyOCwyNzAxKT1zMTZE
YXRhMTooMCw1KSwwLDMyO0RhdGEyOigwLDkpLDMyLDE2O0RhdGEzOigwLDkpLDQ4LDE2O0Rh
dGE0OigyOCwyNzAyKT1hcigwLDEpOzA7NzsoMCwxMSksNjQsNjQ7X19hczo6KDI4LDI3MDMp
PSMjKDI4LDI3MDQpPSYoMjgsMjcwMSk7OlJDNV9HVUlEOzJBLjtfR1VJRDo6KDI4LDI3MDUp
PSMjKDI4LDI3MDYpPSooMjgsMjcwMSk7OlJDNV9HVUlEOzJBLigyOCwyNzA3KT0jIygyOCwy
NzA2KTs6OzJBLjs7AEdVSUQ6dCgyOCwyNzA4KT0oMjgsMjcwMSkATFBHVUlEOnQoMjgsMjcw
OSk9KDI4LDI3MDYpAENMU0lEOnQoMjgsMjcxMCk9KDI4LDI3MDgpAExQQ0xTSUQ6dCgyOCwy
NzExKT0oMjgsMjcxMik9KigyOCwyNzA4KQBfU0VSVklDRV9JTkZPOlR0KDI4LDI3MTMpPXM0
NGxwU2VydmljZVR5cGU6KDI4LDI3MDkpLDAsMzI7bHBTZXJ2aWNlTmFtZTooMjUsOTYpLDMy
LDMyO2xwQ29tbWVudDooMjUsOTYpLDY0LDMyO2xwTG9jYWxlOigyNSw5NiksOTYsMzI7ZHdE
aXNwbGF5SGludDooMjUsMTQpLDEyOCwzMjtkd1ZlcnNpb246KDI1LDE0KSwxNjAsMzI7ZHdU
aW1lOigyNSwxNCksMTkyLDMyO2xwTWFjaGluZU5hbWU6KDI1LDk2KSwyMjQsMzI7bHBTZXJ2
aWNlQWRkcmVzczooMjgsMjcwMCksMjU2LDMyO1NlcnZpY2VTcGVjaWZpY0luZm86KDI4LDI0
OCksMjg4LDY0O19fYXM6OigyOCwyNzE0KT0jIygyOCwyNzE1KT0mKDI4LDI3MTMpOzpSQzEz
X1NFUlZJQ0VfSU5GTzsyQS47X1NFUlZJQ0VfSU5GTzo6KDI4LDI3MTYpPSMjKDI4LDI3MTcp
PSooMjgsMjcxMyk7OlJDMTNfU0VSVklDRV9JTkZPOzJBLigyOCwyNzE4KT0jIygyOCwyNzE3
KTs6OzJBLjs7AFNFUlZJQ0VfSU5GTzp0KDI4LDI3MTkpPSgyOCwyNzEzKQBfTlNfU0VSVklD
RV9JTkZPOlR0KDI4LDI3MjApPXM0OGR3TmFtZVNwYWNlOigyNSwxNCksMCwzMjtTZXJ2aWNl
SW5mbzooMjgsMjcxOSksMzIsMzUyO19fYXM6OigyOCwyNzIxKT0jIygyOCwyNzIyKT0mKDI4
LDI3MjApOzpSQzE2X05TX1NFUlZJQ0VfSU5GTzsyQS47X05TX1NFUlZJQ0VfSU5GTzo6KDI4
LDI3MjMpPSMjKDI4LDI3MjQpPSooMjgsMjcyMCk7OlJDMTZfTlNfU0VSVklDRV9JTkZPOzJB
LigyOCwyNzI1KT0jIygyOCwyNzI0KTs6OzJBLjs7AE5TX1NFUlZJQ0VfSU5GTzp0KDI4LDI3
MjYpPSgyOCwyNzIwKQBfbnVtYmVyZm10OlR0KDI4LDI3MjcpPXMyNE51bURpZ2l0czooMjUs
MTUwKSwwLDMyO0xlYWRpbmdaZXJvOigyNSwxNTApLDMyLDMyO0dyb3VwaW5nOigyNSwxNTAp
LDY0LDMyO2xwRGVjaW1hbFNlcDooMjUsOTYpLDk2LDMyO2xwVGhvdXNhbmRTZXA6KDI1LDk2
KSwxMjgsMzI7TmVnYXRpdmVPcmRlcjooMjUsMTUwKSwxNjAsMzI7X19hczo6KDI4LDI3Mjgp
PSMjKDI4LDI3MjkpPSYoMjgsMjcyNyk7OlJDMTBfbnVtYmVyZm10OzJBLjtfbnVtYmVyZm10
OjooMjgsMjczMCk9IyMoMjgsMjczMSk9KigyOCwyNzI3KTs6UkMxMF9udW1iZXJmbXQ7MkEu
KDI4LDI3MzIpPSMjKDI4LDI3MzEpOzo7MkEuOzsATlVNQkVSRk1UOnQoMjgsMjczMyk9KDI4
LDI3MjcpAF9PRlNUUlVDVDpUdCgyOCwyNzM0KT1zMTM2Y0J5dGVzOigyNSw1KSwwLDg7ZkZp
eGVkRGlzazooMjUsNSksOCw4O25FcnJDb2RlOigyNSwxNTMpLDE2LDE2O1Jlc2VydmVkMToo
MjUsMTUzKSwzMiwxNjtSZXNlcnZlZDI6KDI1LDE1MyksNDgsMTY7c3pQYXRoTmFtZTooMjgs
MTkxNiksNjQsMTAyNDtfX2FzOjooMjgsMjczNSk9IyMoMjgsMjczNik9JigyOCwyNzM0KTs6
UkM5X09GU1RSVUNUOzJBLjtfT0ZTVFJVQ1Q6OigyOCwyNzM3KT0jIygyOCwyNzM4KT0qKDI4
LDI3MzQpOzpSQzlfT0ZTVFJVQ1Q7MkEuKDI4LDI3MzkpPSMjKDI4LDI3MzgpOzo7MkEuOzsA
T0ZTVFJVQ1Q6dCgyOCwyNzQwKT0oMjgsMjczNCkATFBPRlNUUlVDVDp0KDI4LDI3NDEpPSgy
OCwyNzM4KQB0YWdPRk5BOlR0KDI4LDI3NDIpPXM3NmxTdHJ1Y3RTaXplOigyNSwxNCksMCwz
Mjtod25kT3duZXI6KDI1LDYxKSwzMiwzMjtoSW5zdGFuY2U6KDI1LDQzKSw2NCwzMjtscHN0
ckZpbHRlcjooMjUsODEpLDk2LDMyO2xwc3RyQ3VzdG9tRmlsdGVyOigyNSw5NCksMTI4LDMy
O25NYXhDdXN0RmlsdGVyOigyNSwxNCksMTYwLDMyO25GaWx0ZXJJbmRleDooMjUsMTQpLDE5
MiwzMjtscHN0ckZpbGU6KDI1LDk0KSwyMjQsMzI7bk1heEZpbGU6KDI1LDE0KSwyNTYsMzI7
bHBzdHJGaWxlVGl0bGU6KDI1LDk0KSwyODgsMzI7bk1heEZpbGVUaXRsZTooMjUsMTQpLDMy
MCwzMjtscHN0ckluaXRpYWxEaXI6KDI1LDgxKSwzNTIsMzI7bHBzdHJUaXRsZTooMjUsODEp
LDM4NCwzMjtGbGFnczooMjUsMTQpLDQxNiwzMjtuRmlsZU9mZnNldDooMjUsMTUzKSw0NDgs
MTY7bkZpbGVFeHRlbnNpb246KDI1LDE1MyksNDY0LDE2O2xwc3RyRGVmRXh0OigyNSw4MSks
NDgwLDMyO2xDdXN0RGF0YTooMjUsMTQpLDUxMiwzMjtscGZuSG9vazooMjUsMTg4KSw1NDQs
MzI7bHBUZW1wbGF0ZU5hbWU6KDI1LDgxKSw1NzYsMzI7X19hczo6KDI4LDI3NDMpPSMjKDI4
LDI3NDQpPSYoMjgsMjc0Mik7OlJDN3RhZ09GTkE7MkEuO3RhZ09GTkE6OigyOCwyNzQ1KT0j
IygyOCwyNzQ2KT0qKDI4LDI3NDIpOzpSQzd0YWdPRk5BOzJBLigyOCwyNzQ3KT0jIygyOCwy
NzQ2KTs6OzJBLjs7AE9QRU5GSUxFTkFNRUE6dCgyOCwyNzQ4KT0oMjgsMjc0MikATFBPUEVO
RklMRU5BTUVBOnQoMjgsMjc0OSk9KDI4LDI3NDYpAHRhZ09GTlc6VHQoMjgsMjc1MCk9czc2
bFN0cnVjdFNpemU6KDI1LDE0KSwwLDMyO2h3bmRPd25lcjooMjUsNjEpLDMyLDMyO2hJbnN0
YW5jZTooMjUsNDMpLDY0LDMyO2xwc3RyRmlsdGVyOigyNSw4NiksOTYsMzI7bHBzdHJDdXN0
b21GaWx0ZXI6KDI1LDEwNCksMTI4LDMyO25NYXhDdXN0RmlsdGVyOigyNSwxNCksMTYwLDMy
O25GaWx0ZXJJbmRleDooMjUsMTQpLDE5MiwzMjtscHN0ckZpbGU6KDI1LDEwNCksMjI0LDMy
O25NYXhGaWxlOigyNSwxNCksMjU2LDMyO2xwc3RyRmlsZVRpdGxlOigyNSwxMDQpLDI4OCwz
MjtuTWF4RmlsZVRpdGxlOigyNSwxNCksMzIwLDMyO2xwc3RySW5pdGlhbERpcjooMjUsODYp
LDM1MiwzMjtscHN0clRpdGxlOigyNSw4NiksMzg0LDMyO0ZsYWdzOigyNSwxNCksNDE2LDMy
O25GaWxlT2Zmc2V0OigyNSwxNTMpLDQ0OCwxNjtuRmlsZUV4dGVuc2lvbjooMjUsMTUzKSw0
NjQsMTY7bHBzdHJEZWZFeHQ6KDI1LDg2KSw0ODAsMzI7bEN1c3REYXRhOigyNSwxNCksNTEy
LDMyO2xwZm5Ib29rOigyNSwxODgpLDU0NCwzMjtscFRlbXBsYXRlTmFtZTooMjUsODYpLDU3
NiwzMjtfX2FzOjooMjgsMjc1MSk9IyMoMjgsMjc1Mik9JigyOCwyNzUwKTs6UkM3dGFnT0ZO
VzsyQS47dGFnT0ZOVzo6KDI4LDI3NTMpPSMjKDI4LDI3NTQpPSooMjgsMjc1MCk7OlJDN3Rh
Z09GTlc7MkEuKDI4LDI3NTUpPSMjKDI4LDI3NTQpOzo7MkEuOzsAT1BFTkZJTEVOQU1FVzp0
KDI4LDI3NTYpPSgyOCwyNzUwKQBMUE9QRU5GSUxFTkFNRVc6dCgyOCwyNzU3KT0oMjgsMjc1
NCkAT1BFTkZJTEVOQU1FOnQoMjgsMjc1OCk9KDI4LDI3NDgpAExQT1BFTkZJTEVOQU1FOnQo
MjgsMjc1OSk9KDI4LDI3NjApPSooMjgsMjc1OCkAX09GTk9USUZZOlR0KDI4LDI3NjEpPXMy
MGhkcjooMjgsMTc1MSksMCw5NjtscE9GTjooMjgsMjc1OSksOTYsMzI7cHN6RmlsZTooMjUs
OTYpLDEyOCwzMjtfX2FzOjooMjgsMjc2Mik9IyMoMjgsMjc2Myk9JigyOCwyNzYxKTs6UkM5
X09GTk9USUZZOzJBLjtfT0ZOT1RJRlk6OigyOCwyNzY0KT0jIygyOCwyNzY1KT0qKDI4LDI3
NjEpOzpSQzlfT0ZOT1RJRlk7MkEuKDI4LDI3NjYpPSMjKDI4LDI3NjUpOzo7MkEuOzsAT0ZO
T1RJRlk6dCgyOCwyNzY3KT0oMjgsMjc2MSkATFBPRk5PVElGWTp0KDI4LDI3NjgpPSgyOCwy
NzY1KQBfT1NWRVJTSU9OSU5GTzpUdCgyOCwyNzY5KT1zMTQ4ZHdPU1ZlcnNpb25JbmZvU2l6
ZTooMjUsMTQpLDAsMzI7ZHdNYWpvclZlcnNpb246KDI1LDE0KSwzMiwzMjtkd01pbm9yVmVy
c2lvbjooMjUsMTQpLDY0LDMyO2R3QnVpbGROdW1iZXI6KDI1LDE0KSw5NiwzMjtkd1BsYXRm
b3JtSWQ6KDI1LDE0KSwxMjgsMzI7c3pDU0RWZXJzaW9uOigyOCwxOTE2KSwxNjAsMTAyNDtf
X2FzOjooMjgsMjc3MCk9IyMoMjgsMjc3MSk9JigyOCwyNzY5KTs6UkMxNF9PU1ZFUlNJT05J
TkZPOzJBLjtfT1NWRVJTSU9OSU5GTzo6KDI4LDI3NzIpPSMjKDI4LDI3NzMpPSooMjgsMjc2
OSk7OlJDMTRfT1NWRVJTSU9OSU5GTzsyQS4oMjgsMjc3NCk9IyMoMjgsMjc3Myk7OjsyQS47
OwBPU1ZFUlNJT05JTkZPOnQoMjgsMjc3NSk9KDI4LDI3NjkpAFBPU1ZFUlNJT05JTkZPOnQo
MjgsMjc3Nik9KDI4LDI3NzMpAExQT1NWRVJTSU9OSU5GTzp0KDI4LDI3NzcpPSgyOCwyNzcz
KQB0YWdURVhUTUVUUklDOlR0KDI4LDI3NzgpPXM1NnRtSGVpZ2h0OigyNSwxMyksMCwzMjt0
bUFzY2VudDooMjUsMTMpLDMyLDMyO3RtRGVzY2VudDooMjUsMTMpLDY0LDMyO3RtSW50ZXJu
YWxMZWFkaW5nOigyNSwxMyksOTYsMzI7dG1FeHRlcm5hbExlYWRpbmc6KDI1LDEzKSwxMjgs
MzI7dG1BdmVDaGFyV2lkdGg6KDI1LDEzKSwxNjAsMzI7dG1NYXhDaGFyV2lkdGg6KDI1LDEz
KSwxOTIsMzI7dG1XZWlnaHQ6KDI1LDEzKSwyMjQsMzI7dG1PdmVyaGFuZzooMjUsMTMpLDI1
NiwzMjt0bURpZ2l0aXplZEFzcGVjdFg6KDI1LDEzKSwyODgsMzI7dG1EaWdpdGl6ZWRBc3Bl
Y3RZOigyNSwxMyksMzIwLDMyO3RtRmlyc3RDaGFyOigyNSwxNDgpLDM1Miw4O3RtTGFzdENo
YXI6KDI1LDE0OCksMzYwLDg7dG1EZWZhdWx0Q2hhcjooMjUsMTQ4KSwzNjgsODt0bUJyZWFr
Q2hhcjooMjUsMTQ4KSwzNzYsODt0bUl0YWxpYzooMjUsNSksMzg0LDg7dG1VbmRlcmxpbmVk
OigyNSw1KSwzOTIsODt0bVN0cnVja091dDooMjUsNSksNDAwLDg7dG1QaXRjaEFuZEZhbWls
eTooMjUsNSksNDA4LDg7dG1DaGFyU2V0OigyNSw1KSw0MTYsODtfX2FzOjooMjgsMjc3OSk9
IyMoMjgsMjc4MCk9JigyOCwyNzc4KTs6UkMxM3RhZ1RFWFRNRVRSSUM7MkEuO3RhZ1RFWFRN
RVRSSUM6OigyOCwyNzgxKT0jIygyOCwyNzgyKT0qKDI4LDI3NzgpOzpSQzEzdGFnVEVYVE1F
VFJJQzsyQS4oMjgsMjc4Myk9IyMoMjgsMjc4Mik7OjsyQS47OwBURVhUTUVUUklDOnQoMjgs
Mjc4NCk9KDI4LDI3NzgpAExQVEVYVE1FVFJJQzp0KDI4LDI3ODUpPSgyOCwyNzgyKQBfT1VU
TElORVRFWFRNRVRSSUM6VHQoMjgsMjc4Nik9czIxMm90bVNpemU6KDI1LDE1MCksMCwzMjtv
dG1UZXh0TWV0cmljczooMjgsMjc4NCksMzIsNDQ4O290bUZpbGxlcjooMjUsNSksNDgwLDg7
b3RtUGFub3NlTnVtYmVyOigyOCwxMjY5KSw0ODgsODA7b3RtZnNTZWxlY3Rpb246KDI1LDE1
MCksNTc2LDMyO290bWZzVHlwZTooMjUsMTUwKSw2MDgsMzI7b3Rtc0NoYXJTbG9wZVJpc2U6
KDAsMSksNjQwLDMyO290bXNDaGFyU2xvcGVSdW46KDAsMSksNjcyLDMyO290bUl0YWxpY0Fu
Z2xlOigwLDEpLDcwNCwzMjtvdG1FTVNxdWFyZTooMjUsMTUwKSw3MzYsMzI7b3RtQXNjZW50
OigwLDEpLDc2OCwzMjtvdG1EZXNjZW50OigwLDEpLDgwMCwzMjtvdG1MaW5lR2FwOigyNSwx
NTApLDgzMiwzMjtvdG1zQ2FwRW1IZWlnaHQ6KDI1LDE1MCksODY0LDMyO290bXNYSGVpZ2h0
OigyNSwxNTApLDg5NiwzMjtvdG1yY0ZvbnRCb3g6KDI4LDExMyksOTI4LDEyODtvdG1NYWNB
c2NlbnQ6KDAsMSksMTA1NiwzMjtvdG1NYWNEZXNjZW50OigwLDEpLDEwODgsMzI7b3RtTWFj
TGluZUdhcDooMjUsMTUwKSwxMTIwLDMyO290bXVzTWluaW11bVBQRU06KDI1LDE1MCksMTE1
MiwzMjtvdG1wdFN1YnNjcmlwdFNpemU6KDI4LDMwOSksMTE4NCw2NDtvdG1wdFN1YnNjcmlw
dE9mZnNldDooMjgsMzA5KSwxMjQ4LDY0O290bXB0U3VwZXJzY3JpcHRTaXplOigyOCwzMDkp
LDEzMTIsNjQ7b3RtcHRTdXBlcnNjcmlwdE9mZnNldDooMjgsMzA5KSwxMzc2LDY0O290bXNT
dHJpa2VvdXRTaXplOigyNSwxNTApLDE0NDAsMzI7b3Rtc1N0cmlrZW91dFBvc2l0aW9uOigw
LDEpLDE0NzIsMzI7b3Rtc1VuZGVyc2NvcmVTaXplOigwLDEpLDE1MDQsMzI7b3Rtc1VuZGVy
c2NvcmVQb3NpdGlvbjooMCwxKSwxNTM2LDMyO290bXBGYW1pbHlOYW1lOigyNSwxMjMpLDE1
NjgsMzI7b3RtcEZhY2VOYW1lOigyNSwxMjMpLDE2MDAsMzI7b3RtcFN0eWxlTmFtZTooMjUs
MTIzKSwxNjMyLDMyO290bXBGdWxsTmFtZTooMjUsMTIzKSwxNjY0LDMyO19fYXM6OigyOCwy
Nzg3KT0jIygyOCwyNzg4KT0mKDI4LDI3ODYpOzpSQzE4X09VVExJTkVURVhUTUVUUklDOzJB
LjtfT1VUTElORVRFWFRNRVRSSUM6OigyOCwyNzg5KT0jIygyOCwyNzkwKT0qKDI4LDI3ODYp
OzpSQzE4X09VVExJTkVURVhUTUVUUklDOzJBLigyOCwyNzkxKT0jIygyOCwyNzkwKTs6OzJB
Ljs7AE9VVExJTkVURVhUTUVUUklDOnQoMjgsMjc5Mik9KDI4LDI3ODYpAExQT1VUTElORVRF
WFRNRVRSSUM6dCgyOCwyNzkzKT0oMjgsMjc5MCkAX09WRVJMQVBQRUQ6VHQoMjgsMjc5NCk9
czIwSW50ZXJuYWw6KDI1LDE0KSwwLDMyO0ludGVybmFsSGlnaDooMjUsMTQpLDMyLDMyO09m
ZnNldDooMjUsMTQpLDY0LDMyO09mZnNldEhpZ2g6KDI1LDE0KSw5NiwzMjtoRXZlbnQ6KDI1
LDE5KSwxMjgsMzI7X19hczo6KDI4LDI3OTUpPSMjKDI4LDI3OTYpPSYoMjgsMjc5NCk7OlJD
MTFfT1ZFUkxBUFBFRDsyQS47X09WRVJMQVBQRUQ6OigyOCwyNzk3KT0jIygyOCwyNzk4KT0q
KDI4LDI3OTQpOzpSQzExX09WRVJMQVBQRUQ7MkEuKDI4LDI3OTkpPSMjKDI4LDI3OTgpOzo7
MkEuOzsAT1ZFUkxBUFBFRDp0KDI4LDI4MDApPSgyOCwyNzk0KQBMUE9WRVJMQVBQRUQ6dCgy
OCwyODAxKT0oMjgsMjc5OCkAdGFnUFNEOlR0KDI4LDI4MDIpPXM4NGxTdHJ1Y3RTaXplOigy
NSwxNCksMCwzMjtod25kT3duZXI6KDI1LDYxKSwzMiwzMjtoRGV2TW9kZTooMjUsMzgpLDY0
LDMyO2hEZXZOYW1lczooMjUsMzgpLDk2LDMyO0ZsYWdzOigyNSwxNCksMTI4LDMyO3B0UGFw
ZXJTaXplOigyOCwzMDkpLDE2MCw2NDtydE1pbk1hcmdpbjooMjgsMTEzKSwyMjQsMTI4O3J0
TWFyZ2luOigyOCwxMTMpLDM1MiwxMjg7aEluc3RhbmNlOigyNSw0MyksNDgwLDMyO2xDdXN0
RGF0YTooMjUsNzApLDUxMiwzMjtscGZuUGFnZVNldHVwSG9vazooMjUsMjU1KSw1NDQsMzI7
bHBmblBhZ2VQYWludEhvb2s6KDI1LDI1NCksNTc2LDMyO2xwUGFnZVNldHVwVGVtcGxhdGVO
YW1lOigyNSw4MyksNjA4LDMyO2hQYWdlU2V0dXBUZW1wbGF0ZTooMjUsMzgpLDY0MCwzMjtf
X2FzOjooMjgsMjgwMyk9IyMoMjgsMjgwNCk9JigyOCwyODAyKTs6UkM2dGFnUFNEOzJBLjt0
YWdQU0Q6OigyOCwyODA1KT0jIygyOCwyODA2KT0qKDI4LDI4MDIpOzpSQzZ0YWdQU0Q7MkEu
KDI4LDI4MDcpPSMjKDI4LDI4MDYpOzo7MkEuOzsAUEFHRVNFVFVQRExHOnQoMjgsMjgwOCk9
KDI4LDI4MDIpAExQUEFHRVNFVFVQRExHOnQoMjgsMjgwOSk9KDI4LDI4MDYpAHRhZ1BBSU5U
U1RSVUNUOlR0KDI4LDI4MTApPXM2NGhkYzooMjUsMjgpLDAsMzI7ZkVyYXNlOigyNSwyKSwz
MiwzMjtyY1BhaW50OigyOCwxMTMpLDY0LDEyODtmUmVzdG9yZTooMjUsMiksMTkyLDMyO2ZJ
bmNVcGRhdGU6KDI1LDIpLDIyNCwzMjtyZ2JSZXNlcnZlZDooMjgsOTM0KSwyNTYsMjU2O19f
YXM6OigyOCwyODExKT0jIygyOCwyODEyKT0mKDI4LDI4MTApOzpSQzE0dGFnUEFJTlRTVFJV
Q1Q7MkEuO3RhZ1BBSU5UU1RSVUNUOjooMjgsMjgxMyk9IyMoMjgsMjgxNCk9KigyOCwyODEw
KTs6UkMxNHRhZ1BBSU5UU1RSVUNUOzJBLigyOCwyODE1KT0jIygyOCwyODE0KTs6OzJBLjs7
AFBBSU5UU1RSVUNUOnQoMjgsMjgxNik9KDI4LDI4MTApAExQUEFJTlRTVFJVQ1Q6dCgyOCwy
ODE3KT0oMjgsMjgxNCkAX3BhcmFmb3JtYXQ6VHQoMjgsMjgxOCk9czE1NmNiU2l6ZTooMjUs
MTUwKSwwLDMyO2R3TWFzazooMjUsMTQpLDMyLDMyO3dOdW1iZXJpbmc6KDI1LDE1MyksNjQs
MTY7d1Jlc2VydmVkOigyNSwxNTMpLDgwLDE2O2R4U3RhcnRJbmRlbnQ6KDI1LDEzKSw5Niwz
MjtkeFJpZ2h0SW5kZW50OigyNSwxMyksMTI4LDMyO2R4T2Zmc2V0OigyNSwxMyksMTYwLDMy
O3dBbGlnbm1lbnQ6KDI1LDE1MyksMTkyLDE2O2NUYWJDb3VudDooMjUsMTIpLDIwOCwxNjty
Z3hUYWJzOigyOCwyODE5KT1hcigwLDEpOzA7MzE7KDAsMyksMjI0LDEwMjQ7X19hczo6KDI4
LDI4MjApPSMjKDI4LDI4MjEpPSYoMjgsMjgxOCk7OlJDMTFfcGFyYWZvcm1hdDsyQS47X3Bh
cmFmb3JtYXQ6OigyOCwyODIyKT0jIygyOCwyODIzKT0qKDI4LDI4MTgpOzpSQzExX3BhcmFm
b3JtYXQ7MkEuKDI4LDI4MjQpPSMjKDI4LDI4MjMpOzo7MkEuOzsAUEFSQUZPUk1BVDp0KDI4
LDI4MjUpPSgyOCwyODE4KQBfUEVSRl9DT1VOVEVSX0JMT0NLOlR0KDI4LDI4MjYpPXM0Qnl0
ZUxlbmd0aDooMjUsMTQpLDAsMzI7X19hczo6KDI4LDI4MjcpPSMjKDI4LDI4MjgpPSYoMjgs
MjgyNik7OlJDMTlfUEVSRl9DT1VOVEVSX0JMT0NLOzJBLjtfUEVSRl9DT1VOVEVSX0JMT0NL
OjooMjgsMjgyOSk9IyMoMjgsMjgzMCk9KigyOCwyODI2KTs6UkMxOV9QRVJGX0NPVU5URVJf
QkxPQ0s7MkEuKDI4LDI4MzEpPSMjKDI4LDI4MzApOzo7MkEuOzsAUEVSRl9DT1VOVEVSX0JM
T0NLOnQoMjgsMjgzMik9KDI4LDI4MjYpAF9QRVJGX0NPVU5URVJfREVGSU5JVElPTjpUdCgy
OCwyODMzKT1zNDBCeXRlTGVuZ3RoOigyNSwxNCksMCwzMjtDb3VudGVyTmFtZVRpdGxlSW5k
ZXg6KDI1LDE0KSwzMiwzMjtDb3VudGVyTmFtZVRpdGxlOigyNSwxMDQpLDY0LDMyO0NvdW50
ZXJIZWxwVGl0bGVJbmRleDooMjUsMTQpLDk2LDMyO0NvdW50ZXJIZWxwVGl0bGU6KDI1LDEw
NCksMTI4LDMyO0RlZmF1bHRTY2FsZTooMjUsMTQpLDE2MCwzMjtEZXRhaWxMZXZlbDooMjUs
MTQpLDE5MiwzMjtDb3VudGVyVHlwZTooMjUsMTQpLDIyNCwzMjtDb3VudGVyU2l6ZTooMjUs
MTQpLDI1NiwzMjtDb3VudGVyT2Zmc2V0OigyNSwxNCksMjg4LDMyO19fYXM6OigyOCwyODM0
KT0jIygyOCwyODM1KT0mKDI4LDI4MzMpOzpSQzI0X1BFUkZfQ09VTlRFUl9ERUZJTklUSU9O
OzJBLjtfUEVSRl9DT1VOVEVSX0RFRklOSVRJT046OigyOCwyODM2KT0jIygyOCwyODM3KT0q
KDI4LDI4MzMpOzpSQzI0X1BFUkZfQ09VTlRFUl9ERUZJTklUSU9OOzJBLigyOCwyODM4KT0j
IygyOCwyODM3KTs6OzJBLjs7AFBFUkZfQ09VTlRFUl9ERUZJTklUSU9OOnQoMjgsMjgzOSk9
KDI4LDI4MzMpAF9QRVJGX0RBVEFfQkxPQ0s6VHQoMjgsMjg0MCk9czg0U2lnbmF0dXJlOigy
OCwyODQxKT1hcigwLDEpOzA7MzsoMCwyMSksMCw2NDtMaXR0bGVFbmRpYW46KDI1LDE0KSw2
NCwzMjtWZXJzaW9uOigyNSwxNCksOTYsMzI7UmV2aXNpb246KDI1LDE0KSwxMjgsMzI7VG90
YWxCeXRlTGVuZ3RoOigyNSwxNCksMTYwLDMyO0hlYWRlckxlbmd0aDooMjUsMTQpLDE5Miwz
MjtOdW1PYmplY3RUeXBlczooMjUsMTQpLDIyNCwzMjtEZWZhdWx0T2JqZWN0OigyNSwxNCks
MjU2LDMyO1N5c3RlbVRpbWU6KDI4LDIxNjApLDI4OCwxMjg7UGVyZlRpbWU6KDI4LDk2OSks
NDE2LDY0O1BlcmZGcmVxOigyOCw5NjkpLDQ4MCw2NDtQZXJmVGltZTEwMG5TZWM6KDI4LDk2
OSksNTQ0LDY0O1N5c3RlbU5hbWVMZW5ndGg6KDI1LDE0KSw2MDgsMzI7U3lzdGVtTmFtZU9m
ZnNldDooMjUsMTQpLDY0MCwzMjtfX2FzOjooMjgsMjg0Mik9IyMoMjgsMjg0Myk9JigyOCwy
ODQwKTs6UkMxNl9QRVJGX0RBVEFfQkxPQ0s7MkEuO19QRVJGX0RBVEFfQkxPQ0s6OigyOCwy
ODQ0KT0jIygyOCwyODQ1KT0qKDI4LDI4NDApOzpSQzE2X1BFUkZfREFUQV9CTE9DSzsyQS4o
MjgsMjg0Nik9IyMoMjgsMjg0NSk7OjsyQS47OwBQRVJGX0RBVEFfQkxPQ0s6dCgyOCwyODQ3
KT0oMjgsMjg0MCkAX1BFUkZfSU5TVEFOQ0VfREVGSU5JVElPTjpUdCgyOCwyODQ4KT1zMjRC
eXRlTGVuZ3RoOigyNSwxNCksMCwzMjtQYXJlbnRPYmplY3RUaXRsZUluZGV4OigyNSwxNCks
MzIsMzI7UGFyZW50T2JqZWN0SW5zdGFuY2U6KDI1LDE0KSw2NCwzMjtVbmlxdWVJRDooMjUs
MTQpLDk2LDMyO05hbWVPZmZzZXQ6KDI1LDE0KSwxMjgsMzI7TmFtZUxlbmd0aDooMjUsMTQp
LDE2MCwzMjtfX2FzOjooMjgsMjg0OSk9IyMoMjgsMjg1MCk9JigyOCwyODQ4KTs6UkMyNV9Q
RVJGX0lOU1RBTkNFX0RFRklOSVRJT047MkEuO19QRVJGX0lOU1RBTkNFX0RFRklOSVRJT046
OigyOCwyODUxKT0jIygyOCwyODUyKT0qKDI4LDI4NDgpOzpSQzI1X1BFUkZfSU5TVEFOQ0Vf
REVGSU5JVElPTjsyQS4oMjgsMjg1Myk9IyMoMjgsMjg1Mik7OjsyQS47OwBQRVJGX0lOU1RB
TkNFX0RFRklOSVRJT046dCgyOCwyODU0KT0oMjgsMjg0OCkAX1BFUkZfT0JKRUNUX1RZUEU6
VHQoMjgsMjg1NSk9czY0VG90YWxCeXRlTGVuZ3RoOigyNSwxNCksMCwzMjtEZWZpbml0aW9u
TGVuZ3RoOigyNSwxNCksMzIsMzI7SGVhZGVyTGVuZ3RoOigyNSwxNCksNjQsMzI7T2JqZWN0
TmFtZVRpdGxlSW5kZXg6KDI1LDE0KSw5NiwzMjtPYmplY3ROYW1lVGl0bGU6KDI1LDEwNCks
MTI4LDMyO09iamVjdEhlbHBUaXRsZUluZGV4OigyNSwxNCksMTYwLDMyO09iamVjdEhlbHBU
aXRsZTooMjUsMTA0KSwxOTIsMzI7RGV0YWlsTGV2ZWw6KDI1LDE0KSwyMjQsMzI7TnVtQ291
bnRlcnM6KDI1LDE0KSwyNTYsMzI7RGVmYXVsdENvdW50ZXI6KDI1LDE0KSwyODgsMzI7TnVt
SW5zdGFuY2VzOigyNSwxNCksMzIwLDMyO0NvZGVQYWdlOigyNSwxNCksMzUyLDMyO1BlcmZU
aW1lOigyOCw5NjkpLDM4NCw2NDtQZXJmRnJlcTooMjgsOTY5KSw0NDgsNjQ7X19hczo6KDI4
LDI4NTYpPSMjKDI4LDI4NTcpPSYoMjgsMjg1NSk7OlJDMTdfUEVSRl9PQkpFQ1RfVFlQRTsy
QS47X1BFUkZfT0JKRUNUX1RZUEU6OigyOCwyODU4KT0jIygyOCwyODU5KT0qKDI4LDI4NTUp
OzpSQzE3X1BFUkZfT0JKRUNUX1RZUEU7MkEuKDI4LDI4NjApPSMjKDI4LDI4NTkpOzo7MkEu
OzsAUEVSRl9PQkpFQ1RfVFlQRTp0KDI4LDI4NjEpPSgyOCwyODU1KQBfUE9MWVRFWFQ6VHQo
MjgsMjg2Mik9czQweDooMCwxKSwwLDMyO3k6KDAsMSksMzIsMzI7bjooMjUsMTUwKSw2NCwz
MjtscHN0cjooMjUsODMpLDk2LDMyO3VpRmxhZ3M6KDI1LDE1MCksMTI4LDMyO3JjbDooMjgs
MTEzKSwxNjAsMTI4O3BkeDooMjUsOTEpLDI4OCwzMjtfX2FzOjooMjgsMjg2Myk9IyMoMjgs
Mjg2NCk9JigyOCwyODYyKTs6UkM5X1BPTFlURVhUOzJBLjtfUE9MWVRFWFQ6OigyOCwyODY1
KT0jIygyOCwyODY2KT0qKDI4LDI4NjIpOzpSQzlfUE9MWVRFWFQ7MkEuKDI4LDI4NjcpPSMj
KDI4LDI4NjYpOzo7MkEuOzsAUE9MWVRFWFQ6dCgyOCwyODY4KT0oMjgsMjg2MikAX1BPUlRf
SU5GT18xOlR0KDI4LDI4NjkpPXM0cE5hbWU6KDI1LDk2KSwwLDMyO19fYXM6OigyOCwyODcw
KT0jIygyOCwyODcxKT0mKDI4LDI4NjkpOzpSQzEyX1BPUlRfSU5GT18xOzJBLjtfUE9SVF9J
TkZPXzE6OigyOCwyODcyKT0jIygyOCwyODczKT0qKDI4LDI4NjkpOzpSQzEyX1BPUlRfSU5G
T18xOzJBLigyOCwyODc0KT0jIygyOCwyODczKTs6OzJBLjs7AFBPUlRfSU5GT18xOnQoMjgs
Mjg3NSk9KDI4LDI4NjkpAF9QT1JUX0lORk9fMjpUdCgyOCwyODc2KT1zMjBwUG9ydE5hbWU6
KDI1LDk0KSwwLDMyO3BNb25pdG9yTmFtZTooMjUsOTQpLDMyLDMyO3BEZXNjcmlwdGlvbjoo
MjUsOTQpLDY0LDMyO2ZQb3J0VHlwZTooMjUsMTQpLDk2LDMyO1Jlc2VydmVkOigyNSwxNCks
MTI4LDMyO19fYXM6OigyOCwyODc3KT0jIygyOCwyODc4KT0mKDI4LDI4NzYpOzpSQzEyX1BP
UlRfSU5GT18yOzJBLjtfUE9SVF9JTkZPXzI6OigyOCwyODc5KT0jIygyOCwyODgwKT0qKDI4
LDI4NzYpOzpSQzEyX1BPUlRfSU5GT18yOzJBLigyOCwyODgxKT0jIygyOCwyODgwKTs6OzJB
Ljs7AFBPUlRfSU5GT18yOnQoMjgsMjg4Mik9KDI4LDI4NzYpAF9QUkVWRU5UX01FRElBX1JF
TU9WQUw6VHQoMjgsMjg4Myk9czFQcmV2ZW50TWVkaWFSZW1vdmFsOigyNSw0KSwwLDg7X19h
czo6KDI4LDI4ODQpPSMjKDI4LDI4ODUpPSYoMjgsMjg4Myk7OlJDMjJfUFJFVkVOVF9NRURJ
QV9SRU1PVkFMOzJBLjtfUFJFVkVOVF9NRURJQV9SRU1PVkFMOjooMjgsMjg4Nik9IyMoMjgs
Mjg4Nyk9KigyOCwyODgzKTs6UkMyMl9QUkVWRU5UX01FRElBX1JFTU9WQUw7MkEuKDI4LDI4
ODgpPSMjKDI4LDI4ODcpOzo7MkEuOzsAUFJFVkVOVF9NRURJQV9SRU1PVkFMOnQoMjgsMjg4
OSk9KDI4LDI4ODMpAHRhZ1BEOlR0KDI4LDI4OTApPXM2NmxTdHJ1Y3RTaXplOigyNSwxNCks
MCwzMjtod25kT3duZXI6KDI1LDYxKSwzMiwzMjtoRGV2TW9kZTooMjUsMTkpLDY0LDMyO2hE
ZXZOYW1lczooMjUsMTkpLDk2LDMyO2hEQzooMjUsMjgpLDEyOCwzMjtGbGFnczooMjUsMTQp
LDE2MCwzMjtuRnJvbVBhZ2U6KDI1LDE1MyksMTkyLDE2O25Ub1BhZ2U6KDI1LDE1MyksMjA4
LDE2O25NaW5QYWdlOigyNSwxNTMpLDIyNCwxNjtuTWF4UGFnZTooMjUsMTUzKSwyNDAsMTY7
bkNvcGllczooMjUsMTUzKSwyNTYsMTY7aEluc3RhbmNlOigyNSw0MyksMjcyLDMyO2xDdXN0
RGF0YTooMjUsMTQpLDMwNCwzMjtscGZuUHJpbnRIb29rOigyNSwxODkpLDMzNiwzMjtscGZu
U2V0dXBIb29rOigyNSwxOTApLDM2OCwzMjtscFByaW50VGVtcGxhdGVOYW1lOigyNSw4Myks
NDAwLDMyO2xwU2V0dXBUZW1wbGF0ZU5hbWU6KDI1LDgzKSw0MzIsMzI7aFByaW50VGVtcGxh
dGU6KDI1LDE5KSw0NjQsMzI7aFNldHVwVGVtcGxhdGU6KDI1LDE5KSw0OTYsMzI7X19hczo6
KDI4LDI4OTEpPSMjKDI4LDI4OTIpPSYoMjgsMjg5MCk7OlJDNXRhZ1BEOzJBLjt0YWdQRDo6
KDI4LDI4OTMpPSMjKDI4LDI4OTQpPSooMjgsMjg5MCk7OlJDNXRhZ1BEOzJBLigyOCwyODk1
KT0jIygyOCwyODk0KTs6OzJBLjs7AFBSSU5URExHOnQoMjgsMjg5Nik9KDI4LDI4OTApAExQ
UFJJTlRETEc6dCgyOCwyODk3KT0oMjgsMjg5NCkAX1BSSU5URVJfREVGQVVMVFM6VHQoMjgs
Mjg5OCk9czEycERhdGF0eXBlOigyNSw5NiksMCwzMjtwRGV2TW9kZTooMjgsOTQzKSwzMiwz
MjtEZXNpcmVkQWNjZXNzOigyOCwzMiksNjQsMzI7X19hczo6KDI4LDI4OTkpPSMjKDI4LDI5
MDApPSYoMjgsMjg5OCk7OlJDMTdfUFJJTlRFUl9ERUZBVUxUUzsyQS47X1BSSU5URVJfREVG
QVVMVFM6OigyOCwyOTAxKT0jIygyOCwyOTAyKT0qKDI4LDI4OTgpOzpSQzE3X1BSSU5URVJf
REVGQVVMVFM7MkEuKDI4LDI5MDMpPSMjKDI4LDI5MDIpOzo7MkEuOzsAUFJJTlRFUl9ERUZB
VUxUUzp0KDI4LDI5MDQpPSgyOCwyODk4KQBQUFJJTlRFUl9ERUZBVUxUUzp0KDI4LDI5MDUp
PSgyOCwyOTAyKQBMUFBSSU5URVJfREVGQVVMVFM6dCgyOCwyOTA2KT0oMjgsMjkwMikAUFJJ
TlRFUl9ERUZBVUxUU0E6dCgyOCwyOTA3KT0oMjgsMjkwNCkAUFBSSU5URVJfREVGQVVMVFNB
OnQoMjgsMjkwOCk9KDI4LDI5MDUpAExQUFJJTlRFUl9ERUZBVUxUU0E6dCgyOCwyOTA5KT0o
MjgsMjkwNikAX1BSSU5URVJfSU5GT18xOlR0KDI4LDI5MTApPXMxNkZsYWdzOigyNSwxNCks
MCwzMjtwRGVzY3JpcHRpb246KDI1LDk2KSwzMiwzMjtwTmFtZTooMjUsOTYpLDY0LDMyO3BD
b21tZW50OigyNSw5NiksOTYsMzI7X19hczo6KDI4LDI5MTEpPSMjKDI4LDI5MTIpPSYoMjgs
MjkxMCk7OlJDMTVfUFJJTlRFUl9JTkZPXzE7MkEuO19QUklOVEVSX0lORk9fMTo6KDI4LDI5
MTMpPSMjKDI4LDI5MTQpPSooMjgsMjkxMCk7OlJDMTVfUFJJTlRFUl9JTkZPXzE7MkEuKDI4
LDI5MTUpPSMjKDI4LDI5MTQpOzo7MkEuOzsAUFJJTlRFUl9JTkZPXzE6dCgyOCwyOTE2KT0o
MjgsMjkxMCkAUFBSSU5URVJfSU5GT18xOnQoMjgsMjkxNyk9KDI4LDI5MTQpAExQUFJJTlRF
Ul9JTkZPXzE6dCgyOCwyOTE4KT0oMjgsMjkxNCkAX1BSSU5URVJfSU5GT18yOlR0KDI4LDI5
MTkpPXM4NHBTZXJ2ZXJOYW1lOigyNSw5NiksMCwzMjtwUHJpbnRlck5hbWU6KDI1LDk2KSwz
MiwzMjtwU2hhcmVOYW1lOigyNSw5NiksNjQsMzI7cFBvcnROYW1lOigyNSw5NiksOTYsMzI7
cERyaXZlck5hbWU6KDI1LDk2KSwxMjgsMzI7cENvbW1lbnQ6KDI1LDk2KSwxNjAsMzI7cExv
Y2F0aW9uOigyNSw5NiksMTkyLDMyO3BEZXZNb2RlOigyOCw5NDMpLDIyNCwzMjtwU2VwRmls
ZTooMjUsOTYpLDI1NiwzMjtwUHJpbnRQcm9jZXNzb3I6KDI1LDk2KSwyODgsMzI7cERhdGF0
eXBlOigyNSw5NiksMzIwLDMyO3BQYXJhbWV0ZXJzOigyNSw5NiksMzUyLDMyO3BTZWN1cml0
eURlc2NyaXB0b3I6KDI4LDIxOTYpLDM4NCwzMjtBdHRyaWJ1dGVzOigyNSwxNCksNDE2LDMy
O1ByaW9yaXR5OigyNSwxNCksNDQ4LDMyO0RlZmF1bHRQcmlvcml0eTooMjUsMTQpLDQ4MCwz
MjtTdGFydFRpbWU6KDI1LDE0KSw1MTIsMzI7VW50aWxUaW1lOigyNSwxNCksNTQ0LDMyO1N0
YXR1czooMjUsMTQpLDU3NiwzMjtjSm9iczooMjUsMTQpLDYwOCwzMjtBdmVyYWdlUFBNOigy
NSwxNCksNjQwLDMyO19fYXM6OigyOCwyOTIwKT0jIygyOCwyOTIxKT0mKDI4LDI5MTkpOzpS
QzE1X1BSSU5URVJfSU5GT18yOzJBLjtfUFJJTlRFUl9JTkZPXzI6OigyOCwyOTIyKT0jIygy
OCwyOTIzKT0qKDI4LDI5MTkpOzpSQzE1X1BSSU5URVJfSU5GT18yOzJBLigyOCwyOTI0KT0j
IygyOCwyOTIzKTs6OzJBLjs7AFBSSU5URVJfSU5GT18yOnQoMjgsMjkyNSk9KDI4LDI5MTkp
AF9QUklOVEVSX0lORk9fMzpUdCgyOCwyOTI2KT1zNHBTZWN1cml0eURlc2NyaXB0b3I6KDI4
LDIxOTYpLDAsMzI7X19hczo6KDI4LDI5MjcpPSMjKDI4LDI5MjgpPSYoMjgsMjkyNik7OlJD
MTVfUFJJTlRFUl9JTkZPXzM7MkEuO19QUklOVEVSX0lORk9fMzo6KDI4LDI5MjkpPSMjKDI4
LDI5MzApPSooMjgsMjkyNik7OlJDMTVfUFJJTlRFUl9JTkZPXzM7MkEuKDI4LDI5MzEpPSMj
KDI4LDI5MzApOzo7MkEuOzsAUFJJTlRFUl9JTkZPXzM6dCgyOCwyOTMyKT0oMjgsMjkyNikA
X1BSSU5URVJfSU5GT180OlR0KDI4LDI5MzMpPXMxMnBQcmludGVyTmFtZTooMjUsOTYpLDAs
MzI7cFNlcnZlck5hbWU6KDI1LDk2KSwzMiwzMjtBdHRyaWJ1dGVzOigyNSwxNCksNjQsMzI7
X19hczo6KDI4LDI5MzQpPSMjKDI4LDI5MzUpPSYoMjgsMjkzMyk7OlJDMTVfUFJJTlRFUl9J
TkZPXzQ7MkEuO19QUklOVEVSX0lORk9fNDo6KDI4LDI5MzYpPSMjKDI4LDI5MzcpPSooMjgs
MjkzMyk7OlJDMTVfUFJJTlRFUl9JTkZPXzQ7MkEuKDI4LDI5MzgpPSMjKDI4LDI5MzcpOzo7
MkEuOzsAUFJJTlRFUl9JTkZPXzQ6dCgyOCwyOTM5KT0oMjgsMjkzMykAX1BSSU5URVJfSU5G
T181OlR0KDI4LDI5NDApPXMyMHBQcmludGVyTmFtZTooMjUsOTYpLDAsMzI7cFBvcnROYW1l
OigyNSw5NiksMzIsMzI7QXR0cmlidXRlczooMjUsMTQpLDY0LDMyO0RldmljZU5vdFNlbGVj
dGVkVGltZW91dDooMjUsMTQpLDk2LDMyO1RyYW5zbWlzc2lvblJldHJ5VGltZW91dDooMjUs
MTQpLDEyOCwzMjtfX2FzOjooMjgsMjk0MSk9IyMoMjgsMjk0Mik9JigyOCwyOTQwKTs6UkMx
NV9QUklOVEVSX0lORk9fNTsyQS47X1BSSU5URVJfSU5GT181OjooMjgsMjk0Myk9IyMoMjgs
Mjk0NCk9KigyOCwyOTQwKTs6UkMxNV9QUklOVEVSX0lORk9fNTsyQS4oMjgsMjk0NSk9IyMo
MjgsMjk0NCk7OjsyQS47OwBQUklOVEVSX0lORk9fNTp0KDI4LDI5NDYpPSgyOCwyOTQwKQBf
UFJJTlRFUl9OT1RJRllfSU5GT19EQVRBOlR0KDI4LDI5NDcpPXMyMFR5cGU6KDI1LDE1Myks
MCwxNjtGaWVsZDooMjUsMTUzKSwxNiwxNjtSZXNlcnZlZDooMjUsMTQpLDMyLDMyO0lkOigy
NSwxNCksNjQsMzI7Tm90aWZ5RGF0YTooMjgsMjk0OCk9dThhZHdEYXRhOigyOCw0MTEpLDAs
NjQ7RGF0YTooMjgsMjk0OSk9czhjYkJ1ZjooMjUsMTQpLDAsMzI7cEJ1ZjooMjUsOTgpLDMy
LDMyO19fYXM6OigyOCwyOTUwKT0jKDI4LDI5NDkpLCgyOCwyOTUxKT0mKDI4LDI5NDkpLCgy
OCwyOTUyKT0qKDI4LDI5NDkpLCgyOCwyOTUzKT0mKDI4LDI5NDkpLCgwLDIwKTs6X19hc19f
UTMyNV9QUklOVEVSX05PVElGWV9JTkZPX0RBVEE0JF8zMDQkXzMxUkNRMzI1X1BSSU5URVJf
Tk9USUZZX0lORk9fREFUQTQkXzMwNCRfMzE7MkEuOyRfMzE6OigyOCwyOTU0KT0jKDI4LDI5
NDkpLCgyOCwyOTUyKSwoMjgsMjk1MiksKDI4LDI5NTMpLCgwLDIwKTs6X19RMzI1X1BSSU5U
RVJfTk9USUZZX0lORk9fREFUQTQkXzMwNCRfMzFSQ1EzMjVfUFJJTlRFUl9OT1RJRllfSU5G
T19EQVRBNCRfMzA0JF8zMTsyQS4oMjgsMjk1NSk9IygyOCwyOTQ5KSwoMjgsMjk1MiksKDI4
LDI5NTIpLCgwLDIwKTs6X19RMzI1X1BSSU5URVJfTk9USUZZX0lORk9fREFUQTQkXzMwNCRf
MzE7MkEuOzssMCw2NDtfX2FzOjooMjgsMjk1Nik9IygyOCwyOTQ4KSwoMjgsMjk1Nyk9Jigy
OCwyOTQ4KSwoMjgsMjk1OCk9KigyOCwyOTQ4KSwoMjgsMjk1OSk9JigyOCwyOTQ4KSwoMCwy
MCk7Ol9fYXNfX1EyMjVfUFJJTlRFUl9OT1RJRllfSU5GT19EQVRBNCRfMzBSQ1EyMjVfUFJJ
TlRFUl9OT1RJRllfSU5GT19EQVRBNCRfMzA7MkEuOyRfMzA6OigyOCwyOTYwKT0jKDI4LDI5
NDgpLCgyOCwyOTU4KSwoMjgsMjk1OCksKDI4LDI5NTkpLCgwLDIwKTs6X19RMjI1X1BSSU5U
RVJfTk9USUZZX0lORk9fREFUQTQkXzMwUkNRMjI1X1BSSU5URVJfTk9USUZZX0lORk9fREFU
QTQkXzMwOzJBLigyOCwyOTYxKT0jKDI4LDI5NDgpLCgyOCwyOTU4KSwoMjgsMjk1OCksKDAs
MjApOzpfX1EyMjVfUFJJTlRFUl9OT1RJRllfSU5GT19EQVRBNCRfMzA7MkEuOzssOTYsNjQ7
X19hczo6KDI4LDI5NjIpPSMjKDI4LDI5NjMpPSYoMjgsMjk0Nyk7OlJDMjVfUFJJTlRFUl9O
T1RJRllfSU5GT19EQVRBOzJBLjtfUFJJTlRFUl9OT1RJRllfSU5GT19EQVRBOjooMjgsMjk2
NCk9IyMoMjgsMjk2NSk9KigyOCwyOTQ3KTs6UkMyNV9QUklOVEVSX05PVElGWV9JTkZPX0RB
VEE7MkEuKDI4LDI5NjYpPSMjKDI4LDI5NjUpOzo7MkEuOzsAUFJJTlRFUl9OT1RJRllfSU5G
T19EQVRBOnQoMjgsMjk2Nyk9KDI4LDI5NDcpAF9QUklOVEVSX05PVElGWV9JTkZPOlR0KDI4
LDI5NjgpPXMzMlZlcnNpb246KDI1LDE0KSwwLDMyO0ZsYWdzOigyNSwxNCksMzIsMzI7Q291
bnQ6KDI1LDE0KSw2NCwzMjthRGF0YTooMjgsMjk2OSk9YXIoMCwxKTswOzA7KDI4LDI5NDcp
LDk2LDE2MDtfX2FzOjooMjgsMjk3MCk9IyMoMjgsMjk3MSk9JigyOCwyOTY4KTs6UkMyMF9Q
UklOVEVSX05PVElGWV9JTkZPOzJBLjtfUFJJTlRFUl9OT1RJRllfSU5GTzo6KDI4LDI5NzIp
PSMjKDI4LDI5NzMpPSooMjgsMjk2OCk7OlJDMjBfUFJJTlRFUl9OT1RJRllfSU5GTzsyQS4o
MjgsMjk3NCk9IyMoMjgsMjk3Myk7OjsyQS47OwBQUklOVEVSX05PVElGWV9JTkZPOnQoMjgs
Mjk3NSk9KDI4LDI5NjgpAF9QUklOVEVSX05PVElGWV9PUFRJT05TX1RZUEU6VHQoMjgsMjk3
Nik9czIwVHlwZTooMjUsMTUzKSwwLDE2O1Jlc2VydmVkMDooMjUsMTUzKSwxNiwxNjtSZXNl
cnZlZDE6KDI1LDE0KSwzMiwzMjtSZXNlcnZlZDI6KDI1LDE0KSw2NCwzMjtDb3VudDooMjUs
MTQpLDk2LDMyO3BGaWVsZHM6KDI1LDEzOSksMTI4LDMyO19fYXM6OigyOCwyOTc3KT0jIygy
OCwyOTc4KT0mKDI4LDI5NzYpOzpSQzI4X1BSSU5URVJfTk9USUZZX09QVElPTlNfVFlQRTsy
QS47X1BSSU5URVJfTk9USUZZX09QVElPTlNfVFlQRTo6KDI4LDI5NzkpPSMjKDI4LDI5ODAp
PSooMjgsMjk3Nik7OlJDMjhfUFJJTlRFUl9OT1RJRllfT1BUSU9OU19UWVBFOzJBLigyOCwy
OTgxKT0jIygyOCwyOTgwKTs6OzJBLjs7AFBSSU5URVJfTk9USUZZX09QVElPTlNfVFlQRTp0
KDI4LDI5ODIpPSgyOCwyOTc2KQBQUFJJTlRFUl9OT1RJRllfT1BUSU9OU19UWVBFOnQoMjgs
Mjk4Myk9KDI4LDI5ODApAF9QUklOVEVSX05PVElGWV9PUFRJT05TOlR0KDI4LDI5ODQpPXMx
NlZlcnNpb246KDI1LDE0KSwwLDMyO0ZsYWdzOigyNSwxNCksMzIsMzI7Q291bnQ6KDI1LDE0
KSw2NCwzMjtwVHlwZXM6KDI4LDI5ODMpLDk2LDMyO19fYXM6OigyOCwyOTg1KT0jIygyOCwy
OTg2KT0mKDI4LDI5ODQpOzpSQzIzX1BSSU5URVJfTk9USUZZX09QVElPTlM7MkEuO19QUklO
VEVSX05PVElGWV9PUFRJT05TOjooMjgsMjk4Nyk9IyMoMjgsMjk4OCk9KigyOCwyOTg0KTs6
UkMyM19QUklOVEVSX05PVElGWV9PUFRJT05TOzJBLigyOCwyOTg5KT0jIygyOCwyOTg4KTs6
OzJBLjs7AFBSSU5URVJfTk9USUZZX09QVElPTlM6dCgyOCwyOTkwKT0oMjgsMjk4NCkAX1BS
SU5UUFJPQ0VTU09SX0lORk9fMTpUdCgyOCwyOTkxKT1zNHBOYW1lOigyNSw5NiksMCwzMjtf
X2FzOjooMjgsMjk5Mik9IyMoMjgsMjk5Myk9JigyOCwyOTkxKTs6UkMyMl9QUklOVFBST0NF
U1NPUl9JTkZPXzE7MkEuO19QUklOVFBST0NFU1NPUl9JTkZPXzE6OigyOCwyOTk0KT0jIygy
OCwyOTk1KT0qKDI4LDI5OTEpOzpSQzIyX1BSSU5UUFJPQ0VTU09SX0lORk9fMTsyQS4oMjgs
Mjk5Nik9IyMoMjgsMjk5NSk7OjsyQS47OwBQUklOVFBST0NFU1NPUl9JTkZPXzE6dCgyOCwy
OTk3KT0oMjgsMjk5MSkAX1BSSVZJTEVHRV9TRVQ6VHQoMjgsMjk5OCk9czIwUHJpdmlsZWdl
Q291bnQ6KDI1LDE0KSwwLDMyO0NvbnRyb2w6KDI1LDE0KSwzMiwzMjtQcml2aWxlZ2U6KDI4
LDIyODQpLDY0LDk2O19fYXM6OigyOCwyOTk5KT0jIygyOCwzMDAwKT0mKDI4LDI5OTgpOzpS
QzE0X1BSSVZJTEVHRV9TRVQ7MkEuO19QUklWSUxFR0VfU0VUOjooMjgsMzAwMSk9IyMoMjgs
MzAwMik9KigyOCwyOTk4KTs6UkMxNF9QUklWSUxFR0VfU0VUOzJBLigyOCwzMDAzKT0jIygy
OCwzMDAyKTs6OzJBLjs7AFBSSVZJTEVHRV9TRVQ6dCgyOCwzMDA0KT0oMjgsMjk5OCkAUFBS
SVZJTEVHRV9TRVQ6dCgyOCwzMDA1KT0oMjgsMzAwMikATFBQUklWSUxFR0VfU0VUOnQoMjgs
MzAwNik9KDI4LDMwMDIpAF9QUk9DRVNTX0hFQVBfRU5UUlk6VHQoMjgsMzAwNyk9czMybHBE
YXRhOigyNSwxMzYpLDAsMzI7Y2JEYXRhOigyNSwxNCksMzIsMzI7Y2JPdmVyaGVhZDooMjUs
NSksNjQsODtpUmVnaW9uSW5kZXg6KDI1LDUpLDcyLDg7d0ZsYWdzOigyNSwxNTMpLDgwLDE2
O2R3Q29tbWl0dGVkU2l6ZTooMjUsMTQpLDk2LDMyO2R3VW5Db21taXR0ZWRTaXplOigyNSwx
NCksMTI4LDMyO2xwRmlyc3RCbG9jazooMjUsOTgpLDE2MCwzMjtscExhc3RCbG9jazooMjUs
OTgpLDE5MiwzMjtoTWVtOigyNSwxOSksMjI0LDMyO19fYXM6OigyOCwzMDA4KT0jIygyOCwz
MDA5KT0mKDI4LDMwMDcpOzpSQzE5X1BST0NFU1NfSEVBUF9FTlRSWTsyQS47X1BST0NFU1Nf
SEVBUF9FTlRSWTo6KDI4LDMwMTApPSMjKDI4LDMwMTEpPSooMjgsMzAwNyk7OlJDMTlfUFJP
Q0VTU19IRUFQX0VOVFJZOzJBLigyOCwzMDEyKT0jIygyOCwzMDExKTs6OzJBLjs7AFBST0NF
U1NfSEVBUEVOVFJZOnQoMjgsMzAxMyk9KDI4LDMwMDcpAExQUFJPQ0VTU19IRUFQX0VOVFJZ
OnQoMjgsMzAxNCk9KDI4LDMwMTEpAF9QUk9DRVNTX0lORk9STUFUSU9OOlR0KDI4LDMwMTUp
PXMxNmhQcm9jZXNzOigyNSwxOSksMCwzMjtoVGhyZWFkOigyNSwxOSksMzIsMzI7ZHdQcm9j
ZXNzSWQ6KDI1LDE0KSw2NCwzMjtkd1RocmVhZElkOigyNSwxNCksOTYsMzI7X19hczo6KDI4
LDMwMTYpPSMjKDI4LDMwMTcpPSYoMjgsMzAxNSk7OlJDMjBfUFJPQ0VTU19JTkZPUk1BVElP
TjsyQS47X1BST0NFU1NfSU5GT1JNQVRJT046OigyOCwzMDE4KT0jIygyOCwzMDE5KT0qKDI4
LDMwMTUpOzpSQzIwX1BST0NFU1NfSU5GT1JNQVRJT047MkEuKDI4LDMwMjApPSMjKDI4LDMw
MTkpOzo7MkEuOzsAUFJPQ0VTU19JTkZPUk1BVElPTjp0KDI4LDMwMjEpPSgyOCwzMDE1KQBM
UFBST0NFU1NfSU5GT1JNQVRJT046dCgyOCwzMDIyKT0oMjgsMzAxOSkATFBGTlBTUENBTExC
QUNLOnQoMjgsMzAyMyk9KDI4LDMwMjQpPSooMjgsMzAyNSk9ZigyNSwxNTApAF9QUk9QU0hF
RVRQQUdFOlR0KDI4LDMwMjYpPXM0MGR3U2l6ZTooMjUsMTQpLDAsMzI7ZHdGbGFnczooMjUs
MTQpLDMyLDMyO2hJbnN0YW5jZTooMjUsNDMpLDY0LDMyO3UxOigyOCwzMDI3KT11NHBzelRl
bXBsYXRlOigyNSw4MyksMCwzMjtwUmVzb3VyY2U6KDI4LDEwMDIpLDAsMzI7X19hczo6KDI4
LDMwMjgpPSMoMjgsMzAyNyksKDI4LDMwMjkpPSYoMjgsMzAyNyksKDI4LDMwMzApPSooMjgs
MzAyNyksKDI4LDMwMzEpPSYoMjgsMzAyNyksKDAsMjApOzpfX2FzX19RMjE0X1BST1BTSEVF
VFBBR0U0JF8zMlJDUTIxNF9QUk9QU0hFRVRQQUdFNCRfMzI7MkEuOyRfMzI6OigyOCwzMDMy
KT0jKDI4LDMwMjcpLCgyOCwzMDMwKSwoMjgsMzAzMCksKDI4LDMwMzEpLCgwLDIwKTs6X19R
MjE0X1BST1BTSEVFVFBBR0U0JF8zMlJDUTIxNF9QUk9QU0hFRVRQQUdFNCRfMzI7MkEuKDI4
LDMwMzMpPSMoMjgsMzAyNyksKDI4LDMwMzApLCgyOCwzMDMwKSwoMCwyMCk7Ol9fUTIxNF9Q
Uk9QU0hFRVRQQUdFNCRfMzI7MkEuOzssOTYsMzI7dTI6KDI4LDMwMzQpPXU0aEljb246KDI1
LDQxKSwwLDMyO3Bzekljb246KDI1LDgzKSwwLDMyO19fYXM6OigyOCwzMDM1KT0jKDI4LDMw
MzQpLCgyOCwzMDM2KT0mKDI4LDMwMzQpLCgyOCwzMDM3KT0qKDI4LDMwMzQpLCgyOCwzMDM4
KT0mKDI4LDMwMzQpLCgwLDIwKTs6X19hc19fUTIxNF9QUk9QU0hFRVRQQUdFNCRfMzNSQ1Ey
MTRfUFJPUFNIRUVUUEFHRTQkXzMzOzJBLjskXzMzOjooMjgsMzAzOSk9IygyOCwzMDM0KSwo
MjgsMzAzNyksKDI4LDMwMzcpLCgyOCwzMDM4KSwoMCwyMCk7Ol9fUTIxNF9QUk9QU0hFRVRQ
QUdFNCRfMzNSQ1EyMTRfUFJPUFNIRUVUUEFHRTQkXzMzOzJBLigyOCwzMDQwKT0jKDI4LDMw
MzQpLCgyOCwzMDM3KSwoMjgsMzAzNyksKDAsMjApOzpfX1EyMTRfUFJPUFNIRUVUUEFHRTQk
XzMzOzJBLjs7LDEyOCwzMjtwc3pUaXRsZTooMjUsODMpLDE2MCwzMjtwZm5EbGdQcm9jOigy
NSwxOTEpLDE5MiwzMjtsUGFyYW06KDI1LDcwKSwyMjQsMzI7cGZuQ2FsbGJhY2s6KDI4LDMw
MjMpLDI1NiwzMjtwY1JlZlBhcmVudDooMjgsMTk3NCksMjg4LDMyO19fYXM6OigyOCwzMDQx
KT0jIygyOCwzMDQyKT0mKDI4LDMwMjYpOzpSQzE0X1BST1BTSEVFVFBBR0U7MkEuO19QUk9Q
U0hFRVRQQUdFOjooMjgsMzA0Myk9IyMoMjgsMzA0NCk9KigyOCwzMDI2KTs6UkMxNF9QUk9Q
U0hFRVRQQUdFOzJBLigyOCwzMDQ1KT0jIygyOCwzMDQ0KTs6OzJBLjs7AFBST1BTSEVFVFBB
R0U6dCgyOCwzMDQ2KT0oMjgsMzAyNikATFBQUk9QU0hFRVRQQUdFOnQoMjgsMzA0Nyk9KDI4
LDMwNDQpAExQQ1BST1BTSEVFVFBBR0U6dCgyOCwzMDQ4KT0oMjgsMzA0OSk9KigyOCwzMDQ2
KQBIUFJPUFNIRUVUUEFHRTp0KDI4LDMwNTApPSgyOCwzMDUxKT0qKDI4LDMwNTIpPXhzX1BT
UDoAX1BST1BTSEVFVEhFQURFUjpUdCgyOCwzMDUzKT1zNDBkd1NpemU6KDI1LDE0KSwwLDMy
O2R3RmxhZ3M6KDI1LDE0KSwzMiwzMjtod25kUGFyZW50OigyNSw2MSksNjQsMzI7aEluc3Rh
bmNlOigyNSw0MyksOTYsMzI7dTE6KDI4LDMwNTQpPXU0aEljb246KDI1LDQxKSwwLDMyO3Bz
ekljb246KDI1LDgzKSwwLDMyO19fYXM6OigyOCwzMDU1KT0jKDI4LDMwNTQpLCgyOCwzMDU2
KT0mKDI4LDMwNTQpLCgyOCwzMDU3KT0qKDI4LDMwNTQpLCgyOCwzMDU4KT0mKDI4LDMwNTQp
LCgwLDIwKTs6X19hc19fUTIxNl9QUk9QU0hFRVRIRUFERVI0JF8zNFJDUTIxNl9QUk9QU0hF
RVRIRUFERVI0JF8zNDsyQS47JF8zNDo6KDI4LDMwNTkpPSMoMjgsMzA1NCksKDI4LDMwNTcp
LCgyOCwzMDU3KSwoMjgsMzA1OCksKDAsMjApOzpfX1EyMTZfUFJPUFNIRUVUSEVBREVSNCRf
MzRSQ1EyMTZfUFJPUFNIRUVUSEVBREVSNCRfMzQ7MkEuKDI4LDMwNjApPSMoMjgsMzA1NCks
KDI4LDMwNTcpLCgyOCwzMDU3KSwoMCwyMCk7Ol9fUTIxNl9QUk9QU0hFRVRIRUFERVI0JF8z
NDsyQS47OywxMjgsMzI7cHN6Q2FwdGlvbjooMjUsODMpLDE2MCwzMjtuUGFnZXM6KDI1LDE1
MCksMTkyLDMyO3UyOigyOCwzMDYxKT11NG5TdGFydFBhZ2U6KDI1LDE1MCksMCwzMjtwU3Rh
cnRQYWdlOigyNSw4MyksMCwzMjtfX2FzOjooMjgsMzA2Mik9IygyOCwzMDYxKSwoMjgsMzA2
Myk9JigyOCwzMDYxKSwoMjgsMzA2NCk9KigyOCwzMDYxKSwoMjgsMzA2NSk9JigyOCwzMDYx
KSwoMCwyMCk7Ol9fYXNfX1EyMTZfUFJPUFNIRUVUSEVBREVSNCRfMzVSQ1EyMTZfUFJPUFNI
RUVUSEVBREVSNCRfMzU7MkEuOyRfMzU6OigyOCwzMDY2KT0jKDI4LDMwNjEpLCgyOCwzMDY0
KSwoMjgsMzA2NCksKDI4LDMwNjUpLCgwLDIwKTs6X19RMjE2X1BST1BTSEVFVEhFQURFUjQk
XzM1UkNRMjE2X1BST1BTSEVFVEhFQURFUjQkXzM1OzJBLigyOCwzMDY3KT0jKDI4LDMwNjEp
LCgyOCwzMDY0KSwoMjgsMzA2NCksKDAsMjApOzpfX1EyMTZfUFJPUFNIRUVUSEVBREVSNCRf
MzU7MkEuOzssMjI0LDMyO3UzOigyOCwzMDY4KT11NHBwc3A6KDI4LDMwNDgpLDAsMzI7cGhw
YWdlOigyOCwzMDY5KT0qKDI4LDMwNTApLDAsMzI7X19hczo6KDI4LDMwNzApPSMoMjgsMzA2
OCksKDI4LDMwNzEpPSYoMjgsMzA2OCksKDI4LDMwNzIpPSooMjgsMzA2OCksKDI4LDMwNzMp
PSYoMjgsMzA2OCksKDAsMjApOzpfX2FzX19RMjE2X1BST1BTSEVFVEhFQURFUjQkXzM2UkNR
MjE2X1BST1BTSEVFVEhFQURFUjQkXzM2OzJBLjskXzM2OjooMjgsMzA3NCk9IygyOCwzMDY4
KSwoMjgsMzA3MiksKDI4LDMwNzIpLCgyOCwzMDczKSwoMCwyMCk7Ol9fUTIxNl9QUk9QU0hF
RVRIRUFERVI0JF8zNlJDUTIxNl9QUk9QU0hFRVRIRUFERVI0JF8zNjsyQS4oMjgsMzA3NSk9
IygyOCwzMDY4KSwoMjgsMzA3MiksKDI4LDMwNzIpLCgwLDIwKTs6X19RMjE2X1BST1BTSEVF
VEhFQURFUjQkXzM2OzJBLjs7LDI1NiwzMjtwZm5DYWxsYmFjazooMjUsMTk0KSwyODgsMzI7
X19hczo6KDI4LDMwNzYpPSMjKDI4LDMwNzcpPSYoMjgsMzA1Myk7OlJDMTZfUFJPUFNIRUVU
SEVBREVSOzJBLjtfUFJPUFNIRUVUSEVBREVSOjooMjgsMzA3OCk9IyMoMjgsMzA3OSk9Kigy
OCwzMDUzKTs6UkMxNl9QUk9QU0hFRVRIRUFERVI7MkEuKDI4LDMwODApPSMjKDI4LDMwNzkp
Ozo7MkEuOzsAUFJPUFNIRUVUSEVBREVSOnQoMjgsMzA4MSk9KDI4LDMwNTMpAExQUFJPUFNI
RUVUSEVBREVSOnQoMjgsMzA4Mik9KDI4LDMwNzkpAExQQ1BST1BTSEVFVEhFQURFUjp0KDI4
LDMwODMpPSgyOCwzMDg0KT0qKDI4LDMwODEpAExQRk5BRERQUk9QU0hFRVRQQUdFOnQoMjgs
MzA4NSk9KDI4LDMwODYpPSooMjgsMzA4Nyk9ZigyNSwyKQBMUEZOQUREUFJPUFNIRUVUUEFH
RVM6dCgyOCwzMDg4KT0oMjgsMzA4OSk9KigyOCwzMDkwKT1mKDI1LDIpAF9QUk9UT0NPTF9J
TkZPOlR0KDI4LDMwOTEpPXMzMmR3U2VydmljZUZsYWdzOigyNSwxNCksMCwzMjtpQWRkcmVz
c0ZhbWlseTooMjUsNjIpLDMyLDMyO2lNYXhTb2NrQWRkcjooMjUsNjIpLDY0LDMyO2lNaW5T
b2NrQWRkcjooMjUsNjIpLDk2LDMyO2lTb2NrZXRUeXBlOigyNSw2MiksMTI4LDMyO2lQcm90
b2NvbDooMjUsNjIpLDE2MCwzMjtkd01lc3NhZ2VTaXplOigyNSwxNCksMTkyLDMyO2xwUHJv
dG9jb2w6KDI1LDk2KSwyMjQsMzI7X19hczo6KDI4LDMwOTIpPSMjKDI4LDMwOTMpPSYoMjgs
MzA5MSk7OlJDMTRfUFJPVE9DT0xfSU5GTzsyQS47X1BST1RPQ09MX0lORk86OigyOCwzMDk0
KT0jIygyOCwzMDk1KT0qKDI4LDMwOTEpOzpSQzE0X1BST1RPQ09MX0lORk87MkEuKDI4LDMw
OTYpPSMjKDI4LDMwOTUpOzo7MkEuOzsAUFJPVE9DT0xfSU5GTzp0KDI4LDMwOTcpPSgyOCwz
MDkxKQBfUFJPVklET1JfSU5GT18xOlR0KDI4LDMwOTgpPXMxMnBOYW1lOigyNSw5NiksMCwz
MjtwRW52aXJvbm1lbnQ6KDI1LDk2KSwzMiwzMjtwRExMTmFtZTooMjUsOTYpLDY0LDMyO19f
YXM6OigyOCwzMDk5KT0jIygyOCwzMTAwKT0mKDI4LDMwOTgpOzpSQzE2X1BST1ZJRE9SX0lO
Rk9fMTsyQS47X1BST1ZJRE9SX0lORk9fMTo6KDI4LDMxMDEpPSMjKDI4LDMxMDIpPSooMjgs
MzA5OCk7OlJDMTZfUFJPVklET1JfSU5GT18xOzJBLigyOCwzMTAzKT0jIygyOCwzMTAyKTs6
OzJBLjs7AFBST1ZJRE9SX0lORk9fMTp0KDI4LDMxMDQpPSgyOCwzMDk4KQBfUFNITk9USUZZ
OlR0KDI4LDMxMDUpPXMxNmhkcjooMjgsMTc1MSksMCw5NjtsUGFyYW06KDI1LDcwKSw5Niwz
MjtfX2FzOjooMjgsMzEwNik9IyMoMjgsMzEwNyk9JigyOCwzMTA1KTs6UkMxMF9QU0hOT1RJ
Rlk7MkEuO19QU0hOT1RJRlk6OigyOCwzMTA4KT0jIygyOCwzMTA5KT0qKDI4LDMxMDUpOzpS
QzEwX1BTSE5PVElGWTsyQS4oMjgsMzExMCk9IyMoMjgsMzEwOSk7OjsyQS47OwBQU0hOT1RJ
Rlk6dCgyOCwzMTExKT0oMjgsMzEwNSkATFBQU0hOT1RJRlk6dCgyOCwzMTEyKT0oMjgsMzEw
OSkAX3B1bmN0dWF0aW9uOlR0KDI4LDMxMTMpPXM4aVNpemU6KDI1LDE1MCksMCwzMjtzelB1
bmN0dWF0aW9uOigyNSw5NCksMzIsMzI7X19hczo6KDI4LDMxMTQpPSMjKDI4LDMxMTUpPSYo
MjgsMzExMyk7OlJDMTJfcHVuY3R1YXRpb247MkEuO19wdW5jdHVhdGlvbjo6KDI4LDMxMTYp
PSMjKDI4LDMxMTcpPSooMjgsMzExMyk7OlJDMTJfcHVuY3R1YXRpb247MkEuKDI4LDMxMTgp
PSMjKDI4LDMxMTcpOzo7MkEuOzsAUFVOQ1RVQVRJT046dCgyOCwzMTE5KT0oMjgsMzExMykA
X1FVRVJZX1NFUlZJQ0VfQ09ORklHOlR0KDI4LDMxMjApPXMzNmR3U2VydmljZVR5cGU6KDI1
LDE0KSwwLDMyO2R3U3RhcnRUeXBlOigyNSwxNCksMzIsMzI7ZHdFcnJvckNvbnRyb2w6KDI1
LDE0KSw2NCwzMjtscEJpbmFyeVBhdGhOYW1lOigyNSw5NiksOTYsMzI7bHBMb2FkT3JkZXJH
cm91cDooMjUsOTYpLDEyOCwzMjtkd1RhZ0lkOigyNSwxNCksMTYwLDMyO2xwRGVwZW5kZW5j
aWVzOigyNSw5NiksMTkyLDMyO2xwU2VydmljZVN0YXJ0TmFtZTooMjUsOTYpLDIyNCwzMjts
cERpc3BsYXlOYW1lOigyNSw5NiksMjU2LDMyO19fYXM6OigyOCwzMTIxKT0jIygyOCwzMTIy
KT0mKDI4LDMxMjApOzpSQzIxX1FVRVJZX1NFUlZJQ0VfQ09ORklHOzJBLjtfUVVFUllfU0VS
VklDRV9DT05GSUc6OigyOCwzMTIzKT0jIygyOCwzMTI0KT0qKDI4LDMxMjApOzpSQzIxX1FV
RVJZX1NFUlZJQ0VfQ09ORklHOzJBLigyOCwzMTI1KT0jIygyOCwzMTI0KTs6OzJBLjs7AFFV
RVJZX1NFUlZJQ0VfQ09ORklHOnQoMjgsMzEyNik9KDI4LDMxMjApAExQUVVFUllfU0VSVklD
RV9DT05GSUc6dCgyOCwzMTI3KT0oMjgsMzEyNCkAX1FVRVJZX1NFUlZJQ0VfTE9DS19TVEFU
VVM6VHQoMjgsMzEyOCk9czEyZklzTG9ja2VkOigyNSwxNCksMCwzMjtscExvY2tPd25lcjoo
MjUsOTYpLDMyLDMyO2R3TG9ja0R1cmF0aW9uOigyNSwxNCksNjQsMzI7X19hczo6KDI4LDMx
MjkpPSMjKDI4LDMxMzApPSYoMjgsMzEyOCk7OlJDMjZfUVVFUllfU0VSVklDRV9MT0NLX1NU
QVRVUzsyQS47X1FVRVJZX1NFUlZJQ0VfTE9DS19TVEFUVVM6OigyOCwzMTMxKT0jIygyOCwz
MTMyKT0qKDI4LDMxMjgpOzpSQzI2X1FVRVJZX1NFUlZJQ0VfTE9DS19TVEFUVVM7MkEuKDI4
LDMxMzMpPSMjKDI4LDMxMzIpOzo7MkEuOzsAUVVFUllfU0VSVklDRV9MT0NLX1NUQVRVUzp0
KDI4LDMxMzQpPSgyOCwzMTI4KQBMUFFVRVJZX1NFUlZJQ0VfTE9DS19TVEFUVVM6dCgyOCwz
MTM1KT0oMjgsMzEzMikAX1JBU0FNQjpUdCgyOCwzMTM2KT1zMjhkd1NpemU6KDI1LDE0KSww
LDMyO2R3RXJyb3I6KDI1LDE0KSwzMiwzMjtzek5ldEJpb3NFcnJvcjooMjgsMzEzNyk9YXIo
MCwxKTswOzE2OygwLDIpLDY0LDEzNjtiTGFuYTooMjUsNSksMjAwLDg7X19hczo6KDI4LDMx
MzgpPSMjKDI4LDMxMzkpPSYoMjgsMzEzNik7OlJDN19SQVNBTUI7MkEuO19SQVNBTUI6Oigy
OCwzMTQwKT0jIygyOCwzMTQxKT0qKDI4LDMxMzYpOzpSQzdfUkFTQU1COzJBLigyOCwzMTQy
KT0jIygyOCwzMTQxKTs6OzJBLjs7AFJBU0FNQjp0KDI4LDMxNDMpPSgyOCwzMTM2KQBfUkFT
Q09OTjpUdCgyOCwzMTQ0KT1zNDEyZHdTaXplOigyNSwxNCksMCwzMjtocmFzY29ubjooMjUs
NTQpLDMyLDMyO3N6RW50cnlOYW1lOigyOCwzMTQ1KT1hcigwLDEpOzA7MjU2OygwLDIpLDY0
LDIwNTY7c3pEZXZpY2VUeXBlOigyOCwzMTM3KSwyMTIwLDEzNjtzekRldmljZU5hbWU6KDI4
LDMxNDYpPWFyKDAsMSk7MDsxMjg7KDAsMiksMjI1NiwxMDMyO19fYXM6OigyOCwzMTQ3KT0j
IygyOCwzMTQ4KT0mKDI4LDMxNDQpOzpSQzhfUkFTQ09OTjsyQS47X1JBU0NPTk46OigyOCwz
MTQ5KT0jIygyOCwzMTUwKT0qKDI4LDMxNDQpOzpSQzhfUkFTQ09OTjsyQS4oMjgsMzE1MSk9
IyMoMjgsMzE1MCk7OjsyQS47OwBSQVNDT05OOnQoMjgsMzE1Mik9KDI4LDMxNDQpAF9SQVND
T05OU1RBVFVTOlR0KDI4LDMxNTMpPXMxNjBkd1NpemU6KDI1LDE0KSwwLDMyO3Jhc2Nvbm5z
dGF0ZTooMjUsMTYwKSwzMiwzMjtkd0Vycm9yOigyNSwxNCksNjQsMzI7c3pEZXZpY2VUeXBl
OigyOCwzMTM3KSw5NiwxMzY7c3pEZXZpY2VOYW1lOigyOCwzMTQ2KSwyMzIsMTAzMjtfX2Fz
OjooMjgsMzE1NCk9IyMoMjgsMzE1NSk9JigyOCwzMTUzKTs6UkMxNF9SQVNDT05OU1RBVFVT
OzJBLjtfUkFTQ09OTlNUQVRVUzo6KDI4LDMxNTYpPSMjKDI4LDMxNTcpPSooMjgsMzE1Myk7
OlJDMTRfUkFTQ09OTlNUQVRVUzsyQS4oMjgsMzE1OCk9IyMoMjgsMzE1Nyk7OjsyQS47OwBS
QVNDT05OU1RBVFVTOnQoMjgsMzE1OSk9KDI4LDMxNTMpAF9SQVNESUFMRVhURU5TSU9OUzpU
dCgyOCwzMTYwKT1zMTZkd1NpemU6KDI1LDE0KSwwLDMyO2R3Zk9wdGlvbnM6KDI1LDE0KSwz
MiwzMjtod25kUGFyZW50OigyNSw2MSksNjQsMzI7cmVzZXJ2ZWQ6KDI1LDE0KSw5NiwzMjtf
X2FzOjooMjgsMzE2MSk9IyMoMjgsMzE2Mik9JigyOCwzMTYwKTs6UkMxOF9SQVNESUFMRVhU
RU5TSU9OUzsyQS47X1JBU0RJQUxFWFRFTlNJT05TOjooMjgsMzE2Myk9IyMoMjgsMzE2NCk9
KigyOCwzMTYwKTs6UkMxOF9SQVNESUFMRVhURU5TSU9OUzsyQS4oMjgsMzE2NSk9IyMoMjgs
MzE2NCk7OjsyQS47OwBSQVNESUFMRVhURU5TSU9OUzp0KDI4LDMxNjYpPSgyOCwzMTYwKQBf
UkFTRElBTFBBUkFNUzpUdCgyOCwzMTY3KT1zMTA1MmR3U2l6ZTooMjUsMTQpLDAsMzI7c3pF
bnRyeU5hbWU6KDI4LDMxNDUpLDMyLDIwNTY7c3pQaG9uZU51bWJlcjooMjgsMzE0NiksMjA4
OCwxMDMyO3N6Q2FsbGJhY2tOdW1iZXI6KDI4LDMxNDYpLDMxMjAsMTAzMjtzelVzZXJOYW1l
OigyOCwzMTQ1KSw0MTUyLDIwNTY7c3pQYXNzd29yZDooMjgsMzE0NSksNjIwOCwyMDU2O3N6
RG9tYWluOigyOCwzMTY4KT1hcigwLDEpOzA7MTU7KDAsMiksODI2NCwxMjg7X19hczo6KDI4
LDMxNjkpPSMjKDI4LDMxNzApPSYoMjgsMzE2Nyk7OlJDMTRfUkFTRElBTFBBUkFNUzsyQS47
X1JBU0RJQUxQQVJBTVM6OigyOCwzMTcxKT0jIygyOCwzMTcyKT0qKDI4LDMxNjcpOzpSQzE0
X1JBU0RJQUxQQVJBTVM7MkEuKDI4LDMxNzMpPSMjKDI4LDMxNzIpOzo7MkEuOzsAUkFTRElB
TFBBUkFNUzp0KDI4LDMxNzQpPSgyOCwzMTY3KQBfUkFTRU5UUllOQU1FOlR0KDI4LDMxNzUp
PXMyNjRkd1NpemU6KDI1LDE0KSwwLDMyO3N6RW50cnlOYW1lOigyOCwzMTQ1KSwzMiwyMDU2
O19fYXM6OigyOCwzMTc2KT0jIygyOCwzMTc3KT0mKDI4LDMxNzUpOzpSQzEzX1JBU0VOVFJZ
TkFNRTsyQS47X1JBU0VOVFJZTkFNRTo6KDI4LDMxNzgpPSMjKDI4LDMxNzkpPSooMjgsMzE3
NSk7OlJDMTNfUkFTRU5UUllOQU1FOzJBLigyOCwzMTgwKT0jIygyOCwzMTc5KTs6OzJBLjs7
AFJBU0VOVFJZTkFNRTp0KDI4LDMxODEpPSgyOCwzMTc1KQBfUkFTUFBQSVA6VHQoMjgsMzE4
Mik9czI0ZHdTaXplOigyNSwxNCksMCwzMjtkd0Vycm9yOigyNSwxNCksMzIsMzI7c3pJcEFk
ZHJlc3M6KDI4LDMxNjgpLDY0LDEyODtfX2FzOjooMjgsMzE4Myk9IyMoMjgsMzE4NCk9Jigy
OCwzMTgyKTs6UkM5X1JBU1BQUElQOzJBLjtfUkFTUFBQSVA6OigyOCwzMTg1KT0jIygyOCwz
MTg2KT0qKDI4LDMxODIpOzpSQzlfUkFTUFBQSVA7MkEuKDI4LDMxODcpPSMjKDI4LDMxODYp
Ozo7MkEuOzsAUkFTUFBQSVA6dCgyOCwzMTg4KT0oMjgsMzE4MikAX1JBU1BQUElQWDpUdCgy
OCwzMTg5KT1zMzJkd1NpemU6KDI1LDE0KSwwLDMyO2R3RXJyb3I6KDI1LDE0KSwzMiwzMjtz
eklweEFkZHJlc3M6KDI4LDMxOTApPWFyKDAsMSk7MDsyMTsoMCwyKSw2NCwxNzY7X19hczo6
KDI4LDMxOTEpPSMjKDI4LDMxOTIpPSYoMjgsMzE4OSk7OlJDMTBfUkFTUFBQSVBYOzJBLjtf
UkFTUFBQSVBYOjooMjgsMzE5Myk9IyMoMjgsMzE5NCk9KigyOCwzMTg5KTs6UkMxMF9SQVNQ
UFBJUFg7MkEuKDI4LDMxOTUpPSMjKDI4LDMxOTQpOzo7MkEuOzsAUkFTUFBQSVBYOnQoMjgs
MzE5Nik9KDI4LDMxODkpAF9SQVNQUFBOQkY6VHQoMjgsMzE5Nyk9czQ4ZHdTaXplOigyNSwx
NCksMCwzMjtkd0Vycm9yOigyNSwxNCksMzIsMzI7ZHdOZXRCaW9zRXJyb3I6KDI1LDE0KSw2
NCwzMjtzek5ldEJpb3NFcnJvcjooMjgsMzEzNyksOTYsMTM2O3N6V29ya3N0YXRpb25OYW1l
OigyOCwzMTM3KSwyMzIsMTM2O2JMYW5hOigyNSw1KSwzNjgsODtfX2FzOjooMjgsMzE5OCk9
IyMoMjgsMzE5OSk9JigyOCwzMTk3KTs6UkMxMF9SQVNQUFBOQkY7MkEuO19SQVNQUFBOQkY6
OigyOCwzMjAwKT0jIygyOCwzMjAxKT0qKDI4LDMxOTcpOzpSQzEwX1JBU1BQUE5CRjsyQS4o
MjgsMzIwMik9IyMoMjgsMzIwMSk7OjsyQS47OwBSQVNQUFBOQkY6dCgyOCwzMjAzKT0oMjgs
MzE5NykAX1JBU1RFUklaRVJfU1RBVFVTOlR0KDI4LDMyMDQpPXM2blNpemU6KDAsOCksMCwx
Njt3RmxhZ3M6KDAsOCksMTYsMTY7bkxhbmd1YWdlSUQ6KDAsOCksMzIsMTY7X19hczo6KDI4
LDMyMDUpPSMjKDI4LDMyMDYpPSYoMjgsMzIwNCk7OlJDMThfUkFTVEVSSVpFUl9TVEFUVVM7
MkEuO19SQVNURVJJWkVSX1NUQVRVUzo6KDI4LDMyMDcpPSMjKDI4LDMyMDgpPSooMjgsMzIw
NCk7OlJDMThfUkFTVEVSSVpFUl9TVEFUVVM7MkEuKDI4LDMyMDkpPSMjKDI4LDMyMDgpOzo7
MkEuOzsAUkFTVEVSSVpFUl9TVEFUVVM6dCgyOCwzMjEwKT0oMjgsMzIwNCkATFBSQVNURVJJ
WkVSX1NUQVRVUzp0KDI4LDMyMTEpPSgyOCwzMjA4KQBfUkVBU1NJR05fQkxPQ0tTOlR0KDI4
LDMyMTIpPXM4UmVzZXJ2ZWQ6KDI1LDE1MyksMCwxNjtDb3VudDooMjUsMTUzKSwxNiwxNjtC
bG9ja051bWJlcjooMjgsMzQyKSwzMiwzMjtfX2FzOjooMjgsMzIxMyk9IyMoMjgsMzIxNCk9
JigyOCwzMjEyKTs6UkMxNl9SRUFTU0lHTl9CTE9DS1M7MkEuO19SRUFTU0lHTl9CTE9DS1M6
OigyOCwzMjE1KT0jIygyOCwzMjE2KT0qKDI4LDMyMTIpOzpSQzE2X1JFQVNTSUdOX0JMT0NL
UzsyQS4oMjgsMzIxNyk9IyMoMjgsMzIxNik7OjsyQS47OwBSRUFTU0lHTl9CTE9DS1M6dCgy
OCwzMjE4KT0oMjgsMzIxMikAX1JFTU9URV9OQU1FX0lORk86VHQoMjgsMzIxOSk9czEybHBV
bml2ZXJzYWxOYW1lOigyNSw5NiksMCwzMjtscENvbm5lY3Rpb25OYW1lOigyNSw5NiksMzIs
MzI7bHBSZW1haW5pbmdQYXRoOigyNSw5NiksNjQsMzI7X19hczo6KDI4LDMyMjApPSMjKDI4
LDMyMjEpPSYoMjgsMzIxOSk7OlJDMTdfUkVNT1RFX05BTUVfSU5GTzsyQS47X1JFTU9URV9O
QU1FX0lORk86OigyOCwzMjIyKT0jIygyOCwzMjIzKT0qKDI4LDMyMTkpOzpSQzE3X1JFTU9U
RV9OQU1FX0lORk87MkEuKDI4LDMyMjQpPSMjKDI4LDMyMjMpOzo7MkEuOzsAUkVNT1RFX05B
TUVfSU5GTzp0KDI4LDMyMjUpPSgyOCwzMjE5KQBfcmVwYXN0ZXNwZWNpYWw6VHQoMjgsMzIy
Nik9czhkd0FzcGVjdDooMjUsMTQpLDAsMzI7ZHdQYXJhbTooMjUsMTQpLDMyLDMyO19fYXM6
OigyOCwzMjI3KT0jIygyOCwzMjI4KT0mKDI4LDMyMjYpOzpSQzE1X3JlcGFzdGVzcGVjaWFs
OzJBLjtfcmVwYXN0ZXNwZWNpYWw6OigyOCwzMjI5KT0jIygyOCwzMjMwKT0qKDI4LDMyMjYp
OzpSQzE1X3JlcGFzdGVzcGVjaWFsOzJBLigyOCwzMjMxKT0jIygyOCwzMjMwKTs6OzJBLjs7
AFJFUEFTVEVTUEVDSUFMOnQoMjgsMzIzMik9KDI4LDMyMjYpAF9yZXFyZXNpemU6VHQoMjgs
MzIzMyk9czI4bm1oZHI6KDI4LDE3NTEpLDAsOTY7cmM6KDI4LDExMyksOTYsMTI4O19fYXM6
OigyOCwzMjM0KT0jIygyOCwzMjM1KT0mKDI4LDMyMzMpOzpSQzEwX3JlcXJlc2l6ZTsyQS47
X3JlcXJlc2l6ZTo6KDI4LDMyMzYpPSMjKDI4LDMyMzcpPSooMjgsMzIzMyk7OlJDMTBfcmVx
cmVzaXplOzJBLigyOCwzMjM4KT0jIygyOCwzMjM3KTs6OzJBLjs7AFJFUVJFU0laRTp0KDI4
LDMyMzkpPSgyOCwzMjMzKQBfUkdOREFUQUhFQURFUjpUdCgyOCwzMjQwKT1zMzJkd1NpemU6
KDI1LDE0KSwwLDMyO2lUeXBlOigyNSwxNCksMzIsMzI7bkNvdW50OigyNSwxNCksNjQsMzI7
blJnblNpemU6KDI1LDE0KSw5NiwzMjtyY0JvdW5kOigyOCwxMTMpLDEyOCwxMjg7X19hczo6
KDI4LDMyNDEpPSMjKDI4LDMyNDIpPSYoMjgsMzI0MCk7OlJDMTRfUkdOREFUQUhFQURFUjsy
QS47X1JHTkRBVEFIRUFERVI6OigyOCwzMjQzKT0jIygyOCwzMjQ0KT0qKDI4LDMyNDApOzpS
QzE0X1JHTkRBVEFIRUFERVI7MkEuKDI4LDMyNDUpPSMjKDI4LDMyNDQpOzo7MkEuOzsAUkdO
REFUQUhFQURFUjp0KDI4LDMyNDYpPSgyOCwzMjQwKQBfUkdOREFUQTpUdCgyOCwzMjQ3KT1z
MzZyZGg6KDI4LDMyNDYpLDAsMjU2O0J1ZmZlcjooMjgsOTA5KSwyNTYsODtfX2FzOjooMjgs
MzI0OCk9IyMoMjgsMzI0OSk9JigyOCwzMjQ3KTs6UkM4X1JHTkRBVEE7MkEuO19SR05EQVRB
OjooMjgsMzI1MCk9IyMoMjgsMzI1MSk9KigyOCwzMjQ3KTs6UkM4X1JHTkRBVEE7MkEuKDI4
LDMyNTIpPSMjKDI4LDMyNTEpOzo7MkEuOzsAUkdOREFUQTp0KDI4LDMyNTMpPSgyOCwzMjQ3
KQBMUFJHTkRBVEE6dCgyOCwzMjU0KT0oMjgsMzI1MSkAdGFnU0NST0xMSU5GTzpUdCgyOCwz
MjU1KT1zMjhjYlNpemU6KDI1LDE1MCksMCwzMjtmTWFzazooMjUsMTUwKSwzMiwzMjtuTWlu
OigwLDEpLDY0LDMyO25NYXg6KDAsMSksOTYsMzI7blBhZ2U6KDI1LDE1MCksMTI4LDMyO25Q
b3M6KDAsMSksMTYwLDMyO25UcmFja1BvczooMCwxKSwxOTIsMzI7X19hczo6KDI4LDMyNTYp
PSMjKDI4LDMyNTcpPSYoMjgsMzI1NSk7OlJDMTN0YWdTQ1JPTExJTkZPOzJBLjt0YWdTQ1JP
TExJTkZPOjooMjgsMzI1OCk9IyMoMjgsMzI1OSk9KigyOCwzMjU1KTs6UkMxM3RhZ1NDUk9M
TElORk87MkEuKDI4LDMyNjApPSMjKDI4LDMyNTkpOzo7MkEuOzsAU0NST0xMSU5GTzp0KDI4
LDMyNjEpPSgyOCwzMjU1KQBMUFNDUk9MTElORk86dCgyOCwzMjYyKT0oMjgsMzI1OSkATFBD
U0NST0xMSU5GTzp0KDI4LDMyNjMpPSgyOCwzMjY0KT0qKDI4LDMyNjEpAF9TRUNVUklUWV9B
VFRSSUJVVEVTOlR0KDI4LDMyNjUpPXMxMm5MZW5ndGg6KDI1LDE0KSwwLDMyO2xwU2VjdXJp
dHlEZXNjcmlwdG9yOigyNSw5OCksMzIsMzI7YkluaGVyaXRIYW5kbGU6KDI1LDIpLDY0LDMy
O19fYXM6OigyOCwzMjY2KT0jIygyOCwzMjY3KT0mKDI4LDMyNjUpOzpSQzIwX1NFQ1VSSVRZ
X0FUVFJJQlVURVM7MkEuO19TRUNVUklUWV9BVFRSSUJVVEVTOjooMjgsMzI2OCk9IyMoMjgs
MzI2OSk9KigyOCwzMjY1KTs6UkMyMF9TRUNVUklUWV9BVFRSSUJVVEVTOzJBLigyOCwzMjcw
KT0jIygyOCwzMjY5KTs6OzJBLjs7AFNFQ1VSSVRZX0FUVFJJQlVURVM6dCgyOCwzMjcxKT0o
MjgsMzI2NSkATFBTRUNVUklUWV9BVFRSSUJVVEVTOnQoMjgsMzI3Mik9KDI4LDMyNjkpAFNF
Q1VSSVRZX0lORk9STUFUSU9OOnQoMjgsMzI3Myk9KDI1LDE0KQBQU0VDVVJJVFlfSU5GT1JN
QVRJT046dCgyOCwzMjc0KT0oMjUsODgpAF9zZWxjaGFuZ2U6VHQoMjgsMzI3NSk9czI0bm1o
ZHI6KDI4LDE3NTEpLDAsOTY7Y2hyZzooMjgsNDAxKSw5Niw2NDtzZWx0eXA6KDI1LDE1Myks
MTYwLDE2O19fYXM6OigyOCwzMjc2KT0jIygyOCwzMjc3KT0mKDI4LDMyNzUpOzpSQzEwX3Nl
bGNoYW5nZTsyQS47X3NlbGNoYW5nZTo6KDI4LDMyNzgpPSMjKDI4LDMyNzkpPSooMjgsMzI3
NSk7OlJDMTBfc2VsY2hhbmdlOzJBLigyOCwzMjgwKT0jIygyOCwzMjc5KTs6OzJBLjs7AFNF
TENIQU5HRTp0KDI4LDMyODEpPSgyOCwzMjc1KQB0YWdTRVJJQUxLRVlTOlR0KDI4LDMyODIp
PXMyNGNiU2l6ZTooMjUsMTQpLDAsMzI7ZHdGbGFnczooMjUsMTQpLDMyLDMyO2xwc3pBY3Rp
dmVQb3J0OigyNSw5NCksNjQsMzI7bHBzelBvcnQ6KDI1LDk0KSw5NiwzMjtpQmF1ZFJhdGU6
KDI1LDE0KSwxMjgsMzI7aVBvcnRTdGF0ZTooMjUsMTQpLDE2MCwzMjtfX2FzOjooMjgsMzI4
Myk9IyMoMjgsMzI4NCk9JigyOCwzMjgyKTs6UkMxM3RhZ1NFUklBTEtFWVM7MkEuO3RhZ1NF
UklBTEtFWVM6OigyOCwzMjg1KT0jIygyOCwzMjg2KT0qKDI4LDMyODIpOzpSQzEzdGFnU0VS
SUFMS0VZUzsyQS4oMjgsMzI4Nyk9IyMoMjgsMzI4Nik7OjsyQS47OwBTRVJJQUxLRVlTOnQo
MjgsMzI4OCk9KDI4LDMyODIpAExQU0VSSUFMS0VZUzp0KDI4LDMyODkpPSgyOCwzMjg2KQBf
U0VSVklDRV9UQUJMRV9FTlRSWTpUdCgyOCwzMjkwKT1zOGxwU2VydmljZU5hbWU6KDI1LDk2
KSwwLDMyO2xwU2VydmljZVByb2M6KDI1LDE5NyksMzIsMzI7X19hczo6KDI4LDMyOTEpPSMj
KDI4LDMyOTIpPSYoMjgsMzI5MCk7OlJDMjBfU0VSVklDRV9UQUJMRV9FTlRSWTsyQS47X1NF
UlZJQ0VfVEFCTEVfRU5UUlk6OigyOCwzMjkzKT0jIygyOCwzMjk0KT0qKDI4LDMyOTApOzpS
QzIwX1NFUlZJQ0VfVEFCTEVfRU5UUlk7MkEuKDI4LDMyOTUpPSMjKDI4LDMyOTQpOzo7MkEu
OzsAU0VSVklDRV9UQUJMRV9FTlRSWTp0KDI4LDMyOTYpPSgyOCwzMjkwKQBMUFNFUlZJQ0Vf
VEFCTEVfRU5UUlk6dCgyOCwzMjk3KT0oMjgsMzI5NCkAX1NFUlZJQ0VfVFlQRV9WQUxVRV9B
QlM6VHQoMjgsMzI5OCk9czIwZHdOYW1lU3BhY2U6KDI1LDE0KSwwLDMyO2R3VmFsdWVUeXBl
OigyNSwxNCksMzIsMzI7ZHdWYWx1ZVNpemU6KDI1LDE0KSw2NCwzMjtscFZhbHVlTmFtZToo
MjUsOTYpLDk2LDMyO2xwVmFsdWU6KDI1LDEzNiksMTI4LDMyO19fYXM6OigyOCwzMjk5KT0j
IygyOCwzMzAwKT0mKDI4LDMyOTgpOzpSQzIzX1NFUlZJQ0VfVFlQRV9WQUxVRV9BQlM7MkEu
O19TRVJWSUNFX1RZUEVfVkFMVUVfQUJTOjooMjgsMzMwMSk9IyMoMjgsMzMwMik9KigyOCwz
Mjk4KTs6UkMyM19TRVJWSUNFX1RZUEVfVkFMVUVfQUJTOzJBLigyOCwzMzAzKT0jIygyOCwz
MzAyKTs6OzJBLjs7AFNFUlZJQ0VfVFlQRV9WQUxVRV9BQlM6dCgyOCwzMzA0KT0oMjgsMzI5
OCkAX1NFUlZJQ0VfVFlQRV9JTkZPX0FCUzpUdCgyOCwzMzA1KT1zMjhscFR5cGVOYW1lOigy
NSw5NiksMCwzMjtkd1ZhbHVlQ291bnQ6KDI1LDE0KSwzMiwzMjtWYWx1ZXM6KDI4LDMzMDYp
PWFyKDAsMSk7MDswOygyOCwzMjk4KSw2NCwxNjA7X19hczo6KDI4LDMzMDcpPSMjKDI4LDMz
MDgpPSYoMjgsMzMwNSk7OlJDMjJfU0VSVklDRV9UWVBFX0lORk9fQUJTOzJBLjtfU0VSVklD
RV9UWVBFX0lORk9fQUJTOjooMjgsMzMwOSk9IyMoMjgsMzMxMCk9KigyOCwzMzA1KTs6UkMy
Ml9TRVJWSUNFX1RZUEVfSU5GT19BQlM7MkEuKDI4LDMzMTEpPSMjKDI4LDMzMTApOzo7MkEu
OzsAU0VSVklDRV9UWVBFX0lORk9fQUJTOnQoMjgsMzMxMik9KDI4LDMzMDUpAF9TRVNTSU9O
X0JVRkZFUjpUdCgyOCwzMzEzKT1zMzZsc246KDI1LDE0OSksMCw4O3N0YXRlOigyNSwxNDkp
LDgsODtsb2NhbF9uYW1lOigyOCwyNTgxKSwxNiwxMjg7cmVtb3RlX25hbWU6KDI4LDI1ODEp
LDE0NCwxMjg7cmN2c19vdXRzdGFuZGluZzooMjUsMTQ5KSwyNzIsODtzZW5kc19vdXRzdGFu
ZGluZzooMjUsMTQ5KSwyODAsODtfX2FzOjooMjgsMzMxNCk9IyMoMjgsMzMxNSk9JigyOCwz
MzEzKTs6UkMxNV9TRVNTSU9OX0JVRkZFUjsyQS47X1NFU1NJT05fQlVGRkVSOjooMjgsMzMx
Nik9IyMoMjgsMzMxNyk9KigyOCwzMzEzKTs6UkMxNV9TRVNTSU9OX0JVRkZFUjsyQS4oMjgs
MzMxOCk9IyMoMjgsMzMxNyk7OjsyQS47OwBTRVNTSU9OX0JVRkZFUjp0KDI4LDMzMTkpPSgy
OCwzMzEzKQBfU0VTU0lPTl9IRUFERVI6VHQoMjgsMzMyMCk9czRzZXNzX25hbWU6KDI1LDE0
OSksMCw4O251bV9zZXNzOigyNSwxNDkpLDgsODtyY3ZfZGdfb3V0c3RhbmRpbmc6KDI1LDE0
OSksMTYsODtyY3ZfYW55X291dHN0YW5kaW5nOigyNSwxNDkpLDI0LDg7X19hczo6KDI4LDMz
MjEpPSMjKDI4LDMzMjIpPSYoMjgsMzMyMCk7OlJDMTVfU0VTU0lPTl9IRUFERVI7MkEuO19T
RVNTSU9OX0hFQURFUjo6KDI4LDMzMjMpPSMjKDI4LDMzMjQpPSooMjgsMzMyMCk7OlJDMTVf
U0VTU0lPTl9IRUFERVI7MkEuKDI4LDMzMjUpPSMjKDI4LDMzMjQpOzo7MkEuOzsAU0VTU0lP
Tl9IRUFERVI6dCgyOCwzMzI2KT0oMjgsMzMyMCkAX1NFVF9QQVJUSVRJT05fSU5GT1JNQVRJ
T046VHQoMjgsMzMyNyk9czFQYXJ0aXRpb25UeXBlOigyNSw1KSwwLDg7X19hczo6KDI4LDMz
MjgpPSMjKDI4LDMzMjkpPSYoMjgsMzMyNyk7OlJDMjZfU0VUX1BBUlRJVElPTl9JTkZPUk1B
VElPTjsyQS47X1NFVF9QQVJUSVRJT05fSU5GT1JNQVRJT046OigyOCwzMzMwKT0jIygyOCwz
MzMxKT0qKDI4LDMzMjcpOzpSQzI2X1NFVF9QQVJUSVRJT05fSU5GT1JNQVRJT047MkEuKDI4
LDMzMzIpPSMjKDI4LDMzMzEpOzo7MkEuOzsAU0VUX1BBUlRJVElPTl9JTkZPUk1BVElPTjp0
KDI4LDMzMzMpPSgyOCwzMzI3KQB0YWdTSENPTlRGOnQoMjgsMzMzNCk9ZVNIQ09OVEZfRk9M
REVSUzozMixTSENPTlRGX05PTkZPTERFUlM6NjQsU0hDT05URl9JTkNMVURFSElEREVOOjEy
OCw7AFNIQ09OVEY6dCgyOCwzMzM1KT0oMjgsMzMzNCkAX1NIRklMRUlORk86VHQoMjgsMzMz
Nik9czM1MmhJY29uOigyNSw0MSksMCwzMjtpSWNvbjooMCwxKSwzMiwzMjtkd0F0dHJpYnV0
ZXM6KDI1LDE0KSw2NCwzMjtzekRpc3BsYXlOYW1lOigyOCwxMTYxKSw5NiwyMDgwO3N6VHlw
ZU5hbWU6KDI4LDMzMzcpPWFyKDAsMSk7MDs3OTsoMCwyKSwyMTc2LDY0MDtfX2FzOjooMjgs
MzMzOCk9IyMoMjgsMzMzOSk9JigyOCwzMzM2KTs6UkMxMV9TSEZJTEVJTkZPOzJBLjtfU0hG
SUxFSU5GTzo6KDI4LDMzNDApPSMjKDI4LDMzNDEpPSooMjgsMzMzNik7OlJDMTFfU0hGSUxF
SU5GTzsyQS4oMjgsMzM0Mik9IyMoMjgsMzM0MSk7OjsyQS47OwBTSEZJTEVJTkZPOnQoMjgs
MzM0Myk9KDI4LDMzMzYpAEZJTEVPUF9GTEFHUzp0KDI4LDMzNDQpPSgyNSwxNTMpAF9TSEZJ
TEVPUFNUUlVDVDpUdCgyOCwzMzQ1KT1zMzJod25kOigyNSw2MSksMCwzMjt3RnVuYzooMjUs
MTUwKSwzMiwzMjtwRnJvbTooMjUsODEpLDY0LDMyO3BUbzooMjUsODEpLDk2LDMyO2ZGbGFn
czooMjgsMzM0NCksMTI4LDE2O2ZBbnlPcGVyYXRpb25zQWJvcnRlZDooMjUsMiksMTYwLDMy
O2hOYW1lTWFwcGluZ3M6KDI1LDk4KSwxOTIsMzI7bHBzelByb2dyZXNzVGl0bGU6KDI1LDgx
KSwyMjQsMzI7X19hczo6KDI4LDMzNDYpPSMjKDI4LDMzNDcpPSYoMjgsMzM0NSk7OlJDMTVf
U0hGSUxFT1BTVFJVQ1Q7MkEuO19TSEZJTEVPUFNUUlVDVDo6KDI4LDMzNDgpPSMjKDI4LDMz
NDkpPSooMjgsMzM0NSk7OlJDMTVfU0hGSUxFT1BTVFJVQ1Q7MkEuKDI4LDMzNTApPSMjKDI4
LDMzNDkpOzo7MkEuOzsAU0hGSUxFT1BTVFJVQ1Q6dCgyOCwzMzUxKT0oMjgsMzM0NSkATFBT
SEZJTEVPUFNUUlVDVDp0KDI4LDMzNTIpPSgyOCwzMzQ5KQB0YWdTSEdETjp0KDI4LDMzNTMp
PWVTSEdETl9OT1JNQUw6MCxTSEdETl9JTkZPTERFUjoxLFNIR0ROX0ZPUlBBUlNJTkc6MzI3
NjgsOwBTSEdOTzp0KDI4LDMzNTQpPSgyOCwzMzUzKQBfU0hOQU1FTUFQUElORzpUdCgyOCwz
MzU1KT1zMTZwc3pPbGRQYXRoOigyNSw5NCksMCwzMjtwc3pOZXdQYXRoOigyNSw5NCksMzIs
MzI7Y2NoT2xkUGF0aDooMCwxKSw2NCwzMjtjY2hOZXdQYXRoOigwLDEpLDk2LDMyO19fYXM6
OigyOCwzMzU2KT0jIygyOCwzMzU3KT0mKDI4LDMzNTUpOzpSQzE0X1NITkFNRU1BUFBJTkc7
MkEuO19TSE5BTUVNQVBQSU5HOjooMjgsMzM1OCk9IyMoMjgsMzM1OSk9KigyOCwzMzU1KTs6
UkMxNF9TSE5BTUVNQVBQSU5HOzJBLigyOCwzMzYwKT0jIygyOCwzMzU5KTs6OzJBLjs7AFNI
TkFNRU1BUFBJTkc6dCgyOCwzMzYxKT0oMjgsMzM1NSkATFBTSE5BTUVNQVBQSU5HOnQoMjgs
MzM2Mik9KDI4LDMzNTkpAF9TSURfQU5EX0FUVFJJQlVURVM6VHQoMjgsMzM2Myk9czhTaWQ6
KDI4LDIxODUpLDAsMzI7QXR0cmlidXRlczooMjUsMTQpLDMyLDMyO19fYXM6OigyOCwzMzY0
KT0jIygyOCwzMzY1KT0mKDI4LDMzNjMpOzpSQzE5X1NJRF9BTkRfQVRUUklCVVRFUzsyQS47
X1NJRF9BTkRfQVRUUklCVVRFUzo6KDI4LDMzNjYpPSMjKDI4LDMzNjcpPSooMjgsMzM2Myk7
OlJDMTlfU0lEX0FORF9BVFRSSUJVVEVTOzJBLigyOCwzMzY4KT0jIygyOCwzMzY3KTs6OzJB
Ljs7AFNJRF9BTkRfQVRUUklCVVRFUzp0KDI4LDMzNjkpPSgyOCwzMzYzKQBTSURfQU5EX0FU
VFJJQlVURVNfQVJSQVk6dCgyOCwzMzcwKT0oMjgsMzM3MSk9YXIoMCwxKTswOzA7KDI4LDMz
NjMpAFBTSURfQU5EX0FUVFJJQlVURVNfQVJSQVk6dCgyOCwzMzcyKT0oMjgsMzM3Myk9Kigy
OCwzMzcwKQBfU0lOR0xFX0xJU1RfRU5UUlk6VHQoMjgsMzM3NCk9czROZXh0OigyOCwzMzc1
KT0qKDI4LDMzNzQpLDAsMzI7X19hczo6KDI4LDMzNzYpPSMjKDI4LDMzNzcpPSYoMjgsMzM3
NCk7OlJDMThfU0lOR0xFX0xJU1RfRU5UUlk7MkEuO19TSU5HTEVfTElTVF9FTlRSWTo6KDI4
LDMzNzgpPSMjKDI4LDMzNzUpOzpSQzE4X1NJTkdMRV9MSVNUX0VOVFJZOzJBLigyOCwzMzc5
KT0jIygyOCwzMzc1KTs6OzJBLjs7AFNJTkdMRV9MSVNUX0VOVFJZOnQoMjgsMzM4MCk9KDI4
LDMzNzQpAHRhZ1NPVU5EU0VOVFJZOlR0KDI4LDMzODEpPXM0OGNiU2l6ZTooMjUsMTUwKSww
LDMyO2R3RmxhZ3M6KDI1LDE0KSwzMiwzMjtpRlNUZXh0RWZmZWN0OigyNSwxNCksNjQsMzI7
aUZTVGV4dEVmZmVjdE1TZWM6KDI1LDE0KSw5NiwzMjtpRlNUZXh0RWZmZWN0Q29sb3JCaXRz
OigyNSwxNCksMTI4LDMyO2lGU0dyYWZFZmZlY3Q6KDI1LDE0KSwxNjAsMzI7aUZTR3JhZkVm
ZmVjdE1TZWM6KDI1LDE0KSwxOTIsMzI7aUZTR3JhZkVmZmVjdENvbG9yOigyNSwxNCksMjI0
LDMyO2lXaW5kb3dzRWZmZWN0OigyNSwxNCksMjU2LDMyO2lXaW5kb3dzRWZmZWN0TVNlYzoo
MjUsMTQpLDI4OCwzMjtscHN6V2luZG93c0VmZmVjdERMTDooMjUsOTYpLDMyMCwzMjtpV2lu
ZG93c0VmZmVjdE9yZGluYWw6KDI1LDE0KSwzNTIsMzI7X19hczo6KDI4LDMzODIpPSMjKDI4
LDMzODMpPSYoMjgsMzM4MSk7OlJDMTR0YWdTT1VORFNFTlRSWTsyQS47dGFnU09VTkRTRU5U
Ulk6OigyOCwzMzg0KT0jIygyOCwzMzg1KT0qKDI4LDMzODEpOzpSQzE0dGFnU09VTkRTRU5U
Ulk7MkEuKDI4LDMzODYpPSMjKDI4LDMzODUpOzo7MkEuOzsAU09VTkRTRU5UUlk6dCgyOCwz
Mzg3KT0oMjgsMzM4MSkATFBTT1VORFNFTlRSWTp0KDI4LDMzODgpPSgyOCwzMzg1KQB0YWdT
VEFSVFVQSU5GT0E6VHQoMjgsMzM4OSk9czY4Y2I6KDI1LDE0KSwwLDMyO2xwUmVzZXJ2ZWQ6
KDI1LDk0KSwzMiwzMjtscERlc2t0b3A6KDI1LDk0KSw2NCwzMjtscFRpdGxlOigyNSw5NCks
OTYsMzI7ZHdYOigyNSwxNCksMTI4LDMyO2R3WTooMjUsMTQpLDE2MCwzMjtkd1hTaXplOigy
NSwxNCksMTkyLDMyO2R3WVNpemU6KDI1LDE0KSwyMjQsMzI7ZHdYQ291bnRDaGFyczooMjUs
MTQpLDI1NiwzMjtkd1lDb3VudENoYXJzOigyNSwxNCksMjg4LDMyO2R3RmlsbEF0dHJpYnV0
ZTooMjUsMTQpLDMyMCwzMjtkd0ZsYWdzOigyNSwxNCksMzUyLDMyO3dTaG93V2luZG93Oigy
NSwxNTMpLDM4NCwxNjtjYlJlc2VydmVkMjooMjUsMTUzKSw0MDAsMTY7bHBSZXNlcnZlZDI6
KDI1LDczKSw0MTYsMzI7aFN0ZElucHV0OigyNSwxOSksNDQ4LDMyO2hTdGRPdXRwdXQ6KDI1
LDE5KSw0ODAsMzI7aFN0ZEVycm9yOigyNSwxOSksNTEyLDMyO19fYXM6OigyOCwzMzkwKT0j
IygyOCwzMzkxKT0mKDI4LDMzODkpOzpSQzE1dGFnU1RBUlRVUElORk9BOzJBLjt0YWdTVEFS
VFVQSU5GT0E6OigyOCwzMzkyKT0jIygyOCwzMzkzKT0qKDI4LDMzODkpOzpSQzE1dGFnU1RB
UlRVUElORk9BOzJBLigyOCwzMzk0KT0jIygyOCwzMzkzKTs6OzJBLjs7AFNUQVJUVVBJTkZP
QTp0KDI4LDMzOTUpPSgyOCwzMzg5KQBQU1RBUlRVUElORk9BOnQoMjgsMzM5Nik9KDI4LDMz
OTMpAExQU1RBUlRVUElORk9BOnQoMjgsMzM5Nyk9KDI4LDMzOTMpAHRhZ1NUQVJUVVBJTkZP
VzpUdCgyOCwzMzk4KT1zNjhjYjooMjUsMTQpLDAsMzI7bHBSZXNlcnZlZDooMjUsMTA0KSwz
MiwzMjtscERlc2t0b3A6KDI1LDEwNCksNjQsMzI7bHBUaXRsZTooMjUsMTA0KSw5NiwzMjtk
d1g6KDI1LDE0KSwxMjgsMzI7ZHdZOigyNSwxNCksMTYwLDMyO2R3WFNpemU6KDI1LDE0KSwx
OTIsMzI7ZHdZU2l6ZTooMjUsMTQpLDIyNCwzMjtkd1hDb3VudENoYXJzOigyNSwxNCksMjU2
LDMyO2R3WUNvdW50Q2hhcnM6KDI1LDE0KSwyODgsMzI7ZHdGaWxsQXR0cmlidXRlOigyNSwx
NCksMzIwLDMyO2R3RmxhZ3M6KDI1LDE0KSwzNTIsMzI7d1Nob3dXaW5kb3c6KDI1LDE1Myks
Mzg0LDE2O2NiUmVzZXJ2ZWQyOigyNSwxNTMpLDQwMCwxNjtscFJlc2VydmVkMjooMjUsNzMp
LDQxNiwzMjtoU3RkSW5wdXQ6KDI1LDE5KSw0NDgsMzI7aFN0ZE91dHB1dDooMjUsMTkpLDQ4
MCwzMjtoU3RkRXJyb3I6KDI1LDE5KSw1MTIsMzI7X19hczo6KDI4LDMzOTkpPSMjKDI4LDM0
MDApPSYoMjgsMzM5OCk7OlJDMTV0YWdTVEFSVFVQSU5GT1c7MkEuO3RhZ1NUQVJUVVBJTkZP
Vzo6KDI4LDM0MDEpPSMjKDI4LDM0MDIpPSooMjgsMzM5OCk7OlJDMTV0YWdTVEFSVFVQSU5G
T1c7MkEuKDI4LDM0MDMpPSMjKDI4LDM0MDIpOzo7MkEuOzsAU1RBUlRVUElORk9XOnQoMjgs
MzQwNCk9KDI4LDMzOTgpAFBTVEFSVFVQSU5GT1c6dCgyOCwzNDA1KT0oMjgsMzQwMikATFBT
VEFSVFVQSU5GT1c6dCgyOCwzNDA2KT0oMjgsMzQwMikAU1RBUlRVUElORk86dCgyOCwzNDA3
KT0oMjgsMzM5NSkAUFNUQVJUVVBJTkZPOnQoMjgsMzQwOCk9KDI4LDMzOTYpAExQU1RBUlRV
UElORk86dCgyOCwzNDA5KT0oMjgsMzM5NykAdGFnU1RJQ0tZS0VZUzpUdCgyOCwzNDEwKT1z
OGNiU2l6ZTooMjUsMTQpLDAsMzI7ZHdGbGFnczooMjUsMTQpLDMyLDMyO19fYXM6OigyOCwz
NDExKT0jIygyOCwzNDEyKT0mKDI4LDM0MTApOzpSQzEzdGFnU1RJQ0tZS0VZUzsyQS47dGFn
U1RJQ0tZS0VZUzo6KDI4LDM0MTMpPSMjKDI4LDM0MTQpPSooMjgsMzQxMCk7OlJDMTN0YWdT
VElDS1lLRVlTOzJBLigyOCwzNDE1KT0jIygyOCwzNDE0KTs6OzJBLjs7AFNUSUNLWUtFWVM6
dCgyOCwzNDE2KT0oMjgsMzQxMCkATFBTVElDS1lLRVlTOnQoMjgsMzQxNyk9KDI4LDM0MTQp
AF9TVFJSRVQ6VHQoMjgsMzQxOCk9czI2NHVUeXBlOigyNSwxNTApLDAsMzI7RFVNTVlVTklP
Tk5BTUU6KDI4LDM0MTkpPXUyNjBwT2xlU3RyOigyNSwxMDQpLDAsMzI7dU9mZnNldDooMjUs
MTUwKSwwLDMyO2NTdHI6KDI4LDExNjEpLDAsMjA4MDtfX2FzOjooMjgsMzQyMCk9IygyOCwz
NDE5KSwoMjgsMzQyMSk9JigyOCwzNDE5KSwoMjgsMzQyMik9KigyOCwzNDE5KSwoMjgsMzQy
Myk9JigyOCwzNDE5KSwoMCwyMCk7Ol9fYXNfX1EyN19TVFJSRVQ0JF8zN1JDUTI3X1NUUlJF
VDQkXzM3OzJBLjskXzM3OjooMjgsMzQyNCk9IygyOCwzNDE5KSwoMjgsMzQyMiksKDI4LDM0
MjIpLCgyOCwzNDIzKSwoMCwyMCk7Ol9fUTI3X1NUUlJFVDQkXzM3UkNRMjdfU1RSUkVUNCRf
Mzc7MkEuKDI4LDM0MjUpPSMoMjgsMzQxOSksKDI4LDM0MjIpLCgyOCwzNDIyKSwoMCwyMCk7
Ol9fUTI3X1NUUlJFVDQkXzM3OzJBLjs7LDMyLDIwODA7X19hczo6KDI4LDM0MjYpPSMjKDI4
LDM0MjcpPSYoMjgsMzQxOCk7OlJDN19TVFJSRVQ7MkEuO19TVFJSRVQ6OigyOCwzNDI4KT0j
IygyOCwzNDI5KT0qKDI4LDM0MTgpOzpSQzdfU1RSUkVUOzJBLigyOCwzNDMwKT0jIygyOCwz
NDI5KTs6OzJBLjs7AFNUUlJFVDp0KDI4LDM0MzEpPSgyOCwzNDE4KQBMUFNUUlJFVDp0KDI4
LDM0MzIpPSgyOCwzNDI5KQBfdGFnU1RZTEVCVUY6VHQoMjgsMzQzMyk9czM2ZHdTdHlsZToo
MjUsMTQpLDAsMzI7c3pEZXNjcmlwdGlvbjooMjgsMzg4KSwzMiwyNTY7X19hczo6KDI4LDM0
MzQpPSMjKDI4LDM0MzUpPSYoMjgsMzQzMyk7OlJDMTJfdGFnU1RZTEVCVUY7MkEuO190YWdT
VFlMRUJVRjo6KDI4LDM0MzYpPSMjKDI4LDM0MzcpPSooMjgsMzQzMyk7OlJDMTJfdGFnU1RZ
TEVCVUY7MkEuKDI4LDM0MzgpPSMjKDI4LDM0MzcpOzo7MkEuOzsAU1RZTEVCVUY6dCgyOCwz
NDM5KT0oMjgsMzQzMykATFBTVFlMRUJVRjp0KDI4LDM0NDApPSgyOCwzNDM3KQB0YWdTVFlM
RVNUUlVDVDpUdCgyOCwzNDQxKT1zOHN0eWxlT2xkOigyNSwxNCksMCwzMjtzdHlsZU5ldzoo
MjUsMTQpLDMyLDMyO19fYXM6OigyOCwzNDQyKT0jIygyOCwzNDQzKT0mKDI4LDM0NDEpOzpS
QzE0dGFnU1RZTEVTVFJVQ1Q7MkEuO3RhZ1NUWUxFU1RSVUNUOjooMjgsMzQ0NCk9IyMoMjgs
MzQ0NSk9KigyOCwzNDQxKTs6UkMxNHRhZ1NUWUxFU1RSVUNUOzJBLigyOCwzNDQ2KT0jIygy
OCwzNDQ1KTs6OzJBLjs7AFNUWUxFU1RSVUNUOnQoMjgsMzQ0Nyk9KDI4LDM0NDEpAExQU1RZ
TEVTVFJVQ1Q6dCgyOCwzNDQ4KT0oMjgsMzQ0NSkAX1NZU1RFTV9BVURJVF9BQ0U6VHQoMjgs
MzQ0OSk9czEySGVhZGVyOigyOCwzMSksMCwzMjtNYXNrOigyOCwzMiksMzIsMzI7U2lkU3Rh
cnQ6KDI1LDE0KSw2NCwzMjtfX2FzOjooMjgsMzQ1MCk9IyMoMjgsMzQ1MSk9JigyOCwzNDQ5
KTs6UkMxN19TWVNURU1fQVVESVRfQUNFOzJBLjtfU1lTVEVNX0FVRElUX0FDRTo6KDI4LDM0
NTIpPSMjKDI4LDM0NTMpPSooMjgsMzQ0OSk7OlJDMTdfU1lTVEVNX0FVRElUX0FDRTsyQS4o
MjgsMzQ1NCk9IyMoMjgsMzQ1Myk7OjsyQS47OwBTWVNURU1fQVVESVRfQUNFOnQoMjgsMzQ1
NSk9KDI4LDM0NDkpAF9TWVNURU1fSU5GTzpUdCgyOCwzNDU2KT1zMzZ1OigyOCwzNDU3KT11
NGR3T2VtSUQ6KDI1LDE0KSwwLDMyO3M6KDI4LDM0NTgpPXM0d1Byb2Nlc3NvckFyY2hpdGVj
dHVyZTooMjUsMTUzKSwwLDE2O3dSZXNlcnZlZDooMjUsMTUzKSwxNiwxNjtfX2FzOjooMjgs
MzQ1OSk9IygyOCwzNDU4KSwoMjgsMzQ2MCk9JigyOCwzNDU4KSwoMjgsMzQ2MSk9KigyOCwz
NDU4KSwoMjgsMzQ2Mik9JigyOCwzNDU4KSwoMCwyMCk7Ol9fYXNfX1EzMTJfU1lTVEVNX0lO
Rk80JF8zODQkXzM5UkNRMzEyX1NZU1RFTV9JTkZPNCRfMzg0JF8zOTsyQS47JF8zOTo6KDI4
LDM0NjMpPSMoMjgsMzQ1OCksKDI4LDM0NjEpLCgyOCwzNDYxKSwoMjgsMzQ2MiksKDAsMjAp
OzpfX1EzMTJfU1lTVEVNX0lORk80JF8zODQkXzM5UkNRMzEyX1NZU1RFTV9JTkZPNCRfMzg0
JF8zOTsyQS4oMjgsMzQ2NCk9IygyOCwzNDU4KSwoMjgsMzQ2MSksKDI4LDM0NjEpLCgwLDIw
KTs6X19RMzEyX1NZU1RFTV9JTkZPNCRfMzg0JF8zOTsyQS47OywwLDMyO19fYXM6OigyOCwz
NDY1KT0jKDI4LDM0NTcpLCgyOCwzNDY2KT0mKDI4LDM0NTcpLCgyOCwzNDY3KT0qKDI4LDM0
NTcpLCgyOCwzNDY4KT0mKDI4LDM0NTcpLCgwLDIwKTs6X19hc19fUTIxMl9TWVNURU1fSU5G
TzQkXzM4UkNRMjEyX1NZU1RFTV9JTkZPNCRfMzg7MkEuOyRfMzg6OigyOCwzNDY5KT0jKDI4
LDM0NTcpLCgyOCwzNDY3KSwoMjgsMzQ2NyksKDI4LDM0NjgpLCgwLDIwKTs6X19RMjEyX1NZ
U1RFTV9JTkZPNCRfMzhSQ1EyMTJfU1lTVEVNX0lORk80JF8zODsyQS4oMjgsMzQ3MCk9Iygy
OCwzNDU3KSwoMjgsMzQ2NyksKDI4LDM0NjcpLCgwLDIwKTs6X19RMjEyX1NZU1RFTV9JTkZP
NCRfMzg7MkEuOzssMCwzMjtkd1BhZ2VTaXplOigyNSwxNCksMzIsMzI7bHBNaW5pbXVtQXBw
bGljYXRpb25BZGRyZXNzOigyNSw5OCksNjQsMzI7bHBNYXhpbXVtQXBwbGljYXRpb25BZGRy
ZXNzOigyNSw5OCksOTYsMzI7ZHdBY3RpdmVQcm9jZXNzb3JNYXNrOigyNSwxNCksMTI4LDMy
O2R3TnVtYmVyT2ZQcm9jZXNzb3JzOigyNSwxNCksMTYwLDMyO2R3UHJvY2Vzc29yVHlwZToo
MjUsMTQpLDE5MiwzMjtkd0FsbG9jYXRpb25HcmFudWxhcml0eTooMjUsMTQpLDIyNCwzMjt3
UHJvY2Vzc29yTGV2ZWw6KDI1LDE1MyksMjU2LDE2O3dQcm9jZXNzb3JSZXZpc2lvbjooMjUs
MTUzKSwyNzIsMTY7X19hczo6KDI4LDM0NzEpPSMjKDI4LDM0NzIpPSYoMjgsMzQ1Nik7OlJD
MTJfU1lTVEVNX0lORk87MkEuO19TWVNURU1fSU5GTzo6KDI4LDM0NzMpPSMjKDI4LDM0NzQp
PSooMjgsMzQ1Nik7OlJDMTJfU1lTVEVNX0lORk87MkEuKDI4LDM0NzUpPSMjKDI4LDM0NzQp
Ozo7MkEuOzsAU1lTVEVNX0lORk86dCgyOCwzNDc2KT0oMjgsMzQ1NikATFBTWVNURU1fSU5G
Tzp0KDI4LDM0NzcpPSgyOCwzNDc0KQBfU1lTVEVNX1BPV0VSX1NUQVRVUzpUdCgyOCwzNDc4
KT1zMTJBQ0xpbmVTdGF0dXM6KDI1LDUpLDAsODtCYXR0ZXJ5RmxhZzooMjUsNSksOCw4O0Jh
dHRlcnlMaWZlUGVyY2VudDooMjUsNSksMTYsODtSZXNlcnZlZDE6KDI1LDUpLDI0LDg7QmF0
dGVyeUxpZmVUaW1lOigyNSwxNCksMzIsMzI7QmF0dGVyeUZ1bGxMaWZlVGltZTooMjUsMTQp
LDY0LDMyO19fYXM6OigyOCwzNDc5KT0jIygyOCwzNDgwKT0mKDI4LDM0NzgpOzpSQzIwX1NZ
U1RFTV9QT1dFUl9TVEFUVVM7MkEuO19TWVNURU1fUE9XRVJfU1RBVFVTOjooMjgsMzQ4MSk9
IyMoMjgsMzQ4Mik9KigyOCwzNDc4KTs6UkMyMF9TWVNURU1fUE9XRVJfU1RBVFVTOzJBLigy
OCwzNDgzKT0jIygyOCwzNDgyKTs6OzJBLjs7AFNZU1RFTV9QT1dFUl9TVEFUVVM6dCgyOCwz
NDg0KT0oMjgsMzQ3OCkATFBTWVNURU1fUE9XRVJfU1RBVFVTOnQoMjgsMzQ4NSk9KDI4LDM0
ODIpAF9UQVBFX0VSQVNFOlR0KDI4LDM0ODYpPXM0VHlwZTooMjUsMTUxKSwwLDMyO19fYXM6
OigyOCwzNDg3KT0jIygyOCwzNDg4KT0mKDI4LDM0ODYpOzpSQzExX1RBUEVfRVJBU0U7MkEu
O19UQVBFX0VSQVNFOjooMjgsMzQ4OSk9IyMoMjgsMzQ5MCk9KigyOCwzNDg2KTs6UkMxMV9U
QVBFX0VSQVNFOzJBLigyOCwzNDkxKT0jIygyOCwzNDkwKTs6OzJBLjs7AFRBUEVfRVJBU0U6
dCgyOCwzNDkyKT0oMjgsMzQ4NikAX1RBUEVfR0VUX0RSSVZFX1BBUkFNRVRFUlM6VHQoMjgs
MzQ5Myk9czMyRUNDOigyNSw0KSwwLDg7Q29tcHJlc3Npb246KDI1LDQpLDgsODtEYXRhUGFk
ZGluZzooMjUsNCksMTYsODtSZXBvcnRTZXRtYXJrczooMjUsNCksMjQsODtEZWZhdWx0Qmxv
Y2tTaXplOigyNSwxNTEpLDMyLDMyO01heGltdW1CbG9ja1NpemU6KDI1LDE1MSksNjQsMzI7
TWluaW11bUJsb2NrU2l6ZTooMjUsMTUxKSw5NiwzMjtNYXhpbXVtUGFydGl0aW9uQ291bnQ6
KDI1LDE1MSksMTI4LDMyO0ZlYXR1cmVzTG93OigyNSwxNTEpLDE2MCwzMjtGZWF0dXJlc0hp
Z2g6KDI1LDE1MSksMTkyLDMyO0VPVFdhcm5pbmdab25lU2l6ZTooMjUsMTUxKSwyMjQsMzI7
X19hczo6KDI4LDM0OTQpPSMjKDI4LDM0OTUpPSYoMjgsMzQ5Myk7OlJDMjZfVEFQRV9HRVRf
RFJJVkVfUEFSQU1FVEVSUzsyQS47X1RBUEVfR0VUX0RSSVZFX1BBUkFNRVRFUlM6OigyOCwz
NDk2KT0jIygyOCwzNDk3KT0qKDI4LDM0OTMpOzpSQzI2X1RBUEVfR0VUX0RSSVZFX1BBUkFN
RVRFUlM7MkEuKDI4LDM0OTgpPSMjKDI4LDM0OTcpOzo7MkEuOzsAVEFQRV9HRVRfRFJJVkVf
UEFSQU1FVEVSUzp0KDI4LDM0OTkpPSgyOCwzNDkzKQBfVEFQRV9HRVRfTUVESUFfUEFSQU1F
VEVSUzpUdCgyOCwzNTAwKT1zMzJDYXBhY2l0eTooMjgsOTY5KSwwLDY0O1JlbWFpbmluZzoo
MjgsOTY5KSw2NCw2NDtCbG9ja1NpemU6KDI1LDE0KSwxMjgsMzI7UGFydGl0aW9uQ291bnQ6
KDI1LDE0KSwxNjAsMzI7V3JpdGVQcm90ZWN0ZWQ6KDI1LDQpLDE5Miw4O3Jlc2VydmVkOigy
OCwzNTAxKT1hcigwLDEpOzA7NjsoMCwxMSksMjAwLDU2O19fYXM6OigyOCwzNTAyKT0jIygy
OCwzNTAzKT0mKDI4LDM1MDApOzpSQzI2X1RBUEVfR0VUX01FRElBX1BBUkFNRVRFUlM7MkEu
O19UQVBFX0dFVF9NRURJQV9QQVJBTUVURVJTOjooMjgsMzUwNCk9IyMoMjgsMzUwNSk9Kigy
OCwzNTAwKTs6UkMyNl9UQVBFX0dFVF9NRURJQV9QQVJBTUVURVJTOzJBLigyOCwzNTA2KT0j
IygyOCwzNTA1KTs6OzJBLjs7AFRBUEVfR0VUX01FRElBX1BBUkFNRVRFUlM6dCgyOCwzNTA3
KT0oMjgsMzUwMCkAX1RBUEVfR0VUX1BPU0lUSU9OOlR0KDI4LDM1MDgpPXMxNlR5cGU6KDI1
LDE1MSksMCwzMjtQYXJ0aXRpb246KDI1LDE1MSksMzIsMzI7T2Zmc2V0TG93OigyNSwxNTEp
LDY0LDMyO09mZnNldEhpZ2g6KDI1LDE1MSksOTYsMzI7X19hczo6KDI4LDM1MDkpPSMjKDI4
LDM1MTApPSYoMjgsMzUwOCk7OlJDMThfVEFQRV9HRVRfUE9TSVRJT047MkEuO19UQVBFX0dF
VF9QT1NJVElPTjo6KDI4LDM1MTEpPSMjKDI4LDM1MTIpPSooMjgsMzUwOCk7OlJDMThfVEFQ
RV9HRVRfUE9TSVRJT047MkEuKDI4LDM1MTMpPSMjKDI4LDM1MTIpOzo7MkEuOzsAVEFQRV9H
RVRfUE9TSVRJT046dCgyOCwzNTE0KT0oMjgsMzUwOCkAX1RBUEVfUFJFUEFSRTpUdCgyOCwz
NTE1KT1zNE9wZXJhdGlvbjooMjUsMTUxKSwwLDMyO19fYXM6OigyOCwzNTE2KT0jIygyOCwz
NTE3KT0mKDI4LDM1MTUpOzpSQzEzX1RBUEVfUFJFUEFSRTsyQS47X1RBUEVfUFJFUEFSRTo6
KDI4LDM1MTgpPSMjKDI4LDM1MTkpPSooMjgsMzUxNSk7OlJDMTNfVEFQRV9QUkVQQVJFOzJB
LigyOCwzNTIwKT0jIygyOCwzNTE5KTs6OzJBLjs7AFRBUEVfUFJFUEFSRTp0KDI4LDM1MjEp
PSgyOCwzNTE1KQBfVEFQRV9TRVRfRFJJVkVfUEFSQU1FVEVSUzpUdCgyOCwzNTIyKT1zOEVD
QzooMjUsNCksMCw4O0NvbXByZXNzaW9uOigyNSw0KSw4LDg7RGF0YVBhZGRpbmc6KDI1LDQp
LDE2LDg7UmVwb3J0U2V0bWFya3M6KDI1LDQpLDI0LDg7RU9UV2FybmluZ1pvbmVTaXplOigy
NSwxNTEpLDMyLDMyO19fYXM6OigyOCwzNTIzKT0jIygyOCwzNTI0KT0mKDI4LDM1MjIpOzpS
QzI2X1RBUEVfU0VUX0RSSVZFX1BBUkFNRVRFUlM7MkEuO19UQVBFX1NFVF9EUklWRV9QQVJB
TUVURVJTOjooMjgsMzUyNSk9IyMoMjgsMzUyNik9KigyOCwzNTIyKTs6UkMyNl9UQVBFX1NF
VF9EUklWRV9QQVJBTUVURVJTOzJBLigyOCwzNTI3KT0jIygyOCwzNTI2KTs6OzJBLjs7AFRB
UEVfU0VUX0RSSVZFX1BBUkFNRVRFUlM6dCgyOCwzNTI4KT0oMjgsMzUyMikAX1RBUEVfU0VU
X01FRElBX1BBUkFNRVRFUlM6VHQoMjgsMzUyOSk9czRCbG9ja1NpemU6KDI1LDE1MSksMCwz
MjtfX2FzOjooMjgsMzUzMCk9IyMoMjgsMzUzMSk9JigyOCwzNTI5KTs6UkMyNl9UQVBFX1NF
VF9NRURJQV9QQVJBTUVURVJTOzJBLjtfVEFQRV9TRVRfTUVESUFfUEFSQU1FVEVSUzo6KDI4
LDM1MzIpPSMjKDI4LDM1MzMpPSooMjgsMzUyOSk7OlJDMjZfVEFQRV9TRVRfTUVESUFfUEFS
QU1FVEVSUzsyQS4oMjgsMzUzNCk9IyMoMjgsMzUzMyk7OjsyQS47OwBUQVBFX1NFVF9NRURJ
QV9QQVJBTUVURVJTOnQoMjgsMzUzNSk9KDI4LDM1MjkpAF9UQVBFX1NFVF9QT1NJVElPTjpU
dCgyOCwzNTM2KT1zMTZNZXRob2Q6KDI1LDE1MSksMCwzMjtQYXJ0aXRpb246KDI1LDE1MSks
MzIsMzI7T2Zmc2V0TG93OigyNSwxNTEpLDY0LDMyO09mZnNldEhpZ2g6KDI1LDE1MSksOTYs
MzI7X19hczo6KDI4LDM1MzcpPSMjKDI4LDM1MzgpPSYoMjgsMzUzNik7OlJDMThfVEFQRV9T
RVRfUE9TSVRJT047MkEuO19UQVBFX1NFVF9QT1NJVElPTjo6KDI4LDM1MzkpPSMjKDI4LDM1
NDApPSooMjgsMzUzNik7OlJDMThfVEFQRV9TRVRfUE9TSVRJT047MkEuKDI4LDM1NDEpPSMj
KDI4LDM1NDApOzo7MkEuOzsAVEFQRV9TRVRfUE9TSVRJT046dCgyOCwzNTQyKT0oMjgsMzUz
NikAX1RBUEVfV1JJVEVfTUFSS1M6VHQoMjgsMzU0Myk9czhUeXBlOigyNSwxNTEpLDAsMzI7
Q291bnQ6KDI1LDE1MSksMzIsMzI7X19hczo6KDI4LDM1NDQpPSMjKDI4LDM1NDUpPSYoMjgs
MzU0Myk7OlJDMTdfVEFQRV9XUklURV9NQVJLUzsyQS47X1RBUEVfV1JJVEVfTUFSS1M6Oigy
OCwzNTQ2KT0jIygyOCwzNTQ3KT0qKDI4LDM1NDMpOzpSQzE3X1RBUEVfV1JJVEVfTUFSS1M7
MkEuKDI4LDM1NDgpPSMjKDI4LDM1NDcpOzo7MkEuOzsAVEFQRV9XUklURV9NQVJLUzp0KDI4
LDM1NDkpPSgyOCwzNTQzKQBUQkFEREJJVE1BUDp0KDI4LDM1NTApPXM4aEluc3Q6KDI1LDQz
KSwwLDMyO25JRDooMjUsMTUwKSwzMiwzMjtfX2FzOjooMjgsMzU1MSk9IygyOCwzNTUwKSwo
MjgsMzU1Mik9JigyOCwzNTUwKSwoMjgsMzU1Myk9KigyOCwzNTUwKSwoMjgsMzU1NCk9Jigy
OCwzNTU1KT1zOGhJbnN0OigyNSw0MyksMCwzMjtuSUQ6KDI1LDE1MCksMzIsMzI7X19hczo6
KDI4LDM1NTEpOl9fYXNfXzQkXzQwUkM0JF80MDsyQS47JF80MDo6KDI4LDM1NTYpPSMoMjgs
MzU1MCksKDI4LDM1NTMpLCgyOCwzNTUzKSwoMjgsMzU1NCksKDAsMjApOzpfXzQkXzQwUkM0
JF80MDsyQS4oMjgsMzU1Nyk9IygyOCwzNTUwKSwoMjgsMzU1MyksKDI4LDM1NTMpLCgwLDIw
KTs6X180JF80MDsyQS47OywoMCwyMCk7Ol9fYXNfXzQkXzQwUkM0JF80MDsyQS47JF80MDo6
KDI4LDM1NTYpOl9fNCRfNDBSQzQkXzQwOzJBLigyOCwzNTU3KTpfXzQkXzQwOzJBLjs7AExQ
VEJBRERCSVRNQVA6dCgyOCwzNTU4KT0oMjgsMzU1MykAX1RCQlVUVE9OOlR0KDI4LDM1NTkp
PXMyMGlCaXRtYXA6KDAsMSksMCwzMjtpZENvbW1hbmQ6KDAsMSksMzIsMzI7ZnNTdGF0ZToo
MjUsNSksNjQsODtmc1N0eWxlOigyNSw1KSw3Miw4O2R3RGF0YTooMjUsMTQpLDk2LDMyO2lT
dHJpbmc6KDAsMSksMTI4LDMyO19fYXM6OigyOCwzNTYwKT0jIygyOCwzNTYxKT0mKDI4LDM1
NTkpOzpSQzlfVEJCVVRUT047MkEuO19UQkJVVFRPTjo6KDI4LDM1NjIpPSMjKDI4LDM1NjMp
PSooMjgsMzU1OSk7OlJDOV9UQkJVVFRPTjsyQS4oMjgsMzU2NCk9IyMoMjgsMzU2Myk7Ojsy
QS47OwBUQkJVVFRPTjp0KDI4LDM1NjUpPSgyOCwzNTU5KQBQVEJCVVRUT046dCgyOCwzNTY2
KT0oMjgsMzU2MykATFBUQkJVVFRPTjp0KDI4LDM1NjcpPSgyOCwzNTYzKQBMUENUQkJVVFRP
Tjp0KDI4LDM1NjgpPSgyOCwzNTY5KT0qKDI4LDM1NjUpAFRCTk9USUZZOnQoMjgsMzU3MCk9
czQ0aGRyOigyOCwxNzUxKSwwLDk2O2lJdGVtOigwLDEpLDk2LDMyO3RiQnV0dG9uOigyOCwz
NTY1KSwxMjgsMTYwO2NjaFRleHQ6KDAsMSksMjg4LDMyO3BzelRleHQ6KDI1LDk2KSwzMjAs
MzI7X19hczo6KDI4LDM1NzEpPSMoMjgsMzU3MCksKDI4LDM1NzIpPSYoMjgsMzU3MCksKDI4
LDM1NzMpPSooMjgsMzU3MCksKDI4LDM1NzQpPSYoMjgsMzU3NSk9czQ0aGRyOigyOCwxNzUx
KSwwLDk2O2lJdGVtOigwLDEpLDk2LDMyO3RiQnV0dG9uOigyOCwzNTY1KSwxMjgsMTYwO2Nj
aFRleHQ6KDAsMSksMjg4LDMyO3BzelRleHQ6KDI1LDk2KSwzMjAsMzI7X19hczo6KDI4LDM1
NzEpOl9fYXNfXzQkXzQxUkM0JF80MTsyQS47JF80MTo6KDI4LDM1NzYpPSMoMjgsMzU3MCks
KDI4LDM1NzMpLCgyOCwzNTczKSwoMjgsMzU3NCksKDAsMjApOzpfXzQkXzQxUkM0JF80MTsy
QS4oMjgsMzU3Nyk9IygyOCwzNTcwKSwoMjgsMzU3MyksKDI4LDM1NzMpLCgwLDIwKTs6X180
JF80MTsyQS47OywoMCwyMCk7Ol9fYXNfXzQkXzQxUkM0JF80MTsyQS47JF80MTo6KDI4LDM1
NzYpOl9fNCRfNDFSQzQkXzQxOzJBLigyOCwzNTc3KTpfXzQkXzQxOzJBLjs7AExQVEJOT1RJ
Rlk6dCgyOCwzNTc4KT0oMjgsMzU3MykAVEJTQVZFUEFSQU1TOnQoMjgsMzU3OSk9czEyaGty
OigyNSw0NCksMCwzMjtwc3pTdWJLZXk6KDI1LDgzKSwzMiwzMjtwc3pWYWx1ZU5hbWU6KDI1
LDgzKSw2NCwzMjtfX2FzOjooMjgsMzU4MCk9IygyOCwzNTc5KSwoMjgsMzU4MSk9JigyOCwz
NTc5KSwoMjgsMzU4Mik9KigyOCwzNTc5KSwoMjgsMzU4Myk9JigyOCwzNTg0KT1zMTJoa3I6
KDI1LDQ0KSwwLDMyO3BzelN1YktleTooMjUsODMpLDMyLDMyO3BzelZhbHVlTmFtZTooMjUs
ODMpLDY0LDMyO19fYXM6OigyOCwzNTgwKTpfX2FzX180JF80MlJDNCRfNDI7MkEuOyRfNDI6
OigyOCwzNTg1KT0jKDI4LDM1NzkpLCgyOCwzNTgyKSwoMjgsMzU4MiksKDI4LDM1ODMpLCgw
LDIwKTs6X180JF80MlJDNCRfNDI7MkEuKDI4LDM1ODYpPSMoMjgsMzU3OSksKDI4LDM1ODIp
LCgyOCwzNTgyKSwoMCwyMCk7Ol9fNCRfNDI7MkEuOzssKDAsMjApOzpfX2FzX180JF80MlJD
NCRfNDI7MkEuOyRfNDI6OigyOCwzNTg1KTpfXzQkXzQyUkM0JF80MjsyQS4oMjgsMzU4Nik6
X180JF80MjsyQS47OwBfVENfSElUVEVTVElORk86VHQoMjgsMzU4Nyk9czEycHQ6KDI4LDMw
OSksMCw2NDtmbGFnczooMjUsMTUwKSw2NCwzMjtfX2FzOjooMjgsMzU4OCk9IyMoMjgsMzU4
OSk9JigyOCwzNTg3KTs6UkMxNV9UQ19ISVRURVNUSU5GTzsyQS47X1RDX0hJVFRFU1RJTkZP
OjooMjgsMzU5MCk9IyMoMjgsMzU5MSk9KigyOCwzNTg3KTs6UkMxNV9UQ19ISVRURVNUSU5G
TzsyQS4oMjgsMzU5Mik9IyMoMjgsMzU5MSk7OjsyQS47OwBUQ19ISVRURVNUSU5GTzp0KDI4
LDM1OTMpPSgyOCwzNTg3KQBfVENfSVRFTTpUdCgyOCwzNTk0KT1zMjhtYXNrOigyNSwxNTAp
LDAsMzI7bHBSZXNlcnZlZDE6KDI1LDE1MCksMzIsMzI7bHBSZXNlcnZlZDI6KDI1LDE1MCks
NjQsMzI7cHN6VGV4dDooMjUsOTYpLDk2LDMyO2NjaFRleHRNYXg6KDAsMSksMTI4LDMyO2lJ
bWFnZTooMCwxKSwxNjAsMzI7bFBhcmFtOigyNSw3MCksMTkyLDMyO19fYXM6OigyOCwzNTk1
KT0jIygyOCwzNTk2KT0mKDI4LDM1OTQpOzpSQzhfVENfSVRFTTsyQS47X1RDX0lURU06Oigy
OCwzNTk3KT0jIygyOCwzNTk4KT0qKDI4LDM1OTQpOzpSQzhfVENfSVRFTTsyQS4oMjgsMzU5
OSk9IyMoMjgsMzU5OCk7OjsyQS47OwBUQ19JVEVNOnQoMjgsMzYwMCk9KDI4LDM1OTQpAF9U
Q19JVEVNSEVBREVSOlR0KDI4LDM2MDEpPXMyNG1hc2s6KDI1LDE1MCksMCwzMjtscFJlc2Vy
dmVkMTooMjUsMTUwKSwzMiwzMjtscFJlc2VydmVkMjooMjUsMTUwKSw2NCwzMjtwc3pUZXh0
OigyNSw5NiksOTYsMzI7Y2NoVGV4dE1heDooMCwxKSwxMjgsMzI7aUltYWdlOigwLDEpLDE2
MCwzMjtfX2FzOjooMjgsMzYwMik9IyMoMjgsMzYwMyk9JigyOCwzNjAxKTs6UkMxNF9UQ19J
VEVNSEVBREVSOzJBLjtfVENfSVRFTUhFQURFUjo6KDI4LDM2MDQpPSMjKDI4LDM2MDUpPSoo
MjgsMzYwMSk7OlJDMTRfVENfSVRFTUhFQURFUjsyQS4oMjgsMzYwNik9IyMoMjgsMzYwNSk7
OjsyQS47OwBUQ19JVEVNSEVBREVSOnQoMjgsMzYwNyk9KDI4LDM2MDEpAF9UQ19LRVlET1dO
OlR0KDI4LDM2MDgpPXMyMGhkcjooMjgsMTc1MSksMCw5Njt3VktleTooMjUsMTUzKSw5Niwx
NjtmbGFnczooMjUsMTUwKSwxMjgsMzI7X19hczo6KDI4LDM2MDkpPSMjKDI4LDM2MTApPSYo
MjgsMzYwOCk7OlJDMTFfVENfS0VZRE9XTjsyQS47X1RDX0tFWURPV046OigyOCwzNjExKT0j
IygyOCwzNjEyKT0qKDI4LDM2MDgpOzpSQzExX1RDX0tFWURPV047MkEuKDI4LDM2MTMpPSMj
KDI4LDM2MTIpOzo7MkEuOzsAVENfS0VZRE9XTjp0KDI4LDM2MTQpPSgyOCwzNjA4KQBfdGV4
dHJhbmdlOlR0KDI4LDM2MTUpPXMxMmNocmc6KDI4LDQwMSksMCw2NDtscHN0clRleHQ6KDI1
LDk0KSw2NCwzMjtfX2FzOjooMjgsMzYxNik9IyMoMjgsMzYxNyk9JigyOCwzNjE1KTs6UkMx
MF90ZXh0cmFuZ2U7MkEuO190ZXh0cmFuZ2U6OigyOCwzNjE4KT0jIygyOCwzNjE5KT0qKDI4
LDM2MTUpOzpSQzEwX3RleHRyYW5nZTsyQS4oMjgsMzYyMCk9IyMoMjgsMzYxOSk7OjsyQS47
OwBURVhUUkFOR0U6dCgyOCwzNjIxKT0oMjgsMzYxNSkAX1RJTUVfWk9ORV9JTkZPUk1BVElP
TjpUdCgyOCwzNjIyKT1zMTcyQmlhczooMjUsMTMpLDAsMzI7U3RhbmRhcmROYW1lOigyOCw0
NDcpLDMyLDUxMjtTdGFuZGFyZERhdGU6KDI4LDIxNjApLDU0NCwxMjg7U3RhbmRhcmRCaWFz
OigyNSwxMyksNjcyLDMyO0RheWxpZ2h0TmFtZTooMjgsNDQ3KSw3MDQsNTEyO0RheWxpZ2h0
RGF0ZTooMjgsMjE2MCksMTIxNiwxMjg7RGF5bGlnaHRCaWFzOigyNSwxMyksMTM0NCwzMjtf
X2FzOjooMjgsMzYyMyk9IyMoMjgsMzYyNCk9JigyOCwzNjIyKTs6UkMyMl9USU1FX1pPTkVf
SU5GT1JNQVRJT047MkEuO19USU1FX1pPTkVfSU5GT1JNQVRJT046OigyOCwzNjI1KT0jIygy
OCwzNjI2KT0qKDI4LDM2MjIpOzpSQzIyX1RJTUVfWk9ORV9JTkZPUk1BVElPTjsyQS4oMjgs
MzYyNyk9IyMoMjgsMzYyNik7OjsyQS47OwBUSU1FX1pPTkVfSU5GT1JNQVRJT046dCgyOCwz
NjI4KT0oMjgsMzYyMikATFBUSU1FX1pPTkVfSU5GT1JNQVRJT046dCgyOCwzNjI5KT0oMjgs
MzYyNikAdGFnVE9HR0xFS0VZUzpUdCgyOCwzNjMwKT1zOGNiU2l6ZTooMjUsMTQpLDAsMzI7
ZHdGbGFnczooMjUsMTQpLDMyLDMyO19fYXM6OigyOCwzNjMxKT0jIygyOCwzNjMyKT0mKDI4
LDM2MzApOzpSQzEzdGFnVE9HR0xFS0VZUzsyQS47dGFnVE9HR0xFS0VZUzo6KDI4LDM2MzMp
PSMjKDI4LDM2MzQpPSooMjgsMzYzMCk7OlJDMTN0YWdUT0dHTEVLRVlTOzJBLigyOCwzNjM1
KT0jIygyOCwzNjM0KTs6OzJBLjs7AFRPR0dMRUtFWVM6dCgyOCwzNjM2KT0oMjgsMzYzMCkA
X1RPS0VOX1NPVVJDRTpUdCgyOCwzNjM3KT1zMTZTb3VyY2VOYW1lOigyOCwzNjM4KT1hcigw
LDEpOzA7NzsoMCwyKSwwLDY0O1NvdXJjZUlkZW50aWZpZXI6KDI4LDIyNzMpLDY0LDY0O19f
YXM6OigyOCwzNjM5KT0jIygyOCwzNjQwKT0mKDI4LDM2MzcpOzpSQzEzX1RPS0VOX1NPVVJD
RTsyQS47X1RPS0VOX1NPVVJDRTo6KDI4LDM2NDEpPSMjKDI4LDM2NDIpPSooMjgsMzYzNyk7
OlJDMTNfVE9LRU5fU09VUkNFOzJBLigyOCwzNjQzKT0jIygyOCwzNjQyKTs6OzJBLjs7AFRP
S0VOX1NPVVJDRTp0KDI4LDM2NDQpPSgyOCwzNjM3KQBfVE9LRU5fQ09OVFJPTDpUdCgyOCwz
NjQ1KT1zNDBUb2tlbklkOigyOCwyMjczKSwwLDY0O0F1dGhlbnRpY2F0aW9uSWQ6KDI4LDIy
NzMpLDY0LDY0O01vZGlmaWVkSWQ6KDI4LDIyNzMpLDEyOCw2NDtUb2tlblNvdXJjZTooMjgs
MzY0NCksMTkyLDEyODtfX2FzOjooMjgsMzY0Nik9IyMoMjgsMzY0Nyk9JigyOCwzNjQ1KTs6
UkMxNF9UT0tFTl9DT05UUk9MOzJBLjtfVE9LRU5fQ09OVFJPTDo6KDI4LDM2NDgpPSMjKDI4
LDM2NDkpPSooMjgsMzY0NSk7OlJDMTRfVE9LRU5fQ09OVFJPTDsyQS4oMjgsMzY1MCk9IyMo
MjgsMzY0OSk7OjsyQS47OwBUT0tFTl9DT05UUk9MOnQoMjgsMzY1MSk9KDI4LDM2NDUpAF9U
T0tFTl9ERUZBVUxUX0RBQ0w6VHQoMjgsMzY1Mik9czREZWZhdWx0RGFjbDooMjgsNjIpLDAs
MzI7X19hczo6KDI4LDM2NTMpPSMjKDI4LDM2NTQpPSYoMjgsMzY1Mik7OlJDMTlfVE9LRU5f
REVGQVVMVF9EQUNMOzJBLjtfVE9LRU5fREVGQVVMVF9EQUNMOjooMjgsMzY1NSk9IyMoMjgs
MzY1Nik9KigyOCwzNjUyKTs6UkMxOV9UT0tFTl9ERUZBVUxUX0RBQ0w7MkEuKDI4LDM2NTcp
PSMjKDI4LDM2NTYpOzo7MkEuOzsAVE9LRU5fREVGQVVMVF9EQUNMOnQoMjgsMzY1OCk9KDI4
LDM2NTIpAF9UT0tFTl9HUk9VUFM6VHQoMjgsMzY1OSk9czEyR3JvdXBDb3VudDooMjUsMTQp
LDAsMzI7R3JvdXBzOigyOCwzMzcxKSwzMiw2NDtfX2FzOjooMjgsMzY2MCk9IyMoMjgsMzY2
MSk9JigyOCwzNjU5KTs6UkMxM19UT0tFTl9HUk9VUFM7MkEuO19UT0tFTl9HUk9VUFM6Oigy
OCwzNjYyKT0jIygyOCwzNjYzKT0qKDI4LDM2NTkpOzpSQzEzX1RPS0VOX0dST1VQUzsyQS4o
MjgsMzY2NCk9IyMoMjgsMzY2Myk7OjsyQS47OwBUT0tFTl9HUk9VUFM6dCgyOCwzNjY1KT0o
MjgsMzY1OSkAUFRPS0VOX0dST1VQUzp0KDI4LDM2NjYpPSgyOCwzNjYzKQBMUFRPS0VOX0dS
T1VQUzp0KDI4LDM2NjcpPSgyOCwzNjYzKQBfVE9LRU5fT1dORVI6VHQoMjgsMzY2OCk9czRP
d25lcjooMjgsMjE4NSksMCwzMjtfX2FzOjooMjgsMzY2OSk9IyMoMjgsMzY3MCk9JigyOCwz
NjY4KTs6UkMxMl9UT0tFTl9PV05FUjsyQS47X1RPS0VOX09XTkVSOjooMjgsMzY3MSk9IyMo
MjgsMzY3Mik9KigyOCwzNjY4KTs6UkMxMl9UT0tFTl9PV05FUjsyQS4oMjgsMzY3Myk9IyMo
MjgsMzY3Mik7OjsyQS47OwBUT0tFTl9PV05FUjp0KDI4LDM2NzQpPSgyOCwzNjY4KQBfVE9L
RU5fUFJJTUFSWV9HUk9VUDpUdCgyOCwzNjc1KT1zNFByaW1hcnlHcm91cDooMjgsMjE4NSks
MCwzMjtfX2FzOjooMjgsMzY3Nik9IyMoMjgsMzY3Nyk9JigyOCwzNjc1KTs6UkMyMF9UT0tF
Tl9QUklNQVJZX0dST1VQOzJBLjtfVE9LRU5fUFJJTUFSWV9HUk9VUDo6KDI4LDM2NzgpPSMj
KDI4LDM2NzkpPSooMjgsMzY3NSk7OlJDMjBfVE9LRU5fUFJJTUFSWV9HUk9VUDsyQS4oMjgs
MzY4MCk9IyMoMjgsMzY3OSk7OjsyQS47OwBUT0tFTl9QUklNQVJZX0dST1VQOnQoMjgsMzY4
MSk9KDI4LDM2NzUpAF9UT0tFTl9QUklWSUxFR0VTOlR0KDI4LDM2ODIpPXMxNlByaXZpbGVn
ZUNvdW50OigyNSwxNCksMCwzMjtQcml2aWxlZ2VzOigyOCwyMjg0KSwzMiw5NjtfX2FzOjoo
MjgsMzY4Myk9IyMoMjgsMzY4NCk9JigyOCwzNjgyKTs6UkMxN19UT0tFTl9QUklWSUxFR0VT
OzJBLjtfVE9LRU5fUFJJVklMRUdFUzo6KDI4LDM2ODUpPSMjKDI4LDM2ODYpPSooMjgsMzY4
Mik7OlJDMTdfVE9LRU5fUFJJVklMRUdFUzsyQS4oMjgsMzY4Nyk9IyMoMjgsMzY4Nik7Ojsy
QS47OwBUT0tFTl9QUklWSUxFR0VTOnQoMjgsMzY4OCk9KDI4LDM2ODIpAFBUT0tFTl9QUklW
SUxFR0VTOnQoMjgsMzY4OSk9KDI4LDM2ODYpAExQVE9LRU5fUFJJVklMRUdFUzp0KDI4LDM2
OTApPSgyOCwzNjg2KQBfVE9LRU5fU1RBVElTVElDUzpUdCgyOCwzNjkxKT1zNTZUb2tlbklk
OigyOCwyMjczKSwwLDY0O0F1dGhlbnRpY2F0aW9uSWQ6KDI4LDIyNzMpLDY0LDY0O0V4cGly
YXRpb25UaW1lOigyOCw5NjkpLDEyOCw2NDtUb2tlblR5cGU6KDI1LDE3MiksMTkyLDMyO0lt
cGVyc29uYXRpb25MZXZlbDooMjUsMTY0KSwyMjQsMzI7RHluYW1pY0NoYXJnZWQ6KDI1LDE0
KSwyNTYsMzI7RHluYW1pY0F2YWlsYWJsZTooMjUsMTQpLDI4OCwzMjtHcm91cENvdW50Oigy
NSwxNCksMzIwLDMyO1ByaXZpbGVnZUNvdW50OigyNSwxNCksMzUyLDMyO01vZGlmaWVkSWQ6
KDI4LDIyNzMpLDM4NCw2NDtfX2FzOjooMjgsMzY5Mik9IyMoMjgsMzY5Myk9JigyOCwzNjkx
KTs6UkMxN19UT0tFTl9TVEFUSVNUSUNTOzJBLjtfVE9LRU5fU1RBVElTVElDUzo6KDI4LDM2
OTQpPSMjKDI4LDM2OTUpPSooMjgsMzY5MSk7OlJDMTdfVE9LRU5fU1RBVElTVElDUzsyQS4o
MjgsMzY5Nik9IyMoMjgsMzY5NSk7OjsyQS47OwBUT0tFTl9TVEFUSVNUSUNTOnQoMjgsMzY5
Nyk9KDI4LDM2OTEpAF9UT0tFTl9VU0VSOlR0KDI4LDM2OTgpPXM4VXNlcjooMjgsMzM2OSks
MCw2NDtfX2FzOjooMjgsMzY5OSk9IyMoMjgsMzcwMCk9JigyOCwzNjk4KTs6UkMxMV9UT0tF
Tl9VU0VSOzJBLjtfVE9LRU5fVVNFUjo6KDI4LDM3MDEpPSMjKDI4LDM3MDIpPSooMjgsMzY5
OCk7OlJDMTFfVE9LRU5fVVNFUjsyQS4oMjgsMzcwMyk9IyMoMjgsMzcwMik7OjsyQS47OwBU
T0tFTl9VU0VSOnQoMjgsMzcwNCk9KDI4LDM2OTgpAFRPT0xJTkZPOnQoMjgsMzcwNSk9czQw
Y2JTaXplOigyNSwxNTApLDAsMzI7dUZsYWdzOigyNSwxNTApLDMyLDMyO2h3bmQ6KDI1LDYx
KSw2NCwzMjt1SWQ6KDI1LDE1MCksOTYsMzI7cmVjdDooMjgsMTEzKSwxMjgsMTI4O2hpbnN0
OigyNSw0MyksMjU2LDMyO2xwc3pUZXh0OigyNSw5NiksMjg4LDMyO19fYXM6OigyOCwzNzA2
KT0jKDI4LDM3MDUpLCgyOCwzNzA3KT0mKDI4LDM3MDUpLCgyOCwzNzA4KT0qKDI4LDM3MDUp
LCgyOCwzNzA5KT0mKDI4LDM3MTApPXM0MGNiU2l6ZTooMjUsMTUwKSwwLDMyO3VGbGFnczoo
MjUsMTUwKSwzMiwzMjtod25kOigyNSw2MSksNjQsMzI7dUlkOigyNSwxNTApLDk2LDMyO3Jl
Y3Q6KDI4LDExMyksMTI4LDEyODtoaW5zdDooMjUsNDMpLDI1NiwzMjtscHN6VGV4dDooMjUs
OTYpLDI4OCwzMjtfX2FzOjooMjgsMzcwNik6X19hc19fNCRfNDNSQzQkXzQzOzJBLjskXzQz
OjooMjgsMzcxMSk9IygyOCwzNzA1KSwoMjgsMzcwOCksKDI4LDM3MDgpLCgyOCwzNzA5KSwo
MCwyMCk7Ol9fNCRfNDNSQzQkXzQzOzJBLigyOCwzNzEyKT0jKDI4LDM3MDUpLCgyOCwzNzA4
KSwoMjgsMzcwOCksKDAsMjApOzpfXzQkXzQzOzJBLjs7LCgwLDIwKTs6X19hc19fNCRfNDNS
QzQkXzQzOzJBLjskXzQzOjooMjgsMzcxMSk6X180JF80M1JDNCRfNDM7MkEuKDI4LDM3MTIp
Ol9fNCRfNDM7MkEuOzsAUFRPT0xJTkZPOnQoMjgsMzcxMyk9KDI4LDM3MDgpAExQVE9PTElO
Rk86dCgyOCwzNzE0KT0oMjgsMzcwOCkAVE9PTFRJUFRFWFQ6dCgyOCwzNzE1KT1zMTA0aGRy
OigyOCwxNzUxKSwwLDk2O2xwc3pUZXh0OigyNSw5NiksOTYsMzI7c3pUZXh0OigyOCwzMzM3
KSwxMjgsNjQwO2hpbnN0OigyNSw0MyksNzY4LDMyO3VGbGFnczooMjUsMTUwKSw4MDAsMzI7
X19hczo6KDI4LDM3MTYpPSMoMjgsMzcxNSksKDI4LDM3MTcpPSYoMjgsMzcxNSksKDI4LDM3
MTgpPSooMjgsMzcxNSksKDI4LDM3MTkpPSYoMjgsMzcyMCk9czEwNGhkcjooMjgsMTc1MSks
MCw5NjtscHN6VGV4dDooMjUsOTYpLDk2LDMyO3N6VGV4dDooMjgsMzMzNyksMTI4LDY0MDto
aW5zdDooMjUsNDMpLDc2OCwzMjt1RmxhZ3M6KDI1LDE1MCksODAwLDMyO19fYXM6OigyOCwz
NzE2KTpfX2FzX180JF80NFJDNCRfNDQ7MkEuOyRfNDQ6OigyOCwzNzIxKT0jKDI4LDM3MTUp
LCgyOCwzNzE4KSwoMjgsMzcxOCksKDI4LDM3MTkpLCgwLDIwKTs6X180JF80NFJDNCRfNDQ7
MkEuKDI4LDM3MjIpPSMoMjgsMzcxNSksKDI4LDM3MTgpLCgyOCwzNzE4KSwoMCwyMCk7Ol9f
NCRfNDQ7MkEuOzssKDAsMjApOzpfX2FzX180JF80NFJDNCRfNDQ7MkEuOyRfNDQ6OigyOCwz
NzIxKTpfXzQkXzQ0UkM0JF80NDsyQS4oMjgsMzcyMik6X180JF80NDsyQS47OwBMUFRPT0xU
SVBURVhUOnQoMjgsMzcyMyk9KDI4LDM3MTgpAHRhZ1RQTVBBUkFNUzpUdCgyOCwzNzI0KT1z
MjBjYlNpemU6KDI1LDE1MCksMCwzMjtyY0V4Y2x1ZGU6KDI4LDExMyksMzIsMTI4O19fYXM6
OigyOCwzNzI1KT0jIygyOCwzNzI2KT0mKDI4LDM3MjQpOzpSQzEydGFnVFBNUEFSQU1TOzJB
Ljt0YWdUUE1QQVJBTVM6OigyOCwzNzI3KT0jIygyOCwzNzI4KT0qKDI4LDM3MjQpOzpSQzEy
dGFnVFBNUEFSQU1TOzJBLigyOCwzNzI5KT0jIygyOCwzNzI4KTs6OzJBLjs7AFRQTVBBUkFN
Uzp0KDI4LDM3MzApPSgyOCwzNzI0KQBMUFRQTVBBUkFNUzp0KDI4LDM3MzEpPSgyOCwzNzI4
KQBfVFJBTlNNSVRfRklMRV9CVUZGRVJTOlR0KDI4LDM3MzIpPXMxNkhlYWQ6KDI1LDEzNiks
MCwzMjtIZWFkTGVuZ3RoOigyNSwxNCksMzIsMzI7VGFpbDooMjUsMTM2KSw2NCwzMjtUYWls
TGVuZ3RoOigyNSwxNCksOTYsMzI7X19hczo6KDI4LDM3MzMpPSMjKDI4LDM3MzQpPSYoMjgs
MzczMik7OlJDMjJfVFJBTlNNSVRfRklMRV9CVUZGRVJTOzJBLjtfVFJBTlNNSVRfRklMRV9C
VUZGRVJTOjooMjgsMzczNSk9IyMoMjgsMzczNik9KigyOCwzNzMyKTs6UkMyMl9UUkFOU01J
VF9GSUxFX0JVRkZFUlM7MkEuKDI4LDM3MzcpPSMjKDI4LDM3MzYpOzo7MkEuOzsAVFJBTlNN
SVRfRklMRV9CVUZGRVJTOnQoMjgsMzczOCk9KDI4LDM3MzIpAF9UVF9ISVRURVNUSU5GTzpU
dCgyOCwzNzM5KT1zNTJod25kOigyNSw2MSksMCwzMjtwdDooMjgsMzA5KSwzMiw2NDt0aToo
MjgsMzcwNSksOTYsMzIwO19fYXM6OigyOCwzNzQwKT0jIygyOCwzNzQxKT0mKDI4LDM3Mzkp
OzpSQzE1X1RUX0hJVFRFU1RJTkZPOzJBLjtfVFRfSElUVEVTVElORk86OigyOCwzNzQyKT0j
IygyOCwzNzQzKT0qKDI4LDM3MzkpOzpSQzE1X1RUX0hJVFRFU1RJTkZPOzJBLigyOCwzNzQ0
KT0jIygyOCwzNzQzKTs6OzJBLjs7AFRUSElUVEVTVElORk86dCgyOCwzNzQ1KT0oMjgsMzcz
OSkATFBISVRURVNUSU5GTzp0KDI4LDM3NDYpPSgyOCwzNzQzKQB0YWdUVFBPTFlDVVJWRTpU
dCgyOCwzNzQ3KT1zMTJ3VHlwZTooMjUsMTUzKSwwLDE2O2NwZng6KDI1LDE1MyksMTYsMTY7
YXBmeDooMjgsMzc0OCk9YXIoMCwxKTswOzA7KDI4LDMxMiksMzIsNjQ7X19hczo6KDI4LDM3
NDkpPSMjKDI4LDM3NTApPSYoMjgsMzc0Nyk7OlJDMTR0YWdUVFBPTFlDVVJWRTsyQS47dGFn
VFRQT0xZQ1VSVkU6OigyOCwzNzUxKT0jIygyOCwzNzUyKT0qKDI4LDM3NDcpOzpSQzE0dGFn
VFRQT0xZQ1VSVkU7MkEuKDI4LDM3NTMpPSMjKDI4LDM3NTIpOzo7MkEuOzsAVFRQT0xZQ1VS
VkU6dCgyOCwzNzU0KT0oMjgsMzc0NykATFBUVFBPTFlDVVJWRTp0KDI4LDM3NTUpPSgyOCwz
NzUyKQBfVFRQT0xZR09OSEVBREVSOlR0KDI4LDM3NTYpPXMxNmNiOigyNSwxNCksMCwzMjtk
d1R5cGU6KDI1LDE0KSwzMiwzMjtwZnhTdGFydDooMjgsMzE4KSw2NCw2NDtfX2FzOjooMjgs
Mzc1Nyk9IyMoMjgsMzc1OCk9JigyOCwzNzU2KTs6UkMxNl9UVFBPTFlHT05IRUFERVI7MkEu
O19UVFBPTFlHT05IRUFERVI6OigyOCwzNzU5KT0jIygyOCwzNzYwKT0qKDI4LDM3NTYpOzpS
QzE2X1RUUE9MWUdPTkhFQURFUjsyQS4oMjgsMzc2MSk9IyMoMjgsMzc2MCk7OjsyQS47OwBU
VFBPTFlHT05IRUFERVI6dCgyOCwzNzYyKT0oMjgsMzc1NikATFBUVFBPTFlHT05IRUFERVI6
dCgyOCwzNzYzKT0oMjgsMzc2MCkAX1RWX0RJU1BJTkZPOlR0KDI4LDM3NjQpPXM1Mmhkcjoo
MjgsMTc1MSksMCw5NjtpdGVtOigyOCwyNjU5KSw5NiwzMjA7X19hczo6KDI4LDM3NjUpPSMj
KDI4LDM3NjYpPSYoMjgsMzc2NCk7OlJDMTJfVFZfRElTUElORk87MkEuO19UVl9ESVNQSU5G
Tzo6KDI4LDM3NjcpPSMjKDI4LDM3NjgpPSooMjgsMzc2NCk7OlJDMTJfVFZfRElTUElORk87
MkEuKDI4LDM3NjkpPSMjKDI4LDM3NjgpOzo7MkEuOzsAVFZfRElTUElORk86dCgyOCwzNzcw
KT0oMjgsMzc2NCkAX1RWSElUVEVTVElORk86VHQoMjgsMzc3MSk9czE2cHQ6KDI4LDMwOSks
MCw2NDtmbGFnczooMjUsMTUwKSw2NCwzMjtoSXRlbTooMjgsMjY1MCksOTYsMzI7X19hczo6
KDI4LDM3NzIpPSMjKDI4LDM3NzMpPSYoMjgsMzc3MSk7OlJDMTRfVFZISVRURVNUSU5GTzsy
QS47X1RWSElUVEVTVElORk86OigyOCwzNzc0KT0jIygyOCwzNzc1KT0qKDI4LDM3NzEpOzpS
QzE0X1RWSElUVEVTVElORk87MkEuKDI4LDM3NzYpPSMjKDI4LDM3NzUpOzo7MkEuOzsAVFZf
SElUVEVTVElORk86dCgyOCwzNzc3KT0oMjgsMzc3MSkATFBUVl9ISVRURVNUSU5GTzp0KDI4
LDM3NzgpPSgyOCwzNzc1KQBfVFZfSU5TRVJUU1RSVUNUOlR0KDI4LDM3NzkpPXM0OGhQYXJl
bnQ6KDI4LDI2NTApLDAsMzI7aEluc2VydEFmdGVyOigyOCwyNjUwKSwzMiwzMjtpdGVtOigy
OCwyNjU5KSw2NCwzMjA7X19hczo6KDI4LDM3ODApPSMjKDI4LDM3ODEpPSYoMjgsMzc3OSk7
OlJDMTZfVFZfSU5TRVJUU1RSVUNUOzJBLjtfVFZfSU5TRVJUU1RSVUNUOjooMjgsMzc4Mik9
IyMoMjgsMzc4Myk9KigyOCwzNzc5KTs6UkMxNl9UVl9JTlNFUlRTVFJVQ1Q7MkEuKDI4LDM3
ODQpPSMjKDI4LDM3ODMpOzo7MkEuOzsAVFZfSU5TRVJUU1RSVUNUOnQoMjgsMzc4NSk9KDI4
LDM3NzkpAExQVFZfSU5TRVJUU1RSVUNUOnQoMjgsMzc4Nik9KDI4LDM3ODMpAF9UVl9LRVlE
T1dOOlR0KDI4LDM3ODcpPXMyMGhkcjooMjgsMTc1MSksMCw5Njt3VktleTooMjUsMTUzKSw5
NiwxNjtmbGFnczooMjUsMTUwKSwxMjgsMzI7X19hczo6KDI4LDM3ODgpPSMjKDI4LDM3ODkp
PSYoMjgsMzc4Nyk7OlJDMTFfVFZfS0VZRE9XTjsyQS47X1RWX0tFWURPV046OigyOCwzNzkw
KT0jIygyOCwzNzkxKT0qKDI4LDM3ODcpOzpSQzExX1RWX0tFWURPV047MkEuKDI4LDM3OTIp
PSMjKDI4LDM3OTEpOzo7MkEuOzsAVFZfS0VZRE9XTjp0KDI4LDM3OTMpPSgyOCwzNzg3KQBf
VFZfU09SVENCOlR0KDI4LDM3OTQpPXMxMmhQYXJlbnQ6KDI4LDI2NTApLDAsMzI7bHBmbkNv
bXBhcmU6KDI1LDIwMCksMzIsMzI7bFBhcmFtOigyNSw3MCksNjQsMzI7X19hczo6KDI4LDM3
OTUpPSMjKDI4LDM3OTYpPSYoMjgsMzc5NCk7OlJDMTBfVFZfU09SVENCOzJBLjtfVFZfU09S
VENCOjooMjgsMzc5Nyk9IyMoMjgsMzc5OCk9KigyOCwzNzk0KTs6UkMxMF9UVl9TT1JUQ0I7
MkEuKDI4LDM3OTkpPSMjKDI4LDM3OTgpOzo7MkEuOzsAVFZfU09SVENCOnQoMjgsMzgwMCk9
KDI4LDM3OTQpAExQVFZfU09SVENCOnQoMjgsMzgwMSk9KDI4LDM3OTgpAFVEQUNDRUw6dCgy
OCwzODAyKT1zOG5TZWM6KDI1LDE1MCksMCwzMjtuSW5jOigyNSwxNTApLDMyLDMyO19fYXM6
OigyOCwzODAzKT0jKDI4LDM4MDIpLCgyOCwzODA0KT0mKDI4LDM4MDIpLCgyOCwzODA1KT0q
KDI4LDM4MDIpLCgyOCwzODA2KT0mKDI4LDM4MDcpPXM4blNlYzooMjUsMTUwKSwwLDMyO25J
bmM6KDI1LDE1MCksMzIsMzI7X19hczo6KDI4LDM4MDMpOl9fYXNfXzQkXzQ1UkM0JF80NTsy
QS47JF80NTo6KDI4LDM4MDgpPSMoMjgsMzgwMiksKDI4LDM4MDUpLCgyOCwzODA1KSwoMjgs
MzgwNiksKDAsMjApOzpfXzQkXzQ1UkM0JF80NTsyQS4oMjgsMzgwOSk9IygyOCwzODAyKSwo
MjgsMzgwNSksKDI4LDM4MDUpLCgwLDIwKTs6X180JF80NTsyQS47OywoMCwyMCk7Ol9fYXNf
XzQkXzQ1UkM0JF80NTsyQS47JF80NTo6KDI4LDM4MDgpOl9fNCRfNDVSQzQkXzQ1OzJBLigy
OCwzODA5KTpfXzQkXzQ1OzJBLjs7AF9VTEFSR0VfSU5URUdFUjpUdCgyOCwzODEwKT1zOExv
d1BhcnQ6KDI1LDE0KSwwLDMyO0hpZ2hQYXJ0OigyNSwxNCksMzIsMzI7X19hczo6KDI4LDM4
MTEpPSMjKDI4LDM4MTIpPSYoMjgsMzgxMCk7OlJDMTVfVUxBUkdFX0lOVEVHRVI7MkEuO19V
TEFSR0VfSU5URUdFUjo6KDI4LDM4MTMpPSMjKDI4LDM4MTQpPSooMjgsMzgxMCk7OlJDMTVf
VUxBUkdFX0lOVEVHRVI7MkEuKDI4LDM4MTUpPSMjKDI4LDM4MTQpOzo7MkEuOzsAVUxBUkdF
X0lOVEVHRVI6dCgyOCwzODE2KT0oMjgsMzgxMCkAUFVMQVJHRV9JTlRFR0VSOnQoMjgsMzgx
Nyk9KDI4LDM4MTQpAF9VTklWRVJTQUxfTkFNRV9JTkZPOlR0KDI4LDM4MTgpPXM0bHBVbml2
ZXJzYWxOYW1lOigyNSw5NiksMCwzMjtfX2FzOjooMjgsMzgxOSk9IyMoMjgsMzgyMCk9Jigy
OCwzODE4KTs6UkMyMF9VTklWRVJTQUxfTkFNRV9JTkZPOzJBLjtfVU5JVkVSU0FMX05BTUVf
SU5GTzo6KDI4LDM4MjEpPSMjKDI4LDM4MjIpPSooMjgsMzgxOCk7OlJDMjBfVU5JVkVSU0FM
X05BTUVfSU5GTzsyQS4oMjgsMzgyMyk9IyMoMjgsMzgyMik7OjsyQS47OwBVTklWRVJTQUxf
TkFNRV9JTkZPOnQoMjgsMzgyNCk9KDI4LDM4MTgpAHRhZ1VTRVJPQkpFQ1RGTEFHUzpUdCgy
OCwzODI1KT1zMTJmSW5oZXJpdDooMjUsMiksMCwzMjtmUmVzZXJ2ZWQ6KDI1LDIpLDMyLDMy
O2R3RmxhZ3M6KDI1LDE0KSw2NCwzMjtfX2FzOjooMjgsMzgyNik9IyMoMjgsMzgyNyk9Jigy
OCwzODI1KTs6UkMxOHRhZ1VTRVJPQkpFQ1RGTEFHUzsyQS47dGFnVVNFUk9CSkVDVEZMQUdT
OjooMjgsMzgyOCk9IyMoMjgsMzgyOSk9KigyOCwzODI1KTs6UkMxOHRhZ1VTRVJPQkpFQ1RG
TEFHUzsyQS4oMjgsMzgzMCk9IyMoMjgsMzgyOSk7OjsyQS47OwBVU0VST0JKRUNURkxBR1M6
dCgyOCwzODMxKT0oMjgsMzgyNSkAdmFsdWVfZW50OlR0KDI4LDM4MzIpPXMxNnZlX3ZhbHVl
bmFtZTooMjUsOTYpLDAsMzI7dmVfdmFsdWVsZW46KDI1LDE0KSwzMiwzMjt2ZV92YWx1ZXB0
cjooMjUsMTQpLDY0LDMyO3ZlX3R5cGU6KDI1LDE0KSw5NiwzMjtfX2FzOjooMjgsMzgzMyk9
IyMoMjgsMzgzNCk9JigyOCwzODMyKTs6UkM5dmFsdWVfZW50OzJBLjt2YWx1ZV9lbnQ6Oigy
OCwzODM1KT0jIygyOCwzODM2KT0qKDI4LDM4MzIpOzpSQzl2YWx1ZV9lbnQ7MkEuKDI4LDM4
MzcpPSMjKDI4LDM4MzYpOzo7MkEuOzsAVkFMRU5UOnQoMjgsMzgzOCk9KDI4LDM4MzIpAFBW
QUxFTlQ6dCgyOCwzODM5KT0oMjgsMzgzNikAX1ZFUklGWV9JTkZPUk1BVElPTjpUdCgyOCwz
ODQwKT1zMTJTdGFydGluZ09mZnNldDooMjgsOTY5KSwwLDY0O0xlbmd0aDooMjUsMTQpLDY0
LDMyO19fYXM6OigyOCwzODQxKT0jIygyOCwzODQyKT0mKDI4LDM4NDApOzpSQzE5X1ZFUklG
WV9JTkZPUk1BVElPTjsyQS47X1ZFUklGWV9JTkZPUk1BVElPTjo6KDI4LDM4NDMpPSMjKDI4
LDM4NDQpPSooMjgsMzg0MCk7OlJDMTlfVkVSSUZZX0lORk9STUFUSU9OOzJBLigyOCwzODQ1
KT0jIygyOCwzODQ0KTs6OzJBLjs7AFZFUklGWV9JTkZPUk1BVElPTjp0KDI4LDM4NDYpPSgy
OCwzODQwKQBfVlNfRklYRURGSUxFSU5GTzpUdCgyOCwzODQ3KT1zNTJkd1NpZ25hdHVyZToo
MjUsMTQpLDAsMzI7ZHdTdHJ1Y1ZlcnNpb246KDI1LDE0KSwzMiwzMjtkd0ZpbGVWZXJzaW9u
TVM6KDI1LDE0KSw2NCwzMjtkd0ZpbGVWZXJzaW9uTFM6KDI1LDE0KSw5NiwzMjtkd1Byb2R1
Y3RWZXJzaW9uTVM6KDI1LDE0KSwxMjgsMzI7ZHdQcm9kdWN0VmVyc2lvbkxTOigyNSwxNCks
MTYwLDMyO2R3RmlsZUZsYWdzTWFzazooMjUsMTQpLDE5MiwzMjtkd0ZpbGVGbGFnczooMjUs
MTQpLDIyNCwzMjtkd0ZpbGVPUzooMjUsMTQpLDI1NiwzMjtkd0ZpbGVUeXBlOigyNSwxNCks
Mjg4LDMyO2R3RmlsZVN1YnR5cGU6KDI1LDE0KSwzMjAsMzI7ZHdGaWxlRGF0ZU1TOigyNSwx
NCksMzUyLDMyO2R3RmlsZURhdGVMUzooMjUsMTQpLDM4NCwzMjtfX2FzOjooMjgsMzg0OCk9
IyMoMjgsMzg0OSk9JigyOCwzODQ3KTs6UkMxN19WU19GSVhFREZJTEVJTkZPOzJBLjtfVlNf
RklYRURGSUxFSU5GTzo6KDI4LDM4NTApPSMjKDI4LDM4NTEpPSooMjgsMzg0Nyk7OlJDMTdf
VlNfRklYRURGSUxFSU5GTzsyQS4oMjgsMzg1Mik9IyMoMjgsMzg1MSk7OjsyQS47OwBWU19G
SVhFREZJTEVJTkZPOnQoMjgsMzg1Myk9KDI4LDM4NDcpAF9XSU4zMl9GSU5EX0RBVEFBOlR0
KDI4LDM4NTQpPXMzMjBkd0ZpbGVBdHRyaWJ1dGVzOigyNSwxNCksMCwzMjtmdENyZWF0aW9u
VGltZTooMjgsMjg1KSwzMiw2NDtmdExhc3RBY2Nlc3NUaW1lOigyOCwyODUpLDk2LDY0O2Z0
TGFzdFdyaXRlVGltZTooMjgsMjg1KSwxNjAsNjQ7bkZpbGVTaXplSGlnaDooMjUsMTQpLDIy
NCwzMjtuRmlsZVNpemVMb3c6KDI1LDE0KSwyNTYsMzI7ZHdSZXNlcnZlZDA6KDI1LDE0KSwy
ODgsMzI7ZHdSZXNlcnZlZDE6KDI1LDE0KSwzMjAsMzI7Y0ZpbGVOYW1lOigyOCwxMTYxKSwz
NTIsMjA4MDtjQWx0ZXJuYXRlRmlsZU5hbWU6KDI4LDE5MTUpLDI0MzIsMTEyO19fYXM6Oigy
OCwzODU1KT0jIygyOCwzODU2KT0mKDI4LDM4NTQpOzpSQzE3X1dJTjMyX0ZJTkRfREFUQUE7
MkEuO19XSU4zMl9GSU5EX0RBVEFBOjooMjgsMzg1Nyk9IyMoMjgsMzg1OCk9KigyOCwzODU0
KTs6UkMxN19XSU4zMl9GSU5EX0RBVEFBOzJBLigyOCwzODU5KT0jIygyOCwzODU4KTs6OzJB
Ljs7AFdJTjMyX0ZJTkRfREFUQUE6dCgyOCwzODYwKT0oMjgsMzg1NCkATFBXSU4zMl9GSU5E
X0RBVEFBOnQoMjgsMzg2MSk9KDI4LDM4NTgpAFBXSU4zMl9GSU5EX0RBVEFBOnQoMjgsMzg2
Mik9KDI4LDM4NTgpAF9XSU4zMl9GSU5EX0RBVEFXOlR0KDI4LDM4NjMpPXM1OTJkd0ZpbGVB
dHRyaWJ1dGVzOigyNSwxNCksMCwzMjtmdENyZWF0aW9uVGltZTooMjgsMjg1KSwzMiw2NDtm
dExhc3RBY2Nlc3NUaW1lOigyOCwyODUpLDk2LDY0O2Z0TGFzdFdyaXRlVGltZTooMjgsMjg1
KSwxNjAsNjQ7bkZpbGVTaXplSGlnaDooMjUsMTQpLDIyNCwzMjtuRmlsZVNpemVMb3c6KDI1
LDE0KSwyNTYsMzI7ZHdSZXNlcnZlZDA6KDI1LDE0KSwyODgsMzI7ZHdSZXNlcnZlZDE6KDI1
LDE0KSwzMjAsMzI7Y0ZpbGVOYW1lOigyOCwzODY0KT1hcigwLDEpOzA7MjU5OygwLDIxKSwz
NTIsNDE2MDtjQWx0ZXJuYXRlRmlsZU5hbWU6KDI4LDM4NjUpPWFyKDAsMSk7MDsxMzsoMCwy
MSksNDUxMiwyMjQ7X19hczo6KDI4LDM4NjYpPSMjKDI4LDM4NjcpPSYoMjgsMzg2Myk7OlJD
MTdfV0lOMzJfRklORF9EQVRBVzsyQS47X1dJTjMyX0ZJTkRfREFUQVc6OigyOCwzODY4KT0j
IygyOCwzODY5KT0qKDI4LDM4NjMpOzpSQzE3X1dJTjMyX0ZJTkRfREFUQVc7MkEuKDI4LDM4
NzApPSMjKDI4LDM4NjkpOzo7MkEuOzsAV0lOMzJfRklORF9EQVRBVzp0KDI4LDM4NzEpPSgy
OCwzODYzKQBMUFdJTjMyX0ZJTkRfREFUQVc6dCgyOCwzODcyKT0oMjgsMzg2OSkAUFdJTjMy
X0ZJTkRfREFUQVc6dCgyOCwzODczKT0oMjgsMzg2OSkAV0lOMzJfRklORF9EQVRBOnQoMjgs
Mzg3NCk9KDI4LDM4NjApAExQV0lOMzJfRklORF9EQVRBOnQoMjgsMzg3NSk9KDI4LDM4NzYp
PSooMjgsMzg3NCkAUFdJTjMyX0ZJTkRfREFUQTp0KDI4LDM4NzcpPSgyOCwzODc2KQBfV0lO
MzJfU1RSRUFNX0lEOlR0KDI4LDM4NzgpPXMyNGR3U3RyZWFtSWQ6KDI1LDE0KSwwLDMyO2R3
U3RyZWFtQXR0cmlidXRlczooMjUsMTQpLDMyLDMyO1NpemU6KDI4LDk2OSksNjQsNjQ7ZHdT
dHJlYW1OYW1lU2l6ZTooMjUsMTQpLDEyOCwzMjtjU3RyZWFtTmFtZTooMjUsMTAyKSwxNjAs
MzI7X19hczo6KDI4LDM4NzkpPSMjKDI4LDM4ODApPSYoMjgsMzg3OCk7OlJDMTZfV0lOMzJf
U1RSRUFNX0lEOzJBLjtfV0lOMzJfU1RSRUFNX0lEOjooMjgsMzg4MSk9IyMoMjgsMzg4Mik9
KigyOCwzODc4KTs6UkMxNl9XSU4zMl9TVFJFQU1fSUQ7MkEuKDI4LDM4ODMpPSMjKDI4LDM4
ODIpOzo7MkEuOzsAV0lOMzJfU1RSRUFNX0lEOnQoMjgsMzg4NCk9KDI4LDM4NzgpAF9XSU5E
T1dQTEFDRU1FTlQ6VHQoMjgsMzg4NSk9czQ0bGVuZ3RoOigyNSwxNTApLDAsMzI7ZmxhZ3M6
KDI1LDE1MCksMzIsMzI7c2hvd0NtZDooMjUsMTUwKSw2NCwzMjtwdE1pblBvc2l0aW9uOigy
OCwzMDkpLDk2LDY0O3B0TWF4UG9zaXRpb246KDI4LDMwOSksMTYwLDY0O3JjTm9ybWFsUG9z
aXRpb246KDI4LDExMyksMjI0LDEyODtfX2FzOjooMjgsMzg4Nik9IyMoMjgsMzg4Nyk9Jigy
OCwzODg1KTs6UkMxNl9XSU5ET1dQTEFDRU1FTlQ7MkEuO19XSU5ET1dQTEFDRU1FTlQ6Oigy
OCwzODg4KT0jIygyOCwzODg5KT0qKDI4LDM4ODUpOzpSQzE2X1dJTkRPV1BMQUNFTUVOVDsy
QS4oMjgsMzg5MCk9IyMoMjgsMzg4OSk7OjsyQS47OwBXSU5ET1dQTEFDRU1FTlQ6dCgyOCwz
ODkxKT0oMjgsMzg4NSkAX1dORENMQVNTQTpUdCgyOCwzODkyKT1zNDBzdHlsZTooMjUsMTUw
KSwwLDMyO2xwZm5XbmRQcm9jOigyNSwyMDMpLDMyLDMyO2NiQ2xzRXh0cmE6KDAsMSksNjQs
MzI7Y2JXbmRFeHRyYTooMCwxKSw5NiwzMjtoSW5zdGFuY2U6KDI1LDE5KSwxMjgsMzI7aElj
b246KDI1LDQxKSwxNjAsMzI7aEN1cnNvcjooMjUsMjYpLDE5MiwzMjtoYnJCYWNrZ3JvdW5k
OigyNSwyMiksMjI0LDMyO2xwc3pNZW51TmFtZTooMjUsODEpLDI1NiwzMjtscHN6Q2xhc3NO
YW1lOigyNSw4MSksMjg4LDMyO19fYXM6OigyOCwzODkzKT0jIygyOCwzODk0KT0mKDI4LDM4
OTIpOzpSQzEwX1dORENMQVNTQTsyQS47X1dORENMQVNTQTo6KDI4LDM4OTUpPSMjKDI4LDM4
OTYpPSooMjgsMzg5Mik7OlJDMTBfV05EQ0xBU1NBOzJBLigyOCwzODk3KT0jIygyOCwzODk2
KTs6OzJBLjs7AFdORENMQVNTQTp0KDI4LDM4OTgpPSgyOCwzODkyKQBMUFdORENMQVNTQTp0
KDI4LDM4OTkpPSgyOCwzODk2KQBfV05EQ0xBU1NXOlR0KDI4LDM5MDApPXM0MHN0eWxlOigy
NSwxNTApLDAsMzI7bHBmblduZFByb2M6KDI1LDIwMyksMzIsMzI7Y2JDbHNFeHRyYTooMCwx
KSw2NCwzMjtjYlduZEV4dHJhOigwLDEpLDk2LDMyO2hJbnN0YW5jZTooMjUsMTkpLDEyOCwz
MjtoSWNvbjooMjUsNDEpLDE2MCwzMjtoQ3Vyc29yOigyNSwyNiksMTkyLDMyO2hickJhY2tn
cm91bmQ6KDI1LDIyKSwyMjQsMzI7bHBzek1lbnVOYW1lOigyNSw4NiksMjU2LDMyO2xwc3pD
bGFzc05hbWU6KDI1LDg2KSwyODgsMzI7X19hczo6KDI4LDM5MDEpPSMjKDI4LDM5MDIpPSYo
MjgsMzkwMCk7OlJDMTBfV05EQ0xBU1NXOzJBLjtfV05EQ0xBU1NXOjooMjgsMzkwMyk9IyMo
MjgsMzkwNCk9KigyOCwzOTAwKTs6UkMxMF9XTkRDTEFTU1c7MkEuKDI4LDM5MDUpPSMjKDI4
LDM5MDQpOzo7MkEuOzsAV05EQ0xBU1NXOnQoMjgsMzkwNik9KDI4LDM5MDApAExQV05EQ0xB
U1NXOnQoMjgsMzkwNyk9KDI4LDM5MDQpAFdORENMQVNTOnQoMjgsMzkwOCk9KDI4LDM4OTgp
AExQV05EQ0xBU1M6dCgyOCwzOTA5KT0oMjgsMzkxMCk9KigyOCwzOTA4KQBfV05EQ0xBU1NF
WEE6VHQoMjgsMzkxMSk9czQ4Y2JTaXplOigyNSwxNTApLDAsMzI7c3R5bGU6KDI1LDE1MCks
MzIsMzI7bHBmblduZFByb2M6KDI1LDIwMyksNjQsMzI7Y2JDbHNFeHRyYTooMCwxKSw5Niwz
MjtjYlduZEV4dHJhOigwLDEpLDEyOCwzMjtoSW5zdGFuY2U6KDI1LDE5KSwxNjAsMzI7aElj
b246KDI1LDQxKSwxOTIsMzI7aEN1cnNvcjooMjUsMjYpLDIyNCwzMjtoYnJCYWNrZ3JvdW5k
OigyNSwyMiksMjU2LDMyO2xwc3pNZW51TmFtZTooMjUsODEpLDI4OCwzMjtscHN6Q2xhc3NO
YW1lOigyNSw4MSksMzIwLDMyO2hJY29uU206KDI1LDQxKSwzNTIsMzI7X19hczo6KDI4LDM5
MTIpPSMjKDI4LDM5MTMpPSYoMjgsMzkxMSk7OlJDMTJfV05EQ0xBU1NFWEE7MkEuO19XTkRD
TEFTU0VYQTo6KDI4LDM5MTQpPSMjKDI4LDM5MTUpPSooMjgsMzkxMSk7OlJDMTJfV05EQ0xB
U1NFWEE7MkEuKDI4LDM5MTYpPSMjKDI4LDM5MTUpOzo7MkEuOzsAV05EQ0xBU1NFWEE6dCgy
OCwzOTE3KT0oMjgsMzkxMSkATFBXTkRDTEFTU0VYQTp0KDI4LDM5MTgpPSgyOCwzOTE1KQBf
V05EQ0xBU1NFWFc6VHQoMjgsMzkxOSk9czQ4Y2JTaXplOigyNSwxNTApLDAsMzI7c3R5bGU6
KDI1LDE1MCksMzIsMzI7bHBmblduZFByb2M6KDI1LDIwMyksNjQsMzI7Y2JDbHNFeHRyYToo
MCwxKSw5NiwzMjtjYlduZEV4dHJhOigwLDEpLDEyOCwzMjtoSW5zdGFuY2U6KDI1LDE5KSwx
NjAsMzI7aEljb246KDI1LDQxKSwxOTIsMzI7aEN1cnNvcjooMjUsMjYpLDIyNCwzMjtoYnJC
YWNrZ3JvdW5kOigyNSwyMiksMjU2LDMyO2xwc3pNZW51TmFtZTooMjUsODYpLDI4OCwzMjts
cHN6Q2xhc3NOYW1lOigyNSw4NiksMzIwLDMyO2hJY29uU206KDI1LDQxKSwzNTIsMzI7X19h
czo6KDI4LDM5MjApPSMjKDI4LDM5MjEpPSYoMjgsMzkxOSk7OlJDMTJfV05EQ0xBU1NFWFc7
MkEuO19XTkRDTEFTU0VYVzo6KDI4LDM5MjIpPSMjKDI4LDM5MjMpPSooMjgsMzkxOSk7OlJD
MTJfV05EQ0xBU1NFWFc7MkEuKDI4LDM5MjQpPSMjKDI4LDM5MjMpOzo7MkEuOzsAV05EQ0xB
U1NFWFc6dCgyOCwzOTI1KT0oMjgsMzkxOSkATFBXTkRDTEFTU0VYVzp0KDI4LDM5MjYpPSgy
OCwzOTIzKQBXTkRDTEFTU0VYOnQoMjgsMzkyNyk9KDI4LDM5MTcpAExQV05EQ0xBU1NFWDp0
KDI4LDM5MjgpPSgyOCwzOTI5KT0qKDI4LDM5MTcpAF9DT05ORUNURExHU1RSVUNUOlR0KDI4
LDM5MzApPXMyMGNiU3RydWN0dXJlOigyNSwxNCksMCwzMjtod25kT3duZXI6KDI1LDYxKSwz
MiwzMjtscENvbm5SZXM6KDI4LDI2MjApLDY0LDMyO2R3RmxhZ3M6KDI1LDE0KSw5NiwzMjtk
d0Rldk51bTooMjUsMTQpLDEyOCwzMjtfX2FzOjooMjgsMzkzMSk9IyMoMjgsMzkzMik9Jigy
OCwzOTMwKTs6UkMxN19DT05ORUNURExHU1RSVUNUOzJBLjtfQ09OTkVDVERMR1NUUlVDVDo6
KDI4LDM5MzMpPSMjKDI4LDM5MzQpPSooMjgsMzkzMCk7OlJDMTdfQ09OTkVDVERMR1NUUlVD
VDsyQS4oMjgsMzkzNSk9IyMoMjgsMzkzNCk7OjsyQS47OwBDT05ORUNURExHU1RSVUNUOnQo
MjgsMzkzNik9KDI4LDM5MzApAExQQ09OTkVDVERMR1NUUlVDVDp0KDI4LDM5MzcpPSgyOCwz
OTM0KQBfRElTQ0RMR1NUUlVDVDpUdCgyOCwzOTM4KT1zMjBjYlN0cnVjdHVyZTooMjUsMTQp
LDAsMzI7aHduZE93bmVyOigyNSw2MSksMzIsMzI7bHBMb2NhbE5hbWU6KDI1LDk2KSw2NCwz
MjtscFJlbW90ZU5hbWU6KDI1LDk2KSw5NiwzMjtkd0ZsYWdzOigyNSwxNCksMTI4LDMyO19f
YXM6OigyOCwzOTM5KT0jIygyOCwzOTQwKT0mKDI4LDM5MzgpOzpSQzE0X0RJU0NETEdTVFJV
Q1Q7MkEuO19ESVNDRExHU1RSVUNUOjooMjgsMzk0MSk9IyMoMjgsMzk0Mik9KigyOCwzOTM4
KTs6UkMxNF9ESVNDRExHU1RSVUNUOzJBLigyOCwzOTQzKT0jIygyOCwzOTQyKTs6OzJBLjs7
AERJU0NETEdTVFJVQ1Q6dCgyOCwzOTQ0KT0oMjgsMzkzOCkATFBESVNDRExHU1RSVUNUOnQo
MjgsMzk0NSk9KDI4LDM5NDIpAF9ORVRJTkZPU1RSVUNUOlR0KDI4LDM5NDYpPXMzMmNiU3Ry
dWN0dXJlOigyNSwxNCksMCwzMjtkd1Byb3ZpZGVyVmVyc2lvbjooMjUsMTQpLDMyLDMyO2R3
U3RhdHVzOigyNSwxNCksNjQsMzI7ZHdDaGFyYWN0ZXJpc3RpY3M6KDI1LDE0KSw5NiwzMjtk
d0hhbmRsZTooMjUsMTQpLDEyOCwzMjt3TmV0VHlwZTooMjUsMTUzKSwxNjAsMTY7ZHdQcmlu
dGVyczooMjUsMTQpLDE5MiwzMjtkd0RyaXZlczooMjUsMTQpLDIyNCwzMjtfX2FzOjooMjgs
Mzk0Nyk9IyMoMjgsMzk0OCk9JigyOCwzOTQ2KTs6UkMxNF9ORVRJTkZPU1RSVUNUOzJBLjtf
TkVUSU5GT1NUUlVDVDo6KDI4LDM5NDkpPSMjKDI4LDM5NTApPSooMjgsMzk0Nik7OlJDMTRf
TkVUSU5GT1NUUlVDVDsyQS4oMjgsMzk1MSk9IyMoMjgsMzk1MCk7OjsyQS47OwBORVRJTkZP
U1RSVUNUOnQoMjgsMzk1Mik9KDI4LDM5NDYpAExQTkVUSU5GT1NUUlVDVDp0KDI4LDM5NTMp
PSgyOCwzOTUwKQBfTkVUQ09OTkVDVElORk9TVFJVQ1Q6VHQoMjgsMzk1NCk9czIwY2JTdHJ1
Y3R1cmU6KDI1LDE0KSwwLDMyO2R3RmxhZ3M6KDI1LDE0KSwzMiwzMjtkd1NwZWVkOigyNSwx
NCksNjQsMzI7ZHdEZWxheTooMjUsMTQpLDk2LDMyO2R3T3B0RGF0YVNpemU6KDI1LDE0KSwx
MjgsMzI7X19hczo6KDI4LDM5NTUpPSMjKDI4LDM5NTYpPSYoMjgsMzk1NCk7OlJDMjFfTkVU
Q09OTkVDVElORk9TVFJVQ1Q7MkEuO19ORVRDT05ORUNUSU5GT1NUUlVDVDo6KDI4LDM5NTcp
PSMjKDI4LDM5NTgpPSooMjgsMzk1NCk7OlJDMjFfTkVUQ09OTkVDVElORk9TVFJVQ1Q7MkEu
KDI4LDM5NTkpPSMjKDI4LDM5NTgpOzo7MkEuOzsATkVUQ09OTkVDVElORk9TVFJVQ1Q6dCgy
OCwzOTYwKT0oMjgsMzk1NCkATFBORVRDT05ORUNUSU5GT1NUUlVDVDp0KDI4LDM5NjEpPSgy
OCwzOTU4KQBFTlVNTUVUQUZJTEVQUk9DOnQoMjgsMzk2Mik9KDI4LDM5NjMpPSooMjgsMzk2
NCk9ZigwLDEpAEVOSE1FVEFGSUxFUFJPQzp0KDI4LDM5NjUpPSgyOCwzOTY2KT0qKDI4LDM5
NjcpPWYoMCwxKQBFTlVNRk9OVFNQUk9DOnQoMjgsMzk2OCk9KDI4LDM5NjkpPSooMjgsMzk3
MCk9ZigwLDEpAEZPTlRFTlVNUFJPQzp0KDI4LDM5NzEpPSgyOCwzOTcyKT0qKDI4LDM5NzMp
PWYoMCwxKQBGT05URU5VTUVYUFJPQzp0KDI4LDM5NzQpPSgyOCwzOTc1KT0qKDI4LDM5NzYp
PWYoMCwxKQBMUE9WRVJMQVBQRURfQ09NUExFVElPTl9ST1VUSU5FOnQoMjgsMzk3Nyk9KDI4
LDM5NzgpPSooMjgsMzk3OSk9ZigwLDIwKQBfUE9JTlRGTE9BVDpUdCgyOCwzOTgwKT1zOHg6
KDI1LDE4KSwwLDMyO3k6KDI1LDE4KSwzMiwzMjtfX2FzOjooMjgsMzk4MSk9IyMoMjgsMzk4
Mik9JigyOCwzOTgwKTs6UkMxMV9QT0lOVEZMT0FUOzJBLjtfUE9JTlRGTE9BVDo6KDI4LDM5
ODMpPSMjKDI4LDM5ODQpPSooMjgsMzk4MCk7OlJDMTFfUE9JTlRGTE9BVDsyQS4oMjgsMzk4
NSk9IyMoMjgsMzk4NCk7OjsyQS47OwBQT0lOVEZMT0FUOnQoMjgsMzk4Nik9KDI4LDM5ODAp
AFBQT0lOVEZMT0FUOnQoMjgsMzk4Nyk9KDI4LDM5ODQpAF9HTFlQSE1FVFJJQ1NGTE9BVDpU
dCgyOCwzOTg4KT1zMjRnbWZCbGFja0JveFg6KDI1LDE4KSwwLDMyO2dtZkJsYWNrQm94WToo
MjUsMTgpLDMyLDMyO2dtZnB0R2x5cGhPcmlnaW46KDI4LDM5ODYpLDY0LDY0O2dtZkNlbGxJ
bmNYOigyNSwxOCksMTI4LDMyO2dtZkNlbGxJbmNZOigyNSwxOCksMTYwLDMyO19fYXM6Oigy
OCwzOTg5KT0jIygyOCwzOTkwKT0mKDI4LDM5ODgpOzpSQzE4X0dMWVBITUVUUklDU0ZMT0FU
OzJBLjtfR0xZUEhNRVRSSUNTRkxPQVQ6OigyOCwzOTkxKT0jIygyOCwzOTkyKT0qKDI4LDM5
ODgpOzpSQzE4X0dMWVBITUVUUklDU0ZMT0FUOzJBLigyOCwzOTkzKT0jIygyOCwzOTkyKTs6
OzJBLjs7AEdMWVBITUVUUklDU0ZMT0FUOnQoMjgsMzk5NCk9KDI4LDM5ODgpAFBHTFlQSE1F
VFJJQ1NGTE9BVDp0KDI4LDM5OTUpPSgyOCwzOTkyKQBMUEdMWVBITUVUUklDU0ZMT0FUOnQo
MjgsMzk5Nik9KDI4LDM5OTIpAHRhZ0xBWUVSUExBTkVERVNDUklQVE9SOlR0KDI4LDM5OTcp
PXMzMm5TaXplOigyNSwxNTMpLDAsMTY7blZlcnNpb246KDI1LDE1MyksMTYsMTY7ZHdGbGFn
czooMjUsMTQpLDMyLDMyO2lQaXhlbFR5cGU6KDI1LDUpLDY0LDg7Y0NvbG9yQml0czooMjUs
NSksNzIsODtjUmVkQml0czooMjUsNSksODAsODtjUmVkU2hpZnQ6KDI1LDUpLDg4LDg7Y0dy
ZWVuQml0czooMjUsNSksOTYsODtjR3JlZW5TaGlmdDooMjUsNSksMTA0LDg7Y0JsdWVCaXRz
OigyNSw1KSwxMTIsODtjQmx1ZVNoaWZ0OigyNSw1KSwxMjAsODtjQWxwaGFCaXRzOigyNSw1
KSwxMjgsODtjQWxwaGFTaGlmdDooMjUsNSksMTM2LDg7Y0FjY3VtQml0czooMjUsNSksMTQ0
LDg7Y0FjY3VtUmVkQml0czooMjUsNSksMTUyLDg7Y0FjY3VtR3JlZW5CaXRzOigyNSw1KSwx
NjAsODtjQWNjdW1CbHVlQml0czooMjUsNSksMTY4LDg7Y0FjY3VtQWxwaGFCaXRzOigyNSw1
KSwxNzYsODtjRGVwdGhCaXRzOigyNSw1KSwxODQsODtjU3RlbmNpbEJpdHM6KDI1LDUpLDE5
Miw4O2NBdXhCdWZmZXJzOigyNSw1KSwyMDAsODtpTGF5ZXJQbGFuZTooMjUsNSksMjA4LDg7
YlJlc2VydmVkOigyNSw1KSwyMTYsODtjclRyYW5zcGFyZW50OigyNSw5KSwyMjQsMzI7X19h
czo6KDI4LDM5OTgpPSMjKDI4LDM5OTkpPSYoMjgsMzk5Nyk7OlJDMjN0YWdMQVlFUlBMQU5F
REVTQ1JJUFRPUjsyQS47dGFnTEFZRVJQTEFORURFU0NSSVBUT1I6OigyOCw0MDAwKT0jIygy
OCw0MDAxKT0qKDI4LDM5OTcpOzpSQzIzdGFnTEFZRVJQTEFORURFU0NSSVBUT1I7MkEuKDI4
LDQwMDIpPSMjKDI4LDQwMDEpOzo7MkEuOzsATEFZRVJQTEFORURFU0NSSVBUT1I6dCgyOCw0
MDAzKT0oMjgsMzk5NykAUExBWUVSUExBTkVERVNDUklQVE9SOnQoMjgsNDAwNCk9KDI4LDQw
MDEpAExQTEFZRVJQTEFORURFU0NSSVBUT1I6dCgyOCw0MDA1KT0oMjgsNDAwMSkAdGFnUElY
RUxGT1JNQVRERVNDUklQVE9SOlR0KDI4LDQwMDYpPXM0MG5TaXplOigyNSwxNTMpLDAsMTY7
blZlcnNpb246KDI1LDE1MyksMTYsMTY7ZHdGbGFnczooMjUsMTQpLDMyLDMyO2lQaXhlbFR5
cGU6KDI1LDUpLDY0LDg7Y0NvbG9yQml0czooMjUsNSksNzIsODtjUmVkQml0czooMjUsNSks
ODAsODtjUmVkU2hpZnQ6KDI1LDUpLDg4LDg7Y0dyZWVuQml0czooMjUsNSksOTYsODtjR3Jl
ZW5TaGlmdDooMjUsNSksMTA0LDg7Y0JsdWVCaXRzOigyNSw1KSwxMTIsODtjQmx1ZVNoaWZ0
OigyNSw1KSwxMjAsODtjQWxwaGFCaXRzOigyNSw1KSwxMjgsODtjQWxwaGFTaGlmdDooMjUs
NSksMTM2LDg7Y0FjY3VtQml0czooMjUsNSksMTQ0LDg7Y0FjY3VtUmVkQml0czooMjUsNSks
MTUyLDg7Y0FjY3VtR3JlZW5CaXRzOigyNSw1KSwxNjAsODtjQWNjdW1CbHVlQml0czooMjUs
NSksMTY4LDg7Y0FjY3VtQWxwaGFCaXRzOigyNSw1KSwxNzYsODtjRGVwdGhCaXRzOigyNSw1
KSwxODQsODtjU3RlbmNpbEJpdHM6KDI1LDUpLDE5Miw4O2NBdXhCdWZmZXJzOigyNSw1KSwy
MDAsODtpTGF5ZXJUeXBlOigyNSw1KSwyMDgsODtiUmVzZXJ2ZWQ6KDI1LDUpLDIxNiw4O2R3
TGF5ZXJNYXNrOigyNSwxNCksMjI0LDMyO2R3VmlzaWJsZU1hc2s6KDI1LDE0KSwyNTYsMzI7
ZHdEYW1hZ2VNYXNrOigyNSwxNCksMjg4LDMyO19fYXM6OigyOCw0MDA3KT0jIygyOCw0MDA4
KT0mKDI4LDQwMDYpOzpSQzI0dGFnUElYRUxGT1JNQVRERVNDUklQVE9SOzJBLjt0YWdQSVhF
TEZPUk1BVERFU0NSSVBUT1I6OigyOCw0MDA5KT0jIygyOCw0MDEwKT0qKDI4LDQwMDYpOzpS
QzI0dGFnUElYRUxGT1JNQVRERVNDUklQVE9SOzJBLigyOCw0MDExKT0jIygyOCw0MDEwKTs6
OzJBLjs7AFBJWEVMRk9STUFUREVTQ1JJUFRPUjp0KDI4LDQwMTIpPSgyOCw0MDA2KQBQUElY
RUxGT1JNQVRERVNDUklQVE9SOnQoMjgsNDAxMyk9KDI4LDQwMTApAExQUElYRUxGT1JNQVRE
RVNDUklQVE9SOnQoMjgsNDAxNCk9KDI4LDQwMTApAFVTRVJfSU5GT18yOnQoMjgsNDAxNSk9
czk2dXNyaTJfbmFtZTooMjUsMTA0KSwwLDMyO3VzcmkyX3Bhc3N3b3JkOigyNSwxMDQpLDMy
LDMyO3VzcmkyX3Bhc3N3b3JkX2FnZTooMjUsMTQpLDY0LDMyO3VzcmkyX3ByaXY6KDI1LDE0
KSw5NiwzMjt1c3JpMl9ob21lX2RpcjooMjUsMTA0KSwxMjgsMzI7dXNyaTJfY29tbWVudDoo
MjUsMTA0KSwxNjAsMzI7dXNyaTJfZmxhZ3M6KDI1LDE0KSwxOTIsMzI7dXNyaTJfc2NyaXB0
X3BhdGg6KDI1LDEwNCksMjI0LDMyO3VzcmkyX2F1dGhfZmxhZ3M6KDI1LDE0KSwyNTYsMzI7
dXNyaTJfZnVsbF9uYW1lOigyNSwxMDQpLDI4OCwzMjt1c3JpMl91c3JfY29tbWVudDooMjUs
MTA0KSwzMjAsMzI7dXNyaTJfcGFybXM6KDI1LDEwNCksMzUyLDMyO3VzcmkyX3dvcmtzdGF0
aW9uczooMjUsMTA0KSwzODQsMzI7dXNyaTJfbGFzdF9sb2dvbjooMjUsMTQpLDQxNiwzMjt1
c3JpMl9sYXN0X2xvZ29mZjooMjUsMTQpLDQ0OCwzMjt1c3JpMl9hY2N0X2V4cGlyZXM6KDI1
LDE0KSw0ODAsMzI7dXNyaTJfbWF4X3N0b3JhZ2U6KDI1LDE0KSw1MTIsMzI7dXNyaTJfdW5p
dHNfcGVyX3dlZWs6KDI1LDE0KSw1NDQsMzI7dXNyaTJfbG9nb25faG91cnM6KDI1LDEwOCks
NTc2LDMyO3VzcmkyX2JhZF9wd19jb3VudDooMjUsMTQpLDYwOCwzMjt1c3JpMl9udW1fbG9n
b25zOigyNSwxNCksNjQwLDMyO3VzcmkyX2xvZ29uX3NlcnZlcjooMjUsMTA0KSw2NzIsMzI7
dXNyaTJfY291bnRyeV9jb2RlOigyNSwxNCksNzA0LDMyO3VzcmkyX2NvZGVfcGFnZTooMjUs
MTQpLDczNiwzMjtfX2FzOjooMjgsNDAxNik9IygyOCw0MDE1KSwoMjgsNDAxNyk9JigyOCw0
MDE1KSwoMjgsNDAxOCk9KigyOCw0MDE1KSwoMjgsNDAxOSk9JigyOCw0MDIwKT1zOTZ1c3Jp
Ml9uYW1lOigyNSwxMDQpLDAsMzI7dXNyaTJfcGFzc3dvcmQ6KDI1LDEwNCksMzIsMzI7dXNy
aTJfcGFzc3dvcmRfYWdlOigyNSwxNCksNjQsMzI7dXNyaTJfcHJpdjooMjUsMTQpLDk2LDMy
O3VzcmkyX2hvbWVfZGlyOigyNSwxMDQpLDEyOCwzMjt1c3JpMl9jb21tZW50OigyNSwxMDQp
LDE2MCwzMjt1c3JpMl9mbGFnczooMjUsMTQpLDE5MiwzMjt1c3JpMl9zY3JpcHRfcGF0aDoo
MjUsMTA0KSwyMjQsMzI7dXNyaTJfYXV0aF9mbGFnczooMjUsMTQpLDI1NiwzMjt1c3JpMl9m
dWxsX25hbWU6KDI1LDEwNCksMjg4LDMyO3VzcmkyX3Vzcl9jb21tZW50OigyNSwxMDQpLDMy
MCwzMjt1c3JpMl9wYXJtczooMjUsMTA0KSwzNTIsMzI7dXNyaTJfd29ya3N0YXRpb25zOigy
NSwxMDQpLDM4NCwzMjt1c3JpMl9sYXN0X2xvZ29uOigyNSwxNCksNDE2LDMyO3VzcmkyX2xh
c3RfbG9nb2ZmOigyNSwxNCksNDQ4LDMyO3VzcmkyX2FjY3RfZXhwaXJlczooMjUsMTQpLDQ4
MCwzMjt1c3JpMl9tYXhfc3RvcmFnZTooMjUsMTQpLDUxMiwzMjt1c3JpMl91bml0c19wZXJf
d2VlazooMjUsMTQpLDU0NCwzMjt1c3JpMl9sb2dvbl9ob3VyczooMjUsMTA4KSw1NzYsMzI7
dXNyaTJfYmFkX3B3X2NvdW50OigyNSwxNCksNjA4LDMyO3VzcmkyX251bV9sb2dvbnM6KDI1
LDE0KSw2NDAsMzI7dXNyaTJfbG9nb25fc2VydmVyOigyNSwxMDQpLDY3MiwzMjt1c3JpMl9j
b3VudHJ5X2NvZGU6KDI1LDE0KSw3MDQsMzI7dXNyaTJfY29kZV9wYWdlOigyNSwxNCksNzM2
LDMyO19fYXM6OigyOCw0MDE2KTpfX2FzX180JF80NlJDNCRfNDY7MkEuOyRfNDY6OigyOCw0
MDIxKT0jKDI4LDQwMTUpLCgyOCw0MDE4KSwoMjgsNDAxOCksKDI4LDQwMTkpLCgwLDIwKTs6
X180JF80NlJDNCRfNDY7MkEuKDI4LDQwMjIpPSMoMjgsNDAxNSksKDI4LDQwMTgpLCgyOCw0
MDE4KSwoMCwyMCk7Ol9fNCRfNDY7MkEuOzssKDAsMjApOzpfX2FzX180JF80NlJDNCRfNDY7
MkEuOyRfNDY6OigyOCw0MDIxKTpfXzQkXzQ2UkM0JF80NjsyQS4oMjgsNDAyMik6X180JF80
NjsyQS47OwBQVVNFUl9JTkZPXzI6dCgyOCw0MDIzKT0oMjgsNDAxOCkATFBVU0VSX0lORk9f
Mjp0KDI4LDQwMjQpPSgyOCw0MDE4KQBVU0VSX0lORk9fMDp0KDI4LDQwMjUpPXM0dXNyaTBf
bmFtZTooMjUsMTA0KSwwLDMyO19fYXM6OigyOCw0MDI2KT0jKDI4LDQwMjUpLCgyOCw0MDI3
KT0mKDI4LDQwMjUpLCgyOCw0MDI4KT0qKDI4LDQwMjUpLCgyOCw0MDI5KT0mKDI4LDQwMzAp
PXM0dXNyaTBfbmFtZTooMjUsMTA0KSwwLDMyO19fYXM6OigyOCw0MDI2KTpfX2FzX180JF80
N1JDNCRfNDc7MkEuOyRfNDc6OigyOCw0MDMxKT0jKDI4LDQwMjUpLCgyOCw0MDI4KSwoMjgs
NDAyOCksKDI4LDQwMjkpLCgwLDIwKTs6X180JF80N1JDNCRfNDc7MkEuKDI4LDQwMzIpPSMo
MjgsNDAyNSksKDI4LDQwMjgpLCgyOCw0MDI4KSwoMCwyMCk7Ol9fNCRfNDc7MkEuOzssKDAs
MjApOzpfX2FzX180JF80N1JDNCRfNDc7MkEuOyRfNDc6OigyOCw0MDMxKTpfXzQkXzQ3UkM0
JF80NzsyQS4oMjgsNDAzMik6X180JF80NzsyQS47OwBQVVNFUl9JTkZPXzA6dCgyOCw0MDMz
KT0oMjgsNDAyOCkATFBVU0VSX0lORk9fMDp0KDI4LDQwMzQpPSgyOCw0MDI4KQBVU0VSX0lO
Rk9fMzp0KDI4LDQwMzUpPXMxMTZ1c3JpM19uYW1lOigyNSwxMDQpLDAsMzI7dXNyaTNfcGFz
c3dvcmQ6KDI1LDEwNCksMzIsMzI7dXNyaTNfcGFzc3dvcmRfYWdlOigyNSwxNCksNjQsMzI7
dXNyaTNfcHJpdjooMjUsMTQpLDk2LDMyO3VzcmkzX2hvbWVfZGlyOigyNSwxMDQpLDEyOCwz
Mjt1c3JpM19jb21tZW50OigyNSwxMDQpLDE2MCwzMjt1c3JpM19mbGFnczooMjUsMTQpLDE5
MiwzMjt1c3JpM19zY3JpcHRfcGF0aDooMjUsMTA0KSwyMjQsMzI7dXNyaTNfYXV0aF9mbGFn
czooMjUsMTQpLDI1NiwzMjt1c3JpM19mdWxsX25hbWU6KDI1LDEwNCksMjg4LDMyO3Vzcmkz
X3Vzcl9jb21tZW50OigyNSwxMDQpLDMyMCwzMjt1c3JpM19wYXJtczooMjUsMTA0KSwzNTIs
MzI7dXNyaTNfd29ya3N0YXRpb25zOigyNSwxMDQpLDM4NCwzMjt1c3JpM19sYXN0X2xvZ29u
OigyNSwxNCksNDE2LDMyO3VzcmkzX2xhc3RfbG9nb2ZmOigyNSwxNCksNDQ4LDMyO3Vzcmkz
X2FjY3RfZXhwaXJlczooMjUsMTQpLDQ4MCwzMjt1c3JpM19tYXhfc3RvcmFnZTooMjUsMTQp
LDUxMiwzMjt1c3JpM191bml0c19wZXJfd2VlazooMjUsMTQpLDU0NCwzMjt1c3JpM19sb2dv
bl9ob3VyczooMjUsMTA4KSw1NzYsMzI7dXNyaTNfYmFkX3B3X2NvdW50OigyNSwxNCksNjA4
LDMyO3VzcmkzX251bV9sb2dvbnM6KDI1LDE0KSw2NDAsMzI7dXNyaTNfbG9nb25fc2VydmVy
OigyNSwxMDQpLDY3MiwzMjt1c3JpM19jb3VudHJ5X2NvZGU6KDI1LDE0KSw3MDQsMzI7dXNy
aTNfY29kZV9wYWdlOigyNSwxNCksNzM2LDMyO3VzcmkzX3VzZXJfaWQ6KDI1LDE0KSw3Njgs
MzI7dXNyaTNfcHJpbWFyeV9ncm91cF9pZDooMjUsMTQpLDgwMCwzMjt1c3JpM19wcm9maWxl
OigyNSwxMDQpLDgzMiwzMjt1c3JpM19ob21lX2Rpcl9kcml2ZTooMjUsMTA0KSw4NjQsMzI7
dXNyaTNfcGFzc3dvcmRfZXhwaXJlZDooMjUsMTQpLDg5NiwzMjtfX2FzOjooMjgsNDAzNik9
IygyOCw0MDM1KSwoMjgsNDAzNyk9JigyOCw0MDM1KSwoMjgsNDAzOCk9KigyOCw0MDM1KSwo
MjgsNDAzOSk9JigyOCw0MDQwKT1zMTE2dXNyaTNfbmFtZTooMjUsMTA0KSwwLDMyO3Vzcmkz
X3Bhc3N3b3JkOigyNSwxMDQpLDMyLDMyO3VzcmkzX3Bhc3N3b3JkX2FnZTooMjUsMTQpLDY0
LDMyO3VzcmkzX3ByaXY6KDI1LDE0KSw5NiwzMjt1c3JpM19ob21lX2RpcjooMjUsMTA0KSwx
MjgsMzI7dXNyaTNfY29tbWVudDooMjUsMTA0KSwxNjAsMzI7dXNyaTNfZmxhZ3M6KDI1LDE0
KSwxOTIsMzI7dXNyaTNfc2NyaXB0X3BhdGg6KDI1LDEwNCksMjI0LDMyO3VzcmkzX2F1dGhf
ZmxhZ3M6KDI1LDE0KSwyNTYsMzI7dXNyaTNfZnVsbF9uYW1lOigyNSwxMDQpLDI4OCwzMjt1
c3JpM191c3JfY29tbWVudDooMjUsMTA0KSwzMjAsMzI7dXNyaTNfcGFybXM6KDI1LDEwNCks
MzUyLDMyO3VzcmkzX3dvcmtzdGF0aW9uczooMjUsMTA0KSwzODQsMzI7dXNyaTNfbGFzdF9s
b2dvbjooMjUsMTQpLDQxNiwzMjt1c3JpM19sYXN0X2xvZ29mZjooMjUsMTQpLDQ0OCwzMjt1
c3JpM19hY2N0X2V4cGlyZXM6KDI1LDE0KSw0ODAsMzI7dXNyaTNfbWF4X3N0b3JhZ2U6KDI1
LDE0KSw1MTIsMzI7dXNyaTNfdW5pdHNfcGVyX3dlZWs6KDI1LDE0KSw1NDQsMzI7dXNyaTNf
bG9nb25faG91cnM6KDI1LDEwOCksNTc2LDMyO3VzcmkzX2JhZF9wd19jb3VudDooMjUsMTQp
LDYwOCwzMjt1c3JpM19udW1fbG9nb25zOigyNSwxNCksNjQwLDMyO3VzcmkzX2xvZ29uX3Nl
cnZlcjooMjUsMTA0KSw2NzIsMzI7dXNyaTNfY291bnRyeV9jb2RlOigyNSwxNCksNzA0LDMy
O3VzcmkzX2NvZGVfcGFnZTooMjUsMTQpLDczNiwzMjt1c3JpM191c2VyX2lkOigyNSwxNCks
NzY4LDMyO3VzcmkzX3ByaW1hcnlfZ3JvdXBfaWQ6KDI1LDE0KSw4MDAsMzI7dXNyaTNfcHJv
ZmlsZTooMjUsMTA0KSw4MzIsMzI7dXNyaTNfaG9tZV9kaXJfZHJpdmU6KDI1LDEwNCksODY0
LDMyO3VzcmkzX3Bhc3N3b3JkX2V4cGlyZWQ6KDI1LDE0KSw4OTYsMzI7X19hczo6KDI4LDQw
MzYpOl9fYXNfXzQkXzQ4UkM0JF80ODsyQS47JF80ODo6KDI4LDQwNDEpPSMoMjgsNDAzNSks
KDI4LDQwMzgpLCgyOCw0MDM4KSwoMjgsNDAzOSksKDAsMjApOzpfXzQkXzQ4UkM0JF80ODsy
QS4oMjgsNDA0Mik9IygyOCw0MDM1KSwoMjgsNDAzOCksKDI4LDQwMzgpLCgwLDIwKTs6X180
JF80ODsyQS47OywoMCwyMCk7Ol9fYXNfXzQkXzQ4UkM0JF80ODsyQS47JF80ODo6KDI4LDQw
NDEpOl9fNCRfNDhSQzQkXzQ4OzJBLigyOCw0MDQyKTpfXzQkXzQ4OzJBLjs7AFBVU0VSX0lO
Rk9fMzp0KDI4LDQwNDMpPSgyOCw0MDM4KQBMUFVTRVJfSU5GT18zOnQoMjgsNDA0NCk9KDI4
LDQwMzgpAEdST1VQX0lORk9fMjp0KDI4LDQwNDUpPXMxNmdycGkyX25hbWU6KDI1LDEwNCks
MCwzMjtncnBpMl9jb21tZW50OigyNSwxMDQpLDMyLDMyO2dycGkyX2dyb3VwX2lkOigyNSwx
NCksNjQsMzI7Z3JwaTJfYXR0cmlidXRlczooMjUsMTQpLDk2LDMyO19fYXM6OigyOCw0MDQ2
KT0jKDI4LDQwNDUpLCgyOCw0MDQ3KT0mKDI4LDQwNDUpLCgyOCw0MDQ4KT0qKDI4LDQwNDUp
LCgyOCw0MDQ5KT0mKDI4LDQwNTApPXMxNmdycGkyX25hbWU6KDI1LDEwNCksMCwzMjtncnBp
Ml9jb21tZW50OigyNSwxMDQpLDMyLDMyO2dycGkyX2dyb3VwX2lkOigyNSwxNCksNjQsMzI7
Z3JwaTJfYXR0cmlidXRlczooMjUsMTQpLDk2LDMyO19fYXM6OigyOCw0MDQ2KTpfX2FzX180
JF80OVJDNCRfNDk7MkEuOyRfNDk6OigyOCw0MDUxKT0jKDI4LDQwNDUpLCgyOCw0MDQ4KSwo
MjgsNDA0OCksKDI4LDQwNDkpLCgwLDIwKTs6X180JF80OVJDNCRfNDk7MkEuKDI4LDQwNTIp
PSMoMjgsNDA0NSksKDI4LDQwNDgpLCgyOCw0MDQ4KSwoMCwyMCk7Ol9fNCRfNDk7MkEuOzss
KDAsMjApOzpfX2FzX180JF80OVJDNCRfNDk7MkEuOyRfNDk6OigyOCw0MDUxKTpfXzQkXzQ5
UkM0JF80OTsyQS4oMjgsNDA1Mik6X180JF80OTsyQS47OwBQR1JPVVBfSU5GT18yOnQoMjgs
NDA1Myk9KDI4LDQwNDgpAExPQ0FMR1JPVVBfSU5GT18wOnQoMjgsNDA1NCk9czRsZ3JwaTBf
bmFtZTooMjUsMTA0KSwwLDMyO19fYXM6OigyOCw0MDU1KT0jKDI4LDQwNTQpLCgyOCw0MDU2
KT0mKDI4LDQwNTQpLCgyOCw0MDU3KT0qKDI4LDQwNTQpLCgyOCw0MDU4KT0mKDI4LDQwNTkp
PXM0bGdycGkwX25hbWU6KDI1LDEwNCksMCwzMjtfX2FzOjooMjgsNDA1NSk6X19hc19fNCRf
NTBSQzQkXzUwOzJBLjskXzUwOjooMjgsNDA2MCk9IygyOCw0MDU0KSwoMjgsNDA1NyksKDI4
LDQwNTcpLCgyOCw0MDU4KSwoMCwyMCk7Ol9fNCRfNTBSQzQkXzUwOzJBLigyOCw0MDYxKT0j
KDI4LDQwNTQpLCgyOCw0MDU3KSwoMjgsNDA1NyksKDAsMjApOzpfXzQkXzUwOzJBLjs7LCgw
LDIwKTs6X19hc19fNCRfNTBSQzQkXzUwOzJBLjskXzUwOjooMjgsNDA2MCk6X180JF81MFJD
NCRfNTA7MkEuKDI4LDQwNjEpOl9fNCRfNTA7MkEuOzsAUExPQ0FMR1JPVVBfSU5GT18wOnQo
MjgsNDA2Mik9KDI4LDQwNTcpAExQTE9DQUxHUk9VUF9JTkZPXzA6dCgyOCw0MDYzKT0oMjgs
NDA1NykAdGFnSU1BR0VfRE9TX0hFQURFUjpUdCgyOCw0MDY0KT1zNjRlX21hZ2ljOigyNSwx
NTMpLDAsMTY7ZV9jYmxwOigyNSwxNTMpLDE2LDE2O2VfY3A6KDI1LDE1MyksMzIsMTY7ZV9j
cmxjOigyNSwxNTMpLDQ4LDE2O2VfY3BhcmhkcjooMjUsMTUzKSw2NCwxNjtlX21pbmFsbG9j
OigyNSwxNTMpLDgwLDE2O2VfbWF4YWxsb2M6KDI1LDE1MyksOTYsMTY7ZV9zczooMjUsMTUz
KSwxMTIsMTY7ZV9zcDooMjUsMTUzKSwxMjgsMTY7ZV9jc3VtOigyNSwxNTMpLDE0NCwxNjtl
X2lwOigyNSwxNTMpLDE2MCwxNjtlX2NzOigyNSwxNTMpLDE3NiwxNjtlX2xmYXJsYzooMjUs
MTUzKSwxOTIsMTY7ZV9vdm5vOigyNSwxNTMpLDIwOCwxNjtlX3JlczooMjgsNDA2NSk9YXIo
MCwxKTswOzM7KDAsOSksMjI0LDY0O2Vfb2VtaWQ6KDI1LDE1MyksMjg4LDE2O2Vfb2VtaW5m
bzooMjUsMTUzKSwzMDQsMTY7ZV9yZXMyOigyOCw0MDY2KT1hcigwLDEpOzA7OTsoMCw5KSwz
MjAsMTYwO2VfbGZhbmV3OigyNSwxMyksNDgwLDMyO19fYXM6OigyOCw0MDY3KT0jIygyOCw0
MDY4KT0mKDI4LDQwNjQpOzpSQzE5dGFnSU1BR0VfRE9TX0hFQURFUjsyQS47dGFnSU1BR0Vf
RE9TX0hFQURFUjo6KDI4LDQwNjkpPSMjKDI4LDQwNzApPSooMjgsNDA2NCk7OlJDMTl0YWdJ
TUFHRV9ET1NfSEVBREVSOzJBLigyOCw0MDcxKT0jIygyOCw0MDcwKTs6OzJBLjs7AElNQUdF
X0RPU19IRUFERVI6dCgyOCw0MDcyKT0oMjgsNDA2NCkAUElNQUdFX0RPU19IRUFERVI6dCgy
OCw0MDczKT0oMjgsNDA3MCkAdGFnSU1BR0VfT1MyX0hFQURFUjpUdCgyOCw0MDc0KT1zNjRu
ZV9tYWdpYzooMjUsMTUzKSwwLDE2O25lX3ZlcjooMjUsMTEpLDE2LDg7bmVfcmV2OigyNSwx
MSksMjQsODtuZV9lbnR0YWI6KDI1LDE1MyksMzIsMTY7bmVfY2JlbnR0YWI6KDI1LDE1Myks
NDgsMTY7bmVfY3JjOigyNSwxMyksNjQsMzI7bmVfZmxhZ3M6KDI1LDE1MyksOTYsMTY7bmVf
YXV0b2RhdGE6KDI1LDE1MyksMTEyLDE2O25lX2hlYXA6KDI1LDE1MyksMTI4LDE2O25lX3N0
YWNrOigyNSwxNTMpLDE0NCwxNjtuZV9jc2lwOigyNSwxMyksMTYwLDMyO25lX3Nzc3A6KDI1
LDEzKSwxOTIsMzI7bmVfY3NlZzooMjUsMTUzKSwyMjQsMTY7bmVfY21vZDooMjUsMTUzKSwy
NDAsMTY7bmVfY2JucmVzdGFiOigyNSwxNTMpLDI1NiwxNjtuZV9zZWd0YWI6KDI1LDE1Myks
MjcyLDE2O25lX3JzcmN0YWI6KDI1LDE1MyksMjg4LDE2O25lX3Jlc3RhYjooMjUsMTUzKSwz
MDQsMTY7bmVfbW9kdGFiOigyNSwxNTMpLDMyMCwxNjtuZV9pbXB0YWI6KDI1LDE1MyksMzM2
LDE2O25lX25yZXN0YWI6KDI1LDEzKSwzNTIsMzI7bmVfY21vdmVudDooMjUsMTUzKSwzODQs
MTY7bmVfYWxpZ246KDI1LDE1MyksNDAwLDE2O25lX2NyZXM6KDI1LDE1MyksNDE2LDE2O25l
X2V4ZXR5cDooMjUsNSksNDMyLDg7bmVfZmxhZ3NvdGhlcnM6KDI1LDUpLDQ0MCw4O25lX3By
ZXR0aHVua3M6KDI1LDE1MyksNDQ4LDE2O25lX3BzZWdyZWZieXRlczooMjUsMTUzKSw0NjQs
MTY7bmVfc3dhcGFyZWE6KDI1LDE1MyksNDgwLDE2O25lX2V4cHZlcjooMjUsMTUzKSw0OTYs
MTY7X19hczo6KDI4LDQwNzUpPSMjKDI4LDQwNzYpPSYoMjgsNDA3NCk7OlJDMTl0YWdJTUFH
RV9PUzJfSEVBREVSOzJBLjt0YWdJTUFHRV9PUzJfSEVBREVSOjooMjgsNDA3Nyk9IyMoMjgs
NDA3OCk9KigyOCw0MDc0KTs6UkMxOXRhZ0lNQUdFX09TMl9IRUFERVI7MkEuKDI4LDQwNzkp
PSMjKDI4LDQwNzgpOzo7MkEuOzsASU1BR0VfT1MyX0hFQURFUjp0KDI4LDQwODApPSgyOCw0
MDc0KQBQSU1BR0VfT1MyX0hFQURFUjp0KDI4LDQwODEpPSgyOCw0MDc4KQB0YWdJTUFHRV9W
WERfSEVBREVSOlR0KDI4LDQwODIpPXMxOTZlMzJfbWFnaWM6KDI1LDE1MyksMCwxNjtlMzJf
Ym9yZGVyOigyNSw1KSwxNiw4O2UzMl93b3JkZXI6KDI1LDUpLDI0LDg7ZTMyX2xldmVsOigy
NSwxNCksMzIsMzI7ZTMyX2NwdTooMjUsMTUzKSw2NCwxNjtlMzJfb3M6KDI1LDE1MyksODAs
MTY7ZTMyX3ZlcjooMjUsMTQpLDk2LDMyO2UzMl9tZmxhZ3M6KDI1LDE0KSwxMjgsMzI7ZTMy
X21wYWdlczooMjUsMTQpLDE2MCwzMjtlMzJfc3RhcnRvYmo6KDI1LDE0KSwxOTIsMzI7ZTMy
X2VpcDooMjUsMTQpLDIyNCwzMjtlMzJfc3RhY2tvYmo6KDI1LDE0KSwyNTYsMzI7ZTMyX2Vz
cDooMjUsMTQpLDI4OCwzMjtlMzJfcGFnZXNpemU6KDI1LDE0KSwzMjAsMzI7ZTMyX2xhc3Rw
YWdlc2l6ZTooMjUsMTQpLDM1MiwzMjtlMzJfZml4dXBzaXplOigyNSwxNCksMzg0LDMyO2Uz
Ml9maXN1cHN1bTooMjUsMTQpLDQxNiwzMjtlMzJfbGRyc2l6ZTooMjUsMTQpLDQ0OCwzMjtl
MzJfbGRyc3VtOigyNSwxNCksNDgwLDMyO2UzMl9vYmp0YWI6KDI1LDE0KSw1MTIsMzI7ZTMy
X29iamNudDooMjUsMTQpLDU0NCwzMjtlMzJfb2JqbWFwOigyNSwxNCksNTc2LDMyO2UzMl9p
dGVybWFwOigyNSwxNCksNjA4LDMyO2UzMl9yc3JjdGFiOigyNSwxNCksNjQwLDMyO2UzMl9y
c3JjY250OigyNSwxNCksNjcyLDMyO2UzMl9yZXN0YWI6KDI1LDE0KSw3MDQsMzI7ZTMyX2Vu
dHRhYjooMjUsMTQpLDczNiwzMjtlMzJfZGlydGFiOigyNSwxNCksNzY4LDMyO2UzMl9kaXJj
bnQ6KDI1LDE0KSw4MDAsMzI7ZTMyX2ZwYWdldGFiOigyNSwxNCksODMyLDMyO2UzMl9mcmVj
dGFiOigyNSwxNCksODY0LDMyO2UzMl9pbXBtb2Q6KDI1LDE0KSw4OTYsMzI7ZTMyX2ltcG1v
ZGNudDooMjUsMTQpLDkyOCwzMjtlMzJfaW1wcHJvYzooMjUsMTQpLDk2MCwzMjtlMzJfcGFn
ZXN1bTooMjUsMTQpLDk5MiwzMjtlMzJfZGF0YXBhZ2U6KDI1LDE0KSwxMDI0LDMyO2UzMl9w
cmVsb2FkOigyNSwxNCksMTA1NiwzMjtlMzJfbnJlc3RhYjooMjUsMTQpLDEwODgsMzI7ZTMy
X2NibnJlc3RhYjooMjUsMTQpLDExMjAsMzI7ZTMyX25yZXNzdW06KDI1LDE0KSwxMTUyLDMy
O2UzMl9hdXRvZGF0YTooMjUsMTQpLDExODQsMzI7ZTMyX2RlYnVnaW5mbzooMjUsMTQpLDEy
MTYsMzI7ZTMyX2RlYnVnbGVuOigyNSwxNCksMTI0OCwzMjtlMzJfaW5zdHByZWxvYWQ6KDI1
LDE0KSwxMjgwLDMyO2UzMl9pbnN0ZGVtYW5kOigyNSwxNCksMTMxMiwzMjtlMzJfaGVhcHNp
emU6KDI1LDE0KSwxMzQ0LDMyO2UzMl9yZXMzOigyOCw2ODEpLDEzNzYsOTY7ZTMyX3dpbnJl
c29mZjooMjUsMTQpLDE0NzIsMzI7ZTMyX3dpbnJlc2xlbjooMjUsMTQpLDE1MDQsMzI7ZTMy
X2RldmlkOigyNSwxNTMpLDE1MzYsMTY7ZTMyX2Rka3ZlcjooMjUsMTUzKSwxNTUyLDE2O19f
YXM6OigyOCw0MDgzKT0jIygyOCw0MDg0KT0mKDI4LDQwODIpOzpSQzE5dGFnSU1BR0VfVlhE
X0hFQURFUjsyQS47dGFnSU1BR0VfVlhEX0hFQURFUjo6KDI4LDQwODUpPSMjKDI4LDQwODYp
PSooMjgsNDA4Mik7OlJDMTl0YWdJTUFHRV9WWERfSEVBREVSOzJBLigyOCw0MDg3KT0jIygy
OCw0MDg2KTs6OzJBLjs7AElNQUdFX1ZYRF9IRUFERVI6dCgyOCw0MDg4KT0oMjgsNDA4MikA
UElNQUdFX1ZYRF9IRUFERVI6dCgyOCw0MDg5KT0oMjgsNDA4NikAL2hvbWUvbm9lci9zcmMv
YjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvaW5jbHVkZS9XaW5kb3dzMzIvRnVuY3Rpb25z
LmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvaW5jbHVkZS9X
aW5kb3dzMzIvQ29tbW9uRnVuY3Rpb25zLmgATFBUT1BfTEVWRUxfRVhDRVBUSU9OX0ZJTFRF
Ujp0KDMwLDEpPSgzMCwyKT0qKDMwLDMpPWYoMjUsMTMpAExQRk5ERVZNT0RFOnQoMzAsNCk9
KDMwLDUpPSooMzAsNik9ZigyNSwxNTApAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xz
L2Rldm8vd2luc3VwL2luY2x1ZGUvV2luZG93czMyL1VuaWNvZGVGdW5jdGlvbnMuaAAvaG9t
ZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL3dpbnN1cC9pbmNsdWRlL1dpbmRvd3Mz
Mi9BU0NJSUZ1bmN0aW9ucy5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8v
d2luc3VwL2luY2x1ZGUvV2luZG93czMyL0Vycm9ycy5oAG9zX3R5cGU6dCgxLDEpPWV3aW5O
VDoxLHdpbjk1OjIsd2luOTg6Myx3aW4zMnM6NCx1bmtub3duOjUsOwAvaG9tZS9ub2VyL3Ny
Yy9iMjAvY29tcC10b29scy9kZXZvL3dpbnN1cC9maGFuZGxlci5oAC9ob21lL25vZXIvc3Jj
L2IyMC9jb21wLXRvb2xzL2Rldm8vd2luc3VwL2luY2x1ZGUvc3lzL2lvY3RsLmgAZmhhbmRs
ZXJfYmFzZTpUdCgzNCwxKT1zNDhzdGF0dXNfOi8wKDI1LDE0KSwwLDMyO2NiOigwLDEpLDMy
LDMyO2FjY2Vzc186LzAoMCwxKSw2NCwzMjtoYW5kbGVfOi8wKDI1LDE5KSw5NiwzMjtycG9z
XzovMCgwLDEpLDEyOCwzMjtyc2l6ZV86LzAoMCwxKSwxNjAsMzI7cmVhZGFoZWFkXzovMCgw
LDIpLDE5Miw4O25hbWVoYXNoXzovMCgwLDUpLDIyNCwzMjtvcGVuZmxhZ3NfOi8wKDAsMSks
MjU2LDMyO3VuaXhfcGF0aF9uYW1lXzovMSgyLDEwKSwyODgsMzI7d2luMzJfcGF0aF9uYW1l
XzovMSgyLDEwKSwzMjAsMzI7JHZmKDM0LDEpOigzNCwyKT0qKDM0LDMpPWFyKDAsMSk7MDs0
NTsoMCwyMiksMzUyO2ZoYW5kbGVyX2Jhc2U6OigzNCw0KT0jIygzNCw1KT0qKDM0LDEpOzpS
QzEzZmhhbmRsZXJfYmFzZTsyQS47c2V0X25hbWU6OigzNCw2KT0jIygwLDIwKTs6UENjVDFp
OzJBLjtfX2FzOjooMzQsNyk9IyMoMzQsOCk9JigzNCwxKTs6UjEzZmhhbmRsZXJfYmFzZTsy
QS47ZmhhbmRsZXJfYmFzZTo6KDM0LDkpPSMjKDM0LDUpOzpVaVBDY2k7MkEuKDM0LDEwKT0j
KDM0LDEpLCgwLDIwKSwoMzQsNSksKDAsMSksKDAsMjApOzpfJF8xM2ZoYW5kbGVyX2Jhc2U7
MkEqMTsoMzQsMSk7O3NldF9oYW5kbGU6OigzNCwxMSk9IyMoMCwyMCk7OlB2OzJBLjtzZXRf
Y2I6OigzNCwxMik9IyMoMCwyMCk7OlVpOzJBLjtnZXRfZGV2aWNlOjooMzQsMTMpPSMjKDI1
LDE0KTs6OzJBLjtnZXRfdW5pdDo6KDM0LDE0KT0jIygwLDEpOzo7MkEqMjsoMzQsMSk7O2lz
X3Nsb3c6OigzNCwxNSk9IyMoMjUsMyk7OjsyQSozOygzNCwxKTs7Z2V0X2FjY2Vzczo6KDM0
LDE0KTo7MkEuO3NldF9hY2Nlc3M6OigzNCwxMCk6aTsyQS47Z2V0X2FzeW5jOjooMzQsMTQp
OjsyQS47c2V0X2FzeW5jOjooMzQsMTApOmk7MkEuO2dldF9mbGFnczo6KDM0LDE0KTo7MkEu
O3NldF9mbGFnczo6KDM0LDEwKTppOzJBLjtnZXRfd19iaW5hcnk6OigzNCwxNCk6OzJBLjtn
ZXRfcl9iaW5hcnk6OigzNCwxNCk6OzJBLjtzZXRfd19iaW5hcnk6OigzNCwxMCk6aTsyQS47
c2V0X3JfYmluYXJ5OjooMzQsMTApOmk7MkEuO2dldF9yX25vX2ludGVycnVwdDo6KDM0LDE0
KTo7MkEuO3NldF9yX25vX2ludGVycnVwdDo6KDM0LDEwKTppOzJBLjtnZXRfY2xvc2Vfb25f
ZXhlYzo6KDM0LDE0KTo7MkEuO3NldF9jbG9zZV9vbl9leGVjX2ZsYWc6OigzNCwxNik9IyMo
MCwxKTs6aTsyQS47c2V0X2NoZWNrX3dpbjk1X2xzZWVrX2J1Zzo6KDM0LDE3KT0jIygwLDIw
KTs6aTsyQS47Z2V0X2NoZWNrX3dpbjk1X2xzZWVrX2J1Zzo6KDM0LDE0KTo7MkEuO3NldF9j
bG9zZV9vbl9leGVjOjooMzQsMTApOmk7MkEqNDsoMzQsMSk7O2ZpeHVwX2FmdGVyX2Zvcms6
OigzNCwxMSk6UHY7MkEqNTsoMzQsMSk7O2dldF9zeW1saW5rX3A6OigzNCwxNCk6OzJBLjtz
ZXRfc3ltbGlua19wOjooMzQsMTApOmk7MkEuKDM0LDE4KT0jIygwLDIwKTs6OzJBLjtnZXRf
ZXhlY2FibGVfcDo6KDM0LDE0KTo7MkEuO3NldF9leGVjYWJsZV9wOjooMzQsMTApOmk7MkEu
KDM0LDE4KTo7MkEuO2dldF9hcHBlbmRfcDo6KDM0LDE0KTo7MkEuO3NldF9hcHBlbmRfcDo6
KDM0LDEwKTppOzJBLigzNCwxOCk6OzJBLjtnZXRfcmVhZGFoZWFkX3ZhbGlkOjooMzQsMTQp
OjsyQS47c2V0X3JlYWRhaGVhZF92YWxpZDo6KDM0LDEwKTppOzJBLigzNCwxOSk9IyMoMCwy
MCk7OmljOzJBLigzNCwxOCk6OzJBLjtub19mcmVlX25hbWVzOjooMzQsMTQpOjsyQS47c2V0
X25vX2ZyZWVfbmFtZXM6OigzNCwxMCk6aTsyQS4oMzQsMTgpOjsyQS47Z2V0X25hbWU6Oigz
NCwyMCk9IyMoMjUsODIpOzo7MkEuO2dldF93aW4zMl9uYW1lOjooMzQsMjApOjsyQS47Z2V0
X25hbWVoYXNoOjooMzQsMjEpPSMjKDAsNSk7OjsyQS47Zm9ya19maXh1cDo6KDM0LDIyKT0j
IygwLDIwKTs6UHZSUHY7MkEuO29wZW46OigzNCwyMyk9IyMoMCwxKTs6UENjaWk7MkEqNjso
MzQsMSk7KDM0LDI0KT0jIygwLDEpOzppaTsyQSo3OygzNCwxKTs7Y2xvc2U6OigzNCwxNCk6
OzJBKjg7KDM0LDEpOztmc3RhdDo6KDM0LDI1KT0jIygwLDEpOzpQNHN0YXQ7MkEqOTsoMzQs
MSk7O2lvY3RsOjooMzQsMjYpPSMjKDAsMSk7OlVpUHY7MkEqMTA7KDM0LDEpOzt0dHluYW1l
OjooMzQsMjApOjsyQSoxMTsoMzQsMSk7O3JlYWQ6OigzNCwyNyk9IyMoMCwxKTs6UHZVaTsy
QSoxMjsoMzQsMSk7O3dyaXRlOjooMzQsMjgpPSMjKDAsMSk7OlBDdlVpOzJBKjEzOygzNCwx
KTs7bHNlZWs6OigzNCwyOSk9IyMoMiwyNCk7OmxpOzJBKjE0OygzNCwxKTs7bG9jazo6KDM0
LDMwKT0jIygwLDEpOzppUDVmbG9jazsyQSoxNTsoMzQsMSk7O2R1bXA6OigzNCwxOCk6OzJB
KjE2OygzNCwxKTs7ZHVwOjooMzQsMzEpPSMjKDAsMSk7OlAxM2ZoYW5kbGVyX2Jhc2U7MkEq
MTc7KDM0LDEpOztfX253OjooMzQsMzIpPWYoMCwyMyk6VWlQdjsyQT87aW5pdDo6KDM0LDMz
KT0jIygwLDIwKTs6UHZpVWk7MkEqMTg7KDM0LDEpOzt0Y2ZsdXNoOjooMzQsMTYpOmk7MkEq
MTk7KDM0LDEpOzt0Y3NlbmRicmVhazo6KDM0LDE2KTppOzJBKjIwOygzNCwxKTs7dGNkcmFp
bjo6KDM0LDE0KTo7MkEqMjE7KDM0LDEpOzt0Y2Zsb3c6OigzNCwxNik6aTsyQSoyMjsoMzQs
MSk7O3Rjc2V0YXR0cjo6KDM0LDM0KT0jIygwLDEpOzppUEM3dGVybWlvczsyQSoyMzsoMzQs
MSk7O3RjZ2V0YXR0cjo6KDM0LDM1KT0jIygwLDEpOzpQN3Rlcm1pb3M7MkEqMjQ7KDM0LDEp
Ozt0Y3NldHBncnA6OigzNCwzNik9IyMoMCwxKTs6aTsyQSoyNTsoMzQsMSk7O3RjZ2V0cGdy
cDo6KDM0LDE0KTo7MkEqMjY7KDM0LDEpOztpc190dHk6OigzNCwxNCk6OzJBKjI3OygzNCwx
KTs7aXNfZGV2aWNlOjooMzQsMTUpOjsyQSoyODsoMzQsMSk7O3B0c25hbWU6OigzNCwzNyk9
IyMoMiwxMCk7OjsyQSoyOTsoMzQsMSk7O2lzX3NvY2tldDo6KDM0LDM4KT0jIygzNCwzOSk9
KigzNCw0MCk9eHNmaGFuZGxlcl9zb2NrZXQ6Ozo7MkEqMzA7KDM0LDEpOztpc19jb25zb2xl
OjooMzQsNDEpPSMjKDM0LDQyKT0qKDM0LDQzKT14c2ZoYW5kbGVyX2NvbnNvbGU6Ozo7MkEq
MzE7KDM0LDEpOztpc193aW5kb3dzOjooMzQsMTQpOjsyQSozMjsoMzQsMSk7O3Jhd19yZWFk
OjooMzQsMjcpOlB2VWk7MkEqMzM7KDM0LDEpOztyYXdfd3JpdGU6OigzNCwyOCk6UEN2VWk7
MkEqMzQ7KDM0LDEpOztsaW5lYXJpemU6OigzNCw0NCk9IyMoMCwxKTs6UFVjOzJBKjM1Oygz
NCwxKTs7ZGVfbGluZWFyaXplOjooMzQsNDUpPSMjKDAsMSk7OlBDVWM7MkEqMzY7KDM0LDEp
OztnZXRfaGFuZGxlOjooMzQsNDYpPSMjKDI1LDE5KTs6OzJCKjM3OygzNCwxKTs7Z2V0X2lu
cHV0X2hhbmRsZTo6KDM0LDQ2KTo7MkIqMzg7KDM0LDEpOztnZXRfb3V0cHV0X2hhbmRsZTo6
KDM0LDQ2KTo7MkIqMzk7KDM0LDEpOztoaXRfZW9mOjooMzQsMTUpOjsyQSo0MDsoMzQsMSk7
O3NlbGVjdF9yZWFkOjooMzQsNDcpPSMjKDM0LDQ4KT0qKDM0LDQ5KT14c3NlbGVjdF9yZWNv
cmQ6OzpQMTNzZWxlY3RfcmVjb3JkOzJBKjQxOygzNCwxKTs7c2VsZWN0X3dyaXRlOjooMzQs
NDcpOlAxM3NlbGVjdF9yZWNvcmQ7MkEqNDI7KDM0LDEpOztzZWxlY3RfZXhjZXB0OjooMzQs
NDcpOlAxM3NlbGVjdF9yZWNvcmQ7MkEqNDM7KDM0LDEpOztyZWFkeV9mb3JfcmVhZDo6KDM0
LDUwKT0jIygwLDEpOzpVaWk7MkEqNDQ7KDM0LDEpOztnZXRfbmF0aXZlX25hbWU6OigzNCwy
MCk6OzJBKjQ1OygzNCwxKTs7O34lKDM0LDEpOwBmaGFuZGxlcl9zb2NrZXQ6VHQoMzQsNDAp
PXM0OCExLDAyMCwoMzQsMSk7X19hczo6KDM0LDUxKT0jIygzNCw1Mik9JigzNCw0MCk7OlIx
NWZoYW5kbGVyX3NvY2tldDsyQS47ZmhhbmRsZXJfc29ja2V0OjooMzQsNTMpPSMjKDM0LDM5
KTs6UkMxNWZoYW5kbGVyX3NvY2tldDsyQS4oMzQsNTQpPSMjKDM0LDM5KTs6UENjOzJBLigz
NCw1NSk9IyMoMzQsMzkpOzpVaVBDYzsyQS4oMzQsNTYpPSMoMzQsNDApLCgwLDIwKSwoMzQs
MzkpLCgwLDEpLCgwLDIwKTs6XyRfMTVmaGFuZGxlcl9zb2NrZXQ7MkEqMTsoMzQsMSk7O2dl
dF9zb2NrZXQ6OigzNCw1Nyk9IyMoMCwxKTs6OzJCLjtpc19zb2NrZXQ6OigzNCw1OCk9IyMo
MzQsMzkpOzo7MkEqMzA7KDM0LDEpOzt3cml0ZTo6KDM0LDU5KT0jIygwLDEpOzpQQ3ZVaTsy
QSoxMzsoMzQsMSk7O3JlYWQ6OigzNCw2MCk9IyMoMCwxKTs6UHZVaTsyQSoxMjsoMzQsMSk7
O2lvY3RsOjooMzQsNjEpPSMjKDAsMSk7OlVpUHY7MkEqMTA7KDM0LDEpOztsc2Vlazo6KDM0
LDYyKT0jIygyLDI0KTs6bGk7MkEqMTQ7KDM0LDEpOztjbG9zZTo6KDM0LDYzKT0jIygwLDEp
Ozo7MkEqODsoMzQsMSk7O3NlbGVjdF9yZWFkOjooMzQsNjQpPSMjKDM0LDQ4KTs6UDEzc2Vs
ZWN0X3JlY29yZDsyQSo0MTsoMzQsMSk7O3NlbGVjdF93cml0ZTo6KDM0LDY0KTpQMTNzZWxl
Y3RfcmVjb3JkOzJBKjQyOygzNCwxKTs7c2VsZWN0X2V4Y2VwdDo6KDM0LDY0KTpQMTNzZWxl
Y3RfcmVjb3JkOzJBKjQzOygzNCwxKTs7cmVhZHlfZm9yX3JlYWQ6OigzNCw2NSk9IyMoMCwx
KTs6VWlpOzJBKjQ0OygzNCwxKTs7O34lKDM0LDEpOwBmaGFuZGxlcl9waXBlOlR0KDM0LDY2
KT1zNDghMSwwMjAsKDM0LDEpO19fYXM6OigzNCw2Nyk9IyMoMzQsNjgpPSYoMzQsNjYpOzpS
MTNmaGFuZGxlcl9waXBlOzJBLjtmaGFuZGxlcl9waXBlOjooMzQsNjkpPSMjKDM0LDcwKT0q
KDM0LDY2KTs6UkMxM2ZoYW5kbGVyX3BpcGU7MkEuKDM0LDcxKT0jKDM0LDY2KSwoMCwyMCks
KDM0LDcwKSwoMCwxKSwoMCwyMCk7Ol8kXzEzZmhhbmRsZXJfcGlwZTsyQSoxOygzNCwxKTso
MzQsNzIpPSMjKDM0LDcwKTs6UENjOzJBLjtsc2Vlazo6KDM0LDczKT0jIygyLDI0KTs6bGk7
MkEqMTQ7KDM0LDEpOztpc19zbG93OjooMzQsNzQpPSMjKDI1LDMpOzo7MkEqMzsoMzQsMSk7
O3NlbGVjdF9yZWFkOjooMzQsNzUpPSMjKDM0LDQ4KTs6UDEzc2VsZWN0X3JlY29yZDsyQSo0
MTsoMzQsMSk7O3NlbGVjdF93cml0ZTo6KDM0LDc1KTpQMTNzZWxlY3RfcmVjb3JkOzJBKjQy
OygzNCwxKTs7c2VsZWN0X2V4Y2VwdDo6KDM0LDc1KTpQMTNzZWxlY3RfcmVjb3JkOzJBKjQz
OygzNCwxKTs7cmVhZHlfZm9yX3JlYWQ6OigzNCw3Nik9IyMoMCwxKTs6VWlpOzJBKjQ0Oygz
NCwxKTs7O34lKDM0LDEpOwBmaGFuZGxlcl9kZXZfZmxvcHB5OlR0KDM0LDc3KT1zNDghMSww
MjAsKDM0LDEpO19fYXM6OigzNCw3OCk9IyMoMzQsNzkpPSYoMzQsNzcpOzpSMTlmaGFuZGxl
cl9kZXZfZmxvcHB5OzJBLjtmaGFuZGxlcl9kZXZfZmxvcHB5OjooMzQsODApPSMjKDM0LDgx
KT0qKDM0LDc3KTs6UkMxOWZoYW5kbGVyX2Rldl9mbG9wcHk7MkEuKDM0LDgyKT0jKDM0LDc3
KSwoMCwyMCksKDM0LDgxKSwoMCwxKSwoMCwyMCk7Ol8kXzE5ZmhhbmRsZXJfZGV2X2Zsb3Bw
eTsyQSoxOygzNCwxKTsoMzQsODMpPSMjKDM0LDgxKTs6UENjaTsyQS47b3Blbjo6KDM0LDg0
KT0jIygwLDEpOzpQQ2NpaTsyQSo2OygzNCwxKTs7O34lKDM0LDEpOwBmaGFuZGxlcl9kZXZf
dGFwZTpUdCgzNCw4NSk9czQ4ITEsMDIwLCgzNCwxKTtfX2FzOjooMzQsODYpPSMjKDM0LDg3
KT0mKDM0LDg1KTs6UjE3ZmhhbmRsZXJfZGV2X3RhcGU7MkEuO2ZoYW5kbGVyX2Rldl90YXBl
OjooMzQsODgpPSMjKDM0LDg5KT0qKDM0LDg1KTs6UkMxN2ZoYW5kbGVyX2Rldl90YXBlOzJB
LigzNCw5MCk9IygzNCw4NSksKDAsMjApLCgzNCw4OSksKDAsMSksKDAsMjApOzpfJF8xN2Zo
YW5kbGVyX2Rldl90YXBlOzJBKjE7KDM0LDEpOygzNCw5MSk9IyMoMzQsODkpOzpQQ2NpOzJB
LjtvcGVuOjooMzQsOTIpPSMjKDAsMSk7OlBDY2lpOzJBKjY7KDM0LDEpOzs7fiUoMzQsMSk7
AGZoYW5kbGVyX2Rpc2tfZmlsZTpUdCgzNCw5Myk9czQ4ITEsMDIwLCgzNCwxKTtfX2FzOjoo
MzQsOTQpPSMjKDM0LDk1KT0mKDM0LDkzKTs6UjE4ZmhhbmRsZXJfZGlza19maWxlOzJBLjtm
aGFuZGxlcl9kaXNrX2ZpbGU6OigzNCw5Nik9IyMoMzQsOTcpPSooMzQsOTMpOzpSQzE4Zmhh
bmRsZXJfZGlza19maWxlOzJBLigzNCw5OCk9IygzNCw5MyksKDAsMjApLCgzNCw5NyksKDAs
MSksKDAsMjApOzpfJF8xOGZoYW5kbGVyX2Rpc2tfZmlsZTsyQSoxOygzNCwxKTs7Y2hlY2tf
ZXhlY2FibGVfcDo6KDM0LDk5KT0jIygwLDEpOzpQQ2M7MEEuO2ZoYW5kbGVyX2Rpc2tfZmls
ZTo6KDM0LDEwMCk9IyMoMzQsOTcpOzpQQ2M7MkEuO29wZW46OigzNCwxMDEpPSMjKDAsMSk7
OlBDY2lpOzJBKjY7KDM0LDEpOygzNCwxMDIpPSMjKDAsMSk7OlI5cGF0aF9jb252aWk7MkEu
O2Nsb3NlOjooMzQsMTAzKT0jIygwLDEpOzo7MkEqODsoMzQsMSk7O2xvY2s6OigzNCwxMDQp
PSMjKDAsMSk7OmlQNWZsb2NrOzJBKjE1OygzNCwxKTs7aXNfZGV2aWNlOjooMzQsMTA1KT0j
IygyNSwzKTs6OzJBKjI4OygzNCwxKTs7ZnN0YXQ6OigzNCwxMDYpPSMjKDAsMSk7OlA0c3Rh
dDsyQSo5OygzNCwxKTs7Z2V0X25hdGl2ZTo6KDM0LDEwNyk9IyMoMjUsODIpOzo7MkEuOzt+
JSgzNCwxKTsAZmhhbmRsZXJfc2VyaWFsOlR0KDM0LDEwOCk9czYwITEsMDIwLCgzNCwxKTt2
bWluXzovMCgwLDQpLDM4NCwzMjt2dGltZV86LzAoMCw0KSw0MTYsMzI7cGdycF86LzAoMiwy
NyksNDQ4LDMyO19fYXM6OigzNCwxMDkpPSMjKDM0LDExMCk9JigzNCwxMDgpOzpSMTVmaGFu
ZGxlcl9zZXJpYWw7MkEuO2ZoYW5kbGVyX3NlcmlhbDo6KDM0LDExMSk9IyMoMzQsMTEyKT0q
KDM0LDEwOCk7OlJDMTVmaGFuZGxlcl9zZXJpYWw7MkEuKDM0LDExMyk9IygzNCwxMDgpLCgw
LDIwKSwoMzQsMTEyKSwoMCwxKSwoMCwyMCk7Ol8kXzE1ZmhhbmRsZXJfc2VyaWFsOzJBKjE7
KDM0LDEpOygzNCwxMTQpPSMjKDM0LDExMik7OlBDY1VpaTsyQS47b3Blbjo6KDM0LDExNSk9
IyMoMCwxKTs6UENjaWk7MkEqNjsoMzQsMSk7O3Jhd19yZWFkOjooMzQsMTE2KT0jIygwLDEp
OzpQdlVpOzJBKjMzOygzNCwxKTs7dGNzZW5kYnJlYWs6OigzNCwxMTcpPSMjKDAsMSk7Omk7
MkEqMjA7KDM0LDEpOzt0Y2RyYWluOjooMzQsMTE4KT0jIygwLDEpOzo7MkEqMjE7KDM0LDEp
Ozt0Y2Zsb3c6OigzNCwxMTcpOmk7MkEqMjI7KDM0LDEpOzt0Y3NldGF0dHI6OigzNCwxMTkp
PSMjKDAsMSk7OmlQQzd0ZXJtaW9zOzJBKjIzOygzNCwxKTs7dGNnZXRhdHRyOjooMzQsMTIw
KT0jIygwLDEpOzpQN3Rlcm1pb3M7MkEqMjQ7KDM0LDEpOztsc2Vlazo6KDM0LDEyMSk9IyMo
MiwyNCk7OmxpOzJBKjE0OygzNCwxKTs7dGNmbHVzaDo6KDM0LDExNyk6aTsyQSoxOTsoMzQs
MSk7O2R1bXA6OigzNCwxMjIpPSMjKDAsMjApOzo7MkEqMTY7KDM0LDEpOztpc190dHk6Oigz
NCwxMTgpOjsyQSoyNzsoMzQsMSk7O3RjZ2V0cGdycDo6KDM0LDExOCk6OzJBKjI2OygzNCwx
KTs7dGNzZXRwZ3JwOjooMzQsMTIzKT0jIygwLDEpOzppOzJBKjI1OygzNCwxKTs7c2VsZWN0
X3JlYWQ6OigzNCwxMjQpPSMjKDM0LDQ4KTs6UDEzc2VsZWN0X3JlY29yZDsyQSo0MTsoMzQs
MSk7O3NlbGVjdF93cml0ZTo6KDM0LDEyNCk6UDEzc2VsZWN0X3JlY29yZDsyQSo0MjsoMzQs
MSk7O3NlbGVjdF9leGNlcHQ6OigzNCwxMjQpOlAxM3NlbGVjdF9yZWNvcmQ7MkEqNDM7KDM0
LDEpOztyZWFkeV9mb3JfcmVhZDo6KDM0LDEyNSk9IyMoMCwxKTs6VWlpOzJBKjQ0OygzNCwx
KTs7Z2V0X25hdGl2ZTo6KDM0LDEyNik9IyMoMjUsODIpOzo7MkEuOzt+JSgzNCwxKTsAZmhh
bmRsZXJfY29uc29sZTpUdCgzNCw0Myk9czEyNCExLDAyMCwoMzQsMTA4KTtzdGF0ZV86LzAo
MCwxKSw0ODAsMzI7YXJnc186LzAoMzQsMTI3KT1hcigwLDEpOzA7OTsoMCwxKSw1MTIsMzIw
O25hcmdzXzovMCgwLDEpLDgzMiwzMjtvdXRwdXRfaGFuZGxlXzovMCgyNSwxOSksODY0LDMy
O2RlZmF1bHRfY29sb3I6LzAoMjUsMTQpLDg5NiwzMjtpZmxhZ186LzAoMCwxKSw5MjgsMzI7
bGZsYWdfOi8wKDAsMSksOTYwLDMyO19fYXM6OigzNCwxMjgpPSMjKDM0LDEyOSk9JigzNCw0
Myk7OlIxNmZoYW5kbGVyX2NvbnNvbGU7MkEuO2ZoYW5kbGVyX2NvbnNvbGU6OigzNCwxMzAp
PSMjKDM0LDQyKTs6UkMxNmZoYW5kbGVyX2NvbnNvbGU7MkEuKDM0LDEzMSk9IygzNCw0Myks
KDAsMjApLCgzNCw0MiksKDAsMSksKDAsMjApOzpfJF8xNmZoYW5kbGVyX2NvbnNvbGU7MkEq
MTsoMzQsMSk7O3NldF9vdXRwdXRfaGFuZGxlOjooMzQsMTMyKT0jIygwLDIwKTs6UHY7MEEu
O3NldF9jbG9zZV9vbl9leGVjOjooMzQsMTMxKTppOzBBKjQ7KDM0LDEpOztmaXh1cF9hZnRl
cl9mb3JrOjooMzQsMTMyKTpQdjswQSo1OygzNCwxKTs7ZmlsbGluX2luZm86OigzNCwxMzMp
PSMjKDI1LDMpOzo7MEEuO2NsZWFyX3NjcmVlbjo6KDM0LDEzNCk9IyMoMCwyMCk7OmlpaWk7
MEEuO3Njcm9sbF9zY3JlZW46OigzNCwxMzUpPSMjKDAsMjApOzppaWlpaWk7MEEuO2N1cnNv
cl9zZXQ6OigzNCwxMzYpPSMjKDAsMjApOzppaWk7MEEuO2N1cnNvcl9nZXQ6OigzNCwxMzcp
PSMjKDAsMjApOzpQaVQxOzBBLjtjdXJzb3JfcmVsOjooMzQsMTM4KT0jIygwLDIwKTs6aWk7
MEEuO2dldF9pbmZvOjooMzQsMTM5KT0jIygwLDIwKTs6OzBBLjt3cml0ZV9ub3JtYWw6Oigz
NCwxNDApPSMjKDM0LDE0MSk9KigwLDExKTs6UENVY1QxOzBBLjtjaGFyX2NvbW1hbmQ6Oigz
NCwxNDIpPSMjKDAsMjApOzpjOzBBLjtvdXRwdXRfdGNzZXRhdHRyOjooMzQsMTQzKT0jIygw
LDEpOzppUEM3dGVybWlvczswQS47aWduY3JfZW5hYmxlZDo6KDM0LDE0NCk9IyMoMCwxKTs6
OzBBLjtpbnB1dF90Y3NldGF0dHI6OigzNCwxNDMpOmlQQzd0ZXJtaW9zOzBBLjtmaGFuZGxl
cl9jb25zb2xlOjooMzQsMTQ1KT0jIygzNCw0Mik7OlBDYzsyQS47aXNfY29uc29sZTo6KDM0
LDE0Nik9IyMoMzQsNDIpOzo7MkEqMzE7KDM0LDEpOztvcGVuOjooMzQsMTQ3KT0jIygwLDEp
OzpQQ2NpaTsyQSo2OygzNCwxKTs7d3JpdGU6OigzNCwxNDgpPSMjKDAsMSk7OlBDdlVpOzJB
KjEzOygzNCwxKTs7cmVhZDo6KDM0LDE0OSk9IyMoMCwxKTs6UHZVaTsyQSoxMjsoMzQsMSk7
O2Nsb3NlOjooMzQsMTQ0KTo7MkEqODsoMzQsMSk7O3RjZmx1c2g6OigzNCwxNTApPSMjKDAs
MSk7Omk7MkEqMTk7KDM0LDEpOzt0Y3NldGF0dHI6OigzNCwxNDMpOmlQQzd0ZXJtaW9zOzJB
KjIzOygzNCwxKTs7dGNnZXRhdHRyOjooMzQsMTUxKT0jIygwLDEpOzpQN3Rlcm1pb3M7MkEq
MjQ7KDM0LDEpOztkdXA6OigzNCwxNTIpPSMjKDAsMSk7OlAxM2ZoYW5kbGVyX2Jhc2U7MkEq
MTc7KDM0LDEpOztpb2N0bDo6KDM0LDE1Myk9IyMoMCwxKTs6VWlQdjsyQSoxMDsoMzQsMSk7
O2luaXQ6OigzNCwxNTQpPSMjKDAsMjApOzpQdmlVaTsyQSoxODsoMzQsMSk7O3JlYWQxOjoo
MzQsMTU1KT0jIygwLDEpOzpQY1VpUlVpOzJBLjtnZXRfb3V0cHV0X2hhbmRsZTo6KDM0LDE1
Nik9IyMoMjUsMTkpOzo7MkIqMzk7KDM0LDEpOztzZWxlY3RfcmVhZDo6KDM0LDE1Nyk9IyMo
MzQsNDgpOzpQMTNzZWxlY3RfcmVjb3JkOzJBKjQxOygzNCwxKTs7c2VsZWN0X3dyaXRlOjoo
MzQsMTU3KTpQMTNzZWxlY3RfcmVjb3JkOzJBKjQyOygzNCwxKTs7c2VsZWN0X2V4Y2VwdDo6
KDM0LDE1Nyk6UDEzc2VsZWN0X3JlY29yZDsyQSo0MzsoMzQsMSk7O3JlYWR5X2Zvcl9yZWFk
OjooMzQsMTU4KT0jIygwLDEpOzpVaWk7MkEqNDQ7KDM0LDEpOzs7fiUoMzQsMSk7AGZoYW5k
bGVyX3R0eV9jb21tb246VHQoMzQsMTU5KT1zNzYhMSwwMjAsKDM0LDEpO3R0eXA6KDM0LDE2
MCk9KigzNCwxNjEpPXhzdHR5OiwzODQsMzI7b3V0cHV0X2RvbmVfZXZlbnQ6KDI1LDE5KSw0
MTYsMzI7aW9jdGxfcmVxdWVzdF9ldmVudDooMjUsMTkpLDQ0OCwzMjtpb2N0bF9kb25lX2V2
ZW50OigyNSwxOSksNDgwLDMyO291dHB1dF9tdXRleDooMjUsMTkpLDUxMiwzMjtvdXRwdXRf
aGFuZGxlXzooMjUsMTkpLDU0NCwzMjt0dHludW06KDAsMSksNTc2LDMyO19fYXM6OigzNCwx
NjIpPSMjKDM0LDE2Myk9JigzNCwxNTkpOzpSMTlmaGFuZGxlcl90dHlfY29tbW9uOzJBLjtm
aGFuZGxlcl90dHlfY29tbW9uOjooMzQsMTY0KT0jIygzNCwxNjUpPSooMzQsMTU5KTs6UkMx
OWZoYW5kbGVyX3R0eV9jb21tb247MkEuKDM0LDE2Nik9IygzNCwxNTkpLCgwLDIwKSwoMzQs
MTY1KSwoMCwxKSwoMCwyMCk7Ol8kXzE5ZmhhbmRsZXJfdHR5X2NvbW1vbjsyQSoxOygzNCwx
KTs7c2V0X291dHB1dF9oYW5kbGU6OigzNCwxNjcpPSMjKDAsMjApOzpQdjsyQS47ZmhhbmRs
ZXJfdHR5X2NvbW1vbjo6KDM0LDE2OCk9IyMoMzQsMTY1KTs6VWlQQ2NpOzJBLjtkdXA6Oigz
NCwxNjkpPSMjKDAsMSk7OlAxM2ZoYW5kbGVyX2Jhc2U7MkEqMTc7KDM0LDEpOztnZXRfdW5p
dDo6KDM0LDE3MCk9IyMoMCwxKTs6OzJBKjI7KDM0LDEpOztzZXRfY2xvc2Vfb25fZXhlYzo6
KDM0LDE2Nik6aTsyQSo0OygzNCwxKTs7Zml4dXBfYWZ0ZXJfZm9yazo6KDM0LDE2Nyk6UHY7
MkEqNTsoMzQsMSk7O3NlbGVjdF9yZWFkOjooMzQsMTcxKT0jIygzNCw0OCk7OlAxM3NlbGVj
dF9yZWNvcmQ7MkEqNDE7KDM0LDEpOztzZWxlY3Rfd3JpdGU6OigzNCwxNzEpOlAxM3NlbGVj
dF9yZWNvcmQ7MkEqNDI7KDM0LDEpOztzZWxlY3RfZXhjZXB0OjooMzQsMTcxKTpQMTNzZWxl
Y3RfcmVjb3JkOzJBKjQzOygzNCwxKTs7cmVhZHlfZm9yX3JlYWQ6OigzNCwxNzIpPSMjKDAs
MSk7OlVpaTsyQSo0NDsoMzQsMSk7Ozt+JSgzNCwxKTsAZmhhbmRsZXJfdHR5X3NsYXZlOlR0
KDM0LDE3Myk9czgwITEsMDIwLCgzNCwxNTkpO2ludXNlX2V2ZW50OigyNSwxOSksNjA4LDMy
O19fYXM6OigzNCwxNzQpPSMjKDM0LDE3NSk9JigzNCwxNzMpOzpSMThmaGFuZGxlcl90dHlf
c2xhdmU7MkEuO2ZoYW5kbGVyX3R0eV9zbGF2ZTo6KDM0LDE3Nik9IyMoMzQsMTc3KT0qKDM0
LDE3Myk7OlJDMThmaGFuZGxlcl90dHlfc2xhdmU7MkEuKDM0LDE3OCk9IygzNCwxNzMpLCgw
LDIwKSwoMzQsMTc3KSwoMCwxKSwoMCwyMCk7Ol8kXzE4ZmhhbmRsZXJfdHR5X3NsYXZlOzJB
KjE7KDM0LDEpOztzZW5kX2lvY3RsX3JlcXVlc3Q6OigzNCwxNzkpPSMjKDAsMjApOzo7MEEu
O2ZoYW5kbGVyX3R0eV9zbGF2ZTo6KDM0LDE4MCk9IyMoMzQsMTc3KTs6UENjOzJBLigzNCwx
ODEpPSMjKDM0LDE3Nyk7OmlQQ2M7MkEuO29wZW46OigzNCwxODIpPSMjKDAsMSk7OlBDY2lp
OzJBKjY7KDM0LDEpOzt3cml0ZTo6KDM0LDE4Myk9IyMoMCwxKTs6UEN2VWk7MkEqMTM7KDM0
LDEpOztyZWFkOjooMzQsMTg0KT0jIygwLDEpOzpQdlVpOzJBKjEyOygzNCwxKTs7Y2xvc2U6
OigzNCwxODUpPSMjKDAsMSk7OjsyQSo4OygzNCwxKTs7aW5pdDo6KDM0LDE4Nik9IyMoMCwy
MCk7OlB2aVVpOzJBKjE4OygzNCwxKTs7dGNzZXRhdHRyOjooMzQsMTg3KT0jIygwLDEpOzpp
UEM3dGVybWlvczsyQSoyMzsoMzQsMSk7O3RjZ2V0YXR0cjo6KDM0LDE4OCk9IyMoMCwxKTs6
UDd0ZXJtaW9zOzJBKjI0OygzNCwxKTs7dGNzZXRwZ3JwOjooMzQsMTg5KT0jIygwLDEpOzpp
OzJBKjI1OygzNCwxKTs7dGNnZXRwZ3JwOjooMzQsMTg1KTo7MkEqMjY7KDM0LDEpOzt0Y2Zs
dXNoOjooMzQsMTkwKT0jIygwLDEpOzppOzJBKjE5OygzNCwxKTs7aW9jdGw6OigzNCwxOTEp
PSMjKDAsMSk7OlVpUHY7MkEqMTA7KDM0LDEpOztsc2Vlazo6KDM0LDE5Mik9IyMoMiwyNCk7
OmxpOzJBKjE0OygzNCwxKTs7aXNfdHR5OjooMzQsMTg1KTo7MkEqMjc7KDM0LDEpOztkdXA6
OigzNCwxOTMpPSMjKDAsMSk7OlAxM2ZoYW5kbGVyX2Jhc2U7MkEqMTc7KDM0LDEpOztnZXRf
b3V0cHV0X2hhbmRsZTo6KDM0LDE5NCk9IyMoMjUsMTkpOzo7MkIqMzk7KDM0LDEpOztzZXRf
Y2xvc2Vfb25fZXhlYzo6KDM0LDE3OCk6aTsyQSo0OygzNCwxKTs7Zml4dXBfYWZ0ZXJfZm9y
azo6KDM0LDE5NSk9IyMoMCwyMCk7OlB2OzJBKjU7KDM0LDEpOzs7fiUoMzQsMSk7AGZoYW5k
bGVyX3B0eV9tYXN0ZXI6VHQoMzQsMTk2KT1zODghMSwwMjAsKDM0LDE1OSk7cGt0bW9kZTov
MCgwLDEpLDYwOCwzMjtyZXN0YXJ0X291dHB1dF9ldmVudDooMjUsMTkpLDY0MCwzMjtuZWVk
bmxfOigwLDEpLDY3MiwzMjtfX2FzOjooMzQsMTk3KT0jIygzNCwxOTgpPSYoMzQsMTk2KTs6
UjE5ZmhhbmRsZXJfcHR5X21hc3RlcjsyQS47ZmhhbmRsZXJfcHR5X21hc3Rlcjo6KDM0LDE5
OSk9IyMoMzQsMjAwKT0qKDM0LDE5Nik7OlJDMTlmaGFuZGxlcl9wdHlfbWFzdGVyOzJBLigz
NCwyMDEpPSMoMzQsMTk2KSwoMCwyMCksKDM0LDIwMCksKDAsMSksKDAsMjApOzpfJF8xOWZo
YW5kbGVyX3B0eV9tYXN0ZXI7MkEqMTsoMzQsMSk7KDM0LDIwMik9IyMoMzQsMjAwKTs6UENj
VWk7MkEuO3Byb2Nlc3NfaW5wdXRfdG9fc2xhdmU6OigzNCwyMDMpPSMjKDAsMSk7OlBDY2k7
MkEuO3Byb2Nlc3Nfc2xhdmVfb3V0cHV0OjooMzQsMjA0KT0jIygwLDEpOzpQY1VpOzJBLjtk
b2VjaG86OigzNCwyMDUpPSMjKDAsMjApOzpQQ3ZVaTsyQS47b3Blbjo6KDM0LDIwNik9IyMo
MCwxKTs6UENjaWk7MkEqNjsoMzQsMSk7O3dyaXRlOjooMzQsMjA3KT0jIygwLDEpOzpQQ3ZV
aTsyQSoxMzsoMzQsMSk7O3JlYWQ6OigzNCwyMDgpPSMjKDAsMSk7OlB2VWk7MkEqMTI7KDM0
LDEpOztjbG9zZTo6KDM0LDIwOSk9IyMoMCwxKTs6OzJBKjg7KDM0LDEpOzt0Y3NldGF0dHI6
OigzNCwyMTApPSMjKDAsMSk7OmlQQzd0ZXJtaW9zOzJBKjIzOygzNCwxKTs7dGNnZXRhdHRy
OjooMzQsMjExKT0jIygwLDEpOzpQN3Rlcm1pb3M7MkEqMjQ7KDM0LDEpOzt0Y2ZsdXNoOjoo
MzQsMjEyKT0jIygwLDEpOzppOzJBKjE5OygzNCwxKTs7aW9jdGw6OigzNCwyMTMpPSMjKDAs
MSk7OlVpUHY7MkEqMTA7KDM0LDEpOztsc2Vlazo6KDM0LDIxNCk9IyMoMiwyNCk7OmxpOzJB
KjE0OygzNCwxKTs7aXNfdHR5OjooMzQsMjA5KTo7MkEqMjc7KDM0LDEpOztwdHNuYW1lOjoo
MzQsMjE1KT0jIygyLDEwKTs6OzJBKjI5OygzNCwxKTs7Z2V0X291dHB1dF9oYW5kbGU6Oigz
NCwyMTYpPSMjKDI1LDE5KTs6OzJCKjM5OygzNCwxKTs7c2V0X2Nsb3NlX29uX2V4ZWM6Oigz
NCwyMDEpOmk7MkEqNDsoMzQsMSk7O2ZpeHVwX2FmdGVyX2Zvcms6OigzNCwyMTcpPSMjKDAs
MjApOzpQdjsyQSo1OygzNCwxKTs7aGl0X2VvZjo6KDM0LDIxOCk9IyMoMjUsMyk7OjsyQSo0
MDsoMzQsMSk7Ozt+JSgzNCwxKTsAZmhhbmRsZXJfdHR5X21hc3RlcjpUdCgzNCwyMTkpPXM5
NiExLDAyMCwoMzQsMTk2KTtjb25zb2xlOigzNCw1KSw3MDQsMzI7aFRocmVhZDooMjUsMTkp
LDczNiwzMjtfX2FzOjooMzQsMjIwKT0jIygzNCwyMjEpPSYoMzQsMjE5KTs6UjE5ZmhhbmRs
ZXJfdHR5X21hc3RlcjsyQS47ZmhhbmRsZXJfdHR5X21hc3Rlcjo6KDM0LDIyMik9IyMoMzQs
MjIzKT0qKDM0LDIxOSk7OlJDMTlmaGFuZGxlcl90dHlfbWFzdGVyOzJBLigzNCwyMjQpPSMo
MzQsMjE5KSwoMCwyMCksKDM0LDIyMyksKDAsMSksKDAsMjApOzpfJF8xOWZoYW5kbGVyX3R0
eV9tYXN0ZXI7MkEqMTsoMzQsMSk7KDM0LDIyNSk9IyMoMzQsMjIzKTs6UENjOzJBLjtpbml0
OjooMzQsMjI2KT0jIygwLDEpOzppOzJBLjs7fiUoMzQsMSk7AGZoYW5kbGVyX2Rldl9udWxs
OlR0KDM0LDIyNyk9czQ4ITEsMDIwLCgzNCwxKTtfX2FzOjooMzQsMjI4KT0jIygzNCwyMjkp
PSYoMzQsMjI3KTs6UjE3ZmhhbmRsZXJfZGV2X251bGw7MkEuO2ZoYW5kbGVyX2Rldl9udWxs
OjooMzQsMjMwKT0jIygzNCwyMzEpPSooMzQsMjI3KTs6UkMxN2ZoYW5kbGVyX2Rldl9udWxs
OzJBLigzNCwyMzIpPSMoMzQsMjI3KSwoMCwyMCksKDM0LDIzMSksKDAsMSksKDAsMjApOzpf
JF8xN2ZoYW5kbGVyX2Rldl9udWxsOzJBKjE7KDM0LDEpOygzNCwyMzMpPSMjKDM0LDIzMSk7
OlBDYzsyQS47ZHVtcDo6KDM0LDIzNCk9IyMoMCwyMCk7OjsyQSoxNjsoMzQsMSk7O3NlbGVj
dF9yZWFkOjooMzQsMjM1KT0jIygzNCw0OCk7OlAxM3NlbGVjdF9yZWNvcmQ7MkEqNDE7KDM0
LDEpOztzZWxlY3Rfd3JpdGU6OigzNCwyMzUpOlAxM3NlbGVjdF9yZWNvcmQ7MkEqNDI7KDM0
LDEpOztzZWxlY3RfZXhjZXB0OjooMzQsMjM1KTpQMTNzZWxlY3RfcmVjb3JkOzJBKjQzOygz
NCwxKTs7O34lKDM0LDEpOwBmaGFuZGxlcl93aW5kb3dzOlR0KDM0LDIzNik9czU2ITEsMDIw
LCgzNCwxKTtoV25kXzovMCgyNSw2MSksMzg0LDMyO21ldGhvZF86LzAoMCwxKSw0MTYsMzI7
X19hczo6KDM0LDIzNyk9IyMoMzQsMjM4KT0mKDM0LDIzNik7OlIxNmZoYW5kbGVyX3dpbmRv
d3M7MkEuO2ZoYW5kbGVyX3dpbmRvd3M6OigzNCwyMzkpPSMjKDM0LDI0MCk9KigzNCwyMzYp
OzpSQzE2ZmhhbmRsZXJfd2luZG93czsyQS4oMzQsMjQxKT0jKDM0LDIzNiksKDAsMjApLCgz
NCwyNDApLCgwLDEpLCgwLDIwKTs6XyRfMTZmaGFuZGxlcl93aW5kb3dzOzJBKjE7KDM0LDEp
OygzNCwyNDIpPSMjKDM0LDI0MCk7OlBDYzsyQS47aXNfd2luZG93czo6KDM0LDI0Myk9IyMo
MCwxKTs6OzJBKjMyOygzNCwxKTs7b3Blbjo6KDM0LDI0NCk9IyMoMCwxKTs6UENjaWk7MkEq
NjsoMzQsMSk7O3dyaXRlOjooMzQsMjQ1KT0jIygwLDEpOzpQQ3ZVaTsyQSoxMzsoMzQsMSk7
O3JlYWQ6OigzNCwyNDYpPSMjKDAsMSk7OlB2VWk7MkEqMTI7KDM0LDEpOztpb2N0bDo6KDM0
LDI0Nyk9IyMoMCwxKTs6VWlQdjsyQSoxMDsoMzQsMSk7O2xzZWVrOjooMzQsMjQ4KT0jIygy
LDI0KTs6bGk7MkEqMTQ7KDM0LDEpOztjbG9zZTo6KDM0LDI0Myk6OzJBKjg7KDM0LDEpOztz
ZXRfY2xvc2Vfb25fZXhlYzo6KDM0LDI0MSk6aTsyQSo0OygzNCwxKTs7Zml4dXBfYWZ0ZXJf
Zm9yazo6KDM0LDI0OSk9IyMoMCwyMCk7OlB2OzJBKjU7KDM0LDEpOztzZWxlY3RfcmVhZDo6
KDM0LDI1MCk9IyMoMzQsNDgpOzpQMTNzZWxlY3RfcmVjb3JkOzJBKjQxOygzNCwxKTs7c2Vs
ZWN0X3dyaXRlOjooMzQsMjUwKTpQMTNzZWxlY3RfcmVjb3JkOzJBKjQyOygzNCwxKTs7c2Vs
ZWN0X2V4Y2VwdDo6KDM0LDI1MCk6UDEzc2VsZWN0X3JlY29yZDsyQSo0MzsoMzQsMSk7O3Jl
YWR5X2Zvcl9yZWFkOjooMzQsMjUxKT0jIygwLDEpOzpVaWk7MkEqNDQ7KDM0LDEpOzs7fiUo
MzQsMSk7AHNlbGVjdF9yZWNvcmQ6VHQoMzQsNDkpPXM2MGZkOigwLDEpLDAsMzI7aDooMjUs
MTkpLDMyLDMyO2ZoOigzNCw1KSw2NCwzMjt3aW5kb3dzX2hhbmRsZTooMjUsMyksOTYsMzI7
cmVhZF9yZWFkeTooMjUsMyksMTI4LDMyO3dyaXRlX3JlYWR5OigyNSwzKSwxNjAsMzI7ZXhj
ZXB0X3JlYWR5OigyNSwzKSwxOTIsMzI7cmVhZF9zZWxlY3RlZDooMjUsMyksMjI0LDMyO3dy
aXRlX3NlbGVjdGVkOigyNSwzKSwyNTYsMzI7ZXhjZXB0X3NlbGVjdGVkOigyNSwzKSwyODgs
MzI7c3RhcnR1cDooMzQsMjUyKT0qKDM0LDI1Myk9ZigwLDEpLDMyMCwzMjtwb2xsOigzNCwy
NTQpPSooMzQsMjU1KT1mKDAsMSksMzUyLDMyO3ZlcmlmeTooMzQsMjU0KSwzODQsMzI7Y2xl
YW51cDooMzQsMjU2KT0qKDM0LDI1Nyk9ZigwLDIwKSw0MTYsMzI7bmV4dDooMzQsNDgpLDQ0
OCwzMjtfX2FzOjooMzQsMjU4KT0jIygzNCwyNTkpPSYoMzQsNDkpOzpSQzEzc2VsZWN0X3Jl
Y29yZDsyQS47c2VsZWN0X3JlY29yZDo6KDM0LDI2MCk9IyMoMzQsNDgpOzpSQzEzc2VsZWN0
X3JlY29yZDsyQS4oMzQsMjYxKT0jIygzNCw0OCk7OlAxM2ZoYW5kbGVyX2Jhc2U7MkEuOzsA
c2VsZWN0X3N0dWZmOlR0KDM0LDI2Mik9czE1MmFsd2F5c19yZWFkeTooMjUsMyksMCwzMjt3
aW5kb3dzX3VzZWQ6KDI1LDMpLDMyLDMyO3RvdGFsOigwLDEpLDY0LDMyO3N0YXJ0OigzNCw0
OSksOTYsNDgwO2RldmljZV9zcGVjaWZpYzooMzQsMjYzKT1hcigwLDEpOzA7MTk7KDAsMjMp
LDU3Niw2NDA7X19hczo6KDM0LDI2NCk9IyMoMzQsMjY1KT0mKDM0LDI2Mik7OlJDMTJzZWxl
Y3Rfc3R1ZmY7MkEuO3NlbGVjdF9zdHVmZjo6KDM0LDI2Nik9IyMoMzQsMjY3KT0qKDM0LDI2
Mik7OlJDMTJzZWxlY3Rfc3R1ZmY7MkEuKDM0LDI2OCk9IyMoMzQsMjY3KTs6OzJBLigzNCwy
NjkpPSMoMzQsMjYyKSwoMCwyMCksKDM0LDI2NyksKDAsMSksKDAsMjApOzpfJF8xMnNlbGVj
dF9zdHVmZjsyQS47dGVzdF9hbmRfc2V0OjooMzQsMjcwKT0jIygwLDEpOzppUDEzX3R5cGVz
X2ZkX3NldE4yMjsyQS47cG9sbDo6KDM0LDI3MSk9IyMoMCwxKTs6UDEzX3R5cGVzX2ZkX3Nl
dE4yMTsyQS47d2FpdDo6KDM0LDI3Mik9IyMoMCwxKTs6UDEzX3R5cGVzX2ZkX3NldE4yMVVp
OzJBLjs7AC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vd2luc3VwL3BhdGgu
aABzdWZmaXhfaW5mbzpUdCgzNiwxKT1zOG5hbWU6KDI1LDgyKSwwLDMyO2FkZG9uOigwLDEp
LDMyLDMyO19fYXM6OigzNiwyKT0jIygzNiwzKT0mKDM2LDEpOzpSQzExc3VmZml4X2luZm87
MkEuO3N1ZmZpeF9pbmZvOjooMzYsNCk9IyMoMzYsNSk9KigzNiwxKTs6UkMxMXN1ZmZpeF9p
bmZvOzJBLigzNiw2KT0jIygzNiw1KTs6UENjaTsyQS47OwBzeW1saW5rX2ZvbGxvdzp0KDM2
LDcpPWVTWU1MSU5LX0ZPTExPVzowLFNZTUxJTktfTk9GT0xMT1c6MSxTWU1MSU5LX0lHTk9S
RToyLFNZTUxJTktfQ09OVEVOVFM6Myw7AHBhdGhfY29udjpUdCgzNiw4KT1zMjk2cGF0aDov
MCgyOCwxMTYxKSwwLDIwODA7YmluYXJ5X3A6KDAsMiksMjA4MCw4O3NpbGVudF9wOigwLDIp
LDIwODgsODtzeW1saW5rX3A6KDAsMSksMjExMiwzMjtleGVjX3A6KDAsMSksMjE0NCwzMjtz
Y3JpcHRfcDooMCwxKSwyMTc2LDMyO2tub3duX3N1ZmZpeDooMiwxMCksMjIwOCwzMjtlcnJv
cjooMCwxKSwyMjQwLDMyO2Rldm46KDI1LDE0KSwyMjcyLDMyO3VuaXQ6KDAsMSksMjMwNCwz
MjtmaWxlYXR0cjooMjUsMTQpLDIzMzYsMzI7X19hczo6KDM2LDkpPSMjKDM2LDEwKT0mKDM2
LDgpOzpSQzlwYXRoX2NvbnY7MkEuO3BhdGhfY29udjo6KDM2LDExKT0jIygzNiwxMik9Kigz
Niw4KTs6UkM5cGF0aF9jb252OzJBLigzNiwxMyk9IyMoMzYsMTIpOzpQQ2MxNHN5bWxpbmtf
Zm9sbG93aVBDMTFzdWZmaXhfaW5mbzsyQS47Z2V0X3dpbjMyOjooMzYsMTQpPSMjKDIsMTAp
Ozo7MkEuO2lzX2RldmljZTo6KDM2LDE1KT0jIygyNSwzKTs6OzJBLjtnZXRfZGV2bjo6KDM2
LDE2KT0jIygyNSwxNCk7OjsyQS47Z2V0X3VuaXRuOjooMzYsMTcpPSMjKDAsOCk7OjsyQS47
ZmlsZV9hdHRyaWJ1dGVzOjooMzYsMTYpOjsyQS47OwBtb3VudF9pdGVtOlR0KDM2LDE4KT1z
NTMyZGV2aWNlOigyOCwxMTYxKSwwLDIwODA7ZGV2aWNlbGVuOigwLDEpLDIwODAsMzI7cGF0
aDooMjgsMTE2MSksMjExMiwyMDgwO3BhdGhsZW46KDAsMSksNDE5MiwzMjtiaW5hcnk6KDAs
MiksNDIyNCw4O3NpbGVudDooMCwyKSw0MjMyLDg7X19hczo6KDM2LDE5KT0jIygzNiwyMCk9
JigzNiwxOCk7OlJDMTBtb3VudF9pdGVtOzJBLjttb3VudF9pdGVtOjooMzYsMjEpPSMjKDM2
LDIyKT0qKDM2LDE4KTs6UkMxMG1vdW50X2l0ZW07MkEuKDM2LDIzKT0jIygzNiwyMik7Ojsy
QS47aW5pdDo6KDM2LDI0KT0jIygwLDIwKTs6UENjVDFpOzJBLjtnZXRtbnRlbnQ6OigzNiwy
NSk9IyMoMzYsMjYpPSooMzYsMjcpPXhzbW50ZW50Ojs6OzJBLjs7AG1vdW50X2luZm86VHQo
MzYsMjgpPXMxNTk2NG5tb3VudHM6KDAsMSksMCwzMjttb3VudDooMzYsMjkpPWFyKDAsMSk7
MDsyOTsoMzYsMTgpLDMyLDEyNzY4MDtfX2FzOjooMzYsMzApPSMjKDM2LDMxKT0mKDM2LDI4
KTs6UkMxMG1vdW50X2luZm87MkEuO21vdW50X2luZm86OigzNiwzMik9IyMoMzYsMzMpPSoo
MzYsMjgpOzpSQzEwbW91bnRfaW5mbzsyQS4oMzYsMzQpPSMjKDM2LDMzKTs6OzJBLjtpbml0
OjooMzYsMzUpPSMjKDAsMjApOzo7MkEuO2FkZF9pdGVtOjooMzYsMzYpPSMjKDAsMSk7OlBD
Y1QxaTsyQS47ZGVsX2l0ZW06OigzNiwzNyk9IyMoMCwxKTs6UENjOzJBLjtzb3J0OjooMzYs
MzUpOjsyQS47dG9fcmVnaXN0cnk6OigzNiwzNSk6OzJBLjtmcm9tX3JlZ2lzdHJ5OjooMzYs
MzUpOjsyQS47cG9zaXhfcGF0aF9wOjooMzYsMzgpPSMjKDAsMSk7OjsyQS47YmluYXJ5X3dp
bjMyX3BhdGhfcDo6KDM2LDM3KTpQQ2M7MkEuO2NvbnZfdG9fd2luMzJfcGF0aDo6KDM2LDM5
KT0jIygwLDEpOzpQQ2NQY1QyUlVpUmk7MkEuO2NvbnZfdG9fcG9zaXhfcGF0aDo6KDM2LDQw
KT0jIygwLDEpOzpQQ2NQY2k7MkEuO2dldG1udGVudDo6KDM2LDQxKT0jIygzNiwyNik7Omk7
MkEuOzsAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvZmhhbmRs
ZXJfdHR5LmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvaW5j
bHVkZS9zeXMvdGVybWlvcy5oAGNjX3Q6dCgzOCwxKT0oMCwxMSkAdGNmbGFnX3Q6dCgzOCwy
KT0oMCw5KQBzcGVlZF90OnQoMzgsMyk9KDAsMTEpAHRlcm1pb3M6VHQoMzgsNCk9czMwY19p
ZmxhZzooMzgsMiksMCwxNjtjX29mbGFnOigzOCwyKSwxNiwxNjtjX2NmbGFnOigzOCwyKSwz
MiwxNjtjX2xmbGFnOigzOCwyKSw0OCwxNjtjX2xpbmU6KDAsMiksNjQsODtjX2NjOigyOCwx
ODc3KSw3MiwxNDQ7Y19pc3BlZWQ6KDM4LDMpLDIxNiw4O2Nfb3NwZWVkOigzOCwzKSwyMjQs
ODtfX2FzOjooMzgsNSk9IyMoMzgsNik9JigzOCw0KTs6UkM3dGVybWlvczsyQS47dGVybWlv
czo6KDM4LDcpPSMjKDM4LDgpPSooMzgsNCk7OlJDN3Rlcm1pb3M7MkEuKDM4LDkpPSMjKDM4
LDgpOzo7MkEuOzsAd2luc2l6ZTpUdCgzOCwxMCk9czh3c19yb3c6KDAsOSksMCwxNjt3c19j
b2w6KDAsOSksMTYsMTY7d3NfeHBpeGVsOigwLDkpLDMyLDE2O3dzX3lwaXhlbDooMCw5KSw0
OCwxNjtfX2FzOjooMzgsMTEpPSMjKDM4LDEyKT0mKDM4LDEwKTs6UkM3d2luc2l6ZTsyQS47
d2luc2l6ZTo6KDM4LDEzKT0jIygzOCwxNCk9KigzOCwxMCk7OlJDN3dpbnNpemU7MkEuKDM4
LDE1KT0jIygzOCwxNCk7OjsyQS47OwB0dHk6VHQoMzQsMTYxKT1zMTMybnR0eTooMCwxKSww
LDMyO3Rlcm1pb3M6KDM4LDQpLDMyLDI0MDt3aW5zaXplOigzOCwxMCksMjcyLDY0O2NtZDoo
MCwxKSwzNTIsMzI7YXJnOigzNywxKT11MzJ0ZXJtaW9zOigzOCw0KSwwLDI0MDt3aW5zaXpl
OigzOCwxMCksMCw2NDt2YWx1ZTooMCwxKSwwLDMyO3BpZDooMiwyNyksMCwzMjtfX2FzOjoo
MzcsMik9IygzNywxKSwoMzcsMyk9JigzNywxKSwoMzcsNCk9KigzNywxKSwoMzcsNSk9Jigz
NywxKSwoMCwyMCk7Ol9fYXNfX1EyM3R0eTQkXzUyUkNRMjN0dHk0JF81MjsyQS47JF81Mjo6
KDM3LDYpPSMoMzcsMSksKDM3LDQpLCgzNyw0KSwoMzcsNSksKDAsMjApOzpfX1EyM3R0eTQk
XzUyUkNRMjN0dHk0JF81MjsyQS4oMzcsNyk9IygzNywxKSwoMzcsNCksKDM3LDQpLCgwLDIw
KTs6X19RMjN0dHk0JF81MjsyQS47OywzODQsMjU2O2lvY3RsX3JldHZhbDooMCwxKSw2NDAs
MzI7cmVhZF9yZXR2YWw6KDAsMSksNjcyLDMyO091dHB1dFN0b3BwZWQ6KDI1LDMpLDcwNCwz
Mjt3cml0ZV9yZXR2YWw6KDAsMSksNzM2LDMyO3BnaWQ6KDIsMjcpLDc2OCwzMjtzaWQ6KDIs
MjcpLDgwMCwzMjtod25kOigyNSw2MSksODMyLDMyO21hc3Rlcl9waWQ6KDI1LDE0KSw4NjQs
MzI7ZnJvbV9tYXN0ZXI6KDI1LDE5KSw4OTYsMzI7dG9fc2xhdmU6KDI1LDE5KSw5MjgsMzI7
ZnJvbV9zbGF2ZTooMjUsMTkpLDk2MCwzMjt0b19tYXN0ZXI6KDI1LDE5KSw5OTIsMzI7aW51
c2VfZXZlbnQ6KDI1LDE5KSwxMDI0LDMyO19fYXM6OigzNyw4KT0jIygzNyw5KT0mKDM0LDE2
MSk7OlJDM3R0eTsyQS47dHR5OjooMzcsMTApPSMjKDM0LDE2MCk7OlJDM3R0eTsyQS4oMzcs
MTEpPSMjKDM0LDE2MCk7OjsyQS47Z2V0X2V2ZW50OjooMzcsMTIpPSMjKDI1LDE5KTs6UENj
aTswQS47aW5pdDo6KDM3LDEzKT0jIygwLDIwKTs6OzJBLjtjb21tb25faW5pdDo6KDM3LDE0
KT0jIygyNSwzKTs6UDE5ZmhhbmRsZXJfcHR5X21hc3RlcjsyQS47aW51c2U6OigzNywxNSk9
IyMoMjUsMyk7OjsyQS47aW51c2VfZXZlbnRfZXhpc3RzOjooMzcsMTUpOjsyQS47Z2V0c2lk
OjooMzcsMTYpPSMjKDAsMSk7OjsyQS47c2V0c2lkOjooMzcsMTcpPSMjKDAsMjApOzppOzJB
LjtnZXRwZ2lkOjooMzcsMTgpPSMjKDIsMjcpOzo7MkEuO3NldHBnaWQ6OigzNywxNyk6aTsy
QS47c2V0bnR0eTo6KDM3LDE5KT0jIygwLDIwKTs6aTsyQS47Z2V0aHduZDo6KDM3LDIwKT0j
IygyNSw2MSk7OjsyQS47c2V0aHduZDo6KDM3LDIxKT0jIygwLDIwKTs6UHY7MkEuO21ha2Vf
cGlwZXM6OigzNywyMik9IyMoMCwxKTs6UDE5ZmhhbmRsZXJfcHR5X21hc3RlcjsyQS47c2xh
dmVfb3BlbmVkOjooMzcsMjMpPSMjKDAsMjApOzpQdjsyQS47OwB0dHlfbGlzdDpUdCgzNywy
NCk9czE2ODk2dHR5czovMCgzNywyNSk9YXIoMCwxKTswOzEyNzsoMzQsMTYxKSwwLDEzNTE2
ODtfX2FzOjooMzcsMjYpPSMjKDM3LDI3KT0mKDM3LDI0KTs6UkM4dHR5X2xpc3Q7MkEuO3R0
eV9saXN0OjooMzcsMjgpPSMjKDM3LDI5KT0qKDM3LDI0KTs6UkM4dHR5X2xpc3Q7MkEuKDM3
LDMwKT0jIygzNywyOSk7OjsyQS47X192Yzo6KDM3LDMxKT0jIygzNCwxNjApOzppOzJBLjth
bGxvY2F0ZV90dHk6OigzNywzMik9IyMoMCwxKTs6aTsyQS47Y29ubmVjdF90dHk6OigzNywz
Mik6aTsyQS47dGVybWluYXRlOjooMzcsMzMpPSMjKDAsMjApOzo7MkEuO2luaXQ6OigzNywz
Myk6OzJBLjs7AC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vd2luc3VwL2Rl
bHF1ZXVlLmgAZGVscXVldWVfbGlzdDpUdCgzOSwxKT1zMjYxMDRuYW1lOi8wKDM5LDIpPWFy
KDAsMSk7MDs5OTsoMjgsMTE2MSksMCwyMDgwMDA7aW51c2U6LzAoMzksMyk9YXIoMCwxKTsw
Ozk5OygwLDIpLDIwODAwMCw4MDA7ZW1wdHk6LzAoMCwxKSwyMDg4MDAsMzI7X19hczo6KDM5
LDQpPSMjKDM5LDUpPSYoMzksMSk7OlJDMTNkZWxxdWV1ZV9saXN0OzJBLjtkZWxxdWV1ZV9s
aXN0OjooMzksNik9IyMoMzksNyk9KigzOSwxKTs6UkMxM2RlbHF1ZXVlX2xpc3Q7MkEuKDM5
LDgpPSMjKDM5LDcpOzo7MkEuO2luaXQ6OigzOSw5KT0jIygwLDIwKTs6OzJBLjtxdWV1ZV9m
aWxlOjooMzksMTApPSMjKDAsMjApOzpQQ2M7MkEuO3Byb2Nlc3NfcXVldWU6OigzOSw5KTo7
MkEuOzsAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5zdXAvZGVidWcu
aAAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL3dpbnN1cC9pbmNsdWRlL2N5
Z3dpbi92ZXJzaW9uLmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by93aW5z
dXAvc2lncHJvYy5oAHByb2NzdHVmZjp0KDQyLDEpPWVQUk9DX0FERENISUxEOjEsUFJPQ19D
SElMRFNUT1BQRUQ6MixQUk9DX0NISUxEVEVSTUlOQVRFRDozLFBST0NfQ0xFQVJXQUlUOjQs
UFJPQ19XQUlUOjUsOwBzdHJ1Y3Rfd2FpdHE6VHQoNDIsMik9czI4cGlkOigwLDEpLDAsMzI7
b3B0aW9uczooMCwxKSwzMiwzMjtzdGF0dXM6KDAsMSksNjQsMzI7ZXY6KDI1LDE5KSw5Niwz
MjtydXNhZ2U6KDAsMjMpLDEyOCwzMjtuZXh0Oig0MiwzKT0qKDQyLDIpLDE2MCwzMjt0aHJl
YWRfZXY6KDI1LDE5KSwxOTIsMzI7X19hczo6KDQyLDQpPSMjKDQyLDUpPSYoNDIsMik7OlJD
MTJzdHJ1Y3Rfd2FpdHE7MkEuO3N0cnVjdF93YWl0cTo6KDQyLDYpPSMjKDQyLDMpOzpSQzEy
c3RydWN0X3dhaXRxOzJBLig0Miw3KT0jIyg0MiwzKTs6OzJBLjs7AHdhaXRxOnQoNDIsOCk9
KDQyLDIpAHBlcl9wcm9jZXNzOlR0KDEsMik9czE2OGluaXRpYWxfc3A6KDIsMTApLDAsMzI7
bWFnaWNfYmlzY3VpdDooMjUsMTQpLDMyLDMyO2RsbF9tYWpvcjooMjUsMTQpLDY0LDMyO2Rs
bF9taW5vcjooMjUsMTQpLDk2LDMyO2ltcHVyZV9wdHJfcHRyOigxLDMpPSooMSw0KT0qKDEs
NSk9eHNfcmVlbnQ6LDEyOCwzMjtlbnZwdHI6KDEsNik9KigxLDcpPSooMiwxMCksMTYwLDMy
O21hbGxvYzooMSw4KT0qKDEsOSk9ZigwLDIzKSwxOTIsMzI7ZnJlZTooMSwxMCk9KigxLDEx
KT1mKDAsMjApLDIyNCwzMjtyZWFsbG9jOigxLDEyKT0qKDEsMTMpPWYoMCwyMyksMjU2LDMy
O2Ztb2RlX3B0cjooMjUsOTEpLDI4OCwzMjttYWluOigxLDE0KT0qKDEsMTUpPWYoMCwxKSwz
MjAsMzI7Y3RvcnM6KDEsMTYpPSooMSwxNyk9KigxLDE4KT1mKDAsMjApLDM1MiwzMjtkdG9y
czooMSwxNiksMzg0LDMyO2RhdGFfc3RhcnQ6KDAsMjMpLDQxNiwzMjtkYXRhX2VuZDooMCwy
MyksNDQ4LDMyO2Jzc19zdGFydDooMCwyMyksNDgwLDMyO2Jzc19lbmQ6KDAsMjMpLDUxMiwz
MjtjYWxsb2M6KDEsMTkpPSooMSwyMCk9ZigwLDIzKSw1NDQsMzI7cHVibGljX3Jlc2VydmVk
OigxLDIxKT1hcigwLDEpOzA7MzsoMCwyMyksNTc2LDEyODtydW5fY3RvcnNfcDooMCwxKSw3
MDQsMzI7X19pbXBfbWFsbG9jOigwLDEpLDczNiwzMjtfX2ltcF9mcmVlOigwLDEpLDc2OCwz
MjtfX2ltcF9yZWFsbG9jOigwLDEpLDgwMCwzMjtiYXNlOigwLDIzKSw4MzIsMzI7cHRyOigw
LDIzKSw4NjQsMzI7c2l6ZTooMywyKSw4OTYsMzI7cmVzZXJ2ZWQxOigyNSwxOSksOTI4LDMy
O2ZvcmtlZTooMCwxKSw5NjAsMzI7aG1vZHVsZTooMCwyMyksOTkyLDMyO2FwaV9tYWpvcjoo
MjUsMTQpLDEwMjQsMzI7aW50ZXJuYWxfcmVzZXJ2ZWQ6KDEsMjIpPWFyKDAsMSk7MDs4Oygw
LDIzKSwxMDU2LDI4ODtfX2FzOjooMSwyMyk9IyMoMSwyNCk9JigxLDIpOzpSQzExcGVyX3By
b2Nlc3M7MkEuO3Blcl9wcm9jZXNzOjooMSwyNSk9IyMoMSwyNik9KigxLDIpOzpSQzExcGVy
X3Byb2Nlc3M7MkEuKDEsMjcpPSMjKDEsMjYpOzo7MkEuOzsAaGluZm86VHQoMSwyOCk9czEy
ZmRzOi8wKDEsMjkpPSooMzQsNSksMCwzMjtmaXJzdF9mZF9mb3Jfb3BlbjovMCgwLDEpLDMy
LDMyO3NpemU6KDMsMiksNjQsMzI7X19hczo6KDEsMzApPSMjKDEsMzEpPSYoMSwyOCk7OlJD
NWhpbmZvOzJBLjtoaW5mbzo6KDEsMzIpPSMjKDEsMzMpPSooMSwyOCk7OlJDNWhpbmZvOzJB
LjtjbGVhcm91dDo6KDEsMzQpPSMjKDAsMjApOzppOzJBLjtoaW5mbzo6KDEsMzUpPSMjKDEs
MzMpOzo7MkEuO2V4dGVuZDo6KDEsMzYpPSMjKDAsMSk7Omk7MkEuO2ZpeHVwX2FmdGVyX2Zv
cms6OigxLDM3KT0jIygwLDIwKTs6OzJBLjtidWlsZF9maGFuZGxlcjo6KDEsMzgpPSMjKDM0
LDUpOzppVWlQQ2NpOzJBLigxLDM5KT0jIygzNCw1KTs6aVBDY1B2OzJBLjtub3Rfb3Blbjo6
KDEsMzYpOmk7MkEuO2ZpbmRfdW51c2VkX2hhbmRsZTo6KDEsMzYpOmk7MkEuKDEsNDApPSMj
KDAsMSk7OjsyQS47cmVsZWFzZTo6KDEsMzQpOmk7MkEuO2luaXRfc3RkX2ZpbGVfZnJvbV9o
YW5kbGU6OigxLDQxKT0jIygwLDIwKTs6aVB2aWlQQ2M7MkEuO2R1cDI6OigxLDQyKT0jIygw
LDEpOzppaTsyQS47bGluZWFyaXplX2ZkX2FycmF5OjooMSw0Myk9IyMoMCwxKTs6UFVjaTsy
QS47ZGVfbGluZWFyaXplX2ZkX2FycmF5OjooMSw0NCk9IyMoMjUsNzMpOzpQVWM7MkEuO19f
dmM6OigxLDQ1KT0jIygzNCw1KTs6aTsyQS47c2VsZWN0X3JlYWQ6OigxLDQ2KT0jIygzNCw0
OCk7OmlQMTNzZWxlY3RfcmVjb3JkOzJBLjtzZWxlY3Rfd3JpdGU6OigxLDQ2KTppUDEzc2Vs
ZWN0X3JlY29yZDsyQS47c2VsZWN0X2V4Y2VwdDo6KDEsNDYpOmlQMTNzZWxlY3RfcmVjb3Jk
OzJBLjs7AGhvc3RfZGVwZW5kZW50X2NvbnN0YW50czpUdCgxLDQ3KT1zOHdpbjMyX3VwcGVy
OigyNSwxNCksMCwzMjtzaGFyZWQ6KDAsMSksMzIsMzI7X19hczo6KDEsNDgpPSMjKDEsNDkp
PSYoMSw0Nyk7OlJDMjRob3N0X2RlcGVuZGVudF9jb25zdGFudHM7MkEuO2hvc3RfZGVwZW5k
ZW50X2NvbnN0YW50czo6KDEsNTApPSMjKDEsNTEpPSooMSw0Nyk7OlJDMjRob3N0X2RlcGVu
ZGVudF9jb25zdGFudHM7MkEuKDEsNTIpPSMjKDEsNTEpOzo7MkEuO2luaXQ6OigxLDUzKT0j
IygwLDIwKTs6OzJBLjs7AHBpbmZvOlR0KDEsNTQpPXM5OTZoUHJvY2VzczooMjUsMTkpLDAs
MzI7cGFyZW50X2FsaXZlOigyNSwxOSksMzIsMzI7ZHdQcm9jZXNzSWQ6KDI1LDE0KSw2NCwz
Mjt1aWQ6KDIsMjUpLDk2LDE2O2dpZDooMiwyNiksMTEyLDE2O3BnaWQ6KDIsMjcpLDEyOCwz
MjtzaWQ6KDIsMjcpLDE2MCwzMjtjdHR5OigwLDEpLDE5MiwzMjt1bWFzazooMiwzMSksMjI0
LDMyO3N0b3BzaWc6KDAsMiksMjU2LDg7c2lnczooMSw1NSk9YXIoMCwxKTswOzMxOygxOSwy
KSwyODgsMzA3MjtzaWdfbWFzazooMTksMSksMzM2MCwzMjtfc2lndG9kbzooMSw1Nik9YXIo
MCwxKTswOzM0OygwLDMpLDMzOTIsMTEyMDtzdGFydF90aW1lOigwLDMpLDQ1MTIsMzI7cnVz
YWdlX3NlbGY6KDYsMSksNDU0NCw1NzY7cnVzYWdlX2NoaWxkcmVuOig2LDEpLDUxMjAsNTc2
O3Byb2duYW1lOigyOCwxMTYxKSw1Njk2LDIwODA7cGlkOigyLDI3KSw3Nzc2LDMyO3BwaWQ6
KDIsMjcpLDc4MDgsMzI7c3RyYWNlX21hc2s6KDI1LDE0KSw3ODQwLDMyO3N0cmFjZV9maWxl
OigyNSwxOSksNzg3MiwzMjtwcm9jZXNzX3N0YXRlOigyNSwxNCksNzkwNCwzMjttbWFwX3B0
cjooMCwyMyksNzkzNiwzMjtfX2FzOjooMSw1Nyk9IyMoMSw1OCk9JigxLDU0KTs6UkM1cGlu
Zm87MkEuO3BpbmZvOjooMSw1OSk9IyMoMSw2MCk9KigxLDU0KTs6UkM1cGluZm87MkEuKDEs
NjEpPSMjKDEsNjApOzo7MkEuO3JlY29yZF9kZWF0aDo6KDEsNjIpPSMjKDAsMjApOzo7MkEu
O3JlY29yZF9kZWF0aF9ub2xvY2s6OigxLDYyKTo7MkEuOzsAcGluZm9fbGlzdDpUdCgxLDYz
KT1zMTI3NzU2bmV4dF9waWQ6KDAsMSksMCwzMjt2ZWM6KDEsNjQpPWFyKDAsMSk7MDsxMjc7
KDEsNTQpLDMyLDEwMTk5MDQ7bG9ja19pbmZvOigxLDY1KT1hcigwLDEpOzA7MjYwOygwLDIp
LDEwMTk5MzYsMjA4ODtfX2FzOjooMSw2Nik9IyMoMSw2Nyk9JigxLDYzKTs6UkMxMHBpbmZv
X2xpc3Q7MkEuO3BpbmZvX2xpc3Q6OigxLDY4KT0jIygxLDY5KT0qKDEsNjMpOzpSQzEwcGlu
Zm9fbGlzdDsyQS4oMSw3MCk9IyMoMSw2OSk7OjsyQS47Z2V0X2VtcHR5X3BpbmZvOjooMSw3
MSk9IyMoMSw2MCk7OjswQS47X192Yzo6KDEsNzIpPSMjKDEsNjApOzppOzJBLjtzaXplOjoo
MSw3Myk9IyMoMCwxKTs6OzJBLjtsb29rdXBfYnlfaGFuZGxlOjooMSw3NCk9IyMoMSw2MCk7
OlBQdjsyQS47YWxsb2NhdGVfcGlkOjooMSw3MSk6OzJBLjtpbml0OjooMSw3NSk9IyMoMCwy
MCk7OjsyQS47OwBjaGlsZF9pbmZvOlR0KDEsNzYpPXMyNHplcm86KDI1LDE0KSwwLDMyO2Ni
OigyNSwxNCksMzIsMzI7dHlwZTooMjUsMTQpLDY0LDMyO2N5Z3BpZDooMCwxKSw5NiwzMjtz
dWJwcm9jX3JlYWR5OigyNSwxOSksMTI4LDMyO3NoYXJlZF9oOigyNSwxOSksMTYwLDMyO19f
YXM6OigxLDc3KT0jIygxLDc4KT0mKDEsNzYpOzpSQzEwY2hpbGRfaW5mbzsyQS47Y2hpbGRf
aW5mbzo6KDEsNzkpPSMjKDEsODApPSooMSw3Nik7OlJDMTBjaGlsZF9pbmZvOzJBLigxLDgx
KT0jIygxLDgwKTs6OzJBLjs7AGNoaWxkX2luZm9fZm9yazpUdCgxLDgyKT1zMjU2ITEsMDIw
LCgxLDc2KTtmb3JrZXJfZmluaXNoZWQ6KDI1LDE5KSwxOTIsMzI7c3RhY2tzaXplOigyNSwx
NCksMjI0LDMyO2hlYXBzaXplOigzLDIpLDI1NiwzMjtoZWFwYmFzZTooMCwyMyksMjg4LDMy
O2hlYXBwdHI6KDAsMjMpLDMyMCwzMjtqbXA6KDE3LDEpLDM1MiwxNjY0O3N0YWNrbG9jOigw
LDIzKSwyMDE2LDMyO19fYXM6OigxLDgzKT0jIygxLDg0KT0mKDEsODIpOzpSQzE1Y2hpbGRf
aW5mb19mb3JrOzJBLjtjaGlsZF9pbmZvX2Zvcms6OigxLDg1KT0jIygxLDg2KT0qKDEsODIp
OzpSQzE1Y2hpbGRfaW5mb19mb3JrOzJBLigxLDg3KT0jIygxLDg2KTs6OzJBLjs7AHNoYXJl
ZF9pbmZvOlR0KDEsODgpPXMxODY3Mjhpbml0ZWQ6LzAoMCwxKSwwLDMyO3A6KDEsNjMpLDMy
LDEwMjIwNDg7bW91bnQ6KDM2LDI4KSwxMDIyMDgwLDEyNzcxMjtoZWFwX2NodW5rX2luX21i
OigwLDEpLDExNDk3OTIsMzI7dHR5OigzNywyNCksMTE0OTgyNCwxMzUxNjg7ZGVscXVldWU6
KDM5LDEpLDEyODQ5OTIsMjA4ODMyO19fYXM6OigxLDg5KT0jIygxLDkwKT0mKDEsODgpOzpS
QzExc2hhcmVkX2luZm87MkEuO3NoYXJlZF9pbmZvOjooMSw5MSk9IyMoMSw5Mik9KigxLDg4
KTs6UkMxMXNoYXJlZF9pbmZvOzJBLigxLDkzKT0jIygxLDkyKTs6OzJBLjtoZWFwX2NodW5r
X3NpemU6OigxLDk0KT0jIygwLDEpOzo7MkEuO2luaXRpYWxpemU6OigxLDk1KT0jIygwLDIw
KTs6OzJBLjs7AGN5Z3dpbl92ZXJzaW9uX2luZm86VHQoMSw5Nik9czEwMGFwaV9tYWpvcjoo
MjUsMTQpLDAsMzI7YXBpX21pbm9yOigyNSwxNCksMzIsMzI7ZGxsX21ham9yOigyNSwxNCks
NjQsMzI7ZGxsX21pbm9yOigyNSwxNCksOTYsMzI7c2hhcmVkX2RhdGE6KDI1LDE0KSwxMjgs
MzI7bW91bnRfcmVnaXN0cnk6KDI1LDE0KSwxNjAsMzI7ZGxsX2J1aWxkX2RhdGU6KDI1LDgy
KSwxOTIsMzI7c2hhcmVkX2lkOigxLDk3KT1hcigwLDEpOzA7NzA7KDAsMiksMjI0LDU2ODtf
X2FzOjooMSw5OCk9IyMoMSw5OSk9JigxLDk2KTs6UkMxOWN5Z3dpbl92ZXJzaW9uX2luZm87
MkEuO2N5Z3dpbl92ZXJzaW9uX2luZm86OigxLDEwMCk9IyMoMSwxMDEpPSooMSw5Nik7OlJD
MTljeWd3aW5fdmVyc2lvbl9pbmZvOzJBLjs7AHBlcl90aHJlYWQ6VHQoMSwxMDIpPXMxMnRs
czovMCgyNSwxNCksMCwzMjtjbGVhcl9vbl9mb3JrX3A6LzAoMCwxKSwzMiwzMjskdmYoMSwx
MDIpOigxLDEwMyk9KigxLDEwNCk9YXIoMCwxKTswOzQ7KDAsMjIpLDY0O19fYXM6OigxLDEw
NSk9IyMoMSwxMDYpPSYoMSwxMDIpOzpSQzEwcGVyX3RocmVhZDsyQS47cGVyX3RocmVhZDo6
KDEsMTA3KT0jIygxLDEwOCk9KigxLDEwMik7OlJDMTBwZXJfdGhyZWFkOzJBLigxLDEwOSk9
IyMoMSwxMDgpOzppOzJBLjtnZXRfdGxzOjooMSwxMTApPSMjKDI1LDE0KTs6OzJBLjtjbGVh
cl9vbl9mb3JrOjooMSwxMTEpPSMjKDAsMSk7OjsyQS47Z2V0OjooMSwxMTIpPSMjKDAsMjMp
Ozo7MkEqMTsoMSwxMDIpOztzaXplOjooMSwxMTMpPSMjKDMsMik7OjsyQSoyOygxLDEwMik7
O3NldDo6KDEsMTE0KT0jIygwLDIwKTs6UHY7MkEqMzsoMSwxMDIpOztjcmVhdGU6OigxLDEx
Mik6OzJBKjQ7KDEsMTAyKTs7O34lKDEsMTAyKTsAcGVyX3RocmVhZF93YWl0cTpUdCgxLDEx
NSk9czEyITEsMDIwLCgxLDEwMik7X19hczo6KDEsMTE2KT0jIygxLDExNyk9JigxLDExNSk7
OlJDMTZwZXJfdGhyZWFkX3dhaXRxOzJBLjtwZXJfdGhyZWFkX3dhaXRxOjooMSwxMTgpPSMj
KDEsMTE5KT0qKDEsMTE1KTs6UkMxNnBlcl90aHJlYWRfd2FpdHE7MkEuKDEsMTIwKT0jIygx
LDExOSk7OjsyQS47Z2V0OjooMSwxMjEpPSMjKDEsMTIyKT0qKDQyLDgpOzo7MkEqMTsoMSwx
MDIpOztjcmVhdGU6OigxLDEyMSk6OzJBKjQ7KDEsMTAyKTs7c2l6ZTo6KDEsMTIzKT0jIygz
LDIpOzo7MkEqMjsoMSwxMDIpOzs7fiUoMSwxMDIpOwBwZXJfdGhyZWFkX3N0cmFjZV9wcm90
ZWN0OlR0KDEsMTI0KT1zMTIhMSwwMjAsKDEsMTAyKTtfX2FzOjooMSwxMjUpPSMjKDEsMTI2
KT0mKDEsMTI0KTs6UkMyNXBlcl90aHJlYWRfc3RyYWNlX3Byb3RlY3Q7MkEuO3Blcl90aHJl
YWRfc3RyYWNlX3Byb3RlY3Q6OigxLDEyNyk9IyMoMSwxMjgpPSooMSwxMjQpOzpSQzI1cGVy
X3RocmVhZF9zdHJhY2VfcHJvdGVjdDsyQS4oMSwxMjkpPSMjKDEsMTI4KTs6OzJBLjt2YWw6
OigxLDEzMCk9IyMoMCwxKTs6OzJBLjtzZXQ6OigxLDEzMSk9IyMoMCwyMCk7Omk7MkEuO2Ny
ZWF0ZTo6KDEsMTMyKT0jIygwLDIzKTs6OzJBKjQ7KDEsMTAyKTs7c2l6ZTo6KDEsMTMzKT0j
IygzLDIpOzo7MkEqMjsoMSwxMDIpOzs7fiUoMSwxMDIpOwAvaG9tZS9ub2VyL3NyYy9iMjAv
Y29tcC10b29scy9kZXZvL25ld2xpYi9saWJjL2luY2x1ZGUvc3lzL3JlZW50LmgAX2dsdWU6
VHQoNDMsMSk9czEyX25leHQ6KDQzLDIpPSooNDMsMSksMCwzMjtfbmlvYnM6KDAsMSksMzIs
MzI7X2lvYnM6KDQzLDMpPSooNDMsNCk9eHNfX3NGSUxFOiw2NCwzMjtfX2FzOjooNDMsNSk9
IyMoNDMsNik9Jig0MywxKTs6UkM1X2dsdWU7MkEuO19nbHVlOjooNDMsNyk9IyMoNDMsMik7
OlJDNV9nbHVlOzJBLig0Myw4KT0jIyg0MywyKTs6OzJBLjs7AF9CaWdpbnQ6VHQoNDMsOSk9
czI0X25leHQ6KDQzLDEwKT0qKDQzLDkpLDAsMzI7X2s6KDAsMSksMzIsMzI7X21heHdkczoo
MCwxKSw2NCwzMjtfc2lnbjooMCwxKSw5NiwzMjtfd2RzOigwLDEpLDEyOCwzMjtfeDooNDMs
MTEpPWFyKDAsMSk7MDswOygwLDUpLDE2MCwzMjtfX2FzOjooNDMsMTIpPSMjKDQzLDEzKT0m
KDQzLDkpOzpSQzdfQmlnaW50OzJBLjtfQmlnaW50OjooNDMsMTQpPSMjKDQzLDEwKTs6UkM3
X0JpZ2ludDsyQS4oNDMsMTUpPSMjKDQzLDEwKTs6OzJBLjs7AF9hdGV4aXQ6VHQoNDMsMTYp
PXMxMzZfbmV4dDooNDMsMTcpPSooNDMsMTYpLDAsMzI7X2luZDooMCwxKSwzMiwzMjtfZm5z
Oig0MywxOCk9YXIoMCwxKTswOzMxOygxLDE3KSw2NCwxMDI0O19fYXM6Oig0MywxOSk9IyMo
NDMsMjApPSYoNDMsMTYpOzpSQzdfYXRleGl0OzJBLjtfYXRleGl0OjooNDMsMjEpPSMjKDQz
LDE3KTs6UkM3X2F0ZXhpdDsyQS4oNDMsMjIpPSMjKDQzLDE3KTs6OzJBLjs7AF9fc2J1ZjpU
dCg0MywyMyk9czhfYmFzZTooMjUsMTI2KSwwLDMyO19zaXplOigwLDEpLDMyLDMyO19fYXM6
Oig0MywyNCk9IyMoNDMsMjUpPSYoNDMsMjMpOzpSQzZfX3NidWY7MkEuO19fc2J1Zjo6KDQz
LDI2KT0jIyg0MywyNyk9Kig0MywyMyk7OlJDNl9fc2J1ZjsyQS4oNDMsMjgpPSMjKDQzLDI3
KTs6OzJBLjs7AF9mcG9zX3Q6dCg0MywyOSk9KDAsMykAX19zRklMRTpUdCg0Myw0KT1zODhf
cDooMjUsMTI2KSwwLDMyO19yOigwLDEpLDMyLDMyO193OigwLDEpLDY0LDMyO19mbGFnczoo
MCw4KSw5NiwxNjtfZmlsZTooMCw4KSwxMTIsMTY7X2JmOig0MywyMyksMTI4LDY0O19sYmZz
aXplOigwLDEpLDE5MiwzMjtfY29va2llOigwLDIzKSwyMjQsMzI7X3JlYWQ6KDQzLDMwKT0q
KDQzLDMxKT1mKDAsMSksMjU2LDMyO193cml0ZTooNDMsMzIpPSooNDMsMzMpPWYoMCwxKSwy
ODgsMzI7X3NlZWs6KDQzLDM0KT0qKDQzLDM1KT1mKDQzLDI5KSwzMjAsMzI7X2Nsb3NlOig0
MywzNik9Kig0MywzNyk9ZigwLDEpLDM1MiwzMjtfdWI6KDQzLDIzKSwzODQsNjQ7X3VwOigy
NSwxMjYpLDQ0OCwzMjtfdXI6KDAsMSksNDgwLDMyO191YnVmOig0MywzOCk9YXIoMCwxKTsw
OzI7KDAsMTEpLDUxMiwyNDtfbmJ1ZjooMjgsMjUwKSw1MzYsODtfbGI6KDQzLDIzKSw1NDQs
NjQ7X2Jsa3NpemU6KDAsMSksNjA4LDMyO19vZmZzZXQ6KDAsMSksNjQwLDMyO19kYXRhOigx
LDQpLDY3MiwzMjtfX2FzOjooNDMsMzkpPSMjKDQzLDQwKT0mKDQzLDQpOzpSQzdfX3NGSUxF
OzJBLjtfX3NGSUxFOjooNDMsNDEpPSMjKDQzLDMpOzpSQzdfX3NGSUxFOzJBLig0Myw0Mik9
IyMoNDMsMyk7OjsyQS47OwBfcmVlbnQ6VHQoMSw1KT1zNzQ4X2Vycm5vOigwLDEpLDAsMzI7
X3N0ZGluOig0MywzKSwzMiwzMjtfc3Rkb3V0Oig0MywzKSw2NCwzMjtfc3RkZXJyOig0Mywz
KSw5NiwzMjtfaW5jOigwLDEpLDEyOCwzMjtfZW1lcmdlbmN5Oig0Myw0Myk9YXIoMCwxKTsw
OzI0OygwLDIpLDE2MCwyMDA7X2N1cnJlbnRfY2F0ZWdvcnk6KDAsMSksMzg0LDMyO19jdXJy
ZW50X2xvY2FsZTooMjUsODIpLDQxNiwzMjtfX3NkaWRpbml0OigwLDEpLDQ0OCwzMjtfX2Ns
ZWFudXA6KDQzLDQ0KT0qKDQzLDQ1KT1mKDAsMjApLDQ4MCwzMjtfcmVzdWx0Oig0MywxMCks
NTEyLDMyO19yZXN1bHRfazooMCwxKSw1NDQsMzI7X3A1czooNDMsMTApLDU3NiwzMjtfZnJl
ZWxpc3Q6KDQzLDQ2KT0qKDQzLDEwKSw2MDgsMzI7X2N2dGxlbjooMCwxKSw2NDAsMzI7X2N2
dGJ1ZjooMiwxMCksNjcyLDMyO19uZXh0ZjooNDMsNDcpPWFyKDAsMSk7MDsyOTsoMjUsMTI2
KSw3MDQsOTYwO19ubWFsbG9jOig0Myw0OCk9YXIoMCwxKTswOzI5OygwLDQpLDE2NjQsOTYw
O19hdGV4aXQ6KDQzLDE3KSwyNjI0LDMyO19hdGV4aXQwOig0MywxNiksMjY1NiwxMDg4O19z
aWdfZnVuYzooMSwxNiksMzc0NCwzMjtfX3NnbHVlOig0MywxKSwzNzc2LDk2O19fc2Y6KDQz
LDQ5KT1hcigwLDEpOzA7MjsoNDMsNCksMzg3MiwyMTEyO19fYXM6Oig0Myw1MCk9IyMoNDMs
NTEpPSYoMSw1KTs6UkM2X3JlZW50OzJBLjtfcmVlbnQ6Oig0Myw1Mik9IyMoMSw0KTs6UkM2
X3JlZW50OzJBLig0Myw1Myk9IyMoMSw0KTs6OzJBLjs7AHdpbl9lbnY6VHQoMSwxMzQpPXMz
Mm5hbWU6KDI1LDgyKSwwLDMyO25hbWVsZW46KDMsMiksMzIsMzI7cG9zaXg6KDIsMTApLDY0
LDMyO25hdGl2ZTooMiwxMCksOTYsMzI7dG9wb3NpeDooMSwxMzUpPSooMSwxMzYpPWYoMCwy
MCksMTI4LDMyO3Rvd2luMzI6KDEsMTM1KSwxNjAsMzI7cG9zaXhfbGVuOigxLDEzNyk9Kigx
LDEzOCk9ZigwLDEpLDE5MiwzMjt3aW4zMl9sZW46KDEsMTM3KSwyMjQsMzI7X19hczo6KDEs
MTM5KT0jIygxLDE0MCk9JigxLDEzNCk7OlJDN3dpbl9lbnY7MkEuO3dpbl9lbnY6OigxLDE0
MSk9IyMoMSwxNDIpPSooMSwxMzQpOzpSQzd3aW5fZW52OzJBLigxLDE0Myk9IyMoMSwxNDIp
Ozo7MkEuO2FkZF9jYWNoZTo6KDEsMTQ0KT0jIygwLDIwKTs6UENjVDE7MkEuO2dldF9uYXRp
dmU6OigxLDE0NSk9IyMoMjUsODIpOzo7MkEuOzsAc2F2ZV9lcnJubzpUdCgxLDE0Nik9czRz
YXZlZDovMCgwLDEpLDAsMzI7X19hczo6KDEsMTQ3KT0jIygxLDE0OCk9JigxLDE0Nik7OlJD
MTBzYXZlX2Vycm5vOzJBLjtzYXZlX2Vycm5vOjooMSwxNDkpPSMjKDEsMTUwKT0qKDEsMTQ2
KTs6UkMxMHNhdmVfZXJybm87MkEuKDEsMTUxKT0jIygxLDE1MCk7OjsyQS4oMSwxNTIpPSMj
KDEsMTUwKTs6aTsyQS47c2V0OjooMSwxNTMpPSMjKDAsMjApOzppOzJBLjtyZXNldDo6KDEs
MTU0KT0jIygwLDIwKTs6OzJBLjtzYXZlX2Vycm5vOjooMSwxNTMpOl8kXzEwc2F2ZV9lcnJu
bzsyQS47OwBfX3NpZ19wcm90ZWN0OlR0KDEsMTU1KT1zNHN5bmM6LzAoMCwxKSwwLDMyO19f
YXM6OigxLDE1Nik9IyMoMSwxNTcpPSYoMSwxNTUpOzpSQzEzX19zaWdfcHJvdGVjdDsyQS47
X19zaWdfcHJvdGVjdDo6KDEsMTU4KT0jIygxLDE1OSk9KigxLDE1NSk7OlJDMTNfX3NpZ19w
cm90ZWN0OzJBLigxLDE2MCk9IyMoMSwxNTkpOzppUENjaTsyQS4oMSwxNjEpPSMoMSwxNTUp
LCgwLDIwKSwoMSwxNTkpLCgwLDEpLCgwLDIwKTs6XyRfMTNfX3NpZ19wcm90ZWN0OzJBLjs7
AC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vbmV3bGliL2xpYmMvaW5jbHVk
ZS9yZWVudC5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vbmV3bGliL2xp
YmMvaW5jbHVkZS9zeXMvX3R5cGVzLmgAX29mZl90OnQoNDUsMSk9KDAsMykAX3NzaXplX3Q6
dCg0NSwyKT0oMCwzKQAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL25ld2xp
Yi9saWJjL2luY2x1ZGUvc3RkbGliLmgAZGl2X3Q6dCg0NywxKT1zOHF1b3Q6KDAsMSksMCwz
MjtyZW06KDAsMSksMzIsMzI7X19hczo6KDQ3LDIpPSMoNDcsMSksKDQ3LDMpPSYoNDcsMSks
KDQ3LDQpPSooNDcsMSksKDQ3LDUpPSYoNDcsNik9czhxdW90OigwLDEpLDAsMzI7cmVtOigw
LDEpLDMyLDMyO19fYXM6Oig0NywyKTpfX2FzX180JF81NlJDNCRfNTY7MkEuOyRfNTY6Oig0
Nyw3KT0jKDQ3LDEpLCg0Nyw0KSwoNDcsNCksKDQ3LDUpLCgwLDIwKTs6X180JF81NlJDNCRf
NTY7MkEuKDQ3LDgpPSMoNDcsMSksKDQ3LDQpLCg0Nyw0KSwoMCwyMCk7Ol9fNCRfNTY7MkEu
OzssKDAsMjApOzpfX2FzX180JF81NlJDNCRfNTY7MkEuOyRfNTY6Oig0Nyw3KTpfXzQkXzU2
UkM0JF81NjsyQS4oNDcsOCk6X180JF81NjsyQS47OwBsZGl2X3Q6dCg0Nyw5KT1zOHF1b3Q6
KDAsMyksMCwzMjtyZW06KDAsMyksMzIsMzI7X19hczo6KDQ3LDEwKT0jKDQ3LDkpLCg0Nywx
MSk9Jig0Nyw5KSwoNDcsMTIpPSooNDcsOSksKDQ3LDEzKT0mKDQ3LDE0KT1zOHF1b3Q6KDAs
MyksMCwzMjtyZW06KDAsMyksMzIsMzI7X19hczo6KDQ3LDEwKTpfX2FzX180JF81N1JDNCRf
NTc7MkEuOyRfNTc6Oig0NywxNSk9Iyg0Nyw5KSwoNDcsMTIpLCg0NywxMiksKDQ3LDEzKSwo
MCwyMCk7Ol9fNCRfNTdSQzQkXzU3OzJBLig0NywxNik9Iyg0Nyw5KSwoNDcsMTIpLCg0Nywx
MiksKDAsMjApOzpfXzQkXzU3OzJBLjs7LCgwLDIwKTs6X19hc19fNCRfNTdSQzQkXzU3OzJB
LjskXzU3OjooNDcsMTUpOl9fNCRfNTdSQzQkXzU3OzJBLig0NywxNik6X180JF81NzsyQS47
OwBNYWluRnVuYzp0KDAsMjQpPSgxLDE0KQBjeWd3aW5fY3J0MF9jb21tb25fX0ZQRmlQUGNQ
UGNfaTpmKDAsMjApAGY6cCgwLDI0KQBmOnIoMCwyNCkAb25zdGFjazooMCwxKQBjeWd3aW5f
Y3J0MDpGKDAsMjApAGN5Z3dpbl9hdHRhY2hfZGxsOkYoMCwxKQBoOnAoMjUsNTEpAGg6cigy
NSw1MSkAY3lnd2luX2F0dGFjaF9ub25jeWd3aW5fZGxsOkYoMCwxKQBfaW1wdXJlX3B0cjpH
KDEsNCkAZW52aXJvbjpHKDEsNykAX2Ztb2RlOkcoMCwxKQB0aGlzX3Byb2M6UygxLDIpAC9j
eWdudXMvYnVpbGQvaTU4Ni1jeWd3aW4zMi14LWk1ODYtY3lnd2luMzIvZ2NjLwAvaG9tZS9u
b2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZvL2djYy9saWJnY2MyLmMAdGNvbmZpZy5oAC9o
b21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vZ2NjL2NvbmZpZy9pMzg2L3htLWkz
ODYuaAB0bS5oAC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vZ2NjL2NvbmZp
Zy9pMzg2L2N5Z3dpbjMyLmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2by9n
Y2MvY29uZmlnL2kzODYvZ2FzLmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9vbHMvZGV2
by9nY2MvY29uZmlnL2kzODYvaTM4Ni5oAHByb2Nlc3Nvcl9jb3N0czpUKDYsMSk9czI4YWRk
OigwLDEpLDAsMzI7bGVhOigwLDEpLDMyLDMyO3NoaWZ0X3ZhcjooMCwxKSw2NCwzMjtzaGlm
dF9jb25zdDooMCwxKSw5NiwzMjttdWx0X2luaXQ6KDAsMSksMTI4LDMyO211bHRfYml0Oigw
LDEpLDE2MCwzMjtkaXZpZGU6KDAsMSksMTkyLDMyOzsAcHJvY2Vzc29yX3R5cGU6VCg2LDIp
PWVQUk9DRVNTT1JfSTM4NjowLFBST0NFU1NPUl9JNDg2OjEsUFJPQ0VTU09SX1BFTlRJVU06
MixQUk9DRVNTT1JfUEVOVElVTVBSTzozLFBST0NFU1NPUl9LNjo0LDsAcmVnX2NsYXNzOlQo
NiwzKT1lTk9fUkVHUzowLEFSRUc6MSxEUkVHOjIsQ1JFRzozLEJSRUc6NCxBRF9SRUdTOjUs
UV9SRUdTOjYsU0lSRUc6NyxESVJFRzo4LElOREVYX1JFR1M6OSxHRU5FUkFMX1JFR1M6MTAs
RlBfVE9QX1JFRzoxMSxGUF9TRUNPTkRfUkVHOjEyLEZMT0FUX1JFR1M6MTMsQUxMX1JFR1M6
MTQsTElNX1JFR19DTEFTU0VTOjE1LDsAaTM4Nl9hcmdzOlQoNiw0KT1zMTJ3b3JkczooMCwx
KSwwLDMyO25yZWdzOigwLDEpLDMyLDMyO3JlZ25vOigwLDEpLDY0LDMyOzsAQ1VNVUxBVElW
RV9BUkdTOnQoNiw1KT0oNiw0KQAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9kZXZv
L2djYy9jb25maWcvaTM4Ni9ic2QuaAAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10b29scy9k
ZXZvL2djYy9jb25maWcvaTM4Ni91bml4LmgAL2hvbWUvbm9lci9zcmMvYjIwL2NvbXAtdG9v
bHMvZGV2by9nY2MvY29uZmlnL2RieGNvZmYuaAAvaG9tZS9ub2VyL3NyYy9iMjAvY29tcC10
b29scy9kZXZvL2djYy9jb25maWcvaTM4Ni94bS1jeWd3aW4zMi5oAC9ob21lL25vZXIvc3Jj
L2IyMC9jb21wLXRvb2xzL2Rldm8vZ2NjL21hY2htb2RlLmgAL2hvbWUvbm9lci9zcmMvYjIw
L2NvbXAtdG9vbHMvZGV2by9nY2MvZ2Fuc2lkZWNsLmgAL2hvbWUvbm9lci9zcmMvYjIwL2Nv
bXAtdG9vbHMvZGV2by9nY2MvbWFjaG1vZGUuZGVmAG1hY2hpbmVfbW9kZTpUKDExLDEpPWVW
T0lEbW9kZTowLFBRSW1vZGU6MSxRSW1vZGU6MixQSEltb2RlOjMsSEltb2RlOjQsUFNJbW9k
ZTo1LFNJbW9kZTo2LFBESW1vZGU6NyxESW1vZGU6OCxUSW1vZGU6OSxPSW1vZGU6MTAsUUZt
b2RlOjExLEhGbW9kZToxMixUUUZtb2RlOjEzLFNGbW9kZToxNCxERm1vZGU6MTUsWEZtb2Rl
OjE2LFRGbW9kZToxNyxRQ21vZGU6MTgsSENtb2RlOjE5LFNDbW9kZToyMCxEQ21vZGU6MjEs
WENtb2RlOjIyLFRDbW9kZToyMyxDUUltb2RlOjI0LENISW1vZGU6MjUsQ1NJbW9kZToyNixD
REltb2RlOjI3LENUSW1vZGU6MjgsQ09JbW9kZToyOSxCTEttb2RlOjMwLENDbW9kZTozMSxD
Q0ZQRVFtb2RlOjMyLE1BWF9NQUNISU5FX01PREU6MzMsOwBtb2RlX2NsYXNzOlQoMTEsMik9
ZU1PREVfUkFORE9NOjAsTU9ERV9JTlQ6MSxNT0RFX0ZMT0FUOjIsTU9ERV9QQVJUSUFMX0lO
VDozLE1PREVfQ0M6NCxNT0RFX0NPTVBMRVhfSU5UOjUsTU9ERV9DT01QTEVYX0ZMT0FUOjYs
TUFYX01PREVfQ0xBU1M6Nyw7AC9ob21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8v
Z2NjL2RlZmF1bHRzLmgAaW5jbHVkZS9zdGRkZWYuaABwdHJkaWZmX3Q6dCgxNSwxKT0oMCwx
KQBzaXplX3Q6dCgxNSwyKT0oMCw0KQB3Y2hhcl90OnQoMTUsMyk9KDAsOSkAd2ludF90OnQo
MTUsNCk9KDAsNCkAVVFJdHlwZTp0KDAsMjApPSgwLDExKQBTSXR5cGU6dCgwLDIxKT0oMCwx
KQBVU0l0eXBlOnQoMCwyMik9KDAsNCkAREl0eXBlOnQoMCwyMyk9KDAsNikAVURJdHlwZTp0
KDAsMjQpPSgwLDcpAFNGdHlwZTp0KDAsMjUpPSgwLDEyKQBERnR5cGU6dCgwLDI2KT0oMCwx
MykAWEZ0eXBlOnQoMCwyNyk9KDAsMTQpAHdvcmRfdHlwZTp0KDAsMjgpPSgwLDEpAERJc3Ry
dWN0OlQoMCwyOSk9czhsb3c6KDAsMjEpLDAsMzI7aGlnaDooMCwyMSksMzIsMzI7OwBESXVu
aW9uOnQoMCwzMCk9KDAsMzEpPXU4czooMCwyOSksMCw2NDtsbDooMCwyMyksMCw2NDs7AC9o
b21lL25vZXIvc3JjL2IyMC9jb21wLXRvb2xzL2Rldm8vZ2NjL2dibC1jdG9ycy5oAGZ1bmNf
cHRyOnQoMTYsMSk9KDE2LDIpPSooMTYsMyk9ZigwLDE5KQBfX0NUT1JfTElTVF9fOkcoMCwz
Mik9YXIoMCwxKTswOzE7KDE2LDEpAF9fRFRPUl9MSVNUX186RygwLDMyKQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5maWxlAAAAEAAAAP7/
AABnAWNydDAuYwAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAEAAAAGAAAAAAATAAAAAAAAAAEA
AAAGAAAAAAAlAAAAAAAAAAEAIAACAQAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAAAAAAEA
AAADAUAAAAADAAAAAAAAAAAAAAAAAC5kYXRhAAAAAAAAAAIAAAADAQQAAAAAAAAAAAAAAAAA
AAAAAC5ic3MAAAAAAAAAAAMAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5zdGFiAAAAAAAAAAUA
AAADAewBAAAEAAAAAAAAAAAAAAAAAC5zdGFic3RyAAAAAAAAAAADASQEAAAAAAAAAAAAAAAA
AAAAAC5maWxlAAAAIAAAAP7/AABnAWlwYy1kYWVtb24uYwAAAAAAAAAAAAAEAAAAQAAAAAEA
AAAGAAAAAAATAAAAQAAAAAEAAAAGAAAAAAA1AAAAQAAAAAEAIAADAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA/AAAA0AAAAAEAIAADAAAAAABJAAAAbAEAAAEAIAADAF9tYWluAAAAgAMAAAEA
IAACAAAAAABTAAAAHAwAAAEAIAACAC50ZXh0AAAAQAAAAAEAAAADAQAMAAB4AAAAAAAAAAAA
AAAAAC5kYXRhAAAABAAAAAIAAAADAQQAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAAAAAAAMA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5maWxlAAAALAAAAP7/AABnAWl0b2EuYwAAAAAAAAAA
AAAAAAAAAAAEAAAAQAwAAAEAAAAGAAAAAAATAAAAQAwAAAEAAAAGAF9pdG9hAAAAQAwAAAEA
IAACAQAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAQAwAAAEAAAADAXAAAAABAAAAAAAAAAAA
AAAAAC5kYXRhAAAACAAAAAIAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAAAAAAAMA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5maWxlAAAAOAAAAP7/AABnAXJldmVyc2UuYwAAAAAA
AAAAAAAAAAAEAAAAsAwAAAEAAAAGAAAAAAATAAAAsAwAAAEAAAAGAF9yZXZlcnNlsAwAAAEA
IAACAQAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAsAwAAAEAAAADAXAAAAAAAAAAAAAAAAAA
AAAAAC5kYXRhAAAACAAAAAIAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAAAAAAAMA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5maWxlAAAAwwAAAP7/AABnAWxpYmNjcnQwLmNjAAAA
AAAAAAAAAAAEAAAAIA0AAAEAAAAGAAAAAABmAAAAIA0AAAEAAAAGAAAAAACAAAAAVA0AAAEA
IAADAQAAAAAAAAAAAAAAAAAAAAAAAAAAAACiAAAAAAAAAAMAAAADAAAAAACtAAAAKA4AAAEA
IAACAAAAAAC6AAAARA4AAAEAIAACAAAAAADNAAAAaA4AAAEAIAACAC50ZXh0AAAAIA0AAAEA
AAADAYABAAAoAAAAAAAAAAAAAAAAAC5kYXRhAAAACAAAAAIAAAADAQwAAAAAAAAAAAAAAAAA
AAAAAC5ic3MAAAAAAAAAAAMAAAADAbAAAAAAAAAAAAAAAAAAAAAAAC5zdGFiAAAA7AEAAAUA
AAADAVhZAAAIAAAAAAAAAAAAAAAAAC5zdGFic3RyAAAAAAAAAAADARIHBAAAAAAAAAAAAAAA
AAAAAC50ZXh0AAAAoA4AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3uAIAAAQAAAADAC5pZGF0YSQ17AAAAAQAAAADAC5pZGF0YSQ0dAAAAAQA
AAADAC5pZGF0YSQ2sAEAAAQAAAADAC50ZXh0AAAAqA4AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3rAIAAAQAAAADAC5pZGF0YSQ14AAAAAQA
AAADAC5pZGF0YSQ0aAAAAAQAAAADAC5pZGF0YSQ2mAEAAAQAAAADAC50ZXh0AAAAsA4AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3xAIAAAQA
AAADAC5pZGF0YSQ1+AAAAAQAAAADAC5pZGF0YSQ0gAAAAAQAAAADAC5pZGF0YSQ20AEAAAQA
AAADAC50ZXh0AAAAuA4AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3tAIAAAQAAAADAC5pZGF0YSQ16AAAAAQAAAADAC5pZGF0YSQ0cAAAAAQA
AAADAC5pZGF0YSQ2qAEAAAQAAAADAC50ZXh0AAAAwA4AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ31AIAAAQAAAADAC5pZGF0YSQ1CAEAAAQA
AAADAC5pZGF0YSQ0kAAAAAQAAAADAC5pZGF0YSQ2/AEAAAQAAAADAC50ZXh0AAAAyA4AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3wAIAAAQA
AAADAC5pZGF0YSQ19AAAAAQAAAADAC5pZGF0YSQ0fAAAAAQAAAADAC5pZGF0YSQ2yAEAAAQA
AAADAC50ZXh0AAAA0A4AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3nAIAAAQAAAADAC5pZGF0YSQ10AAAAAQAAAADAC5pZGF0YSQ0WAAAAAQA
AAADAC5pZGF0YSQ2TAEAAAQAAAADAC50ZXh0AAAA2A4AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3sAIAAAQAAAADAC5pZGF0YSQ15AAAAAQA
AAADAC5pZGF0YSQ0bAAAAAQAAAADAC5pZGF0YSQ2oAEAAAQAAAADAC50ZXh0AAAA4A4AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ32AIAAAQA
AAADAC5pZGF0YSQ1DAEAAAQAAAADAC5pZGF0YSQ0lAAAAAQAAAADAC5pZGF0YSQ2CAIAAAQA
AAADAC50ZXh0AAAA6A4AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3vAIAAAQAAAADAC5pZGF0YSQ18AAAAAQAAAADAC5pZGF0YSQ0eAAAAAQA
AAADAC5pZGF0YSQ2vAEAAAQAAAADAC50ZXh0AAAA8A4AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3yAIAAAQAAAADAC5pZGF0YSQ1/AAAAAQA
AAADAC5pZGF0YSQ0hAAAAAQAAAADAC5pZGF0YSQ23AEAAAQAAAADAC50ZXh0AAAA+A4AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ30AIAAAQA
AAADAC5pZGF0YSQ1BAEAAAQAAAADAC5pZGF0YSQ0jAAAAAQAAAADAC5pZGF0YSQ28AEAAAQA
AAADAC50ZXh0AAAAAA8AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3qAIAAAQAAAADAC5pZGF0YSQ13AAAAAQAAAADAC5pZGF0YSQ0ZAAAAAQA
AAADAC5pZGF0YSQ2gAEAAAQAAAADAC50ZXh0AAAACA8AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3pAIAAAQAAAADAC5pZGF0YSQ12AAAAAQA
AAADAC5pZGF0YSQ0YAAAAAQAAAADAC5pZGF0YSQ2cAEAAAQAAAADAC50ZXh0AAAAEA8AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3oAIAAAQA
AAADAC5pZGF0YSQ11AAAAAQAAAADAC5pZGF0YSQ0XAAAAAQAAAADAC5pZGF0YSQ2VAEAAAQA
AAADAC50ZXh0AAAAGA8AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3mAIAAAQAAAADAC5pZGF0YSQ1zAAAAAQAAAADAC5pZGF0YSQ0VAAAAAQA
AAADAC5pZGF0YSQ2QAEAAAQAAAADAC50ZXh0AAAAIA8AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3zAIAAAQAAAADAC5pZGF0YSQ1AAEAAAQA
AAADAC5pZGF0YSQ0iAAAAAQAAAADAC5pZGF0YSQ25AEAAAQAAAADAC5maWxlAAAA0wAAAP7/
AABnAWZha2UAAAAAAAAAAAAAAAAAAGhuYW1lAAAAVAAAAAQAAAADAGZ0aHVuawAAzAAAAAQA
AAADAC50ZXh0AAAAKA8AAAEAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5kYXRhAAAAFAAAAAIA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAsAAAAAMAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5pZGF0YSQyAAAAAAQAAAADARQAAAADAAAAAAAAAAAAAAAAAC5pZGF0YSQ1yAAAAAQA
AAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ0UAAAAAQAAAADAQQAAAAAAAAAAAAAAAAA
AAAAAC5maWxlAAAA6AAAAP7/AABnAWZha2UAAAAAAAAAAAAAAAAAAC50ZXh0AAAAKA8AAAEA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5kYXRhAAAAFAAAAAIAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5ic3MAAAAAsAAAAAMAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ0mAAAAAQA
AAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ1EAEAAAQAAAADAQQAAAAAAAAAAAAAAAAA
AAAAAC5pZGF0YSQ33AIAAAQAAAADAQwAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAKA8AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3EAMAAAQA
AAADAC5pZGF0YSQ1OAEAAAQAAAADAC5pZGF0YSQ0wAAAAAQAAAADAC5pZGF0YSQ2iAIAAAQA
AAADAC5maWxlAAAA+AAAAP7/AABnAWZha2UAAAAAAAAAAAAAAAAAAGhuYW1lAAAAwAAAAAQA
AAADAGZ0aHVuawAAOAEAAAQAAAADAC50ZXh0AAAAMA8AAAEAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5kYXRhAAAAFAAAAAIAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAsAAAAAMA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQyKAAAAAQAAAADARQAAAADAAAAAAAAAAAA
AAAAAC5pZGF0YSQ1NAEAAAQAAAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ0vAAAAAQA
AAADAQQAAAAAAAAAAAAAAAAAAAAAAC5maWxlAAAAMAEAAP7/AABnAWZha2UAAAAAAAAAAAAA
AAAAAC50ZXh0AAAAMA8AAAEAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5kYXRhAAAAFAAAAAIA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAsAAAAAMAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5pZGF0YSQ0xAAAAAQAAAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ1PAEAAAQA
AAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ3FAMAAAQAAAADAQwAAAAAAAAAAAAAAAAA
AAAAAC50ZXh0AAAAMA8AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ38AIAAAQAAAADAC5pZGF0YSQ1IAEAAAQAAAADAC5pZGF0YSQ0qAAAAAQA
AAADAC5pZGF0YSQ2NAIAAAQAAAADAC50ZXh0AAAAOA8AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ3/AIAAAQAAAADAC5pZGF0YSQ1LAEAAAQA
AAADAC5pZGF0YSQ0tAAAAAQAAAADAC5pZGF0YSQ2dAIAAAQAAAADAC50ZXh0AAAAQA8AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ36AIAAAQA
AAADAC5pZGF0YSQ1GAEAAAQAAAADAC5pZGF0YSQ0oAAAAAQAAAADAC5pZGF0YSQ2EAIAAAQA
AAADAC50ZXh0AAAASA8AAAEAAAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMA
AAADAC5pZGF0YSQ3+AIAAAQAAAADAC5pZGF0YSQ1KAEAAAQAAAADAC5pZGF0YSQ0sAAAAAQA
AAADAC5pZGF0YSQ2XAIAAAQAAAADAC50ZXh0AAAAUA8AAAEAAAADAC5kYXRhAAAAFAAAAAIA
AAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ39AIAAAQAAAADAC5pZGF0YSQ1JAEAAAQA
AAADAC5pZGF0YSQ0rAAAAAQAAAADAC5pZGF0YSQ2SAIAAAQAAAADAC50ZXh0AAAAWA8AAAEA
AAADAC5kYXRhAAAAFAAAAAIAAAADAC5ic3MAAAAAsAAAAAMAAAADAC5pZGF0YSQ37AIAAAQA
AAADAC5pZGF0YSQ1HAEAAAQAAAADAC5pZGF0YSQ0pAAAAAQAAAADAC5pZGF0YSQ2IAIAAAQA
AAADAC5maWxlAAAAQAEAAP7/AABnAWZha2UAAAAAAAAAAAAAAAAAAGhuYW1lAAAAoAAAAAQA
AAADAGZ0aHVuawAAGAEAAAQAAAADAC50ZXh0AAAAYA8AAAEAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5kYXRhAAAAFAAAAAIAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAsAAAAAMA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQyFAAAAAQAAAADARQAAAADAAAAAAAAAAAA
AAAAAC5pZGF0YSQ1FAEAAAQAAAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ0nAAAAAQA
AAADAQQAAAAAAAAAAAAAAAAAAAAAAC5maWxlAAAATgEAAP7/AABnAWZha2UAAAAAAAAAAAAA
AAAAAC50ZXh0AAAAYA8AAAEAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5kYXRhAAAAFAAAAAIA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAsAAAAAMAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5pZGF0YSQ0uAAAAAQAAAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ1MAEAAAQA
AAADAQQAAAAAAAAAAAAAAAAAAAAAAC5pZGF0YSQ3AAMAAAQAAAADARAAAAAAAAAAAAAAAAAA
AAAAAC5maWxlAAAAXAEAAP7/AABnAWxpYmdjYzIuYwAAAAAAAAAAAAAAAAAEAAAAYA8AAAEA
AAAGAAAAAAATAAAAYA8AAAEAAAAGAC50ZXh0AAAAYA8AAAEAAAADAQAAAAAAAAAAAAAAAAAA
AAAAAC5kYXRhAAAAFAAAAAIAAAADAQAAAAAAAAAAAAAAAAAAAAAAAC5ic3MAAAAAsAAAAAMA
AAADAQAAAAAAAAAAAAAAAAAAAAAAAC5zdGFiAAAAFFsAAAUAAAADAcADAAADAAAAAAAAAAAA
AAAAAC5zdGFic3RyAAAAAAAAAAADAfAMAAAAAAAAAAAAAAAAAAAAAF91c2xlZXAAwA4AAAEA
IAACAF9zcHJpbnRm+A4AAAEAIAACAAAAAADqAAAAGAEAAAQAAAACAAAAAAD/AAAAAAAAAAIA
AAACAAAAAAARAQAAAAAAAAIAAAACAAAAAAAgAQAAaA8AAAEAAAACAF9mcmVlAAAA2A4AAAEA
IAACAAAAAAAvAQAAGAEAAAQAAAACAAAAAABEAQAABAEAAAQAAAACAAAAAABTAQAA9AAAAAQA
AAACAAAAAABfAQAA5AAAAAQAAAACAAAAAABrAQAAEA8AAAEAIAACAAAAAACGAQAA3AAAAAQA
AAACAAAAAACjAQAAJAEAAAQAAAACAAAAAAC+AQAA6AAAAAQAAAACAAAAAADKAQAAABAAAP//
AAACAAAAAADjAQAAAAAAAv//AAACAAAAAAD9AQAABAAAAP//AAACAF9HU3RyTXNnsAAAAAMA
AAACAAAAAAAZAgAALAEAAAQAAAACAAAAAAA0AgAACA8AAAEAIAACAAAAAABBAgAAOA8AAAEA
AAACAAAAAABWAgAA/AAAAAQAAAACAAAAAABiAgAA6AAAAAQAAAACAAAAAABuAgAAKAAAAAQA
AAACAF9HU2VtTXNnwAAAAAMAAAACAAAAAACBAgAAWA8AAAEAAAACAAAAAACVAgAAAAAAAAMA
AAACAAAAAACjAgAADAEAAAQAAAACAAAAAACwAgAAABAAAP//AAACAAAAAADIAgAAMA8AAAEA
AAACAAAAAADbAgAAKA8AAAEAAAACAAAAAADrAgAAIAEAAAQAAAACAF9lbnZpcm9uDAAAAAIA
AAACAAAAAAAEAwAACAEAAAQAAAACAF92ZXJib3NlBAAAAAIAAAACAF9vcGVuAAAA8A4AAAEA
IAACAF9fZGxsX18AAAAAAP//AAACAAAAAAASAwAAAAAAAP//AAACAAAAAAAnAwAALAEAAAQA
AAACAAAAAABCAwAAAABAAP//AAACAAAAAABRAwAA4AAAAAQAAAACAAAAAABdAwAA/AAAAAQA
AAACAAAAAABpAwAAABAAAP//AAACAAAAAAB/AwAA1AAAAAQAAAACAAAAAACgAwAA4AAAAAQA
AAACAAAAAACsAwAAIAEAAAQAAAACAF9HU3RyU2ht0AAAAAMAAAACAGVuZAAAAAAAAAAAAP//
AAACAF9tdW5tYXAAsA4AAAEAIAACAAAAAADFAwAA9AAAAAQAAAACAAAAAADRAwAAAAEAAAQA
AAACAAAAAADgAwAAFAAAAAIAAAACAAAAAADtAwAA8AAAAAQAAAACAAAAAAD7AwAAYA8AAAEA
AAACAAAAAAAJBAAA0AAAAAQAAAACAAAAAAAWBAAABAEAAAQAAAACAGV0ZXh0AAAAcA8AAAEA
AAACAAAAAAAlBAAAMAEAAAMAAAACAAAAAAAxBAAAJAEAAAQAAAACAAAAAABMBAAA2AAAAAQA
AAACAAAAAABfBAAAKAEAAAQAAAACAF9fX21haW4AoA4AAAEAIAACAAAAAAB8BAAACAEAAAQA
AAACAF9HU2VtU2Vt4AAAAAMAAAACAAAAAACKBAAAAAAAAAQAAAACAAAAAACYBAAA3AAAAAQA
AAACAAAAAAC1BAAAYA8AAAEAAAACAF9jYWxsb2MAGA8AAAEAIAACAF9fZm1vZGUAEAAAAAIA
AAACAAAAAADEBAAAOAEAAAQAAAACAAAAAADaBAAA+AAAAAQAAAACAAAAAADoBAAA7AAAAAQA
AAACAAAAAAD2BAAASA8AAAEAAAACAAAAAAANBQAADAEAAAQAAAACAAAAAAAaBQAA7AAAAAQA
AAACAAAAAAAoBQAAAAIAAP//AAACAAAAAAA7BQAAzAAAAAQAAAACAF9yZWFsbG9jIA8AAAEA
IAACAAAAAABJBQAA8AAAAAQAAAACAAAAAABXBQAABAAAAP//AAACAAAAAABsBQAA2AAAAAQA
AAACAAAAAAB/BQAAQA8AAAEAAAACAAAAAACOBQAAAAEAAAQAAAACAF9fZW5kX18AAAAAAP//
AAACAAAAAACdBQAAHAEAAAQAAAACAF9HU2VtU2ht8AAAAAMAAAACAF9tYWxsb2MA6A4AAAEA
IAACAAAAAAC3BQAAaA8AAAEAAAACAAAAAADFBQAAUA8AAAEAAAACAAAAAADaBQAA0AAAAAQA
AAACAAAAAADnBQAAAAAQAP//AAACAAAAAAAABgAAAgAAAP//AAACAAAAAAAOBgAAzAAAAAQA
AAACAAAAAAAcBgAAHAEAAAQAAAACAAAAAAA2BgAA+AAAAAQAAAACAAAAAABEBgAA1AAAAAQA
AAACAAAAAABlBgAACAAAAAIAAAACAAAAAAByBgAAAA8AAAEAIAACAAAAAACJBgAA5AAAAAQA
AAACAF93cml0ZQAA4A4AAAEAIAACAAAAAACVBgAAAQAAAP//AAACAAAAAACtBgAAAAAAAP//
AAACAAAAAAC+BgAAFAMAAAQAAAACAAAAAADSBgAA3AIAAAQAAAACAAAAAADhBgAAFAAAAAQA
AAACAAAAAAD2BgAAAAAAAP//AAACAAAAAAASBwAAAAAAAP//AAACAF9raWxsAAAAuA4AAAEA
IAACAF9leGl0AAAAqA4AAAEAIAACAF9HU3RyU2VtAAEAAAMAAAACAAAAAAAqBwAAOAEAAAQA
AAACAF9tbWFwAAAAyA4AAAEAIAACAAAAAABABwAAAAMAAAQAAAACAAAAAABWBwAAKAEAAAQA
AAACAF9jbG9zZQAA0A4AAAEAIAACAHMHAABnY2MyX2NvbXBpbGVkLgBfX19nbnVfY29tcGls
ZWRfYwBfbWFpbkNSVFN0YXJ0dXAAX21zZ19pbml0AF9zaG1faW5pdABfc2VtX2luaXQAX1dp
bk1haW5DUlRTdGFydHVwAF9fX2dudV9jb21waWxlZF9jcGx1c3BsdXMAX2N5Z3dpbl9jcnQw
X2NvbW1vbl9fRlBGaVBQY1BQY19pAF90aGlzX3Byb2MAX2N5Z3dpbl9jcnQwAF9jeWd3aW5f
YXR0YWNoX2RsbABfY3lnd2luX2F0dGFjaF9ub25jeWd3aW5fZGxsAF9faW1wX19DbG9zZUhh
bmRsZUA0AF9fX2N5Z3dpbl9jcnQwX2JwAF9fZGF0YV9zdGFydF9fAF9fX0RUT1JfTElTVF9f
AF9fX2ltcF9DbG9zZUhhbmRsZUA0AF9fX2ltcF9zcHJpbnRmAF9fX2ltcF9tbWFwAF9fX2lt
cF9mcmVlAF9kbGxfY3J0MF9fRlAxMXBlcl9wcm9jZXNzAF9fX2ltcF9kbGxfbm9uY3lnd2lu
X2RsbGNydDAAX19faW1wX1JlbGVhc2VTZW1hcGhvcmVAMTIAX19faW1wX2tpbGwAX19zaXpl
X29mX3N0YWNrX2NvbW1pdF9fAF9fc2l6ZV9vZl9zdGFja19yZXNlcnZlX18AX19tYWpvcl9z
dWJzeXN0ZW1fdmVyc2lvbl9fAF9faW1wX19DcmVhdGVTZW1hcGhvcmVBQDE2AF9kbGxfZGxs
Y3J0MABfQ3JlYXRlU2VtYXBob3JlQUAxNgBfX2ltcF9fb3BlbgBfX2ltcF9fa2lsbABfX2hl
YWRfbGlidXNlcjMyX2EAX0dldE1vZHVsZUhhbmRsZUFANABfX2Jzc19zdGFydF9fAF9faW1w
X193cml0ZQBfX3NpemVfb2ZfaGVhcF9jb21taXRfXwBfT3BlblNlbWFwaG9yZUFAMTIAX01l
c3NhZ2VCb3hBQDE2AF9fX2ltcF9PcGVuU2VtYXBob3JlQUAxMgBfX19pbXBfdXNsZWVwAF9f
bWlub3Jfb3NfdmVyc2lvbl9fAF9fX2ltcF9DcmVhdGVTZW1hcGhvcmVBQDE2AF9faW1hZ2Vf
YmFzZV9fAF9faW1wX19leGl0AF9fX2ltcF9vcGVuAF9fc2VjdGlvbl9hbGlnbm1lbnRfXwBf
X19pbXBfZGxsX2NydDBfX0ZQMTFwZXJfcHJvY2VzcwBfX19pbXBfZXhpdABfX2ltcF9fT3Bl
blNlbWFwaG9yZUFAMTIAX19pbXBfX21tYXAAX19faW1wX3JlYWxsb2MAX19kYXRhX2VuZF9f
AF9fX2ltcF9tYWxsb2MAX19DVE9SX0xJU1RfXwBfX19pbXBfY2xvc2UAX19pbXBfX3Nwcmlu
dGYAX19ic3NfZW5kX18AX19pbXBfX1JlbGVhc2VTZW1hcGhvcmVAMTIAX19faW1wX2RsbF9k
bGxjcnQwAF9faW1wX19XYWl0Rm9yU2luZ2xlT2JqZWN0QDgAX19pbXBfX3VzbGVlcABfX2hl
YWRfdGVtcF9hAF9faW1wX19kbGxfbm9uY3lnd2luX2RsbGNydDAAX19fQ1RPUl9MSVNUX18A
X19pbXBfX01lc3NhZ2VCb3hBQDE2AF9fX2ltcF9tdW5tYXAAX19faW1wX19fbWFpbgBfV2Fp
dEZvclNpbmdsZU9iamVjdEA4AF9fX2ltcF93cml0ZQBfX2ltcF9fX19tYWluAF9fZmlsZV9h
bGlnbm1lbnRfXwBfX19pbXBfY2FsbG9jAF9faW1wX19tYWxsb2MAX19tYWpvcl9vc192ZXJz
aW9uX18AX19pbXBfX2RsbF9kbGxjcnQwAF9DbG9zZUhhbmRsZUA0AF9faW1wX19yZWFsbG9j
AF9faW1wX19HZXRNb2R1bGVIYW5kbGVBQDQAX19EVE9SX0xJU1RfXwBfUmVsZWFzZVNlbWFw
aG9yZUAxMgBfX2ltcF9fY2xvc2UAX19zaXplX29mX2hlYXBfcmVzZXJ2ZV9fAF9fc3Vic3lz
dGVtX18AX19pbXBfX2NhbGxvYwBfX19pbXBfR2V0TW9kdWxlSGFuZGxlQUA0AF9faW1wX19t
dW5tYXAAX19pbXBfX2RsbF9jcnQwX19GUDExcGVyX3Byb2Nlc3MAX19pbXB1cmVfcHRyAF9k
bGxfbm9uY3lnd2luX2RsbGNydDAAX19pbXBfX2ZyZWUAX19tYWpvcl9pbWFnZV92ZXJzaW9u
X18AX19sb2FkZXJfZmxhZ3NfXwBfX2xpYnVzZXIzMl9hX2luYW1lAF9fdGVtcF9hX2luYW1l
AF9faGVhZF9saWJrZXJuZWwzMl9hAF9fbWlub3Jfc3Vic3lzdGVtX3ZlcnNpb25fXwBfX21p
bm9yX2ltYWdlX3ZlcnNpb25fXwBfX19pbXBfTWVzc2FnZUJveEFAMTYAX19saWJrZXJuZWwz
Ml9hX2luYW1lAF9fX2ltcF9XYWl0Rm9yU2luZ2xlT2JqZWN0QDgA
--------------6219841FA783F8BA8815471E--From bouncefilter Tue Jan 4 00:01:51 2000
Received: from FreeBSD.xlinux.com ([203.79.167.135])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA47969
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 00:01:17 -0500 (EST)
(envelope-from kevlo@hello.com.tw)
Received: from hello.com.tw (FreeBSD.xlinux.com [203.79.167.135])
by FreeBSD.xlinux.com (8.9.3/8.9.3) with ESMTP id NAA33498;
Tue, 4 Jan 2000 13:01:08 +0800 (CST)
(envelope-from kevlo@hello.com.tw)
Sender: kevlo@FreeBSD.xlinux.com
Message-ID: <38717E94.B3290934@hello.com.tw>
Date: Tue, 04 Jan 2000 13:01:08 +0800
From: Kevin Lo <kevlo@hello.com.tw>
X-Mailer: Mozilla 4.7 [zh_TW] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert <robert@robert.cz>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Announce: PostgreSQL-6.5.3 binaries available
forWindows NT
References: <385F9F03.D9C199A0@hello.com.tw> <3870FCF1.E7E026B0@robert.cz>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Robert wrote:
Kevin Lo wrote:
Some people asked me to build PostgreSQL binaries for Windows NT.
The binaries(PostgreSQL-6.5.3) are now available at:ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Hi,
Hi, Robert,
I'm trying this on Win98 (cygwin b20.1): initdb creates template1 just
fine (I had to run it as sh initdb), but whenever I try to run
postgres.exe,
it complainsFATAL 1: Database system does not exist. PGDATA
directory '/usr/local/pgsql/data' not foundeven if two minutes ago it worked and the directory is there of course.
Some funny problem with mount? Any help will be greatly apreciated.
mount? You can't run psql server on Windows 98 platform. The PostgreSQL
doesn't generate pq.dll if you notice it.
- Robert
- Kevin
From bouncefilter Tue Jan 4 01:00:51 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA60466
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 01:00:14 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id AAA49413
for pgsql-general@postgresql.org; Tue, 4 Jan 2000 00:43:30 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <3871884B.B359DDDA@stern.nyu.edu>
From: Eldad Midan <af8@stern.nyu.edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: fr
MIME-Version: 1.0
X-Newsgroups: alt.uu.comp.os.linux.questions, comp.os.linux.misc,
comp.databases.postgresql.questions
Subject: how to make postgresql+odbc+staroffice work? II
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 25
Date: Tue, 04 Jan 2000 00:42:35 -0500
X-Trace: typhoon.nyu.edu 946964725 216.165.2.137 (Tue,
04 Jan 2000 00:45:25 EDT)
Organization: New York University
To: pgsql-questions@postgresql.org
Staroffice 5.1a does not support ODBC out of the box, and I installed
PostgreSQL with ODBC driver, but I have not found anything in the docs
about ODBC.
I tried another avenue, by downloading, compiling and installing
unixODBC-1.8.1 from www.genix.net, were ODBC is central to the entire
program, and StarOffice is briefly discussed, but I did not have any
success following the instructions; they are too brief.
So, MY QUESTIONS ARE:
* how do you make postgresql use ODBC?
* how do you compel StarOffice to use the ODBC drivers
* how do you make StarOffice act as a front-end to PostgreSQL
* same questions when using the unixODBC package
* when I use the GUI to set up unixODBC, I get various error messages
telling me that the drivers I registered are not valid or that the info
in odbc.ini or odbcinst.ini doesn't make sense. Since the
administrator's guide to the package is not yet written, can anyone send
me a short set of instructions on creating an odbc database using the
unixODBC for the ODBC including drivers (I compiled the PostgreSQL
drivers) and with PostgreSQL as the server?
Please email me with your suggestions
Thank you
From bouncefilter Tue Jan 4 02:30:53 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA76753
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 02:30:15 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id CAA56801
for pgsql-general@postgresql.org; Tue, 4 Jan 2000 02:19:16 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "Mike DeFehr" <mdefehr@home.com>
X-Newsgroups: alt.uu.comp.os.linux.questions, comp.os.linux.misc,
comp.databases.postgresql.questions
References: <3871884B.B359DDDA@stern.nyu.edu>
Subject: Re: how to make postgresql+odbc+staroffice work? II
Lines: 39
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <S9hc4.164$26.3412@news1.rdc1.mb.home.com>
Date: Tue, 04 Jan 2000 07:19:14 GMT
X-Complaints-To: abuse@home.net
X-Trace: news1.rdc1.mb.home.com 946970354 24.66.35.216 (Mon,
03 Jan 2000 23:19:14 PST)
Organization: @Home Network Canada
To: pgsql-questions@postgresql.org
don't know anything about Staroffice, but ODBC is pretty much 100% on the
client - you have to find ODBC drivers that run on your client that access
PostgreSQL that Staroffice can make use of
to put it another way, PostgreSQL does not need to be compelled to use
ODBC - its up to your ODBC driver to use PostgreSQL, then its up to your
Client database software to make use of your ODBC driver
sorry I can't be of more help...
Eldad Midan wrote in message <3871884B.B359DDDA@stern.nyu.edu>...
Staroffice 5.1a does not support ODBC out of the box, and I installed
PostgreSQL with ODBC driver, but I have not found anything in the docs
about ODBC.I tried another avenue, by downloading, compiling and installing
unixODBC-1.8.1 from www.genix.net, were ODBC is central to the entire
program, and StarOffice is briefly discussed, but I did not have any
success following the instructions; they are too brief.So, MY QUESTIONS ARE:
* how do you make postgresql use ODBC?
* how do you compel StarOffice to use the ODBC drivers
* how do you make StarOffice act as a front-end to PostgreSQL
* same questions when using the unixODBC package
* when I use the GUI to set up unixODBC, I get various error messages
telling me that the drivers I registered are not valid or that the info
in odbc.ini or odbcinst.ini doesn't make sense. Since the
administrator's guide to the package is not yet written, can anyone send
me a short set of instructions on creating an odbc database using the
unixODBC for the ODBC including drivers (I compiled the PostgreSQL
drivers) and with PostgreSQL as the server?Please email me with your suggestions
Thank you
From bouncefilter Wed Jan 5 02:33:08 2000
Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.25.39])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA37224
for <pgsql-general@postgreSQL.org>; Wed, 5 Jan 2000 02:32:37 -0500 (EST)
(envelope-from makky@uclink4.berkeley.edu)
Received: from uclink4.berkeley.edu (makky4715390.HIP.Berkeley.EDU
[136.152.29.54])
by uclink4.berkeley.edu (8.8.8/8.8.8) with ESMTP id XAA05274
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 23:32:34 -0800 (PST)
Sender: root@uclink4.berkeley.edu
Message-ID: <3871A7DB.6B01302E@uclink4.berkeley.edu>
Date: Mon, 03 Jan 2000 23:57:16 -0800
From: KaYue Mak <makky@uclink4.berkeley.edu>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
unsubscribe
From bouncefilter Tue Jan 4 05:35:54 2000
Received: from genesis.sundayta.co.uk (mail.sundayta.co.uk [212.24.70.227])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA23041
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 05:35:33 -0500 (EST)
(envelope-from david@sundayta.co.uk)
Received: from kings.sundayta.co.uk
([192.168.100.31] helo=sundayta.co.uk ident=david)
by genesis.sundayta.co.uk with esmtp (Exim 3.03 #1 (Debian))
id 125S8T-00008S-00; Tue, 04 Jan 2000 11:28:21 +0000
Sender: david
Message-ID: <3871C778.F6255C58@sundayta.co.uk>
Date: Tue, 04 Jan 2000 10:12:08 +0000
From: David Warnock <david@sundayta.co.uk>
Organization: Sundayta Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Lo <kevlo@hello.com.tw>
CC: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Announce: PostgreSQL-6.5.3 binaries available
forWindows NT
References: <385F9F03.D9C199A0@hello.com.tw> <3870FCF1.E7E026B0@robert.cz>
<38717E94.B3290934@hello.com.tw>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kevin,
We are interested in funding work to get postgresql working on Windows
9x.
I know that cgywin is available for Win9x but that parts of the api are
not available.
Do you believe it will be possible to build and run postgresql on Win9x?
How much work would be involved?
Thanks
Dave
Kevin Lo wrote:
Robert wrote:
Kevin Lo wrote:
Some people asked me to build PostgreSQL binaries for Windows NT.
The binaries(PostgreSQL-6.5.3) are now available at:ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz
Hi,
Hi, Robert,
I'm trying this on Win98 (cygwin b20.1): initdb creates template1 just
fine (I had to run it as sh initdb), but whenever I try to run
postgres.exe,
it complainsFATAL 1: Database system does not exist. PGDATA
directory '/usr/local/pgsql/data' not foundeven if two minutes ago it worked and the directory is there of course.
Some funny problem with mount? Any help will be greatly apreciated.mount? You can't run psql server on Windows 98 platform. The PostgreSQL
doesn't generate pq.dll if you notice it.- Robert
- Kevin
************
From bouncefilter Tue Jan 4 05:55:54 2000
Received: from genesis.sundayta.co.uk (mail.sundayta.co.uk [212.24.70.227])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA30260
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 05:55:26 -0500 (EST)
(envelope-from david@sundayta.co.uk)
Received: from kings.sundayta.co.uk
([192.168.100.31] helo=sundayta.co.uk ident=david)
by genesis.sundayta.co.uk with esmtp (Exim 3.03 #1 (Debian))
id 125SSr-0000A3-00; Tue, 04 Jan 2000 11:49:25 +0000
Sender: david
Message-ID: <3871CC67.F4048189@sundayta.co.uk>
Date: Tue, 04 Jan 2000 10:33:11 +0000
From: David Warnock <david@sundayta.co.uk>
Organization: Sundayta Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Future of PostgreSQL
References: <199912251600.LAA21597@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce,
Interbase users are considering moving en-mass to PostgreSQL
Inprise have just announced that they are making Interbase 6 available
as open source. But no information yet on License or on how they are
going to support it. I am not confident they can recruit enough
volunteers and am confident that it will take a loong while to become an
efficient Open Source team that is confidently developing the code.
Publishers are crawling all over each other to publish a PostgreSQL book
This would be a really good thing.
My big question is, what new challenges will we face as we become more
popular?
I think the overriding emphasis has been clearly stressed as stability
and reliability way ahead of anything else.
After that features which can help stability, reliability and speed (eg
transaction logs).
After that I am not so worried about much apart from support for Win9x
(as I have mentioned just once or twice).
Do we have the proper license? I know this has the possibility of
opening up a GPL vs. BSD slugfest. However, I will not let such a
discussion get out of control.
I am happy with the license.
Regards
Dave
From bouncefilter Tue Jan 4 06:04:54 2000
Received: from smtp-2.nordnet.fr (smtp-2.nordnet.fr [194.206.126.252])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA34303
for <pgsql-general@hub.org>; Tue, 4 Jan 2000 06:04:04 -0500 (EST)
(envelope-from aflorent@iris-tech.fr)
Received: from scomm.iris-tech.fr (gate7-181.nordnet.fr [195.146.225.181])
by smtp-2.nordnet.fr (8.9.3/8.9.0) with ESMTP id MAA19421
for <pgsql-general@hub.org>; Tue, 4 Jan 2000 12:03:59 +0100
Received: from (mail@localhost)
by scomm.iris-tech.fr (8.8.5/jtpda-5.3) id MAA30587
for <pgsql-general@hub.org>; Tue, 4 Jan 2000 12:02:20 +0100
X-Authentication-Warning: Scomm.iris-tech.fr: mail set sender to
<aflorent@iris-tech.fr> using -f
Received: from siris.iris-tech.fr(192.168.0.100) by Scomm via smap (V2.1)
id xma030541; Tue, 4 Jan 00 11:43:29 +0100
Received: from iris-tech.fr (aflorent@afl.iris-tech.fr [192.168.0.5])
by siris.iris-tech.fr (8.8.8/jtpda-5.3) with ESMTP id LAA13274
for <pgsql-general@hub.org>; Tue, 4 Jan 2000 11:43:29 +0100
Message-ID: <3871CED2.E87B7FEF@iris-tech.fr>
Date: Tue, 04 Jan 2000 11:43:30 +0100
From: Arnaud FLORENT <aflorent@iris-tech.fr>
X-Mailer: Mozilla 4.7 [fr] (Win95; I)
X-Accept-Language: fr,en
MIME-Version: 1.0
To: PostgreSQL general ML <pgsql-general@hub.org>
Subject: [GENERAL]disk size
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
is there a method to evaluate the disk size required for a database
exploitation?
--
______________________________
Arnaud FLORENT
IRIS Technologies
phone: (33) 03 20 65 85 80
fax: (33) 03 20 65 85 81
GSM: (33) 06 15 14 32 90
mailto:aflorent@iris-tech.fr
______________________________
From bouncefilter Tue Jan 4 06:29:54 2000
Received: from queluz.economatica.com.br (mail@queluz.economatica.com.br
[200.231.195.36]) by hub.org (8.9.3/8.9.3) with ESMTP id GAA36624
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 06:29:23 -0500 (EST)
(envelope-from oexel@economatica.com.br)
Received: from oexel by queluz.economatica.com.br with local (Exim 2.05 #1
(Debian)) id 125S9M-0000lU-00; Tue, 4 Jan 2000 09:29:16 -0200
Date: Tue, 4 Jan 2000 09:29:16 -0200
From: Otavio Exel <oexel@economatica.com.br>
To: PostgreSQL mailing list <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] WIN-client wanted ...
Message-ID: <20000104092916.B2645@economatica.com.br>
Reply-To: oexel@economatica.com.br
References: <200001011923.UAA06930@feki.toppoint.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <200001011923.UAA06930@feki.toppoint.de>;
from Marten Feldtmann on Sat, Jan 01, 2000 at 08:23:35PM +0100
Organization: Economatica Ltda
Marten Feldtmann wrote:
I'm in need for a thin libpq library under Win'32.
it is amazing how few people seem to be using libpq.dll! my next project
will need some kind of client server db access and I'm seriously
considering using libpq.dll; I won't need a full blown SQL engine, just
a way to store and retrieve records with row-level locking and
transaction support;
is libpq.dll as under-used as I deduce from reading this list?
beers,
--
Otavio Exel /<\oo/>\ oexel@economatica.com.br
From bouncefilter Mon Jan 3 18:01:46 2000
Received: from smtp2.ihug.co.nz (tk2.ihug.co.nz [203.29.160.14])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA61769
for <pgsql-general@postgreSQL.org>; Mon, 3 Jan 2000 18:01:42 -0500 (EST)
(envelope-from mark@chalice.gen.nz)
Received: from chalice.gen.nz (root@se7en.org [203.29.166.124])
by smtp2.ihug.co.nz (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA23989
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 12:01:29 +1300
Received: from morpork (mark@morpork [10.0.0.4])
by chalice.gen.nz (8.8.7/8.8.7) with ESMTP id LAA26552
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 11:31:09 GMT
Date: Tue, 4 Jan 2000 11:31:07 +0000 (GMT)
From: Mark Derricutt <mark@chalice.gen.nz>
To: pgsql-general@postgreSQL.org
Subject: [DUG]: Intebase is OpenSourced (fwd)
Message-ID: <Pine.LNX.4.20.0001041130110.26518-100000@chalice.gen.nz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hey folks, thought you guys might like to read this.
---------- Forwarded message ----------
Date: Tue, 04 Jan 2000 10:58:44 +1300
From: Nic Wise <nic@xerxes.co.nz>
Reply-To: delphi@delphi.org.nz
To: Multiple recipients of list delphi <delphi@delphi.org.nz>
Subject: [DUG]: Intebase is OpenSourced
(ripped (and altered) from an internal memo...)
Hi folks,
if you check out http://www.borland.com/about/press/2000/ib.html
you'll see the news that we have open-sourced InterBase on NT, Linux &
Solaris, including the Beta v.6 of InterBase.
More info on this as we get it (and can release it :) ).
Hmmm, now let me see - free, industrial strength DB, with the option to
change it to your own needs..... being 5.6 is already a stable code base
(and 6.0 was at the point of "we've finished with it, now can you check
your reported bugs are fixed"), I'd say that would beat MSDE hands down,
no?
Nic.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - delphi@delphi.org.nz
Website: http://www.delphi.org.nz
From bouncefilter Tue Jan 4 08:21:56 2000
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA61453
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 08:21:18 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA69266;
Tue, 4 Jan 2000 09:20:09 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 4 Jan 2000 09:20:09 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: David Warnock <david@sundayta.co.uk>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <3871CC67.F4048189@sundayta.co.uk>
Message-ID: <Pine.BSF.4.21.0001040919180.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, David Warnock wrote:
Publishers are crawling all over each other to publish a PostgreSQL
bookThis would be a really good thing.
Two books "in the works" right now...Bruce's is currently
available online off of http://www.postgresql.org ...
From bouncefilter Tue Jan 4 10:38:10 2000
Received: from talos.host4u.net (talos.host4u.net [209.150.128.168])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA94111
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 10:37:35 -0500 (EST)
(envelope-from chip@chipcastle.com)
Received: from chipcastle.com (cx476564-a.mcity1.la.home.com [24.4.63.21])
by talos.host4u.net (8.8.5/8.8.5) with ESMTP id JAA04695
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 09:37:32 -0600
Sender: chip@talos.host4u.net
Message-ID: <387213CA.FFD56532@chipcastle.com>
Date: Tue, 04 Jan 2000 09:37:46 -0600
From: Chip Castle <chip@chipcastle.com>
Reply-To: chip@chipcastle.com
Organization: Chip Castle Dot Com, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgresql.org
Subject: \di won't display indexes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
The following psql transcript shows that \di and \ds commands do not
show output, but that specifying a table explicitly (av_parts for
example) does show the layout of my table as well as the indexes I
expected to see. To make matters more confusing, my queries are
extremely slow, so it appears that the indexes actually DO NOT EXIST.
My Questions:
How can I get the \di and \ds options to work?
How do I verify that the indexes do exist?
BTW: We're running PostGres 6.5.3
=========================================================
parts=> \di
Couldn't find any indices!
parts=> \ds
Couldn't find any sequences!
parts=> \d
Couldn't find any tables, sequences or indices!
parts=> \d av_parts
Table = av_parts
+----------------------------------+----------------------------------+-------+
| Field | Type |
Length|
+----------------------------------+----------------------------------+-------+
| itemid | int4 not null default nextval (
| 4 |
| vendorid | int4
| 4 |
| partnumber | varchar()
| 25 |
| alternatepartnumber | varchar()
| 25 |
| nsn | varchar()
| 15 |
| description | varchar()
| 50 |
| condition | varchar()
| 10 |
| quantity | int4
| 4 |
| rawpartnumber | varchar()
| 25 |
| rawalternatenumber | varchar()
| 25 |
| rawnsnnumber | varchar()
| 15 |
| date | int4
| 4 |
| cagecode | varchar()
| 10 |
+----------------------------------+----------------------------------+-------+
Indices: av_parts_alternatepartnumber_in
av_parts_itemid_key
av_parts_nsn_index
av_parts_partnumber_index
av_parts_rawalternatenumber_ind
av_parts_rawnsnnumber_index
av_parts_rawpartnumber_index
av_parts_vendorid_index
parts=> ==============================================================================
Thanks!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chip Castle Chip Castle Dot Com, Inc.
chip@chipcastle.com http://www.chipcastle.com
504.412.8002 Perl CGI MySQL E-commerce
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From bouncefilter Tue Jan 4 11:13:58 2000
Received: from alf.zfn.uni-bremen.de (alf.zfn.uni-bremen.de [134.102.20.22])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA09330
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 11:13:11 -0500 (EST)
(envelope-from umehlig@uni-bremen.de)
Received: from pandora3.localnet (root@tnt47.zfn.uni-bremen.de [134.102.7.47])
by alf.zfn.uni-bremen.de (8.9.1a/ZfNServer) with ESMTP id RAA57174
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 17:09:23 +0100
Received: (from umehlig@localhost)
by pandora3.localnet (8.9.1/8.9.1) id RAA11073;
Tue, 4 Jan 2000 17:13:38 +0100
Date: Tue, 4 Jan 2000 17:13:38 +0100
From: Ulf Mehlig <umehlig@uni-bremen.de>
Message-Id: <200001041613.RAA11073@pandora3.localnet>
X-Authentication-Warning: pandora3.localnet: umehlig set sender to
umehlig@pandora3.localnet using -f
To: pgsql-general@postgreSQL.org
Subject: dificulties with views and aggregates
Hello out there,
There is a line "Allow DISTINCT on views" in the TODO of 6.5.3; I
think my problem below is due to this ... is there a workaround other
than creating a "real" table instead of a view? Is there any
"schedule" for the "view"-problems (just an interested question, by no
means intended to be offensive! I'm quite happy with postgreSQL so
far :-)
Thank you,
Ulf
P.S.: please CC: me in case of an answer, I'm not on the list at the
moment!
----------------------------------------------------------------------
My problem is: I have a table with a date and a time column
combined with a measurement value.
db=> create table test (d date, t time, val float8);
CREATE
[... insert something ...]
Now I want to calculate the mean daily maximal span of the recorded
values for each month. I create a view:
db=> create view span as
db-> select date_part('year', d) as yr,
db-> date_part('month', d) as mon,
db-> max(val)-min(val) as vdiff
db-> from test group by d;
CREATE
Now I try to calculate the average span:
db=> select yr, mon, avg(vdiff)
db-> from span group by yr, mon order by 1, 2;
yr mon avg
----+---+------------------
1997 1 1.62315789473684
1997 1 3.17684210526316
1997 1 2.66842105263158
[...]
There should be only one tupel for each year/month combination
returned. I is also not possible to select e.g. yr "distict":
db=> select distinct yr from span;
yr
----
1997
1997
1997
If there is only a "date_part()"-column in the view, "distinct" works:
db=> create view dpt as
db-> select date_part('month', d) as mon from test;
CREATE
db=> select distinct * from dpt;
mon
---
1
2
3
--
======================================================================
Ulf Mehlig <umehlig@zmt.uni-bremen.de>
Center for Tropical Marine Ecology/ZMT, Bremen, Germany
----------------------------------------------------------------------
From bouncefilter Wed Jan 5 00:26:07 2000
Received: from mail.toppoint.de (bender.toppoint.de [195.244.243.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA09052
for <pgsql-general@postgreSQL.org>; Wed, 5 Jan 2000 00:25:18 -0500 (EST)
(envelope-from marten@feki.toppoint.de)
Received: (from uucp@localhost) by mail.toppoint.de (8.9.3/8.9.3) id GAA05193;
Wed, 5 Jan 2000 06:25:00 +0100 (MET)
Received: (from marten@localhost)
by feki.toppoint.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id SAA22087;
Tue, 4 Jan 2000 18:25:38 +0100
From: Marten Feldtmann <marten@feki.toppoint.de>
Message-Id: <200001041725.SAA22087@feki.toppoint.de>
Subject: Re: [GENERAL] WIN-client wanted ...
In-Reply-To: <20000104092916.B2645@economatica.com.br> from Otavio Exel at
"Jan
4, 2000 09:29:16 am"
To: oexel@economatica.com.br
Date: Tue, 4 Jan 2000 18:25:38 +0100 (CET)
CC: PostgreSQL mailing list <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Marten Feldtmann wrote:
I'm in need for a thin libpq library under Win'32.
it is amazing how few people seem to be using libpq.dll! my next project
will need some kind of client server db access and I'm seriously
considering using libpq.dll; I won't need a full blown SQL engine, just
a way to store and retrieve records with row-level locking and
transaction support;is libpq.dll as under-used as I deduce from reading this list?
Hmmm, libpq without a full blown SQL engine somewhere does not make sense -
therefore I do not understand your question above - libpq just give you the
communication to this full blown sql engine.
It seems to be dependent of the platform one is using. On Windows'xyz you
use ODBC in nearly all the places. But I've also heard, that some projects
do not use ODBC und just use the low-level libraries from Oracle or IBM to
get rid of the additional odbc structure. When it comes to products suitable
for several databases it may be useful to use odbc.
I myself just would like to have the thin libpq.dll and libpq.lib for the
case NOT to use the ODBC structure of Windows and therefore make everyone the
connectivity to our database product available.
Another point is the thin structure of the API of PostgreSQL. There has
been a libpq available for PostgreSQL 6.4.2 on the net ... but with 6.5.x
I've seen nothing like this. I had thought, that the odbc dll would had
the libpq also, but it seems, that they integrate the libpq stuff into
the odbc library.
Marten
From bouncefilter Tue Jan 4 13:24:59 2000
Received: from sakaki.communique.net (sakaki.communique.net [204.27.64.202])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA38025
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 13:24:43 -0500 (EST)
(envelope-from davidb@vectormath.com)
From: davidb@vectormath.com
Received: from bullwinkle (adsl-204-1-67-149.indi.se.verio.net [204.1.67.149])
by sakaki.communique.net (8.8.8/8.8.8) with SMTP id MAA26065;
Tue, 4 Jan 2000 12:24:16 -0600 (CST)
Message-ID: <00ad01bf56e0$aa6ce6f0$0602010a@bullwinkle.vectormath>
To: "Mike Mascari" <mascarm@mascari.com>,
"Chris Carbaugh" <cjdesigns@sprintmail.com>
Cc: <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Import table from MS Access?
Date: Tue, 4 Jan 2000 12:22:19 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
We've had good luck with something we found at:
David Boerwinkle
-----Original Message-----
From: Mike Mascari <mascarm@mascari.com>
To: Chris Carbaugh <cjdesigns@sprintmail.com>
Cc: pgsql-general@postgreSQL.org <pgsql-general@postgreSQL.org>
Date: Sunday, December 26, 1999 6:08 PM
Subject: Re: [GENERAL] Import table from MS Access?
Chris Carbaugh wrote:
What is the best way to import a table from Microsoft Access 2000?
I was able to export to a text file from access, but this was only the
data. Can I export/import the table definition as well?I have been using pgaccess to administer my DB. It seems I can't tell
it to import a comma delimited file? Is there any way around this?Any help is greatly appreciated.
Chris
One way is to use the PostgreSQL ODBC driver from Insight (search
yahoo.com for: postgres Insight ODBC), and use the File->Export function
in Access to export the tables to PostgreSQL. There are a few problems
with this method, though, if I recall correctly:1. Table and field names will be case-sensitive, so if you have a table
in Access called Employees with a field HireDate, then in PostgreSQL,
you must refer to this as "Employees"."HireDate", not employees.hiredate,
although you could programmatically rename the tables by performing an
update on pg_class and pg_attribute.2. Column constraints are not exported. If I recall (its been some time),
column constraints are not exported from Access when the tables are
created. And, unfortunately, there's no easy way to add them in
PostgreSQL using an ALTER TABLE statement.Nevertheless, it might be easier to perform the export in Access using
ODBC, pg_dump the database to a text file, perform whatever cleanup is
necessary, and then reimport.Also, I rember that there's a PostgreSQL upsizing tool somewhere that
does all this stuff for you. But for the life of me I can't remember
where...Hope that helps,
Mike Mascari
************
From bouncefilter Tue Jan 4 13:27:00 2000
Received: from sakaki.communique.net (sakaki.communique.net [204.27.64.202])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA38259
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 13:26:45 -0500 (EST)
(envelope-from davidb@vectormath.com)
From: davidb@vectormath.com
Received: from bullwinkle (adsl-204-1-67-149.indi.se.verio.net [204.1.67.149])
by sakaki.communique.net (8.8.8/8.8.8) with SMTP id MAA27154
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 12:26:44 -0600 (CST)
Message-ID: <00b801bf56e0$fd49abb0$0602010a@bullwinkle.vectormath>
To: <pgsql-general@postgreSQL.org>
Subject: Fw: [GENERAL] Import table from MS Access?
Date: Tue, 4 Jan 2000 12:24:48 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
When I sent this I overlooked the fact that you specified Access 2000. We
use Access 97.
Sorry,
David Boerwinkle
-----Original Message-----
From: davidb@vectormath.com <davidb@vectormath.com>
To: Mike Mascari <mascarm@mascari.com>; Chris Carbaugh
<cjdesigns@sprintmail.com>
Cc: pgsql-general@postgreSQL.org <pgsql-general@postgreSQL.org>
Date: Tuesday, January 04, 2000 12:22 PM
Subject: Re: [GENERAL] Import table from MS Access?
We've had good luck with something we found at:
David Boerwinkle
-----Original Message-----
From: Mike Mascari <mascarm@mascari.com>
To: Chris Carbaugh <cjdesigns@sprintmail.com>
Cc: pgsql-general@postgreSQL.org <pgsql-general@postgreSQL.org>
Date: Sunday, December 26, 1999 6:08 PM
Subject: Re: [GENERAL] Import table from MS Access?Chris Carbaugh wrote:
What is the best way to import a table from Microsoft Access 2000?
I was able to export to a text file from access, but this was only the
data. Can I export/import the table definition as well?I have been using pgaccess to administer my DB. It seems I can't tell
it to import a comma delimited file? Is there any way around this?Any help is greatly appreciated.
Chris
One way is to use the PostgreSQL ODBC driver from Insight (search
yahoo.com for: postgres Insight ODBC), and use the File->Export function
in Access to export the tables to PostgreSQL. There are a few problems
with this method, though, if I recall correctly:1. Table and field names will be case-sensitive, so if you have a table
in Access called Employees with a field HireDate, then in PostgreSQL,
you must refer to this as "Employees"."HireDate", not employees.hiredate,
although you could programmatically rename the tables by performing an
update on pg_class and pg_attribute.2. Column constraints are not exported. If I recall (its been some time),
column constraints are not exported from Access when the tables are
created. And, unfortunately, there's no easy way to add them in
PostgreSQL using an ALTER TABLE statement.Nevertheless, it might be easier to perform the export in Access using
ODBC, pg_dump the database to a text file, perform whatever cleanup is
necessary, and then reimport.Also, I rember that there's a PostgreSQL upsizing tool somewhere that
does all this stuff for you. But for the life of me I can't remember
where...Hope that helps,
Mike Mascari
************
From bouncefilter Tue Jan 4 14:08:01 2000
Received: from mail1.panix.com (mail1.panix.com [166.84.0.212])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA59064
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 14:07:34 -0500 (EST)
(envelope-from tomg@admin.nrnet.org)
Received: from mailhost.nrnet.org (mailhost.nrnet.org [166.84.192.39])
by mail1.panix.com (Postfix) with ESMTP
id D183430F09; Tue, 4 Jan 2000 14:07:31 -0500 (EST)
Received: from admin.nrnet.org (uucp@localhost)
by mailhost.nrnet.org (8.8.7/8.8.4) with UUCP
id NAA04442; Tue, 4 Jan 2000 13:33:57 -0500
Received: from localhost (tomg@localhost)
by admin.nrnet.org (8.9.1/8.9.1) with ESMTP id NAA20267;
Tue, 4 Jan 2000 13:34:13 -0500
Date: Tue, 4 Jan 2000 13:34:13 -0500 (EST)
From: Thomas Good <tomg@admin.nrnet.org>
To: The Hermit Hacker <scrappy@hub.org>
Cc: David Warnock <david@sundayta.co.uk>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.BSF.4.21.0001040919180.18498-100000@thelab.hub.org>
Message-ID: <Pine.LNX.4.05.10001041334001.20261-100000@admin.nrnet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, The Hermit Hacker wrote:
On Tue, 4 Jan 2000, David Warnock wrote:
Publishers are crawling all over each other to publish a PostgreSQL
bookThis would be a really good thing.
Two books "in the works" right now...Bruce's is currently
available online off of http://www.postgresql.org ...
Marc - what is number 2?
------- North Richmond Community Mental Health Center -------
Thomas Good MIS Coordinator
Vital Signs: tomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056
/* Member: Computer Professionals For Social Responsibility */
From bouncefilter Tue Jan 4 15:07:00 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA72347
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 15:06:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA20457;
Tue, 4 Jan 2000 14:37:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041937.OAA20457@candle.pha.pa.us>
Subject: Re: [GENERAL] Announce: PostgreSQL-6.5.3 binaries available
forWindows
NT
In-Reply-To: <3871C778.F6255C58@sundayta.co.uk> from David Warnock at "Jan 4,
2000 10:12:08 am"
To: David Warnock <david@sundayta.co.uk>
Date: Tue, 4 Jan 2000 14:37:30 -0500 (EST)
CC: Kevin Lo <kevlo@hello.com.tw>, pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Kevin,
We are interested in funding work to get postgresql working on Windows
9x.I know that cgywin is available for Win9x but that parts of the api are
not available.Do you believe it will be possible to build and run postgresql on Win9x?
How much work would be involved?
I wonder if it would be easier to pay Cygnus to port the missing pieces.
Can you give us a detailed list of the missing features the PostgreSQL
needs the Cgywin doesn't have on Win9x?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 15:07:07 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA72313
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 15:06:19 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA20470;
Tue, 4 Jan 2000 14:38:58 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041938.OAA20470@candle.pha.pa.us>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <3871CC67.F4048189@sundayta.co.uk> from David Warnock at "Jan 4,
2000 10:33:11 am"
To: David Warnock <david@sundayta.co.uk>
Date: Tue, 4 Jan 2000 14:38:57 -0500 (EST)
CC: PostgreSQL-general <pgsql-general@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce,
Interbase users are considering moving en-mass to PostgreSQL
Inprise have just announced that they are making Interbase 6 available
as open source. But no information yet on License or on how they are
going to support it. I am not confident they can recruit enough
volunteers and am confident that it will take a loong while to become an
efficient Open Source team that is confidently developing the code.Publishers are crawling all over each other to publish a PostgreSQL book
This would be a really good thing.
My big question is, what new challenges will we face as we become more
popular?I think the overriding emphasis has been clearly stressed as stability
and reliability way ahead of anything else.After that features which can help stability, reliability and speed (eg
transaction logs).After that I am not so worried about much apart from support for Win9x
(as I have mentioned just once or twice).
Seems this is the general consensus, and this has been our order of
priorities from day 1, so it looks like we are OK and heading on the
right course.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 14:54:01 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67092
for <pgsql-general@hub.org>; Tue, 4 Jan 2000 14:53:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA20480;
Tue, 4 Jan 2000 14:39:17 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041939.OAA20480@candle.pha.pa.us>
Subject: Re: [GENERAL]disk size
In-Reply-To: <3871CED2.E87B7FEF@iris-tech.fr> from Arnaud FLORENT at "Jan 4,
2000 11:43:30 am"
To: Arnaud FLORENT <aflorent@iris-tech.fr>
Date: Tue, 4 Jan 2000 14:39:17 -0500 (EST)
CC: PostgreSQL general ML <pgsql-general@hub.org>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
is there a method to evaluate the disk size required for a database
exploitation?
Sure, see FAQ item on this.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 15:01:14 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA68338
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 15:00:17 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id OAA13507
for pgsql-general@postgresql.org; Tue, 4 Jan 2000 14:45:07 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
From: "svn" <svngo@earthlink.net>
X-Newsgroups: comp.databases.postgresql.questions
Subject: grant/revoke rights
Lines: 15
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <F2sc4.5168$Ec5.265658@newsread1.prod.itd.earthlink.net>
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread1.prod.itd.earthlink.net 947014949 158.252.147.150 (Tue,
04 Jan 2000 11:42:29 PST)
Organization: EarthLink Network, Inc.
X-ELN-Date: Tue Jan 4 11:42:29 2000
X-ELN-Insert-Date: Tue Jan 4 11:42:29 2000
X-Posted-Path-Was: not-for-mail
Date: Tue, 04 Jan 2000 19:42:29 GMT
To: pgsql-questions@postgresql.org
Can someone direct me as to why the rights that I specify for a given table
doesn't take affect? I revoked all rights to the "Public" and the postgres
default id "nobody" can still do inserts, deletes, updates, etc.
I do a "\z" on the table and it shows no rights, but still allows anyone w/
a valid
postgres id to wipe out any row they wish. I've even tried to manually
revoke the rights from "nobody" and it still doesn't work. Are there
setting some where that "turns on" the specified privileges intiated by the
revoke/grant commands?
Thanks in advance.....
From bouncefilter Tue Jan 4 15:07:14 2000
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA72316
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 15:06:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA20540;
Tue, 4 Jan 2000 14:43:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200001041943.OAA20540@candle.pha.pa.us>
Subject: Re: [GENERAL] \di won't display indexes
In-Reply-To: <387213CA.FFD56532@chipcastle.com> from Chip Castle at "Jan 4,
2000 09:37:46 am"
To: chip@chipcastle.com
Date: Tue, 4 Jan 2000 14:43:45 -0500 (EST)
CC: pgsql-general@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
My guess is that you lost the pg_shadow entry for the users owning the
tables?
Hello,
The following psql transcript shows that \di and \ds commands do not
show output, but that specifying a table explicitly (av_parts for
example) does show the layout of my table as well as the indexes I
expected to see. To make matters more confusing, my queries are
extremely slow, so it appears that the indexes actually DO NOT EXIST.My Questions:
How can I get the \di and \ds options to work?
How do I verify that the indexes do exist?BTW: We're running PostGres 6.5.3
=========================================================
parts=> \di
Couldn't find any indices!
parts=> \ds
Couldn't find any sequences!
parts=> \d
Couldn't find any tables, sequences or indices!
parts=> \d av_partsTable = av_parts +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | itemid | int4 not null default nextval ( | 4 | | vendorid | int4 | 4 | | partnumber | varchar() | 25 | | alternatepartnumber | varchar() | 25 | | nsn | varchar() | 15 | | description | varchar() | 50 | | condition | varchar() | 10 | | quantity | int4 | 4 | | rawpartnumber | varchar() | 25 | | rawalternatenumber | varchar() | 25 | | rawnsnnumber | varchar() | 15 | | date | int4 | 4 | | cagecode | varchar() | 10 | +----------------------------------+----------------------------------+-------+ Indices: av_parts_alternatepartnumber_in av_parts_itemid_key av_parts_nsn_index av_parts_partnumber_index av_parts_rawalternatenumber_ind av_parts_rawnsnnumber_index av_parts_rawpartnumber_index av_parts_vendorid_index parts=>==============================================================================
Thanks!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chip Castle Chip Castle Dot Com, Inc.
chip@chipcastle.com http://www.chipcastle.com
504.412.8002 Perl CGI MySQL E-commerce
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~************
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Tue Jan 4 14:54:04 2000
Received: from clio.trends.ca (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67005
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 14:53:00 -0500 (EST)
(envelope-from scrappy@hub.org)
Received: from thelab.hub.org (nat200.60.mpoweredpc.net [142.177.200.60])
by clio.trends.ca (8.9.3+Sun/8.9.3) with ESMTP id OAA29635
for <pgsql-general@postgreSQL.org>; Tue, 4 Jan 2000 14:52:49 -0500 (EST)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA72593;
Tue, 4 Jan 2000 15:46:04 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Tue, 4 Jan 2000 15:46:04 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Thomas Good <tomg@admin.nrnet.org>
cc: David Warnock <david@sundayta.co.uk>,
Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-general <pgsql-general@postgreSQL.org>
Subject: Re: [GENERAL] Future of PostgreSQL
In-Reply-To: <Pine.LNX.4.05.10001041334001.20261-100000@admin.nrnet.org>
Message-ID: <Pine.BSF.4.21.0001041545210.18498-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 4 Jan 2000, Thomas Good wrote:
On Tue, 4 Jan 2000, The Hermit Hacker wrote:
On Tue, 4 Jan 2000, David Warnock wrote:
Publishers are crawling all over each other to publish a PostgreSQL
bookThis would be a really good thing.
Two books "in the works" right now...Bruce's is currently
available online off of http://www.postgresql.org ...Marc - what is number 2?
As yet to be announced...its proposed as being more indepth, building from
an "Application programming" standpoint, if memory serves ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Tue Jan 4 15:01:02 2000
Received: from news.tht.net (news.hub.org [216.126.91.242])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA68337
for <pgsql-general@postgresql.org>; Tue, 4 Jan 2000 15:00:16 -0500 (EST)
(envelope-from news@news.tht.net)
Received: (from news@localhost) by news.tht.net (8.9.3/8.9.3) id OAA14176
for pgsql-general@postgresql.org; Tue, 4 Jan 2000 14:59:02 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: news.tht.net: news set sender to <news> using -f
Message-ID: <38724FEF.74A8B992@mediaone.net>
From: dlinton <dlinton@mediaone.net>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
X-Newsgroups: comp.databases.postgresql.questions
Subject: Postgresql C Interface
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 9
Date: Tue, 04 Jan 2000 19:59:01 GMT
X-Complaints-To: abuse@mediaone.net
X-Trace: ndnws01.ne.mediaone.net 947015941 24.128.136.53 (Tue,
04 Jan 2000 14:59:01 EST)
Organization: Road Runner
To: pgsql-questions@postgresql.org
I am interested in finding out where there might be some example C
programs which interface to Postgres databases. The examples given at
the postgres site don't seem to be enough. Are there any sites or people
that have more information and examples.
Thank You
Import Notes
Reference msg id not found: 385C1F8E.2CC771A7@nlr.ruReference msg id not found: 385C3BE0.D307E8B5@mascari.com