diff --git a/docs/start/faq.md b/docs/start/faq.md new file mode 100644 index 00000000..ca41ca97 --- /dev/null +++ b/docs/start/faq.md @@ -0,0 +1,38 @@ +--- +sidebar_position: 4 +--- + +# Frequently Asked Questions + +This FAQ page is designed to address the most common technical questions about WasmEdge. If your question is not directly answered here, please refer to the WasmEdge [documentation](https://wasmedge.org/docs/) or engage with the WasmEdge community via discord. + +## 1. How does WasmEdge handle memory sharing between modules? + +WasmEdge follows the WebAssembly specification, which currently does not support shared memory between different modules. Each module has its own linear memory space. This is because WebAssembly modules are isolated and cannot directly access each other's memory 1. However, it is possible to manually copy data from one module to another using host functions + +## 2. Can WasmEdge support model training? + +As of now, WasmEdge supports [model inference](https://www.secondstate.io/articles/fast-llm-inference/). It uses the WASI-NN API to make predictions using pre-trained models. However, model training is not yet supported. It only allows for the execution of pre-trained models. + +## 3. What is the internal flow of WasmEdge? + +The WasmEdge runtime follows a general flow: parsing the Wasm file, validating the parsed Wasm file, compiling the validated Wasm file into native code, and then executing the compiled code. For more detailed information, please refer to the WasmEdge runtime [documentation](https://wasmedge.org/docs/). + +## 4. Why is my plugin crashing? + +If your plugin crashes, it might be due to several reasons. It could be related to incorrect use of the WasmEdge API, or the plugin may be incompatible with the WasmEdge version you're using. It's recommended to debug the plugin using a debugger tool to get more detailed error information. Also it you should check the [plug-in documentation](https://wasmedge.org/docs/contribute/plugin/test_plugin) + +## 5. How to create a VM to call `infer()` in a Wasm library? + +You can use the WASI-NN API to call the `infer()` function in a Wasm library. First, you need to prepare the model, inputs, and outputs. Then, you can call the `infer()` function with these parameters. + +## 6. Can WasmEdge support Tensorflow as its inference backend using WASI-NN? + +Yes, WasmEdge can use Tensorflow as its [inference](https://wasmedge.org/docs/embed/go/ai/) backend through the WASI-NN API. + +## 7. How to read a host file in WasmEdge runtime? + +WasmEdge provides the WASI (WebAssembly System Interface) API for interacting with the host system, including file operations. You can use the [WASI API](https://wasmedge.org/docs/embed/go/reference/0.11.x?_highlight=wasi&_highlight=api#preregistrations) to open and read files from the host system. + + +Please remember, this FAQ page is not exhaustive, and the WasmEdge community is always ready to help with any questions or issues you may have. Don't hesitate to reach out if you need assistance in our [Discord server](https://discord.gg/h4KDyB8XTt). diff --git a/docs/start/overview.md b/docs/start/overview.md index 6db1eb91..9b579231 100644 --- a/docs/start/overview.md +++ b/docs/start/overview.md @@ -17,6 +17,9 @@ We will cover the following content: - [Getting Started](/category/getting-started-with-wasmEdge) - Introduce the [WasmEdge Runtime](/category/what-is-wasmedge) - Usages of [Running WasmEdge](/category/running-with-wasmedge) +- [Frequently Asked Question](faq.md) +- [Style Guide](style_guide.md) for new contributors +- [Troubleshooting Guide](troubleshooting_guide.md) For advanced programming with WasmEdge, please refer to the guides for [developing WASM apps](../develop/overview.md), [Embedding WasmEdge in your apps](../embed/overview.md), or [contributing](../contribute/overview.md) to WasmEdge. diff --git a/docs/start/style_guide.md b/docs/start/style_guide.md new file mode 100644 index 00000000..2421380e --- /dev/null +++ b/docs/start/style_guide.md @@ -0,0 +1,62 @@ +# WasmEdge Style Guide + +- [Documentation Style Guide](#documentation-style-guide) + - [Language](#language) + - [Structure and Format](#structure-and-format) + - [Content](#content) + - [Other Considerations](#other-considerations) +- [Coding Style Guide](#coding-style-guide) + - [Code Formatting](#code-formatting) + - [Code Quality](#code-quality) + - [Testing](#testing) + - [Security](#security) + +## Documentation Style Guide + +### Language + +- Use clear, simple, and concise language. Avoid jargon and technical terms as much as possible. If they are unavoidable, provide clear definitions or explanations. +- Write in the active voice and use the second person ("you") to make the documentation more user-oriented. + +### Structure and Format + +- Structure content with descriptive headings and subheadings. +- Make content more readable and easier to follow with bullet points and numbered lists. +- Include code examples and technical references where necessary. They should be well-formatted and easy to understand. Use code blocks and syntax highlighting for code examples. + +### Content + +- Start with an introduction that provides an overview of the topic. +- Provide step-by-step instructions and include code examples where necessary. +- Include a section on troubleshooting to help users solve common problems they might encounter. + +### Other Considerations + +- Encourage contributions from the community. Include a section explaining how users can contribute to the project. +- Regularly review the content and make updates as necessary. +- Ensure that the documentation is accessible to everyone. It should be easy to read, understand, and navigate. + +## Coding Style Guide + +### Code Formatting + +- Use consistent indentation. For example, you can choose to use spaces over tabs and stick with it throughout the project. +- Use meaningful variable, function, and class names. They should clearly indicate what the variable contains, what the function does, etc. +- Comment your code. Explain what each section or line of code does, especially if it involves complex logic. + +### Code Quality + +- Keep your code DRY (Don't Repeat Yourself). If you find yourself writing the same code in multiple places, consider creating a function or class. +- Write small, single-purpose functions. Each function should do one thing and do it well. +- Handle errors properly. Don't leave empty catch blocks in your code. + +### Testing + +- Write tests for your code. This helps to catch bugs early and makes sure that the code is working as expected. +- Follow a testing methodology, like unit testing or integration testing. + +### Security + +- Avoid code that might lead to security vulnerabilities, such as SQL injection. +- Use secure functions and libraries. +- Follow the security best practices provided by the CNCF. diff --git a/docs/develop/getting-started/troubleshooting_guide.md b/docs/start/troubleshooting_guide.md similarity index 100% rename from docs/develop/getting-started/troubleshooting_guide.md rename to docs/start/troubleshooting_guide.md diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/start/faq.md b/i18n/zh/docusaurus-plugin-content-docs/current/start/faq.md new file mode 100644 index 00000000..ca41ca97 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/start/faq.md @@ -0,0 +1,38 @@ +--- +sidebar_position: 4 +--- + +# Frequently Asked Questions + +This FAQ page is designed to address the most common technical questions about WasmEdge. If your question is not directly answered here, please refer to the WasmEdge [documentation](https://wasmedge.org/docs/) or engage with the WasmEdge community via discord. + +## 1. How does WasmEdge handle memory sharing between modules? + +WasmEdge follows the WebAssembly specification, which currently does not support shared memory between different modules. Each module has its own linear memory space. This is because WebAssembly modules are isolated and cannot directly access each other's memory 1. However, it is possible to manually copy data from one module to another using host functions + +## 2. Can WasmEdge support model training? + +As of now, WasmEdge supports [model inference](https://www.secondstate.io/articles/fast-llm-inference/). It uses the WASI-NN API to make predictions using pre-trained models. However, model training is not yet supported. It only allows for the execution of pre-trained models. + +## 3. What is the internal flow of WasmEdge? + +The WasmEdge runtime follows a general flow: parsing the Wasm file, validating the parsed Wasm file, compiling the validated Wasm file into native code, and then executing the compiled code. For more detailed information, please refer to the WasmEdge runtime [documentation](https://wasmedge.org/docs/). + +## 4. Why is my plugin crashing? + +If your plugin crashes, it might be due to several reasons. It could be related to incorrect use of the WasmEdge API, or the plugin may be incompatible with the WasmEdge version you're using. It's recommended to debug the plugin using a debugger tool to get more detailed error information. Also it you should check the [plug-in documentation](https://wasmedge.org/docs/contribute/plugin/test_plugin) + +## 5. How to create a VM to call `infer()` in a Wasm library? + +You can use the WASI-NN API to call the `infer()` function in a Wasm library. First, you need to prepare the model, inputs, and outputs. Then, you can call the `infer()` function with these parameters. + +## 6. Can WasmEdge support Tensorflow as its inference backend using WASI-NN? + +Yes, WasmEdge can use Tensorflow as its [inference](https://wasmedge.org/docs/embed/go/ai/) backend through the WASI-NN API. + +## 7. How to read a host file in WasmEdge runtime? + +WasmEdge provides the WASI (WebAssembly System Interface) API for interacting with the host system, including file operations. You can use the [WASI API](https://wasmedge.org/docs/embed/go/reference/0.11.x?_highlight=wasi&_highlight=api#preregistrations) to open and read files from the host system. + + +Please remember, this FAQ page is not exhaustive, and the WasmEdge community is always ready to help with any questions or issues you may have. Don't hesitate to reach out if you need assistance in our [Discord server](https://discord.gg/h4KDyB8XTt). diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/start/style_guide.md b/i18n/zh/docusaurus-plugin-content-docs/current/start/style_guide.md new file mode 100644 index 00000000..2421380e --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/start/style_guide.md @@ -0,0 +1,62 @@ +# WasmEdge Style Guide + +- [Documentation Style Guide](#documentation-style-guide) + - [Language](#language) + - [Structure and Format](#structure-and-format) + - [Content](#content) + - [Other Considerations](#other-considerations) +- [Coding Style Guide](#coding-style-guide) + - [Code Formatting](#code-formatting) + - [Code Quality](#code-quality) + - [Testing](#testing) + - [Security](#security) + +## Documentation Style Guide + +### Language + +- Use clear, simple, and concise language. Avoid jargon and technical terms as much as possible. If they are unavoidable, provide clear definitions or explanations. +- Write in the active voice and use the second person ("you") to make the documentation more user-oriented. + +### Structure and Format + +- Structure content with descriptive headings and subheadings. +- Make content more readable and easier to follow with bullet points and numbered lists. +- Include code examples and technical references where necessary. They should be well-formatted and easy to understand. Use code blocks and syntax highlighting for code examples. + +### Content + +- Start with an introduction that provides an overview of the topic. +- Provide step-by-step instructions and include code examples where necessary. +- Include a section on troubleshooting to help users solve common problems they might encounter. + +### Other Considerations + +- Encourage contributions from the community. Include a section explaining how users can contribute to the project. +- Regularly review the content and make updates as necessary. +- Ensure that the documentation is accessible to everyone. It should be easy to read, understand, and navigate. + +## Coding Style Guide + +### Code Formatting + +- Use consistent indentation. For example, you can choose to use spaces over tabs and stick with it throughout the project. +- Use meaningful variable, function, and class names. They should clearly indicate what the variable contains, what the function does, etc. +- Comment your code. Explain what each section or line of code does, especially if it involves complex logic. + +### Code Quality + +- Keep your code DRY (Don't Repeat Yourself). If you find yourself writing the same code in multiple places, consider creating a function or class. +- Write small, single-purpose functions. Each function should do one thing and do it well. +- Handle errors properly. Don't leave empty catch blocks in your code. + +### Testing + +- Write tests for your code. This helps to catch bugs early and makes sure that the code is working as expected. +- Follow a testing methodology, like unit testing or integration testing. + +### Security + +- Avoid code that might lead to security vulnerabilities, such as SQL injection. +- Use secure functions and libraries. +- Follow the security best practices provided by the CNCF. diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/develop/getting-started/troubleshooting_guide.md b/i18n/zh/docusaurus-plugin-content-docs/current/start/troubleshooting_guide.md similarity index 100% rename from i18n/zh/docusaurus-plugin-content-docs/current/develop/getting-started/troubleshooting_guide.md rename to i18n/zh/docusaurus-plugin-content-docs/current/start/troubleshooting_guide.md