https://github.com/WasmEdge/WasmEdge summary

The central problem discussed in the issue is enabling WasmEdge compilation with the MSVC toolchain. The main solutions proposed include modifying code to be compatible with MSVC, addressing compiler-specific issues, replacing GCC-specific intrinsics with MSVC alternatives, and adding conditional code paths for MSVC.

The central problem discussed in the issue is that a backward incompatible change has been made in the WasmEdge installer, breaking the installation for shells other than bash and zsh. The issue was reported by user 'zifeo' and they expect a successful installation on the Fish shell.
The main solutions proposed or agreed upon are not mentioned in the given information, so it is unclear what potential solutions have been suggested by other users or agreed upon by the developers.

The central problem discussed in the issue is that Wasmedge, when handling a non-WASI wasm binary, is slower compared to other runtimes like wasmtime and wasmer. The user provided a wasm binary and commands used. No specific solutions were proposed or agreed upon in the issue.

The central problem discussed in the issue is that users in China, due to regional constraints, are unable to access GitHub and need an option to use the Gitee link instead. The issue also highlights potential problems with syncing GitHub and Gitee repositories, lack of error handling if Gitee fails, unexpected behavior for non-Chinese users, and logical errors in variable assignment.
The main solutions proposed include adding a wrapper option to use the Gitee link during installation, updating the uninstaller script to work with the Gitee option, and making necessary adjustments to accommodate Homebrew in the CI workflows.
In summary, the issue focuses

The central problem discussed in the issue is an abortion report on the instruction memory.grow. The user expects no exception to be thrown, but they are encountering an abortion. The issue occurs on Ubuntu 20.04 with hardware architecture amd64. The user has provided a zip file with steps to reproduce the issue. Another user has commented that they cannot reproduce the issue on their testing platform. The main solutions proposed are not mentioned in the issue content.

The central problem discussed in the issue is a crash caused by the instruction table.init in a specific codebase. The user expects an exception indicating "OOB" instead of a segmentation fault. The main solution proposed is for an internal handler to catch this error and prevent the segmentation fault.

The central problem discussed in the issue is a crash report related to the instruction memory.init in the WasmEdge project. The user expects an exception indicating "OOB" (Out of Bounds) to be raised instead of a segmentation fault. One potential solution proposed by user '.hydai' is to catch this issue with an internal handler instead of triggering a segmentation fault.

The central problem discussed in the issue is the addition of the load_by_name implementation into the wasi-nn plugin. The main solutions proposed include adding a new method to read in a pre-loaded model by its name, implementing a map of backend and device options, handling concurrency and thread safety, proper error handling, reviewing code complexity, and ensuring integration with other parts of the system. However, it is noted that unit tests are not included, making it difficult to verify the correctness of the new functionalities.

The central problem discussed in the issue is the lack of a universal plugin in the current release workflow for WASI-NN. The existing plugins are limited to specific backends like PyTorch, TensorflowLite, or OpenVINO. This limitation restricts users who require multiple backends.
The main solution proposed is to create a universal plugin that incorporates all available backends. This would provide users with a more flexible and comprehensive solution. The issue does not mention any agreed-upon solutions.
In summary, the issue addresses the need for a universal WASI-NN plugin in the release workflow to overcome the limitation of standalone plugins and suggests

The central problem discussed in the issue is that while executing a given testcase, WasmEdge hangs and does not terminate. Other wasm runtimes like Wasmer terminate abnormally or run normally without output. The expected result is unclear due to a lack of understanding of WebAssembly. The main solutions proposed are to investigate the issue with the AOT mode and confirm if there is a problem with its usage.

The central problem discussed in the issue is the restructuring of the documentation towards an external website, which raises concerns about reliability, version tracking, backup procedures, and quality control. The main solutions proposed or agreed upon include ensuring the reliability and accessibility of the new website, implementing a system for version tracking, retaining some documentation within the repository as a backup, and conducting manual validation of the new URL links.

The central problem discussed in the issue is that the results of executing a wasm binary in WasmEdge are different from other runtimes. Specifically, the issue is about the return value types of an exported function. The main solution proposed is to change the behavior of WasmEdge to return a signed integer instead of an unsigned one, following the convention of JavaScript. It is suggested to add an option called "--i32-as-signed" to control the return value types, while ensuring that existing conditions are not broken.

The central problem discussed in the issue is that although WasmEdge_ModuleInstanceGetHostData allows obtaining host data from within a module instance, the module instance in the parameters of the host function is not the one to which it belongs. The main solution proposed is to fix the issue, which is blocking the 'code-flows' project to support 'http_req_wasi 0.10'.

The central problem discussed in the issue is the introduction of coroutine functionality in the WasmEdge runtime. The main potential problems identified include the lack of error handling for misused coroutines, the absence of safeguards preventing destroyed coroutines from being invoked, the need to validate the new system against concurrency and memory leaks, and the importance of ensuring proper versioning and backward compatibility. No specific solutions were proposed in the issue.

In this GitHub issue, user 'hangedfish' reported that the build for the target 'wasmedgeHostModuleWasi' failed with the Xcode generator. The expected outcome was a successful build. The issue occurred on macOS 13 with an aarch64 architecture. The suggested solution was to add the flag '-Wno-shorten-64-to-32' to the target 'wasmedgeHostModuleWasi'. User '.hydai' identified the root cause as a type mismatch, where a 64-bit integer was being copied into a 32-bit integer, potentially causing truncation issues. They suggested adding a

User 'luxinyi0105' opened an issue titled 'Does not meet the witx spec while executing the given wasm file'. The issue discusses a bug where WasmEdge may not be compliant with the witx spec when executing a specific test case. The test case involves mutating a wasm file obtained by compiling a C program with Emscripten. The mutation changes a subtraction operation to a division operation, resulting in a misalignment of the stack. The witx spec states that misaligned pointers should trap, but WasmEdge does not return a trap in this situation. The main solution proposed is for WasmEdge to return

The central problem discussed in the GitHub issue is the need to create a Rust SDK for supporting applications on YOLO models. The issue highlights the requirement for implementing pre-processing and post-processing functions, supporting both image and video inputs, and providing examples and documentation.
The main solutions proposed or agreed upon are:

Building a Rust SDK that implements the necessary pre-processing and post-processing functions for YOLO models.
Porting Python functions to Rust for the required functionality.
Familiarizing oneself with the relevant technologies and resources like YOLO models, WASI-NN plugins, mediapipe-rs, and Open

Issue Title: feat: LFX create a ffmpeg plugin
User 'juntao' opened an issue regarding the slow performance of Wasm-compiled ffmpeg functions in the mediapipe-rs project. The proposed solution is to create a ffmpeg plugin for WasmEdge, enabling Wasm applications to call native ffmpeg functions as host functions. The expected outcome includes developing a WasmEdge plugin for ffmpeg, a Rust SDK for Wasm programs, and refactoring the mediapipe-rs project. The deliverable should cover at least 80% of ffmpeg functions, with complete unit tests and documentation coverage. The main skills required are C

Issue: 'feat: LFX Support AOT mode in proxy-wasm'
Problem: WasmEdge only supports interpreter mode in proxy-wasm, lacking AOT mode for better performance.
Solutions: Modify bazel file to include LLVM dependency, modify code to support AOT mode, add documentation in WasmEdge docs.
Potential Solution: Collaborate with LFX mentorship program applicant 'Sangam-ghimire' who has shown interest and completed pre-test tasks.

The central problem discussed in the issue is the need to build tests in a nix environment for the WasmEdge project. The suggested solution is to add an app called 'test' in the nix flake script and then invoke it using the command 'nix run wasmedge#test'. This would allow the user to run tests within the nix environment.

The central problem discussed in the issue is how to enable multiple backends in the WASI-NN plugin. The user is asking if it's possible to have multiple functions (PyTorch, TensorFlow Lite, OpenVINO) enabled at the same time and how to handle it.
The main solution proposed is to compile from the source with the option -DWASMEDGE_PLUGIN_WASI_NN_BACKEND="openvino;pytorch;tensorflowlite", which allows for multiple backends to be enabled in the plugin.
Additionally, the user asks if WASI-NN can support AI tasks other than image-related ones and requests related examples

The central problem discussed in the GitHub issue is that the WasmEdge package on Winget is not being updated after version 0.10.0. The main solutions proposed include figuring out how to submit/update packages on the Winget repository and submitting a pull request (PR) to provide the latest release. Other suggestions include updating the package for versions 0.11.2 and 0.12.1, signing the MSI package to avoid Windows Defender SmartScreen warnings, and automating the process with a GitHub action. However, there is uncertainty about the signing process, and it is suggested to use external dependencies and ignore the signing

The central problem discussed in the issue is that some functions in the WASI-Crypto implementation of WasmEdge are marked as NOT_IMPLEMENTED. The issue aims to track these functions and find a solution to implement them.
The main solutions proposed are to use the grep command to identify the unimplemented functions and to refer to the WASI-Crypto repository for the detailed specifications of these functions. The suggested solution is to implement these functions using the OpenSSL library.
Overall, the issue focuses on identifying the remaining functions to be implemented in the WASI-Crypto plugin and suggests using the OpenSSL library as a solution.

The central problem discussed in the issue is how to use GPU with wasi-nn-pytorch. The user is encountering errors when trying to run GPU-related testing examples. The main solutions proposed are to build WasmEdge from source because the PyTorch plugin in the current release is CPU-only, and to downgrade LLVM to version 16 to resolve build errors. Additionally, there is a question about converting a trained model to a pt file and the error message related to the output type in wasi-nn-pytorch.

The central problem discussed in the issue is the need for enabling Packit for Fedora and EPEL rpm builds to improve Fedora integration. The issue also addresses the broken state of wasmedge on Fedora rawhide. The main solutions proposed are:

Implementing Packit to automate RPM builds on active versions of Fedora and EPEL.
Syncing the downstream spec file with the upstream spec file through PRs for manual review and merge.
Resolving the issue on Fedora rawhide by releasing a newer version of WasmEdge.
Verifying the WasmEdge organization with Packit-as

The central problem discussed in the GitHub issue is the need to unify the read and write functions in the WASI module to address issues when using epoll. The current implementation causes epoll to be triggered endlessly.
The main solutions proposed include introducing a 'process' function that handles both read and write operations on file descriptors, refactoring code to avoid duplication, improving error handling and exception safety, conducting performance assessments, and adding proper test cases to ensure reliability and correctness.

Issue: Exec format error when using kubeedge to create a pod.
The user encountered an error message stating "Exec format error" when attempting to create a pod using kubeedge. The error occurred both when using kubectl and ctr commands. The user provided the command used and the error output. The user also mentioned that the annotations field may not be working.
Solutions proposed:

Request for the kubeedge settings and detailed steps to help diagnose the issue.
Suggestion to use the --platform wasi/wasm flag when creating the pod.
Uncertainty about whether the annotations are still available in kubeedge.

Potential Solutions

The central problem discussed in the issue is enabling WasmEdge compilation with the MSVC toolchain. The user encountered complex template errors and an issue with designated initializers. They also found that MSVC does not support the attribute [[gnu::vector_size(16)]]. The main solutions proposed are rewriting the incompatible parts of the code to work without designated initializers, and rewriting SIMD-related instructions with unrolling. The user made progress in solving compilation errors and test failures, and created a workflow for MSVC. The next steps include writing documentation and moving forward with code review to further improve the patch.

The central problem discussed in the issue is that when running AOT compiled wasm modules that depend on each other, there are out of bounds memory access errors. The issue occurs when one module calls a function in another module through host functions. The error only happens with AOT compilation, not with interpretation. The main solution proposed is to try using version 0.13.0 of Wasmedge, as it may have fixed the issue.

The central problem discussed in the issue is the serialization compilation in the Loader, which involves refactoring and improvement of serialization functionality. The main solutions proposed include rigorous code review, addressing unfinished tasks, handling data manipulation and hard-coded values in tests, and improving error handling and return statements.

The central problem discussed in the issue is that when running a specific command, the user encounters an error related to a missing library on macOS 14. The user suspects that the issue might be related to the installation, hardware, or the new operating system version. The main solution proposed is for the user to provide the golang source code used so that others can reproduce the environment and investigate further. Additionally, there is mention of waiting for macOS 14 to be released in order to further investigate the issue.

The central problem discussed in the issue is that the WasmEdge AOT loader implementation is not compliant with the security guidelines of the App Store and Play Store on iOS and Android platforms. The main proposed solution is to AOT compile Wasm bytecodes to native static libs and link them to WasmEdge's WASI runtime. Additionally, suggestions are made to use an LLVM framework for compiling Wasm code and to convert the WASM-AOT file into a suitable object file or use a linker script.

The central problem discussed in the issue is the need to enhance the memory manipulation capabilities of the C API in the WasmEdge program. The main solutions proposed include adding memory allocation and deallocation functions, implementing helper functions for internal memory operations, and introducing mutex locks for thread safety.

The central problem discussed in the GitHub issue is the lack of support for the TCP_NODELAY socket option in the WASI implementation. The main solutions proposed include adding the TCP_NODELAY option and IPPROTO_TCP option in the WASI enumerations, implementing conversions between system-level and WASI-level values for the TCP_NODELAY option, updating sockSetOpt function signatures and implementations for different platforms, and reordering include statements in header files.

The central problem discussed in the issue is that the Java bindings for WasmEdge are out of sync with the WasmEdge version. The user is seeking documentation to determine which version of WasmEdge is compatible with the Java bindings. The main solution proposed is to add documentation specifying the version compatibility between the Java bindings and WasmEdge.

The central problem discussed in the issue is the need to publish the Java bindings for WasmEdge to the Maven repository. The main solution proposed is to register WasmEdge with Sonatype, create PGP keys for signing, and add it to the pipelines for automatic publishing to Maven Central.

The central problem discussed in the issue is the removal of unnecessary documentation files and the reorganization of other docs in the WasmEdge project. The main solutions proposed are to provide justification for the removal of documentation files, ensure compatibility with existing projects, address potential broken links and dependencies, reconsider the reorganization of files to adhere to standard organization patterns, and clarify language support in the documentation.

The central problem discussed in the issue is the need to update the Ubuntu armv7l Dockerfile and modify the .github/workflows/docker.yml file. The proposed solutions include:

Updating the base image and package versions in the Dockerfile.
Removing unnecessary packages and CMake build from source.
Updating LLVM-related packages.
Restricting the triggering of GitHub Docker workflow to specific file changes.
Potential issues include:

The removal of packages that may affect cross-compilation support.
Compatibility issues if the project relies on a specific CMake version.
Compatibility issues if the project depends on LLVM

The central problem discussed in the issue is that the cxx11abi issue for the WASI-NN PyTorch plugin requires multiple assets to be released on different Linux distributions (manylinux2014 / Ubuntu 20.04), leading to confusion among users who may download and install the wrong versions from the release pages. The proposed solution is to use manylinux_2_28, the next generation of manylinux, to replace the Ubuntu 20.04 release workflow. The functionality of other plugins also needs to be verified.

The central problem discussed in the issue is that after a recent Podman update, annotations are no longer propagated when running container images. The proposed solution is to drop the 'module.wasm.image/variant=compat' annotation and use the '--platform wasi/wasm' flag instead. This change should be applied to all container examples and documents. The aim is to align the build and run processes with the same flags. Additionally, it is confirmed that the '--platform wasi/wasm' flag is also used when building Wasm images with Docker.

The central problem discussed in the GitHub issue is the lack of support for exception handling and stack unwinding across AOT (Ahead-of-Time) compiled binaries in the WebAssembly project WasmEdge. The user 'ibmibmibm' suggests using hidden functions in libgcc and libunwind to apply Frame Description Entry (FDE) data in the .eh_frame section to address this issue.
The potential solutions proposed in the issue include:

Using hidden functions __register_frame and __deregister_frame in libgcc and libunwind to manage FDE data in the .eh_frame section.
Adding specific handling

The central problem discussed in the issue is the implementation of a zlib plugin in the WasmEdge project. The main solutions proposed include adding the necessary CMake configuration, implementing the required functions and structures for zlib integration, and addressing potential issues such as error handling, memory management, and compatibility with the zlib library.

The central problem discussed in the issue is that WasmEdge is unable to run a WebAssembly file in text format. The existing Abstract Syntax Trees (AST) need to be serialized into binary format for execution. The proposed solution involves implementing serialization for instructions, segments, sections, and modules. Milestones include planning, code implementation, testing, code review, and optimization. User 'dracoooooo' plans to submit a pull request (PR) this week for discussion and progress review.

The central problem discussed in the issue is the lack of support for the zlib plugin in the LFX Workspace of WasmEdge. This prevents existing C/C++/Rust apps, especially the Python port, from being compiled and run in WasmEdge. The proposed solution is to add support for zlib host functions through the plug-in system, allowing existing zlib apps to be compiled and run inside WasmEdge. This approach improves performance, simplifies the compilation process, and eliminates the need for developers to register host functions. The issue is currently in progress with several milestones defined for implementation.

The central problem discussed in the issue is the need to support Tensorflow and PyTorch in WasmEdge's Python runtime for lightweight deployment of AI applications. The proposed solution includes incorporating WasmEdge's NN extensions into the Python interpreter, creating CPython wrappers for host functions, and creating high-level Python wrapper functions. Milestones are defined, including building a container, demonstrating inference examples, and creating documentation and tutorials. The project is currently in progress, with milestones 1 and 2 completed and work ongoing for milestones 3 and 4.

Issue: [Proposal] Implement WASI-threads
User 'LFsWang' opened an issue requesting the implementation of WASI-threads. The main tasks to be addressed are resolving a race condition issue and addressing the memory base pointer issue during page growth.
Potential Solutions:

Introduce a SharedMemory in MemoryInstance to manage shared memory between threads.
Implement concurrency control to handle race conditions.
Modify the MemoryInstance and ModuleInstance classes to handle shared and cloned memory instances better.
Improve error handling strategies to avoid abrupt program termination.
Ensure thread safety

The central problem discussed in the issue is the lack of a way to deregister registered models in the Named Models feature of WASI NN. The main proposed solution is to add an extension function to fulfill the requirements of the FaaS use scenario. Additionally, the suggestion is made to implement a superset of the official spec. Another solution mentioned is the opening of a PR for review after the release of wasi-nn.

The central problem discussed in the issue is the need to update the libsql UDF runtime and examples to WasmEdge 0.12. The main solutions proposed include updating the integration WasmEdge version to 0.12.1, updating the TFLite UDF example to WASI NN + TFLite plugin, and updating the web service UDF example to HTTPS + TLS plugin.

The central problem discussed in the GitHub issue is that the user is facing errors while building WasmEdge with WASI-NN PyTorch Backend. The user has followed the guide and documentation but encountered various errors, including file not found and undefined symbol lookup errors.
The main solutions proposed or suggested include checking if the test data is downloaded successfully, running the download-pytorch-fixtures.sh script manually to check for network issues, following the torch part of the guide to install torch dependency and set environment variables, making sure to reset environment variables and perform a clean fresh build, and raising a separate issue for the unresolved error.

The central problem discussed in the issue is that the 'port' variable in the inode-linux.cpp file needs to be converted using the ntohs function. The main solution proposed is to add the ntohs conversion to the 'port' variable.

This GitHub issue titled 'Unexpected Behaviour inferencing a model with Wasi-NN plugin using Pytorch Backend' is opened by user 'sarrah-basta'. The issue revolves around encountering unexpected behavior while using the Wasi-NN plugin in the WasmEdge project. The user has provided a reproducible example and made changes to the Wasi-NN plugin files to create tensors of the correct types. However, they are still facing errors during model inference. The user suggests that the issue may be related to the versions of Python or Transformers library used. They also seek assistance in understanding how TorchScript in Wasi-NN calls the Python

The central problem discussed in the issue is the trade-off between performance and ease of use in WasmEdge. The interpreter mode is reliable but slow, while the ahead-of-time (AOT) compilation mode boosts performance but requires the LLVM framework and is time-consuming.
The main solutions proposed are to introduce a Just-in-Time (JIT) compilation, potentially using an existing framework to minimize costs, and to develop a One-Pass compiler that eliminates the need for LLVM dependency and reduces compilation time, although with some performance trade-offs.
The aim is to create a smoother user experience by improving the performance of WasmEdge while reducing the

The central problem discussed in the issue is the lack of a method in WasmEdge C-SDK to remove registered modules owned by the VM. The issue highlights that not deleting registered modules after use is wasteful. One potential solution suggested is to create methods that allow the VM to release its ownership and delete specific named modules. However, it is mentioned that this function may not be safe as module instances may have dependencies, which can cause core dump when execution occurs. Another potential solution discussed is implementing the dependency tree of registered modules in the store. It is suggested that this API can be implemented with a warning message first, and the dependency tree

Issue Title: Memory Errors when using AOT. Golang Host, Rust Guest
User: pcfreak30
Label: bug, arch-x86_64, binding-go
Description:

Compiling the project with AOT version of wasm causes 'out of bounds memory access' error when 'allocate' is called by the SDK.
Interpreted version of wasm works fine but is slow.
Expected behavior is to run at native computing speed.

Environment:

Hardware Architecture: x86_64/amd64
Operating System: Linux Mint 21 Vanessa

Suggested solutions:

Compile Rust application with `cargo

The central problem discussed in the issue is to add support for Tensorflow and PyTorch in WasmEdge's Python runtime. The motivation behind this is to enable lightweight deployment of Python applications in WasmEdge containers. The proposed solutions include incorporating WasmEdge's NN extensions into the Python interpreter, creating CPython wrappers for host function APIs, creating high-level Python wrapper functions, and validating the Python wrapper API through CI and demo apps. Multiple candidates have expressed interest in working on the project and have showcased relevant skills in C programming, Python, and machine learning.

The central problem discussed in the GitHub issue is the need for a lightweight and high-performance log processing framework using WasmEdge. The proposed solution involves building a Rust-based framework with traits for log collection, transformation, and routing, implementing collectors for MySQL binlog and generic log files, supporting transformer algorithms from FileBeat, and providing destinations for Kafka, Redis, and ElasticSearch. The issue also mentions the requirement for proficiency in Rust, familiarity with various technologies, and completion of pretests for candidates applying through LFX Mentorship.

Issue: Release Process for WasmEdge 0.13.0
Problem: The release process for WasmEdge 0.13.0 is being discussed, including planned alpha and release dates, features, issues, and document updates.
Solutions: Some features and issues have been addressed or moved to future releases, and there is a mention of updating the C API document.

The central problem discussed in the GitHub issue is the need for automatic buffer allocation on memory instances for WASM functions. The main solutions proposed are:

Use the exported malloc or __new functions of the WASM module.
Maintain the heap section on memory instances with the __heap_base global.
Approach 1 is considered easier, but approach 2 is seen as more general. The issue is open for contribution, and a PR has already been created for approach 1.

The central problem discussed in the issue is that when using cout instead of printf in the wasm interpreter mode, the execution may crash due to complicated exception handling blocks in cout. The main solution proposed is to merge the issue first and solve this problem in the future.

The central problem discussed in the issue is the lack of support for TensorFlow Lite (TFLite) backend and custom operators in the WASI-NN plugin. The main solutions proposed include adding support for tf_select_ops and TFLite custom ops, modifying the code to handle error conditions, improving code quality and documentation, and addressing compatibility issues with other backends.

The central problem discussed in the issue is the need to create a Rust and JavaScript-based framework for building lightweight serverless functions using the WasmEdge runtime. The framework should support various tasks around Large Language Models (LLMs), such as accessing cloud LLM services, locally trained LLM instances, fine-tuning LLMs, document segmentation, and embedding generation. It should also provide features like managing vector databases and prompt libraries, as well as interfacing with external systems through the WasmEdge connectors SDK. The main solutions proposed include developing a Rust language framework and a JavaScript framework for WasmEdge applications, along with documentation and sample applications

The central problem discussed in the issue is that when developers install the latest version of WasmEdge and test an unreleased Rust SDK, they may forget to set the necessary variables (WASMEDGE_INCLUDE_DIR, WASMEDGE_LIB_DIR, WASMEDGE_BUILD_DIR) to the installed path. This can result in compilation errors that are challenging to identify and fix.
The main solution proposed is to consider adding support for these environments as the default behavior in the Rust-SDK. By doing so, developers won't have to manually set the variables, reducing the chances of compilation errors.

The central problem discussed in the GitHub issue is the poor performance of the wasmedge runtime when executing Go code. The performance is reported to be around 10x slower compared to other WebAssembly runtimes. The main solutions proposed include using the AOT (Ahead-of-Time) compilation mode of wasmedge, which significantly improves performance but adds compilation time. Another solution proposed is the implementation of a JIT (Just-in-Time) compilation engine in the wasmedge runtime to improve performance without the need for AOT compilation. A tracking issue for the JIT work has been created.

The central problem discussed in the issue is a significant performance difference observed when invoking a function pointer in a structure using the 'wasmedge' WebAssembly runtime compared to other runtimes. The execution time in 'wasmedge' is 9x slower. The issue suggests that there might be a performance bug when invoking the function pointer. The main proposed solution is to investigate and address this performance issue in the 'wasmedge' runtime.

The central problem discussed in the issue is a performance difference observed in the execution of a virtual function in the 'wasmedge' runtime compared to other runtimes. The execution time in 'wasmedge' is significantly slower when the virtual keyword is present. The main proposed solution is to review and improve the codegen of 'call_indirect' in 'wasmedge' to address this performance issue. The issue is labeled as 'help wanted' for community assistance.

The central problem discussed in the issue is the lack of support for the WasmEdge WASI Socket component on macOS, which limits its functionality to the Linux platform. The objective is to investigate and resolve the underlying issues preventing compatibility with macOS, implement necessary changes and fixes, and validate the functionality through testing and examples. The main solutions proposed include modifying the WasmEdge WASI Socket component to support macOS, documenting the investigation process and solutions, and verifying the correct functioning of various examples on macOS.

The central problem discussed in the issue is to enable WasmEdge compilation with the MSVC toolchain on the Microsoft Windows platform. The main solutions proposed are to refactor and modify the WasmEdge source code to ensure compatibility, validate the test suite behavior, and provide comprehensive documentation. The aim is to deliver a modified version of WasmEdge that can be compiled using the MSVC toolchain without errors or warnings, while maintaining consistency with the Clang toolchain.

The central problem discussed in the issue is that the AOT-compiled WASM file crashes when executing the WasmEdge_VMExecute() function. The user is unsure if they are doing something wrong or if it is a genuine bug. They provide code snippets and a screenshot showing the crash.
One potential solution suggested by another user is to try setting the compilation optimization level to O2 or O3 instead of Os. This could be an attempt to see if the crash is related to the optimization level used during compilation.
In summary, the issue revolves around a crash when executing the AOT-compiled WAS

The central problem discussed in the issue is that the struct padding is inconsistent between the host (compiled with MSVC) and the library (compiled with Clang). This causes bugs #2421 and #2422. The proposed solution is to add uint64_t pad; to the struct WasmEdge_Value. However, there is a search for a better solution, as other structures may also be affected. The aim is to refactor the type to have a stable size and address the issue.

The central problem discussed in the issue is that the Windows build instructions for the project expect Visual Studio Enterprise, causing issues for users with Visual Studio Community. Additionally, the curl command fails and the compiler raises errors.
The main solutions proposed or suggested are:

Applying a regex workaround to the build file.
Editing the curl command by replacing -sLO with -s -L.
Downloading curl using a web browser instead.
Using vcpkg to install LLVM instead of building it from source.
Considering using MSVC instead of installing Clang.
Removing LLVM/LLD/Clang dependencies if not needed

The central problem discussed in the issue is that the int128.h header file in WasmEdge is incompatible with MSVC compiler, causing errors during compilation. The user Photosounder suggests using a different condition in the #if statement to make it compatible. Another user, abhinandanudupa, suggests using Clang as the compiler instead of MSVC. The user hydai acknowledges the compatibility issue and agrees to change the check condition in int128.h as suggested by Photosounder.

The central problem discussed in the GitHub issue is a "module name conflict" when running a custom-built WebAssembly (Wasm) OCI image on Kubernetes (k8s). The user successfully runs the image using 'ctr run' but encounters an error when deploying it on k8s. The error message states "instantiation failed: module name conflict." The user seeks a solution to enable successful execution of the Wasm container on k8s. One potential solution suggested is to upload the problematic image to Docker Hub for further investigation and troubleshooting.

Issue: 'feat: fully support wasmedge-wasi-socket on the macOS apple silicon platform'

User 'hydai' reported that some examples cannot be executed on macOS.
The issue refers to an example from a GitHub repository.
The user expects the examples to work on macOS Apple Silicon platform like they do on Linux.
Environment: macOS on Apple Silicon (aarch64), WasmEdge version 0.11.2.
No steps to reproduce mentioned.

Central problem: Incompatibility issue with executing examples on macOS Apple Silicon platform.
Main solutions proposed/agreed upon: None mentioned in the issue.

The central problem discussed in the issue is that the current implementation of Wasmedge requires manual addition of shared memory in the C API, preventing direct execution of examples using wasi-threads. The main solution proposed is for the WASI host to allocate shared memories to satisfy the module's imports.

The central problem discussed in the issue is the lack of an example for exception handling in WasmEdge. The user suggests providing an example after the exception handling proposal has been added. The main solution proposed is to generate standalone wasm from C++ using emscripten with the -fwasm-exceptions flag.

The central problem discussed in the issue is that the Go program is encountering a "fatal error: non-Go code set up signal handler without SA_ONSTACK flag" when running tests. This error is obfuscating the real test failures. The suggested solution is to add the SA_ONSTACK flag to the signal handler in the WasmEdge codebase. This issue seems to be specific to MacOS M1, as it does not occur on other operating systems.

The central problem discussed in the issue is the need for supporting function execution timeout within a sandbox. The user wants the ability to specify a timeout value when invoking a function in a WASM sandbox, and if the execution time exceeds the specified timeout, an error should be returned and the sandbox should be properly shutdown.
The main solutions proposed in the comments include using an async function and a timeout in combination, as suggested by AshantiM. The use of an async runtime like tokio for cancellation is also mentioned. Additionally, juntao mentions that the WasmEdge C SDK provides a mechanism for interrupting VM execution, but a solution for

The central problem discussed in the issue is the need to restrict a virtual machine (VM) to use specific network interface cards (NICs) in order to connect to external resources with different VPC configurations. The proposed solution is to modify the implementation of WASI sockets to support the ability to bind to specific network interfaces. There is a suggestion to provide this feature either through the host SDK or through host functions in the Wasm code. The idea is to bind to multiple IP addresses based on routing rules and have control over socket creation.

The central problem discussed in the issue is that when using CTR to run an OCI image created from an AOT wasm module, an "out of bounds memory access" error occurs. This issue is specific to the machine where the AOT wasm is created, as the same image runs fine on other machines. The main solution proposed is for the user to share their wasm image with @hydai, who can then try to reproduce the issue and provide assistance.

The central problem discussed in the GitHub issue is to support Document AI tasks in WasmEdge applications. The aim is to create pre- and post-processing functions for tasks such as OCR, document image classification, document layout analysis, document parsing, and document visual question answering. The proposed solutions include creating generalized pre- and post-processing functions, implementing inference functions for each task using fine-tuned models, creating demo examples and tests, and modularizing the code for easy integration. Additionally, there is a discussion about selecting the best models and addressing licensing issues.

The central problem discussed in the issue is the need to build a Rust library crate that allows easy integration of Mediapipe models in WasmEdge applications. The user has made progress in implementing various tasks and models, including image classification, object detection, hand landmarks detection, gesture recognition, text classification, and audio classification. They have also explored the use of FFmpeg and OpenCV for video and image processing. The user has proposed solutions such as building a new TfLite library with MediaPipe custom operators and implementing GPU support for MediaPipe models.

The central problem discussed in the issue is to enhance the user experience of installing and managing plugins in the container environment. The main solutions proposed include:

Providing a total solution for running WASM inside a container, with automatic recognition of supported plugins based on a specific path.
Allowing users to have control over containerd to install, overwrite, and version control on shim, wasmedge, and its plugins.
Allowing users without root permission on the host to build their WASM application based on a toolchain image, with the /lib directory automatically mounted to /opt/containerd/lib.
The aim is to

Issue Title: LFX Workspace: streaming data processing with WasmEdge
Issue Content Analysis:

User 'xxchan' opened this issue as part of the LFX mentorship.
The issue aims to integrate WasmEdge as an alternative runtime for Fluvio, an open-source data streaming platform with in-line computation capabilities.
The milestones mentioned in the issue include:

Quick attempt to replace wasmtime with WasmEdge in filter.
Investigating Fluvio's usage of wasm engine in detail and designing a solution to support different wasm engines simultaneously.
Implementing full WasmEdge engine support and

The central problem discussed in the issue is the development of a C++ SDK for WasmEdge, based on the existing C SDK. The goal is to implement the Basics and VM functionalities. The proposed solution is to study the SDK documentation and source code, design the C++ SDK with well-structured APIs, write the necessary class implementations, and provide documentation and installation guides. The main focus at the moment is exploring the existing C SDK and internal C++ APIs to understand how to expose SDK functions and design the C++ API for the VM section.

The central problem in the issue is that while implementing the Tensorflow backend for WASI-NN in WasmEdge, the use of string names for input/output nodes in Tensorflow conflicts with the numeric index approach used in WASI-NN. Additionally, loading SavedModel in Tensorflow requires passing a string path, which is challenging in the WASI environment where models are typically passed as bytes buffers.
The suggested solutions are:

Convert the Tensorflow model to TensorflowLite and use the TensorflowLite backend in WASI-NN.
Implement a buffer-loading version of the Tensorflow backend to handle cases where there is only

Issue: 'Unable to build on Windows'
Problem: The user is unable to successfully build the project on Windows. The build fails with an error.
Solutions proposed:

Using a different Visual Studio edition: A user suggests that the issue might be related to the Visual Studio edition being used. They recommend checking if the required file is present in the correct directory, specifically in the "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/DIA SDK/lib/amd64/diaguids.lib" path. They also suggest trying to compile using the "2022 Community" edition instead of "2022 Enterprise"

Issue: 'Support exception handling proposal'
Central problem: The issue discusses the need to support exception handling proposal for running Kotlin/Wasm in WasmEdge, as it is usually required by GCed languages like Kotlin or Java.
Main solutions proposed: The first step suggested is to allow parsing of WebAssembly bytecode built with EH proposal enabled, to support positive scenarios that do not throw exceptions. This would enable experimentation with Kotlin/Wasm, Dart, etc.
Agreed upon solution: It is mentioned in the comments that 'harry900831' will take on the task of implementing the proposed solution.

The central problem discussed in the issue is that the optimization of wasmedge_quickjs with wasmedgec (AOT) fails, resulting in an error regarding out of bounds memory access. The main solutions proposed include using the .dylib format for the shared library and using the --optimize=0 format for the O0 optimization. The issue is scheduled to be fixed in the next release period.

The central problem in the GitHub issue is that the manylinux release of Wasmedge with the wasi_nn-pytorch plugin is not working on Ubuntu. The user expected the manylinux release to work on Ubuntu as well.
Two potential solutions were suggested in the comments. The user 'hydai' mentioned that only WASI-NN has this issue, and recommended using the Ubuntu versions instead of the manylinux release. Another user 'q82419' suggested using the Ubuntu versions of WasmEdge and the cxx11-abi enabled libtorch for Ubuntu platforms.
In summary, the issue revolves around the compatibility of the

The central problem discussed in the issue is the release of binary files in Java. It is unclear from the given information what specific problem related to the release of binary files is being addressed.
No main solutions or agreements are mentioned in the given content.

The central problem discussed in the issue is the lack of support for async functions inside Wasm programs. The main solution proposed is to support the Typed Continuations Proposal, which would enable async functions in Wasm. The issue is labeled as a high priority feature request.

Issue: 'feat: Support the wasi-threads proposal'

User 'juntao' suggests supporting the 'wasi-threads' API, enabling spawning new Wasm instances in new threads.
Together with the 'wasm threads' proposal, existing multi-thread C/C++ or Rust libraries can be compiled into WASI.
'WasmEdge' already supports 'wasm threads' and provides examples using a host C SDK.
User 'juntao' suggests providing a C and Rust API library for developers to explicitly code the 'wasi_thread_spawn' call.
User 'LFsWang' volunteers

The central problem discussed in the issue is the difficulty in understanding what happened when a Wasm instance traps. The user suggests implementing Wasm coredumps as a way to enable post-mortem debugging, similar to how it is done in native environments. The user provides a link to a specification for Wasm coredumps and also mentions that feedback is welcome. Additionally, the user highlights that Wasm coredumps would be particularly useful in serverless environments where production binaries are stripped and have limited logging.

The central problem discussed in the issue is the static build error on Windows caused by specific lines of code in the CMakeLists.txt file. The user suggests using the OBJECT keyword and linking it to the library instead of manually merging objects. They also mention that hard coding the library name is not ideal for Windows. Another user comments that the Windows platform is not implemented yet and requests contributions for the Windows part.

Issue Title: feat: LFX Serialization Completion
Label: LFX Mentorship
Central Problem: WasmEdge, a WebAssembly runtime, currently only supports the binary format for input WebAssembly files. To enable the future text format WebAssembly loader feature, the implementation of serializing a WebAssembly module is necessary.
Main Solutions Proposed/Agreed Upon:

Complete the serialization functions of WebAssembly modules, including element segment and data segment encoding.
Complete the WebAssembly instructions encoding.
Generate unit test data and pass the unit tests.
Achieve >80% code coverage for serialization.

Potential Mentees: Shubham435

The central problem discussed in the GitHub issue is the inability to create static binaries using the wasmedge-sys crate in Rust. The user encountered build failures and missing dependencies when trying to build a static binary. Potential solutions suggested include updating the dependencies, using the rust-static-lib workflow as a reference, and submitting a feature request to address the issue.


 I cannot just add a transform or even just a transform and a start position. Possibly this is WAI, but if so, it's seems a somewhat inconvenient and awkward, IMO. Why can't I use a transform with the page length default, for example?
I tried all the following variants, but only the first of these results in invocation of my transform:
    .slice(1, 10, vb.transform('js-query-transform'))

    .slice(vb.transform('js-query-transform'))
    .slice(0, vb.transform('js-query-transform'))
    .slice(1, vb.transform('js-query-transform'))
    .slice({start: 1, transform: vb.transform('js-query-transform')})

This probably applies to queryBuilder.slice  as well, but I didn't happen to try it there.

The .slice() clause should be able to take a .transform() invocation without the paging parameters.

Tests added to regression under test test-complete/nodejs-transform-javascript.js


Type missed.

🛑 IMPORTANT: You can get your feedback addressed faster if you use the comment section for the article in which you encountered a problem.
Link to article:
https://docs.microsoft.com/ja-jp/dynamics365/customer-engagement/marketing/easy-subscription-lists
Problem:
"乳s力" is missed type. Maybe "入力" is correct.

@ShinjiFunabiki Please submit feedback by clicking on the button at the doc's bottom.


Is RancherOS available on Vultr?

It doesn't seem to show up on the os list https://api.vultr.com/v1/os/list

You are right, it's not available as an OS option on Vultr. RancherOS is therefore installed via iPXE: https://www.vultr.com/docs/ipxe-boot-feature

Right I see. The default OSID is 159 which is custom and allows IPXE and this section activates IPXE while this one creates the bootscript  from the latest RancherOS image. Got it.


Fixed some Japanese translation.

I found some mistake with my translation and fixed them.
I'm Sorry😭

Thanks!


$P 1 for automatic play don't work

I'm adding to my app the play function, but I discovered that the play mode work from RC but not from Bluetooth $P 1 command. I tried also to put $P 1 from Putty connected by usb, and it don't work.
The command is accepted as correct, but nothing happen.
Also tried to unassign the RC channel.
What I'm doing wrong?
EDIT: I uploaded the APP with play here if you want try: http://william-fanelli.com/wp-content/uploads/myupload/ID_CablecamSetup_8.apk

Again about Play function, I have some suggest:

very important: if you turn on the cablecam and forgot the play switch on in the RC, the cablecam start to play and it can be dangerous. I don't know how solve this, may be at the start up the swich must be in off, if is in on you must switch it in off before start operation.
the 5 seconds pause sometimes is too much. Can you add a parameter for set this time? Is not necessary that you can set from RC (RC have a lot of function now), simply from terminal (and my app)

Found the problem. I said "if the channel is unassigned or stick = neutral then Play = OFF". It must be "is unassigned then do nothing, else check if in neutral and turn on or off".
Yes, that is a very good point. We have a controller that prevent something, yet with Play and storing end points permanently, it might have its own will. I have changed the logic that it fall off the Play mode whenever there is even the smallest glitch. In all those cases you need to turn off Play in order to start it again.

Stick movement? Forcibly turn off Play.
Entered another mode? Forcibly turn off Play.

The command $R 5 does set the the wait time when reversing to 5 seconds (default)

ATTENTION: I have also changed the command response for all commands. Before it was a mixture of OK and echoing back the settings plus OK.
Now it is consistent for all commands: Without arguments it does the same print as before. With arguments it sets the values and then does the same print as without commands.
Example:
Old: $N 1500 30 700 ---> $N OK
New: $N 1500 30 700 ---> $N 1500 30 700 OK

Thanks Werner, I will modify my app. Actually I'm in holiday until 13 August, so I can't do it now. I let you know when ready.

During my holidays I had a problem at a my eye: retina detachment. So, I''m back before, from end of July.
My eye is OK now, and I' m working on cablecam. Now the command $P 1 is working.
I will publish link to new app asap, I'm checking it. Now the app require android 4.0 or higher.


Adding example for nxp cubox-i/hummingboard board.

This layer demonstrates A/B updates with RAUC for cubox-i/hummingboard boards.

Hi @ejoerns,

I am not yet sure if we should name this layer meta-rauc-nxp since it does not only sound quite official but also covers only one specific board and I am unsure if there is much more to share with other nxp platforms.

I hope that over the time there will be opportunities to extend the RAUC support in this sub-layer for other dev boards with i.MX6 and i.MX8 SoC. Layer meta-freescale has its name due to historical reasons but nowadays having freescale in the name for a new sublayer may create confusion.

In general, I have to say that I am not a huge fan of meta-freescale (or vendor layers in general) since it adds very much overhead to the BSP that is not needed in 90% of the use cases, but on the other hand, it is a simple reference for an integration of some platforms and so we don't have to provide our own machine config, yet.

I have just tried out this pull request and it works fine in terms of RAUC.
It is interesting that my Hummingboard doesn't boot properly if there is an HDMI cable connected to it and u-boot complains for Unknown command 'fastboot' - try 'help'. This is weird but it is BSP issues and not related to RAUC. It happens with and without meta-rauc & meta-rauc-community.
@AtanasBunchev could you please address the minor issues pointed out in Enrico's code review?
Thanks,
Leon

Hi @ejoerns,

I am not yet sure if we should name this layer meta-rauc-nxp since it does not only sound quite official but also covers only one specific board and I am unsure if there is much more to share with other nxp platforms.

I hope that over the time there will be opportunities to extend the RAUC support in this sub-layer for other dev boards with i.MX6 and i.MX8 SoC. Layer meta-freescale has its name due to historical reasons but nowadays having freescale in the name for a new sublayer may create confusion.

Yes, I know, but this was not my point. My thought was more about if we should name this meta-rauc-nxp or meta-rauc-cubox-i.
But also note that there are only a few example boards in the nxp/freescale layer (and they are actually in meta-freescale-3rdparty). For others, I do not see too much benefit in adding meta-freescale since i.MX processors are well-supported by mainline u-boot and kernel. For i.MX8 and its firmware, meta-freescale might however make a little more sense.

In general, I have to say that I am not a huge fan of meta-freescale (or vendor layers in general) since it adds very much overhead to the BSP that is not needed in 90% of the use cases, but on the other hand, it is a simple reference for an integration of some platforms and so we don't have to provide our own machine config, yet.

I have just tried out this pull request and it works fine in terms of RAUC.

So you have a Cubox-I? Great! I have only compile-tested it but this looks fine.

It is interesting that my Hummingboard doesn't boot properly if there is a HDMI cable connected to it and u-boot complains for Unknown command 'fastboot' - try 'help'. This is weird but it is BSP issues and not related to RAUC. It happens with and without meta-rauc & meta-rauc-community.
@AtanasBunchev could you please address the minor issues pointed out in Enrico's code review?
Thanks, Leon

Yes, I know, but this was not my point. My thought was more about if we should name this meta-rauc-nxp or meta-rauc-cubox-i.

I don't insist but I prefer to think about the long-term future and group together support for devices with NXP i.mx6/i.mx8. At the moment cubox-i is the first one but hopefully there will be more to follow.

So you have a Cubox-I? Great! I have only compile-tested it but this looks fine.

I have both HummingBoard and cubox. However, only Hummingboard has convenient pins for attaching UART to USB. As I mentioned there is an U-Boot issue with the HDMI which affects both devices so I tested only on Hummingboard. Unfortunately I don't have enough time for debugging this in the BSP and based on my tests it is definitely not related to RAUC.

I changed the bundle format to verity and added description about updating with HTTP Streaming.

Hi @AtanasBunchev,
Awesome! Great work! It is always welcome to extend the list of supported hardware in meta-rauc-community. Now with the enabled verity format we should be good to go so I will merge this GitHub pull request. Thank you!
Thanks,
Leon


Unable to create VM on IBM Z DPM Partition

Required information

Distribution: Ubuntu
Distribution version: 20.04
The output of "lxc info" or if that fails:

Kernel version: 5.4.0-70-generic
LXC version: 4.0.6 | 5.2.0
LXD version:4.12
Storage backend in use: dir

Issue description
I am unable to launch a VM on an IBM Z DPM Partition.
Steps to reproduce
root@ta05-canonical:~# lxc launch --vm ubuntu:20.04
Creating the instance
Instance name is: assured-toad
Starting assured-toad
Error: Failed to run: forklimits limit=memlock:unlimited:unlimited -- /snap/lxd/19819/bin/qemu-system-s390x -S -name assured-toad -uuid b00cf2b7-d0a0-4a3e-9b34-e93be7f6ec24 -daemonize -cpu host -nographic -serial chardev:console -nodefaults -no-reboot -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny -readconfig /var/snap/lxd/common/lxd/logs/assured-toad/qemu.conf -pidfile /var/snap/lxd/common/lxd/logs/assured-toad/qemu.pid -D /var/snap/lxd/common/lxd/logs/assured-toad/qemu.log -chroot /var/snap/lxd/common/lxd/virtual-machines/assured-toad -runas lxd: char device redirected to /dev/pts/0 (label console)
: Process exited with a non-zero value
Try `lxc info --show-log local:assured-toad` for more info
root@ta05-canonical:~# lxc info --show-log local:assured-toad
Name: assured-toad
Location: none
Remote: unix://
Architecture: s390x
Created: 2021/03/25 20:45 UTC
Status: Stopped
Type: virtual-machine
Profiles: default

Log:

qemu-system-s390x:/var/snap/lxd/common/lxd/logs/assured-toad/qemu.conf:130: 'virtio-9p-ccw' is not a valid device model name

Our development LPAR appears to be broken or deleted, I requested a new one so hopefully I can reproduce the issue tomorrow.
It's a bit odd though as I definitely tested on s390x after we added 9p support, maybe a regression caused by the QEMU version we're using in the snap. Anyway, shouldn't be too hard to sort out once I have access to an LPAR again.

Managed to reproduce this on my LPAR

Really looks like the 9p-ccw driver is just plain missing in current qemu, not sure what's up with that...

Found one small fix we need to make to LXD to fix CCW networking which regressed when we added multi-queue support to our network config, that's a trivial fix which will be merged shortly.
On the 9p front, it looks like it was a regression in qemu 5.2.0. I found a recent commit which claims to fix it, so giving that a shot in a local snap build, if that works, we'll include the fix in our snaps.

Fix merged in LXD for the network side of things, we'll cherry-pick into the other snaps shortly.
The snap packaging for 4.0 and latest has also been updated to include the 9p fix.


Add-ocl-header

This PR should fix the need to have the OpenCL headers in the system path for build. See https://github.com/clEsperanto/clesperantoj_prototype/issues/28#issuecomment-2133919872
We fetch the headers from github and stores them in a controlled path that we can include later on for the Jar build.

@carlosuc3m
Headers are now directly dl and set in the ./lib/{os}/include folder. This should solve the last part for stabilizing the maven build.
If you have time to test it on you Windows to confirm you do not need to manage the INCLUDE environment variable.

does this mean that we do not need to do apt install ocl-icd-opencl-dev anymore on Linux systems?

It works well on windows by the way!

does this mean that we do not need to do apt install ocl-icd-opencl-dev anymore on Linux systems?

Normally yes! The package install the .so dynamic library already provided by your drivers install (CUDAToolkit, etc.), and the headers. You needed it because you did not have the headers in your PATH which are needed for build (not deployment).
Now, with the PR, the headers are fetch from the khronos repo and included with the pom.xml.
If it works for windows, I will merge this then!


Feat: Accordian/collapse

options could include:
• expandIconPosition prop - , for left or right chevron position
• ability to show 1, or multiple items (see Vercel for singular examples)
• bordered  prop - to show border/background version, if false then show no background/border
•expandIcon prop - ReactNode prop to use your own chevron icon
example of in use:
<Accordian
  defaultActiveId={['1']}
  onChange={callback}
  expandIconPosition="left"
>
  <Accordian.Item label="This is panel header 1" id="1">

{text}

  </Accordian.Item>
  <Accordian.Item label="This is panel header 2" id="2">

{text}

  </Accordian.Item>
  <Accordian.Item label="This is panel header 3" id="3">

{text}

  </Accordian.Item>
</Accordian>

vercel example
https://user-images.githubusercontent.com/8291514/105789085-c051aa80-5fbc-11eb-85da-013549f5cd33.mov

antd example
https://ant.design/components/collapse/

materializeUI example
https://material-ui.com/components/accordion/

I was about to create an issue, but you had already anticipated me haha. Another good example of this could be the "Disclosure" component of Handless UI.
Disclosure Component

@angelmtztrc 👍 😂
I think using either HeadlessUI or RadixUI for anything in this library is fine.
I'm just implementing the Select now with headlessui Listbox.
It's pretty good - and having all the keyboard controls for free is awesome 💯

@angelmtztrc did you want to work on this?

@MildTomato @angelmtztrc I'll give this a go if it is available?

@jonthomp I have not a problem with that! I'm a little busy with other things, so go on!

@jonthomp go for it!


Android export should have the string id as key

When you export  as Android ressource, the key of each string is the string to translate itself, while it should be the id of the string in the android project.
Example: export is like this:
<resources>
  <string name="Add dream">Ajouter un rêve</string>
  <string name="Delete">Supprimer</string>
</resources>

When it should be something like:
<resources>
  <string name="settings_btn_add_dream">Ajouter un rêve</string>
  <string name="main_activity_delete_btn_text">Supprimer</string>
</resources>

But for this to be feasible, every string should have an id when created, which is not the case right now.

I'm not sure if I'm getting the issue. When I try to replicate your strings and translations I get the following export for Android:
<?xml version="1.0" encoding="UTF-8"?>
<resources>
  <string name="settings_btn_add_dream">Ajouter un rêve</string>
  <string name="main_activity_delete_btn_text">Supprimer</string>
</resources>

Which is the output that you expect.
Here's the translations on the web app for reference:

@anthonynsimon That's the thing, shouldn't the original string (in the left column) be a word or phrase to translate? In your example it's a key and the translator has no idea what to translate.

That would be a usability issue, at the moment this is not supported. But it definitely makes sense at some point to add this. I'll keep the issue open for future reference.


Zoowsome2

I've used UUID instead of long for generating random ID.Hope, it's not such a big problem!:))

Not at all a problem. Did you commit the Caretaker class as well? Or am I missing something?

Yes I did! I don't know what is going on..

It's fine now. well done


No entries in the playlist

Checklist

[x] I'm asking a question
[x] I've looked through the README and FAQ for similar questions
[x] I've searched the bugtracker for similar questions including closed ones

Question

WRITE QUESTION HERE
Good time of day, I ran into a problem, using the search I find an empty playlist called 'корова' (I'm from Russia), which is why I can't get a link to the video.
YDL_OPTIONS = {'format': 'worstaudio/worst',                'simulate': 'True',                'preferredquality': '192',                'preferredcodec': 'mp3',                'extractor_key': 'FFmpegExtractAudio',                'default_search': 'auto',                'no_warnings': True,                'ignoreerrors': False,                # 'flat-playlist': True,                'nocheckcertificate': True,                'noplaylist': True                }
with YoutubeDL(YDL_OPTIONS) as ydl:     info = ydl.extract_info(f"ytsearch:{arg}", download=False)['entries'][0] #Next, I need to get a link to the video, but I can't do it, because [entries] contains 0 elements
[download] Downloading playlist: корова [youtube:search] query "корова": Downloading page 1 [youtube:search] playlist корова: Downloading 0 videos [download] Finished downloading playlist: корова Ignoring exception in command msPlay: Traceback (most recent call last):   File "C:\Users\Maxim\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\ext\commands\core.py", line 85, in wrapped     ret = await coro(*args, **kwargs)   File "C:\Users\Maxim\Desktop\Umaru Боты\UmaruBotDiscord\helper.py", line 756, in msPlay     info = ydl.extract_info(f"ytsearch:{arg}", download=False)[ IndexError: list index out of range

Post verbose output.


Please provide a dockerfile

Please provide a dockerfile so that we can use it directly. Mostly we need a ubuntu container
some thing like this which is available for lunarVim.
https://raw.githubusercontent.com/LunarVim/LunarVim/master/utils/docker/Dockerfile.remote
Thanks in advance

This is the way I'm testing my LazyVim with Docker. You might see this usage on other NVim distributions.
docker run -w /root -it --rm alpine:latest sh -uelic '
  apk add git nodejs neovim ripgrep build-base --update
  git clone https://github.com/LazyVim/starter ~/.config/nvim
  nvim
  '

Check the docs. You can find the docker instructions there.


feat: add Yasha Prihodko as individual

I'm totally behind this initiative. We've been using TF for years. Without this the future of TF would be chaotic for everyone outside of HashiCorp

Added in https://github.com/opentffoundation/manifesto/pull/203


Can anyone help me with how to query the data

Can anyone help me with how to query the data.
use rusqlite::{Connection, OpenFlags, Result};

#[derive(Serialize, Deserialize, Debug)]
pub struct Article {
    title: String,
    created: u128,
    content: String
}

fn init_db() -> Result<()> {
    let path = "~/.blog.db";
    let conn = Connection::open_with_flags(path, OpenFlags::SQLITE_OPEN_CREATE);
    conn?.execute_batch(
    "begin;
    create table if not exists article (
             id integer primary key,
             title text not null unique,
             created integer not null,
             content text not null
    );
    commit;")
}

fn query_all_articles() -> Result<()> {
    let path = "~/.blog.db";
    let conn = Connection::open(path);
    let mut stmt = conn.expect("REASON").prepare("SELECT title, created, content FROM article");
    let articles = stmt.expect("REASON").query_map([], |row|{
        Ok(Article{
            title: row.get(0)?,
            created: row.get(1)?,
            content: row.get(2)?
        })
    });

    for a in articles {
        println!("{:?}", a);
    }
    Ok(());
}

fn main() {
   init_db();
   query_all_articles();
}

Everything is right, but wrong.

Please, no screenshot.
And as the error message says, we don't support u128 (only i128)


feat: idpy oidcop frontend

oidcop Satosa Frontend

Tested with JWTConnect-Python-OidcRP.
Mongodb storage for client and session, additional storage engines may be implemented in the future.
Demo project

endpoints

[x] provider discovery
[x] jwks uri
[x] authorization
[x] token
[x] userinfo
[x] registration
[x] registration_read endpoint
[x] introspection endpoint (https://github.com/IdentityPython/SATOSA/pull/378/commits/473310fb5968561f962bf6bcc6b6eacbf78f0b3e)
[ ] token exchange

todo

[x] unit tests
[x] pytest mongo mock
[x] test response_type = "code id_token token" (https://github.com/IdentityPython/SATOSA/pull/378/commits/a61dc99503bcb9d4982b77a6ddcf0c41b6732915)
[x] auto prune expired sessions with mongodb index (https://github.com/IdentityPython/SATOSA/pull/378/commits/137993f77bfb05b44f25ba6df3784e8fb86a31ce, mongo index)
[x] token refresh (https://github.com/IdentityPython/SATOSA/pull/378/commits/59c0a53fa73e70551d76c5355c051a7389ab99fd)
[ ] ~rfc7523 - private_key_jwt test~ > a RP cannot reach the token endpoint if a user have not passed by authz endpoint before. private_key_jwt is a kind of authentication where the user interaction is not needed.
[ ] DPoP support
[ ] general frontend configuration yml file review and refactor (https://github.com/IdentityPython/SATOSA/pull/378/commits/b7668f741b667e0ee8242a234c0380191f50a7df)
[ ] satosa best practice compliances
[ ] Refactor scopes/claims configuration following this

Here a brief description about the main characteristics of this implementation.
Design principle 1
Anyone can migrate its oidcop configuration, from flask_op or django-oidc-op or whatever, in SATOSA and without any particular efforts. Looking at the example configuration we see that config.op.server_info have a standard SATOSA configuration with the only addition of the following customizations, needed in SATOSA for interoperational needs. These are:

autentication

        authentication:
          user:
            acr: urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword
            class: satosa.frontends.oidcop.user_authn.SatosaAuthnMethod

userinfo

       userinfo:
         class: satosa.frontends.oidcop.user_info.SatosaOidcUserInfo

authentication inherits oidcop.user_authn.user.UserAuthnMethod and overloads two methods involved in user authentication and verification. These task are handled by SATOSA in their authentication backends.
userinfo inherits oidcop.user_info.UserInfo and proposes a way to store the claims of the users when they comes from the backend. The claims are stored in the session database (actually mongodb) and then they will be fetched during userinfo endpoint (and also token endpoint, for having  them optionally in id_token claims).
Weakness of SatosaOidcUserInfo

It stores the claims of the user in the db
It loads some temporary data and flush them before returning the userinfo response, here

unhandled features

oidcop SSO and cookies were not have been implemented yet because SATOSA doesn't support logout
dynamic client registration and registration_api are not needed in my deployments but we can have them in a future roadmap
DPoP2, introspection and exchage SHOULD be implemented

Client and Session Storage
MongoDB is the storage, here some brief descriptions for a demo setup. The interface to SATOSA oidcop storage is satosa.frontends.oidcop.storage.base.SatosaOidcStorage and it have three methods:

get_client_by_id(self, client_id:str, expired:bool = True)
store_session_to_db(self, session_manager, **kwargs)
load_session_from_db(self, req_args, http_headers, session_manager, **kwargs)

satosa.frontends.oidcop.storage.mongo.Mongodb overloads them to have I/O operations on mongodb.

Storage design principles
At this time the storage logic is based on the session_manager load/dump/flush methods.
Each time a request is handled by an endpoint the oidcop session manager flushes its memory and loads the definition from the storage, only which one are strictly related to the request received (client_id, acces_token, 'auth code' ...).
Due to this fact, this implementation MUST be improved and extended to handle the introspection/exchange/registration endpoints.
Weakness of the storage model
it's transactional because it loads data from oidcop's in_memory engine before handling a request and dumps them before doing a response, flushing the inmem storage. Each workers do its own.
each session is in its own, I don't let them grow in concurrency between many workers and requests.
I didn't faced any issues at this time with django-oidc-op and I believe that it would be the same in satosa.
This approach CAN'T be deployd in a multithreaded/asyncio-based approach, but can't see any weakness with standalone workers and indipendent sessions.

Added to the docs under external contributions: https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#external-contributions


Add latex snippets for acro package

Acro is a latex package for efficient handling of acronyms. I find myself using it quite often, and therefore adding snippets to improve latex workflow.

@nela sorry but i cant merge this PR. As not every users uses this package :( .


feat: add support for KeyExists and KeysExist

@malandis I've done a bit more research and I am feeling okay about the API names here.  Accessor names/types are up for discussion so if you have any feedback I'd love to hear it.


Add details about codesplitting

Hi!
I wonder if you have tackled or thought about code-splitting yet. It is kinda important to have some sort of code-splitting support. I want to use a react component only on one page but because of the way live_react and the default esbuild config is currently set up in Phoenix, everything is bundled in the App.js file.
In an ideal world, only the specific page that makes use of react will have a link to the react bundle.

Hello there is an example about lazy loading a component
https://live-react-examples.fly.dev/lazy
It could be documented with more detail :thinking:
I also made a TIL on this topic  some time ago.
https://mrdotb.com/tils/phoenix-1.7-config-esbuild-for-dynamic-import

Ah I see. If I understand correctly though this does not split react itself from the main app.js and only bundles the React components separately as required. Is this understanding correct?

Correct. Every time you use a dynamic import it create a new chunk. I am not sure if it's possible to load react with a dynamic import :thinking:
It's probably possible to make it a dynamic import here but it's not the default config on the esbuild shipped with phoenix.
https://github.com/mrdotb/live_react/blob/main/assets/js/live_react/hooks.js
https://esbuild.github.io/analyze/
Is very helpful to understand the different chunk and size.
I wrote this TIL some time ago about lazy loading in component
https://mrdotb.com/tils/phoenix-1.7-config-esbuild-for-dynamic-import


Correlation id for response (526263) does not match request (0) error after IAM is enabled

We have the application that was running without any issue before enable IAM. After IAM is configured, we started getting below errors in very low frequency.
"java.lang.IllegalStateException: Correlation id for response (526263) does not match request (0), request header: RequestHeader(apiKey=SASL_HANDSHAKE, apiVersion=1, clientId=ef958fc7-4d43-490d-aa3c-c1ba0d189003-StreamThread-1-restore-consumer, correlationId=0)
Encountered the following unexpected Kafka exception during processing, this usually indicate Streams internal errors:","error":{"stack":"org.apache.kafka.common.protocol.types.SchemaException: Error reading field 'responses': Error reading array of size<PHONE_NUMBER>, only 5 bytes available
There are threads indicate that the mismatch of kafka server-client version would cause above errors, but why does it only happen when IAM is enabled?
Versions we use:
Kafka cluster version: 2.6.2
kafka-client version: 2.5.0

Would it be possible for you to provide debug logs for the application when running with IAM ?

Sorry about the delayed reply. Would it be possible for you to provide debug logs for the application when running with IAM ?
Thanks for getting back! @sayantacC

This is the full error log for the two errors. 3 mins prior to the errors, I can see there is successful SASL authentication. Events were also being processed after the re-authentication until it fails.
error_logs.txt
Successful_sasl_prior_error.txt
Since the issue happens very infrequent, I'm waiting to see when it happens again and if there is similar pattern.

@mandy-yan-liu Thanks for the logs. As you saw in the logs, when IAM is used, clients are required to reauthenticate periodically. This periodic re-authentication was not happening before you turned on IAM. I wonder if the low rate of failures are related to these periodic re-authentications.
I had a few more clarifying questions:

What is the size of the instance in your MSK cluster?
What is the approximate rate of failure either per unit time or as a fraction of total (re)authentication calls ?
What is the impact of these failures on the application? Does it crash and stop or does it automatically retry and recover from the failure?

@sayantacC I'm also suspecting the error is related to the re-authentication, the specific correlationId error looks like it's from the communication between server and client for handshake api call and it usually fails after the authentication call is made.

The log I sent out was from our testing environment, the broker type is kafka.m5.large and the total number of brokers is 3, EBS storage volume per broker is 100 GIB. We also see the error happen in our production environment, where the broker type is kafka.m5.xlarge with 3 brokers as well, EBS storage volume per broker is 1000GIB.
It's difficult to determine the rate of failure, it's very inconsistent. For the last 6 days, the service we used to monitor this error has failed once in the testing environment, and twice in production. The IAM role the service is using is set with Maximum session duration=1hr.
With this error the service crash and stop, if we restart the service then it works fine again until the error shows up again. I don't see any automatically retry in the code/log and it cannot recover from the failure. Much appreciated if you could give us any guidance on if there is a way to add retry.

Thanks a lot for your help!

@mandy-yan-liu Would it be possible for you to handle the uncaught exception by using KafkaStreams::setUncaughtExceptionHandler ?
Kafka Streams added an easier to use setUncaughtExceptionHandler in version 2.8. This new version provides explicit results that allow you to choose to replace a thread, shutdown client/application ?
Hope this helps.

Closing due to inactivity. Please feel free to reopen.


Error on open wallet connect modal on desktop

I was using the wallet connect connector and somehow, it is not opening on the newest version of thirdweb package. I tested it on another project that I've worked and the wallet connect was working nicely but when I upgraded the third it didn't work anymore.
I see that walletconnect is on v3 now. idk but maybe its the reason.

Hi @bruno3du - The issue is in the WalletConnect package itself.
You can follow this thread to see the discussion -> https://github.com/WalletConnect/walletconnect-monorepo/issues/3852
Looks like they pushed a fix for it a few hours ago. Once they release the fix in the NPM, This issue should be resolved

This issue has been resolved - please install the latest version to try it out


Allow on the fly changes to config.toml using workflows

Give workflows the ability to change settings in the config.toml that are loaded without needing to restart porla.
This would allow changes in download/upload_rate_limit depending on the time of day for example. Also the listen_interface if the port forwarding from the VPN provider changes.

I'm thinking the actual config file should be read only, but we should be able to change the values in-memory while running. Something like,
function(ctx)
  local settings = ctx.session.settings()
  settings.download_rate_limit = 1024
  settings.upload_rate_limit = 1024
end

At least, this is how I'm imagining things until we move all settings to the database - when we've moved there, it will be easier to do things like persist changes from Lua.

Yeah that makes sense, basically being able to change settings and load them into porla on the fly without having to restart the client.

I think this can be closed now that #233 has been merged. It supports getting and setting session settings.


vello_shaders: Use naga 0.12, not git rev.

The git revision being used was from 0.11 while the current release is 0.12. 0.12 is used in wgpu, so this lets us have a single naga crate being built.

The git revision was pinned, without comment that I can find, and appears to be included in the 0.12 release


OSError: Unable to create file (Unable to open file: name = 'model/time03-15/weights_3t832.001-0.306.h5', errno = 2, error message = 'no such file or directory',

ModelCheckPoint suggestion
Could you add some makdirs code to avoid this issue happening?
Please make sure that the boxes below are checked before you submit your issue. If your issue is an implementation question, please ask your question on StackOverflow or join the Keras Slack channel and ask there instead of filing a GitHub issue.
Thank you!

[√ ] Check that you are up-to-date with the master branch of Keras. You can update with:
pip install git+git://github.com/keras-team/keras.git --upgrade --no-deps

[ √] If running on TensorFlow, check that you are up-to-date with the latest version. The installation instructions can be found here.

[ ] If running on Theano, check that you are up-to-date with the master branch of Theano. You can update with:
pip install git+git://github.com/Theano/Theano.git --upgrade --no-deps

[ √] Provide a link to a GitHub Gist of a Python script that can reproduce your issue (or just copy the script here if it is short).

I don't think this should be done by Keras. This can be easily done on your end:
import os
path = 'model/time03-15/'
os.makedirs(path, exist_ok=True)


SwipeView.SwipeItem.IconImageSource IconColor and IconBackgroundColor does not affect the appearance of the icon

Describe the bug
SwipeView.SwipeItem.IconImageSourceЖ
IconColor and IconBackgroundColor properties does not affect the appearance of the icon
To Reproduce:
<SwipeView>
	<SwipeView.LeftItems>
		<SwipeItems>

			<SwipeItem>
				<SwipeItem.IconImageSource>
					<mi:MaterialOutlined
						Icon="Edit"
						IconBackgroundColor="Magenta"
						IconColor="Green" />
					</SwipeItem.IconImageSource>
				</SwipeItem>

				<SwipeItem
				IconImageSource="{mi:MaterialOutlined Icon=Delete,
				                                      IconColor=Red}" />
			</SwipeItems>
	</SwipeView.LeftItems>

</SwipeView>

Light Mode:

DarkMode:

Expected behavior
Icons must respect the specified colors
Smartphone:
Additional context
API33 Android 13.0
net8.0-android

Describe the bug SwipeView.SwipeItem.IconImageSourceЖ IconColor and IconBackgroundColor properties does not affect the appearance of the icon
To Reproduce:
<SwipeView>
	<SwipeView.LeftItems>
		<SwipeItems>

			<SwipeItem>
				<SwipeItem.IconImageSource>
					<mi:MaterialOutlined
						Icon="Edit"
						IconBackgroundColor="Magenta"
						IconColor="Green" />
					</SwipeItem.IconImageSource>
				</SwipeItem>

				<SwipeItem
				IconImageSource="{mi:MaterialOutlined Icon=Delete,
				                                      IconColor=Red}" />
			</SwipeItems>
	</SwipeView.LeftItems>

</SwipeView>

Light Mode:
DarkMode:
Expected behavior Icons must respect the specified colors
Smartphone: Additional context API33 Android 13.0 net8.0-android

As far as My Testing on this Use Case, I Found that Even If we pass a custom Image Source to SwipeItem with Different Color Property Which Isn't White, The SwipeItem Still Overrides the Image Source Color to Be Black or White Based on AppTheme, On  my understanding this should be limitation that applied by Maui Itself or a Bug in Maui

@uom42 I'm closing this issue, if you have any further questions, feel free to comment on this issue.


Deploy error

Error encountered when running the deploy step in 00_QuickStart.ipynb.
401 Client Error: Unauthorized for url: https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/nui-sample-rg/providers/Microsoft.MachineLearningModelManagement/accounts/nui-sample?api-version=2017-09-01-preview
HttpException: (401)
Reason: Unauthorized

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 25565324-f64d-a8db-bc1c-e50956e6e878
Version Independent ID: a6c9ffa3-c085-b4fc-7153-06adb8a50ce4
Content: How to deploy a model as a web service on an FPGA with Azure Machine Learning
Content Source: articles/machine-learning/service/how-to-deploy-fpga-web-service.md
Service: machine-learning
GitHub Login: @tedway
Microsoft Alias: tedway

Hi nuiwos, thanks for giving this a try!  Currently we have a quota request requirement before deployment can be successful.  Could you please fill this out first: https://aka.ms/aml-real-time-ai-request.  We'll notify you when the quota has been allocated.  Apologies that was not in these docs.  We'll get this updated.  Please go to http://aka.ms/aml-real-time-ai for the latest.

@nuiwos We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.
@tedway Thank you for your response!


Add icons and change accordion behaviour

Depends on #108
Closes #131
In this PR:

icons are added to intro accordion titles
on open accordion is closed so that user sees an overview of all topics and the view fits into one page
user can close and open the tabs in accordion at will

I converted it to draft to prevent merging before #108 is merged.

@MonikaFu this PR implements two different things, can you please separate them into two PRs?

Adding of icons (this is an easy approve and makes sense)
The change of the accordion functionality warrants further discussion

The auto_collapse requires that one of the AccordionItem's is open by default (which you probably noticed).
I don't think removing the auto_collapse option is very user friendly... the Introduction is massive, and allowing the possibility of having all sections open at once (or, requiring that the user shuts each section and opens the next one after they are done) seems against the goal of "having it all fit in one view" of the dashboard.
I understand (and do tend to agree) that having all sections collapsed by default is a bit sleeker, but I don't think it's worth doing that at the expense of losing autocollapse

For example, see how long this scroll bar becomes when all sections are opened at the same time:

The autocollapse option would make it impossible for the page to ever get so long

With #108 merged, I see that the icons now render as expected here 😊
(looking at the PR preview link)

Note #150 handled the incorporation of icons into the accordion.
Recommend closing this PR, and opening a separate PR to remove the autocollapse functionality (if that's desired)