diff --git a/demo/cheat.html b/demo/cheat.html deleted file mode 100644 index a56fb50..0000000 --- a/demo/cheat.html +++ /dev/null @@ -1,525 +0,0 @@ - - - - - - - - - - - - - - -
- -
Theoretical Computer Science Cheat Sheet
Definitions Series
f(n)=O(g(n)) iff ∃ positive c, n
0
such that
0 ≤ f(n) ≤ cg(n) ∀n ≥ n
0
.
n
i=1
i =
n(n +1)
2
,
n
i=1
i
2
=
n(n + 1)(2n +1)
6
,
n
i=1
i
3
=
n
2
(n +1)
2
4
.
In general:
n
i=1
i
m
=
1
m +1
(n +1)
m+1
− 1 −
n
i=1
(i +1)
m+1
− i
m+1
− (m +1)i
m
n−1
i=1
i
m
=
1
m +1
m
k=0
m +1
k
B
k
n
m+1−k
.
Geometric series:
n
i=0
c
i
=
c
n+1
− 1
c − 1
,c=1,
∞
i=0
c
i
=
1
1 − c
,
∞
i=1
c
i
=
c
1 − c
, |c| < 1,
n
i=0
ic
i
=
nc
n+2
− (n +1)c
n+1
+ c
(c − 1)
2
,c=1,
∞
i=0
ic
i
=
c
(1 − c)
2
, |c| < 1.
Harmonic series:
H
n
=
n
i=1
1
i
,
n
i=1
iH
i
=
n(n +1)
2
H
n
−
n(n − 1)
4
.
n
i=1
H
i
=(n +1)H
n
− n,
n
i=1
i
m
H
i
=
n +1
m +1

H
n+1
−
1
m +1
.
f(n)=Ω(g(n)) iff ∃ positive c, n
0
such that
f(n) ≥ cg(n) ≥ 0 ∀n ≥ n
0
.
f(n)=Θ(g(n)) iff f(n)=O(g(n)) and
f(n)=Ω(g(n)).
f(n)=o(g(n)) iff lim
n→∞
f(n)/g(n)=0.
lim
n→∞
a
n
= a iff ∀>0, ∃n
0
such that
|a
n
− a| <, ∀n ≥ n
0
.
sup S least b ∈ R such that b ≥ s,
∀s ∈ S.
inf S greatest b ∈ R such that b ≤
s, ∀s ∈ S.
lim inf
n→∞
a
n
lim
n→∞
inf{a
i
| i ≥ n, i ∈ N}.
lim sup
n→∞
a
n
lim
n→∞
sup{a
i
| i ≥ n, i ∈ N}.
n
k
Combinations: Size k sub-
sets of a size n set.
n
k
Stirling numbers (1st kind):
Arrangements of an n ele-
ment set into k cycles.
1.
n
k
=
n!
(n − k)!k!
, 2.
n
k=0
n
k
=2
n
, 3.
n
k
=
n
n − k
,
4.
n
k
=
n
k
n − 1
k − 1
, 5.
n
k
=
n − 1
k
+
n − 1
k − 1
,
6.
n
m

m
k
=
n
k

n − k
m − k
, 7.
n
k=0
r + k
k
=
r + n +1
n
,
8.
n
k=0
k
m
=
n +1
m +1
, 9.
n
k=0
r
k

s
n − k
=
r + s
n
,
10.
n
k
=(−1)
k
k − n − 1
k
, 11.
n
1
=
n
n
=1,
12.
n
2
=2
n−1
− 1, 13.
n
k
= k
n − 1
k
+
n − 1
k − 1
,
n
k
Stirling numbers (2nd kind):
Partitions of an n element
set into k non-empty sets.
n
k
1st order Eulerian numbers:
Permutations π
1
π
2
...π
n
on
{1, 2,...,n} with k ascents.
n
k
2nd order Eulerian numbers.
C
n
Catalan Numbers: Binary
trees with n + 1 vertices.
14.
n
1
=(n − 1)!, 15.
n
2
=(n − 1)!H
n−1
, 16.
n
n
=1, 17.
n
k
≥
n
k
,
18.
n
k
=(n − 1)
n − 1
k
+
n − 1
k − 1
, 19.
n
n − 1
=
n
n − 1
=
n
2
, 20.
n
k=0
n
k
= n!, 21. C
n
=
1
n +1
2n
n
,
22.
n
0
=
n
n − 1
=1, 23.
n
k
=
n
n − 1 − k
, 24.
n
k
=(k +1)
n − 1
k
+(n − k)
n − 1
k − 1
,
25.
0
k
=
1ifk =0,
0 otherwise
26.
n
1
=2
n
− n − 1, 27.
n
2
=3
n
− (n + 1)2
n
+
n +1
2
,
28. x
n
=
n
k=0
n
k

x + k
n
, 29.
n
m
=
m
k=0
n +1
k
(m +1− k)
n
(−1)
k
, 30. m!
n
m
=
n
k=0
n
k

k
n − m
,
31.
n
m
=
n
k=0
n
k

n − k
m
(−1)
n−k−m
k!, 32.
n
0
=1, 33.
n
n
= 0 for n =0,
34.
n
k
=(k +1)
n − 1
k
+(2n − 1 − k)
n − 1
k − 1
, 35.
n
k=0
n
k
=
(2n)
n
2
n
,
36.
x
x − n
=
n
k=0
n
k

x + n − 1 − k
2n
, 37.
n +1
m +1
=
k
n
k

k
m
=
n
k=0
k
m
(m +1)
n−k
,
-
Theoretical Computer Science Cheat Sheet
Identities Cont. Trees
38.
n +1
m +1
=
k
n
k

k
m
=
n
k=0
k
m
n
n−k
= n!
n
k=0
1
k!
k
m
, 39.
x
x − n
=
n
k=0
n
k

x + k
2n
,
40.
n
m
=
k
n
k

k +1
m +1
(−1)
n−k
, 41.
n
m
=
k
n +1
k +1

k
m
(−1)
m−k
,
42.
m + n +1
m
=
m
k=0
k
n + k
k
, 43.
m + n +1
m
=
m
k=0
k(n + k)
n + k
k
,
44.
n
m
=
k
n +1
k +1

k
m
(−1)
m−k
, 45. (n − m)!
n
m
=
k
n +1
k +1

k
m
(−1)
m−k
, for n ≥ m,
46.
n
n − m
=
k
m − n
m + k

m + n
n + k

m + k
k
, 47.
n
n − m
=
k
m − n
m + k

m + n
n + k

m + k
k
,
48.
n
+ m

+ m
=
k
k

n − k
m

n
k
, 49.
n
+ m

+ m
=
k
k

n − k
m

n
k
.
Every tree with n
vertices has n − 1
edges.
Kraft inequal-
ity: If the depths
of the leaves of
a binary tree are
d
1
,...,d
n
:
n
i=1
2
−d
i
≤ 1,
and equality holds
only if every in-
ternal node has 2
sons.
Recurrences
Master method:
T (n)=aT (n/b)+f(n),a≥ 1,b>1
If ∃>0 such that f(n)=O(n
log
b
a−
)
then
T (n)=Θ(n
log
b
a
).
If f(n)=Θ(n
log
b
a
) then
T (n)=Θ(n
log
b
a
log
2
n).
If ∃>0 such that f(n)=Ω(n
log
b
a+
),
and ∃c<1 such that af(n/b) ≤ cf(n)
for large n, then
T (n)=Θ(f(n)).
Substitution (example): Consider the
following recurrence
T
i+1
=2
2
i
· T
2
i
,T
1
=2.
Note that T
i
is always a power of two.
Let t
i
= log
2
T
i
. Then we have
t
i+1
=2
i
+2t
i
,t
1
=1.
Let u
i
= t
i
/2
i
. Dividing both sides of
the previous equation by 2
i+1
we get
t
i+1
2
i+1
=
2
i
2
i+1
+
t
i
2
i
.
Substituting we find
u
i+1
=
1
2
+ u
i
,u
1
=
1
2
,
which is simply u
i
= i/2. So we find
that T
i
has the closed form T
i
=2
i2
i−1
.
Summing factors (example): Consider
the following recurrence
T (n)=3T (n/2) + n, T (1) = 1.
Rewrite so that all terms involving T
are on the left side
T (n) − 3T (n/2) = n.
Now expand the recurrence, and choose
a factor which makes the left side “tele-
scope”
1
T (n) − 3T (n/2) = n
3
T (n/2) − 3T (n/4) = n/2
.
.
.
.
.
.
.
.
.
3
log
2
n−1
T (2) − 3T (1) = 2
Let m = log
2
n. Summing the left side
we get T (n) − 3
m
T (1) = T (n) − 3
m
=
T (n) − n
k
where k = log
2
3 ≈ 1.58496.
Summing the right side we get
m−1
i=0
n
2
i
3
i
= n
m−1
i=0
3
2
i
.
Let c =
3
2
. Then we have
n
m−1
i=0
c
i
= n
c
m
− 1
c − 1
=2n(c
log
2
n
− 1)
=2n(c
(k−1) log
c
n
− 1)
=2n
k
− 2n,
and so T (n)=3n
k
− 2n. Full history re-
currences can often be changed to limited
history ones (example): Consider
T
i
=1+
i−1
j=0
T
j
,T
0
=1.
Note that
T
i+1
=1+
i
j=0
T
j
.
Subtracting we find
T
i+1
− T
i
=1+
i
j=0
T
j
− 1 −
i−1
j=0
T
j
= T
i
.
And so T
i+1
=2T
i
=2
i+1
.
Generating functions:
1. Multiply both sides of the equa-
tion by x
i
.
2. Sum both sides over all i for
which the equation is valid.
3. Choose a generating function
G(x). Usually G(x)=
∞
i=0
x
i
g
i
.
3. Rewrite the equation in terms of
the generating function G(x).
4. Solve for G(x).
5. The coefficient of x
i
in G(x)isg
i
.
Example:
g
i+1
=2g
i
+1,g
0
=0.
Multiply and sum:
i≥0
g
i+1
x
i
=
i≥0
2g
i
x
i
+
i≥0
x
i
.
We choose G(x)=
i≥0
x
i
g
i
. Rewrite
in terms of G(x):
G(x) − g
0
x
=2G(x)+
i≥0
x
i
.
Simplify:
G(x)
x
=2G(x)+
1
1 − x
.
Solve for G(x):
G(x)=
x
(1 − x)(1 − 2x)
.
Expand this using partial fractions:
G(x)=x
2
1 − 2x
−
1
1 − x
= x
2
i≥0
2
i
x
i
−
i≥0
x
i
=
i≥0
(2
i+1
− 1)x
i+1
.
So g
i
=2
i
− 1.
-
Theoretical Computer Science Cheat Sheet
π ≈ 3.14159, e ≈ 2.71828, γ ≈ 0.57721, φ =
1+
√
5
2
≈ 1.61803,
ˆ
φ =
1−
√
5
2
≈−.61803
i 2
i
p
i
General Probability
1 2 2
Bernoulli Numbers (B
i
=0,oddi = 1):
B
0
=1,B
1
= −
1
2
, B
2
=
1
6
, B
4
= −
1
30
,
B
6
=
1
42
, B
8
= −
1
30
, B
10
=
5
66
.
Change of base, quadratic formula:
log
b
x =
log
a
x
log
a
b
,
−b ±
√
b
2
− 4ac
2a
.
Euler’s number e:
e =1+
1
2
+
1
6
+
1
24
+
1
120
+ ···
lim
n→∞
1+
x
n
n
= e
x
.
1+
1
n
n
<e<
1+
1
n
n+1
.
1+
1
n
n
= e −
e
2n
+
11e
24n
2
− O
1
n
3
.
Harmonic numbers:
1,
3
2
,
11
6
,
25
12
,
137
60
,
49
20
,
363
140
,
761
280
,
7129
2520
,...
ln n<H
n
< ln n +1,
H
n
=lnn + γ + O
1
n
.
Factorial, Stirling’s approximation:
1, 2, 6, 24, 120, 720, 5040, 40320, 362880,
...
n!=
√
2πn
n
e
n
1+Θ
1
n

.
Ackermann’s function and inverse:
a(i, j)=
2
j
i =1
a(i − 1, 2) j =1
a(i − 1,a(i, j − 1)) i, j ≥ 2
α(i) = min{j | a(j, j) ≥ i}.
Continuous distributions: If
Pr[a<X<b]=
b
a
p(x) dx,
then p is the probability density function of
X.If
Pr[X<a]=P (a),
then P is the distribution function of X.If
P and p both exist then
P (a)=
a
−∞
p(x) dx.
Expectation: If X is discrete
E
[g(X)] =
x
g(x)Pr[X = x].
If X continuous then
E
[g(X)] =
∞
−∞
g(x)p(x) dx =
∞
−∞
g(x) dP (x).
Variance, standard deviation:
VAR[X]=
E
[X
2
] −
E
[X]
2
,
σ =
VAR[X].
For events A and B:
Pr[A ∨ B] = Pr[A] + Pr[B] − Pr[A ∧ B]
Pr[A ∧ B] = Pr[A] · Pr[B],
iff A and B are independent.
Pr[A|B]=
Pr[A ∧ B]
Pr[B]
For random variables X and Y :
E
[X · Y ]=
E
[X] ·
E
[Y ],
if X and Y are independent.
E
[X + Y ]=
E
[X]+
E
[Y ],
E
[cX]=c
E
[X].
Bayes’ theorem:
Pr[A
i
|B]=
Pr[B|A
i
]Pr[A
i
]
n
j=1
Pr[A
j
]Pr[B|A
j
]
.
Inclusion-exclusion:
Pr
n
i=1
X
i
=
n
i=1
Pr[X
i
]+
n
k=2
(−1)
k+1
i
i
<···<i
k
Pr
k
j=1
X
i
j
.
Moment inequalities:
Pr
|X|≥λ
E
[X]
≤
1
λ
,
Pr
X −
E
[X]
≥ λ · σ
≤
1
λ
2
.
Geometric distribution:
Pr[X = k]=pq
k−1
,q=1− p,
E
[X]=
∞
k=1
kpq
k−1
=
1
p
.
2 4 3
3 8 5
4 16 7
5 32 11
6 64 13
7 128 17
8 256 19
9 512 23
10 1,024 29
11 2,048 31
12 4,096 37
13 8,192 41
14 16,384 43
15 32,768 47
16 65,536 53
17 131,072 59
18 262,144 61
19 524,288 67
20 1,048,576 71
21 2,097,152 73
22 4,194,304 79
23 8,388,608 83
24 16,777,216 89
25 33,554,432 97
26 67,108,864 101
27 134,217,728 103
28 268,435,456 107
Binomial distribution:
Pr[X = k]=
n
k
p
k
q
n−k
,q=1− p,
E
[X]=
n
k=1
k
n
k
p
k
q
n−k
= np.
Poisson distribution:
Pr[X = k]=
e
−λ
λ
k
k!
,
E
[X]=λ.
Normal (Gaussian) distribution:
p(x)=
1
√
2πσ
e
−(x−μ)
2
/2σ
2
,
E
[X]=μ.
The “coupon collector”: We are given a
random coupon each day, and there are n
different types of coupons. The distribu-
tion of coupons is uniform. The expected
number of days to pass before we to col-
lect all n types is
nH
n
.
29 536,870,912 109
30 1,073,741,824 113
31 2,147,483,648 127
32 4,294,967,296 131
Pascal’s Triangle
1
11
121
1331
14641
1 5 10 10 5 1
1 6 15 20 15 6 1
1 7 21 35 35 21 7 1
1 8 28 56 70 56 28 8 1
1 9 36 84 126 126 84 36 9 1
1 10 45 120 210 252 210 120 45 10 1
-
Theoretical Computer Science Cheat Sheet
Trigonometry Matrices More Trig.
A
c
θ
B
a
b
C
(0,-1)
(0,1)
(-1,0) (1,0)
(cos θ, sin θ)
Pythagorean theorem:
C
2
= A
2
+ B
2
.
Definitions:
sin a = A/C, cos a = B/C,
csc a = C/A, sec a = C/B,
tan a =
sin a
cos a
=
A
B
, cot a =
cos a
sin a
=
B
A
.
Area, radius of inscribed circle:
1
2
AB,
AB
A + B + C
.
Identities:
sin x =
1
csc x
, cos x =
1
sec x
,
tan x =
1
cot x
, sin
2
x + cos
2
x =1,
1 + tan
2
x = sec
2
x, 1 + cot
2
x = csc
2
x,
sin x = cos
π
2
− x
, sin x = sin(π − x),
cos x = − cos(π − x), tan x = cot
π
2
− x
,
cot x = − cot(π − x), csc x = cot
x
2
− cot x,
sin(x ± y) = sin x cos y ± cos x sin y,
cos(x ± y) = cos x cos y ∓ sin x sin y,
tan(x ± y)=
tan x ± tan y
1 ∓ tan x tan y
,
cot(x ± y)=
cot x cot y ∓ 1
cot x ± cot y
,
sin 2x = 2 sin x cos x, sin 2x =
2 tan x
1 + tan
2
x
,
cos 2x = cos
2
x − sin
2
x, cos 2x = 2 cos
2
x − 1,
cos 2x =1− 2 sin
2
x, cos 2x =
1 − tan
2
x
1 + tan
2
x
,
tan 2x =
2 tan x
1 − tan
2
x
, cot 2x =
cot
2
x − 1
2 cot x
,
sin(x + y) sin(x − y) = sin
2
x − sin
2
y,
cos(x + y) cos(x − y) = cos
2
x − sin
2
y.
Euler’s equation:
e
ix
= cos x + i sin x, e
iπ
= −1.
Multiplication:
C = A · B, c
i,j
=
n
k=1
a
i,k
b
k,j
.
Determinants: det A =0iffA is non-singular.
det A · B = det A · det B,
det A =
π
n
i=1
sign(π)a
i,π(i)
.
2 × 2 and 3 × 3 determinant:
ab
cd
= ad − bc,
abc
def
ghi
= g
bc
ef
− h
ac
df
+ i
ab
de
=
aei + bfg + cdh
− ceg − fha− ibd.
Permanents:
perm A =
π
n
i=1
a
i,π(i)
.
A
a
c
h
b
B
C
Law of cosines:
c
2
= a
2
+b
2
−2ab cos C.
Area:
A =
1
2
hc,
=
1
2
ab sin C,
=
c
2
sin A sin B
2 sin C
.
Heron’s formula:
A =
√
s · s
a
· s
b
· s
c
,
s =
1
2
(a + b + c),
s
a
= s − a,
s
b
= s − b,
s
c
= s − c.
More identities:
sin
x
2
=
1 − cos x
2
,
cos
x
2
=
1 + cos x
2
,
tan
x
2
=
1 − cos x
1 + cos x
,
=
1 − cos x
sin x
,
=
sin x
1 + cos x
,
cot
x
2
=
1 + cos x
1 − cos x
,
=
1 + cos x
sin x
,
=
sin x
1 − cos x
,
sin x =
e
ix
− e
−ix
2i
,
cos x =
e
ix
+ e
−ix
2
,
tan x = −i
e
ix
− e
−ix
e
ix
+ e
−ix
,
= −i
e
2ix
− 1
e
2ix
+1
,
sin x =
sinh ix
i
,
cos x = cosh ix,
tan x =
tanh ix
i
.
Hyperbolic Functions
Definitions:
sinh x =
e
x
− e
−x
2
, cosh x =
e
x
+ e
−x
2
,
tanh x =
e
x
− e
−x
e
x
+ e
−x
, csch x =
1
sinh x
,
sech x =
1
cosh x
, coth x =
1
tanh x
.
Identities:
cosh
2
x − sinh
2
x =1, tanh
2
x + sech
2
x =1,
coth
2
x − csch
2
x =1, sinh(−x)=− sinh x,
cosh(−x) = cosh x, tanh(−x)=− tanh x,
sinh(x + y) = sinh x cosh y + cosh x sinh y,
cosh(x + y) = cosh x cosh y + sinh x sinh y,
sinh 2x = 2 sinh x cosh x,
cosh 2x = cosh
2
x + sinh
2
x,
cosh x + sinh x = e
x
, cosh x − sinh x = e
−x
,
(cosh x + sinh x)
n
= cosh nx + sinh nx, n ∈ Z,
2 sinh
2
x
2
= cosh x − 1, 2 cosh
2
x
2
= cosh x +1.
θ sin θ cos θ tan θ
00 1 0
π
6
1
2
√
3
2
√
3
3
π
4
√
2
2
√
2
2
1
π
3
√
3
2
1
2
√
3
π
2
10∞
...in mathematics
you don’t under-
stand things, you
just get used to
them.
– J. von Neumann
v2.02
c
1994 by Steve Seiden
sseiden@acm.org
http://www.csc.lsu.edu/~seiden
-
Theoretical Computer Science Cheat Sheet
Number Theory Graph Theory
The Chinese remainder theorem: There ex-
ists a number C such that:
C ≡ r
1
mod m
1
.
.
.
.
.
.
.
.
.
C ≡ r
n
mod m
n
if m
i
and m
j
are relatively prime for i = j.
Euler’s function: φ(x) is the number of
positive integers less than x relatively
prime to x.If
n
i=1
p
e
i
i
is the prime fac-
torization of x then
φ(x)=
n
i=1
p
e
i
−1
i
(p
i
− 1).
Euler’s theorem: If a and b are relatively
prime then
1 ≡ a
φ(b)
mod b.
Fermat’s theorem:
1 ≡ a
p−1
mod p.
The Euclidean algorithm: if a>bare in-
tegers then
gcd(a, b) = gcd(a mod b, b).
If
n
i=1
p
e
i
i
is the prime factorization of x
then
S(x)=
d|x
d =
n
i=1
p
e
i
+1
i
− 1
p
i
− 1
.
Perfect Numbers: x is an even perfect num-
ber iff x =2
n−1
(2
n
−1) and 2
n
−1 is prime.
Wilson’s theorem: n is a prime iff
(n − 1)! ≡−1modn.
M¨obius inversion:
μ(i)=
1ifi =1.
0ifi is not square-free.
(−1)
r
if i is the product of
r distinct primes.
If
G(a)=
d|a
F (d),
then
F (a)=
d|a
μ(d)G
a
d
.
Prime numbers:
p
n
= n ln n + n ln ln n − n + n
ln ln n
ln n
+ O
n
ln n
,
π(n)=
n
ln n
+
n
(ln n)
2
+
2!n
(ln n)
3
+ O
n
(ln n)
4
.
Definitions:
Loop An edge connecting a ver-
tex to itself.
Directed Each edge has a direction.
Simple Graph with no loops or
multi-edges.
Walk A sequence v
0
e
1
v
1
...e
v
.
Trail A walk with distinct edges.
Path A trail with distinct
vertices.
Connected A graph where there exists
a path between any two
vertices.
Component A maximal connected
subgraph.
Tree A connected acyclic graph.
Free tree A tree with no root.
DAG Directed acyclic graph.
Eulerian Graph with a trail visiting
each edge exactly once.
Hamiltonian Graph with a cycle visiting
each vertex exactly once.
Cut A set of edges whose re-
moval increases the num-
ber of components.
Cut-set A minimal cut.
Cut edge A size 1 cut.
k-Connected A graph connected with
the removal of any k − 1
vertices.
k-Tough ∀S ⊆ V,S = ∅ we have
k · c(G − S) ≤|S|.
k-Regular A graph where all vertices
have degree k.
k-Factor A k-regular spanning
subgraph.
Matching A set of edges, no two of
which are adjacent.
Clique A set of vertices, all of
which are adjacent.
Ind. set A set of vertices, none of
which are adjacent.
Vertex cover A set of vertices which
cover all edges.
Planar graph A graph which can be em-
beded in the plane.
Plane graph An embedding of a planar
graph.
v∈V
deg(v)=2m.
If G is planar then n − m + f =2,so
f ≤ 2n − 4,m≤ 3n − 6.
Any planar graph has a vertex with de-
gree ≤ 5.
Notation:
E(G) Edge set
V (G) Vertex set
c(G) Number of components
G[S] Induced subgraph
deg(v) Degree of v
Δ(G) Maximum degree
δ(G) Minimum degree
χ(G) Chromatic number
χ
E
(G) Edge chromatic number
G
c
Complement graph
K
n
Complete graph
K
n
1
,n
2
Complete bipartite graph
r
(k, ) Ramsey number
Geometry
Projective coordinates: triples
(x, y, z), not all x, y and z zero.
(x, y, z)=(cx, cy, cz) ∀c =0.
Cartesian Projective
(x, y)(x, y, 1)
y = mx + b (m,−1,b)
x = c (1, 0,−c)
Distance formula, L
p
and L
∞
metric:
(x
1
− x
0
)
2
+(y
1
− y
0
)
2
,
|x
1
− x
0
|
p
+ |y
1
− y
0
|
p
1/p
,
lim
p→∞
|x
1
− x
0
|
p
+ |y
1
− y
0
|
p
1/p
.
Area of triangle (x
0
,y
0
), (x
1
,y
1
)
and (x
2
,y
2
):
1
2
abs
x
1
− x
0
y
1
− y
0
x
2
− x
0
y
2
− y
0
.
Angle formed by three points:
θ
(0, 0)
(x
1
,y
1
)
(x
2
,y
2
)
2
1
cos θ =
(x
1
,y
1
) · (x
2
,y
2
)
1
2
.
Line through two points (x
0
,y
0
)
and (x
1
,y
1
):
xy1
x
0
y
0
1
x
1
y
1
1
=0.
Area of circle, volume of sphere:
A = πr
2
,V=
4
3
πr
3
.
If I have seen farther than others,
it is because I have stood on the
shoulders of giants.
– Issac Newton
-
Theoretical Computer Science Cheat Sheet
π Calculus
Wallis’ identity:
π =2·
2 · 2 · 4 · 4 · 6 · 6···
1 · 3 · 3 · 5 · 5 · 7···
Brouncker’s continued fraction expansion:
π
4
=1+
1
2
2+
3
2
2+
5
2
2+
7
2
2+···
Gregrory’s series:
π
4
=1−
1
3
+
1
5
−
1
7
+
1
9
−···
Newton’s series:
π
6
=
1
2
+
1
2 · 3 · 2
3
+
1 · 3
2 · 4 · 5 · 2
5
+ ···
Sharp’s series:
π
6
=
1
√
3
1−
1
3
1
· 3
+
1
3
2
· 5
−
1
3
3
· 7
+···
Euler’s series:
π
2
6
=
1
1
2
+
1
2
2
+
1
3
2
+
1
4
2
+
1
5
2
+ ···
π
2
8
=
1
1
2
+
1
3
2
+
1
5
2
+
1
7
2
+
1
9
2
+ ···
π
2
12
=
1
1
2
−
1
2
2
+
1
3
2
−
1
4
2
+
1
5
2
−···
Derivatives:
1.
d(cu)
dx
= c
du
dx
, 2.
d(u + v)
dx
=
du
dx
+
dv
dx
, 3.
d(uv)
dx
= u
dv
dx
+ v
du
dx
,
4.
d(u
n
)
dx
= nu
n−1
du
dx
, 5.
d(u/v)
dx
=
v
du
dx
− u
dv
dx
v
2
, 6.
d(e
cu
)
dx
= ce
cu
du
dx
,
7.
d(c
u
)
dx
= (ln c)c
u
du
dx
, 8.
d(ln u)
dx
=
1
u
du
dx
,
9.
d(sin u)
dx
= cos u
du
dx
, 10.
d(cos u)
dx
= − sin u
du
dx
,
11.
d(tan u)
dx
= sec
2
u
du
dx
, 12.
d(cot u)
dx
= csc
2
u
du
dx
,
13.
d(sec u)
dx
= tan u sec u
du
dx
, 14.
d(csc u)
dx
= − cot u csc u
du
dx
,
15.
d(arcsin u)
dx
=
1
√
1 − u
2
du
dx
, 16.
d(arccos u)
dx
=
−1
√
1 − u
2
du
dx
,
17.
d(arctan u)
dx
=
1
1+u
2
du
dx
, 18.
d(arccot u)
dx
=
−1
1+u
2
du
dx
,
19.
d(arcsec u)
dx
=
1
u
√
1 − u
2
du
dx
, 20.
d(arccsc u)
dx
=
−1
u
√
1 − u
2
du
dx
,
21.
d(sinh u)
dx
= cosh u
du
dx
, 22.
d(cosh u)
dx
= sinh u
du
dx
,
23.
d(tanh u)
dx
= sech
2
u
du
dx
, 24.
d(coth u)
dx
= − csch
2
u
du
dx
,
25.
d(sech u)
dx
= − sech u tanh u
du
dx
, 26.
d(csch u)
dx
= − csch u coth u
du
dx
,
27.
d(arcsinh u)
dx
=
1
√
1+u
2
du
dx
, 28.
d(arccosh u)
dx
=
1
√
u
2
− 1
du
dx
,
29.
d(arctanh u)
dx
=
1
1 − u
2
du
dx
, 30.
d(arccoth u)
dx
=
1
u
2
− 1
du
dx
,
31.
d(arcsech u)
dx
=
−1
u
√
1 − u
2
du
dx
, 32.
d(arccsch u)
dx
=
−1
|u|
√
1+u
2
du
dx
.
Integrals:
1.
cu dx = c
u dx, 2.
(u + v) dx =
udx+
v dx,
3.
x
n
dx =
1
n +1
x
n+1
,n= −1, 4.
1
x
dx =lnx, 5.
e
x
dx = e
x
,
6.
dx
1+x
2
= arctan x, 7.
u
dv
dx
dx = uv −
v
du
dx
dx,
8.
sin xdx= − cos x, 9.
cos xdx= sin x,
10.
tan xdx= − ln| cos x|, 11.
cot xdx=ln| cos x|,
12.
sec xdx=ln| sec x + tan x|, 13.
csc xdx=ln| csc x + cot x|,
14.
arcsin
x
a
dx = arcsin
x
a
+
a
2
− x
2
,a>0,
Partial Fractions
Let N(x) and D(x) be polynomial func-
tions of x. We can break down
N(x)/D(x) using partial fraction expan-
sion. First, if the degree of N is greater
than or equal to the degree of D, divide
N by D, obtaining
N(x)
D(x)
= Q(x)+
N
(x)
D(x)
,
where the degree of N
is less than that of
D. Second, factor D(x). Use the follow-
ing rules: For a non-repeated factor:
N(x)
(x − a)D(x)
=
A
x − a
+
N
(x)
D(x)
,
where
A =
N(x)
D(x)
x=a
.
For a repeated factor:
N(x)
(x − a)
m
D(x)
=
m−1
k=0
A
k
(x − a)
m−k
+
N
(x)
D(x)
,
where
A
k
=
1
k!
d
k
dx
k
N(x)
D(x)

x=a
.
The reasonable man adapts himself to the
world; the unreasonable persists in trying
to adapt the world to himself. Therefore
all progress depends on the unreasonable.
– George Bernard Shaw
-
Theoretical Computer Science Cheat Sheet
Calculus Cont.
15.
arccos
x
a
dx = arccos
x
a
−
a
2
− x
2
,a>0, 16.
arctan
x
a
dx = x arctan
x
a
−
a
2
ln(a
2
+ x
2
),a>0,
17.
sin
2
(ax)dx =
1
2a
ax − sin(ax) cos(ax)
, 18.
cos
2
(ax)dx =
1
2a
ax + sin(ax) cos(ax)
,
19.
sec
2
xdx= tan x, 20.
csc
2
xdx= − cot x,
21.
sin
n
xdx= −
sin
n−1
x cos x
n
+
n − 1
n
sin
n−2
x dx, 22.
cos
n
xdx=
cos
n−1
x sin x
n
+
n − 1
n
cos
n−2
x dx,
23.
tan
n
xdx=
tan
n−1
x
n − 1
−
tan
n−2
x dx, n =1, 24.
cot
n
xdx= −
cot
n−1
x
n − 1
−
cot
n−2
x dx, n =1,
25.
sec
n
xdx=
tan x sec
n−1
x
n − 1
+
n − 2
n − 1
sec
n−2
x dx, n =1,
26.
csc
n
xdx= −
cot x csc
n−1
x
n − 1
+
n − 2
n − 1
csc
n−2
x dx, n =1, 27.
sinh xdx= cosh x, 28.
cosh xdx= sinh x,
29.
tanh xdx=ln| cosh x|, 30.
coth xdx=ln| sinh x|, 31.
sech xdx= arctan sinh x, 32.
csch xdx=ln
tanh
x
2
,
33.
sinh
2
xdx=
1
4
sinh(2x) −
1
2
x, 34.
cosh
2
xdx=
1
4
sinh(2x)+
1
2
x, 35.
sech
2
xdx= tanh x,
36.
arcsinh
x
a
dx = x arcsinh
x
a
−
x
2
+ a
2
,a>0, 37.
arctanh
x
a
dx = x arctanh
x
a
+
a
2
ln|a
2
− x
2
|,
38.
arccosh
x
a
dx =
x arccosh
x
a
−
x
2
+ a
2
, if arccosh
x
a
> 0 and a>0,
x arccosh
x
a
+
x
2
+ a
2
, if arccosh
x
a
< 0 and a>0,
39.
dx
√
a
2
+ x
2
=ln
x +
a
2
+ x
2
,a>0,
40.
dx
a
2
+ x
2
=
1
a
arctan
x
a
,a>0, 41.
a
2
− x
2
dx =
x
2
a
2
− x
2
+
a
2
2
arcsin
x
a
,a>0,
42.
(a
2
− x
2
)
3/2
dx =
x
8
(5a
2
− 2x
2
)
a
2
− x
2
+
3a
4
8
arcsin
x
a
,a>0,
43.
dx
√
a
2
− x
2
= arcsin
x
a
,a>0, 44.
dx
a
2
− x
2
=
1
2a
ln
a + x
a − x
, 45.
dx
(a
2
− x
2
)
3/2
=
x
a
2
√
a
2
− x
2
,
46.
a
2
± x
2
dx =
x
2
a
2
± x
2
±
a
2
2
ln
x +
a
2
± x
2
, 47.
dx
√
x
2
− a
2
=ln
x +
x
2
− a
2
,a>0,
48.
dx
ax
2
+ bx
=
1
a
ln
x
a + bx
, 49.
x
√
a + bx dx =
2(3bx − 2a)(a + bx)
3/2
15b
2
,
50.
√
a + bx
x
dx =2
√
a + bx + a
1
x
√
a + bx
dx, 51.
x
√
a + bx
dx =
1
√
2
ln
√
a + bx −
√
a
√
a + bx +
√
a
,a>0,
52.
√
a
2
− x
2
x
dx =
a
2
− x
2
− a ln
a +
√
a
2
− x
2
x
, 53.
x
a
2
− x
2
dx = −
1
3
(a
2
− x
2
)
3/2
,
54.
x
2
a
2
− x
2
dx =
x
8
(2x
2
− a
2
)
a
2
− x
2
+
a
4
8
arcsin
x
a
,a>0, 55.
dx
√
a
2
− x
2
= −
1
a
ln
a +
√
a
2
− x
2
x
,
56.
xdx
√
a
2
− x
2
= −
a
2
− x
2
, 57.
x
2
dx
√
a
2
− x
2
= −
x
2
a
2
− x
2
+
a
2
2
arcsin
x
a,
a>0,
58.
√
a
2
+ x
2
x
dx =
a
2
+ x
2
− a ln
a +
√
a
2
+ x
2
x
, 59.
√
x
2
− a
2
x
dx =
x
2
− a
2
− a arccos
a
|x|
,a>0,
60.
x
x
2
± a
2
dx =
1
3
(x
2
± a
2
)
3/2
, 61.
dx
x
√
x
2
+ a
2
=
1
a
ln
x
a +
√
a
2
+ x
2
,
-
Theoretical Computer Science Cheat Sheet
Calculus Cont. Finite Calculus
62.
dx
x
√
x
2
− a
2
=
1
a
arccos
a
|x|
,a>0, 63.
dx
x
2
√
x
2
± a
2
= ∓
√
x
2
± a
2
a
2
x
,
64.
xdx
√
x
2
± a
2
=
x
2
± a
2
, 65.
√
x
2
± a
2
x
4
dx = ∓
(x
2
+ a
2
)
3/2
3a
2
x
3
,
66.
dx
ax
2
+ bx + c
=
1
√
b
2
− 4ac
ln
2ax + b −
√
b
2
− 4ac
2ax + b +
√
b
2
− 4ac
, if b
2
> 4ac,
2
√
4ac − b
2
arctan
2ax + b
√
4ac − b
2
, if b
2
< 4ac,
67.
dx
√
ax
2
+ bx + c
=
1
√
a
ln
2ax + b +2
√
a
ax
2
+ bx + c
, if a>0,
1
√
−a
arcsin
−2ax − b
√
b
2
− 4ac
, if a<0,
68.
ax
2
+ bx + cdx=
2ax + b
4a
ax
2
+ bx + c +
4ax − b
2
8a
dx
√
ax
2
+ bx + c
,
69.
xdx
√
ax
2
+ bx + c
=
√
ax
2
+ bx + c
a
−
b
2a
dx
√
ax
2
+ bx + c
,
70.
dx
x
√
ax
2
+ bx + c
=
−1
√
c
ln
2
√
c
√
ax
2
+ bx + c + bx +2c
x
, if c>0,
1
√
−c
arcsin
bx +2c
|x|
√
b
2
− 4ac
, if c<0,
71.
x
3
x
2
+ a
2
dx =(
1
3
x
2
−
2
15
a
2
)(x
2
+ a
2
)
3/2
,
72.
x
n
sin(ax) dx = −
1
a
x
n
cos(ax)+
n
a
x
n−1
cos(ax) dx,
73.
x
n
cos(ax) dx =
1
a
x
n
sin(ax) −
n
a
x
n−1
sin(ax) dx,
74.
x
n
e
ax
dx =
x
n
e
ax
a
−
n
a
x
n−1
e
ax
dx,
75.
x
n
ln(ax) dx = x
n+1
ln(ax)
n +1
−
1
(n +1)
2
,
76.
x
n
(ln ax)
m
dx =
x
n+1
n +1
(ln ax)
m
−
m
n +1
x
n
(ln ax)
m−1
dx.
Difference, shift operators:
Δf(x)=f(x +1)− f(x),
E
f(x)=f(x +1).
Fundamental Theorem:
f(x)=ΔF (x) ⇔
f(x)δx = F (x)+C.
b
a
f(x)δx =
b−1
i=a
f(i).
Differences:
Δ(cu)=cΔu, Δ(u + v)=Δu +Δv,
Δ(uv)=uΔv +
E
vΔu,
Δ(x
n
)=nx
n−1
,
Δ(H
x
)=x
−1
, Δ(2
x
)=2
x
,
Δ(c
x
)=(c − 1)c
x
, Δ
x
m
=
x
m−1
.
Sums:
cu δx = c
uδx,
(u + v) δx =
uδx+
vδx,
uΔvδx= uv −
E
vΔuδx,
x
n
δx =
x
n+1
m+1
,
x
−1
δx = H
x
,
c
x
δx =
c
x
c−1
,
x
m
δx =
x
m+1
.
Falling Factorial Powers:
x
n
= x(x − 1)···(x − n +1),n>0,
x
0
=1,
x
n
=
1
(x +1)···(x + |n|)
,n<0,
x
n+m
= x
m
(x − m)
n
.
Rising Factorial Powers:
x
n
= x(x +1)···(x + n − 1),n>0,
x
0
=1,
x
n
=
1
(x − 1)···(x −|n|)
,n<0,
x
n+m
= x
m
(x + m)
n
.
Conversion:
x
n
=(−1)
n
(−x)
n
=(x − n +1)
n
=1/(x +1)
−n
,
x
n
=(−1)
n
(−x)
n
=(x + n − 1)
n
=1/(x − 1)
−n
,
x
n
=
n
k=1
n
k
x
k
=
n
k=1
n
k
(−1)
n−k
x
k
,
x
n
=
n
k=1
n
k
(−1)
n−k
x
k
,
x
n
=
n
k=1
n
k
x
k
.
x
1
= x
1
= x
1
x
2
= x
2
+ x
1
= x
2
− x
1
x
3
= x
3
+3x
2
+ x
1
= x
3
− 3x
2
+ x
1
x
4
= x
4
+6x
3
+7x
2
+ x
1
= x
4
− 6x
3
+7x
2
− x
1
x
5
= x
5
+15x
4
+25x
3
+10x
2
+ x
1
= x
5
− 15x
4
+25x
3
− 10x
2
+ x
1
x
1
= x
1
x
1
= x
1
x
2
= x
2
+ x
1
x
2
= x
2
− x
1
x
3
= x
3
+3x
2
+2x
1
x
3
= x
3
− 3x
2
+2x
1
x
4
= x
4
+6x
3
+11x
2
+6x
1
x
4
= x
4
− 6x
3
+11x
2
− 6x
1
x
5
= x
5
+10x
4
+35x
3
+50x
2
+24x
1
x
5
= x
5
− 10x
4
+35x
3
− 50x
2
+24x
1
-
Theoretical Computer Science Cheat Sheet
Series
Taylor’s series:
f(x)=f(a)+(x− a)f
(a)+
(x − a)
2
2
f

(a)+···=
∞
i=0
(x − a)
i
i!
f
(i)
(a).
Expansions:
1
1 − x
=1+x + x
2
+ x
3
+ x
4
+ ··· =
∞
i=0
x
i
,
1
1 − cx
=1+cx + c
2
x
2
+ c
3
x
3
+ ··· =
∞
i=0
c
i
x
i
,
1
1 − x
n
=1+x
n
+ x
2n
+ x
3n
+ ··· =
∞
i=0
x
ni
,
x
(1 − x)
2
= x +2x
2
+3x
3
+4x
4
+ ··· =
∞
i=0
ix
i
,
x
k
d
n
dx
n
1
1 − x
= x +2
n
x
2
+3
n
x
3
+4
n
x
4
+ ··· =
∞
i=0
i
n
x
i
,
e
x
=1+x +
1
2
x
2
+
1
6
x
3
+ ··· =
∞
i=0
x
i
i!
,
ln(1 + x)=x −
1
2
x
2
+
1
3
x
3
−
1
4
x
4
−··· =
∞
i=1
(−1)
i+1
x
i
i
,
ln
1
1 − x
= x +
1
2
x
2
+
1
3
x
3
+
1
4
x
4
+ ··· =
∞
i=1
x
i
i
,
sin x = x −
1
3!
x
3
+
1
5!
x
5
−
1
7!
x
7
+ ··· =
∞
i=0
(−1)
i
x
2i+1
(2i + 1)!
,
cos x =1−
1
2!
x
2
+
1
4!
x
4
−
1
6!
x
6
+ ··· =
∞
i=0
(−1)
i
x
2i
(2i)!
,
tan
−1
x = x −
1
3
x
3
+
1
5
x
5
−
1
7
x
7
+ ··· =
∞
i=0
(−1)
i
x
2i+1
(2i +1)
,
(1 + x)
n
=1+nx +
n(n−1)
2
x
2
+ ··· =
∞
i=0
n
i
x
i
,
1
(1 − x)
n+1
=1+(n +1)x +
n+2
2
x
2
+ ··· =
∞
i=0
i + n
i
x
i
,
x
e
x
− 1
=1−
1
2
x +
1
12
x
2
−
1
720
x
4
+ ··· =
∞
i=0
B
i
x
i
i!
,
1
2x
(1 −
√
1 − 4x)=1+x +2x
2
+5x
3
+ ··· =
∞
i=0
1
i +1
2i
i
x
i
,
1
√
1 − 4x
=1+x +2x
2
+6x
3
+ ··· =
∞
i=0
2i
i
x
i
,
1
√
1 − 4x
1 −
√
1 − 4x
2x
n
=1+(2+n)x +
4+n
2
x
2
+ ··· =
∞
i=0
2i + n
i
x
i
,
1
1 − x
ln
1
1 − x
= x +
3
2
x
2
+
11
6
x
3
+
25
12
x
4
+ ··· =
∞
i=1
H
i
x
i
,
1
2
ln
1
1 − x
2
=
1
2
x
2
+
3
4
x
3
+
11
24
x
4
+ ··· =
∞
i=2
H
i−1
x
i
i
,
x
1 − x − x
2
= x + x
2
+2x
3
+3x
4
+ ··· =
∞
i=0
F
i
x
i
,
F
n
x
1 − (F
n−1
+ F
n+1
)x − (−1)
n
x
2
= F
n
x + F
2n
x
2
+ F
3n
x
3
+ ··· =
∞
i=0
F
ni
x
i
.
Ordinary power series:
A(x)=
∞
i=0
a
i
x
i
.
Exponential power series:
A(x)=
∞
i=0
a
i
x
i
i!
.
Dirichlet power series:
A(x)=
∞
i=1
a
i
i
x
.
Binomial theorem:
(x + y)
n
=
n
k=0
n
k
x
n−k
y
k
.
Difference of like powers:
x
n
− y
n
=(x − y)
n−1
k=0
x
n−1−k
y
k
.
For ordinary power series:
αA(x)+βB(x)=
∞
i=0
(αa
i
+ βb
i
)x
i
,
x
k
A(x)=
∞
i=k
a
i−k
x
i
,
A(x) −
k−1
i=0
a
i
x
i
x
k
=
∞
i=0
a
i+k
x
i
,
A(cx)=
∞
i=0
c
i
a
i
x
i
,
A
(x)=
∞
i=0
(i +1)a
i+1
x
i
,
xA
(x)=
∞
i=1
ia
i
x
i
,
A(x) dx =
∞
i=1
a
i−1
i
x
i
,
A(x)+A(−x)
2
=
∞
i=0
a
2i
x
2i
,
A(x) − A(−x)
2
=
∞
i=0
a
2i+1
x
2i+1
.
Summation: If b
i
=
i
j=0
a
i
then
B(x)=
1
1 − x
A(x).
Convolution:
A(x)B(x)=
∞
i=0
i
j=0
a
j
b
i−j
x
i
.
God made the natural numbers;
all the rest is the work of man.
– Leopold Kronecker
-
Theoretical Computer Science Cheat Sheet
Series Escher’s Knot
Expansions:
1
(1 − x)
n+1
ln
1
1 − x
=
∞
i=0
(H
n+i
− H
n
)
n + i
i
x
i
,
1
x
−n
=
∞
i=0
i
n
x
i
,
x
n
=
∞
i=0
n
i
x
i
, (e
x
− 1)
n
=
∞
i=0
i
n
n!x
i
i!
,
ln
1
1 − x
n
=
∞
i=0
i
n
n!x
i
i!
,xcot x =
∞
i=0
(−4)
i
B
2i
x
2i
(2i)!
,
tan x =
∞
i=1
(−1)
i−1
2
2i
(2
2i
− 1)B
2i
x
2i−1
(2i)!
,ζ(x)=
∞
i=1
1
i
x
,
1
ζ(x)
=
∞
i=1
μ(i)
i
x
,
ζ(x− 1)
ζ(x)
=
∞
i=1
φ(i)
i
x
,
Stieltjes Integration
ζ(x)=
p
1
1 − p
−x
,
ζ
2
(x)=
∞
i=1
d(i)
x
i
where d(n)=
d|n
1,
ζ(x)ζ(x − 1) =
∞
i=1
S(i)
x
i
where S(n)=
d|n
d,
ζ(2n)=
2
2n−1
|B
2n
|
(2n)!
π
2n
,n∈ N,
x
sin x
=
∞
i=0
(−1)
i−1
(4
i
− 2)B
2i
x
2i
(2i)!
,
1 −
√
1 − 4x
2x
n
=
∞
i=0
n(2i + n − 1)!
i!(n + i)!
x
i
,
e
x
sin x =
∞
i=1
2
i/2
sin
iπ
4
i!
x
i
,
1 −
√
1 − x
x
=
∞
i=0
(4i)!
16
i
√
2(2i)!(2i + 1)!
x
i
,
arcsin x
x
2
=
∞
i=0
4
i
i!
2
(i + 1)(2i + 1)!
x
2i
.
If G is continuous in the interval [a, b] and F is nondecreasing then
b
a
G(x) dF (x)
exists. If a ≤ b ≤ c then
c
a
G(x) dF (x)=
b
a
G(x) dF (x)+
c
b
G(x) dF (x).
If the integrals involved exist
b
a
G(x)+H(x)
dF (x)=
b
a
G(x) dF (x)+
b
a
H(x) dF (x),
b
a
G(x) d
F (x)+H(x)
=
b
a
G(x) dF (x)+
b
a
G(x) dH(x),
b
a
c · G(x) dF (x)=
b
a
G(x) d
c · F (x)
= c
b
a
G(x) dF (x),
b
a
G(x) dF (x)=G(b)F (b) − G(a)F (a) −
b
a
F (x) dG(x).
If the integrals involved exist, and F possesses a derivative F
at every
point in [a, b] then
b
a
G(x) dF (x)=
b
a
G(x)F
(x) dx.
Cramer’s Rule
00 47 18 76 29 93 85 34 61 52
86 11 57 28 70 39 94 45 02 63
95 80 22 67 38 71 49 56 13 04
59 96 81 33 07 48 72 60 24 15
73 69 90 82 44 17 58 01 35 26
68 74 09 91 83 55 27 12 46 30
37 08 75 19 92 84 66 23 50 41
14 25 36 40 51 62 03 77 88 99
21 32 43 54 65 06 10 89 97 78
42 53 64 05 16 20 31 98 79 87
Fibonacci Numbers
If we have equations:
a
1,1
x
1
+ a
1,2
x
2
+ ···+ a
1,n
x
n
= b
1
a
2,1
x
1
+ a
2,2
x
2
+ ···+ a
2,n
x
n
= b
2
.
.
.
.
.
.
.
.
.
a
n,1
x
1
+ a
n,2
x
2
+ ···+ a
n,n
x
n
= b
n
Let A =(a
i,j
) and B be the column matrix (b
i
). Then
there is a unique solution iff det A = 0. Let A
i
be A
with column i replaced by B. Then
x
i
=
det A
i
det A
.
1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89,...
Definitions:
F
i
= F
i−1
+F
i−2
,F
0
= F
1
=1,
F
−i
=(−1)
i−1
F
i
,
F
i
=
1
√
5
φ
i
−
ˆ
φ
i
,
Cassini’s identity: for i>0:
F
i+1
F
i−1
− F
2
i
=(−1)
i
.
Additive rule:
F
n+k
= F
k
F
n+1
+ F
k−1
F
n
,
F
2n
= F
n
F
n+1
+ F
n−1
F
n
.
Calculation by matrices:
F
n−2
F
n−1
F
n−1
F
n
=
01
11
n
.
The Fibonacci number system:
Every integer n has a unique
representation
n = F
k
1
+ F
k
2
+ ···+ F
k
m
,
where k
i
≥ k
i+1
+ 2 for all i,
1 ≤ i<mand k
m
≥ 2.
Improvement makes strait roads, but the crooked
roads without Improvement, are roads of Genius.
– William Blake (The Marriage of Heaven and Hell)
- -
- - - diff --git a/demo/chn.html b/demo/chn.html deleted file mode 100644 index 821f996..0000000 --- a/demo/chn.html +++ /dev/null @@ -1,249 +0,0 @@ - - - - - - - - - - - - - - -
- -
Git 使用指南
Li Yanrui
v 0.1, 20080728
liyanrui.m2@gmail.com
-
前 言
Git 是什么
非常简单地说，Git 是 一 个 快 速 、可 扩 展 的 分 布 式 版 本 控 制 系 统 ，它 具 有 极 为 丰
富的命令集，对内部系统提供了高级操作和完全访问。所谓版本控制系统 (Version
Control System)，从狭义上来说，它是软件项目开发过程中用于储存我们所写的代
码所有修订版本的软件，但事实上我们可以将任何对项目有帮助的文档交付版本控
制系统进行管理。
2005 年 ，Torvalds 开始着手开发 Git 是 为 了 作 为 一 种 过 渡 方 案 来 替 代
BitKeeper，后者之前一直是 Linux 内 核 开 发 人 员 在 使 用 的 版 本 控 制 工 具 ，当 时 由
于自由软件社区中的许多人觉得 BitKeeper 的 使 用 许 可 证 并 不 适 合 自 由 软 件 社 区
的工作，因此 Linus 决 定 着 手 开 发 许 可 证 更 为 自 由 灵 活 的 版 本 控 制 系 统 。尽 管 最 初
Git 的开发是为了辅助 Linux 内 核 开 发 的 过 程 ，但是 现 在 很 多 其 他 自 由 软 件 项 目 中
也使用了 Git 实现代码版本管理，譬如，X.org 项目、许多 Freedesktop.org 的 项 目 、
Ruby 项目等。
为什么使用版本控制系统
版本控制系统是为懒人准备的，它让懒人们比那些善于备份文档的勤劳人拥有
更干净的文件系统以及更多的可以活着的时间。
本文档主要内容
在第 1 章中讲述如何使用 Git 管理自己的个人文档，主要是初步熟悉 Git 的
诸多概念及其日常基本命令的使用。第 2 章中主要讲述如何基于 Git 实 现 多 人 协
作 的 项 目 开 发 模 式 ，以 此 扭 转 当 前 实 验 室 成 员 在 项 目 研 发 中 各 自 为 政 或 不 能 有 效
沟通的现状。第 3 章讲述如何利用 Git 强 大 的 项 目 分 支 管 理 功 能 实 现 良 好 风 格 的
项目协同开发模式。第 4 章为 Git 使用之 FAQ，用 于 记 载 在 本 实 验 室 推 广 使 用
Git 过程中诸位同学所遇到的一些细节问题。
-
Contents
第 1 章 使用 Git 管理个人文档 1
1.1 何种文档需要保存 1
1.2 建立项目仓库 1
1.3 关于建立 Git 仓库的一些细节 2
1.4 仓库与工作树 3
1.5 在项目中工作 4
1.6 查看版本历史 5
1.7 撤销与恢复 7
1.8 如何使用 Git 帮助文档 7
1.9 总结 8
第 2 章 基于 Git 的团队协同开发 9
2.1 两个人如何协同 9
2.2 如何解决仓库合并冲突 10
2.3 三人以至更多人如何协同 12
2.4 M2GE 的协同开发 12
2.5 总结 13
第 3 章 项目分支管理 14
3.1 如何产生项目分支 14
3.2 分支的合并 15
3.3 M2GE 新的协同开发模式 15
3.4 总结 16
-
第 1 章 使用 Git 管理个人文档
本章讲述如何使用 Git 管理我们的个人文档，用以展示 Git 的 一 些 基 本 功 能 ，
并且秉承学以致用、用以促学的精神，引导大家积极地将 Git 应 用 于 日 常 学 习 与 工
作中的文档备份。仿温水煮蛙之古例，此章乃温水也。
1.1 何种文档需要保存
凡需要持续变动的文档皆可作为项目并交付于 Git 进行管理。由于 Git 可以详
细地记录对于项目的各种修改并提供了功能强大的版本控制，因此愈是修改较为频
繁的文档，愈是有必要将其纳入 Git 的管理之下。
理论上，Git 可 以 保 存 任 何 文 档 ，但 是 最 善 于 保 存 文 本 文 档 ，因 为 它 本 来 就 是 为
解决软件源代码（也是一种文本文档）版本管理问题而开发的，提供了许多有助于文
本分析的工具。对于非文本文档，Git 只是简单地为其进行备份并实施版本管理。
1.2 建立项目仓库
欲使用 Git 对 现 有 文 档 进 行 版 本 控 制 ，首 先 要 基 于 现 有 文 档 建 立 项 目 仓 库 。下
面以本文档的版本管理为例，演示如何将其作为项目并纳于 Git 的版本控制之下。
本文档是由 T
E
X 生成的，对应 T
E
X 源文档皆位于 $HOME/work/m2doc 目 录
下，下文为叙述方便，以 Bash 变量 $WORK 代替该目录。首先需初始化 Git 仓库：
$ cd $WORK
$ git init
Git 会作出以下回应：
Initialized empty Git repository in $PROJECT/.git/
上述操作的结果是在 $WORK 目录下创建了一个 .git 隐 藏 目 录 ，它 就 是 所 谓
的 Git 仓库，不过现在它还是空的。另外 $WORK 目 录 也 不 再 是 普 通 的 文 档 目 录 了 ，
今后我们将其称为工作树。
下面应当有选择地将工作树中的一些文档存储至 Git 仓库中。由于 Git 在 向
仓 库 中 添 加 文 档 时 并 非 是 简 单 地 文 档 复 制 过 去 ，势 必 要 将 所 添 加 文 档 进 行 一 番 处
-
2
理，生成 Git 仓库所能接受的数据格式，Git 称这个过程为 "take a snapshot"（ 生 成
快照）。若将工作树下所有文档（包含子目录）生成快照，可采用以下命令：
$ cd $WORK
$ git add .
所生成的快照被存放到一个临时的存储区域，Git 称该区域为索引 。使 用
git-commit 命令可将索引提交至仓库中，这个过程称为提交 ，每 一 次 提 交 都 意 味 着
版本在进行一次更新。git-commit 最简单的用法如下：
$ git commit
执行上述 git-commit 命令时，Git 会 自 动 调 用 系 统 默 认 的 文 本 编 辑 器 ，要 求 你
输入版本更新说明并保存。请记住，输入简约的版本更新说明是非常有必要的，它就
像剧本一样，可以帮助你快速回忆起对项目的重大改动。
对于简短的版本更新信息，可以使用 git-commit 的“-m”选项，如下：
$ git commit -m "你的版本更新信息"
上述过程即为建立 Git 仓库的一般过程，我将其总结为图1.1所示之流程：
git-init
仓 库 初 始 化
git-add
生 成 快 照 并 存
入 项 目 索 引
版 本 更 新 说 明
git-commit
项 目 索 引 提 交
图 1.1 Git 仓 库 建 立 流 程
1.3 关于建立 Git 仓库的一些细节
看过上一节内容，也许你会跃跃欲试，准备拿自己的一个文档目录下手。切莫如
此 着 急 ，为 了 概 念 的 完 整 性 ，上 一 节 内 容 中 ，我 故 意 省 略 了 两 个 细 节 问 题 ，下 面 逐 一
道来。
-
3
第一个问题是：在使用 Git 之前，你需要面对 Git 来一番自我介绍。Git 不 喜 欢
不 愿 透 漏 姓 名 的 人 ，因 为 它 要 求 每 个 人 在 向 仓 库 提 交 数 据 时 ，都 应 当 承 担 一 定 的 责
任。要向 Git 进行自我介绍，请使用以下命令：
$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email you@yourdomain.example.com
第 二 个 问 题 是 ：在 生 成 文 档 内 容 快 照 时 ，工 作 树 中 有 一 些 文 档 是 你 不 希 望 接 受
Git 管 理 的 ，譬 如 程 序 编 译 时 生 成 的 中 间 文 件 ，对 于 这 样 的 文 件 如 何 避 免 为 之 生 成
快照？
譬如对于上一节的用例，在工作树中存在以下文件（或子目录）：
doc-env.tex git-tutor.tex Makefile zh
git-tutor main.tex vfonts.tex
其中的 zh 目录存放着 T
E
X 文档编译时生成的中间文件，因此该目录不应该被
Git 所管理。为解决此类问题，Git 提 供 了 文 档 忽 略 机 制 ，可 以 将 工 作 树 中 你 不 希 望
接受 Git 管理的文档信息写到同一目录下的 .gitignore 文 件 中 。对 于 本 例 中 的
zh 目录，采用如下操作可将其排除仓库之外，然后再对 $WORK 生成快照即可。
$ cd $WORK
$ echo "zh" > .gitignore
$ git add .
有关 gitignore 文件的诸多细节知识可阅读其使用手册：
$ man gitignore
1.4 仓库与工作树
按照前文的说法，Git 仓库就是那个 .git 目录 ，其中 存放 的是 我们 所提 交的 文
档索引内容，Git 可 基 于 文 档 索 引 内 容 对 其 所 管 理 的 文 档 进 行 内 容 追 踪 ，从 而 实 现
文档的版本控制。工作树是包含 .git 的目录，在前文示例中即 $WORK 目录。
为了更加明确仓库与工作树的概念，下面做一个实验：
-
4
$ cp -R $WORK/.git /tmp/m2doc.git
$ cd /tmp
$ git clone m2doc.git m2doc-copy
首先，我们将 $WORK 目录中的 .git 目录复制到 /tmp 目 录 下 并 进 行 重 命 名 为
m2doc.git ，然后使用 git-clone 命 令
1
从 m2doc.git 中生成 m2doc-copy 目 录 。若
进入 m2doc-copy 目录观察一下，就会发现该目录所包含的内容是等同于 $WORK 目
录的。
上述实验意味着，只要我们拥有仓库，即 m2doc.git ，那 么 就 可 以 很 容 易 地 生
成工作树，而这个工作树又包含着一个仓库，即 m2doc-copy/.git 。所 以 ，我 们 可
以这样理解：在 Git 中，仓库与工作树之间无需分的很清楚。
1.5 在项目中工作
在工作树中，我们日常所进行的工作无非是对 Git 仓 库 所 管 理 的 文 档 进 行 修
改，或者添加／删除一些文件。这些操作与采用 Git 管 理 我 们 的 文 档 之 前 没 有 任 何
差异，只是在你认为一个工作阶段完成之时，要记得通知 Git，命 令 它 记 下 你 所 进
行更新，这一步骤是通过生成文档快照并将其加入到索引中来实现的。
譬如今天，我向 $WORK 目录添加了一份新文档 ch1.tex ，我需要通知 Git 记
住我的这一更新：
$ cd $WORK
$ git add ch1.tex
这样，Git 就会将有关 ch1.tex 的 更 新 添 加 到 索 引 中 。然 后 我 又 对 其 它 文 档
进行了一些修改，譬如修改了 doc-env.tex 以及 git-tutor.tex 文 件 ，继 续 使 用
git-add 命令将它们的更新添加到索引中：
$ git add doc-env.tex git-tutor.tex
晚上，这一天的工作告以段落，我觉得有必要将今天所做的提交到仓库中，于是
执行 git-commit 操作，将索引内容添加到仓库中。
可 能 一 天 下 来 ，你 对 工 作 树 中 的 许 多 文 档 都 进 行 了 更 新（ 文 档 添 加 、修 改 、删
除 ），但 是 我 忘 记 了 它 们 的 名 字 ，此 时 若 将 所 做 的 全 部 更 新 添 加 到 索 引 中 ，比 较 轻 省
的做法就是：
工作树克隆命令，在后文中将会对其详细讲述。
1
-
5
$ cd $WORK
$ git add .
$ git commit -a
... 输入日志信息 ...
git-add 命 令 通 常 能 够 判 断 出 当 前 目 录（ 包 括 其 子 目 录 ）下 用 户 所 添 加 的 新 文
档，并将其信息追加到索引中。git-commit 命令的 -a 选 项 可 将 所 有 被 修 改 的 文 档
或 者 已 删 除 的 文 档 的 当 前 状 态 提 交 倒 仓 库 中 。记 住 ，如 果 只 是 修 改 或 者 删 除 了 已 被
Git 管理的文档，是没必要使用 git-add 命令的。
本节并未讲述新的 Git 命 令 ，完 全 是 前 面 所 讲 过 的 一 些 命 令 的 重 复 介 绍 ，只 是
它们出现的场景有所区别而已。另外，要注意的问题是，Git 不 会 主 动 记 录 你 对 文 档
进行的更新，除非你对它发号施令。
1.6 查看版本历史
在工作树中，使用 git-log 命 令 可 以 查 看 当 前 项 目 的 日 志 ，也 就 是 你 在 使 用
git-commit 向仓库提交新版本时所属如的版本更新信息。
$ git log
如果你想看一下每一次版本的大致变动情况，可使用以下命令：
$ git log --stat --summary
下面分析一下 git-log 命令的回应信息。譬如当我在“Git 使 用 指 南 ” 这 一 文
档项目的工作树中查阅项目日志，git-log 命令给出了以下回应信息：
-
6
commit dfb02e6e4f2f7b573337763e5c0013802e392818
Author: Li Yanrui <LiYanrui.m2@gmail.com>
Date: Wed Jul 9 16:32:25 2008 +0800
Git 使用指南文档项目初始化
commit 9a4a9ce37561bbb42d8187d7a851e228e26e1212
Author: Li Yanrui <LiYanrui.m2@gmail.com>
Date: Wed Jul 9 16:31:07 2008 +0800
添加 .gitignore 文件
commit 459640624390eb733fb2ad45bcb8731435931e60
Author: Li Yanrui <LiYanrui.m2@gmail.com>
Date: Wed Jul 9 16:28:50 2008 +0800
M2Doc 项目初始化
lines 1-17/17 (END)
从上面的项目日志信息中可以看到我对 M2Doc 项 目 所 做 的 一 些 阶 段 性 工 作 ，
每 一 个 版 本 都 对 应 着 一 次 项 目 版 本 更 新 提 交 。在 项 目 日 志 信 息 中 ，每 条 日 志 的 首 行
（ 就 是 那 一 串 莫 名 奇 妙 的 数 字 ）为 版 本 更 新 提 交 所 进 行 的 命 名 ，我 们 可 以 将 该 命 名
理解为项目版本号。项目版本号应该是唯一的，默认由 Git 自动生成，用以标示项目
的某一次更新。如果我们将项目版本号用作 git-show 命 令 的 参 数 ，即 可 查 看 该 次 项
目版本的更新细节：
$ git show dfb02e6e4f2f7b573337763e5c0013802e392818
除了使用完整的版本号查看项目版本更新细节之外，也还可以使用以下方式：
$ git show dfb02 # 一般只使用版本号的前几个字符即可
$ git show HEAD # 显示当前分支的最新版本的更新细节
每一个项目版本号通常都对应存在一个父版本号，也就是项目的前一次版本状
态。可使用如下命令查看当前项目版本的父版本更新细节：
$ git show HEAD^ # 查看 HEAD 的父版本更新细节
$ git show HEAD^^ # 查看 HEAD 的祖父版本更新细节
$ git show HEAD~4 # 查看 HEAD 的祖父之祖父的版本更新细节
你可以对项目版本号进行自定义，然后就可以使用自定义的版本号查看对应的
项目版本更新细节：
-
7
$ git tag v0.1 dfb02
$ git show
实际上，上述命令并非是真正的进行版本号自定义，只是制造了一个 tag 对 象
而已，这在进行项目版本对外发布时比较有用。本文档后续章节会对 tag 的 一 些 细
节进行介绍。
1.7 撤销与恢复
版 本 控 制 系 统 的 一 个 重 要 任 务 就 是 提 供 撤 销 和 恢 复 某 一 阶 段 工 作 的 功 能 。
git-reset 命令 就是 为 这样 的 任务 而 准备 的 ，它可 以将 项 目当 前 版本 定 位到 之 前提 交
的任何版本中。
git-reset 命令有三个选项：--mixed 、 --soft 和 --hard 。我 们 在 日 常 使 用
中 仅 使 用 前 两 个 选 项 ；第 三 个 选 项 由 于 杀 伤 力 太 大 ，容 易 损 坏 项 目 仓 库 ，需 谨 慎 使
用。
--mixed 是 git-reset 的 默 认 选 项 ，它 的 作 用 是 重 置 索 引 内 容 ，将 其 定 位 到 指 定
的项目版本，而不改变你的工作树中的所有内容，只是提示你有哪些文件还未更新。
--soft 选项既 不触动索 引的位 置，也不改变 工作树 中的任 何内容，但是会要 求
它们处于一个良好的次序之内。该选项会保留你在工作树中的所有更新并使之处于
待提交状态。
关于 git-reset 命 令 的 具 体 如 何 使 用 可 留 作 本 章 的 练 习 题 ，你 可 以 随 便 创 建 一
个 Git 仓库并向其提交一些版本更新，然后测试 --mixed 与 --soft 选 项 的 效 果 。
如果欲查看 git-reset 命令对工作树的影响，可使用 git-status 命 令 。另 外 ，这 道 练 习
题应当结合 git-reset 的使用帮助（参考下一节）来做，当你大致明白了 git-reset 的
用法，这道题就算做对了。
1.8 如何使用 Git 帮助文档
前 文 中 ，我 一 直 没 有 解 释 这 样 一 个 现 象 ，那 就 是 在 正 文 中 ，总 是 使 用 类 似
git-reset 这 样 的 命 令 形 式 ，但 是 在 终 端 中 实 际 输 入 这 些 指 令 时 ，所 采 用 的 命 令 形 式
又变为 git reset。我 猜 测 这 样 做 的 原 因 是 后 者 作 为 命 令 形 式 对 于 用 户 更 为 友 好 一
些 ，因 为 我 们 已 经 习 惯 了 在 终 端 中 输 入 这 样 的 命 令 格 式 。但 是 在 查 阅 命 令 的 说 明 文
档时，需要使用第一种命令格式，譬如要查看 git reset 命令的用法，可：
-
8
$ man git-reset
1.9 总结
现在我们总算是掌握了有关 Git 的一些粗浅但非常实用的知识，已具备了使用
Git 管理个人文档的能力，希望大家能够学以致用，积极地使用 Git 来 管 理 你 认 为
需要进行版本控制的个人文档。
-
第 2 章 基于 Git 的团队协同开发
很多时候我们是多个人同时为做一件事情而努力，如何有效化解多人协同运作
过程中出现的种种矛盾是相当重要的。实践证明，Git 可 以 很 好 的 胜 任 此 类 任 务 ，这
也是我们要在实验室内部推广 Git 应用的主要原因。
2.1 两个人如何协同
Lyr 与 Tzc 是本节的两位主角。现在假设 Lyr 开始着手开发 M2GE 库，并按照
第 1 章所讲述的 Git 基本用法将 M2GE 库纳于 Git 的管理之下。但是，很快 Lyr 就
发现了仅凭个人之力很难在项目规定期限内完成这项工作，因此他邀请 Tzc 来 参
与 M2GE 库，故事就这样开始了。
Lyr 的 M2GE 工作树为 /work/m2ge ，Tzc 可通过以下命令获得与 Lyr 同 样
的工作树：
$ cd work
$ git clone lyr@192.168.0.7:~/work/m2ge m2ge
git-clone 可利用各种网络协议访问远端机器中的 Git 仓 库 ，从 中 导 出 完 整 的
工作树到本地。在上述示例中，Tzc 通过 SSH 协议访问了 Lyr 机器上的 lyr 账 户
的 M2GE 仓库并进行导出，从而在当前目录下建立了 m2ge 工 作 树 。若 上 述 命 令
中未指定本地工作树名，那么 git-clone 会在 Tzc 当前所在目录中建立与 Lyr 的
M2GE 工作树同名的工作树，所以上述命令指定 Tzc 的工作树名为 m2ge 显 得 有
些多余。
注意，git-clone 命 令 只 要 碰 到 类 似 以 下 格 式 的 远 端 仓 库 地 址 ，它 就 会 认 为 该 地
址是符合 SSH 协议的。
账户@IP:工作树路径
Tzc 既已获得 M2GE 工作树，他就可以开始工作了，同时，Lyr 也在位于自己的
机器上的 M2GE 工作树中工作。在此期间，二人对位于各自机器上的 M2GE 仓 库
的操作只需具备第 1 章所讲述的内容足矣。
一个阶段之后，二人均将所做的工作不断地提交到各自的 Git 仓 库 中 ，直 至 他
们觉得有必要将各自所做的工作合并起来之后再进行新的开发阶段。由于 Lyr 作
-
10
为主要开发者，二人的工作在他的机器上进行合并是比较自然的。当然在 Tzc 机 器
上合并也未尝不可，因为 Git 是 不 分 主 次 仓 库 的 ，同 一 项 目 的 不 同 仓 库 都 是 地 位 均
等。
为实现与 Tzc 的工作合并，Lyr 执行了以下操作：
$ cd ~/work/m2ge
$ git pull tzc@192.168.0.5:~/work/m2ge
git-pull 命令可将属 于同一项目 的远端仓库 与同样属于 同一项目的 本地仓库进
行 合 并 ，它 包 含 了 两 个 操 作 ：从 远 端 仓 库 中 取 出 更 新 版 本 ，然 后 合 并 到 本 地 仓 库 。上
述命令可在 Lyr 的 m2ge 仓库中完成对 Tzc 机器上的 myge 仓库的合并。
如果 Lyr 与 Tzc 是 对 了 不 同 的 文 件 进 行 了 改 动 ，那 么 可 以 不 费 周 折 地 完 成 仓
库 合 并 。但 是 倘 若 二 人 对 一 些 相 同 的 文 件 进 行 了 改 动 ，那 么 在 合 并 时 必 然 会 遭 遇 合
并冲突的问题，此时手动修改发生合并冲突的文件，然后将结果提交到本地仓库。由
于处理合并冲突的问题比较复杂一些，所以下面单独拿出一个小节来讲述。
当项目合并结束后，意味着 Lyr 与 Tzc 一 个 协 同 开 发 周 期 的 结 束 ，他 们 彼 此 很
欣赏对方的工作，所以又开始了下一个周期……
2.2 如何解决仓库合并冲突
现在假设 Lyr 与 Tzc 在各自的工作树中对同一份文件 foo.txt 进 行 了 修 改 ，而
foo.txt 原内容如下：
one
two
three
Lyr 对 foo.txt 进行了如下改动，并将该改动提交到本地仓库。
ONE
two
three
Tzc 对 foo.txt 进行了以下改动，也将该改动提交到本地仓库。
one
two
THREE
-
11
当 Lyr 在合并 Tzc 的 Git 仓库时，Git 会自动合并二人对 foo.txt 的修改：
ONE
two
THREE
现在 Lyr 工作树中的 foo.txt 文件即包含了 Lyr 的改动，也包含了 Tzc 的 改
动，而且合并结果自动作为新版本提交到 Lyr 的仓库中。
观察上述合并冲突示例，可以看出，虽然 Lyr 与 Tzc 是 对 同 一 份 文 件 进 行 了 修
改，但是他们的修改并未重叠。现在假设二人对 foo.txt 的 同 一 行 做 出 了 修 改 ，那 么
在仓库合并时会发生什么，应当如何处理呢？
现在假定上述示例中，Tzc 对 foo.txt 的修改如下：
one ONE
two
three
这样，二人对 foo.txt 的同一行进行了不同的修改，当合并时，Git 会 给 出 以 下
反馈信息：
Auto-merged foo.txt
CONFLICT (content): Merge conflict in foo
Automatic merge failed; fix conflicts and then commit the result.
上述信息之意是：尝试合并 foo.txt 文 件 的 改 动 发 生 了 冲 突 ，自 动 合 并 失 败 ，请
用户手动修复冲突然后将结果提交到仓库中。Lyr 看 到 上 述 信 息 ，就 打 开 了 合 并 后
的 foo.txt，他看到了以下内容：
<<<<<<< HEAD:foo
ONE
=======
one ONE
>>>>>>> 1116d3270764d91a25532a753a47b8b0e1b6f1b8:foo
two
three
以一串 < 开头的字串表示 Lyr 的当前项目版本对 foo.txt 的 修 改 结 果 ，而 以 一
串 > 开头的字串表示 Tzc 的当前项目版本对 foo.txt 的 修 改 结 果 。中 间 用 了 一 串
= 号将二人修改结果隔开。一旦理解了版本冲突的表示格式，Lyr 就 很 容 易 地 根 据
现实情况将合并冲突问题解决掉，他认为 Tzc 的 改 动 是 不 符 合 项 目 需 求 的 ，并 且 按
-
12
照项目的实际需求进行了手工合并。最后，Lyr 将合 并处 理结 果提 交到 仓库 中，即完
成了重叠冲突的合并问题的解决。
2.3 三人以至更多人如何协同
前文在讲述二人协同模式时，强调了 Lyr 与 Tzc 的 主 次 关 系 ，这 种 关 系 似 乎 对
于三人以至更多人的协同也有效。现在我们再引入两位故事主角 Lxc 与 Zhu 来 说
明此问题。假设 Lxc 与 Zhu 仿照 Tzc 那样从 Lyr 那里 git-clone 了 一 份 项 目 仓 库 ，
进行了一番卓有成效的版本更新。最后，Lyr 需要 一一 取回 其他 三人 的仓 库，然后 再
一一合并方能完成一个协同周期，这些工作逐渐让 Lyr 汗 流 浃 背 ，疲 于 应 付 。因 此
Lyr 希望其他三人能够分担一下项目版本合并问题的处理工作。
Git 提供了 git-pull 的对偶命令，即 git-push。顾名思义，git-pull 命 令 负 责 从
远端仓库取回版本更新，而 git-push 可将本地版本更新推送到远端仓库中。
利用 git-pull 与 git-push 命令，那么在一个协同周期之内，除了 Lyr 之外，其余
三人的项目开发流程大致如下：
$ git clone lyr@192.168.0.7:~/work/m2ge
... 项目开发 ...
$ git add 改动的文件
$ git commit
$ git pull
... 解决版本合并问题 ...
$ git push
在一个协同周期内，Lyr 对 M2GE 仓 库 的 管 理 工 作 相 当 于 管 理 一 份 他 个 人 项
目一般，因为 M2GE 库是位于他的机器上，他是不需要 git-pull 与 git-push 的。
这样，一个基于 Git 较 为 简 单 的 三 人 以 至 更 多 人 的 协 同 工 作 模 式 被 实 现 了 ，这
是我们在尚未熟悉 Git 应用之时比较稳妥的协同方案。下一节将基于这一方案讲述
M2GE 库仓库的建立以及多人协同开发过程的具体实现。
2.4 M2GE 的协同开发
上一节所给出的三人及三人以上的协同工作模式有些不合理，譬如 Lyr 过 于
特殊，别人都要 git-pull 与 git-push，唯 独 他 不 需 要 。现 在 要 剥 夺 他 的 这 一 特 权 ，最
有效的办法就是将 M2GE 仓库建立在实验室的服务器上。
-
13
首先，Lyr 通过 SSH 登录到服务器，寻找合适位置，建立 m2ge.git 目 录 ，譬 如
/project/m2ge.git ，然后初始化一个空仓库，以此作为 M2GE 仓库：
$ mkdir -p ~/project/m2ge.git
$ cd ~/project/m2ge.git
$ git --bare init --shared
上述操作中，git-init 命令的 --bare 选项可以让 m2ge.git 目 录 等 价 于 一 个 仓
库。也就是说，m2ge.git 本来是一个工作树，但是 --bare 选 项 将 本 应 当 存 放 在
m2ge.git/.git 中的仓库内容全部放置在 m2ge.git 目 录 下 ，就 好 像 仓 库 完 全 的 裸
露在工作树中，所以称之为赤裸的仓库。
然后，Lyr 将自己机器上已经接受 Git 管理的 m2ge 仓 库 推 送 到 服 务 器 端 的
m2ge.git 仓库：
$ cd ~/work/m2ge
$ git push m2@192.168.0.2:~/project/m2ge.git master
上述 git-push 命令中出现的 master 参 数 的 含 义 将 在 下 一 章 讲 述 ，此 处 可 略 过
不谈。现在，大家已经得到了 M2GE 仓库的最初版本，并且可以使用 git-clone 命 令
在本地创建工作目录：
$ git clone m2@192.168.0.2:~/project/m2ge.git
之后，我们就可以开始一个又一个协同周期，服务器上的 m2ge.git 仓 库 将 会 逐
次记录着每位协同开发者的版本更新提交，此基本过程可参考上一节所述内容来理
解。
2.5 总结
本章讲述了基于 Git 最基本的多人协同工作模式，并引入了三个新的 Git 命
令：git-clone、git-pull 与 git-push。基于这三个命令并配合上一章所讲述 Git 基本
操作，足以实现 M2GE 初级阶段的协同开发。
-
第 3 章 项目分支管理
Git 最 为 世 人 称 道 的 就 是 它 那 强 大 的 项 目 分 支 管 理 功 能 ，现 在 较 为 流 行 的 版 本
控制系统，诸如 CVS、SVN 等，虽然也提供了项目分支管理功能，但是可用性极低。
对于 Git 而言，管理多个项目分支如探囊取物耳。本章主要讲述 Git 的 项 目 分 支 管
理的基本知识以及如何利用这一功能形成更有章法的项目协同开发模式。
3.1 如何产生项目分支
前 两 章 所 讲 内 容 未 有 提 及 项 目 分 支 问 题 ，但 事 实 上 是 有 一 个 分 支 存 在 的 ，那 就
是 master 分支（主分支），该分支是由 Git 自 动 产 生 的 。在 此 之 前 ，我 们 针 对 项 目 版
本的各种操作都是在主分支上进行的，只是我们未察觉它的存在而已。
Git 可以轻松地产生新的项目分支，譬如下面操作可添加一个名曰“local”的
新的项目分支：
$ git branch local
对于新产生的 local 分支，初始时是完全等同于主分支的。但是，在 local 分 支
所 进 行 的 所 有 版 本 更 新 工 作 都 不 影 响 主 分 支 ，这 意 味 着 作 为 项 目 的 参 与 者 ，可 以 在
local 中开始各种各样的更新尝试。
查看项目仓库中存在多少分支，可直接使用 git-branch 命 令 ，譬 如 使 用 该 命 令
查看我的 M2Doc 项目分支列表：
$ git branch
local
* master
在上述操作输出结果中，若分支名之前存在 * 符号，表示此分支为当前分支。其
实 Git 各 分 支 不 存 在 尊 卑 之 别 ，只 存 在 哪 个 分 支 是 当 前 分 支 的 区 别 。为 了 某 种 良 好
的秩序，很多人默认是将 master 分支视为主分支，本文也将沿用这一潜在规则。
由上述操作输出的分支列表可以看出，虽然使用 git-branch 命 令 产 生 了
local 分支，但是 Git 不会自动将当前分支切换到 local 下。可使用 git-checkout 命
令实现分支切换，下面操作将当前分支切换为前文所产生的 local 分支：
$ git checkout local
-
15
3.2 分支的合并
我们产生了 local 分支，并在该分支下进行了诸多修改与数次的版本更新提交，
但是该如何将这一分支的最终状态提交到 master 分支中呢？
git-merge 命令可实现两个分支的合并。譬如我们将 local 分支与 master 分 支
合并，操作如下：
$ git checkout master # 将当前分支切换为master
$ git merge local # 将local分支与当前分支合并
当一个分支检查无误并且与 master 分 支 成 功 合 并 完 毕 后 ，那 么 这 一 分 支 基 本
上就没有存在的必要性了，可以删除掉：
$ git branch -d local
注意，git-branch 的 -d 选项 只能 删除 已经 参 与了 合并 的分 支 ，对于 未 有合 并 的
分支是无法删除的。如果想不问青红皂白地删除一个分支，可以使用 git-branch 的
-D 选项。
3.3 M2GE 新的协同开发模式
现在来讨论一下如何基于 Git 项 目 分 支 管 理 功 能 实 现 更 为 稳 健 、高 效 的
M2GE 库的协同开发机制。
实验室服务器上已经建立了 M2GE 仓库
1
。现在以 Lyr 作为主角，看一看他围绕
M2GE 开发工作的一天中的工作过程。
首先，Lyr 需 要 更 新 自 己 机 器 上 的 工 作 树 ，并 查 看 实 验 室 其 他 成 员 的 版 本 更 新
信息：
$ git pull
$ git log
然后，Lyr 开始建立一个新的项目分支，将其命名为 lyr，并 将 当 前 分 支 切 换 为
该分支：
$ git branch lyr
$ git checkout lyr
如有不解，请阅读第 2 章。
1
-
16
然后这一天中剩余的大部分时间，Lyr 都 在 自 己 所 建 立 的 项 目 分 支 上 工 作 ，譬
如增加了 3 个 新 的 接 口 及 相 关 测 试 程 序 ，并 对 原 有 接 口 做 了 一 些 修 改 。一 天 的 工 作
完成后，他有必要将这一天的工作与 M2GE 仓库的 master 分 支 进 行 合 并 ，然 后 删
除 lyr 分支：
$ git checkout
$ git merge lyr
$ git branch -d lyr
现在，Lyr 已经将这一天的工作反映到自己机器上的 M2GE master 分支上 了，
他最后要做的是将其推送到服务器的 M2GE 仓 库 ，以 使 项 目 其 他 成 员 能 够 分 享 他
的工作。这里要注意，在推送版本更新之前，需要使用 git-pull 命 令 将 这 一 天 中 其 他
成员对服务器端的 M2GE 的更新拉过来合并到自己的 master 分支，然后才可以将
自己的版本更新推送到服务器上的 M2GE 仓库，具体操作如下：
1. 使用 git-pull 命令更新本地工作树；
2. 若出现版本合并冲突，并且 Git 无法自动合并，需要手工合并，然后将合并结
果提交到本地 master 分支；
3. 使用 git-push 命令将本地 master 分支更新推送到服务器 M2GE 仓库中。
目前，对于我们而言，在基于 Git 的 M2GE 协 同 开 发 过 程 中 ，引 入 分 支 管 理
功能，可有效防止因个人操作不当而导致向服务器 M2GE 仓 库 提 交 太 多 的 脏 数
据。另外，也有效保持了本地项目主分支的干净，避免了频繁 git-clone 服 务 器 端 的
M2GE 仓库来恢复本地的项目主分支。
3.4 总结
本章讲述了 Git 项目分支管理的基本知识，并利用这些知识巩固了 M2GE 库
的协同开发机制。至此为止，诸位同学已经接触了 Git 的主要功能，并且已经具备了
向专业级别的开发团队过渡的基本能力。但是，工具毕竟是工具，并不能代替人的地
位，因此希望大家能够学以致用，积极妥善地在日常学习与工作中使用 Git，并 且
努力培养团队协同开发意识。
- -
- - - diff --git a/demo/demo.html b/demo/demo.html deleted file mode 100644 index ad61698..0000000 --- a/demo/demo.html +++ /dev/null @@ -1,335 +0,0 @@ - - - - - - - - - - - - - - -
- -
Trace-based Just-in-Time Type Specialization for Dynamic
Languages
Andreas Gal
∗ +
, Brendan Eich
∗
, Mike Shaver
∗
, David Anderson
∗
, David Mandelin
∗
,
Mohammad R. Haghighat
$
, Blake Kaplan
∗
, Graydon Hoare
∗
, Boris Zbarsky
∗
, Jason Orendorff
∗
,
Jesse Ruderman
∗
, Edwin Smith
#
, Rick Reitmaier
#
, Michael Bebenita
+
, Mason Chang
+ #
, Michael Franz
+
Mozilla Corporation
∗
{gal,brendan,shaver,danderson,dmandelin,mrbkap,graydon,bz,jorendorff,jruderman}@mozilla.com
Adobe Corporation
#
{edwsmith,rreitmai}@adobe.com
Intel Corporation
$
{mohammad.r.haghighat}@intel.com
University of California, Irvine
+
{mbebenit,changm,franz}@uci.edu
Abstract
Dynamic languages such as JavaScript are more difficult to com-
pile than statically typed ones. Since no concrete type information
is available, traditional compilers need to emit generic code that can
handle all possible type combinations at runtime. We present an al-
ternative compilation technique for dynamically-typed languages
that identifies frequently executed loop traces at run-time and then
generates machine code on the fly that is specialized for the ac-
tual dynamic types occurring on each path through the loop. Our
method provides cheap inter-procedural type specialization, and an
elegant and efficient way of incrementally compiling lazily discov-
ered alternative paths through nested loops. We have implemented
a dynamic compiler for JavaScript based on our technique and we
have measured speedups of 10x and more for certain benchmark
programs.
Categories and Subject Descriptors D.3.4 [Programming Lan-
guages]: Processors — Incremental compilers, code generation.
General Terms Design, Experimentation, Measurement, Perfor-
mance.
Keywords JavaScript, just-in-time compilation, trace trees.
1. Introduction
Dynamic languages such as JavaScript, Python, and Ruby, are pop-
ular since they are expressive, accessible to non-experts, and make
deployment as easy as distributing a source file. They are used for
small scripts as well as for complex applications. JavaScript, for
example, is the de facto standard for client-side web programming
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, to republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee.
PLDI’09, June 15–20, 2009, Dublin, Ireland.
Copyright
c
2009 ACM 978-1-60558-392-1/09/06. . . $5.00
and is used for the application logic of browser-based productivity
applications such as Google Mail, Google Docs and Zimbra Col-
laboration Suite. In this domain, in order to provide a fluid user
experience and enable a new generation of applications, virtual ma-
chines must provide a low startup time and high performance.
Compilers for statically typed languages rely on type informa-
tion to generate efficient machine code. In a dynamically typed pro-
gramming language such as JavaScript, the types of expressions
may vary at runtime. This means that the compiler can no longer
easily transform operations into machine instructions that operate
on one specific type. Without exact type information, the compiler
must emit slower generalized machine code that can deal with all
potential type combinations. While compile-time static type infer-
ence might be able to gather type information to generate opti-
mized machine code, traditional static analysis is very expensive
and hence not well suited for the highly interactive environment of
a web browser.
We present a trace-based compilation technique for dynamic
languages that reconciles speed of compilation with excellent per-
formance of the generated machine code. Our system uses a mixed-
mode execution approach: the system starts running JavaScript in a
fast-starting bytecode interpreter. As the program runs, the system
identifies hot (frequently executed) bytecode sequences, records
them, and compiles them to fast native code. We call such a se-
quence of instructions a trace.
Unlike method-based dynamic compilers, our dynamic com-
piler operates at the granularity of individual loops. This design
choice is based on the expectation that programs spend most of
their time in hot loops. Even in dynamically typed languages, we
expect hot loops to be mostly type-stable, meaning that the types of
values are invariant. (12) For example, we would expect loop coun-
ters that start as integers to remain integers for all iterations. When
both of these expectations hold, a trace-based compiler can cover
the program execution with a small number of type-specialized, ef-
ficiently compiled traces.
Each compiled trace covers one path through the program with
one mapping of values to types. When the VM executes a compiled
trace, it cannot guarantee that the same path will be followed
or that the same types will occur in subsequent loop iterations.
-
Hence, recording and compiling a trace speculates that the path and
typing will be exactly as they were during recording for subsequent
iterations of the loop.
Every compiled trace contains all the guards (checks) required
to validate the speculation. If one of the guards fails (if control
flow is different, or a value of a different type is generated), the
trace exits. If an exit becomes hot, the VM can record a branch
trace starting at the exit to cover the new path. In this way, the VM
records a trace tree covering all the hot paths through the loop.
Nested loops can be difficult to optimize for tracing VMs. In
a na
¨
ıve implementation, inner loops would become hot first, and
the VM would start tracing there. When the inner loop exits, the
VM would detect that a different branch was taken. The VM would
try to record a branch trace, and find that the trace reaches not the
inner loop header, but the outer loop header. At this point, the VM
could continue tracing until it reaches the inner loop header again,
thus tracing the outer loop inside a trace tree for the inner loop.
But this requires tracing a copy of the outer loop for every side exit
and type combination in the inner loop. In essence, this is a form
of unintended tail duplication, which can easily overflow the code
cache. Alternatively, the VM could simply stop tracing, and give up
on ever tracing outer loops.
We solve the nested loop problem by recording nested trace
trees. Our system traces the inner loop exactly as the na
¨
ıve version.
The system stops extending the inner tree when it reaches an outer
loop, but then it starts a new trace at the outer loop header. When
the outer loop reaches the inner loop header, the system tries to call
the trace tree for the inner loop. If the call succeeds, the VM records
the call to the inner tree as part of the outer trace and finishes
the outer trace as normal. In this way, our system can trace any
number of loops nested to any depth without causing excessive tail
duplication.
These techniques allow a VM to dynamically translate a pro-
gram to nested, type-specialized trace trees. Because traces can
cross function call boundaries, our techniques also achieve the ef-
fects of inlining. Because traces have no internal control-flow joins,
they can be optimized in linear time by a simple compiler (10).
Thus, our tracing VM efficiently performs the same kind of op-
timizations that would require interprocedural analysis in a static
optimization setting. This makes tracing an attractive and effective
tool to type specialize even complex function call-rich code.
We implemented these techniques for an existing JavaScript in-
terpreter, SpiderMonkey. We call the resulting tracing VM Trace-
Monkey. TraceMonkey supports all the JavaScript features of Spi-
derMonkey, with a 2x-20x speedup for traceable programs.
This paper makes the following contributions:
•
We explain an algorithm for dynamically forming trace trees to
cover a program, representing nested loops as nested trace trees.
•
We explain how to speculatively generate efficient type-specialized
code for traces from dynamic language programs.
•
We validate our tracing techniques in an implementation based
on the SpiderMonkey JavaScript interpreter, achieving 2x-20x
speedups on many programs.
The remainder of this paper is organized as follows. Section 3 is
a general overview of trace tree based compilation we use to cap-
ture and compile frequently executed code regions. In Section 4
we describe our approach of covering nested loops using a num-
ber of individual trace trees. In Section 5 we describe our trace-
compilation based speculative type specialization approach we use
to generate efficient machine code from recorded bytecode traces.
Our implementation of a dynamic type-specializing compiler for
JavaScript is described in Section 6. Related work is discussed in
Section 8. In Section 7 we evaluate our dynamic compiler based on
1 for (var i = 2; i < 100; ++i) {
2 if (!primes[i])
3 continue;
4 for (var k = i + i; i < 100; k += i)
5 primes[k] = false;
6 }
Figure 1. Sample program: sieve of Eratosthenes. primes is
initialized to an array of 100 false values on entry to this code
snippet.
Interpret
Bytecodes
Monitor
Record
LIR Trace
Execute
Compiled Trace
Enter
Compiled Trace
Compile
LIR Trace
Leave
Compiled Trace
loop
edge
hot
loop/exit
abort
recording
finish at
loop header
cold/blacklisted
loop/exit
compiled trace
ready
loop edge with
same types
side exit to
existing trace
side exit,
no existing trace
Overhead
Interpreting
Native
Symbol Key
Figure 2. State machine describing the major activities of Trace-
Monkey and the conditions that cause transitions to a new activ-
ity. In the dark box, TM executes JS as compiled traces. In the
light gray boxes, TM executes JS in the standard interpreter. White
boxes are overhead. Thus, to maximize performance, we need to
maximize time spent in the darkest box and minimize time spent in
the white boxes. The best case is a loop where the types at the loop
edge are the same as the types on entry–then TM can stay in native
code until the loop is done.
a set of industry benchmarks. The paper ends with conclusions in
Section 9 and an outlook on future work is presented in Section 10.
2. Overview: Example Tracing Run
This section provides an overview of our system by describing
how TraceMonkey executes an example program. The example
program, shown in Figure 1, computes the first 100 prime numbers
with nested loops. The narrative should be read along with Figure 2,
which describes the activities TraceMonkey performs and when it
transitions between the loops.
TraceMonkey always begins executing a program in the byte-
code interpreter. Every loop back edge is a potential trace point.
When the interpreter crosses a loop edge, TraceMonkey invokes
the trace monitor, which may decide to record or execute a native
trace. At the start of execution, there are no compiled traces yet, so
the trace monitor counts the number of times each loop back edge is
executed until a loop becomes hot, currently after 2 crossings. Note
that the way our loops are compiled, the loop edge is crossed before
entering the loop, so the second crossing occurs immediately after
the first iteration.
Here is the sequence of events broken down by outer loop
iteration:
-
v0 := ld state[748] // load primes from the trace activation record
st sp[0], v0 // store primes to interpreter stack
v1 := ld state[764] // load k from the trace activation record
v2 := i2f(v1) // convert k from int to double
st sp[8], v1 // store k to interpreter stack
st sp[16], 0 // store false to interpreter stack
v3 := ld v0[4] // load class word for primes
v4 := and v3, -4 // mask out object class tag for primes
v5 := eq v4, Array // test whether primes is an array
xf v5 // side exit if v5 is false
v6 := js_Array_set(v0, v2, false) // call function to set array element
v7 := eq v6, 0 // test return value from call
xt v7 // side exit if js_Array_set returns false.
Figure 3. LIR snippet for sample program. This is the LIR recorded for line 5 of the sample program in Figure 1. The LIR encodes
the semantics in SSA form using temporary variables. The LIR also encodes all the stores that the interpreter would do to its data stack.
Sometimes these stores can be optimized away as the stack locations are live only on exits to the interpreter. Finally, the LIR records guards
and side exits to verify the assumptions made in this recording: that primes is an array and that the call to set its element succeeds.
mov edx, ebx(748) // load primes from the trace activation record
mov edi(0), edx // (*) store primes to interpreter stack
mov esi, ebx(764) // load k from the trace activation record
mov edi(8), esi // (*) store k to interpreter stack
mov edi(16), 0 // (*) store false to interpreter stack
mov eax, edx(4) // (*) load object class word for primes
and eax, -4 // (*) mask out object class tag for primes
cmp eax, Array // (*) test whether primes is an array
jne side_exit_1 // (*) side exit if primes is not an array
sub esp, 8 // bump stack for call alignment convention
push false // push last argument for call
push esi // push first argument for call
call js_Array_set // call function to set array element
add esp, 8 // clean up extra stack space
mov ecx, ebx // (*) created by register allocator
test eax, eax // (*) test return value of js_Array_set
je side_exit_2 // (*) side exit if call failed
...
side_exit_1:
mov ecx, ebp(-4) // restore ecx
mov esp, ebp // restore esp
jmp epilog // jump to ret statement
Figure 4. x86 snippet for sample program. This is the x86 code compiled from the LIR snippet in Figure 3. Most LIR instructions compile
to a single x86 instruction. Instructions marked with (*) would be omitted by an idealized compiler that knew that none of the side exits
would ever be taken. The 17 instructions generated by the compiler compare favorably with the 100+ instructions that the interpreter would
execute for the same code snippet, including 4 indirect jumps.
i=2. This is the first iteration of the outer loop. The loop on
lines 4-5 becomes hot on its second iteration, so TraceMonkey en-
ters recording mode on line 4. In recording mode, TraceMonkey
records the code along the trace in a low-level compiler intermedi-
ate representation we call LIR. The LIR trace encodes all the oper-
ations performed and the types of all operands. The LIR trace also
encodes guards, which are checks that verify that the control flow
and types are identical to those observed during trace recording.
Thus, on later executions, if and only if all guards are passed, the
trace has the required program semantics.
TraceMonkey stops recording when execution returns to the
loop header or exits the loop. In this case, execution returns to the
loop header on line 4.
After recording is finished, TraceMonkey compiles the trace to
native code using the recorded type information for optimization.
The result is a native code fragment that can be entered if the
interpreter PC and the types of values match those observed when
trace recording was started. The first trace in our example, T
45
,
covers lines 4 and 5. This trace can be entered if the PC is at line 4,
i and k are integers, and primes is an object. After compiling T
45
,
TraceMonkey returns to the interpreter and loops back to line 1.
i=3. Now the loop header at line 1 has become hot, so Trace-
Monkey starts recording. When recording reaches line 4, Trace-
Monkey observes that it has reached an inner loop header that al-
ready has a compiled trace, so TraceMonkey attempts to nest the
inner loop inside the current trace. The first step is to call the inner
trace as a subroutine. This executes the loop on line 4 to completion
and then returns to the recorder. TraceMonkey verifies that the call
was successful and then records the call to the inner trace as part of
the current trace. Recording continues until execution reaches line
1, and at which point TraceMonkey finishes and compiles a trace
for the outer loop, T
16
.
-
i=4. On this iteration, TraceMonkey calls T
16
. Because i=4, the
if statement on line 2 is taken. This branch was not taken in the
original trace, so this causes T
16
to fail a guard and take a side exit.
The exit is not yet hot, so TraceMonkey returns to the interpreter,
which executes the continue statement.
i=5. TraceMonkey calls T
16
, which in turn calls the nested trace
T
45
. T
16
loops back to its own header, starting the next iteration
without ever returning to the monitor.
i=6. On this iteration, the side exit on line 2 is taken again. This
time, the side exit becomes hot, so a trace T
23,1
is recorded that
covers line 3 and returns to the loop header. Thus, the end of T
23,1
jumps directly to the start of T
16
. The side exit is patched so that
on future iterations, it jumps directly to T
23,1
.
At this point, TraceMonkey has compiled enough traces to cover
the entire nested loop structure, so the rest of the program runs
entirely as native code.
3. Trace Trees
In this section, we describe traces, trace trees, and how they are
formed at run time. Although our techniques apply to any dynamic
language interpreter, we will describe them assuming a bytecode
interpreter to keep the exposition simple.
3.1 Traces
A trace is simply a program path, which may cross function call
boundaries. TraceMonkey focuses on loop traces, that originate at
a loop edge and represent a single iteration through the associated
loop.
Similar to an extended basic block, a trace is only entered at
the top, but may have many exits. In contrast to an extended basic
block, a trace can contain join nodes. Since a trace always only
follows one single path through the original program, however, join
nodes are not recognizable as such in a trace and have a single
predecessor node like regular nodes.
A typed trace is a trace annotated with a type for every variable
(including temporaries) on the trace. A typed trace also has an entry
type map giving the required types for variables used on the trace
before they are defined. For example, a trace could have a type map
(x: int, b: boolean), meaning that the trace may be entered
only if the value of the variable x is of type int and the value of b
is of type boolean. The entry type map is much like the signature
of a function.
In this paper, we only discuss typed loop traces, and we will
refer to them simply as “traces”. The key property of typed loop
traces is that they can be compiled to efficient machine code using
the same techniques used for typed languages.
In TraceMonkey, traces are recorded in trace-flavored SSA LIR
(low-level intermediate representation). In trace-flavored SSA (or
TSSA), phi nodes appear only at the entry point, which is reached
both on entry and via loop edges. The important LIR primitives
are constant values, memory loads and stores (by address and
offset), integer operators, floating-point operators, function calls,
and conditional exits. Type conversions, such as integer to double,
are represented by function calls. This makes the LIR used by
TraceMonkey independent of the concrete type system and type
conversion rules of the source language. The LIR operations are
generic enough that the backend compiler is language independent.
Figure 3 shows an example LIR trace.
Bytecode interpreters typically represent values in a various
complex data structures (e.g., hash tables) in a boxed format (i.e.,
with attached type tag bits). Since a trace is intended to represent
efficient code that eliminates all that complexity, our traces oper-
ate on unboxed values in simple variables and arrays as much as
possible.
A trace records all its intermediate values in a small activation
record area. To make variable accesses fast on trace, the trace also
imports local and global variables by unboxing them and copying
them to its activation record. Thus, the trace can read and write
these variables with simple loads and stores from a native activation
recording, independently of the boxing mechanism used by the
interpreter. When the trace exits, the VM boxes the values from
this native storage location and copies them back to the interpreter
structures.
For every control-flow branch in the source program, the
recorder generates conditional exit LIR instructions. These instruc-
tions exit from the trace if required control flow is different from
what it was at trace recording, ensuring that the trace instructions
are run only if they are supposed to. We call these instructions
guard instructions.
Most of our traces represent loops and end with the special loop
LIR instruction. This is just an unconditional branch to the top of
the trace. Such traces return only via guards.
Now, we describe the key optimizations that are performed as
part of recording LIR. All of these optimizations reduce complex
dynamic language constructs to simple typed constructs by spe-
cializing for the current trace. Each optimization requires guard in-
structions to verify their assumptions about the state and exit the
trace if necessary.
Type specialization.
All LIR primitives apply to operands of specific types. Thus,
LIR traces are necessarily type-specialized, and a compiler can
easily produce a translation that requires no type dispatches. A
typical bytecode interpreter carries tag bits along with each value,
and to perform any operation, must check the tag bits, dynamically
dispatch, mask out the tag bits to recover the untagged value,
perform the operation, and then reapply tags. LIR omits everything
except the operation itself.
A potential problem is that some operations can produce values
of unpredictable types. For example, reading a property from an
object could yield a value of any type, not necessarily the type
observed during recording. The recorder emits guard instructions
that conditionally exit if the operation yields a value of a different
type from that seen during recording. These guard instructions
guarantee that as long as execution is on trace, the types of values
match those of the typed trace. When the VM observes a side exit
along such a type guard, a new typed trace is recorded originating
at the side exit location, capturing the new type of the operation in
question.
Representation specialization: objects. In JavaScript, name
lookup semantics are complex and potentially expensive because
they include features like object inheritance and eval. To evaluate
an object property read expression like o.x, the interpreter must
search the property map of o and all of its prototypes and parents.
Property maps can be implemented with different data structures
(e.g., per-object hash tables or shared hash tables), so the search
process also must dispatch on the representation of each object
found during search. TraceMonkey can simply observe the result of
the search process and record the simplest possible LIR to access
the property value. For example, the search might finds the value of
o.x in the prototype of o, which uses a shared hash-table represen-
tation that places x in slot 2 of a property vector. Then the recorded
can generate LIR that reads o.x with just two or three loads: one to
get the prototype, possibly one to get the property value vector, and
one more to get slot 2 from the vector. This is a vast simplification
and speedup compared to the original interpreter code. Inheritance
relationships and object representations can change during execu-
tion, so the simplified code requires guard instructions that ensure
the object representation is the same. In TraceMonkey, objects’ rep-
-
resentations are assigned an integer key called the object shape.
Thus, the guard is a simple equality check on the object shape.
Representation specialization: numbers. JavaScript has no
integer type, only a Number type that is the set of 64-bit IEEE-
754 floating-pointer numbers (“doubles”). But many JavaScript
operators, in particular array accesses and bitwise operators, really
operate on integers, so they first convert the number to an integer,
and then convert any integer result back to a double.
1
Clearly, a
JavaScript VM that wants to be fast must find a way to operate on
integers directly and avoid these conversions.
In TraceMonkey, we support two representations for numbers:
integers and doubles. The interpreter uses integer representations
as much as it can, switching for results that can only be represented
as doubles. When a trace is started, some values may be imported
and represented as integers. Some operations on integers require
guards. For example, adding two integers can produce a value too
large for the integer representation.
Function inlining. LIR traces can cross function boundaries
in either direction, achieving function inlining. Move instructions
need to be recorded for function entry and exit to copy arguments
in and return values out. These move statements are then optimized
away by the compiler using copy propagation. In order to be able
to return to the interpreter, the trace must also generate LIR to
record that a call frame has been entered and exited. The frame
entry and exit LIR saves just enough information to allow the
intepreter call stack to be restored later and is much simpler than
the interpreter’s standard call code. If the function being entered
is not constant (which in JavaScript includes any call by function
name), the recorder must also emit LIR to guard that the function
is the same.
Guards and side exits. Each optimization described above
requires one or more guards to verify the assumptions made in
doing the optimization. A guard is just a group of LIR instructions
that performs a test and conditional exit. The exit branches to a
side exit, a small off-trace piece of LIR that returns a pointer to
a structure that describes the reason for the exit along with the
interpreter PC at the exit point and any other data needed to restore
the interpreter’s state structures.
Aborts. Some constructs are difficult to record in LIR traces.
For example, eval or calls to external functions can change the
program state in unpredictable ways, making it difficult for the
tracer to know the current type map in order to continue tracing.
A tracing implementation can also have any number of other limi-
tations, e.g.,a small-memory device may limit the length of traces.
When any situation occurs that prevents the implementation from
continuing trace recording, the implementation aborts trace record-
ing and returns to the trace monitor.
3.2 Trace Trees
Especially simple loops, namely those where control flow, value
types, value representations, and inlined functions are all invariant,
can be represented by a single trace. But most loops have at least
some variation, and so the program will take side exits from the
main trace. When a side exit becomes hot, TraceMonkey starts a
new branch trace from that point and patches the side exit to jump
directly to that trace. In this way, a single trace expands on demand
to a single-entry, multiple-exit trace tree.
This section explains how trace trees are formed during execu-
tion. The goal is to form trace trees during execution that cover all
the hot paths of the program.
1
Arrays are actually worse than this: if the index value is a number, it must
be converted from a double to a string for the property access operator, and
then to an integer internally to the array implementation.
Starting a tree. Tree trees always start at loop headers, because
they are a natural place to look for hot paths. In TraceMonkey, loop
headers are easy to detect–the bytecode compiler ensures that a
bytecode is a loop header iff it is the target of a backward branch.
TraceMonkey starts a tree when a given loop header has been exe-
cuted a certain number of times (2 in the current implementation).
Starting a tree just means starting recording a trace for the current
point and type map and marking the trace as the root of a tree. Each
tree is associated with a loop header and type map, so there may be
several trees for a given loop header.
Closing the loop. Trace recording can end in several ways.
Ideally, the trace reaches the loop header where it started with
the same type map as on entry. This is called a type-stable loop
iteration. In this case, the end of the trace can jump right to the
beginning, as all the value representations are exactly as needed to
enter the trace. The jump can even skip the usual code that would
copy out the state at the end of the trace and copy it back in to the
trace activation record to enter a trace.
In certain cases the trace might reach the loop header with a
different type map. This scenario is sometime observed for the first
iteration of a loop. Some variables inside the loop might initially be
undefined, before they are set to a concrete type during the first loop
iteration. When recording such an iteration, the recorder cannot
link the trace back to its own loop header since it is type-unstable.
Instead, the iteration is terminated with a side exit that will always
fail and return to the interpreter. At the same time a new trace is
recorded with the new type map. Every time an additional type-
unstable trace is added to a region, its exit type map is compared to
the entry map of all existing traces in case they complement each
other. With this approach we are able to cover type-unstable loop
iterations as long they eventually form a stable equilibrium.
Finally, the trace might exit the loop before reaching the loop
header, for example because execution reaches a break or return
statement. In this case, the VM simply ends the trace with an exit
to the trace monitor.
As mentioned previously, we may speculatively chose to rep-
resent certain Number-typed values as integers on trace. We do so
when we observe that Number-typed variables contain an integer
value at trace entry. If during trace recording the variable is unex-
pectedly assigned a non-integer value, we have to widen the type
of the variable to a double. As a result, the recorded trace becomes
inherently type-unstable since it starts with an integer value but
ends with a double value. This represents a mis-speculation, since
at trace entry we specialized the Number-typed value to an integer,
assuming that at the loop edge we would again find an integer value
in the variable, allowing us to close the loop. To avoid future spec-
ulative failures involving this variable, and to obtain a type-stable
trace we note the fact that the variable in question as been observed
to sometimes hold non-integer values in an advisory data structure
which we call the “oracle”.
When compiling loops, we consult the oracle before specializ-
ing values to integers. Speculation towards integers is performed
only if no adverse information is known to the oracle about that
particular variable. Whenever we accidentally compile a loop that
is type-unstable due to mis-speculation of a Number-typed vari-
able, we immediately trigger the recording of a new trace, which
based on the now updated oracle information will start with a dou-
ble value and thus become type stable.
Extending a tree. Side exits lead to different paths through
the loop, or paths with different types or representations. Thus, to
completely cover the loop, the VM must record traces starting at all
side exits. These traces are recorded much like root traces: there is
a counter for each side exit, and when the counter reaches a hotness
threshold, recording starts. Recording stops exactly as for the root
trace, using the loop header of the root trace as the target to reach.
-
Our implementation does not extend at all side exits. It extends
only if the side exit is for a control-flow branch, and only if the side
exit does not leave the loop. In particular we do not want to extend
a trace tree along a path that leads to an outer loop, because we
want to cover such paths in an outer tree through tree nesting.
3.3 Blacklisting
Sometimes, a program follows a path that cannot be compiled
into a trace, usually because of limitations in the implementation.
TraceMonkey does not currently support recording throwing and
catching of arbitrary exceptions. This design trade off was chosen,
because exceptions are usually rare in JavaScript. However, if a
program opts to use exceptions intensively, we would suddenly
incur a punishing runtime overhead if we repeatedly try to record
a trace for this path and repeatedly fail to do so, since we abort
tracing every time we observe an exception being thrown.
As a result, if a hot loop contains traces that always fail, the VM
could potentially run much more slowly than the base interpreter:
the VM repeatedly spends time trying to record traces, but is never
able to run any. To avoid this problem, whenever the VM is about
to start tracing, it must try to predict whether it will finish the trace.
Our prediction algorithm is based on blacklisting traces that
have been tried and failed. When the VM fails to finish a trace start-
ing at a given point, the VM records that a failure has occurred. The
VM also sets a counter so that it will not try to record a trace starting
at that point until it is passed a few more times (32 in our imple-
mentation). This backoff counter gives temporary conditions that
prevent tracing a chance to end. For example, a loop may behave
differently during startup than during its steady-state execution. Af-
ter a given number of failures (2 in our implementation), the VM
marks the fragment as blacklisted, which means the VM will never
again start recording at that point.
After implementing this basic strategy, we observed that for
small loops that get blacklisted, the system can spend a noticeable
amount of time just finding the loop fragment and determining that
it has been blacklisted. We now avoid that problem by patching the
bytecode. We define an extra no-op bytecode that indicates a loop
header. The VM calls into the trace monitor every time the inter-
preter executes a loop header no-op. To blacklist a fragment, we
simply replace the loop header no-op with a regular no-op. Thus,
the interpreter will never again even call into the trace monitor.
There is a related problem we have not yet solved, which occurs
when a loop meets all of these conditions:
•
The VM can form at least one root trace for the loop.
•
There is at least one hot side exit for which the VM cannot
complete a trace.
•
The loop body is short.
In this case, the VM will repeatedly pass the loop header, search
for a trace, find it, execute it, and fall back to the interpreter.
With a short loop body, the overhead of finding and calling the
trace is high, and causes performance to be even slower than the
basic interpreter. So far, in this situation we have improved the
implementation so that the VM can complete the branch trace.
But it is hard to guarantee that this situation will never happen.
As future work, this situation could be avoided by detecting and
blacklisting loops for which the average trace call executes few
bytecodes before returning to the interpreter.
4. Nested Trace Tree Formation
Figure 7 shows basic trace tree compilation (11) applied to a nested
loop where the inner loop contains two paths. Usually, the inner
loop (with header at i
2
) becomes hot first, and a trace tree is rooted
at that point. For example, the first recorded trace may be a cycle
T
Trunk
Trace
Tree
Anchor
Trace
Anchor
Branch
Trace
Guard
Side
Exit
Figure 5. A tree with two traces, a trunk trace and one branch
trace. The trunk trace contains a guard to which a branch trace was
attached. The branch trace contain a guard that may fail and trigger
a side exit. Both the trunk and the branch trace loop back to the tree
anchor, which is the beginning of the trace tree.
Trace
2
Trace
1 Trace
2Trace
1
Closed
Linked Linked Linked
Number
Number
String
String
String
String
Boolean
Trace
2Trace
1 Trace
3
Linked
Linked Linked
Closed
Number
Number Number
Boolean Number
Boolean Number
Boolean
(a)
(b)
(c)
Figure 6. We handle type-unstable loops by allowing traces to
compile that cannot loop back to themselves due to a type mis-
match. As such traces accumulate, we attempt to connect their loop
edges to form groups of trace trees that can execute without having
to side-exit to the interpreter to cover odd type cases. This is par-
ticularly important for nested trace trees where an outer tree tries to
call an inner tree (or in this case a forest of inner trees), since inner
loops frequently have initially undefined values which change type
to a concrete value after the first iteration.
through the inner loop, {i
2
, i
3
, i
5
,α}. The α symbol is used to
indicate that the trace loops back the tree anchor.
When execution leaves the inner loop, the basic design has two
choices. First, the system can stop tracing and give up on compiling
the outer loop, clearly an undesirable solution. The other choice is
to continue tracing, compiling traces for the outer loop inside the
inner loop’s trace tree.
For example, the program might exit at i
5
and record a branch
trace that incorporates the outer loop: {i
5
, i
7
, i
1
, i
6
, i
7
, i
1
,α}.
Later, the program might take the other branch at i
2
and then
exit, recording another branch trace incorporating the outer loop:
{i
2
, i
4
, i
5
, i
7
, i
1
, i
6
, i
7
, i
1
,α}. Thus, the outer loop is recorded and
compiled twice, and both copies must be retained in the trace cache.
-
i
2
i
3
i
4
i
5
i
1
i
6
i
7
t
1
t
2
Tree
Call
Outer
Tree
Nested
Tree
Exit
Guard
(a)
(b)
Figure 7. Control flow graph of a nested loop with an if statement
inside the inner most loop (a). An inner tree captures the inner
loop, and is nested inside an outer tree which “calls” the inner tree.
The inner tree returns to the outer tree once it exits along its loop
condition guard (b).
In general, if loops are nested to depth k, and each loop has n paths
(on geometric average), this na
¨
ıve strategy yields O(n
k
) traces,
which can easily fill the trace cache.
In order to execute programs with nested loops efficiently, a
tracing system needs a technique for covering the nested loops with
native code without exponential trace duplication.
4.1 Nesting Algorithm
The key insight is that if each loop is represented by its own trace
tree, the code for each loop can be contained only in its own tree,
and outer loop paths will not be duplicated. Another key fact is that
we are not tracing arbitrary bytecodes that might have irreduceable
control flow graphs, but rather bytecodes produced by a compiler
for a language with structured control flow. Thus, given two loop
edges, the system can easily determine whether they are nested
and which is the inner loop. Using this knowledge, the system can
compile inner and outer loops separately, and make the outer loop’s
traces call the inner loop’s trace tree.
The algorithm for building nested trace trees is as follows. We
start tracing at loop headers exactly as in the basic tracing system.
When we exit a loop (detected by comparing the interpreter PC
with the range given by the loop edge), we stop the trace. The
key step of the algorithm occurs when we are recording a trace
for loop L
R
(R for loop being recorded) and we reach the header
of a different loop L
O
(O for other loop). Note that L
O
must be an
inner loop of L
R
because we stop the trace when we exit a loop.
•
If L
O
has a type-matching compiled trace tree, we call L
O
as
a nested trace tree. If the call succeeds, then we record the call
in the trace for L
R
. On future executions, the trace for L
R
will
call the inner trace directly.
•
If L
O
does not have a type-matching compiled trace tree yet,
we have to obtain it before we are able to proceed. In order
to do this, we simply abort recording the first trace. The trace
monitor will see the inner loop header, and will immediately
start recording the inner loop.
2
If all the loops in a nest are type-stable, then loop nesting creates
no duplication. Otherwise, if loops are nested to a depth k , and each
2
Instead of aborting the outer recording, we could principally merely sus-
pend the recording, but that would require the implementation to be able
to record several traces simultaneously, complicating the implementation,
while saving only a few iterations in the interpreter.
i
2
i
3
i
1
i
6
i
4
i
5
t
2
t
1
t
4
Exit
Guard
Nested
Tree
Figure 8. Control flow graph of a loop with two nested loops (left)
and its nested trace tree configuration (right). The outer tree calls
the two inner nested trace trees and places guards at their side exit
locations.
loop is entered with m different type maps (on geometric average),
then we compile O(m
k
) copies of the innermost loop. As long as
m is close to 1, the resulting trace trees will be tractable.
An important detail is that the call to the inner trace tree must act
like a function call site: it must return to the same point every time.
The goal of nesting is to make inner and outer loops independent;
thus when the inner tree is called, it must exit to the same point
in the outer tree every time with the same type map. Because we
cannot actually guarantee this property, we must guard on it after
the call, and side exit if the property does not hold. A common
reason for the inner tree not to return to the same point would
be if the inner tree took a new side exit for which it had never
compiled a trace. At this point, the interpreter PC is in the inner
tree, so we cannot continue recording or executing the outer tree.
If this happens during recording, we abort the outer trace, to give
the inner tree a chance to finish growing. A future execution of the
outer tree would then be able to properly finish and record a call to
the inner tree. If an inner tree side exit happens during execution of
a compiled trace for the outer tree, we simply exit the outer trace
and start recording a new branch in the inner tree.
4.2 Blacklisting with Nesting
The blacklisting algorithm needs modification to work well with
nesting. The problem is that outer loop traces often abort during
startup (because the inner tree is not available or takes a side exit),
which would lead to their being quickly blacklisted by the basic
algorithm.
The key observation is that when an outer trace aborts because
the inner tree is not ready, this is probably a temporary condition.
Thus, we should not count such aborts toward blacklisting as long
as we are able to build up more traces for the inner tree.
In our implementation, when an outer tree aborts on the inner
tree, we increment the outer tree’s blacklist counter as usual and
back off on compiling it. When the inner tree finishes a trace, we
decrement the blacklist counter on the outer loop, “forgiving” the
outer loop for aborting previously. We also undo the backoff so that
the outer tree can start immediately trying to compile the next time
we reach it.
5. Trace Tree Optimization
This section explains how a recorded trace is translated to an
optimized machine code trace. The trace compilation subsystem,
NANOJIT , is separate from the VM and can be used for other
applications.
-
5.1 Optimizations
Because traces are in SSA form and have no join points or φ-
nodes, certain optimizations are easy to implement. In order to
get good startup performance, the optimizations must run quickly,
so we chose a small set of optimizations. We implemented the
optimizations as pipelined filters so that they can be turned on and
off independently, and yet all run in just two loop passes over the
trace: one forward and one backward.
Every time the trace recorder emits a LIR instruction, the in-
struction is immediately passed to the first filter in the forward
pipeline. Thus, forward filter optimizations are performed as the
trace is recorded. Each filter may pass each instruction to the next
filter unchanged, write a different instruction to the next filter, or
write no instruction at all. For example, the constant folding filter
can replace a multiply instruction like v
13
:= mul3, 1000 with a
constant instruction v
13
= 3000.
We currently apply four forward filters:
•
On ISAs without floating-point instructions, a soft-float filter
converts floating-point LIR instructions to sequences of integer
instructions.
•
CSE (constant subexpression elimination),
•
expression simplification, including constant folding and a few
algebraic identities (e.g., a − a = 0), and
•
source language semantic-specific expression simplification,
primarily algebraic identities that allow DOUBLE to be replaced
with INT. For example, LIR that converts an INT to a D O U B L E
and then back again would be removed by this filter.
When trace recording is completed, nanojit runs the backward
optimization filters. These are used for optimizations that require
backward program analysis. When running the backward filters,
nanojit reads one LIR instruction at a time, and the reads are passed
through the pipeline.
We currently apply three backward filters:
•
Dead data-stack store elimination. The LIR trace encodes many
stores to locations in the interpreter stack. But these values are
never read back before exiting the trace (by the interpreter or
another trace). Thus, stores to the stack that are overwritten
before the next exit are dead. Stores to locations that are off
the top of the interpreter stack at future exits are also dead.
•
Dead call-stack store elimination. This is the same optimization
as above, except applied to the interpreter’s call stack used for
function call inlining.
•
Dead code elimination. This eliminates any operation that
stores to a value that is never used.
After a LIR instruction is successfully read (“pulled”) from
the backward filter pipeline, nanojit’s code generator emits native
machine instruction(s) for it.
5.2 Register Allocation
We use a simple greedy register allocator that makes a single
backward pass over the trace (it is integrated with the code gen-
erator). By the time the allocator has reached an instruction like
v
3
= add v
1
, v
2
, it has already assigned a register to v
3
. If v
1
and
v
2
have not yet been assigned registers, the allocator assigns a free
register to each. If there are no free registers, a value is selected for
spilling. We use a class heuristic that selects the “oldest” register-
carried value (6).
The heuristic considers the set R of values v in registers imme-
diately after the current instruction for spilling. Let v
m
be the last
instruction before the current where each v is referred to. Then the
Tag JS Type Description
xx1 number 31-bit integer representation
000 object pointer to JSObject handle
010 number pointer to double handle
100 string pointer to JSString handle
110 boolean enumeration for null, undefined, true, false
null, or
undefined
Figure 9. Tagged values in the SpiderMonkey JS interpreter.
Testing tags, unboxing (extracting the untagged value) and boxing
(creating tagged values) are significant costs. Avoiding these costs
is a key benefit of tracing.
heuristic selects v with minimum v
m
. The motivation is that this
frees up a register for as long as possible given a single spill.
If we need to spill a value v
s
at this point, we generate the
restore code just after the code for the current instruction. The
corresponding spill code is generated just after the last point where
v
s
was used. The register that was assigned to v
s
is marked free for
the preceding code, because that register can now be used freely
without affecting the following code
6. Implementation
To demonstrate the effectiveness of our approach, we have im-
plemented a trace-based dynamic compiler for the SpiderMonkey
JavaScript Virtual Machine (4). SpiderMonkey is the JavaScript
VM embedded in Mozilla’s Firefox open-source web browser (2),
which is used by more than 200 million users world-wide. The core
of SpiderMonkey is a bytecode interpreter implemented in C++.
In SpiderMonkey, all JavaScript values are represented by the
type jsval. A jsval is machine word in which up to the 3 of the
least significant bits are a type tag, and the remaining bits are data.
See Figure 6 for details. All pointers contained in jsvals point to
GC-controlled blocks aligned on 8-byte boundaries.
JavaScript object values are mappings of string-valued property
names to arbitrary values. They are represented in one of two ways
in SpiderMonkey. Most objects are represented by a shared struc-
tural description, called the object shape, that maps property names
to array indexes using a hash table. The object stores a pointer to
the shape and the array of its own property values. Objects with
large, unique sets of property names store their properties directly
in a hash table.
The garbage collector is an exact, non-generational, stop-the-
world mark-and-sweep collector.
In the rest of this section we discuss key areas of the TraceMon-
key implementation.
6.1 Calling Compiled Traces
Compiled traces are stored in a trace cache, indexed by intepreter
PC and type map. Traces are compiled so that they may be
called as functions using standard native calling conventions (e.g.,
FASTCALL on x86).
The interpreter must hit a loop edge and enter the monitor in
order to call a native trace for the first time. The monitor computes
the current type map, checks the trace cache for a trace for the
current PC and type map, and if it finds one, executes the trace.
To execute a trace, the monitor must build a trace activation
record containing imported local and global variables, temporary
stack space, and space for arguments to native calls. The local and
global values are then copied from the interpreter state to the trace
activation record. Then, the trace is called like a normal C function
pointer.
-
When a trace call returns, the monitor restores the interpreter
state. First, the monitor checks the reason for the trace exit and
applies blacklisting if needed. Then, it pops or synthesizes inter-
preter JavaScript call stack frames as needed. Finally, it copies the
imported variables back from the trace activation record to the in-
terpreter state.
At least in the current implementation, these steps have a non-
negligible runtime cost, so minimizing the number of interpreter-
to-trace and trace-to-interpreter transitions is essential for perfor-
mance. (see also Section 3.3). Our experiments (see Figure 12)
show that for programs we can trace well such transitions hap-
pen infrequently and hence do not contribute significantly to total
runtime. In a few programs, where the system is prevented from
recording branch traces for hot side exits by aborts, this cost can
rise to up to 10% of total execution time.
6.2 Trace Stitching
Transitions from a trace to a branch trace at a side exit avoid the
costs of calling traces from the monitor, in a feature called trace
stitching. At a side exit, the exiting trace only needs to write live
register-carried values back to its trace activation record. In our im-
plementation, identical type maps yield identical activation record
layouts, so the trace activation record can be reused immediately
by the branch trace.
In programs with branchy trace trees with small traces, trace
stitching has a noticeable cost. Although writing to memory and
then soon reading back would be expected to have a high L1
cache hit rate, for small traces the increased instruction count has
a noticeable cost. Also, if the writes and reads are very close
in the dynamic instruction stream, we have found that current
x86 processors often incur penalties of 6 cycles or more (e.g., if
the instructions use different base registers with equal values, the
processor may not be able to detect that the addresses are the same
right away).
The alternate solution is to recompile an entire trace tree, thus
achieving inter-trace register allocation (10). The disadvantage is
that tree recompilation takes time quadratic in the number of traces.
We believe that the cost of recompiling a trace tree every time
a branch is added would be prohibitive. That problem might be
mitigated by recompiling only at certain points, or only for very
hot, stable trees.
In the future, multicore hardware is expected to be common,
making background tree recompilation attractive. In a closely re-
lated project (13) background recompilation yielded speedups of
up to 1.25x on benchmarks with many branch traces. We plan to
apply this technique to TraceMonkey as future work.
6.3 Trace Recording
The job of the trace recorder is to emit LIR with identical semantics
to the currently running interpreter bytecode trace. A good imple-
mentation should have low impact on non-tracing interpreter per-
formance and a convenient way for implementers to maintain se-
mantic equivalence.
In our implementation, the only direct modification to the inter-
preter is a call to the trace monitor at loop edges. In our benchmark
results (see Figure 12) the total time spent in the monitor (for all
activities) is usually less than 5%, so we consider the interpreter
impact requirement met. Incrementing the loop hit counter is ex-
pensive because it requires us to look up the loop in the trace cache,
but we have tuned our loops to become hot and trace very quickly
(on the second iteration). The hit counter implementation could be
improved, which might give us a small increase in overall perfor-
mance, as well as more flexibility with tuning hotness thresholds.
Once a loop is blacklisted we never call into the trace monitor for
that loop (see Section 3.3).
Recording is activated by a pointer swap that sets the inter-
preter’s dispatch table to call a single “interrupt” routine for ev-
ery bytecode. The interrupt routine first calls a bytecode-specific
recording routine. Then, it turns off recording if necessary (e.g.,
the trace ended). Finally, it jumps to the standard interpreter byte-
code implementation. Some bytecodes have effects on the type map
that cannot be predicted before executing the bytecode (e.g., call-
ing String.charCodeAt, which returns an integer or NaN if the
index argument is out of range). For these, we arrange for the inter-
preter to call into the recorder again after executing the bytecode.
Since such hooks are relatively rare, we embed them directly into
the interpreter, with an additional runtime check to see whether a
recorder is currently active.
While separating the interpreter from the recorder reduces indi-
vidual code complexity, it also requires careful implementation and
extensive testing to achieve semantic equivalence.
In some cases achieving this equivalence is difficult since Spi-
derMonkey follows a fat-bytecode design, which was found to be
beneficial to pure interpreter performance.
In fat-bytecode designs, individual bytecodes can implement
complex processing (e.g., the getprop bytecode, which imple-
ments full JavaScript property value access, including special cases
for cached and dense array access).
Fat bytecodes have two advantages: fewer bytecodes means
lower dispatch cost, and bigger bytecode implementations give the
compiler more opportunities to optimize the interpreter.
Fat bytecodes are a problem for TraceMonkey because they
require the recorder to reimplement the same special case logic
in the same way. Also, the advantages are reduced because (a)
dispatch costs are eliminated entirely in compiled traces, (b) the
traces contain only one special case, not the interpreter’s large
chunk of code, and (c) TraceMonkey spends less time running the
base interpreter.
One way we have mitigated these problems is by implementing
certain complex bytecodes in the recorder as sequences of simple
bytecodes. Expressing the original semantics this way is not too dif-
ficult, and recording simple bytecodes is much easier. This enables
us to retain the advantages of fat bytecodes while avoiding some of
their problems for trace recording. This is particularly effective for
fat bytecodes that recurse back into the interpreter, for example to
convert an object into a primitive value by invoking a well-known
method on the object, since it lets us inline this function call.
It is important to note that we split fat opcodes into thinner op-
codes only during recording. When running purely interpretatively
(i.e. code that has been blacklisted), the interpreter directly and ef-
ficiently executes the fat opcodes.
6.4 Preemption
SpiderMonkey, like many VMs, needs to preempt the user program
periodically. The main reasons are to prevent infinitely looping
scripts from locking up the host system and to schedule GC.
In the interpreter, this had been implemented by setting a “pre-
empt now” flag that was checked on every backward jump. This
strategy carried over into TraceMonkey: the VM inserts a guard on
the preemption flag at every loop edge. We measured less than a
1% increase in runtime on most benchmarks for this extra guard.
In practice, the cost is detectable only for programs with very short
loops.
We tested and rejected a solution that avoided the guards by
compiling the loop edge as an unconditional jump, and patching
the jump target to an exit routine when preemption is required.
This solution can make the normal case slightly faster, but then
preemption becomes very slow. The implementation was also very
complex, especially trying to restart execution after the preemption.
-
6.5 Calling External Functions
Like most interpreters, SpiderMonkey has a foreign function inter-
face (FFI) that allows it to call C builtins and host system functions
(e.g., web browser control and DOM access). The FFI has a stan-
dard signature for JS-callable functions, the key argument of which
is an array of boxed values. External functions called through the
FFI interact with the program state through an interpreter API (e.g.,
to read a property from an argument). There are also certain inter-
preter builtins that do not use the FFI, but interact with the program
state in the same way, such as the CallIteratorNext function
used with iterator objects. TraceMonkey must support this FFI in
order to speed up code that interacts with the host system inside hot
loops.
Calling external functions from TraceMonkey is potentially dif-
ficult because traces do not update the interpreter state until exit-
ing. In particular, external functions may need the call stack or the
global variables, but they may be out of date.
For the out-of-date call stack problem, we refactored some of
the interpreter API implementation functions to re-materialize the
interpreter call stack on demand.
We developed a C++ static analysis and annotated some inter-
preter functions in order to verify that the call stack is refreshed
at any point it needs to be used. In order to access the call stack,
a function must be annotated as either FORCESSTACK or RE -
QUIRESSTACK . These annotations are also required in order to call
REQUIRESSTACK functions, which are presumed to access the call
stack transitively. FORCESSTACK is a trusted annotation, applied
to only 5 functions, that means the function refreshes the call stack.
REQUIRESSTACK is an untrusted annotation that means the func-
tion may only be called if the call stack has already been refreshed.
Similarly, we detect when host functions attempt to directly
read or write global variables, and force the currently running trace
to side exit. This is necessary since we cache and unbox global
variables into the activation record during trace execution.
Since both call-stack access and global variable access are
rarely performed by host functions, performance is not significantly
affected by these safety mechanisms.
Another problem is that external functions can reenter the inter-
preter by calling scripts, which in turn again might want to access
the call stack or global variables. To address this problem, we made
the VM set a flag whenever the interpreter is reentered while a com-
piled trace is running.
Every call to an external function then checks this flag and exits
the trace immediately after returning from the external function call
if it is set. There are many external functions that seldom or never
reenter, and they can be called without problem, and will cause
trace exit only if necessary.
The FFI’s boxed value array requirement has a performance
cost, so we defined a new FFI that allows C functions to be an-
notated with their argument types so that the tracer can call them
directly, without unnecessary argument conversions.
Currently, we do not support calling native property get and set
override functions or DOM functions directly from trace. Support
is planned future work.
6.6 Correctness
During development, we had access to existing JavaScript test
suites, but most of them were not designed with tracing VMs in
mind and contained few loops.
One tool that helped us greatly was Mozilla’s JavaScript fuzz
tester, JSFUNFUZZ , which generates random JavaScript programs
by nesting random language elements. We modified J S F U N F U Z Z
to generate loops, and also to test more heavily certain constructs
we suspected would reveal flaws in our implementation. For exam-
ple, we suspected bugs in TraceMonkey’s handling of type-unstable
!"# $!"# %!"# &!"# '!"# (!"# )!"# *!"# +!"# ,!"# $!!"#
&-./012#3%4%56#
&-.789:;#3%4,56#
&-.9<=>9</2#3$4%56#
<//2??.1@A<9=.>922?#3!4,56#
<//2??.B<AAC0/;#3%4%56#
<//2??.A18-=#3'4%56#
<//2??.A?@2D2#3&4!56#
1@>8:?.&1@>.1@>?.@A.1=>2#3%(4(56#
1@>8:?.1@>?.@A.1=>2#3+4*56#
1@>8:?.1@>E@?2.<A-#3%(4%56#
1@>8:?.A?@2D2.1@>?#3%4*56#
/8A>98FG8E.92/09?@D2#3$4!56#
/9=:>8.<2?#3$4)56#
/9=:>8.7-(#3%4&56#
/9=:>8.?;<$#3(4,56#
-<>2.B897<>.>8H2#3$4$56#
-<>2.B897<>.5:<91#3$4!56#
7<>;./89-@/#3'4,56#
7<>;.:<9I<F.?07?#3(4,56#
7<>;.?:2/>9<F.A897#3*4$56#
92J25:.-A<#3'4%56#
?>9@AJ.1<?2)'#3%4(56#
?>9@AJ.B<?><#3$4(56#
?>9@AJ.><J/F80-#3$4$56#
?>9@AJ.0A:</C./8-2#3$4%56#
?>9@AJ.D<F@-<>2.@A:0>#3$4,56#
KA>29:92># L<ID2#
Figure 11. Fraction of dynamic bytecodes executed by inter-
preter and on native traces. The speedup vs. interpreter is shown
in parentheses next to each test. The fraction of bytecodes exe-
cuted while recording is too small to see in this figure, except
for crypto-md5, where fully 3% of bytecodes are executed while
recording. In most of the tests, almost all the bytecodes are exe-
cuted by compiled traces. Three of the benchmarks are not traced
at all and run in the interpreter.
loops and heavily branching code, and a specialized fuzz tester in-
deed revealed several regressions which we subsequently corrected.
7. Evaluation
We evaluated our JavaScript tracing implementation using Sun-
Spider, the industry standard JavaScript benchmark suite. SunSpi-
der consists of 26 short-running (less than 250ms, average 26ms)
JavaScript programs. This is in stark contrast to benchmark suites
such as SpecJVM98 (3) used to evaluate desktop and server Java
VMs. Many programs in those benchmarks use large data sets and
execute for minutes. The SunSpider programs carry out a variety of
tasks, primarily 3d rendering, bit-bashing, cryptographic encoding,
math kernels, and string processing.
All experiments were performed on a MacBook Pro with 2.2
GHz Core 2 processor and 2 GB RAM running MacOS 10.5.
Benchmark results. The main question is whether programs
run faster with tracing. For this, we ran the standard SunSpider test
driver, which starts a JavaScript interpreter, loads and runs each
program once for warmup, then loads and runs each program 10
times and reports the average time taken by each. We ran 4 differ-
ent configurations for comparison: (a) SpiderMonkey, the baseline
interpreter, (b) TraceMonkey, (d) SquirrelFish Extreme (SFX), the
call-threaded JavaScript interpreter used in Apple’s WebKit, and
(e) V8, the method-compiling JavaScript VM from Google.
Figure 10 shows the relative speedups achieved by tracing, SFX,
and V8 against the baseline (SpiderMonkey). Tracing achieves the
best speedups in integer-heavy benchmarks, up to the 25x speedup
on bitops-bitwise-and.
TraceMonkey is the fastest VM on 9 of the 26 benchmarks
(3d-morph, bitops-3bit-bits-in-byte, bitops-bitwise-
and, crypto-sha1, math-cordic, math-partial-sums, math-
spectral-norm, string-base64, string-validate-input).
-
!"
#"
$!"
$#"
%!"
%#"
&'()*+,"
-./"
01"
Figure 10. Speedup vs. a baseline JavaScript interpreter (SpiderMonkey) for our trace-based JIT compiler, Apple’s SquirrelFish Extreme
inline threading interpreter and Google’s V8 JS compiler. Our system generates particularly efficient code for programs that benefit most from
type specialization, which includes SunSpider Benchmark programs that perform bit manipulation. We type-specialize the code in question
to use integer arithmetic, which substantially improves performance. For one of the benchmark programs we execute 25 times faster than
the SpiderMonkey interpreter, and almost 5 times faster than V8 and SFX. For a large number of benchmarks all three VMs produce similar
results. We perform worst on benchmark programs that we do not trace and instead fall back onto the interpreter. This includes the recursive
benchmarks access-binary-trees and control-flow-recursive, for which we currently don’t generate any native code.
In particular, the bitops benchmarks are short programs that per-
form many bitwise operations, so TraceMonkey can cover the en-
tire program with 1 or 2 traces that operate on integers. TraceMon-
key runs all the other programs in this set almost entirely as native
code.
regexp-dna is dominated by regular expression matching,
which is implemented in all 3 VMs by a special regular expression
compiler. Thus, performance on this benchmark has little relation
to the trace compilation approach discussed in this paper.
TraceMonkey’s smaller speedups on the other benchmarks can
be attributed to a few specific causes:
•
The implementation does not currently trace recursion, so
TraceMonkey achieves a small speedup or no speedup on
benchmarks that use recursion extensively: 3d-cube, 3d-
raytrace, access-binary-trees, string-tagcloud, and
controlflow-recursive.
•
The implementation does not currently trace eval and some
other functions implemented in C. Because date-format-
tofte and date-format-xparb use such functions in their
main loops, we do not trace them.
•
The implementation does not currently trace through regular
expression replace operations. The replace function can be
passed a function object used to compute the replacement text.
Our implementation currently does not trace functions called
as replace functions. The run time of string-unpack-code is
dominated by such a replace call.
•
Two programs trace well, but have a long compilation time.
access-nbody forms a large number of traces (81). crypto-md5
forms one very long trace. We expect to improve performance
on this programs by improving the compilation speed of nano-
jit.
•
Some programs trace very well, and speed up compared to
the interpreter, but are not as fast as SFX and/or V8, namely
bitops-bits-in-byte, bitops-nsieve-bits, access-
fannkuch, access-nsieve, and crypto-aes. The reason is
not clear, but all of these programs have nested loops with
small bodies, so we suspect that the implementation has a rela-
tively high cost for calling nested traces. string-fasta traces
well, but its run time is dominated by string processing builtins,
which are unaffected by tracing and seem to be less efficient in
SpiderMonkey than in the two other VMs.
Detailed performance metrics. In Figure 11 we show the frac-
tion of instructions interpreted and the fraction of instructions exe-
cuted as native code. This figure shows that for many programs, we
are able to execute almost all the code natively.
Figure 12 breaks down the total execution time into four activ-
ities: interpreting bytecodes while not recording, recording traces
(including time taken to interpret the recorded trace), compiling
traces to native code, and executing native code traces.
These detailed metrics allow us to estimate parameters for a
simple model of tracing performance. These estimates should be
considered very rough, as the values observed on the individual
benchmarks have large standard deviations (on the order of the
-
Loops Trees Traces Aborts Flushes Trees/Loop Traces/Tree Traces/Loop Speedup
3d-cube 25 27 29 3 0 1.1 1.1 1.2 2.20x
3d-morph 5 8 8 2 0 1.6 1.0 1.6 2.86x
3d-raytrace 10 25 100 10 1 2.5 4.0 10.0 1.18x
access-binary-trees 0 0 0 5 0 - - - 0.93x
access-fannkuch 10 34 57 24 0 3.4 1.7 5.7 2.20x
access-nbody 8 16 18 5 0 2.0 1.1 2.3 4.19x
access-nsieve 3 6 8 3 0 2.0 1.3 2.7 3.05x
bitops-3bit-bits-in-byte 2 2 2 0 0 1.0 1.0 1.0 25.47x
bitops-bits-in-byte 3 3 4 1 0 1.0 1.3 1.3 8.67x
bitops-bitwise-and 1 1 1 0 0 1.0 1.0 1.0 25.20x
bitops-nsieve-bits 3 3 5 0 0 1.0 1.7 1.7 2.75x
controlflow-recursive 0 0 0 1 0 - - - 0.98x
crypto-aes 50 72 78 19 0 1.4 1.1 1.6 1.64x
crypto-md5 4 4 5 0 0 1.0 1.3 1.3 2.30x
crypto-sha1 5 5 10 0 0 1.0 2.0 2.0 5.95x
date-format-tofte 3 3 4 7 0 1.0 1.3 1.3 1.07x
date-format-xparb 3 3 11 3 0 1.0 3.7 3.7 0.98x
math-cordic 2 4 5 1 0 2.0 1.3 2.5 4.92x
math-partial-sums 2 4 4 1 0 2.0 1.0 2.0 5.90x
math-spectral-norm 15 20 20 0 0 1.3 1.0 1.3 7.12x
regexp-dna 2 2 2 0 0 1.0 1.0 1.0 4.21x
string-base64 3 5 7 0 0 1.7 1.4 2.3 2.53x
string-fasta 5 11 15 6 0 2.2 1.4 3.0 1.49x
string-tagcloud 3 6 6 5 0 2.0 1.0 2.0 1.09x
string-unpack-code 4 4 37 0 0 1.0 9.3 9.3 1.20x
string-validate-input 6 10 13 1 0 1.7 1.3 2.2 1.86x
Figure 13. Detailed trace recording statistics for the SunSpider benchmark set.
mean). We exclude regexp-dna from the following calculations,
because most of its time is spent in the regular expression matcher,
which has much different performance characteristics from the
other programs. (Note that this only makes a difference of about
10% in the results.) Dividing the total execution time in processor
clock cycles by the number of bytecodes executed in the base
interpreter shows that on average, a bytecode executes in about
35 cycles. Native traces take about 9 cycles per bytecode, a 3.9x
speedup over the interpreter.
Using similar computations, we find that trace recording takes
about 3800 cycles per bytecode, and compilation 3150 cycles per
bytecode. Hence, during recording and compiling the VM runs at
1/200 the speed of the interpreter. Because it costs 6950 cycles to
compile a bytecode, and we save 26 cycles each time that code is
run natively, we break even after running a trace 270 times.
The other VMs we compared with achieve an overall speedup
of 3.0x relative to our baseline interpreter. Our estimated native
code speedup of 3.9x is significantly better. This suggests that
our compilation techniques can generate more efficient native code
than any other current JavaScript VM.
These estimates also indicate that our startup performance could
be substantially better if we improved the speed of trace recording
and compilation. The estimated 200x slowdown for recording and
compilation is very rough, and may be influenced by startup factors
in the interpreter (e.g., caches that have not warmed up yet during
recording). One observation supporting this conjecture is that in
the tracer, interpreted bytecodes take about 180 cycles to run. Still,
recording and compilation are clearly both expensive, and a better
implementation, possibly including redesign of the LIR abstract
syntax or encoding, would improve startup performance.
Our performance results confirm that type specialization using
trace trees substantially improves performance. We are able to
outperform the fastest available JavaScript compiler (V8) and the
fastest available JavaScript inline threaded interpreter (SFX) on 9
of 26 benchmarks.
8. Related Work
Trace optimization for dynamic languages. The closest area of
related work is on applying trace optimization to type-specialize
dynamic languages. Existing work shares the idea of generating
type-specialized code speculatively with guards along interpreter
traces.
To our knowledge, Rigo’s Psyco (16) is the only published
type-specializing trace compiler for a dynamic language (Python).
Psyco does not attempt to identify hot loops or inline function calls.
Instead, Psyco transforms loops to mutual recursion before running
and traces all operations.
Pall’s LuaJIT is a Lua VM in development that uses trace com-
pilation ideas. (1). There are no publications on LuaJIT but the cre-
ator has told us that LuaJIT has a similar design to our system, but
will use a less aggressive type speculation (e.g., using a floating-
point representation for all number values) and does not generate
nested traces for nested loops.
General trace optimization. General trace optimization has
a longer history that has treated mostly native code and typed
languages like Java. Thus, these systems have focused less on type
specialization and more on other optimizations.
Dynamo (7) by Bala et al, introduced native code tracing as a
replacement for profile-guided optimization (PGO). A major goal
was to perform PGO online so that the profile was specific to
the current execution. Dynamo used loop headers as candidate hot
traces, but did not try to create loop traces specifically.
Trace trees were originally proposed by Gal et al. (11) in the
context of Java, a statically typed language. Their trace trees ac-
tually inlined parts of outer loops within the inner loops (because
-
!"# $!"# %!"# &!"# '!"# (!!"#
)*+,-./#0$1$23#
)*+45678#0$1923#
)*+6:;<6:,/#0(1$23#
:,,/==+.>?:6;+<6//=#0!1923#
:,,/==+@:??A-,8#0$1$23#
:,,/==+?.5*;#0%1$23#
:,,/==+?=>/B/#0)1!23#
.><57=+).><+.><=+>?+.;</#0$C1C23#
.><57=+.><=+>?+.;</#0'1D23#
.><57=+.><E>=/+:?*#0$C1$23#
.><57=+?=>/B/+.><=#0$1D23#
,5?<65FG5E+6/,-6=>B/#0(1!23#
,6;7<5+:/=#0(1&23#
,6;7<5+4*C#0$1)23#
,6;7<5+=8:(#0C1923#
*:</+@564:<+<5H/#0(1(23#
*:</+@564:<+27:6.#0(1!23#
4:<8+,56*>,#0%1923#
4:<8+7:6I:F+=-4=#0C1923#
4:<8+=7/,<6:F+?564#0D1(23#
6/J/27+*?:#0%1$23#
=<6>?J+.:=/&%#0$1C23#
=<6>?J+@:=<:#0(1C23#
=<6>?J+<:J,F5-*#0(1(23#
=<6>?J+-?7:,A+,5*/#0(1$23#
=<6>?J+B:F>*:</+>?7-<#0(1923#
K?</676/<# L5?><56# M/,56*# N547>F/# N:FF#O6:,/# M-?#O6:,/#
Figure 12. Fraction of time spent on major VM activities. The
speedup vs. interpreter is shown in parentheses next to each test.
Most programs where the VM spends the majority of its time run-
ning native code have a good speedup. Recording and compilation
costs can be substantial; speeding up those parts of the implemen-
tation would improve SunSpider performance.
inner loops become hot first), leading to much greater tail duplica-
tion.
YETI, from Zaleski et al. (19) applied Dynamo-style tracing
to Java in order to achieve inlining, indirect jump elimination,
and other optimizations. Their primary focus was on designing an
interpreter that could easily be gradually re-engineered as a tracing
VM.
Suganuma et al. (18) described region-based compilation (RBC),
a relative of tracing. A region is an subprogram worth optimizing
that can include subsets of any number of methods. Thus, the com-
piler has more flexibility and can potentially generate better code,
but the profiling and compilation systems are correspondingly more
complex.
Type specialization for dynamic languages. Dynamic lan-
guage implementors have long recognized the importance of type
specialization for performance. Most previous work has focused on
methods instead of traces.
Chambers et. al (9) pioneered the idea of compiling multiple
versions of a procedure specialized for the input types in the lan-
guage Self. In one implementation, they generated a specialized
method online each time a method was called with new input types.
In another, they used an offline whole-program static analysis to
infer input types and constant receiver types at call sites. Interest-
ingly, the two techniques produced nearly the same performance.
Salib (17) designed a type inference algorithm for Python based
on the Cartesian Product Algorithm and used the results to special-
ize on types and translate the program to C++.
McCloskey (14) has work in progress based on a language-
independent type inference that is used to generate efficient C
implementations of JavaScript and Python programs.
Native code generation by interpreters. The traditional inter-
preter design is a virtual machine that directly executes ASTs or
machine-code-like bytecodes. Researchers have shown how to gen-
erate native code with nearly the same structure but better perfor-
mance.
Call threading, also known as context threading (8), compiles
methods by generating a native call instruction to an interpreter
method for each interpreter bytecode. A call-return pair has been
shown to be a potentially much more efficient dispatch mechanism
than the indirect jumps used in standard bytecode interpreters.
Inline threading (15) copies chunks of interpreter native code
which implement the required bytecodes into a native code cache,
thus acting as a simple per-method JIT compiler that eliminates the
dispatch overhead.
Neither call threading nor inline threading perform type special-
ization.
Apple’s SquirrelFish Extreme (5) is a JavaScript implementa-
tion based on call threading with selective inline threading. Com-
bined with efficient interpreter engineering, these threading tech-
niques have given SFX excellent performance on the standard Sun-
Spider benchmarks.
Google’s V8 is a JavaScript implementation primarily based
on inline threading, with call threading only for very complex
operations.
9. Conclusions
This paper described how to run dynamic languages efficiently by
recording hot traces and generating type-specialized native code.
Our technique focuses on aggressively inlined loops, and for each
loop, it generates a tree of native code traces representing the
paths and value types through the loop observed at run time. We
explained how to identify loop nesting relationships and generate
nested traces in order to avoid excessive code duplication due
to the many paths through a loop nest. We described our type
specialization algorithm. We also described our trace compiler,
which translates a trace from an intermediate representation to
optimized native code in two linear passes.
Our experimental results show that in practice loops typically
are entered with only a few different combinations of value types
of variables. Thus, a small number of traces per loop is sufficient
to run a program efficiently. Our experiments also show that on
programs amenable to tracing, we achieve speedups of 2x to 20x.
10. Future Work
Work is underway in a number of areas to further improve the
performance of our trace-based JavaScript compiler. We currently
do not trace across recursive function calls, but plan to add the
support for this capability in the near term. We are also exploring
adoption of the existing work on tree recompilation in the context
of the presented dynamic compiler in order to minimize JIT pause
times and obtain the best of both worlds, fast tree stitching as well
as the improved code quality due to tree recompilation.
We also plan on adding support for tracing across regular ex-
pression substitutions using lambda functions, function applica-
tions and expression evaluation using eval. All these language
constructs are currently executed via interpretation, which limits
our performance for applications that use those features.
Acknowledgments
Parts of this effort have been sponsored by the National Science
Foundation under grants CNS-0615443 and CNS-0627747, as well
as by the California MICRO Program and industrial sponsor Sun
Microsystems under Project No. 07-127.
The U.S. Government is authorized to reproduce and distribute
reprints for Governmental purposes notwithstanding any copyright
annotation thereon. Any opinions, findings, and conclusions or rec-
ommendations expressed here are those of the author and should
-
not be interpreted as necessarily representing the official views,
policies or endorsements, either expressed or implied, of the Na-
tional Science foundation (NSF), any other agency of the U.S. Gov-
ernment, or any of the companies mentioned above.
References
[1] LuaJIT roadmap 2008 - http://lua-users.org/lists/lua-l/2008-
02/msg00051.html.
[2] Mozilla — Firefox web browser and Thunderbird email client -
http://www.mozilla.com.
[3] SPECJVM98 - http://www.spec.org/jvm98/.
[4] SpiderMonkey (JavaScript-C) Engine -
http://www.mozilla.org/js/spidermonkey/.
[5] Surfin’ Safari - Blog Archive - Announcing SquirrelFish Extreme -
http://webkit.org/blog/214/introducing-squirrelfish-extreme/.
[6] A. Aho, R. Sethi, J. Ullman, and M. Lam. Compilers: Principles,
techniques, and tools, 2006.
[7] V. Bala, E. Duesterwald, and S. Banerjia. Dynamo: A transparent
dynamic optimization system. In Proceedings of the ACM SIGPLAN
Conference on Programming Language Design and Implementation,
pages 1–12. ACM Press, 2000.
[8] M. Berndl, B. Vitale, M. Zaleski, and A. Brown. Context Threading:
a Flexible and Efficient Dispatch Technique for Virtual Machine In-
terpreters. In Code Generation and Optimization, 2005. CGO 2005.
International Symposium on, pages 15–26, 2005.
[9] C. Chambers and D. Ungar. Customization: Optimizing Compiler
Technology for SELF, a Dynamically-Typed O bject-Oriented Pro-
gramming Language. In Proceedings of the ACM SIGPLAN 1989
Conference on Programming Language Design and Implementation,
pages 146–160. ACM New York, NY, USA, 1989.
[10] A. Gal. Efficient Bytecode Verification and Compilation in a Virtual
Machine Dissertation. PhD thesis, University Of California, Irvine,
2006.
[11] A. Gal, C. W. Probst, and M. Franz. HotpathVM: An effective JIT
compiler for resource-constrained devices. In Proceedings of the
International Conference on Virtual Execution Environments, pages
144–153. ACM Press, 2006.
[12] C. Garrett, J. Dean, D. Grove, and C. Chambers. Measurement and
Application of Dynamic Receiver Class Distributions. 1994.
[13] J. Ha, M. R. Haghighat, S. Cong, and K. S. McKinley. A concurrent
trace-based just-in-time compiler for javascript. Dept.of Computer
Sciences, The University of Texas at Austin, TR-09-06, 2009.
[14] B. McCloskey. Personal communication.
[15] I. Piumarta and F. Riccardi. Optimizing direct threaded code by selec-
tive inlining. In Proceedings of the ACM SIGPLAN 1998 conference
on Programming language design and implementation, pages 291–
300. ACM New York, NY, USA, 1998.
[16] A. Rigo. Representation-Based Just-In-time Specialization and the
Psyco Prototype for Python. In PEPM, 2004.
[17] M. Salib. Starkiller: A Static Type Inferencer and Compiler for
Python. In Master’s Thesis, 2004.
[18] T. Suganuma, T. Yasue, and T. Nakatani. A Region-Based Compila-
tion Technique for Dynamic Compilers. ACM Transactions on Pro-
gramming Languages and Systems (TOPLAS), 28(1):134–174, 2006.
[19] M. Zaleski, A. D. Brown, and K. Stoodley. YETI: A graduallY
Extensible Trace Interpreter. In Proceedings of the International
Conference on Virtual Execution Environments, pages 83–93. ACM
Press, 2007.
- -
- - - diff --git a/demo/geneve.html b/demo/geneve.html deleted file mode 100644 index 2781199..0000000 --- a/demo/geneve.html +++ /dev/null @@ -1,214 +0,0 @@ - - - - - - - - - - - - - - -
- -
1
Le premier lire de Moyſe,
Di Geneſe.
.
Ce premier lire comprend l’origine caſes de totes choſes, principalement la creation de l’homme, q’il a eſté d
commencement, ſa chete releement : comment d’n tos ont eſté procreés, por lers enormes pechés Die
les a conſmés, par le delge, reſeré hi, dont la ſemence a rempli tote la terre. Pis il deſcrit les vies, fais, reli-
gion, lignees des ſaints Patriarches, qi ont veſc deant la Loy : Les benediions, promees, alliances d Sei-
gner faies aec icex : Comment de le la terre de Chanaan ſont deſcends en Egypte. Acns ont appelé ce lire, le
lire des Iſtes. Totefois ceci a obten entre nos predeceers nos, q’il eſt appelé Geneſe, qi eſt n mot Grec,
gnifiant generation origine : d’atant q’en iceli eſt deſcrite l’origine procreation de totes choſes : nom-
mément des Peres anciens, qi ont eſté tant deant q’apres le delge, e eſgard à deſcen-
d d’icex ſelon la chair.
.
I
Creation d ciel de la terre, II, 10. de tot ce qi y eſt
comprins. 3.14. De la lmiere a, 26 de l’homme, 18
qel tot eſt aietti. 2.2. 18 Die benit totes ſes œ-
vres, 31 q’il a accomplies en x iors.
1
Ie
a
crea
b
a com
mence -
ment
c
le
ciel & la
terre.
2 Or la
terre eſ-
toit ſans
forme, &
vide, & les tenebres eſtoyent ſr les
abyſmes : & l’Eſprit de Die
d
eſtoit
eſpand par des les eax.
3 Adonc Die dît,
2
’il y ait lmie-
re.
e
Et la lmiere ft.
4 Et Die vid q
̃
la lmiere eſtoit bon-
ne : & ſepara la lmiere des tenebres.
5 Et Die appela la lmiere ior,& les
tenebres ni. Lors ft fai le
f
ſoir &
le matin d premier ior.
6 Pis Die dît,
3
’il y ait ne
g
eſ-
tende entre les eax, & qelle ſepare
les
h
eax daec les eax.
7 Die donc fit leſtende, & diiſa
I
Ce premier cha-
pitre eſt fort diffi-
cile : & por cette
caſe, il eſtoit de-
fend entre les He-
briex de le lire &
interpreter deant
laagedetrenteans.
a
Fit de rien, & ſans
acne matiere.
1
Iob 38.4,
Pſea. 33.6, &
89.13.
b
Tot premiere-
ment, & aãt q’il
y et acne crea-
tre, Iean 1.10.
2
Hebr. 11.3.
c
Le ciel & la
terre, les eax,
les abyſmes, ſe
prennent ici por
vne meſme choſe :
asç. por ne
matiere cõfſe
& ſans forme, q
̃
Die forma &
agença apres par ſa
Parole.
d
O, ſe mooit.
Ceſt, ſoſtenoit et
conſeroit en ſon
eſtre cette matiere
confſe. Car il
eſt impoble,
q
̃
acne choſe
apres aoir eſté
faies, pie
ſbſter n ſel
moment, Die
ne la ſoſtient
& cõſere par ſa
vert, Pſea. 130.
e
Cette lmiere
neſtoit point
encore a ſoleil, car
il naoit pas eſté
creé, mais eſtoit en
la main de Die,
ayãt ſon ordre
ſccef aec les
tenebres, por
faire le ior & la
ni & ce iſqes
a qatrieme
ior, qe Die
fit le ſoleil por
eſtre miniſtre &
diſpenſater de
cette lmiere, aec
la lne & eſtoilles.
3
Pſea. 33.6 &
136.5.
f
Ici eſt la caſe
les eax, qi eſtoyent ſos leſtende,
daec celles, qi eſtoyent ſr leſten-
de. Et ft ain fai.
8 Et Die appela leſtende, Ciel. Lors
ft fai le ſoir & le matin d ſecond
ior.
9 Pis Die dît,
4 i
e les eax, qi
ſont ſos le ciel, ſoyent aemblees en
n lie, & qe le ſec apparoie. Et ft
ain fai.
10 EtDieappeꝉaleſec,Terre,&laem
blee des eax, mers. Et Die vid qe
celà eſtoit bon.
11 Et Die dît, e la terre prodiſe
verdre, herbe prodiſant ſemence, &
arbre friier, faiſant fri ſelon ſon
eſpece, leqel ait ſa ſemẽce en ſoy-meſ-
me ſr la terre. Et ft ain fai.
12 La terre dõc prodit verdre, her-
be prodiſant ſemẽce ſelon ſon eſpece,
& arbre ſans fri, leqel aoit ſa
ſemence en ſoymeſme ſelon ſon eſpe-
ce. Et Die vid qe celà eſtoit bon.
13 Lors ft fai le ſoir & le matin d
troieme ior.
14 Apres Die dît,
5 k
’il y ait lmi
naires en leſtende d ciel, por ſepa-
rer la ni d ior : & ſoyẽt en
l
gnes,
a en
porqoy les He-
briex cõmencent
le ior natrel le
ſoir apres le ſoleil
cochant.
g
Ce mot d’Eſtẽ
de, comprẽd tot
ce qi ſe voit par
des nos, tãt en
la region celeſte,
qelementaire.
4
Pſea. 33.7.
h
Il eſt ici parlé
de dex manieres
deax : asçaoir,
celles q ſont ſos
leſtende, comme
la mer, les flees,
& atres qi ſont
ſr la terre & cel-
les, qi ſont ſr
leſtende, comme
ſont les nees
pleines dea
ça hat en lair
par des nos.
Die a mis entre
ces dex forces
deax ne grãde
eſtende, qon
appelle le ciel : de
là nos appelons
les oiſeax d ciel.
i
Ceci appartiẽt a
ſecõd ior, aqel
Die ſepara, & fit
apparoir la terre d
milie des eax.
k
Il inſtite n
noel ordre en
natre, qand il
fat & ordonne le
ſoleil diſtribter
de cette lmiere
q’il aoit creée
aant li, & aant
la lne & les eſ-
toilles.
5
Pſea. 136.7
l
Ceſt por -
gnifier dierſes di-
ſpotions qe les
corps ĩferiers ſe-
lon lordre de na-
tre ont des corps
celeſtes, cõme ca
ſes ſecõdes ordon
nees de Die à ce-
là. En qoy to-
tefois fat fir c-
rioté & ſperſti-
tion q
̃
les hõmes
ont cõtroee ſr
celà.
- -
- - - diff --git a/fonts/opensans-bold-webfont.eot b/fonts/opensans-bold-webfont.eot deleted file mode 100644 index b5bad08..0000000 Binary files a/fonts/opensans-bold-webfont.eot and /dev/null differ diff --git a/fonts/opensans-bold-webfont.svg b/fonts/opensans-bold-webfont.svg deleted file mode 100644 index 1557f68..0000000 --- a/fonts/opensans-bold-webfont.svg +++ /dev/null @@ -1,251 +0,0 @@ - - - - -This is a custom SVG webfont generated by Font Squirrel. -Copyright : Digitized data copyright 20102011 Google Corporation -Foundry : Ascender Corporation -Foundry URL : httpwwwascendercorpcom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/fonts/opensans-bold-webfont.ttf b/fonts/opensans-bold-webfont.ttf deleted file mode 100644 index 338220f..0000000 Binary files a/fonts/opensans-bold-webfont.ttf and /dev/null differ diff --git a/fonts/opensans-bold-webfont.woff b/fonts/opensans-bold-webfont.woff deleted file mode 100644 index ea6007b..0000000 Binary files a/fonts/opensans-bold-webfont.woff and /dev/null differ diff --git a/fonts/opensans-bolditalic-webfont.eot b/fonts/opensans-bolditalic-webfont.eot deleted file mode 100644 index d892fd9..0000000 Binary files a/fonts/opensans-bolditalic-webfont.eot and /dev/null differ diff --git a/fonts/opensans-bolditalic-webfont.svg b/fonts/opensans-bolditalic-webfont.svg deleted file mode 100644 index 24661f3..0000000 --- a/fonts/opensans-bolditalic-webfont.svg +++ /dev/null @@ -1,251 +0,0 @@ - - - - -This is a custom SVG webfont generated by Font Squirrel. -Copyright : Digitized data copyright 20102011 Google Corporation -Foundry : Ascender Corporation -Foundry URL : httpwwwascendercorpcom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/fonts/opensans-bolditalic-webfont.ttf b/fonts/opensans-bolditalic-webfont.ttf deleted file mode 100644 index b3eb0d3..0000000 Binary files a/fonts/opensans-bolditalic-webfont.ttf and /dev/null differ diff --git a/fonts/opensans-bolditalic-webfont.woff b/fonts/opensans-bolditalic-webfont.woff deleted file mode 100644 index 1712e15..0000000 Binary files a/fonts/opensans-bolditalic-webfont.woff and /dev/null differ diff --git a/fonts/opensans-extrabold-webfont.eot b/fonts/opensans-extrabold-webfont.eot deleted file mode 100644 index 0e88f02..0000000 Binary files a/fonts/opensans-extrabold-webfont.eot and /dev/null differ diff --git a/fonts/opensans-extrabold-webfont.svg b/fonts/opensans-extrabold-webfont.svg deleted file mode 100644 index c3d6642..0000000 --- a/fonts/opensans-extrabold-webfont.svg +++ /dev/null @@ -1,251 +0,0 @@ - - - - -This is a custom SVG webfont generated by Font Squirrel. -Copyright : Digitized data copyright 2011 Google Corporation -Foundry : Ascender Corporation -Foundry URL : httpwwwascendercorpcom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/fonts/opensans-extrabold-webfont.ttf b/fonts/opensans-extrabold-webfont.ttf deleted file mode 100644 index bec521d..0000000 Binary files a/fonts/opensans-extrabold-webfont.ttf and /dev/null differ diff --git a/fonts/opensans-extrabold-webfont.woff b/fonts/opensans-extrabold-webfont.woff deleted file mode 100644 index a24b205..0000000 Binary files a/fonts/opensans-extrabold-webfont.woff and /dev/null differ diff --git a/fonts/opensans-italic-webfont.eot b/fonts/opensans-italic-webfont.eot deleted file mode 100644 index 3593c12..0000000 Binary files a/fonts/opensans-italic-webfont.eot and /dev/null differ diff --git a/fonts/opensans-italic-webfont.svg b/fonts/opensans-italic-webfont.svg deleted file mode 100644 index 537d20c..0000000 --- a/fonts/opensans-italic-webfont.svg +++ /dev/null @@ -1,251 +0,0 @@ - - - - -This is a custom SVG webfont generated by Font Squirrel. -Copyright : Digitized data copyright 20102011 Google Corporation -Foundry : Ascender Corporation -Foundry URL : httpwwwascendercorpcom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/fonts/opensans-italic-webfont.ttf b/fonts/opensans-italic-webfont.ttf deleted file mode 100644 index ddc75c6..0000000 Binary files a/fonts/opensans-italic-webfont.ttf and /dev/null differ diff --git a/fonts/opensans-italic-webfont.woff b/fonts/opensans-italic-webfont.woff deleted file mode 100644 index 302cb00..0000000 Binary files a/fonts/opensans-italic-webfont.woff and /dev/null differ diff --git a/fonts/opensans-regular-webfont.eot b/fonts/opensans-regular-webfont.eot deleted file mode 100644 index 1c64986..0000000 Binary files a/fonts/opensans-regular-webfont.eot and /dev/null differ diff --git a/fonts/opensans-regular-webfont.svg b/fonts/opensans-regular-webfont.svg deleted file mode 100644 index ead219a..0000000 --- a/fonts/opensans-regular-webfont.svg +++ /dev/null @@ -1,252 +0,0 @@ - - - - -This is a custom SVG webfont generated by Font Squirrel. -Copyright : Digitized data copyright 20102011 Google Corporation -Foundry : Ascender Corporation -Foundry URL : httpwwwascendercorpcom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/fonts/opensans-regular-webfont.ttf b/fonts/opensans-regular-webfont.ttf deleted file mode 100644 index 99a1ece..0000000 Binary files a/fonts/opensans-regular-webfont.ttf and /dev/null differ diff --git a/fonts/opensans-regular-webfont.woff b/fonts/opensans-regular-webfont.woff deleted file mode 100644 index 826d643..0000000 Binary files a/fonts/opensans-regular-webfont.woff and /dev/null differ diff --git a/images/bg-ramp.jpg b/images/bg-ramp.jpg deleted file mode 100644 index 2b951e4..0000000 Binary files a/images/bg-ramp.jpg and /dev/null differ diff --git a/images/blockquote-gfx-2x.png b/images/blockquote-gfx-2x.png deleted file mode 100644 index 01addbd..0000000 Binary files a/images/blockquote-gfx-2x.png and /dev/null differ diff --git a/images/blockquote-gfx.png b/images/blockquote-gfx.png deleted file mode 100644 index 5611d69..0000000 Binary files a/images/blockquote-gfx.png and /dev/null differ diff --git a/images/body-bg.jpg b/images/body-bg.jpg new file mode 100644 index 0000000..0e0f861 Binary files /dev/null and b/images/body-bg.jpg differ diff --git a/images/chevron-2x.png b/images/chevron-2x.png deleted file mode 100644 index 96e3ce9..0000000 Binary files a/images/chevron-2x.png and /dev/null differ diff --git a/images/chevron.png b/images/chevron.png deleted file mode 100644 index 55b1b73..0000000 Binary files a/images/chevron.png and /dev/null differ diff --git a/images/download-button.png b/images/download-button.png new file mode 100644 index 0000000..df3f09a Binary files /dev/null and b/images/download-button.png differ diff --git a/images/download-fallback-bg.png b/images/download-fallback-bg.png deleted file mode 100644 index 6179dc6..0000000 Binary files a/images/download-fallback-bg.png and /dev/null differ diff --git a/images/download-sprite.png b/images/download-sprite.png deleted file mode 100644 index 62ef48d..0000000 Binary files a/images/download-sprite.png and /dev/null differ diff --git a/images/footer-ramp.jpg b/images/footer-ramp.jpg deleted file mode 100644 index fd35c2a..0000000 Binary files a/images/footer-ramp.jpg and /dev/null differ diff --git a/images/fork-sprite.png b/images/fork-sprite.png deleted file mode 100644 index a4e48b3..0000000 Binary files a/images/fork-sprite.png and /dev/null differ diff --git a/images/github-button.png b/images/github-button.png new file mode 100644 index 0000000..efe07f9 Binary files /dev/null and b/images/github-button.png differ diff --git a/images/header-bg.jpg b/images/header-bg.jpg new file mode 100644 index 0000000..960bff7 Binary files /dev/null and b/images/header-bg.jpg differ diff --git a/images/highlight-bg.jpg b/images/highlight-bg.jpg new file mode 100644 index 0000000..4c4a78e Binary files /dev/null and b/images/highlight-bg.jpg differ diff --git a/images/hr-2x.jpg b/images/hr-2x.jpg deleted file mode 100644 index ddd89f1..0000000 Binary files a/images/hr-2x.jpg and /dev/null differ diff --git a/images/hr.jpg b/images/hr.jpg deleted file mode 100644 index bc6f7e7..0000000 Binary files a/images/hr.jpg and /dev/null differ diff --git a/images/octocat-2x.png b/images/octocat-2x.png deleted file mode 100644 index c720132..0000000 Binary files a/images/octocat-2x.png and /dev/null differ diff --git a/images/octocat.png b/images/octocat.png deleted file mode 100644 index cbe4a18..0000000 Binary files a/images/octocat.png and /dev/null differ diff --git a/images/ribbon-tail-sprite-2x.png b/images/ribbon-tail-sprite-2x.png deleted file mode 100644 index 7df408a..0000000 Binary files a/images/ribbon-tail-sprite-2x.png and /dev/null differ diff --git a/images/ribbon-tail-sprite.png b/images/ribbon-tail-sprite.png deleted file mode 100644 index a754912..0000000 Binary files a/images/ribbon-tail-sprite.png and /dev/null differ diff --git a/images/shield-fallback.png b/images/shield-fallback.png deleted file mode 100644 index a451160..0000000 Binary files a/images/shield-fallback.png and /dev/null differ diff --git a/images/shield.png b/images/shield.png deleted file mode 100644 index 5115c33..0000000 Binary files a/images/shield.png and /dev/null differ diff --git a/images/sidebar-bg.jpg b/images/sidebar-bg.jpg new file mode 100644 index 0000000..42890fe Binary files /dev/null and b/images/sidebar-bg.jpg differ diff --git a/images/site-2.png b/images/site-2.png deleted file mode 100644 index 2a549a7..0000000 Binary files a/images/site-2.png and /dev/null differ diff --git a/images/small-ribbon-tail-sprite-2x.png b/images/small-ribbon-tail-sprite-2x.png deleted file mode 100644 index 64563db..0000000 Binary files a/images/small-ribbon-tail-sprite-2x.png and /dev/null differ diff --git a/images/small-ribbon-tail-sprite.png b/images/small-ribbon-tail-sprite.png deleted file mode 100644 index 8a8e32e..0000000 Binary files a/images/small-ribbon-tail-sprite.png and /dev/null differ diff --git a/index.html b/index.html index de6fb30..c06fe12 100644 --- a/index.html +++ b/index.html @@ -3,55 +3,43 @@ - + + + + + - - - + - - - - pdf2htmlEX by coolwanglu - View on GitHub -
+
+
+

pdf2htmlEX

+

A PDF to HTML converter

+ View project onGitHub +
+
-
- - -

pdf2htmlEX

-

A PDF to HTML converter

- - - - -
- -
- - download .ZIPdownload .TGZ - -
- - - - - -
-

pdf2htmlEX +
+
+
+

pdf2htmlEX

-

View Demo

+

A beautiful demo is worth a thousand words:

-

Another Demo (CJK)

+

Typography

+ +

Formulas

+ +

Scientific Paper

+ +

Chinese

WINDOWS XP USERS: Please make sure ClearType is turned on

@@ -97,9 +85,19 @@
  • CMake
    • -
  • compilers support C++11
    • -
  • libpoppler with xpdf header >= 0.20.2 (compile with --enable-xpdf-headers)
    • -
  • boost c++ library (format, program options, gil, filesystem, serialization, system(which is actually required by filesystem))
    • +
  • compilers support C++11 + +
      +
    • GCC >= 4.6.x
      • +
    +
    • +
  • libpoppler with xpdf header >= 0.20.2 (compile with --enable-xpdf-headers) + +
      +
    • Install libpng (and headers) BEFORE you compile libpoppler if you want background images generated
      • +
    +
    • +
  • boost c++ library (program options, gil, filesystem, system(which is actually required by filesystem))
  • fontforge (with header files)

Compiling

@@ -117,6 +115,10 @@ pdf2htmlEX --help

GPLv2 & GPLv3 Dual licensed

+

Please credit pdf2htmlEX if you use it in your work, especially for commercial use

+ +

Font extraction or conversion may be illegal, please check your local laws

+

Credits

The following projects have been consulted for pdf2htmlEX:

@@ -129,6 +131,10 @@ pdf2htmlEX --help
  • Google Doc

    • Contact

    +

    Suggestions and questions are welcome.

    + +

    Please read the FAQ beforehand.

    + -
    +

    - + +
    - + - + \ No newline at end of file diff --git a/javascripts/headsmart.min.js b/javascripts/headsmart.min.js deleted file mode 100644 index 16da97a..0000000 --- a/javascripts/headsmart.min.js +++ /dev/null @@ -1 +0,0 @@ -(function(a){a.fn.headsmart=function(){var c=a(this);d();function d(){var e=[],g="";if(b("h1")){e.push("h1")}if(b("h2")){e.push("h2")}if(b("h3")){e.push("h3")}if(b("h4")){e.push("h4")}if(b("h5")){e.push("h5")}if(b("h6")){e.push("h6")}for(var f=0;f0)?true:false}}})(jQuery); \ No newline at end of file diff --git a/javascripts/modernizr.js b/javascripts/modernizr.js deleted file mode 100644 index 434b0af..0000000 --- a/javascripts/modernizr.js +++ /dev/null @@ -1,4 +0,0 @@ -/* Modernizr 2.5.2 (Custom Build) | MIT & BSD - * Build: http://www.modernizr.com/download/#-fontface-borderradius-boxshadow-textshadow-cssgradients-shiv-cssclasses-teststyles-testprop-testallprops-prefixes-domprefixes-load - */ -;window.Modernizr=function(a,b,c){function z(a){j.cssText=a}function A(a,b){return z(m.join(a+";")+(b||""))}function B(a,b){return typeof a===b}function C(a,b){return!!~(""+a).indexOf(b)}function D(a,b){for(var d in a)if(j[a[d]]!==c)return b=="pfx"?a[d]:!0;return!1}function E(a,b,d){for(var e in a){var f=b[a[e]];if(f!==c)return d===!1?a[e]:B(f,"function")?f.bind(d||b):f}return!1}function F(a,b,c){var d=a.charAt(0).toUpperCase()+a.substr(1),e=(a+" "+o.join(d+" ")+d).split(" ");return B(b,"string")||B(b,"undefined")?D(e,b):(e=(a+" "+p.join(d+" ")+d).split(" "),E(e,b,c))}var d="2.5.2",e={},f=!0,g=b.documentElement,h="modernizr",i=b.createElement(h),j=i.style,k,l={}.toString,m=" -webkit- -moz- -o- -ms- ".split(" "),n="Webkit Moz O ms",o=n.split(" "),p=n.toLowerCase().split(" "),q={},r={},s={},t=[],u=t.slice,v,w=function(a,c,d,e){var f,i,j,k=b.createElement("div"),l=b.body,m=l?l:b.createElement("body");if(parseInt(d,10))while(d--)j=b.createElement("div"),j.id=e?e[d]:h+(d+1),k.appendChild(j);return f=["­",""].join(""),k.id=h,m.innerHTML+=f,m.appendChild(k),l||g.appendChild(m),i=c(k,a),l?k.parentNode.removeChild(k):m.parentNode.removeChild(m),!!i},x={}.hasOwnProperty,y;!B(x,"undefined")&&!B(x.call,"undefined")?y=function(a,b){return x.call(a,b)}:y=function(a,b){return b in a&&B(a.constructor.prototype[b],"undefined")},Function.prototype.bind||(Function.prototype.bind=function(b){var c=this;if(typeof c!="function")throw new TypeError;var d=u.call(arguments,1),e=function(){if(this instanceof e){var a=function(){};a.prototype=c.prototype;var f=new a,g=c.apply(f,d.concat(u.call(arguments)));return Object(g)===g?g:f}return c.apply(b,d.concat(u.call(arguments)))};return e});var G=function(a,c){var d=a.join(""),f=c.length;w(d,function(a,c){var d=b.styleSheets[b.styleSheets.length-1],g=d?d.cssRules&&d.cssRules[0]?d.cssRules[0].cssText:d.cssText||"":"",h=a.childNodes,i={};while(f--)i[h[f].id]=h[f];e.fontface=/src/i.test(g)&&g.indexOf(c.split(" ")[0])===0},f,c)}(['@font-face {font-family:"font";src:url("https://")}'],["fontface"]);q.borderradius=function(){return F("borderRadius")},q.boxshadow=function(){return F("boxShadow")},q.textshadow=function(){return b.createElement("div").style.textShadow===""},q.cssgradients=function(){var a="background-image:",b="gradient(linear,left top,right bottom,from(#9f9),to(white));",c="linear-gradient(left top,#9f9, white);";return z((a+"-webkit- ".split(" ").join(b+a)+m.join(c+a)).slice(0,-a.length)),C(j.backgroundImage,"gradient")},q.fontface=function(){return e.fontface};for(var H in q)y(q,H)&&(v=H.toLowerCase(),e[v]=q[H](),t.push((e[v]?"":"no-")+v));return z(""),i=k=null,function(a,b){function g(a,b){var c=a.createElement("p"),d=a.getElementsByTagName("head")[0]||a.documentElement;return c.innerHTML="x",d.insertBefore(c.lastChild,d.firstChild)}function h(){var a=k.elements;return typeof a=="string"?a.split(" "):a}function i(a){function m(){var a=j.cloneNode(!1);return k.shivMethods?(i(a),a):a}function n(a){var b=(c[a]||(c[a]=e(a))).cloneNode(!1);return k.shivMethods&&!d.test(a)?j.appendChild(b):b}var b,c={},e=a.createElement,f=a.createDocumentFragment,g=h(),j=f(),l=g.length;while(l--)b=g[l],c[b]=e(b),j.createElement(b);a.createElement=n,a.createDocumentFragment=m}function j(a){var b;return a.documentShived?a:(k.shivCSS&&!e&&(b=!!g(a,"article,aside,details,figcaption,figure,footer,header,hgroup,nav,section{display:block}audio{display:none}canvas,video{display:inline-block;*display:inline;*zoom:1}[hidden]{display:none}audio[controls]{display:inline-block;*display:inline;*zoom:1}mark{background:#FF0;color:#000}")),k.shivMethods&&!f&&(b=!i(a)),b&&(a.documentShived=b),a)}var c=a.html5||{},d=/^<|^(?:button|iframe|input|script|textarea)$/i,e,f;(function(){var c,d=b.createElement("a"),g=a.getComputedStyle,h=b.documentElement,i=b.body||(c=h.insertBefore(b.createElement("body"),h.firstChild));i.insertBefore(d,i.firstChild),d.hidden=!0,d.innerHTML="",e=(d.currentStyle||g(d,null)).display=="none",f=d.childNodes.length==1||function(){try{b.createElement("a")}catch(a){return!0}var c=b.createDocumentFragment();return typeof c.cloneNode=="undefined"||typeof c.createDocumentFragment=="undefined"||typeof c.createElement=="undefined"}(),i.removeChild(d),c&&h.removeChild(c)})();var k={elements:c.elements||"abbr article aside audio bdi canvas data datalist details figcaption figure footer header hgroup mark meter nav output progress section summary time video".split(" "),shivCSS:c.shivCSS!==!1,shivMethods:c.shivMethods!==!1,type:"default",shivDocument:j};a.html5=k,j(b)}(this,b),e._version=d,e._prefixes=m,e._domPrefixes=p,e._cssomPrefixes=o,e.testProp=function(a){return D([a])},e.testAllProps=F,e.testStyles=w,g.className=g.className.replace(/(^|\s)no-js(\s|$)/,"$1$2")+(f?" js "+t.join(" "):""),e}(this,this.document),function(a,b,c){function d(a){return o.call(a)=="[object Function]"}function e(a){return typeof a=="string"}function f(){}function g(a){return!a||a=="loaded"||a=="complete"||a=="uninitialized"}function h(){var a=p.shift();q=1,a?a.t?m(function(){(a.t=="c"?B.injectCss:B.injectJs)(a.s,0,a.a,a.x,a.e,1)},0):(a(),h()):q=0}function i(a,c,d,e,f,i,j){function k(b){if(!o&&g(l.readyState)&&(u.r=o=1,!q&&h(),l.onload=l.onreadystatechange=null,b)){a!="img"&&m(function(){t.removeChild(l)},50);for(var d in y[c])y[c].hasOwnProperty(d)&&y[c][d].onload()}}var j=j||B.errorTimeout,l={},o=0,r=0,u={t:d,s:c,e:f,a:i,x:j};y[c]===1&&(r=1,y[c]=[],l=b.createElement(a)),a=="object"?l.data=c:(l.src=c,l.type=a),l.width=l.height="0",l.onerror=l.onload=l.onreadystatechange=function(){k.call(this,r)},p.splice(e,0,u),a!="img"&&(r||y[c]===2?(t.insertBefore(l,s?null:n),m(k,j)):y[c].push(l))}function j(a,b,c,d,f){return q=0,b=b||"j",e(a)?i(b=="c"?v:u,a,b,this.i++,c,d,f):(p.splice(this.i++,0,a),p.length==1&&h()),this}function k(){var a=B;return a.loader={load:j,i:0},a}var l=b.documentElement,m=a.setTimeout,n=b.getElementsByTagName("script")[0],o={}.toString,p=[],q=0,r="MozAppearance"in l.style,s=r&&!!b.createRange().compareNode,t=s?l:n.parentNode,l=!!b.attachEvent,u=r?"object":l?"script":"img",v=l?"script":u,w=Array.isArray||function(a){return o.call(a)=="[object Array]"},x=[],y={},z={timeout:function(a,b){return b.length&&(a.timeout=b[0]),a}},A,B;B=function(a){function b(a){var a=a.split("!"),b=x.length,c=a.pop(),d=a.length,c={url:c,origUrl:c,prefixes:a},e,f,g;for(f=0;f Display -> Appearance -> Effects -> \"Use the following method to smooth edges of screen fonts\" -> ClearType)\r\n\r\n## Introduction\r\n\r\npdf2htmlEX renders PDF files in HTML, utilizing modern Web technologies, aims to provide an accuracy rendering, while keeping optimized for Web display.\r\n\r\nIt is optimized for modern web browsers such as Mozilla Firefox & Google Chrome.\r\n\r\nThis program is designed for scientific papers with complicate formulas and figures, so a precise rendering is also the #1 concern. But of course general PDF files are also supported.\r\n\r\n## Features\r\n\r\n* Single HTML file output \r\n* Precise rendering \r\n* Text Selection\r\n* Font embedding & reencoding for Web\r\n* Proper styling (Color, Transformation...)\r\n* Optimization for Web \r\n\r\n### Not supported yet\r\n\r\n* Type 3 fonts\r\n* Non-text object (Don't worry, they will be rendered as images)\r\n\r\n## Get started\r\n\r\n**Fontforge-git is no longer required, a recent version should be OK** \r\n\r\n### Ubuntu \r\n\r\nThere is a Ubuntu PPA set up at [here](https://launchpad.net/~coolwanglu/+archive/pdf2htmlex).\r\n\r\n### ArchLinux\r\n\r\nSpecial thanks to Arthur Titeica for the [AUR Package](https://aur.archlinux.org/packages.php?ID=62426).\r\n\r\n### Build from source\r\n\r\n#### Dependency\r\n\r\n* CMake \r\n* compilers support C++11\r\n* libpoppler with xpdf header >= 0.20.2 (compile with --enable-xpdf-headers)\r\n* boost c++ library (format, program options, gil, filesystem, serialization, system(which is actually required by filesystem))\r\n* fontforge (with header files)\r\n\r\n#### Compiling\r\n\r\n cmake . && make && sudo make install\r\n\r\n## Usage\r\n\r\n pdf2htmlEX /path/to/foobar.pdf\r\n\r\n pdf2htmlEX --help\r\n\r\n## LICENSE\r\n\r\nGPLv2 & GPLv3 Dual licensed\r\n\r\n## Credits\r\n\r\nThe following projects have been consulted for pdf2htmlEX:\r\n\r\n* pdftops & pdftohtml from poppler \r\n* MuPDF\r\n* PDF.js\r\n* Crocodoc\r\n* Google Doc\r\n\r\n## Contact\r\n\r\n* Lu Wang \r\n\r\n### Special Thanks\r\n\r\n* Hongliang Tian \r\n\r\n","google":"","note":"Don't delete this file! It's used internally to help with page regeneration.","name":"pdf2htmlEX","tagline":"A PDF to HTML converter"} \ No newline at end of file +{"google":"","note":"Don't delete this file! It's used internally to help with page regeneration.","name":"pdf2htmlEX","tagline":"A PDF to HTML converter","body":"# pdf2html**EX**\r\n\r\nA beautiful demo is worth a thousand words:\r\n\r\n[**Typography**](http://coolwanglu.github.com/pdf2htmlEX/demo/geneve.html)\r\n\r\n[**Formulas**](http://coolwanglu.github.com/pdf2htmlEX/demo/cheat.html)\r\n\r\n[**Scientific Paper**](http://coolwanglu.github.com/pdf2htmlEX/demo/demo.html)\r\n\r\n[**Chinese**](http://coolwanglu.github.com/pdf2htmlEX/demo/chn.html)\r\n\r\n\r\n**WINDOWS XP USERS: Please make sure ClearType is turned on** \r\n\r\n(Control Panel -> Display -> Appearance -> Effects -> \"Use the following method to smooth edges of screen fonts\" -> ClearType)\r\n\r\n## Introduction\r\n\r\npdf2htmlEX renders PDF files in HTML, utilizing modern Web technologies, aims to provide an accuracy rendering, while keeping optimized for Web display.\r\n\r\nIt is optimized for modern web browsers such as Mozilla Firefox & Google Chrome.\r\n\r\nThis program is designed for scientific papers with complicate formulas and figures, so a precise rendering is also the #1 concern. But of course general PDF files are also supported.\r\n\r\n## Features\r\n\r\n* Single HTML file output \r\n* Precise rendering \r\n* Text Selection\r\n* Font embedding & reencoding for Web\r\n* Proper styling (Color, Transformation...)\r\n* Optimization for Web \r\n\r\n### Not supported yet\r\n\r\n* Type 3 fonts\r\n* Non-text object (Don't worry, they will be rendered as images)\r\n\r\n## Get started\r\n\r\n**Fontforge-git is no longer required, a recent version should be OK** \r\n\r\n### Ubuntu \r\n\r\nThere is a Ubuntu PPA set up at [here](https://launchpad.net/~coolwanglu/+archive/pdf2htmlex).\r\n\r\n### ArchLinux\r\n\r\nSpecial thanks to Arthur Titeica for the [AUR Package](https://aur.archlinux.org/packages.php?ID=62426).\r\n\r\n### Build from source\r\n\r\n#### Dependency\r\n\r\n* CMake \r\n* compilers support C++11\r\n * GCC >= 4.6.x\r\n* libpoppler with xpdf header >= 0.20.2 (compile with --enable-xpdf-headers)\r\n * Install libpng (and headers) BEFORE you compile libpoppler if you want background images generated\r\n* boost c++ library (program options, gil, filesystem, system(which is actually required by filesystem))\r\n* fontforge (with header files)\r\n\r\n#### Compiling\r\n\r\n cmake . && make && sudo make install\r\n\r\n## Usage\r\n\r\n pdf2htmlEX /path/to/foobar.pdf\r\n\r\n pdf2htmlEX --help\r\n\r\n## LICENSE\r\n\r\nGPLv2 & GPLv3 Dual licensed\r\n\r\n**Please credit pdf2htmlEX if you use it in your work, especially for commercial use**\r\n\r\n**Font extraction or conversion may be illegal, please check your local laws**\r\n\r\n## Credits\r\n\r\nThe following projects have been consulted for pdf2htmlEX:\r\n\r\n* pdftops & pdftohtml from poppler \r\n* MuPDF\r\n* PDF.js\r\n* Crocodoc\r\n* Google Doc\r\n\r\n## Contact\r\n\r\nSuggestions and questions are welcome.\r\n\r\nPlease read the [FAQ](https://github.com/coolwanglu/pdf2htmlEX/wiki/FAQ) beforehand.\r\n\r\n* Lu Wang \r\n\r\n### Special Thanks\r\n\r\n* Hongliang Tian \r\n\r\n"} \ No newline at end of file diff --git a/stylesheets/core.css b/stylesheets/core.css deleted file mode 100644 index 7aaec46..0000000 --- a/stylesheets/core.css +++ /dev/null @@ -1,3 +0,0 @@ -@import url("screen.css"); -@import url("non-screen.css") handheld; -@import url("non-screen.css") only screen and (max-device-width:640px); \ No newline at end of file diff --git a/stylesheets/mobile.css b/stylesheets/mobile.css deleted file mode 100644 index c860c09..0000000 --- a/stylesheets/mobile.css +++ /dev/null @@ -1,510 +0,0 @@ -/* Generated by Font Squirrel (http://www.fontsquirrel.com) on February 9, 2012 */ - - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-regular-webfont.eot'); - src: url('../fonts/opensans-regular-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-regular-webfont.woff') format('woff'), - url('../fonts/opensans-regular-webfont.ttf') format('truetype'), - url('../fonts/opensans-regular-webfont.svg#OpenSansRegular') format('svg'); - font-weight: normal; - font-style: normal; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-italic-webfont.eot'); - src: url('../fonts/opensans-italic-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-italic-webfont.woff') format('woff'), - url('../fonts/opensans-italic-webfont.ttf') format('truetype'), - url('../fonts/opensans-italic-webfont.svg#OpenSansItalic') format('svg'); - font-weight: normal; - font-style: italic; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-bold-webfont.eot'); - src: url('../fonts/opensans-bold-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-bold-webfont.woff') format('woff'), - url('../fonts/opensans-bold-webfont.ttf') format('truetype'), - url('../fonts/opensans-bold-webfont.svg#OpenSansBold') format('svg'); - font-weight: bold; - font-style: normal; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-bolditalic-webfont.eot'); - src: url('../fonts/opensans-bolditalic-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-bolditalic-webfont.woff') format('woff'), - url('../fonts/opensans-bolditalic-webfont.ttf') format('truetype'), - url('../fonts/opensans-bolditalic-webfont.svg#OpenSansBoldItalic') format('svg'); - font-weight: bold; - font-style: italic; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-extrabold-webfont.eot'); - src: url('../fonts/opensans-extrabold-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-extrabold-webfont.woff') format('woff'), - url('../fonts/opensans-extrabold-webfont.ttf') format('truetype'), - url('../fonts/opensans-extrabold-webfont.svg#OpenSansExtrabold') format('svg'); - font-weight: bolder; - font-style: normal; -} - - -/* http://meyerweb.com/eric/tools/css/reset/ - v2.0 | 20110126 - License: none (public domain) -*/ - -html, body, div, span, applet, object, iframe, -h1, h2, h3, h4, h5, h6, p, blockquote, pre, -a, abbr, acronym, address, big, cite, code, -del, dfn, em, img, ins, kbd, q, s, samp, -small, strike, strong, sub, sup, tt, var, -b, u, i, center, -dl, dt, dd, ol, ul, li, -fieldset, form, label, legend, -table, caption, tbody, tfoot, thead, tr, th, td, -article, aside, canvas, details, embed, -figure, figcaption, footer, header, hgroup, -menu, nav, output, ruby, section, summary, -time, mark, audio, video { - margin: 0; - padding: 0; - border: 0; - font-size: 100%; - font: inherit; - vertical-align: baseline; -} -/* HTML5 display-role reset for older browsers */ -article, aside, details, figcaption, figure, -footer, header, hgroup, menu, nav, section { - display: block; -} -body { - line-height: 1; -} -ol, ul { - list-style: none; -} -blockquote, q { - quotes: none; -} -blockquote:before, blockquote:after, -q:before, q:after { - content: ''; - content: none; -} -table { - border-collapse: collapse; - border-spacing: 0; -} - -header, footer, section { - display: block; - position: relative; -} - -/* STYLES */ - -div.shell { - display: block; - width: 640px; - margin: 0 auto; -} - -a#forkme_banner { - display: none; -} - -/* header */ - -header { - position: relative; - z-index: 2; - margin: 0; - max-width: 640px; - top: 51px; -} - -header span.ribbon-inner { - position: relative; - display: block; - background-color: #cd596b; - border: 8px solid #7c334f; - padding: 6px; - z-index: 1; -} - -header span.left-tail, header span.right-tail { - position: relative; - display: block; - width: 19px; - height: 10px; - background: transparent url(../images/ribbon-tail-sprite-2x.png) 0 0 no-repeat; - position: absolute; - bottom: -10px; - z-index: 0; -} - -header span.left-tail { - background-position: 0 0; - left: 0; -} - -header span.right-tail { - background-position: -19px 0; - right: 0; -} - -header h1 { - background-color: #7c334f; - font-size: 2em; - font-weight: bolder; - font-style: normal; - text-transform: uppercase; - color: #ece4d8; - text-align: center; - line-height:1; - padding: 14px 20px 0; -} - -header h2 { - background-color: #7c334f; - font: bold italic .85em/1.5 Georgia, Times, “Times New Roman”, serif; - color: #e69b95; - padding-bottom: 14px; - margin-top: -3px; - text-align: center; -} - -section#downloads { - position: relative; - display: block; - height: 171px; - width: 602px; - padding-bottom: 150px; - margin: 51px auto -250px; - z-index: 1; - background: transparent url(../images/shield.png) center 0 no-repeat; -} - -section#downloads a { - display: none; -} - -span.banner-fix { - background: transparent url(../images/shield-fallback.png) center top no-repeat; - display: block; - height: 31px; - position: absolute; - width: 640px; - top: 20px; - -} - -section#main_content { - z-index: 2; - padding: 20px 40px 0; - min-height:185px; -} - -/* footer */ - -footer { - background: none; - padding-top: 104px; - margin: -94px auto 40px; - max-width:640px; - text-align: center; -} - -footer span.ribbon-outer { - display: block; - position: relative; - border-bottom: 2px solid #bdb6ad; -} - -footer span.ribbon-inner { - position: relative; - display: block; - background-color: #cd596b; - border: 8px solid #7c334f; - padding: 6px; - z-index: 1; -} - -footer p { - font-family: 'Open Sans', sans-serif; - font-weight: bold; - font-size: .6em; - color: #8b786f; -} - -footer a { - color: #cd596b; -} - -footer span.ribbon-inner p { - background-color: #7c334f; - margin: 0; - color: #e69b95; - font: bold italic 22px/1 Georgia, Times, “Times New Roman”, serif; - height: auto; - line-height: 1.1; - padding: 20px 0px 10px; -} - -footer span.ribbon-inner a { - display: block; - position: relative; - bottom: 0; - color: #7eb0d2; - font-family: 'Open Sans', sans-serif; - text-transform: uppercase; - font-style: normal; - font-weight: bolder; - font-size: 38px; - padding-bottom: 10px; -} - -footer span.ribbon-inner a:hover { - color: #7eb0d2; -} - -footer span.left-tail, footer span.right-tail { - position: relative; - display: block; - width: 23px; - height: 126px; - background: transparent url(../images/small-ribbon-tail-sprite-2x.png) 0 0 no-repeat; - position: absolute; - top: -126px; - z-index: 0; -} - -footer span.left-tail { - background-position: 0 0; - left: 0; -} - -footer span.right-tail { - background-position: -23px 0; - right: 0; -} - -footer span.octocat { - background: transparent url(../images/octocat-2x.png) 0 0 no-repeat; - display: block; - width: 60px; - height: 60px; - margin: 20px auto 0;} - -/* content */ - -body { - background: #ece4d8; - font: normal normal 30px/1.5 Georgia, Palatino,” Palatino Linotype”, Times, “Times New Roman”, serif; - color: #544943; - -webkit-font-smoothing: antialiased; -} - -a, a:hover { - color: #417090; -} - -a { - text-decoration: none; -} - -a:hover { - text-decoration: underline; -} - -h1,h2,h3,h4,h5,h6 { - font-family: 'Open Sans', sans-serif; - font-weight: bold; -} - -p { - margin: .7em 0 0; -} - -strong { - font-weight: bold; -} - -em { - font-style: italic; -} - -ol { - margin: .7em 0; - list-style-type: decimal; - padding-left: 1.35em; -} - -ul { - margin: .7em 0; - padding-left: 1.35em; -} - -ul li { - padding-left: 20px; - background: transparent url(../images/chevron-2x.png) left 15px no-repeat; -} - -blockquote { - font-family: 'Open Sans', sans-serif; - margin: 20px 0; - color: #8b786f; - padding-left: 1.35em; - background: transparent url('../images/blockquote-gfx-2x.png') 0 8px no-repeat; -} - -img { - -webkit-box-shadow: 0px 4px 0px #bdb6ad; - -moz-box-shadow: 0px 4px 0px #bdb6ad; - box-shadow: 0px 4px 0px #bdb6ad; - border: 4px solid #fff6e9; - max-width: 556px; -} - -hr { - border: none; - outline: none; - height: 42px; - background: transparent url('../images/hr-2x.jpg') center center repeat-x; - margin: 0 0 20px; -} - -code { - background: #fff6e9; - font: normal normal .9em/1.7 "Lucida Sans Typewriter", "Lucida Console", Monaco, "Bitstream Vera Sans Mono", monospace; - padding: 0 5px 1px; -} - -pre { - margin: 10px 0 20px; - padding: .7em; - background: #fff6e9; - border-bottom: 4px solid #bdb6ad; - font: normal normal .9em/1.7 "Lucida Sans Typewriter", "Lucida Console", Monaco, "Bitstream Vera Sans Mono", monospace; - overflow: auto; -} - -table { - background: #fff6e9; - display: table; - width: 100%; - border-collapse: separate; - border-bottom: 4px solid #bdb6ad; - margin: 10px 0; -} - -tr { - display: table-row; -} - -th { - display: table-cell; - padding: 2px 10px; - border: solid #ece4d8; - border-width: 0 4px 4px 0; - color: #cd596b; - font-family: 'Open Sans', sans-serif; - font-weight: bold; - font-size: .85em; -} - -td { - display: table-cell; - padding: 0 .7em; - border: solid #ece4d8; - border-width: 0 4px 4px 0; -} - -td:last-child, th:last-child { - border-right: none; -} - -tr:last-child td { - border-bottom: none; -} - -dl { - margin: .7em 0 20px; -} - -dt { - font-family: 'Open Sans', sans-serif; - font-weight: bold; -} - -dd { - padding-left: 1.35em; -} - -dd p:first-child { - margin-top: 0; -} - -/* Content based headers */ - -#main_content > .header-level-1:first-child, -#main_content > .header-level-2:first-child, -#main_content > .header-level-3:first-child, -#main_content > .header-level-4:first-child, -#main_content > .header-level-5:first-child, -#main_content > .header-level-6:first-child { - margin-top: 0; -} - -.header-level-1 { - font-size: 1.85em; - border-bottom: .2em double #d3ccc1; - color: #7c334f; - text-align: center; - font-style: italic; - margin: 1.1em 0 .38em; - line-height: 1.2; - padding-bottom: 10px -} - -.header-level-2 { - font-size: 1.58em; - color: #7c334f; - margin: .95em 0 .5em; - border-bottom: .1em solid #D3CCC1; - line-height: 1.2; - padding-bottom: 10px -} - -.header-level-3 { - margin: 20px 0 10px; - font-size: 1.45em; -} - -.header-level-4 { - margin: .6em 0; - font-size: 1.2em; - color: #cd596b; -} - -.header-level-5 { - margin: .7em 0; - font-size: 1em; - color: #8b786f; -} - -.header-level-6 { - margin: .8em 0; - font-size: .85em; - font-style: italic; -} \ No newline at end of file diff --git a/stylesheets/non-screen.css b/stylesheets/non-screen.css deleted file mode 100644 index eea5ecd..0000000 --- a/stylesheets/non-screen.css +++ /dev/null @@ -1,154 +0,0 @@ -a#forkme_banner { - display: none; -} - -div.shell { - width: 640px; -} - - -header { - max-width:640px; - margin: 0; - top: 51px; -} - -header span.ribbon-inner { - border: 8px solid #7c334f; - padding: 6px; -} - -header span.left-tail, header span.right-tail { - width: 19px; - height: 10px; - background: transparent url(../images/ribbon-tail-sprite-2x.png) 0 0 no-repeat; - bottom: -10px; -} - -header span.left-tail { - left: 0; -} - -header span.right-tail { - background-position: -19px 0; - right: 0; -} - -header h1 { - font-size: 2em; -} - -section#downloads { - height: 171px; - width: 602px; - margin: 51px auto -250px; - background: transparent url(../images/shield.png) center 0 no-repeat; -} - -section#downloads a { - display: none; -} - -span.banner-fix { - background: transparent url(../images/shield-fallback.png) center top no-repeat; - height: 31px; - width: 640px; - top: 20px; -} - -section#main_content { - padding: 20px 40px 0; -} - -footer { - max-width:640px; - background: none; -} - -footer span.left-tail, footer span.right-tail { - width: 23px; - height: 126px; - background: transparent url(../images/small-ribbon-tail-sprite-2x.png) 0 0 no-repeat; - top: -126px; -} - -footer span.left-tail { - left: 0; -} - -footer span.right-tail { - background-position: -23px 0; - right: 0; -} - -footer p { - font-size: .6em; -} - -footer span.ribbon-inner { - border: 8px solid #7c334f; - padding: 6px; -} - -footer span.ribbon-inner p { - font-size: 22px; - height: auto; - line-height: 1.1; - padding: 20px 0px 10px; -} - -footer span.ribbon-inner a { - font-size: 38px; - display: block; - bottom: 0; - padding-bottom: 10px; -} - -footer span.octocat { - background: transparent url(../images/octocat-2x.png) 0 0 no-repeat; - width: 60px; - height: 60px; - margin: 20px auto 0; -} - -body { - font: normal normal 30px/1.5 Georgia, Palatino,” Palatino Linotype”, Times, “Times New Roman”, serif; -} - -ul li { - padding-left: 20px; - background: transparent url(../images/chevron-2x.png) left 15px no-repeat; -} - -table { - border-bottom: 4px solid #bdb6ad; -} - -th { - border-width: 0 4px 4px 0; -} - -td { - border-width: 0 4px 4px 0; -} - -pre { - border-bottom: 4px solid #bdb6ad; -} - -img { - -webkit-box-shadow: 0px 4px 0px #bdb6ad; - -moz-box-shadow: 0px 4px 0px #bdb6ad; - box-shadow: 0px 4px 0px #bdb6ad; - border: 4px solid #fff6e9; - max-width: 556px; -} - -blockquote { - background: transparent url('../images/blockquote-gfx-2x.png') 0 8px no-repeat; -} - -hr { - height: 42px; - background: transparent url('../images/hr-2x.jpg') center center repeat-x; -} \ No newline at end of file diff --git a/stylesheets/print.css b/stylesheets/print.css index 32d9a9d..541695b 100644 --- a/stylesheets/print.css +++ b/stylesheets/print.css @@ -1,34 +1,226 @@ -* { - background: none !important; - color: #333 !important; +html, body, div, span, applet, object, iframe, +h1, h2, h3, h4, h5, h6, p, blockquote, pre, +a, abbr, acronym, address, big, cite, code, +del, dfn, em, img, ins, kbd, q, s, samp, +small, strike, strong, sub, sup, tt, var, +b, u, i, center, +dl, dt, dd, ol, ul, li, +fieldset, form, label, legend, +table, caption, tbody, tfoot, thead, tr, th, td, +article, aside, canvas, details, embed, +figure, figcaption, footer, header, hgroup, +menu, nav, output, ruby, section, summary, +time, mark, audio, video { + margin: 0; + padding: 0; + border: 0; + font-size: 100%; + font: inherit; + vertical-align: baseline; } - -h1,h2,h3,h4,h5,h6 { - color: #7c334f !important; +/* HTML5 display-role reset for older browsers */ +article, aside, details, figcaption, figure, +footer, header, hgroup, menu, nav, section { + display: block; +} +body { + line-height: 1; +} +ol, ul { + list-style: none; +} +blockquote, q { + quotes: none; +} +blockquote:before, blockquote:after, +q:before, q:after { + content: ''; + content: none; +} +table { + border-collapse: collapse; + border-spacing: 0; +} +body { + font-size: 13px; + line-height: 1.5; + font-family: 'Helvetica Neue', Helvetica, Arial, serif; + color: #000; } a { - color: #417090 !important; + color: #d5000d; + font-weight: bold; } -#main_content > .header-level-1:first-child, -#main_content > .header-level-2:first-child, -#main_content > .header-level-3:first-child, -#main_content > .header-level-4:first-child, -#main_content > .header-level-5:first-child, -#main_content > .header-level-6:first-child { - margin-top: 10px !important; +header { + padding-top: 35px; + padding-bottom: 10px; } -#forkme_banner, -#downloads, -.left-tail, -.right-tail -{ -display: none !important; - +header h1 { + font-weight: bold; + letter-spacing: -1px; + font-size: 48px; + color: #303030; + line-height: 1.2; } -.ribbon-inner,.ribbon-outer { - border: 0 !important; +header h2 { + letter-spacing: -1px; + font-size: 24px; + color: #aaa; + font-weight: normal; + line-height: 1.3; } +#downloads { + display: none; +} +#main_content { + padding-top: 20px; +} + +code, pre { + font-family: Monaco, "Bitstream Vera Sans Mono", "Lucida Console", Terminal; + color: #222; + margin-bottom: 30px; + font-size: 12px; +} + +code { + padding: 0 3px; +} + +pre { + border: solid 1px #ddd; + padding: 20px; + overflow: auto; +} +pre code { + padding: 0; +} + +ul, ol, dl { + margin-bottom: 20px; +} + + +/* COMMON STYLES */ + +table { + width: 100%; + border: 1px solid #ebebeb; +} + +th { + font-weight: 500; +} + +td { + border: 1px solid #ebebeb; + text-align: center; + font-weight: 300; +} + +form { + background: #f2f2f2; + padding: 20px; + +} + + +/* GENERAL ELEMENT TYPE STYLES */ + +h1 { + font-size: 2.8em; +} + +h2 { + font-size: 22px; + font-weight: bold; + color: #303030; + margin-bottom: 8px; +} + +h3 { + color: #d5000d; + font-size: 18px; + font-weight: bold; + margin-bottom: 8px; +} + +h4 { + font-size: 16px; + color: #303030; + font-weight: bold; +} + +h5 { + font-size: 1em; + color: #303030; +} + +h6 { + font-size: .8em; + color: #303030; +} + +p { + font-weight: 300; + margin-bottom: 20px; +} + +a { + text-decoration: none; +} + +p a { + font-weight: 400; +} + +blockquote { + font-size: 1.6em; + border-left: 10px solid #e9e9e9; + margin-bottom: 20px; + padding: 0 0 0 30px; +} + +ul li { + list-style: disc inside; + padding-left: 20px; +} + +ol li { + list-style: decimal inside; + padding-left: 3px; +} + +dl dd { + font-style: italic; + font-weight: 100; +} + +footer { + margin-top: 40px; + padding-top: 20px; + padding-bottom: 30px; + font-size: 13px; + color: #aaa; +} + +footer a { + color: #666; +} + +/* MISC */ +.clearfix:after { + clear: both; + content: '.'; + display: block; + visibility: hidden; + height: 0; +} + +.clearfix {display: inline-block;} +* html .clearfix {height: 1%;} +.clearfix {display: block;} \ No newline at end of file diff --git a/stylesheets/screen.css b/stylesheets/screen.css deleted file mode 100644 index ba63020..0000000 --- a/stylesheets/screen.css +++ /dev/null @@ -1,569 +0,0 @@ -/* Generated by Font Squirrel (http://www.fontsquirrel.com) on February 9, 2012 */ - - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-regular-webfont.eot'); - src: url('../fonts/opensans-regular-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-regular-webfont.woff') format('woff'), - url('../fonts/opensans-regular-webfont.ttf') format('truetype'), - url('../fonts/opensans-regular-webfont.svg#OpenSansRegular') format('svg'); - font-weight: normal; - font-style: normal; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-italic-webfont.eot'); - src: url('../fonts/opensans-italic-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-italic-webfont.woff') format('woff'), - url('../fonts/opensans-italic-webfont.ttf') format('truetype'), - url('../fonts/opensans-italic-webfont.svg#OpenSansItalic') format('svg'); - font-weight: normal; - font-style: italic; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-bold-webfont.eot'); - src: url('../fonts/opensans-bold-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-bold-webfont.woff') format('woff'), - url('../fonts/opensans-bold-webfont.ttf') format('truetype'), - url('../fonts/opensans-bold-webfont.svg#OpenSansBold') format('svg'); - font-weight: bold; - font-style: normal; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-bolditalic-webfont.eot'); - src: url('../fonts/opensans-bolditalic-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-bolditalic-webfont.woff') format('woff'), - url('../fonts/opensans-bolditalic-webfont.ttf') format('truetype'), - url('../fonts/opensans-bolditalic-webfont.svg#OpenSansBoldItalic') format('svg'); - font-weight: bold; - font-style: italic; -} - -@font-face { - font-family: 'Open Sans'; - src: url('../fonts/opensans-extrabold-webfont.eot'); - src: url('../fonts/opensans-extrabold-webfont.eot?#iefix') format('embedded-opentype'), - url('../fonts/opensans-extrabold-webfont.woff') format('woff'), - url('../fonts/opensans-extrabold-webfont.ttf') format('truetype'), - url('../fonts/opensans-extrabold-webfont.svg#OpenSansExtrabold') format('svg'); - font-weight: 800; - font-style: normal; -} - -/* http://meyerweb.com/eric/tools/css/reset/ - v2.0 | 20110126 - License: none (public domain) -*/ - -html, body, div, span, applet, object, iframe, -h1, h2, h3, h4, h5, h6, p, blockquote, pre, -a, abbr, acronym, address, big, cite, code, -del, dfn, em, img, ins, kbd, q, s, samp, -small, strike, strong, sub, sup, tt, var, -b, u, i, center, -dl, dt, dd, ol, ul, li, -fieldset, form, label, legend, -table, caption, tbody, tfoot, thead, tr, th, td, -article, aside, canvas, details, embed, -figure, figcaption, footer, header, hgroup, -menu, nav, output, ruby, section, summary, -time, mark, audio, video { - margin: 0; - padding: 0; - border: 0; - font-size: 100%; - font: inherit; - vertical-align: baseline; -} -/* HTML5 display-role reset for older browsers */ -article, aside, details, figcaption, figure, -footer, header, hgroup, menu, nav, section { - display: block; -} -body { - line-height: 1; -} -ol, ul { - list-style: none; -} -blockquote, q { - quotes: none; -} -blockquote:before, blockquote:after, -q:before, q:after { - content: ''; - content: none; -} -table { - border-collapse: collapse; - border-spacing: 0; -} - -header, footer, section { - display: block; - position: relative; -} - -/* STYLES */ - -div.shell { - display: block; - width: 670px; - margin: 0 auto; -} - -a#forkme_banner { - position: absolute; - top: 0; - left: 0; - width: 138px; - height: 138px; - display: block; - background: transparent url(../images/fork-sprite.png) 0 0 no-repeat; - text-indent: -9000px; - z-index: 3; -} - -a#forkme_banner:hover { - background-position: 0 -138px; -} - -/* header */ - -header { - position: relative; - z-index: 2; - margin: 0 auto; - max-width: 600px; - top: 38px; -} - -header span.ribbon-inner { - position: relative; - display: block; - background-color: #cd596b; - border: 4px solid #7c334f; - padding: 2px; - z-index: 1; -} - -header span.left-tail, header span.right-tail { - position: relative; - display: block; - width: 56px; - height: 105px; - background: transparent url(../images/ribbon-tail-sprite.png) 0 0 no-repeat; - position: absolute; - bottom: -37px; - z-index: 0; -} - -header span.left-tail { - background-position: 0 0; - left: -31px; -} - -header span.right-tail { - background-position: -56px 0; - right: -31px; -} - -header h1 { - background-color: #7c334f; - font-size: 2.5em; - font-weight: 800; - font-style: normal; - text-transform: uppercase; - color: #ece4d8; - text-align: center; - line-height:1; - padding: 14px 20px 0; -} - -header h2 { - background-color: #7c334f; - font: bold italic .85em/1.5 Georgia, Times, “Times New Roman”, serif; - color: #e69b95; - padding-bottom: 14px; - margin-top: -3px; - text-align: center; -} - -section#downloads, -div#no-downloads { - position: relative; - display: block; - height: 197px; - width: 550px; - padding-bottom: 150px; - margin: -80px auto -150px; - z-index: 1; - background: transparent url(../images/bg-ramp.jpg) center 171px no-repeat; -} - -div#no-downloads span.inner { - display: block; - position: relative; - height: 197px; - width: 550px; - background: transparent url(../images/download-sprite.png) 0 0 no-repeat; -} - -section#downloads a { - display: block; - position: relative; - height: 67px; - width: 275px; - padding-top: 130px; - background: transparent url(../images/download-sprite.png) 0 0 no-repeat; - text-align: center; - line-height: 1; - color: #fff; - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - font-weight: 800; - font-size: 1.3em; -} - -section#downloads a:hover { - text-decoration: none; -} - -section#downloads a em { - font: bold italic 12px/1 Georgia, Times, “Times New Roman”, serif; - color: #83b7da; - display: block; -} - -section#downloads a.zip { - float: left; - background-position: 0 0; -} - -section#downloads a.tgz { - float: right; - background-position: -275px 0; -} - -section#downloads a.zip:hover { - background-position: 0 -197px; -} - -section#downloads a.tgz:hover { - background-position: -275px -197px; -} - -span.banner-fix { - background: transparent url(../images/download-fallback-bg.png) center top no-repeat; - display: block; - height: 19px; - position: absolute; - width: 670px; - top: 19px; -} - -section#main_content { - z-index: 2; - padding: 20px 82px 0; - min-height:185px; -} - -/* footer */ - -footer { - background: transparent url(../images/footer-ramp.jpg) center -1px no-repeat; - padding-top: 104px; - margin: -94px auto 40px; - max-width: 560px; - text-align: center; -} - -footer span.ribbon-outer { - display: block; - position: relative; - border-bottom: 2px solid #bdb6ad; -} - -footer span.ribbon-inner { - position: relative; - display: block; - background-color: #cd596b; - border: 2px solid #7c334f; - padding: 1px; - z-index: 1; -} - -footer p { - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - font-weight: bold; - font-size: .8em; - color: #8b786f; -} - -footer a { - color: #cd596b; -} - -footer span.ribbon-inner p { - background-color: #7c334f; - margin: 0; - color: #e69b95; - font: bold italic 12px/1 Georgia, Times, “Times New Roman”, serif; - padding-bottom:4px; -} - -footer span.ribbon-inner a { - position: relative; - bottom: -1px; - color: #7eb0d2; - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - text-transform: uppercase; - font-style: normal; - font-weight: 800; - font-size: 1.2em; -} - -footer span.ribbon-inner a:hover { - color: #7eb0d2; -} - -footer span.left-tail, footer span.right-tail { - position: relative; - display: block; - width: 18px; - height: 29px; - background: transparent url(../images/small-ribbon-tail-sprite.png) 0 0 no-repeat; - position: absolute; - bottom: 5px; - z-index: 0; -} - -footer span.left-tail { - background-position: 0 0; - left: -11px; -} - -footer span.right-tail { - background-position: -18px 0; - right: -11px; -} - -footer span.octocat { - background: transparent url(../images/octocat.png) 0 0 no-repeat; - display: block; - width: 30px; - height: 30px; - margin: 0 auto; -} - -/* content */ - -body { - background: #ece4d8; - font: normal normal 15px/1.5 Georgia, Palatino,” Palatino Linotype”, Times, “Times New Roman”, serif; - color: #544943; - -webkit-font-smoothing: antialiased; -} - -a, a:hover { - color: #417090; -} - -a { - text-decoration: none; -} - -a:hover { - text-decoration: underline; -} - -h1,h2,h3,h4,h5,h6 { - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - font-weight: bold; -} - -p { - margin: .7em 0; -} - -strong { - font-weight: bold; -} - -em { - font-style: italic; -} - -ol { - margin: .7em 0; - list-style-type: decimal; - padding-left: 1.35em; -} - -ul { - margin: .7em 0; - padding-left: 1.35em; -} - -ul li { - padding-left: 10px; - background: transparent url(../images/chevron.png) left 6px no-repeat; -} - -blockquote { - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - margin: 20px 0; - color: #8b786f; - padding-left: 1.35em; - background: transparent url('../images/blockquote-gfx.png') 0 4px no-repeat; -} - -img { - -webkit-box-shadow: 0px 2px 0px #bdb6ad; - -moz-box-shadow: 0px 2px 0px #bdb6ad; - box-shadow: 0px 2px 0px #bdb6ad; - border: 2px solid #fff6e9; - max-width: 502px; -} - -hr { - border: none; - outline: none; - height: 18px; - background: transparent url('../images/hr.jpg') center center repeat-x; - margin: 0 0 20px; -} - -code { - background: #fff6e9; - font: normal normal .8em/1.7 "Lucida Sans Typewriter", "Lucida Console", Monaco, "Bitstream Vera Sans Mono", monospace; - padding: 0 5px 1px; -} - -pre { - margin: 10px 0 20px; - padding: .7em; - background: #fff6e9; - border-bottom: 2px solid #bdb6ad; - font: normal normal .9em/1.7 "Lucida Sans Typewriter", "Lucida Console", Monaco, "Bitstream Vera Sans Mono", monospace; - overflow: auto; -} - -pre code { - padding: 0; -} - -table { - background: #fff6e9; - display: table; - width: 100%; - border-collapse: separate; - border-bottom: 2px solid #bdb6ad; - margin: 10px 0; -} - -tr { - display: table-row; -} - -th { - display: table-cell; - padding: 2px 10px; - border: solid #ece4d8; - border-width: 0 2px 2px 0; - color: #cd596b; - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - font-weight: bold; - font-size: .85em; -} - -td { - display: table-cell; - padding: 0 .7em; - border: solid #ece4d8; - border-width: 0 2px 2px 0; -} - -td:last-child, th:last-child { - border-right: none; -} - -tr:last-child td { - border-bottom: none; -} - -dl { - margin: .7em 0 20px; -} - -dt { - font-family: 'Open Sans', Myriad, Calibri, sans-serif; - font-weight: bold; -} - -dd { - padding-left: 1.35em; -} - -dd p:first-child { - margin-top: 0; -} - -/* Content based headers */ - -#main_content > .header-level-1:first-child, -#main_content > .header-level-2:first-child, -#main_content > .header-level-3:first-child, -#main_content > .header-level-4:first-child, -#main_content > .header-level-5:first-child, -#main_content > .header-level-6:first-child { - margin-top: 0; -} - -.header-level-1 { - font-size: 1.85em; - border-bottom: .2em double #d3ccc1; - color: #7c334f; - text-align: center; - font-style: italic; - margin: 1.1em 0 .38em; - line-height: 1.2; - padding-bottom: 10px -} - -.header-level-2 { - font-size: 1.58em; - color: #7c334f; - margin: .95em 0 .5em; - border-bottom: .1em solid #D3CCC1; - line-height: 1.2; - padding-bottom: 10px -} - -.header-level-3 { - margin: 20px 0 10px; - font-size: 1.45em; -} - -.header-level-4 { - margin: .6em 0; - font-size: 1.2em; - color: #cd596b; -} - -.header-level-5 { - margin: .7em 0; - font-size: 1em; - color: #8b786f; -} - -.header-level-6 { - margin: .8em 0; - font-size: .85em; - font-style: italic; -} diff --git a/stylesheets/stylesheet.css b/stylesheets/stylesheet.css new file mode 100644 index 0000000..7e3b8f0 --- /dev/null +++ b/stylesheets/stylesheet.css @@ -0,0 +1,479 @@ +/* http://meyerweb.com/eric/tools/css/reset/ + v2.0 | 20110126 + License: none (public domain) +*/ +html, body, div, span, applet, object, iframe, +h1, h2, h3, h4, h5, h6, p, blockquote, pre, +a, abbr, acronym, address, big, cite, code, +del, dfn, em, img, ins, kbd, q, s, samp, +small, strike, strong, sub, sup, tt, var, +b, u, i, center, +dl, dt, dd, ol, ul, li, +fieldset, form, label, legend, +table, caption, tbody, tfoot, thead, tr, th, td, +article, aside, canvas, details, embed, +figure, figcaption, footer, header, hgroup, +menu, nav, output, ruby, section, summary, +time, mark, audio, video { + margin: 0; + padding: 0; + border: 0; + font-size: 100%; + font: inherit; + vertical-align: baseline; +} +/* HTML5 display-role reset for older browsers */ +article, aside, details, figcaption, figure, +footer, header, hgroup, menu, nav, section { + display: block; +} +body { + line-height: 1; +} +ol, ul { + list-style: none; +} +blockquote, q { + quotes: none; +} +blockquote:before, blockquote:after, +q:before, q:after { + content: ''; + content: none; +} +table { + border-collapse: collapse; + border-spacing: 0; +} + +/* LAYOUT STYLES */ +body { + font-size: 15px; + line-height: 1.5; + background: #fafafa url(../images/body-bg.jpg) 0 0 repeat; + font-family: 'Helvetica Neue', Helvetica, Arial, serif; + font-weight: 400; + color: #666; +} + +a { + color: #2879d0; +} +a:hover { + color: #2268b2; +} + +header { + padding-top: 40px; + padding-bottom: 40px; + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + background: #2e7bcf url(../images/header-bg.jpg) 0 0 repeat-x; + border-bottom: solid 1px #275da1; +} + +header h1 { + letter-spacing: -1px; + font-size: 72px; + color: #fff; + line-height: 1; + margin-bottom: 0.2em; + width: 540px; +} + +header h2 { + font-size: 26px; + color: #9ddcff; + font-weight: normal; + line-height: 1.3; + width: 540px; + letter-spacing: 0; +} + +.inner { + position: relative; + width: 940px; + margin: 0 auto; +} + +#content-wrapper { + border-top: solid 1px #fff; + padding-top: 30px; +} + +#main-content { + width: 690px; + float: left; +} + +#main-content img { + max-width: 100%; +} + +aside#sidebar { + width: 200px; + padding-left: 20px; + min-height: 504px; + float: right; + background: transparent url(../images/sidebar-bg.jpg) 0 0 no-repeat; + font-size: 12px; + line-height: 1.3; +} + +aside#sidebar p.repo-owner, +aside#sidebar p.repo-owner a { + font-weight: bold; +} + +#downloads { + margin-bottom: 40px; +} + +a.button { + width: 134px; + height: 58px; + line-height: 1.2; + font-size: 23px; + color: #fff; + padding-left: 68px; + padding-top: 22px; + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; +} +a.button small { + display: block; + font-size: 11px; +} +header a.button { + position: absolute; + right: 0; + top: 0; + background: transparent url(../images/github-button.png) 0 0 no-repeat; +} +aside a.button { + width: 138px; + padding-left: 64px; + display: block; + background: transparent url(../images/download-button.png) 0 0 no-repeat; + margin-bottom: 20px; + font-size: 21px; +} + +code, pre { + font-family: Monaco, "Bitstream Vera Sans Mono", "Lucida Console", Terminal, monospace; + color: #222; + margin-bottom: 30px; + font-size: 13px; +} + +code { + background-color: #f2f8fc; + border: solid 1px #dbe7f3; + padding: 0 3px; +} + +pre { + padding: 20px; + background: #fff; + text-shadow: none; + overflow: auto; + border: solid 1px #f2f2f2; +} +pre code { + color: #2879d0; + background-color: #fff; + border: none; + padding: 0; +} + +ul, ol, dl { + margin-bottom: 20px; +} + + +/* COMMON STYLES */ + +hr { + height: 1px; + line-height: 1px; + margin-top: 1em; + padding-bottom: 1em; + border: none; + background: transparent url('../images/hr.png') 0 0 no-repeat; +} + +table { + width: 100%; + border: 1px solid #ebebeb; +} + +th { + font-weight: 500; +} + +td { + border: 1px solid #ebebeb; + text-align: center; + font-weight: 300; +} + +form { + background: #f2f2f2; + padding: 20px; + +} + + +/* GENERAL ELEMENT TYPE STYLES */ + +#main-content h1 { + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + font-size: 2.8em; + letter-spacing: -1px; + color: #474747; +} + +#main-content h1:before { + content: "/"; + color: #9ddcff; + padding-right: 0.3em; + margin-left: -0.9em; +} + +#main-content h2 { + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + font-size: 22px; + font-weight: bold; + margin-bottom: 8px; + color: #474747; +} +#main-content h2:before { + content: "//"; + color: #9ddcff; + padding-right: 0.3em; + margin-left: -1.5em; +} + +#main-content h3 { + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + font-size: 18px; + font-weight: bold; + margin-top: 24px; + margin-bottom: 8px; + color: #474747; +} + +#main-content h3:before { + content: "///"; + color: #9ddcff; + padding-right: 0.3em; + margin-left: -2em; +} + +#main-content h4 { + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + font-size: 15px; + font-weight: bold; + color: #474747; +} + +h4:before { + content: "////"; + color: #9ddcff; + padding-right: 0.3em; + margin-left: -2.8em; +} + +#main-content h5 { + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + font-size: 14px; + color: #474747; +} +h5:before { + content: "/////"; + color: #9ddcff; + padding-right: 0.3em; + margin-left: -3.2em; +} + +#main-content h6 { + font-family: 'Architects Daughter', 'Helvetica Neue', Helvetica, Arial, serif; + font-size: .8em; + color: #474747; +} +h6:before { + content: "//////"; + color: #9ddcff; + padding-right: 0.3em; + margin-left: -3.7em; +} + +p { + margin-bottom: 20px; +} + +a { + text-decoration: none; +} + +p a { + font-weight: 400; +} + +blockquote { + font-size: 1.6em; + border-left: 10px solid #e9e9e9; + margin-bottom: 20px; + padding: 0 0 0 30px; +} + +ul li { + list-style: disc inside; + padding-left: 20px; +} + +ol li { + list-style: decimal inside; + padding-left: 3px; +} + +dl dd { + font-style: italic; + font-weight: 100; +} + +footer { + background: transparent url('../images/hr.png') 0 0 no-repeat; + margin-top: 40px; + padding-top: 20px; + padding-bottom: 30px; + font-size: 13px; + color: #aaa; +} + +footer a { + color: #666; +} +footer a:hover { + color: #444; +} + +/* MISC */ +.clearfix:after { + clear: both; + content: '.'; + display: block; + visibility: hidden; + height: 0; +} + +.clearfix {display: inline-block;} +* html .clearfix {height: 1%;} +.clearfix {display: block;} + +/* #Media Queries +================================================== */ + +/* Smaller than standard 960 (devices and browsers) */ +@media only screen and (max-width: 959px) {} + +/* Tablet Portrait size to standard 960 (devices and browsers) */ +@media only screen and (min-width: 768px) and (max-width: 959px) { + .inner { + width: 740px; + } + header h1, header h2 { + width: 340px; + } + header h1 { + font-size: 60px; + } + header h2 { + font-size: 30px; + } + #main-content { + width: 490px; + } + #main-content h1:before, + #main-content h2:before, + #main-content h3:before, + #main-content h4:before, + #main-content h5:before, + #main-content h6:before { + content: none; + padding-right: 0; + margin-left: 0; + } +} + +/* All Mobile Sizes (devices and browser) */ +@media only screen and (max-width: 767px) { + .inner { + width: 93%; + } + header { + padding: 20px 0; + } + header .inner { + position: relative; + } + header h1, header h2 { + width: 100%; + } + header h1 { + font-size: 48px; + } + header h2 { + font-size: 24px; + } + header a.button { + background-image: none; + width: auto; + height: auto; + display: inline-block; + margin-top: 15px; + padding: 5px 10px; + position: relative; + text-align: center; + font-size: 13px; + line-height: 1; + background-color: #9ddcff; + color: #2879d0; + -moz-border-radius: 5px; + -webkit-border-radius: 5px; + border-radius: 5px; + } + header a.button small { + font-size: 13px; + display: inline; + } + #main-content, + aside#sidebar { + float: none; + width: 100% ! important; + } + aside#sidebar { + background-image: none; + margin-top: 20px; + border-top: solid 1px #ddd; + padding: 20px 0; + min-height: 0; + } + aside#sidebar a.button { + display: none; + } + #main-content h1:before, + #main-content h2:before, + #main-content h3:before, + #main-content h4:before, + #main-content h5:before, + #main-content h6:before { + content: none; + padding-right: 0; + margin-left: 0; + } +} + +/* Mobile Landscape Size to Tablet Portrait (devices and browsers) */ +@media only screen and (min-width: 480px) and (max-width: 767px) {} + +/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */ +@media only screen and (max-width: 479px) {}