Skip to content

Commit 98f879d

Browse files
authored
Merge pull request funcool#18 from dspearson/master
Minor spelling & grammar corrections.
2 parents b70ebdb + d43e657 commit 98f879d

File tree

1 file changed

+18
-18
lines changed

1 file changed

+18
-18
lines changed

doc/content.adoc

+18-18
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ And the library works with the following platforms: *jdk7*, *jdk8*, *node-lts*.
4141
== Getting started
4242

4343
The main goal of _octet_ is provide, multiplatform abstraction for work with
44-
byte buffer's. Offering a ligweight api for define message types in a declarative
44+
byte buffers. Offering a lightweight api for define message types in a declarative
4545
way and use them for read or write to bytebuffers.
4646

4747
As previously said, _octet_ works with both most used clojure implementations:
@@ -59,7 +59,7 @@ Two most common composition types are: associative and indexed.
5959

6060
The difference of indexed and associative compositions is the input and output. In
6161
associative composition the expected input and output is a map. And in indexed
62-
composition, the expected input and input is a vector. Internally them represents
62+
composition, the expected input and input is a vector. Internally it represents
6363
the same value in bytes.
6464

6565
Let start defining one:
@@ -108,7 +108,7 @@ This operation is almost platform independent if the library defaults satisfies
108108
(def buffer (buf/allocate 24))
109109
----
110110

111-
The buffer allocation is parametrizable so you can specify the concrete
111+
The buffer allocation is parameterisable so you can specify the concrete
112112
implementation to use and the type of buffer:
113113

114114
.Example allocation 24 bytes size buffer with nio buffer implementation
@@ -136,7 +136,7 @@ You can see all supported options <<supported-bytebuffers,here>>
136136

137137
[NOTE]
138138
====
139-
The return value of `allocate` depens on implementation used. Is a plain instance
139+
The return value of `allocate` depends on the implementation used. Is a plain instance
140140
without additional wrapping. If you want access to its internals, you can do it
141141
with native host platform api.
142142
====
@@ -150,7 +150,7 @@ specs. Specs are simple schema on how the data should be read or write to the bu
150150
.Example writing data into buffer using indexed composed schema
151151
[source, clojure]
152152
----
153-
;; The indexed composed spec exptects a vector as input
153+
;; The indexed composed spec expects a vector as input
154154
(buf/write! buffer [22 true] my-spec1)
155155
;; => 5
156156
----
@@ -195,8 +195,8 @@ Also, you can perform the same operation, but using a associative spec:
195195

196196
[NOTE]
197197
====
198-
This works idependently of implementation used for allocate the buffer. Some
199-
implementations has little limitations, es6 (cljs) as example, des not support
198+
This works independently of implementation used for allocate the buffer. Some
199+
implementations have a few limitations; es6 (cljs) as example, does not support
200200
`int64` typespec due to platform limitations.
201201
====
202202

@@ -267,7 +267,7 @@ with `repeat` composition function:
267267

268268
=== Using arbitrary size type specs
269269

270-
Until now, we have seen examples alway using fixed size compositions. Fixed size
270+
Until now, we have seen examples always using fixed size compositions. Fixed size
271271
compositions are easy understand, the size of the spec can be know in any time.
272272
But in some circumstances we want store arbitrary length. Strings are one great
273273
example:
@@ -353,9 +353,9 @@ that it has always an overhead of 4 bytes for store the length of the vector.
353353
=== Read and write spec to multiple byte buffers
354354

355355
In some circumstances (specially when we working with streams) the buffers are
356-
splitted. The simplest but not very efficient approach will be copy all data in one
356+
split. The simplest but not very efficient approach will be copy all data in one
357357
unique byte buffer and read a spec from it. Octet comes with facilities for read a
358-
spec from a vector of buffers that prevents unnecesary copy action.
358+
spec from a vector of buffers that prevents unnecessary copy action.
359359

360360
.Example reading and writing data to a vector of buffers
361361
[source, clojure]
@@ -386,7 +386,7 @@ situations. _octet_ is build around abstractions and define new type spec is not
386386
very complicated job.
387387

388388
An typespec consists mainly in `ISpec` protocol that has two methods: `read` and
389-
`write`. Let see an example defining a typespec for point of coordenades:
389+
`write`. Let see an example defining a typespec for point of coordinades:
390390

391391
.Example definition of type spec that represents a point
392392
[source, clojure]
@@ -401,7 +401,7 @@ An typespec consists mainly in `ISpec` protocol that has two methods: `read` and
401401
(reify
402402
spec/ISpecSize
403403
(size [_]
404-
;; we kwno that is datatype has fixed size in bytes
404+
;; we know that is datatype has fixed size in bytes
405405
;; that represents two int32.
406406
8)
407407
@@ -495,7 +495,7 @@ implements the same abstraction and can be used in read or write operations.
495495
=== Byte order
496496

497497
All the builtin implementations uses the `:big-endian` as default byte order. That
498-
value can be canched at any time using the provided `*byteorder*` dynamic var on
498+
value can be cached at any time using the provided `*byteorder*` dynamic var on
499499
the `octet.buffer` namespace.
500500

501501
Let see a little example:
@@ -514,7 +514,7 @@ Let see a little example:
514514
;; => 19
515515
516516
(buf/read buffer myspec)
517-
;; => BufferUnderflowException (because of incorect byte order)
517+
;; => BufferUnderflowException (because of incorrect byte order)
518518
519519
(buf/with-byte-order :little-endian
520520
(buf/read buffer myspec))
@@ -526,7 +526,7 @@ Let see a little example:
526526

527527
*What is the difference with _clojurewerkz/buffy_?*
528528

529-
*Buffy* is a excelent library, and I have used it in some circumstances, but is has
529+
*Buffy* is a excellent library, and I have used it in some circumstances, but is has
530530
some things that I personally don't like:
531531

532532
- It works only with netty bytebuf and I need an abstraction for work with
@@ -540,13 +540,13 @@ some things that I personally don't like:
540540

541541
*What is the difference with _ztellman/gloss_?*
542542

543-
Gloss is also similiar project, and has similar purposes, but it has several
544-
differeces:
543+
Gloss is also similar project, and has similar purposes, but it has several
544+
differences:
545545

546546
- It has a limited set of types. Octet has an extensible abstraction for build own
547547
arbitrary type specs.
548548
- It only works with nio as buffer implementations. Octet exposes an extensible
549-
abstraction and support few differents out of the box.
549+
abstraction and supports a few different implementations out of the box.
550550
- In my opinion it has slightly ugly and unclear api.
551551
- Seems not very maintained (has issues from 2013).
552552
- It not has support for ClojureScript.

0 commit comments

Comments
 (0)