Move 1988-2004 entries into subdirs
We we move 1988-2004 entries from all of a year's winning entries in a single directory to each winner being in their own sub-directory under the given year directory.
This commit is contained in:
Landon Curt Noll committed
1 parent
1e82e8aa3e
commit
d2a42f42e8
478 files changed
No files matched your search
@@ -0,0 +1,60 @@
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
#define a typedef
|
||||
a long N;
|
||||
#define i =m(p(r,o,v),e,d
|
||||
N G,l,I,C,B,A,W,L,S
|
||||
, R,O,c,k,s =
|
||||
80, U=13
|
||||
,T=169; a double P;
|
||||
#define F for(
|
||||
a P*E; a char*w; P sqrt(P); N H(){ F;
|
||||
O=scanf(" %[#]%*[^\n]",&O); ); scanf("%ld%*c",&O);
|
||||
#define D return
|
||||
D O; }
|
||||
|
||||
|
||||
|
||||
#define V =malloc(sizeof(
|
||||
#define M M(
|
||||
#define X +=
|
||||
P M N R){ s= s>=k?printf( "%ld%c"
|
||||
+3*(C<1),s-k, R&7?32:10):s; D R>0?B
|
||||
/2?H():getchar ():R?.9+.7*M R+1):0; }
|
||||
P t(N x,P K){ D x?(x>U?0:t(x+2,K)*(x-1)
|
||||
/x/K)+1/sqrt(K): t(2,K*K/U+1)*K; } N _(N
|
||||
J,N x){ F*(x?&W:& A)=W+J+x; (O=x=W/(J=k*k))
|
||||
||A<J||(( O=2*W/J) &&2*A/J<3); A X A-J+1){ F
|
||||
J*=x+O; S--*B&&x==O ; O=x=!J){ s X x+s; M 0); }
|
||||
W X W-J; S X 2; L X L-J*k+M S%8==B); } D 1; } E
|
||||
p(E J,E x,E O){ F R=T; R--; )O[R]=J[R]+.8*x[R]; D O;
|
||||
} P m(E W,E x,P s){ F R = U; --R; ){ E A=W+R*U; W[R]X s/
|
||||
12; *W X s; *A-=*x++; F; A>W; ){ *A/=*W; F O=R; O; O--)A[O]-=
|
||||
W[O]**A; A-=U; } W X 14; } D*W; } int main(int z,w*y){ N K=s,g; Y;
|
||||
M z); s= B=C=15-H(); s=G= M 8); s=l=M C); G*=g=C%3?1:3; if(I=s=M 8)){ N
|
||||
b=G+9,x=b*340+U,J=b*(l+5), * n V N ) * J ),*j=n+5*b; E h V P)*x),q=h+b,e=q+
|
||||
b; P d=K; F; J--; )n[J]=J<b ? 0: I / 2 ; F; x; )h[--x]=0; s=M x); k=256; C
|
||||
=4-C; B=C/4; s=_(_(T,0),0); F ; -- z ; ){ R=atoi(*++y); c=R>0?K=R,c :-2*R;
|
||||
} z=G/K+1; z X g>z; I++; c++; F ; ++ J<l; ){ P u=0,C,y; E H =e+U,o= H+b*T,r
|
||||
=o-2*T,v=r-T; F; x<G; x++){ p( H , o -T,o); o X T; H X T; q[x]= .7*(q[x-1]+h
|
||||
[x] );
|
||||
} p(H,
|
||||
H,r );
|
||||
F; x;
|
||||
) { E S=
|
||||
e ; w l =
|
||||
" !{ ,;lf6D@"
|
||||
; j X 1-g; F; *++l;
|
||||
){ *S++ =*j; j X*l%3*g-
|
||||
g+*l%5*b-3*b; } y =M x-G);
|
||||
y =M-J)* M-x)+ M-J-1)*y+.01; y=
|
||||
sqrt((u+q[--x]+.1)/y ); o-=T; C i)+
|
||||
#define Z(x)(t(0,(x-C)/y)-l+1e-6*(x-Q))
|
||||
.5; K=M-B); { N f=I,Q=0; F; f-Q>c; ){ P l=0
|
||||
; N H = C+c/2+1; H%=c; H X(f+Q+c-2*H)/2/c*c; l=
|
||||
Z(Q); O=(A-W)*Z(H)/Z(f); _(O,R=B?K>= H:L/k>O+W); *(
|
||||
R?&Q:&f)=H; } Q X f; *S=*j=Q/=2; s=B?s:Q+k; f=Q+n[x/z];
|
||||
n[x/z]=x%z+J%(z*2/g)?f:!putc(x?l[4*g*f/z/z/I-8]:10,stderr);
|
||||
H-=U; F O=156; O--; ){ H--; *H=e[O%U]*e[O/U]/y+.8**H; } C-=Q+.5
|
||||
; y i/.9)-Q-C; p(p(r+T,r,r),H,r); h[x]=.7*h[x]+C*C; u X h[x]; u*=.7
|
||||
; d X C>0?-y:y; } } j X 9; } _(_(x,x),x); } D 0; }
|
||||
@@ -0,0 +1,351 @@
|
||||
Best Utility:
|
||||
|
||||
Bernd Meyer
|
||||
Monash University, Melbourne, Australia
|
||||
1/832 Blackburn Rd
|
||||
Clayton, VIC 3168
|
||||
Australia
|
||||
|
||||
http://byron.csse.monash.edu.au/
|
||||
|
||||
|
||||
Judges' Comments:
|
||||
|
||||
To build:
|
||||
|
||||
make bmeyer
|
||||
|
||||
Compile with the maximum possible optimization on your system.
|
||||
If your system has 80-bit internal representation of floating
|
||||
point values (x86, some Motorola processors) and you want the
|
||||
compressed format to be portable across platforms, you need
|
||||
to set your FPU to use 64 bit mode. See the extra build lines
|
||||
in the Makefile, and read the author's comments below.
|
||||
|
||||
If you cannot work out hwo to get into 64 bit mode, you can
|
||||
try using -ffloat-store if you compile with GCC (this may have
|
||||
a performance penalty). The resulting binary will have a good
|
||||
chance to produce portable files, but due to the resulting
|
||||
double-rounding (first internally to 80 bit, then to 64 bit
|
||||
on writing the value to memory), there is a small but very real
|
||||
chance any given file produced might not be portable.
|
||||
|
||||
To run:
|
||||
|
||||
In a video window (white text on black background):
|
||||
|
||||
./bmeyer < michael.pgm > michael.glic
|
||||
|
||||
Compare the michael.pgm to the screen output.
|
||||
|
||||
To test that you are compressing and decompressing the same way the
|
||||
author was, try
|
||||
|
||||
./bmeyer < lenna.glic
|
||||
|
||||
Also try in a reverse video window:
|
||||
|
||||
./bmeyer < michael.pgm 2>/dev/null | ./bmeyer > new.pgm
|
||||
|
||||
Compare the michael.pgm to the screen output. Compare the new.pgm file
|
||||
to the michael.pgm file.
|
||||
|
||||
Create a large reverse video xterm, say 200 columns wide and try:
|
||||
|
||||
./bmeyer 200 < lavabus.pgm > lavabus.glic
|
||||
|
||||
Produce an even smaller output:
|
||||
|
||||
./bmeyer -2 200 < lavabus.pgm > lavabus.glic2
|
||||
|
||||
Decompress that smaller glic-file:
|
||||
|
||||
./bmeyer -2 200 < lavabus.glic2 > new.pgm
|
||||
|
||||
Compare the new.pgm file to the lavabus.pgm file by viewing
|
||||
them.
|
||||
|
||||
Don't even think of supplying different compression factors (the
|
||||
dashed argument) for compression and decompression! You've been warned.
|
||||
|
||||
|
||||
Selected Author's Comments:
|
||||
|
||||
GLICBAWLS
|
||||
|
||||
A) Function
|
||||
===========
|
||||
|
||||
"GLICBAWLS" stands for:
|
||||
|
||||
"Grey Level Image Compression By Adaptive Weighted Least Squares".
|
||||
|
||||
And that's exactly what this program does --- feed it a .PGM file
|
||||
(either raw [i.e. P5] or ascii [i.e. P2]) on stdin, and it will
|
||||
output a compressed version to stdout. Feed it a compressed file
|
||||
on stdin, and it will decompress it to stdout --- as either raw or
|
||||
ascii .PGM, depending on what format it was compressed from. For
|
||||
example:
|
||||
|
||||
./bmeyer < michael.pgm > michael.glic
|
||||
|
||||
and then
|
||||
|
||||
./bmeyer < michael.glic > michael.decoded.pgm
|
||||
|
||||
As it turns out, glicbawls compresses greyscale images (or, more
|
||||
precisely, "natural" greyscale images) better than any other
|
||||
program I am aware of (with the exception of the not-yet-published
|
||||
program developed for my PhD thesis). Of course, this might take
|
||||
some time, so a progress indicator is provided. To make things
|
||||
more interesting, instead of a boring bar or percentage display,
|
||||
an ASCII rendition of the image being compressed/decompressed is
|
||||
output to stderr (assuming white text on black background). If you
|
||||
have trouble recognizing the image, try squinting at it ;-).
|
||||
|
||||
If you still have trouble, simply use a terminal or xterm with
|
||||
more than 80 columns, and tell glicbawls about it by giving the
|
||||
number of columns as an argument. For example
|
||||
|
||||
./bmeyer 260 <lavabus.pgm >lavabus.glic
|
||||
|
||||
will allow glicbawls to use up to 260 columns, which makes things
|
||||
much more recognizable.
|
||||
|
||||
Still running out of space? Need to compress those images just a
|
||||
tad more? And maybe you can handle some loss due to the
|
||||
compression? If so, you can use glicbawls' "near lossless"
|
||||
compression mode. In that mode, the decoded pixel values are
|
||||
allowed to differ from tbe originals, but there is an upper limit
|
||||
on the magnitude of the difference. For example, if a maximum
|
||||
error of 2 is allowed, an original pixel value of 37 could be
|
||||
decoded as 35,36,37, 38 or 39. In order to use this mode, simply
|
||||
give the maximum allowed error as an argument, with a dash ('-')
|
||||
before it. For example
|
||||
|
||||
./bmeyer -2 < graph.pgm > graph.2.glic
|
||||
|
||||
will compress in a way that allows decompression with a maximum
|
||||
error of two. You can combine both types of arguments, i.e.
|
||||
|
||||
./bmeyer -3 180 < graph.pgm >graph.3.glic
|
||||
|
||||
will compress with a maximum error of 3, using a 180 column
|
||||
terminal for the progress display, and
|
||||
|
||||
./bmeyer -3 180 < graph.3.glic > graph.3maxerr.pgm
|
||||
|
||||
will decompress the result on such a terminal.
|
||||
|
||||
But wait, there is more --- you can also feed glicbawls .PPM files
|
||||
(i.e. colour images), raw or ascii, your choice. Glicbawls will
|
||||
compress and decompress them just fine. However, it only does
|
||||
"reasonably well" on them; It beats PNG easily, but there are
|
||||
certainly programs out there that can compress colour images
|
||||
considerably better. And don't even *think* about using it for
|
||||
so-called "artistic" images (i.e. anything that wasn't scanned
|
||||
from a photo or camera)....
|
||||
|
||||
*****************************************************************
|
||||
* *
|
||||
* WARNING WARNING WARNING WARNING WARNING WARNING WARNING *
|
||||
* *
|
||||
* *
|
||||
* Glicball is rather CPU and FPU intensive. Don't *
|
||||
* run it on anything slow. Things start to be *
|
||||
* usable around 300+MHz, with 600+ being highly *
|
||||
* desirable. *
|
||||
* *
|
||||
*****************************************************************
|
||||
|
||||
|
||||
|
||||
B) Compile Instructions
|
||||
=======================
|
||||
|
||||
Unlike most compression program, glicbawls makes heavy use of
|
||||
floating point maths --- and not all FPUs are created equal. Most
|
||||
importantly, the x86 and 68k FPUs use 80 bit floating point
|
||||
formats internally, while most other processors use IEEE 64 bit
|
||||
formats by default. If not taken care of, this means that a
|
||||
glicbawls file compressed on one CPU cannot generally be
|
||||
decompressed on another.
|
||||
|
||||
Fortunately, just about all current FPUs can be put into IEEE 64
|
||||
bit mode (or at least something close enough for
|
||||
glicbawls). Unfortunately, there is no standard way of doing
|
||||
so. For this reason, the build file contains *three* compile
|
||||
lines; One for machines that already use 64 bit mode by default
|
||||
(most RISC processors), one for linux/x86 machines using libc4,
|
||||
libc5 or glibc2.0, and one for linux/x86 machines using glibc2.1
|
||||
(glibc2.1 no longer exports the __setfpucw function, necessitating
|
||||
the use of gcc inline assembly. *Grumble*).
|
||||
|
||||
So, if you are building on a machine that does not, by default,
|
||||
use IEEE 64 bit floating point doubles, you'll have to define Y to
|
||||
be a command that switches it into that mode. If you fail to do
|
||||
so, your glicbawls executable will still be able to decompress its
|
||||
own compressed files, but you may be unable to exchange files with
|
||||
glicbawls on other machines.
|
||||
|
||||
|
||||
C) Obfuscation
|
||||
==============
|
||||
|
||||
Most of the obfuscation of this program was driven by the
|
||||
desperate struggle to fit all of glicbawls' features into code
|
||||
that fits the IOCCC's size limits. All identifiers names are
|
||||
single-character, which was only possible by ruthless exploitation
|
||||
of scope. There is a function M() that handles nearly all input
|
||||
from stdin, handles all output to stdout, and also recursively
|
||||
calculates one of the mathematical expressions needed for error
|
||||
modelling. There is a function that calculates (A^(-1)*b)*x with A
|
||||
a matrix and b and x being vectors, and does so in a very
|
||||
efficient way --- but one would be hard pressed to find it. There
|
||||
is an arithmetic coder that is even less recognizable. A lot of
|
||||
loop variables don't get initialized, but instead the code is
|
||||
arranged in such a way that they just happen to have the right
|
||||
value when control flow reaches the loops. Lots of functions use
|
||||
the same two global scratch variables. Variables change their
|
||||
meaning all the time, and the differences between compressing and
|
||||
decompressing are handled in rather subtle ways all over the
|
||||
program. The string that holds the ascii values for displaying the
|
||||
progress image doubles as a description on how to find a pixel's
|
||||
causal neighbours. And then there are a few #define's that really
|
||||
are just in there to save a few characters, but as an added
|
||||
"benefit" make the source ever more unreadable.
|
||||
|
||||
In short --- running it through the preprocessor and the
|
||||
pretty-printer will give you something that looks slightly less
|
||||
like line noise and slightly more like a C program, but unless you
|
||||
are a true wizard, it is unlikely to gain you any insights into
|
||||
what is actually going on....[0]
|
||||
|
||||
|
||||
D) Bugs, Assumptions and TODOs
|
||||
==============================
|
||||
|
||||
Glicbawls assumes that characters are 8 bit wide, and that the
|
||||
character set used is ASCII. If one of these isn't true, all hell
|
||||
will break loose.
|
||||
|
||||
The .PGM headers are not checked very thoroughly --- glicbawls
|
||||
will happily try to encode lots of files that it shouldn't
|
||||
touch. The old adage of "garbage in, garbage out" holds in that
|
||||
case. Furthermore, even if glicbawls detects an incorrect input,
|
||||
it fails to provide a meaningful error message, and instead
|
||||
simply aborts.
|
||||
|
||||
When decompressing a near-losslessy encoded image, the maximum
|
||||
allowed error is required as a command line parameter. This should
|
||||
really be saved in the compressed file!
|
||||
|
||||
Glicbawls relies on the decimal representation of all integers
|
||||
having less than 255 digits. While ANSI C does not guarantee this,
|
||||
it seems rather unlikely that anyone in the foreseeable future
|
||||
would use images with 10^255 rows, columns or different levels of
|
||||
grey. Also, it is assumed that any integer used can be cast to a
|
||||
double and back without loss of precision. This limits the number
|
||||
of rows, columns and grey levels to 9 quintillion, which should
|
||||
also be sufficient for the next few years.
|
||||
|
||||
There is a theoretical chance that you might get a division by
|
||||
zero error. You have a MUCH better chance of getting hit by
|
||||
lightning the very second you realize that you just won a few
|
||||
million in a lottery. But if it happens to you, don't say I
|
||||
didn't warn you! Instead, go out and buy a lightning rod and a
|
||||
lottery ticket ;-)
|
||||
|
||||
At one point, a pointer to int is used as the target of a "%1[#]"
|
||||
conversion in a scanf, which makes gcc rather unhappy, but
|
||||
shouldn't really cause anyone any trouble. The same goes for a
|
||||
couple of assignments which are used as truth values.
|
||||
|
||||
|
||||
E) Algorithm
|
||||
============
|
||||
|
||||
An exhaustive explanation of the algorithm used would go beyond
|
||||
the scope of an info file, and would also be quite difficult in
|
||||
pure ASCII, so the following is just a rough outline, and contains
|
||||
some compression-speak...
|
||||
|
||||
The image is handled in scanline ordering. For each pixel, an
|
||||
expected value is calculated by creating a least squares predictor
|
||||
of order 12 based on all of the previously encoded/decoded
|
||||
pixels. However, the contribution of each pixel is weighted
|
||||
according to its Manhattan-distance from the current pixel,
|
||||
D. That weight used is pow(0.8,D). [1][2][3]
|
||||
|
||||
|
||||
In a similar way, the prediction *errors* for all previous pixels
|
||||
are combined --- a weighted average (with weight pow(0.7,D)) of
|
||||
the squares of all previous prediction errors is taken, and the
|
||||
square root of the (appropriately scaled) result is called sigma.
|
||||
|
||||
The predicted value and sigma are then used as the parameters of a
|
||||
Student or t-distribution (which is similar to a normal
|
||||
distribution, but has more weight in the tails), providing a
|
||||
probability distribution for the current pixel.
|
||||
|
||||
Next, the possible interval of values for the current pixel is
|
||||
halved, and through integration of the probability distribution, a
|
||||
probability is calculated for the pixel value being in the lower
|
||||
half. During encoding, the actual value is examined, and the
|
||||
result encoded using an arithmetic coder. During decoding, the
|
||||
arithmetic decoder provides the information which half the actual
|
||||
value is in. In both cases, the interval borders are adjusted
|
||||
accordingly, the arithmetic coder/decoder updated, and the
|
||||
interval halving repeated until the precise value has been
|
||||
en/decoded[4].
|
||||
|
||||
|
||||
[0] Yes, this could be seen as a challenge....
|
||||
[1] Actually, the weight is pow(0.8,D)/s, where s is the sigma
|
||||
used for en/decoding the particular previous pixel. Dividing
|
||||
by s is a rather arbitrary action justified only by the
|
||||
improvement in results. Mathematically, I can only justify
|
||||
dividing by s^2, or not dividing at all....
|
||||
[2] Obviously, these least squares predictors are not calculated
|
||||
from scratch for each pixel. Some clever reuse of earlier
|
||||
results allows O(1) calculation, rather than the
|
||||
O(previous_rows*columns) this description would suggest.
|
||||
[3] As anyone who has ever tried local least squares knows from
|
||||
bitter experience, there is a lot of numerical instability
|
||||
associated with them. So glicbawls adds a bias towards an
|
||||
averaging predictor to the equation system the least squares
|
||||
predictor is calculated from. The weight that is given to
|
||||
this bias is constantly adjusted throughout coding/decoding,
|
||||
thus justifying the 'a' in "glicbawls".
|
||||
[4] In the case of near-lossless coding, the interval is not
|
||||
necessarily *halved*, but rather split at a convenient point
|
||||
(the split points are chosen in such a way as to minimise the
|
||||
expected number of bits needed for coding). Also, the
|
||||
iteration ends as soon as the interval is small enough to
|
||||
guarantee decoding within the requested maximum error.
|
||||
|
||||
####################################################################
|
||||
|
||||
Photo Credit:
|
||||
|
||||
Lavabus was taken by the judge, Landon Curt Noll. Michael was
|
||||
provided by the author. Lenna is a 1972 Playboy centerfold.
|
||||
|
||||
michael.pgm
|
||||
|
||||
The author's Godchild and nephew.
|
||||
|
||||
lavabus.pgm
|
||||
|
||||
A bus that was trapped by lava from Kilauea volcano in
|
||||
Hawaii, USA. Nobody was in the bus at the time, BTW.
|
||||
Photo date: 1981.
|
||||
|
||||
lenna.glic
|
||||
|
||||
A November 1972 Playboy centerfold was scanned in long ago and
|
||||
has been used for image compression research since then. Playboy
|
||||
originally threatened to prosecute unauthorized use, but
|
||||
eventually granted that, having been in use for image compression
|
||||
testing for so long, it was now a useful benchmark. (Note: This
|
||||
picture doesn't show very much.)
|
||||
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,5 @@
|
||||
P5
|
||||
# CREATOR: The GIMP's PNM Filter Version 1.0
|
||||
446 640
|
||||
255
|
||||
VWWYXWWXWVTVXXY\_acggedca^[WSTTVZ_`beghjkmnpprsvxy{}ｅ�件痘囹剿昼�}wtokjiifdb`__^]]^^]\[ZZZXVTSRQRRTTTSROMKKLNNONNNMNNNLKIJJHFFGEFFEDDCCBA?====??ACFHHJLNNPRTUVYY[[\]]__`abadefffghiikmllklomnnpppqqrssttsrqqpqtsttsuvuutsvxxwwyywvz|yzyyyxxz||~~~ヤ㊧у�月克書涛箔蘭楓葡詞試詩麹麹諮書錘諮詩試給滑活�о~}|z{xwvtuuuvwwuuwvvtstrrqqqppponolljihhihegihhgihhgggihhhgghjhhhgfffccb_\\ZXXVRQNKHFCA?><;:9888777776666776666666767889;@DEHMOQTWSPMKLOSXYXYZYUWWVTWWX[^`cddffca_^\XSTTVW_aceeijkmlopqsuwyz~≠ф�藷履撼尸武奄~xvqmjihgc``__^^_^^]]\[[YYXUUTSSQQPOMLJHGFGGIHIIJKLMNMKIIHGGHHGFFFFEEEEDCA@ABBCEFHHIKLOPPSUUWXY\\\^]__aab`defghijkklnmmllonnpqqpqrstsuvutsssttuvvvvvwwvuvtuuxxyyy{z{{zy{{zz|}~~÷×~＝÷ц炎旧轟藷駐舶末粕柏刻瑞随酎試瑞草緒錘麹視糾演援��{yz{xuuuttsuvuvvutvtuttttqqrrpqoomlliljlighiijihfgefedddec`a`^]]ZZZY[YXUTRPNLKIHFDB?=<:998777776667666666666666666777789<AEGHMOOQVVRNKLOPYYXZYWTVWWTVZZ[^acdcdecb`_^ZUSTUW^aacegijmnnqqsvvy~ュ�鵠李棧沱囑総�zwrmjjghfb_`^_``_^]][[\ZYXUTROMKKJHGGEBAABCDDEGHKLLLMLLLKKJIIGHIIIHGGHHGGFFFGGHIHIJKMPRPSSVXYZYZ]^^_a`bdaghghhjikkkmlmlnopnnpqorqsssstuurrsrssvvyywwvvvutvvxzyz{}{||{{}~~}~~~}~}~}＜х演葛去刻酎瀦迄�部駐灯涛涛草崇随血詞結克給渇��ａ~|yywuvtstttuwxwvusstssstursrqrsqoonljliijhhfgfeddcaa^^_\]\\[WVSROMLLMKIIHEDCCBA@?>=;::987777777776666666666556667<977888;AEHIMMNQTVTPLKNPYZXYZWUVXWVW[\[^`dcbcdda__^[USVUU[_befghiklmpqsvwz}ユ㈱諸�棔�椢俣号＋upmihgggdba____]]][YYXYVSNLLHFEEDBA@?=<=>@BCEFILMMMNNOONLKKKIJKLMKJJJJLKKKKKKJLJILMNORRTUUVWXY\]]``aacfdghhijjjijjkmmmnonooprqtsttvttsurstrttuwwwvwwvwwwxxxyy{}}~~}}~|}}~}}~~~＞ｅ演焔血詞瑞枢又楓粕崇藍覧藍蕪涛衷渚訣結牛結���≠~{zzyvxuvwvxwvxvvuutstssqrtssrsrpnnmjhggfdcc`a``]^]\]\ZYZZYZVTOKGCAAA@@@?@?@B@>???>=;:99887666777666666566666666667:878:8;@DHJMNNQTUWQMMMNYZYZZXVUYYXW[^^_`cdbbdddaa_\VTUVVZ_bdeghhklnrquyzy}ｄ㊨賜葺屎撩囗鱒�}wrmkihheedcb^^^^\ZYXVVTPLIFEC@??=<<=<<=>>ACFHLMMNMNOOPPOMMMLMMMMLMMMMNPOOPOMLKKKLNNNOSSRTTTUVVZ]]^_abefdfghjjgihijijjnmnopqqqsssstututtrsssttuvtuuuuuvuvvvxwxz||}}||}|}}~~~~~}~�ｇ�訣旧渚誌髄酎髄草走剿沫覧葡綜渚結穴��㊥у��＝~zyyyyyyywxwxxwvxvusttuuqrsqpqnmmjjfdbb_^^]]\^]\\\\[Z[YZXYXVTQJEA=;:::;;<==?@A@@?@>=<::9977667666666565666565555555667778:>EIKNMMNSVXRNLLNYZYYZYXWYZZZ\___`bdcceddbba^WTUVWZ]`efhhiklnrruwwz{~~ф燕数吏圀尹剳相�ysoljihgfdaa__^]ZYXUTRPLHEA@@?>=<<=>@@BCEHJKMOOOPOPRSQQRPOONMNONMMNNOOQQPQONLLLLLMNOQRTSTTUWVTYZ^]_`bbdbefihgghhiikjkmmnooppqttrututuussrsttsttuuuuuuvvvvwxwxy||z|}~~~~~|{{~~＜＞�焔詩訣結試書諮註飼侭劍�欄糟結糾給���モｄモ≠×||{xzzyxwwvwwxwwwurqqqomlljgfeaa``]^^_\\\[[\\\\\[[ZZYYXYZZXVQJD@;999:;;<>?@AAAAAAA?=;::987666666666666555565555566666778:>EIMNOMNPTVTPNMOVYZY\[\Z[]]]]^^`abdcbdedca`^YTUUVY^`cfgghjlmpqstuy{|ｃ�諮髄曝屎屁�初【tqmiihffda^_^[[ZYVTRPLHECBABCA@AABDFHIKKNPQRRQQRQQQTSSRPRQPOOONNNNNNNQQQOMLLKLKLNOQRPTRSUUUUTUWZ^_`__ab`ddeegifikjjllooooopqrrrrrsuutsrssstvutuuuvwxwvxyyxxzz|}}}~~~~~}}z|~ｂнｇ㊧轄豪級褐轟月試刻当��嵐綜滑滑炎級��＝÷ａ�{zxywyyxvwwvvtssrpplkgfdca_\ZYVSSTVWZ[\[]\YYZZZ[]]]\[[[[\]^\ZVMEA<989::<=>@ABCCBBBA@><;9987666666666666666556665666666778:=DKOPPOOPZVTRNNMVZ[Z[]^\\^^\\]^_aacdcddccb_^ZUTTTV]aabghiklmopqsvvwz|~ｄ�試当囿沺棡�桁{vsokhheea^][[XZYZWVTRLHGGGGHGGFGFGILPRQQRTTUUTSTRRRSRSRRRRRQOOMNMMNNPPQPMLKJIIJLMOPPQRRRQTTUXWZYY]_a^__]``__`ceikjklmpnoqprqoqsssssssusuuuuxwvwxwwuwutwxz{xz{|{}}}~п~|}~~÷ａ~≦��糾�炎給滑括去樗末部綜麹轟給演穴演�≠�~}}}}||xvvuututsrqpoljhfdaa^ZXVTQOLJHGGHJLMSWYZ[\[Y]^]^^aaaa```_^`^ZWMF@;989::;=@A@BDCDCBA?>=;:988866666666666666665556666666788:>EJQPQONOSVVROMNTXZZ[^_\]^^]]^__acddcddcdba`\VTTUUZ_`ddhijkjmnnoptvyzу㈲告履擅｣｣｣�恂紙~vqolhgfc`]\\\ZZ[[ZXWVQPMLNOPONMLKLORTUUUUVVVUTTSSSSTRRRRSRQPPNMLLMMMMOLLLKJIIHJKKLNNNOOPQTUVXV[[WTVY[^b`adcddbbbeiimmooonoqroqrqsttvtutvvtuuwwywwyxxwuxyz{yzyz{}}~÷}}~~~~÷≦演炎滑滑給渇窮щ諮荘酎白髄曙血穴級�怨ャｃ}{zzxxutsrrplikjgdca_\\ZWUQQMJIHEA@?><<<<>CFNV[\^b`^ababbbeba`ca``__[WOHB<9899;;=?ABCEEDCBA@><;:989<766666565666666656665656667779=CJPRQPOOQUVUPMNRY][[^a_]^^^^`aa_addbeedcdaa^XUUUUY^bdcgikmmnnnopuxzxャ�去副泪･･､｢攪劫}sonkigeeb_]]]]\]\\[ZXXUSSUUWURPQOPRUWVVVWVVVUTTSTSSSQRQQRQPPOONKKKLLKKLJKJIHGFGGIJMMLMNOQSRTSRQRTWYYY[]_^ceegggffddhjlkkkmmnopnorstuusrttuuvwwxxwwwwvvywxwy{yyz{|}~~|z~~||~~≠ｇ�血潔糾糾���去署錐髄随暑焔渇��№ム~}zxxqronllhfeb_]\ZWTSQPLLJGEBA?=<;:988777779>DNW^^`bb``abbccb`_`````_^[XQIC>:::9:<>@ABDEFDCBB@>=;:988:766666676666666666666666666779<CJRSSRPNOTTTQNMR]`^]___]^^__bcb``feddfedfcc`ZUUUVY^bdfhiloooprssvyzz|ｅ焔雌圉｣ｦｦ･､椈糸}tpnmlihhfdbb`_````^]\ZZYYZZZWUTSQRRUVWVVUVVUVVUTTTRTQRPPQQPNONNLKIIJJJLKLJJJHGFHJIJJLOQRSTTQOQQSRSTVVUTVXZaadgghhigdflonpqqqqrqqrqruvusuutvwvuvywvuvwvxuwwxyzxxyyyz{{z|{}~~}��褐曙穴訣克括≦㊥�緒血試結�㊥℡�{xvspnkhfca^]YWVSQOLHFDCB@@>=;::988777766666678=DNW]_`dc^`aababbaaab`_``^ZYSJC>;:9:;<>@ABDECDCBA@><;:9887766666666666666666666666666779<CJQUUTQOQSVVSNMOVZ^\__^\\_^^_ab`_cbcefgfffdc]XVUVV]acfhilnoppqrtuuy{z|}＜㍾据棧｣･｢椈昼кurpkjkhggeddbabb`a`Line truncated
|
||||
Reference in new issue
Block a user