Fix typos and grammer in coreclr README.md

README.md

@@ -33,16 +33,16 @@ related to .NET Core including:
 
 ## What Can you Make from this Repository?
 
-.NET Core relies heavily on the [Nuget](https://en.wikipedia.org/wiki/NuGet) package manager
-which is system to package, distribute and version software components.  See [https://www.nuget.org/](https://www.nuget.org/) 
+.NET Core relies heavily on the [Nuget](https://en.wikipedia.org/wiki/NuGet) package manager,
+which is the system to package, distribute and version software components.  See [https://www.nuget.org/](https://www.nuget.org/) 
 for more information on Nuget.   For now it is enough to know Nuget is a system that
 bundles components into `*.nupkg` files (which are ZIP archives) and these packages can be 'published' 
 either through a local file system path or by a URL (e.g. https://www.nuget.org/).   There are then tools 
 (e.g. Nuget.exe, Visual Studio, dotnet.exe) that based on a configuration file (project.json) know 
 how to search these publishing locations and pull down consistent set of packages for the 
 application.   
 
-In a concrete terms, this repository is best thought of as the source code for the following Nuget package
+In concrete terms, this repository is best thought of as the source code for the following Nuget package
 
  * **Microsoft.NETCore.Runtime.CoreCLR** - Represents the object allocator, garbage collector (GC), class 
    loader, type system, interop and the most fundamental parts of the .NET class library (e.g. 
@@ -59,7 +59,7 @@ It also contains the source code for the following closely related support packa
  * **Microsoft.NETCore.TestHost** - This contains the corehost.exe program, which is a small wrapper 
    that uses the .NET Runtime to run IL DLLs passed to it on the command line.
  * **Microsoft.TargetingPack.Private.CoreCLR** - A set of assemblies that represent the compile time surface 
-   area of class library implemented by the runtime itself.
+   area of the class library implemented by the runtime itself.
 
 ## Relationship with the [CoreFX](https://github.com/dotnet/corefx) Repository 
 
@@ -79,19 +79,19 @@ belongs and use that package as its **public publishing** point.   That 'facade'
 to the (private) implementation in System.Private.CoreLib.dll defined here.
 For example the *System.Runtime* package defined in CoreFX declares the PUBLIC name for types like 
 System.Object and System.String.   Thus from an applications point of view these types live in System.Runtime.dll. 
-However System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately to System.Private.CoreLib.dll 
+However, System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately to System.Private.CoreLib.dll 
 which is defined here.
 
 Thus in order to run an application, you need BOTH the Microsoft.NETCore.Runtime.CoreCLR Nuget package 
-(defined in this repository) as well as  packages for whatever you actually references that were defined 
+(defined in this repository) as well as  packages for whatever you actually reference that were defined 
 in the CoreFX repository (which at a minimum includes the System.Runtime package).    You also need some 
 sort of 'host' executable that loads the CoreCLR package as well as the CoreFX packages and starts your code (typically 
 you use dotnet.exe for this).   
 
 These extra pieces are not defined here, however you don't need to build them in order to use the CoreCLR 
 Nuget package you create here.   There are already versions of the CoreFX packages published on 
-https://www.nuget.org/ so you  can just have your test application's project.json specify the CoreCLR you 
-built it will naturally pull anything else it needs from the official location https://www.nuget.org/ to 
+https://www.nuget.org/ so you can have your test application's project.json specify the CoreCLR you 
+built and it will naturally pull anything else it needs from the official location https://www.nuget.org/, to 
 make a complete application.  More on this in the [Using Your Build](Documentation/workflow/UsingYourBuild.md) page.
 
 --------------------------
@@ -128,8 +128,8 @@ The build has two main 'buildTypes'
    can be difficult to debug.   Passing 'release' to the build script select this.  
 
 In addition, by default the build will not only create the runtime executables, but it will also 
-build all the tests.   There are quit a few tests so this does take a significant amount of time
-that is not necessary if you are just want to experiment with changes.   You can submit the building
+build all the tests.   There are quite a few tests so this does take a significant amount of time
+that is not necessary if you want to experiment with changes.   You can submit the building
 of the tests with the 'skiptests' argument to the build script.
 
 Thus to get a build as quickly as possible type the following (using \ as the directory separator, use / on Unix machines)
@@ -156,7 +156,7 @@ that were built, which are placed in the directory
 
 * bin\Product\Windows_NT.x64.Release\.nuget\pkg
 
-directory.   These packages are the 'output' of your build.   
+These packages are the 'output' of your build.   
 
 There are two basic techniques for using your new runtime.