From matei@cs.toronto.edu Wed Oct 14 22:26:31 2015 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.85) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1ZmSd2-000Qe7-RG>; Wed, 14 Oct 2015 22:26:28 +0200 Received: from bureau94.ns.utoronto.ca ([128.100.132.252]) by relay1.zedat.fu-berlin.de (Exim 4.85) for seqan-dev@lists.fu-berlin.de with esmtps (envelope-from ) id <1ZmSd2-000wMQ-DJ>; Wed, 14 Oct 2015 22:26:28 +0200 Received: from ara-vm ([206.108.127.16]) (authenticated bits=0) by bureau94.ns.utoronto.ca (8.13.8/8.13.8) with ESMTP id t9EKQMo9001923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 14 Oct 2015 16:26:23 -0400 Date: Wed, 14 Oct 2015 16:26:22 -0400 From: Matei David To: seqan-dev@lists.fu-berlin.de Message-ID: <20151014162622.45095bde@ara-vm> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 128.100.132.252 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1444854388-00000D05-2275CBF9/0/0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, version=1.2.4 X-Spam-Flag: NO X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED X-Spam-Checker-Version: SpamAssassin 3.4.1 on Tokelau.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] end-to-end consensus alignment for short sequences X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.16 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 20:26:31 -0000 Hi, First of all, thanks for a great library. I have some questions about using the library in my project (not developing it per se), I hope this is the right venue for asking. I would like to do end-to-end consensus alignment between several DNA sequences. I currently have this implemented as follows: for (unsigned i = 0; i < v.size(); ++i) { seqan::appendRead(store, v[i].data()); seqan::appendAlignedRead( store, i, 0, 0, 0 + (int)v[i].size()); } options.useContigID = true; options.usePositions = true; seqan::consensusAlignment(store, options); // seqan::reAlignment(store, 0, 1, 10, false); // needed? result = store.contigStore[0].seq; This works ok, but it has 2 shortcomings: 1. I noticed after some runs is that the library only processes the read store if it contains sequences with length greater than 20bp. I'm not sure if all sequences, or only some of them, need to be of this length for it to work. If all sequences are shorter than 20bp, it seems that the consensus output is just the first sequence. So, for instance: Reads: A AA AA Consensus alignment: A . So the output is "A", not "AA" as I would expect. Is there a way to force the consensus algorithm to run regardless of the size of the sequences? I couldn't find such an option documented anywhere. As a workaround, I tried to add an "N" * 20 prefix to all sequences, but now I'm occasionally getting strange results such as: Reads: NNNNNNNNNNNNNNNNNNNNTTTTTTTTTTTTTTTTTTTTTAG NNNNNNNNNNNNNNNNNNNNTTTTTTTTTTTTTTTTTTTAG NNNNNNNNNNNNNNNNNNNNTTTTTTTTTTTTTTTTTTTTTAG NNNNNNNNNNNNNNNNNNNNTTTTTTTTTTTTTTTTTTAG Consensus alignment: NNNNNNNNNNNNNNNNNNNNTTTTTTTTTTTTTTTTTTTTNNNNNNNNNNNNNNNNNNNN--TTTTTTTTTTTTTTTTTTTAG ........................................TAG ....................**..................... ....................TT..................... ...................**N.................... In case this gets wrapped, the idea is that the output of the consensus alignment contains (unexpectedly) more than 1 initial run of Ns. I tried to do reAlignment() with a bandwidth of 20, but it doesn't always fix it. Is the 20 1- or 2-sided? Note- if I were to use real bases instead of Ns, then it would become nontrivial to remove them from the consensus sequence, because they might get mixed up with the real sequence. Is there a way to use seqan to do the consensus on short sequences as well? 2. The second problem I noticed is that the alignments are not always end-to-end. This is usually seen only when the tails are homopolymers: Reads: TTTTTTTTTTTTTTTTTTTTGAA TTTTTTTTTTTTTTTTTTTGAGA TTTTTTTTTTTTTTTTTTTTGAGA TTTTTTTTTTTTTTTTTTTGAGA TTTTTTTTTTTTTTTTTTTGAGA TTTTTTTTTTTTTTTTTTTGAGA Consensus alignment: TTTTTTTTTTTTTTTTTTTTGAGA ......................A ........................ ....................... ....................... ....................... ....................... ^ - note the spaces here Here, I would have hoped the consensus to be the sequence which occurs 4 times, with one less T than the in the largest sequence. As before, I can potentially work around this by adding a common homopolymer prefix and suffix, then removing it from the output: Reads: CCCCCTTTTTTTTTTTTTTTTTTTTGAACCCCC CCCCCTTTTTTTTTTTTTTTTTTTGAGACCCCC CCCCCTTTTTTTTTTTTTTTTTTTTGAGACCCCC CCCCCTTTTTTTTTTTTTTTTTTTGAGACCCCC CCCCCTTTTTTTTTTTTTTTTTTTGAGACCCCC CCCCCTTTTTTTTTTTTTTTTTTTGAGACCCCC Consensus alignment: (note: one less T) CCCCC-TTTTTTTTTTTTTTTTTTTGAGACCCCC .....T.....................*...... .....*............................ .....T............................ .....*............................ .....*............................ .....*............................ However, this works ok only if the homopolymer I add doesn't get mixed up with the rest of the input sequences. I wonder if there is a way to get seqan to do end-to-end (re-)alignment, with no free end gaps. Thanks, Matei From hansenlo@stanford.edu Fri Oct 30 04:22:28 2015 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.85) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Zs0Gq-002J9X-4K>; Fri, 30 Oct 2015 04:22:28 +0100 Received: from smtp2.stanford.edu ([171.67.219.82] helo=smtp.stanford.edu) by relay1.zedat.fu-berlin.de (Exim 4.85) for seqan-dev@lists.fu-berlin.de with esmtps (envelope-from ) id <1Zs0Gp-003j8G-GY>; Fri, 30 Oct 2015 04:22:28 +0100 Received: from codegreen2.stanford.edu (dlp-lb.stanford.edu [171.67.224.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id ABA10341633 for ; Thu, 29 Oct 2015 20:22:24 -0700 (PDT) Received: from codegreen2.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen2.stanford.edu (Postfix) with ESMTP id 93FF962 for ; Thu, 29 Oct 2015 20:22:24 -0700 (PDT) Received: from pps02-smtp.stanford.edu (pps02-smtp.stanford.edu [171.67.214.168]) by codegreen2.stanford.edu (Postfix) with ESMTP id 8840C62 for ; Thu, 29 Oct 2015 20:22:24 -0700 (PDT) Received: from pps.filterd (pps02-smtp.stanford.edu [127.0.0.1]) by pps02-smtp.stanford.edu (8.15.0.59/8.15.0.59) with SMTP id t9U3JWGk028144 for ; Thu, 29 Oct 2015 20:22:24 -0700 Received: from smtp.stanford.edu (smtp3.stanford.edu [171.67.219.83]) by pps02-smtp.stanford.edu with ESMTP id 1xr5by5m7s-1 for ; Thu, 29 Oct 2015 20:22:24 -0700 Received: from [171.65.76.190] (l302-ubuntubox.stanford.edu [171.65.76.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hansenlo) by smtp.stanford.edu (Postfix) with ESMTPSA id 3E8A2101BA6 for ; Thu, 29 Oct 2015 20:22:24 -0700 (PDT) Message-ID: <5632E289.5060204@stanford.edu> Date: Thu, 29 Oct 2015 20:22:49 -0700 From: Loren Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: seqan-dev@lists.fu-berlin.de Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-30_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510300062 X-Originating-IP: 171.67.219.82 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1446175348-00000D05-642B069F/0/0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.499465, version=1.2.4 X-Spam-Flag: NO X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS X-Spam-Checker-Version: SpamAssassin 3.4.1 on Tokelau.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] Reverse Complement and Consensus Sequence X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.16 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 03:22:28 -0000 Hi, Thank you for providing such a useful library. I am a new user and am interesting in using the consensus alignment functionality, obtaining the consensus sequence for a collection of NGS reads. I have run into a small problem I am not sure how to solve. I am able to run the example code provided and obtain the consensus sequence using the 5 example sequences provided. However when I reverse complement one of the sequences and run the example again the reverse complimented sequence does not appear to align and no longer appears in the alignment output. Here is the code snippet where I make the only change from the example provided. appendRead(store, "AATGGATGGCAAAATAGTTGTTCCATGAATACATCTCTAAAGAGCTTT"); appendRead(store, "AAAGTAGTTGTTCCATGAATACATCTCTAAAGAGCTTTGATGCTAATTT"); //appendRead(store, "AGTTGTCCATGAATACATCTCTAAAGAGCTTTGATGCTAATTTAGTCAATTTTCAATACTGTA"); appendRead(store, "TACAGTATTGAAAATTGACTAAATTAGCATCAAAGCTCTTTAGAGATGTATTCATGGACAACT"); //I replace the 3rd sequence with its reverse complement. appendRead(store, "ACATCTCTTAAAGAGCTTTGATGCTAATTTAGTCAAATT"); appendRead(store, "AGAGCTTTGATGCTAATTTAGTCAAATTTTCAATACTGTACAATCTTCTCTAG"); The output I get when I run the code is: Final alignment AATGGATGGCAAAATAGTTGTTCCATGAATACATCTC-TAAAGAGCTTTGATGCTAATTTAGTCAAATTTTCAATACTGT .....................................*........... ...G.......................*...................... .......T............................... ....................................... The reverse complemented sequence does not appear to have been aligned. My inclination is to think I am missing something trivial but I do not know what that is. I very much appreciate your time and your help. Best, Loren From eik.dahms@gmail.com Fri Oct 30 13:21:13 2015 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.85) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Zs8gC-002rR4-Ot>; Fri, 30 Oct 2015 13:21:12 +0100 Received: from mail-wi0-f169.google.com ([209.85.212.169]) by relay1.zedat.fu-berlin.de (Exim 4.85) for seqan-dev@lists.fu-berlin.de with esmtps (envelope-from ) id <1Zs8gC-0012Cv-Lw>; Fri, 30 Oct 2015 13:21:12 +0100 Received: by wikq8 with SMTP id q8so9791816wik.1 for ; Fri, 30 Oct 2015 05:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=NA60JOgTnKaMHWbv9lXSN3VU+lpwQpVkYYVgq9w/Nr0=; b=gJlKG44IxD3TB9YEjAP+xpEmYqWym3CqpzgkUxdO6wF2hlWQmH0uMu6UJjlsYfMuiD QR/0zgWHKCdiHGEB4vh2sbVHa4QRySj6wKvgv+24sZi3gJvYOck1Noi3ksYHfGAAlhfY s+biuPG8+QbpoEMaPjBgCrHfhmRf2tGfrCwvcFV+9774BUdXNllRgJTStQ0oiBuYrWZI hEMBJsMvq/HEDCfDU/3P3VpT4NU3Mt7mLsp/0vDPFPbf/yMkxtE6JNBuIJXcsn2WwNf5 Rqnlc/vViU9QllNLcCksArea332xKhG7+CFx3/v0ER9ekfJwm3zDyx/R4A3rd83QnYSc s2vQ== X-Received: by 10.194.91.143 with SMTP id ce15mr8948850wjb.93.1446207671098; Fri, 30 Oct 2015 05:21:11 -0700 (PDT) MIME-Version: 1.0 From: Eik Dahms Date: Fri, 30 Oct 2015 12:21:01 +0000 Message-ID: To: seqan-dev@lists.fu-berlin.de Content-Type: multipart/mixed; boundary=047d7bf0dac081ffc30523517688 X-Originating-IP: 209.85.212.169 X-ZEDAT-Hint: A X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1446207672-00000D05-473824DF/0/0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.003346, version=1.2.4 X-Spam-Flag: NO X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_PASS X-Spam-Checker-Version: SpamAssassin 3.4.1 on Niue.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] bug report readSequence() X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.16 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 12:21:13 -0000 --047d7bf0dac081ffc30523517688 Content-Type: multipart/alternative; boundary=047d7bf0dac081ffbf0523517686 --047d7bf0dac081ffbf0523517686 Content-Type: text/plain; charset=UTF-8 Dear all, i recently upgraded sequan from 1.4.0 to 2.0.0. I did not change my code. When i now try to run the program i get the following allocation error when i try to read a sequence via readSequence() from a FaiIndex: /seqan/basic/basic_exception.h:368 FAILED! (Uncaught exception of type std::bad_alloc: std::bad_alloc) This error occurs only on my laptop with 4GB RAM. When i run the program on a Server with 500GB RAM - it works. It seems that the memory that is allocated, for the string that the sequence is read in, is to high. I appended the stacktrace from gnu debugger. Thanks in advance ! Eik --047d7bf0dac081ffbf0523517686 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

i recently upgraded sequan fr= om 1.4.0 to 2.0.0. I did not change my code.=C2=A0

When i now try to run the program =C2=A0i get the following allocation err= or when i try to read a sequence via readSequence() from a FaiIndex:
<= div>
/seqan/basic/basic_exception.h:368 FAILED! =C2=A0(U= ncaught exception of type std::bad_alloc: std::bad_alloc)
<= br>
This error occurs only on my laptop with 4GB RAM. When i run = the program on a Server with 500GB RAM - it works.

It seems that the memory that is allocated, for the string that the sequen= ce is read in, is to high.

I appended the stacktra= ce from gnu debugger. =C2=A0

Thanks in advance !
Eik


--047d7bf0dac081ffbf0523517686-- --047d7bf0dac081ffc30523517688 Content-Type: text/plain; charset=US-ASCII; name="gdb_stacktrace.txt" Content-Disposition: attachment; filename="gdb_stacktrace.txt" Content-Transfer-Encoding: base64 Content-ID: <150b8ab8d1599de19191> X-Attachment-Id: 150b8ab8d1599de19191 IzAgIDB4MDAwMDdmZmZmNjc2ZWNjOSBpbiBfX0dJX3JhaXNlIChzaWc9c2lnQGVudHJ5PTYpIGF0 IC4uL25wdGwvc3lzZGVwcy91bml4L3N5c3YvbGludXgvcmFpc2UuYzo1NgojMSAgMHgwMDAwN2Zm ZmY2NzcyMGQ4IGluIF9fR0lfYWJvcnQgKCkgYXQgYWJvcnQuYzo4OQojMiAgMHgwMDAwMDAwMDAw NDNiYmRjIGluIGZhaWwgKCkgYXQgL2hvbWUvZWRhaG1zL0FsZ0Jpby90YXhhdG9yLXRrL2luY2x1 ZGVzLWV4dGVybmFsL3NlcWFuL2Jhc2ljL2RlYnVnX3Rlc3Rfc3lzdGVtLmg6MTcxNQojMyAgc2Vx YW46Omdsb2JhbEV4Y2VwdGlvbkhhbmRsZXIgKCkgYXQgL2hvbWUvZWRhaG1zL0FsZ0Jpby90YXhh dG9yLXRrL2luY2x1ZGVzLWV4dGVybmFsL3NlcWFuL2Jhc2ljL2Jhc2ljX2V4Y2VwdGlvbi5oOjM2 OAojNCAgMHgwMDAwN2ZmZmY3MDc4ODM2IGluID8/ICgpIGZyb20gL3Vzci9saWIveDg2XzY0LWxp bnV4LWdudS9saWJzdGRjKysuc28uNgojNSAgMHgwMDAwN2ZmZmY3MDc4ODYzIGluIHN0ZDo6dGVy bWluYXRlKCkgKCkgZnJvbSAvdXNyL2xpYi94ODZfNjQtbGludXgtZ251L2xpYnN0ZGMrKy5zby42 CiM2ICAweDAwMDA3ZmZmZjcwNzhhYTIgaW4gX19jeGFfdGhyb3cgKCkgZnJvbSAvdXNyL2xpYi94 ODZfNjQtbGludXgtZ251L2xpYnN0ZGMrKy5zby42CiM3ICAweDAwMDA3ZmZmZjcwNzhmOGQgaW4g b3BlcmF0b3IgbmV3KHVuc2lnbmVkIGxvbmcpICgpIGZyb20gL3Vzci9saWIveDg2XzY0LWxpbnV4 LWdudS9saWJzdGRjKysuc28uNgojOCAgMHgwMDAwMDAwMDAwNDNiOWIwIGluIGFsbG9jYXRlPHNl cWFuOjpTdHJpbmc8c2VxYW46OlNpbXBsZVR5cGU8dW5zaWduZWQgY2hhciwgc2VxYW46OkRuYTVf Piwgc2VxYW46OkFsbG9jPD4gPiwgc2VxYW46OlNpbXBsZVR5cGU8dW5zaWduZWQgY2hhciwgc2Vx YW46OkRuYTVfPiwgbG9uZyB1bnNpZ25lZCBpbnQsIHNlcWFuOjpBbGxvY2F0ZVN0b3JhZ2VfPiAo CiAgICBjb3VudD08b3B0aW1pemVkIG91dD4sIGRhdGE9QDB4N2ZmZmZmZmZjYWUwOiAweDApIGF0 IC9ob21lL2VkYWhtcy9BbGdCaW8vdGF4YXRvci10ay9pbmNsdWRlcy1leHRlcm5hbC9zZXFhbi9i YXNpYy9hbGxvY2F0b3JfaW50ZXJmYWNlLmg6MjI3CiM5ICBfYWxsb2NhdGVTdG9yYWdlPHNlcWFu OjpTaW1wbGVUeXBlPHVuc2lnbmVkIGNoYXIsIHNlcWFuOjpEbmE1Xz4sIHZvaWQsIHVuc2lnbmVk IGxvbmc+IChuZXdfY2FwYWNpdHk9MTQ4NjU0Nzc5OTMsIG1lPS4uLikgYXQgL2hvbWUvZWRhaG1z L0FsZ0Jpby90YXhhdG9yLXRrL2luY2x1ZGVzLWV4dGVybmFsL3NlcWFuL3NlcXVlbmNlL3N0cmlu Z19hbGxvYy5oOjM2MAojMTAgX3JlYWxsb2NhdGVTdG9yYWdlPHNlcWFuOjpTaW1wbGVUeXBlPHVu c2lnbmVkIGNoYXIsIHNlcWFuOjpEbmE1Xz4sIHNlcWFuOjpBbGxvYzw+LCBsb25nIHVuc2lnbmVk IGludD4gKG5ld19jYXBhY2l0eT0xNDg2NTQ3Nzk5MywgbWU9Li4uKQogICAgYXQgL2hvbWUvZWRh aG1zL0FsZ0Jpby90YXhhdG9yLXRrL2luY2x1ZGVzLWV4dGVybmFsL3NlcWFuL3NlcXVlbmNlL3N0 cmluZ19iYXNlLmg6MTUwOQojMTEgX3JlYWxsb2NhdGVTdG9yYWdlPHNlcWFuOjpTaW1wbGVUeXBl PHVuc2lnbmVkIGNoYXIsIHNlcWFuOjpEbmE1Xz4sIHNlcWFuOjpBbGxvYzw+LCBsb25nIHVuc2ln bmVkIGludD4gKG5ld19jYXBhY2l0eT08b3B0aW1pemVkIG91dD4sIG1lPS4uLikKICAgIGF0IC9o b21lL2VkYWhtcy9BbGdCaW8vdGF4YXRvci10ay9pbmNsdWRlcy1leHRlcm5hbC9zZXFhbi9zZXF1 ZW5jZS9zdHJpbmdfYmFzZS5oOjE1NTQKIzEyIHNlcWFuOjpfcmVzZXJ2ZVN0b3JhZ2U8c2VxYW46 OlNpbXBsZVR5cGU8dW5zaWduZWQgY2hhciwgc2VxYW46OkRuYTVfPiwgc2VxYW46OkFsbG9jPD4s IGxvbmcgdW5zaWduZWQgaW50LCBzZXFhbjo6VGFnR2VuZXJvdXNfPihzZXFhbjo6U3RyaW5nPHNl cWFuOjpTaW1wbGVUeXBlPHVuc2lnbmVkIGNoYXIsIHNlcWFuOjpEbmE1Xz4sIHNlcWFuOjpBbGxv Yzx2b2lkPiA+ICYsIHVuc2lnbmVkIGxvbmcpIChzZXE9Li4uLCBuZXdfY2FwYWNpdHk9PG9wdGlt aXplZCBvdXQ+LCB0YWc9Li4uKSBhdCAvaG9tZS9lZGFobXMvQWxnQmlvL3RheGF0b3ItdGsvaW5j bHVkZXMtZXh0ZXJuYWwvc2VxYW4vc2VxdWVuY2Uvc3RyaW5nX2Jhc2UuaDoxNjU2CiMxMyAweDAw MDAwMDAwMDA0NjUwMDEgaW4gcmVzZXJ2ZTxzZXFhbjo6U2ltcGxlVHlwZTx1bnNpZ25lZCBjaGFy LCBzZXFhbjo6RG5hNV8+LCBzZXFhbjo6QWxsb2M8PiwgbG9uZyB1bnNpZ25lZCBpbnQsIHNlcWFu OjpUYWdHZW5lcm91c18+IChuZXdfY2FwYWNpdHk9PG9wdGltaXplZCBvdXQ+LCBzZXE9Li4uLCB0 YWc9Li4uKQogICAgYXQgL2hvbWUvZWRhaG1zL0FsZ0Jpby90YXhhdG9yLXRrL2luY2x1ZGVzLWV4 dGVybmFsL3NlcWFuL3NlcXVlbmNlL3N0cmluZ19iYXNlLmg6MTY3NAojMTQgcmVzZXJ2ZTxzZXFh bjo6U3RyaW5nPHNlcWFuOjpTaW1wbGVUeXBlPHVuc2lnbmVkIGNoYXIsIHNlcWFuOjpEbmE1Xz4s IHNlcWFuOjpBbGxvYzw+ID4sIGxvbmcgdW5zaWduZWQgaW50PiAobmV3X2NhcGFjaXR5PTxvcHRp bWl6ZWQgb3V0PiwgbWU9Li4uKQogICAgYXQgL2hvbWUvZWRhaG1zL0FsZ0Jpby90YXhhdG9yLXRr L2luY2x1ZGVzLWV4dGVybmFsL3NlcWFuL3NlcXVlbmNlL3NlcXVlbmNlX2ludGVyZmFjZS5oOjEz MzYKIzE1IHJlc2VydmVDaHVuazxzZXFhbjo6U2ltcGxlVHlwZTx1bnNpZ25lZCBjaGFyLCBzZXFh bjo6RG5hNV8+LCBzZXFhbjo6QWxsb2M8PiwgbG9uZyB1bnNpZ25lZCBpbnQ+IChzaXplPTxvcHRp bWl6ZWQgb3V0Piwgc3RyPS4uLikKICAgIGF0IC9ob21lL2VkYWhtcy9BbGdCaW8vdGF4YXRvci10 ay9pbmNsdWRlcy1leHRlcm5hbC9zZXFhbi9zZXF1ZW5jZS9zdHJpbmdfYmFzZS5oOjE5NTYKIzE2 IF9yZWFkVW50aWw8c2VxYW46OlN0cmluZzxzZXFhbjo6U2ltcGxlVHlwZTx1bnNpZ25lZCBjaGFy LCBzZXFhbjo6RG5hNV8+LCBzZXFhbjo6QWxsb2M8PiA+LCBzZXFhbjo6SXRlcjxjb25zdCBzZXFh bjo6U3RyaW5nPGNoYXIsIHNlcWFuOjpNTWFwPD4gPiwgc2VxYW46OkFkYXB0b3JJdGVyYXRvcjxj aGFyIGNvbnN0Kiwgc2VxYW46OlRhZzxzZXFhbjo6RGVmYXVsdF8+ID4gPiwgc2VxYW46OkNvdW50 RG93bkZ1bmN0b3I8c2VxYW46Ok5vdEZ1bmN0b3I8c2VxYW46Ok9yRnVuY3RvcjxzZXFhbjo6T3JG dW5jdG9yPHNlcWFuOjpFcXVhbHNDaGFyPCcgJz4sIHNlcWFuOjpFcXVhbHNDaGFyPCdcMDExJz4g Piwgc2VxYW46Ok9yRnVuY3RvcjxzZXFhbjo6RXF1YWxzQ2hhcjwnXDAxMic+LCBzZXFhbjo6RXF1 YWxzQ2hhcjwnXDAxNSc+ID4gPiA+ID4sIHNlcWFuOjpPckZ1bmN0b3I8c2VxYW46Ok9yRnVuY3Rv cjxzZXFhbjo6RXF1YWxzQ2hhcjwnICc+LCBzZXFhbjo6RXF1YWxzQ2hhcjwnXDAxMSc+ID4sIHNl cWFuOjpPckZ1bmN0b3I8c2VxYW46OkVxdWFsc0NoYXI8J1wwMTInPiwgc2VxYW46OkVxdWFsc0No YXI8J1wwMTUnPiA+ID4sIGNoYXIgY29uc3QsIHNlcWFuOjpTaW1wbGVUeXBlPHVuc2lnbmVkIGNo YXIsIHNlcWFuOjpEbmE1Xz4gPiAoaWdub3JlRnVuY3Rvcj08c3ludGhldGlzY2hlciBaZWlnZXI+ LCBzdG9wRnVuY3Rvcj08c3ludGhldGlzY2hlciBaZWlnZXI+LCBpdGVyPTxzeW50aGV0aXNjaGVy IFplaWdlcj4sIHRhcmdldD0uLi4pCiAgICBhdCAvaG9tZS9lZGFobXMvQWxnQmlvL3RheGF0b3It dGsvaW5jbHVkZXMtZXh0ZXJuYWwvc2VxYW4vc3RyZWFtL3Rva2VuaXphdGlvbi5oOjMwOAojMTcg cmVhZFVudGlsPHNlcWFuOjpTdHJpbmc8c2VxYW46OlNpbXBsZVR5cGU8dW5zaWduZWQgY2hhciwg c2VxYW46OkRuYTVfPiwgc2VxYW46OkFsbG9jPD4gPiwgc2VxYW46Okl0ZXI8Y29uc3Qgc2VxYW46 OlN0cmluZzxjaGFyLCBzZXFhbjo6TU1hcDw+ID4sIHNlcWFuOjpBZGFwdG9ySXRlcmF0b3I8Y2hh ciBjb25zdCosIHNlcWFuOjpUYWc8c2VxYW46OkRlZmF1bHRfPiA+ID4sIHNlcWFuOjpDb3VudERv d25GdW5jdG9yPHNlcWFuOjpOb3RGdW5jdG9yPHNlcWFuOjpPckZ1bmN0b3I8c2VxYW46Ok9yRnVu Y3RvcjxzZXFhbjo6RXF1YWxzQ2hhcjwnICc+LCBzZXFhbjo6RXF1YWxzQ2hhcjwnXDAxMSc+ID4s IHNlcWFuOjpPckZ1bmN0b3I8c2VxYW46OkVxdWFsc0NoYXI8J1wwMTInPiwgc2VxYW46OkVxdWFs c0NoYXI8J1wwMTUnPiA+ID4gPiA+LCBzZXFhbjo6T3JGdW5jdG9yPHNlcWFuOjpPckZ1bmN0b3I8 c2VxYW46OkVxdWFsc0NoYXI8JyAnPiwgc2VxYW46OkVxdWFsc0NoYXI8J1wwMTEnPiA+LCBzZXFh bjo6T3JGdW5jdG9yPHNlcWFuOjpFcXVhbHNDaGFyPCdcMDEyJz4sIHNlcWFuOjpFcXVhbHNDaGFy PCdcMDE1Jz4gPiA+ID4gKGlnbm9yZUZ1bmN0b3I9PHN5bnRoZXRpc2NoZXIgWmVpZ2VyPiwgCiAg ICBzdG9wRnVuY3Rvcj08c3ludGhldGlzY2hlciBaZWlnZXI+LCBpdGVyPTxzeW50aGV0aXNjaGVy IFplaWdlcj4sIHRhcmdldD0uLi4pIGF0IC9ob21lL2VkYWhtcy9BbGdCaW8vdGF4YXRvci10ay9p bmNsdWRlcy1leHRlcm5hbC9zZXFhbi9zdHJlYW0vdG9rZW5pemF0aW9uLmg6MzMxCiMxOCBzZXFh bjo6cmVhZFJlZ2lvbjxzZXFhbjo6U2ltcGxlVHlwZTx1bnNpZ25lZCBjaGFyLCBzZXFhbjo6RG5h NV8+LCBzZXFhbjo6QWxsb2M8dm9pZD4sIHVuc2lnbmVkIGludCwgaW50LCBpbnQ+IChzdHI9Li4u LCBpbmRleD0uLi4sIHJJRD1ySURAZW50cnk9OTA0NDksIGJlZ2luUG9zPTxvcHRpbWl6ZWQgb3V0 PiwgYmVnaW5Qb3NAZW50cnk9MSwgCiAgICBlbmRQb3M9PG9wdGltaXplZCBvdXQ+LCBlbmRQb3NA ZW50cnk9MikgYXQgL2hvbWUvZWRhaG1zL0FsZ0Jpby90YXhhdG9yLXRrL2luY2x1ZGVzLWV4dGVy bmFsL3NlcWFuL3NlcV9pby9mYWlfaW5kZXguaDozMzMKCgo= --047d7bf0dac081ffc30523517688--