From 3979c192b538d34ccc3657ab3cde52728f50b848 Mon Sep 17 00:00:00 2001 From: Ed Costello Date: Mon, 10 Jul 2017 10:04:22 -0400 Subject: [PATCH] Copy edits for typos/misspellings (#811) --- commands/command.md | 2 +- topics/ARM.md | 4 ++-- topics/indexes.md | 4 ++-- topics/rediscli.md | 2 +- topics/replication.md | 2 +- topics/twitter-clone.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/commands/command.md b/commands/command.md index 03122cee76..88c0ef5a7a 100644 --- a/commands/command.md +++ b/commands/command.md @@ -99,7 +99,7 @@ Command flags is @array-reply containing one or more status replies: Some Redis commands have no predetermined key locations. For those commands, flag `movablekeys` is added to the command flags @array-reply. Your Redis -Cluster client needs to parse commands marked `movabkeleys` to locate all relevant key positions. +Cluster client needs to parse commands marked `movablekeys` to locate all relevant key positions. Complete list of commands currently requiring key location parsing: diff --git a/topics/ARM.md b/topics/ARM.md index 67a5b62fec..7c649b5e1e 100644 --- a/topics/ARM.md +++ b/topics/ARM.md @@ -35,13 +35,13 @@ run as expected. There is nothing special in the process. The only difference is that by default, Redis uses the libc allocator instead of defaulting to Jemalloc as it does in other Linux based environments. This is because we believe -that for the small use cases inside embeddeed devices, memory fragmentation +that for the small use cases inside embedded devices, memory fragmentation is unlikely to be a problem. Moreover Jemalloc on ARM may not be as tested as the libc allocator. ## Performance -Performance testing of Redis was performend in the Raspberry Pi 3 and in the +Performance testing of Redis was performed in the Raspberry Pi 3 and in the original model B Pi. The difference between the two Pis in terms of delivered performance is quite big. The benchmarks were performed via the loopback interface, since most use cases will probably use Redis from within diff --git a/topics/indexes.md b/topics/indexes.md index 0e4b50582f..a7dd0b0c30 100644 --- a/topics/indexes.md +++ b/topics/indexes.md @@ -644,7 +644,7 @@ What we do is to start with the left bottom corner of our search box, which is 50,100, and find the first range by substituting the last 6 bits in each number with 0. Then we do the same with the right top corner. -With two trivial nested for loops where we increment only the significative +With two trivial nested for loops where we increment only the significant bits, we can find all the squares between these two. For each square we convert the two numbers into our interleaved representation, and create the range using the converted representation as our start, and the same @@ -687,7 +687,7 @@ Turning this into code is simple. Here is a Ruby example: While non immediately trivial this is a very useful indexing strategy that in the future may be implemented in Redis in a native way. -For now, the good thing is that the complexity may be easily encapsualted +For now, the good thing is that the complexity may be easily encapsulated inside a library that can be used in order to perform indexing and queries. One example of such library is [Redimension](https://github.com/antirez/redimension), a proof of concept Ruby library which indexes N-dimensional data inside Redis using the technique described here. diff --git a/topics/rediscli.md b/topics/rediscli.md index 27ff39f6a5..8373bc0b0e 100644 --- a/topics/rediscli.md +++ b/topics/rediscli.md @@ -679,7 +679,7 @@ name is simply `--slave`. This is how it works: "SELECT","0" "set","foo","bar" "PING" - "incr","myconuter" + "incr","mycounter" The command begins by discarding the RDB file of the first synchronization and then logs each command received as in CSV format. diff --git a/topics/replication.md b/topics/replication.md index 83737c92bd..518fabc3c5 100644 --- a/topics/replication.md +++ b/topics/replication.md @@ -155,7 +155,7 @@ use case for storing ephemeral data in writable slaves. For example computing slow Set or Sorted set operations and storing them into local keys is an use case for writable slaves that was observed multiple times. -However note that **writable slaves before version 4.0 were uncapable of expiring keys with a time to live set**. This means that if you use `EXPIRE` or other commands that set a maximum TTL for a key, the key will leak, and while you may no longer see it while accessing it with read commands, you will see it in the count of keys and it will still use memory. So in general mixing writable slaves (previous version 4.0) and keys with TTL is going to create issues. +However note that **writable slaves before version 4.0 were incapable of expiring keys with a time to live set**. This means that if you use `EXPIRE` or other commands that set a maximum TTL for a key, the key will leak, and while you may no longer see it while accessing it with read commands, you will see it in the count of keys and it will still use memory. So in general mixing writable slaves (previous version 4.0) and keys with TTL is going to create issues. Redis 4.0 RC3 and greater versions totally solve this problem and now writable slaves are able to evict keys with TTL as masters do, with the exceptions diff --git a/topics/twitter-clone.md b/topics/twitter-clone.md index febe1e96d8..e27f350831 100644 --- a/topics/twitter-clone.md +++ b/topics/twitter-clone.md @@ -265,7 +265,7 @@ This is the actual code: goback("Wrong username or password"); $realpassword = $r->hget("user:$userid","password"); if ($realpassword != $password) - goback("Wrong useranme or password"); + goback("Wrong username or password"); # Username / password OK, set the cookie and redirect to index.php $authsecret = $r->hget("user:$userid","auth");