Update the webpage (#4813)
JerryScript-DCO-1.0-Signed-off-by: Zsolt Borbély zsborbely.u-szeged@partner.samsung.com
This commit is contained in:
Zsolt Borbély
+1
-1
@@ -11,7 +11,7 @@ permalink: /configuration/
|
||||
# Configuration
|
||||
|
||||
JerryScript provides a large number of configuration options which can be used to enable or disable specific features, allowing users to fine tune the engine to best suit their needs.
|
||||
A configuration option's value can be changed either by providing specific C preprocessor definitions, by adding CMake defininitions, or by using the arguments of the `tools/build.py` script.
|
||||
A configuration option's value can be changed either by providing specific C preprocessor definitions, by adding CMake definitions, or by using the arguments of the `tools/build.py` script.
|
||||
This document lists the available configuration options, shows the configuration name for C, CMake, and python, and provides a brief description that explains the effect of the options.
|
||||
|
||||
|
||||
|
||||
+1906
-463
File diff suppressed because it is too large
Load Diff
+2
-2
@@ -88,7 +88,7 @@ Argument combinations are limited to the following seven forms:
|
||||
## Literals
|
||||
|
||||
Literals are organized into groups whose represent various literal types. Having these groups consuming less space than assigning flag bits to each literal.
|
||||
(In the followings, the mentioned ranges represent those indicies which are greater than or equal to the left side and less than the right side of the range. For example a range between `ident_end` and `literal_end` fields of the byte-code header contains those indicies, which are greater than or equal to `ident_end`
|
||||
(In the followings, the mentioned ranges represent those indices which are greater than or equal to the left side and less than the right side of the range. For example a range between `ident_end` and `literal_end` fields of the byte-code header contains those indices, which are greater than or equal to `ident_end`
|
||||
and less than `literal_end`. If `ident_end` equals to `literal_end` the range is empty.)
|
||||
|
||||
The two major group of literals are _identifiers_ and _values_.
|
||||
@@ -277,7 +277,7 @@ An object can be a conventional data object or a lexical environment object. Unl
|
||||
|
||||
[Lexical environments](http://www.ecma-international.org/ecma-262/5.1/#sec-10.2) are implemented as objects in JerryScript, since lexical environments contains key-value pairs (called bindings) like objects. This simplifies the implementation and reduces code size.
|
||||
|
||||
{: class="thumbnail center-block img-responsive" }
|
||||
{: class="thumbnail center-block img-responsive" }
|
||||
|
||||
The objects are represented as following structure:
|
||||
|
||||
|
||||
+3
-3
@@ -82,8 +82,8 @@ typedef enum
|
||||
void jerry_port_log (jerry_log_level_t level, const char *fmt, ...);
|
||||
```
|
||||
|
||||
The `jerry_port_print_char` is currenlty not used by the jerry-core directly.
|
||||
However, it provides a port specifc way for `jerry-ext` components to print
|
||||
The `jerry_port_print_char` is currently not used by the jerry-core directly.
|
||||
However, it provides a port specific way for `jerry-ext` components to print
|
||||
information.
|
||||
|
||||
```c
|
||||
@@ -294,7 +294,7 @@ void
|
||||
jerry_port_print_char (char c)
|
||||
{
|
||||
putchar (c);
|
||||
} /* jerr_port_print_char */
|
||||
} /* jerry_port_print_char */
|
||||
```
|
||||
|
||||
## Date
|
||||
|
||||
+2
-2
@@ -326,12 +326,12 @@ wait_for_source_callback (const jerry_char_t *resource_name_p, /**< resource nam
|
||||
|
||||
jerry_parse_options_t parse_options;
|
||||
parse_options.options = JERRY_PARSE_HAS_RESOURCE;
|
||||
parse_options.resource_name_p = resource_name_p;
|
||||
parse_options.resource_name_length = resource_name_size;
|
||||
parse_options.resource_name = jerry_create_string ((const jerry_char_t *) resource_name_p);
|
||||
|
||||
jerry_value_t ret_val = jerry_parse (source_p,
|
||||
source_size,
|
||||
&parse_options);
|
||||
jerry_release_value (parse_options.resource_name);
|
||||
|
||||
if (!jerry_value_is_error (ret_val))
|
||||
{
|
||||
|
||||
@@ -56,7 +56,7 @@ is doing.
|
||||
|
||||
/* not a complete sentence */
|
||||
|
||||
/* A bad mulitiline
|
||||
/* A bad multiline
|
||||
comment. */
|
||||
```
|
||||
|
||||
@@ -379,7 +379,7 @@ a = 6;
|
||||
|
||||
b = 7;
|
||||
|
||||
/* No newlines are allowed between control staments
|
||||
/* No newlines are allowed between control statements
|
||||
* and their code blocks. */
|
||||
|
||||
if (a > 6)
|
||||
@@ -429,7 +429,7 @@ a=b+c;
|
||||
a = b+c;
|
||||
a += c + ( d );
|
||||
/* Introduce temporary variables or macros
|
||||
* if the expression is too long. Occures rarely.. */
|
||||
* if the expression is too long. Occurs rarely.. */
|
||||
a = b
|
||||
+ c;
|
||||
if ( a + b > 0 )
|
||||
|
||||
@@ -151,7 +151,7 @@ jerryx_has_property_str (const jerry_value_t target_object,
|
||||
- `target_object` - object on which the property name is accessed
|
||||
- `name` - property name as an UTF-8 `char*`
|
||||
- return value
|
||||
- true, if the given property name exsits on the object
|
||||
- true, if the given property name exists on the object
|
||||
- false, if there is no such property name or there was an error accessing the property
|
||||
|
||||
**Example**
|
||||
@@ -190,7 +190,7 @@ for this the following utility structures and methods are provided.
|
||||
Structure to define an array of properties with `name` and `value` fields which
|
||||
can be registered to a target object.
|
||||
|
||||
The engine must be initialied before specifying the `jerry_value_t` in the struct.
|
||||
The engine must be initialized before specifying the `jerry_value_t` in the struct.
|
||||
|
||||
|
||||
**Prototype**
|
||||
@@ -219,7 +219,7 @@ successfully registered methods.
|
||||
This must be passed for the [jerryx_release_property_entry](#jerryx_release_property_entry) method
|
||||
after the property registration.
|
||||
|
||||
If any error occured during the property registration the `result` field of the structure
|
||||
If any error occurred during the property registration the `result` field of the structure
|
||||
must be manually released after processing the error value.
|
||||
|
||||
**Prototype**
|
||||
@@ -403,7 +403,7 @@ Release all `jerry_value_t` in a `jerryx_property_entry` array based on a previo
|
||||
and also the error value (if any) in the `jerryx_register_result` structure.
|
||||
In case of a successful registration it is safe to call this method.
|
||||
|
||||
After the method call the `ęntries` array should not be used as all values are released.
|
||||
After the method call the `entries` array should not be used as all values are released.
|
||||
|
||||
**Prototype**
|
||||
|
||||
@@ -413,7 +413,7 @@ jerryx_release_property_entry (const jerryx_property_entry entries[],
|
||||
const jerryx_register_result register_result);
|
||||
```
|
||||
|
||||
- `entires` - array of [jerryx_property_entry](#jerryx_property_entry).
|
||||
- `entries` - array of [jerryx_property_entry](#jerryx_property_entry).
|
||||
- `register_result` - result of a previous [jerryx_set_properties](#jerryx_set_properties) call.
|
||||
|
||||
**Example**
|
||||
@@ -523,7 +523,7 @@ jerryx_handler_gc (const jerry_value_t func_obj_val, const jerry_value_t this_p,
|
||||
|
||||
Provide a `print` implementation for scripts. The routine converts all of its
|
||||
arguments to strings and outputs them char-by-char using
|
||||
`jerry_port_print_char`. The NUL character is output as "\u0000",
|
||||
`jerry_port_print_char`. The NULL character is output as "\u0000",
|
||||
other characters are output bytewise.
|
||||
|
||||
*Note*: This implementation does not use standard C `printf` to print its
|
||||
|
||||
@@ -267,7 +267,7 @@ symbols so that they may be called explicitly from within the application.
|
||||
#define JERRYX_NATIVE_MODULE(module_name, on_resolve_cb)
|
||||
```
|
||||
|
||||
- `module_name` - the name of the module without quotes. This value is used as the prefix for the registration and unregistration funtions. For example, when `module_name` is `example_module`, this results in the declaration of two functions `example_module_register()` and `example_module_unregister()`. These functions are declared global if support for library constructors/destructors is absent, allowing you to call them from other parts of the code by
|
||||
- `module_name` - the name of the module without quotes. This value is used as the prefix for the registration and unregistration functions. For example, when `module_name` is `example_module`, this results in the declaration of two functions `example_module_register()` and `example_module_unregister()`. These functions are declared global if support for library constructors/destructors is absent, allowing you to call them from other parts of the code by
|
||||
first forward-declaring them.
|
||||
- `on_resolve_cb` - the function of type `jerryx_native_module_on_resolve_t` that will be called when the module needs to be
|
||||
loaded.
|
||||
|
||||
@@ -110,7 +110,7 @@ typedef bool (*jerry_debugger_transport_receive_t) (struct jerry_debugger_transp
|
||||
|
||||
**Summary**
|
||||
|
||||
Add a new interface to the transporation interface chain. The interface
|
||||
Add a new interface to the transportation interface chain. The interface
|
||||
will be the first item of the interface chain.
|
||||
|
||||
**Prototype**
|
||||
@@ -121,7 +121,7 @@ void jerry_debugger_transport_add (jerry_debugger_transport_header_t *header_p,
|
||||
size_t receive_message_header_size, size_t max_receive_message_size);
|
||||
```
|
||||
|
||||
- `header_p`: header of a transporation interface.
|
||||
- `header_p`: header of a transportation interface.
|
||||
- `send_message_header_size`: size of the outgoing message header, can be 0.
|
||||
- `max_send_message_size`: maximum outgoing message size supported by the interface.
|
||||
- `receive_message_header_size`: size of the incoming message header, can be 0.
|
||||
|
||||
+3
-3
@@ -17,7 +17,7 @@ Embedders wishing to use native builtin modules with ES6 imports can use the [Po
|
||||
## General
|
||||
|
||||
If a script contains import statements, then JerryScript will open and evaluate the the referenced modules before the main script runs, resolving and creating bindings for the referenced identifiers in the process.
|
||||
It is not necessary to use any specific filename extensions for modules, JerryScript will try to open the given file paths as they are, but will try to normalize them before doing so. The exact normalization process is dependant on the port implementation provided. It is the user's responsibility to verify that the given files are valid EcmaScript modules.
|
||||
It is not necessary to use any specific filename extensions for modules, JerryScript will try to open the given file paths as they are, but will try to normalize them before doing so. The exact normalization process is dependant on the port implementation provided. It is the user's responsibility to verify that the given files are valid ECMAScript modules.
|
||||
|
||||
main.js
|
||||
|
||||
@@ -86,7 +86,7 @@ export var version = "1.0 (e92ae0fb)";
|
||||
|
||||
```js
|
||||
// module_2.js
|
||||
var featureName = "EcmaScript modules";
|
||||
var featureName = "ECMAScript modules";
|
||||
var year = 2018;
|
||||
|
||||
export function getFeatureDetails() {
|
||||
@@ -96,7 +96,7 @@ export function getFeatureDetails() {
|
||||
|
||||
### Module namespace import statements
|
||||
|
||||
A module namespace object can be imported. In this case the local binding will contain an object holding the exported values of the module, including local exports and all indirect exports. Ambiguous exported names are exluded from the namespace object.
|
||||
A module namespace object can be imported. In this case the local binding will contain an object holding the exported values of the module, including local exports and all indirect exports. Ambiguous exported names are excluded from the namespace object.
|
||||
|
||||
```js
|
||||
import * as module from './module.js';
|
||||
|
||||
@@ -11,11 +11,11 @@ permalink: /migration-guide/
|
||||
# Migration guide
|
||||
|
||||
This guide intends to describe the major changes between the JerryScript 1.0 and 2.0 versions.
|
||||
In addtion it is designed to provide a guide on how to modify the 1.0 version code to a
|
||||
In addition it is designed to provide a guide on how to modify the 1.0 version code to a
|
||||
2.0 compliant code.
|
||||
|
||||
During the development it was important to minimize the changes in the API functions and types.
|
||||
Each API method removal or chang is described below providing a ***before*** and ***after***
|
||||
Each API method removal or change is described below providing a ***before*** and ***after***
|
||||
code example.
|
||||
For more information on the current API methods please check the [API reference](02.API-REFERENCE.md) document.
|
||||
|
||||
@@ -63,7 +63,7 @@ For more information on the current API methods please check the [API reference]
|
||||
|
||||
## Error manipulating functions
|
||||
|
||||
The most important changes in the API are releated to error handling and manipulation.
|
||||
The most important changes in the API are related to error handling and manipulation.
|
||||
|
||||
### jerry_value_set_abort_flag
|
||||
|
||||
|
||||
Reference in New Issue
Block a user