koffi 0.9.4 → 0.9.5

package/vendor/node-addon-api/doc/maybe.md

@@ -1,76 +1,76 @@
-# Maybe (template)
-
-Class `Napi::Maybe<T>` represents a value that may be empty: every `Maybe` is
-either `Just` and contains a value, or `Nothing`, and does not. `Maybe` types
-are very common in node-addon-api code, as they represent that the function may
-throw a JavaScript exception and cause the program to be unable to evaluate any
-JavaScript code until the exception has been handled.
-
-Typically, the value wrapped in `Napi::Maybe<T>` is [`Napi::Value`] and its
-subclasses.
-
-## Methods
-
-### IsNothing
-
-```cpp
-template <typename T>
-bool Napi::Maybe::IsNothing() const;
-```
-
-Returns `true` if the `Maybe` is `Nothing` and does not contain a value, and
-`false` otherwise.
-
-### IsJust
-
-```cpp
-template <typename T>
-bool Napi::Maybe::IsJust() const;
-```
-
-Returns `true` if the `Maybe` is `Just` and contains a value, and `false`
-otherwise.
-
-### Check
-
-```cpp
-template <typename T>
-void Napi::Maybe::Check() const;
-```
-
-Short-hand for `Maybe::Unwrap()`, which doesn't return a value. Could be used
-where the actual value of the Maybe is not needed like `Object::Set`.
-If this Maybe is nothing (empty), node-addon-api will crash the
-process.
-
-### Unwrap
-
-```cpp
-template <typename T>
-T Napi::Maybe::Unwrap() const;
-```
-
-Return the value of type `T` contained in the Maybe. If this Maybe is
-nothing (empty), node-addon-api will crash the process.
-
-### UnwrapOr
-
-```cpp
-template <typename T>
-T Napi::Maybe::UnwrapOr(const T& default_value) const;
-```
-
-Return the value of type T contained in the Maybe, or use a default
-value if this Maybe is nothing (empty).
-
-### UnwrapTo
-
-```cpp
-template <typename T>
-bool Napi::Maybe::UnwrapTo(T* result) const;
-```
-
-Converts this Maybe to a value of type `T` in the `out`. If this Maybe is
-nothing (empty), `false` is returned and `out` is left untouched.
-
-[`Napi::Value`]: ./value.md
+# Maybe (template)
+
+Class `Napi::Maybe<T>` represents a value that may be empty: every `Maybe` is
+either `Just` and contains a value, or `Nothing`, and does not. `Maybe` types
+are very common in node-addon-api code, as they represent that the function may
+throw a JavaScript exception and cause the program to be unable to evaluate any
+JavaScript code until the exception has been handled.
+
+Typically, the value wrapped in `Napi::Maybe<T>` is [`Napi::Value`] and its
+subclasses.
+
+## Methods
+
+### IsNothing
+
+```cpp
+template <typename T>
+bool Napi::Maybe::IsNothing() const;
+```
+
+Returns `true` if the `Maybe` is `Nothing` and does not contain a value, and
+`false` otherwise.
+
+### IsJust
+
+```cpp
+template <typename T>
+bool Napi::Maybe::IsJust() const;
+```
+
+Returns `true` if the `Maybe` is `Just` and contains a value, and `false`
+otherwise.
+
+### Check
+
+```cpp
+template <typename T>
+void Napi::Maybe::Check() const;
+```
+
+Short-hand for `Maybe::Unwrap()`, which doesn't return a value. Could be used
+where the actual value of the Maybe is not needed like `Object::Set`.
+If this Maybe is nothing (empty), node-addon-api will crash the
+process.
+
+### Unwrap
+
+```cpp
+template <typename T>
+T Napi::Maybe::Unwrap() const;
+```
+
+Return the value of type `T` contained in the Maybe. If this Maybe is
+nothing (empty), node-addon-api will crash the process.
+
+### UnwrapOr
+
+```cpp
+template <typename T>
+T Napi::Maybe::UnwrapOr(const T& default_value) const;
+```
+
+Return the value of type T contained in the Maybe, or use a default
+value if this Maybe is nothing (empty).
+
+### UnwrapTo
+
+```cpp
+template <typename T>
+bool Napi::Maybe::UnwrapTo(T* result) const;
+```
+
+Converts this Maybe to a value of type `T` in the `out`. If this Maybe is
+nothing (empty), `false` is returned and `out` is left untouched.
+
+[`Napi::Value`]: ./value.md

package/vendor/node-addon-api/doc/memory_management.md

@@ -1,27 +1,27 @@
-# MemoryManagement
-
-The `Napi::MemoryManagement` class contains functions that give the JavaScript engine
-an indication of the amount of externally allocated memory that is kept alive by
-JavaScript objects.
-
-## Methods
-
-### AdjustExternalMemory
-
-The function `AdjustExternalMemory` adjusts the amount of registered external
-memory used to give the JavaScript engine an indication of the amount of externally
-allocated memory that is kept alive by JavaScript objects.
-The JavaScript engine uses this to decide when to perform global garbage collections.
-Registering externally allocated memory will trigger global garbage collections
-more often than it would otherwise in an attempt to garbage collect the JavaScript
-objects that keep the externally allocated memory alive.
-
-```cpp
-static int64_t Napi::MemoryManagement::AdjustExternalMemory(Napi::Env env, int64_t change_in_bytes);
-```
-
-- `[in] env`: The environment in which the API is invoked under.
-- `[in] change_in_bytes`: The change in externally allocated memory that is kept
-alive by JavaScript objects expressed in bytes.
-
-Returns the adjusted memory value.
+# MemoryManagement
+
+The `Napi::MemoryManagement` class contains functions that give the JavaScript engine
+an indication of the amount of externally allocated memory that is kept alive by
+JavaScript objects.
+
+## Methods
+
+### AdjustExternalMemory
+
+The function `AdjustExternalMemory` adjusts the amount of registered external
+memory used to give the JavaScript engine an indication of the amount of externally
+allocated memory that is kept alive by JavaScript objects.
+The JavaScript engine uses this to decide when to perform global garbage collections.
+Registering externally allocated memory will trigger global garbage collections
+more often than it would otherwise in an attempt to garbage collect the JavaScript
+objects that keep the externally allocated memory alive.
+
+```cpp
+static int64_t Napi::MemoryManagement::AdjustExternalMemory(Napi::Env env, int64_t change_in_bytes);
+```
+
+- `[in] env`: The environment in which the API is invoked under.
+- `[in] change_in_bytes`: The change in externally allocated memory that is kept
+alive by JavaScript objects expressed in bytes.
+
+Returns the adjusted memory value.

package/vendor/node-addon-api/doc/name.md

@@ -1,29 +1,29 @@
-# Name
-
-Class `Napi::Name` inherits from class [`Napi::Value`][].
-
-Names are JavaScript values that can be used as a property name. There are two
-specialized types of names supported in Node.js Addon API [`Napi::String`](string.md)
-and [`Napi::Symbol`](symbol.md).
-
-## Methods
-
-### Constructor
-```cpp
-Napi::Name::Name();
-```
-
-Returns an empty `Napi::Name`.
-
-```cpp
-Napi::Name::Name(napi_env env, napi_value value);
-```
-- `[in] env` - The environment in which to create the array.
-- `[in] value` - The primitive to wrap.
-
-Returns a `Napi::Name` created from the JavaScript primitive.
-
-Note:
-The value is not coerced to a string.
-
-[`Napi::Value`]: ./value.md
+# Name
+
+Class `Napi::Name` inherits from class [`Napi::Value`][].
+
+Names are JavaScript values that can be used as a property name. There are two
+specialized types of names supported in Node.js Addon API [`Napi::String`](string.md)
+and [`Napi::Symbol`](symbol.md).
+
+## Methods
+
+### Constructor
+```cpp
+Napi::Name::Name();
+```
+
+Returns an empty `Napi::Name`.
+
+```cpp
+Napi::Name::Name(napi_env env, napi_value value);
+```
+- `[in] env` - The environment in which to create the array.
+- `[in] value` - The primitive to wrap.
+
+Returns a `Napi::Name` created from the JavaScript primitive.
+
+Note:
+The value is not coerced to a string.
+
+[`Napi::Value`]: ./value.md

package/vendor/node-addon-api/doc/node-gyp.md

@@ -1,82 +1,82 @@
-# node-gyp
-
-C++ code needs to be compiled into executable form whether it be as an object
-file to linked with others, a shared library, or a standalone executable.
-
-The main reason for this is that we need to link to the Node.js dependencies and
-headers correctly, another reason is that we need a cross platform way to build
-C++ source into binary for the target platform.
-
-Until now **node-gyp** is the **de-facto** standard build tool for writing
-Node.js addons. It's based on Google's **gyp** build tool, which abstract away
-many of the tedious issues related to cross platform building.
-
-**node-gyp** uses a file called ```binding.gyp``` that is located on the root of
-your addon project.
-
-```binding.gyp``` file, contains all building configurations organized with a
-JSON like syntax. The most important parameter is the  **target** that must be
-set to the same value used on the initialization code of the addon as in the
-examples reported below:
-
-### **binding.gyp**
-
-```gyp
-{
-  "targets": [
-    {
-      # myModule is the name of your native addon
-      "target_name": "myModule",
-      "sources": ["src/my_module.cc", ...],
-      ...
-  ]
-}
-```
-
-### **my_module.cc**
-
-```cpp
-#include <napi.h>
-
-// ...
-
-/**
-* This code is our entry-point. We receive two arguments here, the first is the
-* environment that represent an independent instance of the JavaScript runtime,
-* the second is exports, the same as module.exports in a .js file.
-* You can either add properties to the exports object passed in or create your
-* own exports object. In either case you must return the object to be used as
-* the exports for the module when you return from the Init function.
-*/
-Napi::Object Init(Napi::Env env, Napi::Object exports) {
-
-  // ...
-
-  return exports;
-}
-
-/**
-* This code defines the entry-point for the Node addon, it tells Node where to go
-* once the library has been loaded into active memory. The first argument must
-* match the "target" in our *binding.gyp*. Using NODE_GYP_MODULE_NAME ensures
-* that the argument will be correct, as long as the module is built with
-* node-gyp (which is the usual way of building modules). The second argument
-* points to the function to invoke. The function must not be namespaced.
-*/
-NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)
-```
-
-## **node-gyp** reference
-
-  - [Installation](https://www.npmjs.com/package/node-gyp#installation)
-  - [How to use](https://www.npmjs.com/package/node-gyp#how-to-use)
-  - [The binding.gyp file](https://www.npmjs.com/package/node-gyp#the-bindinggyp-file)
-  - [Commands](https://www.npmjs.com/package/node-gyp#commands)
-  - [Command options](https://www.npmjs.com/package/node-gyp#command-options)
-  - [Configuration](https://www.npmjs.com/package/node-gyp#configuration)
-
-Sometimes finding the right settings for ```binding.gyp``` is not easy so to
-accomplish at most complicated task please refer to:
-
-- [GYP documentation](https://gyp.gsrc.io/index.md)
-- [node-gyp wiki](https://github.com/nodejs/node-gyp/wiki)
+# node-gyp
+
+C++ code needs to be compiled into executable form whether it be as an object
+file to linked with others, a shared library, or a standalone executable.
+
+The main reason for this is that we need to link to the Node.js dependencies and
+headers correctly, another reason is that we need a cross platform way to build
+C++ source into binary for the target platform.
+
+Until now **node-gyp** is the **de-facto** standard build tool for writing
+Node.js addons. It's based on Google's **gyp** build tool, which abstract away
+many of the tedious issues related to cross platform building.
+
+**node-gyp** uses a file called ```binding.gyp``` that is located on the root of
+your addon project.
+
+```binding.gyp``` file, contains all building configurations organized with a
+JSON like syntax. The most important parameter is the  **target** that must be
+set to the same value used on the initialization code of the addon as in the
+examples reported below:
+
+### **binding.gyp**
+
+```gyp
+{
+  "targets": [
+    {
+      # myModule is the name of your native addon
+      "target_name": "myModule",
+      "sources": ["src/my_module.cc", ...],
+      ...
+  ]
+}
+```
+
+### **my_module.cc**
+
+```cpp
+#include <napi.h>
+
+// ...
+
+/**
+* This code is our entry-point. We receive two arguments here, the first is the
+* environment that represent an independent instance of the JavaScript runtime,
+* the second is exports, the same as module.exports in a .js file.
+* You can either add properties to the exports object passed in or create your
+* own exports object. In either case you must return the object to be used as
+* the exports for the module when you return from the Init function.
+*/
+Napi::Object Init(Napi::Env env, Napi::Object exports) {
+
+  // ...
+
+  return exports;
+}
+
+/**
+* This code defines the entry-point for the Node addon, it tells Node where to go
+* once the library has been loaded into active memory. The first argument must
+* match the "target" in our *binding.gyp*. Using NODE_GYP_MODULE_NAME ensures
+* that the argument will be correct, as long as the module is built with
+* node-gyp (which is the usual way of building modules). The second argument
+* points to the function to invoke. The function must not be namespaced.
+*/
+NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)
+```
+
+## **node-gyp** reference
+
+  - [Installation](https://www.npmjs.com/package/node-gyp#installation)
+  - [How to use](https://www.npmjs.com/package/node-gyp#how-to-use)
+  - [The binding.gyp file](https://www.npmjs.com/package/node-gyp#the-bindinggyp-file)
+  - [Commands](https://www.npmjs.com/package/node-gyp#commands)
+  - [Command options](https://www.npmjs.com/package/node-gyp#command-options)
+  - [Configuration](https://www.npmjs.com/package/node-gyp#configuration)
+
+Sometimes finding the right settings for ```binding.gyp``` is not easy so to
+accomplish at most complicated task please refer to:
+
+- [GYP documentation](https://gyp.gsrc.io/index.md)
+- [node-gyp wiki](https://github.com/nodejs/node-gyp/wiki)