Removed italics on quoted text

.cache_hx

@@ -1,11 +1,11 @@
 5c077be0b38b57d5a26de50b3c9bacf45ea9608e  chapter2.wd
 a378a85a1afe997c61224307971534c64ac1a525  chapter4.wd
-b4df485628148efe371a44a4d8fdf1b3544b94b9  chapter5.wd
 c5c3b37b6dbed1f8974d788182f886ff939171cf  all.wd
 a9448c5ef91de2083e0464028b786f3a1ab3937b  chapter3.wd
 f78cb1d5fb60462b11f0a85da692dad28919bdf8  chapter6.wd
 cd00ccaa01724d7a22ea6dfef912b6440da39fa0  chapter1.wd
 d3a4c72d28e516daa71a7661100915d1741d8778  preface.wd
 2e40ba8506aa074e7a7d567edd92265499390602  chapter7.wd
-1f643c2b95707bd37f39e0625fb5fae4201ff599  chapter8.wd
 cba9875dfca1a655488011babd24161fe4f69c25  postface.wd
+2af2616bc27709f7d706f4bdddcee646b2a54837  chapter5.wd
+f80735f0a7b5bc8014846770326ad46f7f9ca6c1  chapter8.wd

.cache_lua

@@ -1,11 +1,11 @@
 8111e9143750b64f80f372ba914a27719f0ffe30  chapter2.wd
 402cdb35294475cd1581c5c1e4cc2f6f82fe7819  chapter4.wd
-bd6a701d300416b65aa829772df5ffacc282410f  chapter5.wd
 60456bf61f72f010982487fc0e2f6da6d8fcbdfd  all.wd
 a013a749e9f04caed215f1fee40fad53bf56bda3  chapter3.wd
 43322c2f1217a53441fad4c54eae111d9a4d9a17  chapter6.wd
 3e1fee6dbd888a884eb216309a931af3f7ea21b9  chapter1.wd
 d3a4c72d28e516daa71a7661100915d1741d8778  preface.wd
 2e40ba8506aa074e7a7d567edd92265499390602  chapter7.wd
-fca77cbc4d264bad00a8f770cd352a7a75cc81e0  chapter8.wd
 cba9875dfca1a655488011babd24161fe4f69c25  postface.wd
+1f9ad47ba20d2321b0854be98d311f9dbc16d096  chapter5.wd
+0613cc18ab8d2e1294b3abed6d40e815e2901994  chapter8.wd

.cache_main

@@ -1 +1 @@
-a639096ef7764339c33c3a6829f043fd0879df3d  scoreboard.wd
+daaf8497c647503bb412139b581bd8c138219699  scoreboard.wd

.cache_page

@@ -1,11 +1,11 @@
 be796f17f149ba0960c69375e6d7e574fafaddee  chapter2.wd
 38a6089b465f904f99913b777d4befd2a431c0d1  chapter4.wd
-08e3fb5e4cfe04fe3b67345f61df957042fc299c  chapter5.wd
 43c0dfa50dd8c2ac4c6bd2b10fbb2924aa0adfb6  all.wd
 b8900dc46a410547505a4ed6ca658de8648dbc93  chapter3.wd
 c7c304efdd8d448a0955a4c5cfc71b1e3c2e0df7  chapter6.wd
 274122251bc7d4a08cab4d74837405e41fbcd4eb  chapter1.wd
 d3a4c72d28e516daa71a7661100915d1741d8778  preface.wd
 2e40ba8506aa074e7a7d567edd92265499390602  chapter7.wd
-fb04c9e9fd5f71c98969475e7374ddedecbb3b82  chapter8.wd
 cba9875dfca1a655488011babd24161fe4f69c25  postface.wd
+6ce7f73827c420870efc658f3508c2c740d7e430  chapter5.wd
+6946e0ebfe35bde36c6d1f41ce96e9369cd8a3a8  chapter8.wd

.cache_php

@@ -1,11 +1,11 @@
 85772d4c635419667450de8c560f48984b4cb278  chapter2.wd
 6a130a92a262018225d478c106af859e88bb7db9  chapter4.wd
-98b482ae9f2873ff7653badeafdcbc73c488b1c3  chapter5.wd
 84556de2857c949e1f80be42c499e6a4482a4c2d  all.wd
 4aca27418ccef52f7b07d9ed1bb6d96f76f699a4  chapter3.wd
 4f6198e84c05fcce5cae00cd74e349fe2e013cce  chapter6.wd
 eb22ecb814b2498888ffb9ce271c3ca5d7f30db1  chapter1.wd
 d3a4c72d28e516daa71a7661100915d1741d8778  preface.wd
 2e40ba8506aa074e7a7d567edd92265499390602  chapter7.wd
-cb166caaddbb958070fc36332561903a422c8175  chapter8.wd
 cba9875dfca1a655488011babd24161fe4f69c25  postface.wd
+c88d162f5090c75556f89d4332d69d0d16e4c7df  chapter5.wd
+2401515fa3652b4ec3bb2b5c4dbea15dc530b088  chapter8.wd

.cache_py

@@ -1,11 +1,11 @@
 c2b48f941c55e8cc2001eac9f4d5521eb5680a3b  chapter2.wd
 2b85719f1b774f2f7155632a7d2105b1e992c222  chapter4.wd
-580b66df9a7cac119cca6ed95e9f8c7c8f3900cc  chapter5.wd
 1ed1f82517a1901947eb9e824ff2e9f2e9eb09a3  all.wd
 272c993b7b1aedc0b0d3ff60880e1fc0b1511c4c  chapter3.wd
 bf4885c23bbf5abdc1c4e903f6799acf17c43e13  chapter6.wd
 641040959347fe9fa4c4b4865f4f84afaa779329  chapter1.wd
 d3a4c72d28e516daa71a7661100915d1741d8778  preface.wd
 2e40ba8506aa074e7a7d567edd92265499390602  chapter7.wd
-dcebae8feb0923b35b1e1710cf1883f5b8bf34f0  chapter8.wd
 cba9875dfca1a655488011babd24161fe4f69c25  postface.wd
+aed6b0433d7ed42dd3661d6cbe43e3f73b1d1495  chapter5.wd
+4ac2905c0749b2f0542b95b37e05d4f1f11d276c  chapter8.wd

chapter1.txt

@@ -767,7 +767,7 @@ In early 2012, 0MQ/3.2 became stable enough for live use and by the time you're
 
 The main change in 3.x is that PUB-SUB works properly, as in, the publisher only sends subscribers stuff they actually want. In 2.x, publishers send everything and the subscribers filter. Simple, but not ideal for performance on a TCP network.
 
-Most of the API is backwards compatible, except a few blockheaded changes that went into 3.0 with no real regard to the cost of breaking existing code. The syntax of zmq_send[3] and zmq_recv[3] changed, and ZMQ_NOBLOCK got rebaptised to ZMQ_DONTWAIT. So although I'd love to say, //"you just recompile your code with the latest libzmq and everything will work"//, that's not how it is. For what it's worth, we banned such API breakage afterwards.
+Most of the API is backwards compatible, except a few blockheaded changes that went into 3.0 with no real regard to the cost of breaking existing code. The syntax of zmq_send[3] and zmq_recv[3] changed, and ZMQ_NOBLOCK got rebaptised to ZMQ_DONTWAIT. So although I'd love to say, "you just recompile your code with the latest libzmq and everything will work", that's not how it is. For what it's worth, we banned such API breakage afterwards.
 
 So the minimal change for C/C++ apps that use the low-level libzmq API is to replace all calls to zmq_send with zmq_msg_send, and zmq_recv with zmq_msg_recv. In other languages, your binding author may have done the work already. Note that these two functions now return -1 in case of error, and zero or more according to how many bytes were sent or received.
 

chapter2.txt

@@ -24,7 +24,7 @@ We'll cover:
 
 +++ The Zen of Zero
 
-The Ø in 0MQ is all about tradeoffs. On the one hand this strange name lowers 0MQ's visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like "ØMG røtfl", and "//Ø is not a funny looking zero!//" and "//Rødgrød med Fløde!//", which is apparently an insult that means "may your neighbours be the direct descendants of Grendel!"  Seems like a fair trade.
+The Ø in 0MQ is all about tradeoffs. On the one hand this strange name lowers 0MQ's visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like "ØMG røtfl", and "Ø is not a funny looking zero!" and "//Rødgrød med Fløde!//", which is apparently an insult that means "may your neighbours be the direct descendants of Grendel!"  Seems like a fair trade.
 
 Originally the zero in 0MQ was meant as "zero broker" and (as close to) "zero latency" (as possible). In the meantime it has come to cover different goals: zero administration, zero cost, zero waste. More generally, "zero" refers to the culture of minimalism that permeates the project. We add power by removing complexity rather than exposing new functionality.
 
@@ -193,7 +193,7 @@ The inter-thread transport, **{{inproc}}**, is a connected signaling transport.
 
 +++ 0MQ is Not a Neutral Carrier
 
-A common question that newcomers to 0MQ ask (it's one I asked myself) is something like, "//how do I write a XYZ server in 0MQ?//"  For example, "how do I write an HTTP server in 0MQ?"
+A common question that newcomers to 0MQ ask (it's one I asked myself) is something like, "how do I write a XYZ server in 0MQ?" For example, "how do I write an HTTP server in 0MQ?"
 
 The implication is that if we use normal sockets to carry HTTP requests and responses, we should be able to use 0MQ sockets to do the same, only much faster and better.
 
@@ -885,7 +885,7 @@ The two (or three sockets, if we want to capture data) must be properly connecte
 [[code type="example" title="Message queue broker" name="msgqueue"]]
 [[/code]]
 
-If you're like most 0MQ users, at this stage your mind is starting to think, "//what kind of evil stuff can I do if I plug random socket types into the proxy?//"  The short answer is: try it and work out what is happening. In practice you would usually stick to ROUTER/DEALER, XSUB/XPUB, or PULL/PUSH.
+If you're like most 0MQ users, at this stage your mind is starting to think, "what kind of evil stuff can I do if I plug random socket types into the proxy?"  The short answer is: try it and work out what is happening. In practice you would usually stick to ROUTER/DEALER, XSUB/XPUB, or PULL/PUSH.
 
 ++++ The Transport Bridging Problem
 
@@ -949,7 +949,7 @@ By "perfect" MT programs I mean code that's easy to write and understand, that w
 
 If you've spent years learning tricks to make your MT code work at all, let alone rapidly, with locks and semaphores and critical sections, you will be disgusted when you realize it was all for nothing. If there's one lesson we've learned from 30+ years of concurrent programming it is: //just don't share state//. It's like two drunkards trying to share a beer. It doesn't matter if they're good buddies. Sooner or later they're going to get into a fight. And the more drunkards you add to the table, the more they fight each other over the beer. The tragic majority of MT applications look like drunken bar fights.
 
-The list of weird problems that you need to fight as you write classic shared-state MT code would be hilarious if it didn't translate directly into stress and risk, as code that seems to work suddenly fails under pressure. Here is a list of "//11 Likely Problems In Your Multithreaded Code//" from a large firm with world-beating experience in buggy code: forgotten synchronization, incorrect granularity, read and write tearing, lock-free reordering, lock convoys, two-step dance, and priority inversion.
+The list of weird problems that you need to fight as you write classic shared-state MT code would be hilarious if it didn't translate directly into stress and risk, as code that seems to work suddenly fails under pressure. Here is a list of "11 Likely Problems In Your Multithreaded Code" from a large firm with world-beating experience in buggy code: forgotten synchronization, incorrect granularity, read and write tearing, lock-free reordering, lock convoys, two-step dance, and priority inversion.
 
 Yeah, we also counted seven, not eleven. That's not the point though. The point is, do you really want that code running the power grid or stock market to start getting two-step lock convoys at 3pm on a busy Thursday? Who cares what the terms actually mean. This is not what turned us on to programming, fighting ever more complex side-effects with ever more complex hacks.
 

chapter3.txt

@@ -978,7 +978,7 @@ So idea #2 then. We interconnect the brokers and don't touch the clients or work
                         :
 [[/code]]
 
-This design is appealing because the problem is solved in one place, invisible to the rest of the world. Basically, brokers open secret channels to each other and whisper, like camel traders, "//Hey, I've got some spare capacity, if you have too many clients give me a shout and we'll deal"//.
+This design is appealing because the problem is solved in one place, invisible to the rest of the world. Basically, brokers open secret channels to each other and whisper, like camel traders, "Hey, I've got some spare capacity, if you have too many clients give me a shout and we'll deal".
 
 It is in effect just a more sophisticated routing algorithm: brokers become subcontractors for each other. Other things to like about this design, even before we play with real code:
 

chapter5.txt

@@ -616,7 +616,7 @@ To test the sixth model, start the primary server and backup server, and a set o
 
 After this much work to build reliable pub-sub, we want some guarantee that we can safely build applications to exploit the work. A good start is to write-up the protocol. This lets us make implementations in other languages and lets us improve the design on paper, rather than hands-deep in code.
 
-Here, then, is the Clustered Hashmap Protocol, which "//defines a cluster-wide key-value hashmap, and mechanisms for sharing this across a set of clients. CHP allows clients to work with subtrees of the hashmap, to update values, and to define ephemeral values.//"
+Here, then, is the Clustered Hashmap Protocol, which "defines a cluster-wide key-value hashmap, and mechanisms for sharing this across a set of clients. CHP allows clients to work with subtrees of the hashmap, to update values, and to define ephemeral values."
 
 * http://rfc.zeromq.org/spec:12