https://github.com/dholth/zstdpy/blob/master/streaming_decompression.py#L60

Suggestion: put a warning against emscripten at the top of the docs.

Will try with wasienv.

You are welcome to take this as a more complicated example (if it starts working)

Motivation

Having it also available for Python-3.9 this summer

https://docs.python.org/3/library/doctest.html

Because it's cool!

Thanks for proposing a new feature!

Motivation

I need to create the type signature for a function returning i64. I am auto-generating code for these functions so its very inconvenient to treat i64 specially.

Proposed solution

def HPyLong_AsLongLong(runtime_context, ctx: int, num_handle: int) -> Value.i64:

AND

def HPyLong_AsLongLong(runtime_context, ctx: int, num_handle: int) -> Type.I64:

Should both do it.

Additional context

Also:

def returns_nothing() -> None

should be treated identically to:

def returns_nothing()

As it is in the rest of Python.

Wasmer or the PHP extension have Github templates. Copy them :-).

I know this has something to do with Tables but I couldn't discover the answer through experimentation.

If a C program reports that the address of a function is "0x8", how do I invoke that from Python?

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2020-06-12, rust version 1.46.0-nightly (a37c32e2d 2020-06-11)
warning: Force-skipping unavailable component 'rustfmt-x86_64-unknown-linux-gnu'
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
info: installing component 'rust-std'
info: installing component 'rustc'
error: failed to parse manifest at `/home/dependabot/dependabot-updater/dependabot_tmp_dir/Cargo.toml`

Caused by:
  readme file with name 'README.md' was not found

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Motivation

Currently, Wasmer supports viewing raw memory and accessing functions with numeric parameters and returns. However, it is not (easily) possible to transfer/access strings, arrays/lists/dictionaries and other high level objects.

Proposed solution

Ideally, WebAssembly specs should be updated to support strings and other high level objects :)

More realistic approach is to provide some wrapper functions both to host and WebAssembly module to easily store strings and other objects into memory using currently supported data types and then later easily view/access them.

Some other tools (which are mostly for JS in browsers) already provide similar things. Some of them are Bindgen, Nbind and Embind, there are also some JS functions for this and Emscripten also provides some high level wrappers. You can get others if you just search something like "webassembly strings." Wasmer's implementation of this could be compatible with some of existing implementations for JS to make it easier to write such modules.

Alternatives

It is already possible that function returns pointer to a string and you then manually view memory and assemble the string, but this is not really very practical.

I'm totally new to wasmer and python but I need to use them anyway.
So I installed python-ext-wasm using "pip3 install wasmer" on macOs and CentOs
I'm using python 3.6 on both
when I try to run my code I get this error :
ImportError: cannot import name 'Instance' from 'wasmer'

A Module can already knows how to resolve this. To facilitate the API, we should also introduce an Instance.inner_module or something similar to go back to a module from an instance.

Would it be possible tp include a wasm compiler option like project https://bitbucket.org/windel/ppci ?

As the title says, I installed the beta version 0.4.2 and yet I'm still getting ImportError: Wasmer is not available on this system .
It's possible that I couldn't installed it wrong but I did pip install wasmer-0.4.2_beta_11-cp36-none-win_amd64 and it said that it installed correctly. Anyone able to help me out?

The compiler packages mentioned in the README aren't available on PyPI yet. But I was able to set up wasmer-python using the development instructions and run the examples, and I see that the examples don't require any of the compiler packages.

Will compiler packages be available with the next wasmer-python release?

Thank you for your work on wasmer!

The __call__ method in ExportedFunction should be factorised into methods (similar to getters?).

Motivation

This is important as when debugging Wasmer functions on the Python side there are no introspection tools. So to allow better fine-grained access to information in wasmer_runtime_core::instance::dyn_func underlying the exported function, like signature parameters etc. Developers may need to know how wasmer_runtime_core::instance::ExportedFunction represent Python function's signature in a way similar to what Python's inspect module provides. Also having a help method that prints this information on the Python side could be very useful.

Proposed solution

I am preparing a PR to implement methods like:

// returns the dynamic function object. To be used by __call__ and other methods
fn get_runtime_func_obj(&self) -> Result<DynFunc, PyErr> {...}

// other convenience methods
fn get_runtime_signature(&self) -> ... {...}
fn get_runtime_arguments(&self) -> ... {...}
...

// Plus any code required to turn the return values into pyo3 PyObject

Please provide feedback.

Motivation

Wheels are only provided for classic 64-bit Linux systems. This means that is is currently not possible to easily use Python Wasmer library on Raspberry Pi, as well as other ARM-based systems.

Proposed solution

You should provide wheels for Raspberry Pi. However, you shouldn't publish them on PyPI, as Raspberry Pi armv7l can be uncompatible with other ARM-based systems. Instead, they should be published on piwheels which is a Python package repository providing Arm platform wheels specifically for the Raspberry Pi.

Normally, wheels are automatically built and published by piwheels servers, but as this library requires extra building steps (and actually even doesn't publish source code to PyPI), this doesn't work.

You will probably need to contact @bennuttall or @waveform80 to set up build dependencies on piwheels servers and provide instructions for building library.

Summary

In PR #62 a wheel was created that installs anywhere and fails on import. It was published with version 0.3 but not with version 0.4.1. This breaks @syrusakbary snapshottest for me. Could please publish that wheel? It seems that code needed to build the wheel is still there.

Does this library support importing Python functions into the WebAssembly module instances?

I couldn't find any example and looking at the code at https://github.com/wasmerio/python-ext-wasm/blob/89cecbbd672023f2b12ae183641fba2f9cc4c7e3/src/instance.rs#L133-L134 it seems like it is not supported yet?

I posted it as a question here and on stackOverflow, and nobody answered, so now it's clear it's a bug.

pip install wasmer
python -c 'from wasmer import ImportObject'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'ImportObject' from 'wasmer' (/usr/lib/python3.8/site-packages/wasmer.cpython-38-x86_64-linux-gnu.so

"ImportObject" class is described in readme and presented in examples. I've checked that proper 0.4.1 version of "wasmer" was installed. Also I checked the newest tagged version of "wasmer" which fails with the same error. What can be wrong?

generate_import_object() function doesn't work also:

python -c "from wasmer import Module; Module.generate_import_object()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: type object 'Module' has no attribute 'generate_import_object'

This code gives the same result:

wasm_bytes = open('binary.wasm', 'rb').read()
module = Module(wasm_bytes)
import_object = module.generate_import_object()

Motivation

As done in #27 for __version__ method, it can be useful to have a __core_version__ method that returns the wasmer_runtime version.

Proposed solution

I don't know exactly if there is another way of doing introspection into linked libraries (I suppose not due to mangling), the only solution I can imagine is to parse Cargo.toml using toml crate and then read the wasmer_runtime values. Any better way?

Additional context

We should put as much "meta-information" as possible about the WASM environment in the resulting Python object.

Thanks for proposing a new feature!

Motivation

I want to import a FUNC_REF table into my module.

Proposed solution

I would like to see an example like this in the docs and tests:

    table = Table(store, TableType(Type.FUNC_REF, minimum=0, maximum=10 ), INITIAL_VALUE)

What is INITIAL_VALUE?

At https://github.com/wasmerio/python-ext-wasm#getting-an-access-to-the-in-memory-data

assert bytes(memory_view[0:3]).decode() == 'Wasmer'

should be
assert bytes(memory_view[0:6]).decode() == 'Wasmer'

Motivation

As proposed in #37, it would be nice to collect ideas about how a stable interface should look like from the Python side and how to make it possible using the latest additions to pyo3.

Proposed solution

Collecting notes and comments in this gist. Please keep this issue open to keep track of progress.

Summary

Currently installing the package with Python 3.9 on macOS doesn't give errors but actually only installs an __init__,py with:

raise ImportError("Wasmer is not available on this system")

now that Python 3.9 is released as stable, is there a roadmap to release for it?

See https://github.com/wasmerio/wasmer/releases/tag/0.4.0.

The question is fully described here: https://stackoverflow.com/questions/63489278/cant-import-importobject-from-python-wasmer. Can you help?

Motivation

The library needs some documents to guide developers through adoption/usage/contribution, so to bring them to a "what to do next" stage after trying the example in the README.

Proposed solution

We are working out some stuff in a section of this gist. Please leave this issue open to track progress.

Additional context

It would be great in the future to have an online playground where user can load their own WASM-compiled binary and then try some scripting in Python in an interactive way (like Skulpt)

some pseudo code:

string_to_set = np.frombuffer(b"hello", dtype=uint8)
str_len = len(string_to_set)
ptr= instance.exports.alloc(str_len )


# this is what can be done in JS
arr= UInt8Array.new(instance.exports.memory.buffer(), prt, str_len)
arr.set(string_to_set )

OK, I managed to make it like this:

for i, u in enumerate(string_to_set):
    instance.exports.memory.uint8_view()[i] = int(u)

Still, I think this should be included in the example_memory.py

I'm writing this issue to provide a summary of where we are at publishing the 1.0.0-alpha1 version.

The rewrite is over. We are going to publish the new release. To do so, we need to fix an issue with LLVM.

LLVM is required for the wasmer_compiler_llvm crate. So far, we use the official LLVM builts on Linux and macOS. On Windows, we are using a custom built from ours (see https://github.com/wasmerio/llvm-build/).

However, the official LLVM builts come with ncurse as a dependency. It breaks the manylinux rule of Python wheels. Our own builts have ncurse turned off, so it is likely to fix that issue! However, we have another issue: Our own builts do not build clang, which is required by the native engine.

This last problem is being tested in wasmerio/llvm-build#1 for the moment.

Once it is done, we will see if our custom builts will fix the issue with Python wheels.

Hi! I've tried running the example to see how wasmer runs, and encountered the error:
'libwasmer.Instance' object has no attribute 'exports'

wasmer: 0.1.4
python: 3.7.3
wasm: build with cargo wasm.

The wasm files seems working when I load it with the below code:

fetch('rusty.wasm').then(response =>
        response.arrayBuffer()
      ).then(bytes =>
        WebAssembly.instantiate(bytes, {})
      ).then(results => {
        alert(results.instance.exports.add_one(41));
      });

Motivation

Way to use this project is simple, but by micking Javascipt API, it's not pythonic nor transparent to users.

Proposed solution

Implement Python Importers protocol so WebAssembly modules can be imported in Python code as if they were Python modules, with plain from blah import foo statements.

Not much to reproduce, this just seems like a typo in the README.md

The project publishes wheels for macOS and Linux. We must add wheels for Windows too, as requested in #24.

cc @xmclark

README says the project is BSD licensed and refers to the LICENSE file, but I can’t seem to find said file in the repository.

Is the pip release out of sync with the README or something?

The following fails with a fresh install from pip on python 3.7, same goes with just about anything except the Module and Instance constructor;

from wasmer import Module

wasm_bytes = open('a.out', 'rb').read()
wasm_module = Module(wasm_bytes)
print(wasm_module.custom_section_names)

Summary

I have compiled a library to wrap in python using webassembly but the wrapped function requires a different number of arguments from the original rust code.

Additional details

To reproduce the issue:

install wasmer from pip

pip install wasmer

Clone the repo and build wrapper lib into the target wasm32-unknown-unknown

git clone https://github.com/hskang9/schnorrkel-py.git
cd schnorrkel-py
cargo build --target wasm32-unknown-unknown

Run python-ext-wasm

from wasmer import Instance
from wasmer import Uint8Array
wasm_bytes = open('target/wasm32-unknown-unknown/release/schnorrkel_py.wasm', 'rb').read()
instance = Instance(wasm_bytes)

result = instance.exports.secret_from_seed([1, 2])

print(result)

The error shows that the exported function requires 3 arguments when the original rust code required one pointer to UInt8Array.

here is the error log:

Traceback (most recent call last):
RuntimeError: Missing 2 argument(s) when calling `secret_from_seed`: Expect 3 argument(s), given 1.

Here is the rust code compiled to wasm:

#[no_mangle]
pub extern fn secret_from_seed(seed: &[u8]) -> Vec<u8> {
	__secret_from_seed(seed).to_vec()
}

pub fn __secret_from_seed(seed: &[u8]) -> [u8; SECRET_KEY_LENGTH] {
	let secret = keypair_from_seed(seed).secret.to_bytes();
	let mut s = [0u8; SECRET_KEY_LENGTH];
	s.copy_from_slice(&secret);
	s
}

My question is:

1. How did the argument increase?
2. Did I compile the rust code to the right target?

Motivation

I'd like to be able to (easily) use WASI with Wasmer's Python package in order to publish a native dependency of my application on PyPI. Wasmtime-py, which is what I'm currently using, does provide this.

Proposed solution

Expose WASI functions (perhaps from wasi-common?) through the Python interface in a way that allows easily linking them to WASM modules.

Additional context

The dependency I'm packaging is here.

Hi. I have a function in WebAssembly which gets an image matrix as a parameter. The image format is "unsigned char*" pointer. To pass it I allocate the memory with "dataPtr = instance.exports.malloc(dataLen)" call, fill the data under this pointer with an image and use "dataPtr" as a parameter to my function. In C++ world I usually need to free memory afterwards. I don't have such function here. And after some number of runs I finally get a memory out-of-bounds access, and I need to restart python. Is there any way to free the memory in WebAssembly from python?

Below is the code to reproduce the problem:

image_list = bytearray(image.flatten().tolist())            # convert numpy matrix to byte array
dataLen = len(image_list)                                   # amount of memory we need for image
dataPtr = instance.exports.malloc(dataLen)                  # allocate memory with malloc
uint8_view = instance.memory.uint8_view(offset = dataPtr)   # get "uint8_view" for pointer
uint8_view[:dataLen] = image_list[:]                        # fill data under pointer with bytes

instance.exports.setImage(dataPtr, imageWidth, imageHeight) # call WebAssembly function
# instance.exports.free(dataPtr)                            # absent function to free memory after call

This code works normally except of the aforementioned memory leak which leads to runtime error after some runs:

<ipython-input-49-35a9fe36b2bc> in func(image)
      2     image_list = bytearray(image.flatten().tolist())
      3     dataLen = len(image_list)
----> 4     dataPtr = instance.exports.malloc(dataLen)
      5     uint8_view = instance.memory.uint8_view(offset = dataPtr)
      6     uint8_view[:dataLen] = image_list[:]

RuntimeError: Call error: Error when calling invoke: A `memory out-of-bounds access` trap was thrown at code offset 76788

I didn't find anything about memory freeing in the documentation (including "malloc" function, which is not documented feature).

Thank you for your help

The master branch README says there are wheels on PyPI. But I look at PyPI and it looks like there aren't any. What gives?

That would be super useful to expose the wat2wasm crate directly in Python.

Summary

Assume there is a function foo, which is exposed to python via loading a native C compiled library via ctypes. Is it possible to call this ctypes defined / imported library from wasm using this library?

Additional details

In my usecase, we have a lot of numerical code from C++/C wrapped exposed to python. To speed up the execution, it would be great to move some of the code from python to wasm. For prototype reasons, writing a first version in python is preferred.

The closest I could find is issue #28. However, this is not about importing python but native code, where the (ctypes) are assumed to be known.

Summary

is this lib only support rust's wasm?

I can't test wasm build by cpp.

Additional details

index.cc

#include <emscripten/bind.h>

using namespace emscripten;

int add(int x,int y){
    return x+y;
} 

EMSCRIPTEN_BINDINGS(module){
    function("add",&add);
}

and command to build

emcc index.cc --std=c++11 --bind -s WASM=1

and load into python

from wasmer import Instance

# Get the Wasm module as bytes.
wasm_bytes = open('index.wasm', 'rb').read()

# Instantiate the Wasm module.
instance = Instance(wasm_bytes)

# Call a function on it.
result = instance.exports.add(1, 2)

//not work .

and use Module also not work too.

Describe the bug

Trying to install and use wasmer in windows 10, using (mini)conda environment with py3.7(tried with 3.8 and 3.6 also), installed wasmer "successfully" via: pip install wasmer

First import fails with the following output:

(py37) C:\tmp>python test_wasm.py
Traceback (most recent call last):
File "test_wasm.py", line 1, in
from wasmer import Instance
File "C:\Users\kha\AppData\Local\Continuum\miniconda3\envs\py37\lib\site-packages\wasmer_init_.py", line 1, in
raise ImportError("Wasmer is not available on this system")
ImportError: Wasmer is not available on this system

NOTE: Exact same procedure works fine when performed in a WSL(1) Ubuntu instance on the same machine

Example/greet.py doesn't work well.

Describe

Executing example/greet.py fails with the following message.

$ python examples/greet.py
Traceback (most recent call last):
  File "examples/greet.py", line 19, in <module>
    memory[0:length_of_subject] = subject
TypeError: 'slice' object cannot be interpreted as an integer

If I modify the part memory[0:length_of_subject] = subject to the following code, it works well.

for i in range(length_of_subject-1):
  memory[i] = subject[i]

However, slice assignment should work well based on the implementation __setitem__ in impl PyMappingProtocol for Uint8Array.

I'm not sure if it relates to this issue but I found the external issue (PyO3/pyo3#611).

Thanks for proposing a new feature!

Motivation

Wasmer could support type inferencing of multi-valued return types using Python's typing.Tuple or simple tuples:

from typing import Tuple
from wasmer import Function, Store

store = Store()


def func(foo: int) -> Tuple[int, int]:
    return (foo, foo)


myfunc = Function(store, func)

Proposed solution

I would like the code above to infer FunctionType { params: [I32], results: [I32, I32] })

Alternatives

I can of course supply an explicit declaration

Other spellings that might make sense (more inferencing is better than less, so I'd suggest all be supported, if effort is available):

(int, int)

class Point(NamedTuple):
   x: int
   y: int

def makePoint()->Point:...

Motivation

The Wasmer LLVM backend provides support for a lot more platforms than Cranelift. At the moment if I am depending on Wasmer I would need to ask users on platforms other than x86_64/AArch64 to build Wasmer manually, which is a significant hurdle.

Proposed solution

It would be nice if the Wasmer Python extension had wheels published with the LLVM backend enabled.

Motivation

Beside the exported functions (the custom functions written by the user and compiled to Wasm), we should provide built-in functions that provide a "mini standard library" for the user to leverage on the Python side. For example, regarding this issue, some functions to handle memory views should be included in the Python interface to allow reading/writing to memory views.

Proposed solution

At the moment I use these utilities to access memory views from my Python scripts:

def get_memory_view(instance, size=8):
    """Get a view of `size` from a Wasmer an instance.
    Returns a memory view"""
    mem = instance.memory
    funcname = f'uint{size}_view'
    return getattr(mem, funcname)()

def write_to_view(bytestr, mem_view, offset=0):
    """Fill memory with values from a bytestring starting at `offset`.
    Returns a memory view"""
    for i, c in enumerate(bytestr):
        mem_view[offset + i] = c
    return mem_view

These should be embedded on the Rust side with pyo3 in the Wasmer Instance, so the user can leverage them as he/she leverages exports. So as we have

from instance.exports import some_custom_function

we should have something like:

from instance.builtins import get_memory_view

To achieve this we can add to Instance:

#[pyclass]
pub struct Instance {
    pub(crate) exports: Py<ExportedFunctions>,
    pub(crate) memory: Py<Memory>,
    // to be added
    pub(crate) builtins: Py<BuiltIns>,   
}
...
#[pyclass]
pub struct BuiltIns {
    pub(crate) instance: Rc<runtime::Instance>,
}

#[pymethods]
impl BuiltIns {
    #[getter]
    fn get_memory_view ...

    #[setter]
    fn write_memory_view ...
}

Additional context

As a reference, see what is already present in examples/greet.rs for the host machine. This feature proposes to have those functions also for the Wasm Instance as built-ins.

In addition, as a note, similar to this feature we may want to have a "toolkit" of Rust functions that collects this kind of utilities (as the one in examples/greet.rs; C FFI and similar) and provide them in some sort of wasmer-dev-toolkit crate.

Thanks for proposing a new feature!

Motivation

currently installing wasmer on python 3.8 results in a empty package installation

>>> import wasmer                                            
Traceback (most recent call last):                        
  File "<stdin>", line 1, in <module>                             
  File "/Users/kapilt/.pyenv/versions/pywasm/lib/python3.8/site-packages/wasmer/__init__.py", line 1, in <module>
    raise ImportError("Wasmer is not available on this system")
ImportError: Wasmer is not available on this system

Proposed solution

updating the build / release to use python 3.8 for artifacts published would resolve.

Thanks for proposing a new feature!

Motivation

I was trying to run a wasm file generated by https://github.com/open-policy-agent/opa

>>> i = Instance(wasm_bytes)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Failed to instantiate the module:
    7 link errors: (1 of 7) Import not found, namespace: env, name: opa_abort (2 of 7) Import not found, namespace: env, name: opa_builtin0 (3 of 7) Import not found, namespace: env, name: opa_builtin1 (4 of 7) Import not found, namespace: env, name: opa_builtin2 (5 of 7) Import not found, namespace: env, name: opa_builtin3 (6 of 7) Import not found, namespace: env, name: opa_builtin4 (7 of 7) Import not found, namespace: env, name: memory

it looks like opa expects as part of its integration to provider some imports, here's an example in js

https://github.com/open-policy-agent/npm-opa-wasm/blob/master/src/opa.js#L95

Proposed solution

allow the user to pass in an imports mapping

at the moment it looks as though that its always set to an empty import object

        let imports = imports! {};

        // Instantiate the module.
        let instance = match self.module.instantiate(&imports) {

See https://pyo3.rs/v0.9.2/function.html#making-the-function-signature-available-to-python.