# HG changeset patch
# User Christian Urban 
The background for this project is that some regular expressions are 
-  "evil" 
-  and can "stab you in the back" according to
+  “evil”
+  and can “stab you in the back” according to
   this blog post.
   For example, if you use in Python or 
   in Ruby (probably also in other mainstream programming languages) the 
@@ -69,7 +69,7 @@
   re.rb 
   (Ruby version). You can imagine an attacker
   mounting a nice DoS attack against 
-  your program if it contains such an "evil" regular expression. Actually 
+  your program if it contains such an “evil” regular expression. Actually 
   Scala (and also Java) are almost immune from such
   attacks as they can deal with strings of up to 4,300 as in less than a second. But if you scale
   the regular expression and string further to, say, 4,600 as, then you get a StackOverflowError 
@@ -87,7 +87,7 @@
   derivatives of regular expressions.
   These derivatives were introduced in 1964 by 
   Janusz Brzozowski, but according to this 
-  paper had been lost in the "sands of time".
+  paper had been lost in the “sands of time”.
   The advantage of derivatives is that they side-step completely the usual 
   translations of regular expressions
   into NFAs or DFAs, which can introduce the exponential behaviour exhibited by the regular
@@ -106,7 +106,7 @@
   I used them once myself in a paper 
   in order to prove the Myhill-Nerode theorem.
   So I know they are worth their money. Still, it would be interesting to actually compare their results
-  with my simple rainy-afternoon matcher and potentially "blow away" the regular expression matchers 
+  with my simple rainy-afternoon matcher and potentially “blow away” the regular expression matchers 
   in Python and Ruby (and possibly in Scala too).
   
However, there is one restriction that makes this project harder than it seems - as first sight. The department does not allow large server applications and databases - to be run on calcium - the central server in the department. So the problem should be solved with as few resources needed - on the "back-end" which collects the votes. + at first sight: The department does not allow large server applications and databases + to be run on calcium, which is the central server in the department. So the problem + should be solved with as few resources as possible + on the “back-end” collecting the votes.