Comments

• 

  over 4 years ago by bmwiedemann | Reply

  On the topic of WASM and shared code: https://webperl.zero-g.net/

×
Edit Comment 4922
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
On the topic of WASM and shared code: https://webperl.zero-g.net/
 
×
Reply to bmwiedemann
On the topic of WASM and shared code: https://webperl.zero-g.net/
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  over 4 years ago by ancorgs | Reply

  Regarding the "explore a GUI/TUI toolkit different from libyui" and thinking about how to make this project useful for the YaST mid-term, I would like to explore https://github.com/AndyObtiva/glimmer-dsl-tk

×
Edit Comment 4932
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
Regarding the "explore a GUI/TUI toolkit different from libyui" and thinking about how to make this project useful for the YaST mid-term, I would like to explore https://github.com/AndyObtiva/glimmer-dsl-tk
 
×
Reply to ancorgs
Regarding the "explore a GUI/TUI toolkit different from libyui" and thinking about how to make this project useful for the YaST mid-term, I would like to explore https://github.com/AndyObtiva/glimmer-dsl-tk
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  over 4 years ago by ancorgs | Reply

  I have focused my experiments in two areas:

  1) Developing a really interactive GUI with Ruby (intentionally avoiding libyui).

  In that regard, I found the Observer and data-binding implementations of Glimmer to be really convenient and straightforward to use. See my experiments at ancorgs/y3network-ruby-ui.

  2) Interfacing WASM with Ruby and/or Python (no browser involved)

  The results in this area were discouraging. In theory WASM should be able to communicate back and forward with Javascript when running in a browser and with any "host" language (let's call it that way) when running out of the browser, inside a "native" WASM runtime. But that communication is limited to passing integers and floats. Anything more advanced (like a string or any structured data) needs extra mechanisms on top that are understood by both the code running in WASM (Rust in our case) and its caller (Ruby/Python/Javascript).

  For the browser, we used wasm-bindgen to interface the WASM code written in Rust with Javascript. That works pretty well, but is useless (even counterproductive) to connect the resulting WASM to any other "host" language. See below.

  In Ruby I tried to use both Wasmer and Wasmtime as runtimes. But wasmer-ruby is in the middle of a major rewrite and is basically unusable with recent versions of Wasmer and/or Ruby. On the other hand, wasmtime-ruby is very basic, lacking basically all features that would be useful for a good integration.

  Integration of Python with both Wasmer and Wastime is much better and more mature. But still the current limits of WASM regarding interfacing with the outer world are a huge limiting factor. These are the three solutions I explored:

  2.1) Using WASM Interface Types, which is expected to become the standard multi-language mechanism to do what we wanted. But it's currently far from being a real option. In the Rust=>WASM side, wasm-bindgen could be used to generate the corresponding specification... but it only worked with an old version. Even that was useless because we couldn't use the Interface Types from the Python or Ruby side. Wasmer has never supported it. Wasmtime supported it for some time but now they dropped the support.

  2.2) Reusing what wasm-bingen generated for the communication with Javascript by writing some connectors in Python that are equivalent to the Javascript ones auto-generated by wasm-bingen. It's not trivial and there is absolutely no guarantee it will keep working. wasm-bingen is a pure Rust<-WASM->Javascript solution with no interest in making it easy (or even possible) to reuse their mechanisms for/from other languages.

  2.3) Handcrafting a mechanism to pass a string in which we could even serialize more complex data. That would be similar to this example that uses C++ in the WASM side and Javascript outside. Valid as a proof of concept, but definitely not a real solution in the mid-term.

×
Edit Comment 5438
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
I have focused my experiments in two areas: 1) Developing a really interactive GUI with Ruby (intentionally avoiding libyui). In that regard, I found the Observer and data-binding implementations of Glimmer to be really convenient and straightforward to use. See my experiments at [ancorgs/y3network-ruby-ui](https://github.com/ancorgs/y3network-ruby-ui). 2) Interfacing WASM with Ruby and/or Python (no browser involved) The results in this area were discouraging. In theory WASM should be able to communicate back and forward with Javascript when running in a browser and with any "host" language (let's call it that way) when running out of the browser, inside a "native" WASM runtime. But that communication is limited to passing integers and floats. Anything more advanced (like a string or any structured data) needs extra mechanisms on top that are understood by both the code running in WASM (Rust in our case) and its caller (Ruby/Python/Javascript). For the browser, we used `wasm-bindgen` to interface the WASM code written in Rust with Javascript. That works pretty well, but is useless (even counterproductive) to connect the resulting WASM to any other "host" language. See below. In Ruby I tried to use both Wasmer and Wasmtime as runtimes. But `wasmer-ruby` is in the middle of a major rewrite and is basically unusable with recent versions of Wasmer and/or Ruby. On the other hand, `wasmtime-ruby` is very basic, lacking basically all features that would be useful for a good integration. Integration of Python with both Wasmer and Wastime is much better and more mature. But still the current limits of WASM regarding interfacing with the outer world are a huge limiting factor. These are the three solutions I explored: 2.1) Using WASM Interface Types, which is expected to become the standard multi-language mechanism to do what we wanted. But it's currently far from being a real option. In the Rust=>WASM side, `wasm-bindgen` could be used to generate the corresponding specification... but it only worked with an old version. Even that was useless because we couldn't use the Interface Types from the Python or Ruby side. Wasmer has never supported it. Wasmtime supported it for some time but now they dropped the support. 2.2) Reusing what `wasm-bingen` generated for the communication with Javascript by writing some connectors in Python that are equivalent to the Javascript ones auto-generated by wasm-bingen. It's not trivial and there is absolutely no guarantee it will keep working. `wasm-bingen` is a pure Rust<-WASM->Javascript solution with no interest in making it easy (or even possible) to reuse their mechanisms for/from other languages. 2.3) Handcrafting a mechanism to pass a string in which we could even serialize more complex data. That would be similar to [this example](https://dev.to/azure/passing-strings-from-c-to-javascript-in-web-assembly-1p01) that uses C++ in the WASM side and Javascript outside. Valid as a proof of concept, but definitely not a real solution in the mid-term.
 
×
Reply to ancorgs
I have focused my experiments in two areas:
1) Developing a really interactive GUI with Ruby (intentionally avoiding libyui).
In that regard, I found the Observer and data-binding implementations of Glimmer to be really convenient and straightforward to use. See my experiments at ancorgs/y3network-ruby-ui.
2) Interfacing WASM with Ruby and/or Python (no browser involved)
The results in this area were discouraging. In theory WASM should be able to communicate back and forward with Javascript when running in a browser and with any "host" language (let's call it that way) when running out of the browser, inside a "native" WASM runtime. But that communication is limited to passing integers and floats. Anything more advanced (like a string or any structured data) needs extra mechanisms on top that are understood by both the code running in WASM (Rust in our case) and its caller (Ruby/Python/Javascript).
For the browser, we used wasm-bindgen to interface the WASM code written in Rust with Javascript. That works pretty well, but is useless (even counterproductive) to connect the resulting WASM to any other "host" language. See below.
In Ruby I tried to use both Wasmer and Wasmtime as runtimes. But wasmer-ruby is in the middle of a major rewrite and is basically unusable with recent versions of Wasmer and/or Ruby. On the other hand, wasmtime-ruby is very basic, lacking basically all features that would be useful for a good integration.
Integration of Python with both Wasmer and Wastime is much better and more mature. But still the current limits of WASM regarding interfacing with the outer world are a huge limiting factor. These are the three solutions I explored:
2.1) Using WASM Interface Types, which is expected to become the standard multi-language mechanism to do what we wanted. But it's currently far from being a real option. In the Rust=>WASM side, wasm-bindgen could be used to generate the corresponding specification... but it only worked with an old version. Even that was useless because we couldn't use the Interface Types from the Python or Ruby side. Wasmer has never supported it. Wasmtime supported it for some time but now they dropped the support.
2.2) Reusing what wasm-bingen generated for the communication with Javascript by writing some connectors in Python that are equivalent to the Javascript ones auto-generated by wasm-bingen. It's not trivial and there is absolutely no guarantee it will keep working. wasm-bingen is a pure Rust<-WASM->Javascript solution with no interest in making it easy (or even possible) to reuse their mechanisms for/from other languages.
2.3) Handcrafting a mechanism to pass a string in which we could even serialize more complex data. That would be similar to this example that uses C++ in the WASM side and Javascript outside. Valid as a proof of concept, but definitely not a real solution in the mid-term.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  over 4 years ago by ancorgs | Reply

  > wasm-bindgen could be used to generate the corresponding specification

  I meant wasm-pack

×
Edit Comment 5440
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
> `wasm-bindgen` could be used to generate the corresponding specification I meant `wasm-pack`
 
×
Reply to ancorgs
> wasm-bindgen could be used to generate the corresponding specification
I meant wasm-pack
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview