fix serveral typos (#1558)

* fix typos in markdown files

* fix typos in CMake files

* fix typos in headers and test code
This commit is contained in:
Dirk Stolle 2021-05-01 16:19:53 +02:00 committed by GitHub
parent 85b910814e
commit 2abcc35031
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
20 changed files with 30 additions and 30 deletions

View File

@ -69,7 +69,7 @@ Pull requests are always invited. However, we ask that you follow these guidelin
3. Other types of changes must be clearly motivated. We openly discourage changes with no identifiable benefits.
- Changes should be focused and minimal. You should change as few lines of code as possible. Please do not reformat or touch files needlessly.
- New features must be accompanied of new tests, in general.
- Your code should pass our continuous-integration tests. It is your responsability to ensure that your proposal pass the tests. We do not merge pull requests that would break our build.
- Your code should pass our continuous-integration tests. It is your responsibility to ensure that your proposal pass the tests. We do not merge pull requests that would break our build.
- An exception to this would be changes to non-code files, such as documentation and assets, or trivial changes to code, such as comments, where it is encouraged to explicitly ask for skipping a CI run using the `[skip ci]` prefix in your Pull Request title **and** in the first line of the most recent commit in a push. Example for such a commit: `[skip ci] Fixed typo in power_of_ten's docs`
This benefits the project in such a way that the CI pipeline is not burdened by running jobs on changes that don't change any behavior in the code, which reduces wait times for other Pull Requests that do change behavior and require testing.

View File

@ -159,7 +159,7 @@ processor.
At this point, we are require to use one of two main strategies.
1. On POSIX systems, the main compilers (LLVM clang, GNU gcc) allow us to use any intrinsic function after including the header, but they fail to inline the resulting instruction if the target processor does not support them. Because we compile for a generic processor, we would not be able to use most intrinsic functions. Thankfully, more recent versions of these compilers allow us to flag a region of code with a specific target, so that we can compile only some of the code with support for advanced instructions. Thus in our C++, one might notice macros like `TARGET_HASWELL`. It is then our responsability, at runtime, to only run the regions of code (that we call kernels) matching the properties of the runtime processor. The benefit of this approach is that the compiler not only let us use intrinsic functions, but it can also optimize the rest of the code in the kernel with advanced instructions we enabled.
1. On POSIX systems, the main compilers (LLVM clang, GNU gcc) allow us to use any intrinsic function after including the header, but they fail to inline the resulting instruction if the target processor does not support them. Because we compile for a generic processor, we would not be able to use most intrinsic functions. Thankfully, more recent versions of these compilers allow us to flag a region of code with a specific target, so that we can compile only some of the code with support for advanced instructions. Thus in our C++, one might notice macros like `TARGET_HASWELL`. It is then our responsibility, at runtime, to only run the regions of code (that we call kernels) matching the properties of the runtime processor. The benefit of this approach is that the compiler not only let us use intrinsic functions, but it can also optimize the rest of the code in the kernel with advanced instructions we enabled.
2. Under Visual Studio, the problem is somewhat simpler. Visual Studio will not only provide the intrinsic functions, but it will also allow us to use them. They will compile just fine. It is at runtime that they may cause a crash. So we do not need to mark regions of code for compilation toward advanced processors (e.g., with `TARGET_HASWELL` macros). The downside of the Visual Studio approach is that the compiler is not allowed to use advanced instructions others than those we specify. In principle, this means that Visual Studio has weaker optimization opportunities.

View File

@ -19,7 +19,7 @@ editing CMAKE_CXX_FLAGS")
# Here, we disable both with the - argument negation operator
string(REPLACE "/EHsc" "/EHs-c-" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
# Because we cannot change the flag above on an invidual target (yet), the
# Because we cannot change the flag above on an individual target (yet), the
# definition below must similarly be added globally
add_definitions(-D_HAS_EXCEPTIONS=0)
elseif(CMAKE_COMPILER_IS_GNUCC)

View File

@ -459,7 +459,7 @@ select the value. If your keys contain the characters '/' or '~', they must be e
'~0' respectively. An empty JSON Path refers to the whole document.
We also extend the JSON Pointer support to include *relative* paths.
You can apply a JSON path to any node and the path gets interpreted relatively, as if the currrent node were a whole JSON document.
You can apply a JSON path to any node and the path gets interpreted relatively, as if the current node were a whole JSON document.
Consider the following example:
@ -816,7 +816,7 @@ Unlike `parser.parse`, both `parser.load_many(filename)` and `parser.parse_many(
document at a time.
1. When calling `parser.load_many(filename)`, the file's content is loaded up in a memory buffer owned by the `parser`'s instance. Thus the file can be safely deleted after calling `parser.load_many(filename)` as the parser instance owns all of the data.
2. When calling `parser.parse_many(string)`, no copy is made of the provided string input. The provided memory buffer may be accessed each time a JSON document is parsed. Calling `parser.parse_many(string)` on a temporary string buffer (e.g., `docs = parser.parse_many("[1,2,3]"_padded)`) is unsafe (and will not compile) because the `document_stream` instance needs access to the buffer to return the JSON documents. In constrast, calling `doc = parser.parse("[1,2,3]"_padded)` is safe because `parser.parse` eagerly parses the input.
2. When calling `parser.parse_many(string)`, no copy is made of the provided string input. The provided memory buffer may be accessed each time a JSON document is parsed. Calling `parser.parse_many(string)` on a temporary string buffer (e.g., `docs = parser.parse_many("[1,2,3]"_padded)`) is unsafe (and will not compile) because the `document_stream` instance needs access to the buffer to return the JSON documents. In contrast, calling `doc = parser.parse("[1,2,3]"_padded)` is safe because `parser.parse` eagerly parses the input.
Both `load_many` and `parse_many` take an optional parameter `size_t batch_size` which defines the window processing size. It is set by default to a large value (`1000000` corresponding to 1 MB). None of your JSON documents should exceed this window size, or else you will get the error `simdjson::CAPACITY`. You cannot set this window size larger than 4 GB: you will get the error `simdjson::CAPACITY`. The smaller the window size is, the less memory the function will use. Setting the window size too small (e.g., less than 100 kB) may also impact performance negatively. Leaving it to 1 MB is expected to be a good choice, unless you have some larger documents.

View File

@ -213,7 +213,7 @@ select the value. If your keys contain the characters '/' or '~', they must be e
'~0' respectively. An empty JSON Path refers to the whole document.
We also extend the JSON Pointer support to include *relative* paths.
You can apply a JSON path to any node and the path gets interpreted relatively, as if the currrent node were a whole JSON document.
You can apply a JSON path to any node and the path gets interpreted relatively, as if the current node were a whole JSON document.
Consider the following example:

View File

@ -636,7 +636,7 @@ direct raw ASCII comparisons: `key().raw()` provides direct access to the unesca
You can compare `key()` with unescaped C strings (e.g., `key()=="test"`). It is expected
that the provided string is a valid JSON string. Importantly,
the C string must not contain an unescaped quote character (`"`). For speed, the comparison is done byte-by-byte
without handling the escaped caracters.
without handling the escaped characters.
If you occasionally need to access and store the
unescaped key values, you may use the `unescaped_key()` method. Once you have called `unescaped_key()` method,
neither the `key()` nor the `unescaped_key()` methods should be called: the current field instance

View File

@ -25,7 +25,7 @@ if(ENABLE_FUZZING)
# (note that libFuzzer can also reproduce, just pass it the files)
#
# Using this by default, means the fuzzers will be built as a part of the normal
# workflow, meaning they wont bitrot and will participate in refactoring etc.
# workflow, meaning they won't bitrot and will participate in refactoring etc.
#
option(SIMDJSON_FUZZ_LINKMAIN "links a main into fuzz targets for building reproducers" On)

View File

@ -70,7 +70,7 @@ simdjson_really_inline uint64_t reverse_bits(uint64_t input_num) {
/**
* Flips bit at index 63 - lz. Thus if you have 'leading_zeroes' leading zeroes,
* then this will set to zero the leading bit. It is possible for leading_zeroes to be
* greating or equal to 63 in which case we trigger undefined behavior, but the ouput
* greating or equal to 63 in which case we trigger undefined behavior, but the output
* of such undefined behavior is never used.
**/
NO_SANITIZE_UNDEFINED

View File

@ -364,7 +364,7 @@ simdjson_really_inline int8x16_t make_int8x16_t(int8_t x1, int8_t x2, int8_t x
// Explicit conversion to/from unsigned
//
// Under Visual Studio/ARM64 uint8x16_t and int8x16_t are apparently the same type.
// In theory, we could check this occurence with std::same_as and std::enabled_if but it is C++14
// In theory, we could check this occurrence with std::same_as and std::enabled_if but it is C++14
// and relatively ugly and hard to read.
#ifndef SIMDJSON_REGULAR_VISUAL_STUDIO
simdjson_really_inline explicit simd8(const uint8x16_t other): simd8(vreinterpretq_s8_u8(other)) {}

View File

@ -161,7 +161,7 @@ constexpr size_t DEFAULT_MAX_DEPTH = 1024;
* the regular visual studio or clang under visual
* studio, you still need to handle these issues.
*
* Non-Windows sytems do not have this complexity.
* Non-Windows systems do not have this complexity.
*/
#if SIMDJSON_BUILDING_WINDOWS_DYNAMIC_LIBRARY
// We set SIMDJSON_BUILDING_WINDOWS_DYNAMIC_LIBRARY when we build a DLL under Windows.
@ -215,7 +215,7 @@ constexpr size_t DEFAULT_MAX_DEPTH = 1024;
// now it is safe to trigger the include
#include <string_view> // though the file is there, it does not follow that we got the implementation
#if defined(_LIBCPP_STRING_VIEW)
// Ah! So we under libc++ which under its Library Fundamentals Technical Specification, which preceeded C++17,
// Ah! So we under libc++ which under its Library Fundamentals Technical Specification, which preceded C++17,
// included string_view.
// This means that we have string_view *even though* we may not have C++17.
#define SIMDJSON_HAS_STRING_VIEW

View File

@ -123,7 +123,7 @@ public:
using iterator_category = std::input_iterator_tag;
/**
* Default contructor.
* Default constructor.
*/
simdjson_really_inline iterator() noexcept;
/**

View File

@ -208,7 +208,7 @@ public:
// throughout return true if we can do the navigation, false
// otherwise
// Withing a given scope (series of nodes at the same depth within either an
// Within a given scope (series of nodes at the same depth within either an
// array or an object), we move forward.
// Thus, given [true, null, {"a":1}, [1,2]], we would visit true, null, {
// and [. At the object ({) or at the array ([), you can issue a "down" to

View File

@ -536,7 +536,7 @@ public:
/**
* @private return an error code corresponding to the last parsing attempt, see
* simdjson.h will return UNITIALIZED if no parsing was attempted
* simdjson.h will return UNINITIALIZED if no parsing was attempted
*/
[[deprecated("Use the result of parser.parse() instead")]]
inline int get_error_code() const noexcept;

View File

@ -37,7 +37,7 @@ public:
inline void append(simdjson::dom::element value);
/** Append an array to the builder (to be printed) **/
inline void append(simdjson::dom::array value);
/** Append an objet to the builder (to be printed) **/
/** Append an object to the builder (to be printed) **/
inline void append(simdjson::dom::object value);
/** Reset the builder (so that it would print the empty string) **/
simdjson_really_inline void clear();
@ -149,7 +149,7 @@ inline std::ostream& operator<<(std::ostream& out, simdjson::simdjson_result<sim
* Print JSON to an output stream.
*
* @param out The output stream.
* @param value The objet.
* @param value The object.
* @throw if there is an error with the underlying output stream. simdjson itself will not throw.
*/
inline std::ostream& operator<<(std::ostream& out, simdjson::dom::object value) {

View File

@ -162,7 +162,7 @@ simdjson_really_inline bool compute_float_64(int64_t power, uint64_t i, bool neg
// implies that the either the most or the second most significant bit of the product
// is 1. We pack values in this manner for efficiency reasons: it maximizes the use
// we make of the product. It also makes it easy to reason about the product: there
// 0 or 1 leading zero in the product.
// is 0 or 1 leading zero in the product.
// Unless the least significant 9 bits of the high (64-bit) part of the full
// product are all 1s, then we know that the most significant 55 bits are
@ -277,7 +277,7 @@ simdjson_really_inline bool compute_float_64(int64_t power, uint64_t i, bool neg
mantissa &= ~(1ULL << 52);
// we have to check that real_exponent is in range, otherwise we bail out
if (simdjson_unlikely(real_exponent > 2046)) {
// We have an infinte value!!! We could actually throw an error here if we could.
// We have an infinite value!!! We could actually throw an error here if we could.
return false;
}
d = to_double(mantissa, real_exponent, negative);
@ -440,7 +440,7 @@ simdjson_really_inline error_code write_float(const uint8_t *const src, bool neg
// we could extend our code by using a 128-bit integer instead
// of a 64-bit integer. However, this is uncommon in practice.
//
// 9999999999999999999 < 2**64 so we can accomodate 19 digits.
// 9999999999999999999 < 2**64 so we can accommodate 19 digits.
// If we have a decimal separator, then digit_count - 1 is the number of digits, but we
// may not have a decimal separator!
if (simdjson_unlikely(digit_count > 19 && significant_digits(start_digits, digit_count) > 19)) {

View File

@ -75,7 +75,7 @@ public:
* long strings.
*
* If target is a compile-time constant, and your compiler likes you,
* you should be able to do the following without performance penatly...
* you should be able to do the following without performance penalty...
*
* static_assert(raw_json_string::is_free_from_unescaped_quote(target), "");
* s.unsafe_is_equal(target);
@ -89,7 +89,7 @@ public:
* the caller is responsible for this check. See is_free_from_unescaped_quote.
*
* If target is a compile-time constant, and your compiler likes you,
* you should be able to do the following without performance penatly...
* you should be able to do the following without performance penalty...
*
* static_assert(raw_json_string::is_free_from_unescaped_quote(target), "");
* s.unsafe_is_equal(target);

View File

@ -16,7 +16,7 @@ public:
inline simdjson::error_code append(value element) noexcept;
/** Append an array to the builder (to be printed) **/
inline simdjson::error_code append(array value) noexcept;
/** Append an objet to the builder (to be printed) **/
/** Append an object to the builder (to be printed) **/
inline simdjson::error_code append(object value) noexcept;
/** Append a field to the builder (to be printed) **/
inline simdjson::error_code append(field value) noexcept;
@ -134,7 +134,7 @@ inline std::ostream& operator<<(std::ostream& out, document& value) {
* Print JSON to an output stream.
*
* @param out The output stream.
* @param value The objet.
* @param value The object.
* @throw if there is an error with the underlying output stream. simdjson itself will not throw.
*/
#if SIMDJSON_EXCEPTIONS

View File

@ -687,7 +687,7 @@ namespace dom_api_tests {
return false;
}
if (!iter.down()) {
printf("Root should not be emtpy\n");
printf("Root should not be empty\n");
return false;
}
if (!iter.is_string()) {
@ -708,7 +708,7 @@ namespace dom_api_tests {
return false;
}
if(!iter.down()) {
printf("Image key should not be emtpy\n");
printf("Image key should not be empty\n");
return false;
}
if(!iter.next()) {

View File

@ -58,7 +58,7 @@ bool validate(const char *dirname) {
bool everything_fine = true;
const char *extension1 = ".ndjson";
const char *extension2 = ".jsonl";
const char *extension3 = ".json"; // bad json files shoud fail
const char *extension3 = ".json"; // bad json files should fail
size_t dirlen = std::strlen(dirname);
struct dirent **entry_list;

View File

@ -1,5 +1,5 @@
if(TARGET cxxopts) # we only build the tools if cxxopts is available
message(STATUS "We have cxxopts as a dependency and we are buiding the tools (e.g., json2json).")
message(STATUS "We have cxxopts as a dependency and we are building the tools (e.g., json2json).")
foreach(tool IN ITEMS json2json jsonstats jsonpointer minify)
add_executable("${tool}" "${tool}.cpp")
simdjson_apply_props("${tool}")