Merge branch 'master' into remove-old-addons

README.ko.md

@@ -7,7 +7,7 @@ ofBook
 - English(영어) : [README.md](README.md)
 
 **이 저장소는 현재 작업 진행중임을 명심하십시오**
-
+**현재는 ofBook은 영어로만 보여지고 있습니다. [이곳](http://openframeworks.cc/ofBook/)에서 확인할 수 있습니다. 한국어 및 일본어 번역이 진행중에 있습니다.**
 
 # 책 빌드하기
 

chapters/animation/chapter.md

@@ -34,24 +34,24 @@ The second point to make about animation is that it requires variables. A variab
 
 ```cpp
 void ofApp::setup(){
-    xpos = 5;  // vertical start position
+    xpos = 5;  // horizontal start position
     ofBackground(ofColor::black);  // black background
 }
 
 void ofApp::update(){
     xpos += 2;
-    if(ofGetWidth()<xPos){  // if vertical position is off the screen (width)
-        xPos = 5;             // reset vertical position
+    if(ofGetWidth()<xPos){  // if horizontal position is off the screen (width)
+        xPos = 5;             // reset horizontal position
     }
 }
 
 void ofApp::draw(){
     ofSetColor(ofColor::red);  // draw everything in red
-    ofDrawCircle(xpos, 100, 10);   // draw a circle at the (variable) vertical position, 100 pixels from the top with a 10 pixel diameter
+    ofDrawCircle(xpos, 100, 10);   // draw a circle at the (variable) horizontal position, 100 pixels from the top with a 10 pixel diameter
 }
 ```
 
-In this example a red circle moves from the left to the right on the screen. The vertical position (`xpos`) is an integer and gets set to 5 as the initial value in `setup()`. The `update()` function always adds 2 to the `xpos` variable and stores the new value until it becomes larger than the screen width (`ofGetWidth()`), then the vertical position gets reset. The `draw()` function reads the value stored in the variable `xpos` and draws the red circle accordingly.
+In this example a red circle moves from the left to the right on the screen. The horizontal position (`xpos`) is an integer and gets set to 5 as the initial value in `setup()`. The `update()` function always adds 2 to the `xpos` variable and stores the new value until it becomes larger than the screen width (`ofGetWidth()`), then the horizontal position gets reset. The `draw()` function reads the value stored in the variable `xpos` and draws the red circle accordingly.
 
 ### Frame rate
 
@@ -96,7 +96,7 @@ void testApp::update(){
 }
 ```
 
-Here `ofGetLastFrameTime()` returns the time it took to complete the last frame. Since this tome has passed in the system, we use it to multiply with the speed. This is going to yield the distance (virtually) travelled by the rectangle. Now it is effectively moving at the same speed regardless of frame rate.  Frame rate independence is fairly important to think about once you get the hang of things. As observers of animation, we really do feel objects speeding up or slowing down even slightly, but in this chapter I will skip it for the sake of simplicity in the code.
+Here `ofGetLastFrameTime()` returns the time it took to complete the last frame. Since this time has passed in the system, we use it to multiply with the speed. This is going to yield the distance (virtually) travelled by the rectangle. Now it is effectively moving at the same speed regardless of frame rate.  Frame rate independence is fairly important to think about once you get the hang of things. As observers of animation, we really do feel objects speeding up or slowing down even slightly, but in this chapter I will skip it for the sake of simplicity in the code.
 
 ### Time functions
 
@@ -177,7 +177,7 @@ void rectangle::interpolateByPct(float myPct){
 }
 ```
 
-in the ofApp file, we create a variable called pct, and set it to 0.  We increate pct every frame and pass it through to the rectangle object in the update function:  
+in the ofApp file, we create a variable called pct, and set it to 0.  We increment pct every frame and pass it through to the rectangle object in the update function:  
 
 
 ```cpp

chapters/c++11/chapter.md

@@ -411,7 +411,7 @@ One way of doing this would be to store some data saying that we needed to chang
 
 A nice workaround is to use lambda functions for this purpose, e.g. :
 
-```
+```cpp
 class CameraClass : public ofThread {
 protected:
 	void threadedFunction() override {

chapters/generativemesh/chapter.md

@@ -230,7 +230,7 @@ So we need some data and some rules.  Let's grab some "data" in the form of an i
 
 ![Original hubble image](images/stars.png)
 
-Create a new openFrameworks project called HubbleMesh. Inside that project create the bin/data directory ('bin' may already exist) and save the above image there as "stars.png".  (Click [here](/images/stars.png), then right-click the image and "save as image.")
+Create a new openFrameworks project called HubbleMesh. Inside that project create the bin/data directory ('bin' may already exist) and save the above image there as "stars.png".  (Click [here](https://raw.githubusercontent.com/openframeworks/ofBook/master/chapters/generativemesh/images/stars.png), then right-click the image and "save as image.")
 
 Now we have some colorful, pixely goodness, but what rules should we use to transform those pixels into a mesh?  We can start with drawing points and work our way up to drawing lines.  Our image has a ton of stars, so let's create some vertices where those stars are located.  Once we do that, we can connect up neighboring vertices with lines in order to create a web of sorts.
 

chapters/memory/chapter.md

@@ -855,7 +855,7 @@ void ofApp::setup(){
 now ofApp doesn't know anymore about the allocated memory but both cases are possible so we actually need to know details of the implementation of object to know if we need to keep a reference of that variable to destroy it later or not. That, among other things breaks encapsulation, that you might now from chapter 1. We shouldn't need to know how object works internally to be able to use it. This makes the logic of our code really complicated and error prone.
 
 
-Smart pointers solve this by clearly defining who owns and object and by automatically deleting the allocated memory when the owner is destroyed. Sometimes, we need to share an object among several owners. For that cases we have a special type of smart pointers called shared pointers that defined a shader ownership and free the allocated memory only when all the owners cease to use the variable.
+Smart pointers solve this by clearly defining who owns an object and by automatically deleting the allocated memory when the owner is destroyed. Sometimes, we need to share an object among several owners. For that cases we have a special type of smart pointers called shared pointers that defined a shared ownership and free the allocated memory only when all the owners cease to use the variable.
 
 We are only going to see this briefly, there's lots of examples in the web about how to use smart pointers and reference to their syntax, the most important is to understand how they work by defining the ownership clearly compared to raw pointers and the problems they solve.
 
@@ -883,7 +883,7 @@ void ofApp::setup(){
 
 We can also use the `->` to access it's member variables and functions.
 
-When the function goes out of scope, being unique_ptr an object, it's destructor will get called, which internally will call `delete` on the allocated memory so we don't need to call delete on unique_ptr at all.
+When the function goes out of scope, since unique_ptr is an object, it's destructor will get called, which internally will call `delete` on the allocated memory so we don't need to call delete on unique_ptr at all.
 
 Now let's say we want to move a unique_ptr into a vector:
 
@@ -924,7 +924,7 @@ void ofApp::setup(){
 }
 ```
 
-The compiler won't fail there but if we try to execute the application it'll crash since `a` is not owned by ofApp::setup anymore, having to explicitly use `move` tries to solve that problem by making the syntax clearer. After using move, we can't use that variable anymore except through the vector. More modern langauages like [Rust](http://www.rust-lang.org/) completely solve this by making the compiler detect this kind of uses of moved variables and producing a compiler error. This will probably be solved at some point in c++ but by now you need to be careful to not use a moved variable.
+The compiler won't fail there but if we try to execute the application it'll crash since `a` is not owned by ofApp::setup anymore, having to explicitly use `move` tries to solve that problem by making the syntax clearer. After using move, we can't use that variable anymore except through the vector. More modern langauages like [Rust](http://www.rust-lang.org/) completely solve this by making the compiler detect these kinds of uses of moved variables and producing a compiler error. This will probably be solved at some point in c++ but for now you need to be careful to not use a moved variable.
 
 
 ###shared_ptr
@@ -956,4 +956,4 @@ void ofApp::setup(){
 }
 ```
 
-Is perfectly ok. The way a shared_ptr works is by keeping a count of how many references there are to it, whenever we make a copy of it, it increases that counter by one, whenever a reference is destroyed it decreases that reference by one. When the reference cound arrives to 0 it frees the allocated memory. That reference counting is done atomically, which means that we can share a shared_ptr across threads without having problems with the count. That doesn't mean that we can access the contained data safely in a multithreaded application, just that the reference count won't get wrong if we pass a shared_ptr accross different threads.
+Is perfectly ok. The way a shared_ptr works is by keeping a count of how many references there are to it, whenever we make a copy of it, it increases that counter by one, whenever a reference is destroyed it decreases that reference by one. When the reference count arrives to 0 it frees the allocated memory. The reference counting is done atomically, which means that we can share a shared_ptr across threads without having problems with the count. That doesn't mean that we can access the contained data safely in a multithreaded application, just that the reference count won't get wrong if we pass a shared_ptr accross different threads.