Re: Rust journey

[Alon Zakai]

I understand now, thanks!

On Sun, Feb 6, 2022 at 7:49 AM Александр Гурьянов 
wrote:

> It's because I don't use glfw from rust. In my case I used c/c++ glfw +
> wgpu-native (from rust).
>
> https://github.com/gfx-rs/wgpu-native/blob/f7d731e7fd2a233d550c58ebac54cabfe416a6cb/examples/triangle/main.c
>
> So when I say sdl/glfw + wgpu-native, I mean that I will use c/c++
> sdl/glfw for windows/events and wgpu-native for graphics.
>
> сб, 5 февр. 2022 г. в 00:31, Alon Zakai :
>
>> Wow, great that you got all that working!
>>
>> I'm also interested in SDL/glfw. I was trying to get glfw working with
>> emscripten/rust and hit several problems, so I'm curious how you got it to
>> work. I filed this issue with my problems:
>>
>> https://github.com/PistonDevelopers/glfw-rs/issues/495
>>
>> https://github.com/PistonDevelopers/glfw-rs/issues/495
>>
>> On Fri, Feb 4, 2022 at 2:46 AM Александр Гурьянов 
>> wrote:
>>
>>> Did it! Also I added support for emscripten in wgpu/wgpu-native, and
>>> soon it will be possible to use it with SDL/gflw. Want to add tutorial
>>> about it.
>>>
>>> This article is about linking Vangers (1998) and vange-rs (wgpu renderer)
>>>
>>> https://caiiiycuk.medium.com/vangers-3d-example-of-using-emscripten-in-rust-720ee8099d72
>>>
>>> чт, 27 янв. 2022 г. в 18:16, 'Ingvar Stepanyan' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com>:
>>>
 Ah sorry, I see you tried and said it doesn't work even with `extern
 "C"` in the issue description. That's odd, it definitely should.

 On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan 
 wrote:

> But it's not a bug. As I said, you just need to add "C" to your
> `extern`, because right now you're exposing it from Rust via C FFI, but
> declaring it as a C++ symbol on the other side.
>
> On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
> wrote:
>
>> Filled this bug:
>> https://github.com/emscripten-core/emscripten/issues/16123
>>
>> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via
>> emscripten-discuss :
>>
>>> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++
>>> side, otherwise normal mangling rules apply and it's looking up (or, 
>>> this
>>> case, declaring) a namespaced variable.
>>>
>>> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>>>
 Is it valid to simply do `extern int32_t rv_api_1;` in C to refer
 to a rust variable?  Does that address of `rv_api_1` on the C side look
 correct?

 Does `pub static rv_api_1: i32 = 1;` in rust generate a static
 initializer function or is it simply static memory (like it would be in
 C/C++)?

 Assuming it is generating a ctor then there are a couple of things
 that could be going on.   Are you sure your static ctors have been run?
 i.e. where is your code running?  Is it inside of main?
  Disassembling your final binary should show all static ctors being 
 called
 from the `__wasm_call_ctors` function.

 cheers,
 sam


 On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов <
 caii...@gmail.com> wrote:

> Okay, I think I almost did the same in Rust what Alon described.
> vanger-rs now compiles as static library (.a) with emscripten triple. 
> I use
> this static library to link with original C++ game. So I have *.o 
> files
> from vangers, and librusty_vangers.a (which provides rendering on 
> wgpu). I
> link them with emcc, and it produce wasm  without any error!
>
> Also I do the same with native build - it works fine.
>
> However, when I tries to run it fails with assertion.
>
> On RUST side I have the following code:
> #[no_mangle]
> pub static rv_api_1: i32 = 1;
>
> On C++ side I have the following code:
> extern int32_t rv_api_1;
> // ...
> if(rv_api_1 != 1){
> printf("Invalid libvangers_ffi version expected 1, actual
> %d\n", rv_api_1);
> // abort();
> }
>
> When I run it, I have following output:
> Invalid libvangers_ffi version expected 1, actual 0
>
> For me it looks like static initializer from RUST didn't run.
> Because if I comment the abort(); seems integration works fine. Native
> build works correctly...
> Do you have any idea why so?
>
> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>
>>
>>
>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <
>> caii...@gmail.com> wrote:
>>
>>> Let's look closer to my case. I ported C++ game Vangers to the
>>> web (https://www.gamepix.com/play/vangers). Vangers community
>>> did big 

Re: Rust journey

[Александр Гурьянов]

It's because I don't use glfw from rust. In my case I used c/c++ glfw +
wgpu-native (from rust).
https://github.com/gfx-rs/wgpu-native/blob/f7d731e7fd2a233d550c58ebac54cabfe416a6cb/examples/triangle/main.c

So when I say sdl/glfw + wgpu-native, I mean that I will use c/c++ sdl/glfw
for windows/events and wgpu-native for graphics.

сб, 5 февр. 2022 г. в 00:31, Alon Zakai :

> Wow, great that you got all that working!
>
> I'm also interested in SDL/glfw. I was trying to get glfw working with
> emscripten/rust and hit several problems, so I'm curious how you got it to
> work. I filed this issue with my problems:
>
> https://github.com/PistonDevelopers/glfw-rs/issues/495
>
> https://github.com/PistonDevelopers/glfw-rs/issues/495
>
> On Fri, Feb 4, 2022 at 2:46 AM Александр Гурьянов 
> wrote:
>
>> Did it! Also I added support for emscripten in wgpu/wgpu-native, and soon
>> it will be possible to use it with SDL/gflw. Want to add tutorial about it.
>>
>> This article is about linking Vangers (1998) and vange-rs (wgpu renderer)
>>
>> https://caiiiycuk.medium.com/vangers-3d-example-of-using-emscripten-in-rust-720ee8099d72
>>
>> чт, 27 янв. 2022 г. в 18:16, 'Ingvar Stepanyan' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com>:
>>
>>> Ah sorry, I see you tried and said it doesn't work even with `extern
>>> "C"` in the issue description. That's odd, it definitely should.
>>>
>>> On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan 
>>> wrote:
>>>
 But it's not a bug. As I said, you just need to add "C" to your
 `extern`, because right now you're exposing it from Rust via C FFI, but
 declaring it as a C++ symbol on the other side.

 On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
 wrote:

> Filled this bug:
> https://github.com/emscripten-core/emscripten/issues/16123
>
> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss
> :
>
>> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++
>> side, otherwise normal mangling rules apply and it's looking up (or, this
>> case, declaring) a namespaced variable.
>>
>> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>>
>>> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to
>>> a rust variable?  Does that address of `rv_api_1` on the C side look
>>> correct?
>>>
>>> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
>>> initializer function or is it simply static memory (like it would be in
>>> C/C++)?
>>>
>>> Assuming it is generating a ctor then there are a couple of things
>>> that could be going on.   Are you sure your static ctors have been run?
>>> i.e. where is your code running?  Is it inside of main?
>>>  Disassembling your final binary should show all static ctors being 
>>> called
>>> from the `__wasm_call_ctors` function.
>>>
>>> cheers,
>>> sam
>>>
>>>
>>> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов <
>>> caii...@gmail.com> wrote:
>>>
 Okay, I think I almost did the same in Rust what Alon described.
 vanger-rs now compiles as static library (.a) with emscripten triple. 
 I use
 this static library to link with original C++ game. So I have *.o files
 from vangers, and librusty_vangers.a (which provides rendering on 
 wgpu). I
 link them with emcc, and it produce wasm  without any error!

 Also I do the same with native build - it works fine.

 However, when I tries to run it fails with assertion.

 On RUST side I have the following code:
 #[no_mangle]
 pub static rv_api_1: i32 = 1;

 On C++ side I have the following code:
 extern int32_t rv_api_1;
 // ...
 if(rv_api_1 != 1){
 printf("Invalid libvangers_ffi version expected 1, actual
 %d\n", rv_api_1);
 // abort();
 }

 When I run it, I have following output:
 Invalid libvangers_ffi version expected 1, actual 0

 For me it looks like static initializer from RUST didn't run.
 Because if I comment the abort(); seems integration works fine. Native
 build works correctly...
 Do you have any idea why so?

 ср, 19 янв. 2022 г. в 00:36, Alon Zakai :

>
>
> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <
> caii...@gmail.com> wrote:
>
>> Let's look closer to my case. I ported C++ game Vangers to the
>> web (https://www.gamepix.com/play/vangers). Vangers community
>> did big work to integrate vange-rs (rust 3d render, based on wgpu) 
>> and
>> Vangers game. It works as follow:
>> 1. Vange-rs provide c ffi interface
>> 2. Vange-rs compiled with rust to static library
>> 3. 

Re: Rust journey

[Alon Zakai]

Wow, great that you got all that working!

I'm also interested in SDL/glfw. I was trying to get glfw working with
emscripten/rust and hit several problems, so I'm curious how you got it to
work. I filed this issue with my problems:

https://github.com/PistonDevelopers/glfw-rs/issues/495

https://github.com/PistonDevelopers/glfw-rs/issues/495

On Fri, Feb 4, 2022 at 2:46 AM Александр Гурьянов 
wrote:

> Did it! Also I added support for emscripten in wgpu/wgpu-native, and soon
> it will be possible to use it with SDL/gflw. Want to add tutorial about it.
>
> This article is about linking Vangers (1998) and vange-rs (wgpu renderer)
>
> https://caiiiycuk.medium.com/vangers-3d-example-of-using-emscripten-in-rust-720ee8099d72
>
> чт, 27 янв. 2022 г. в 18:16, 'Ingvar Stepanyan' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> Ah sorry, I see you tried and said it doesn't work even with `extern "C"`
>> in the issue description. That's odd, it definitely should.
>>
>> On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan 
>> wrote:
>>
>>> But it's not a bug. As I said, you just need to add "C" to your
>>> `extern`, because right now you're exposing it from Rust via C FFI, but
>>> declaring it as a C++ symbol on the other side.
>>>
>>> On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
>>> wrote:
>>>
 Filled this bug:
 https://github.com/emscripten-core/emscripten/issues/16123

 чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss <
 emscripten-discuss@googlegroups.com>:

> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++
> side, otherwise normal mangling rules apply and it's looking up (or, this
> case, declaring) a namespaced variable.
>
> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>
>> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to
>> a rust variable?  Does that address of `rv_api_1` on the C side look
>> correct?
>>
>> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
>> initializer function or is it simply static memory (like it would be in
>> C/C++)?
>>
>> Assuming it is generating a ctor then there are a couple of things
>> that could be going on.   Are you sure your static ctors have been run?
>> i.e. where is your code running?  Is it inside of main?
>>  Disassembling your final binary should show all static ctors being 
>> called
>> from the `__wasm_call_ctors` function.
>>
>> cheers,
>> sam
>>
>>
>> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов <
>> caii...@gmail.com> wrote:
>>
>>> Okay, I think I almost did the same in Rust what Alon described.
>>> vanger-rs now compiles as static library (.a) with emscripten triple. I 
>>> use
>>> this static library to link with original C++ game. So I have *.o files
>>> from vangers, and librusty_vangers.a (which provides rendering on 
>>> wgpu). I
>>> link them with emcc, and it produce wasm  without any error!
>>>
>>> Also I do the same with native build - it works fine.
>>>
>>> However, when I tries to run it fails with assertion.
>>>
>>> On RUST side I have the following code:
>>> #[no_mangle]
>>> pub static rv_api_1: i32 = 1;
>>>
>>> On C++ side I have the following code:
>>> extern int32_t rv_api_1;
>>> // ...
>>> if(rv_api_1 != 1){
>>> printf("Invalid libvangers_ffi version expected 1, actual
>>> %d\n", rv_api_1);
>>> // abort();
>>> }
>>>
>>> When I run it, I have following output:
>>> Invalid libvangers_ffi version expected 1, actual 0
>>>
>>> For me it looks like static initializer from RUST didn't run.
>>> Because if I comment the abort(); seems integration works fine. Native
>>> build works correctly...
>>> Do you have any idea why so?
>>>
>>> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>>>


 On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <
 caii...@gmail.com> wrote:

> Let's look closer to my case. I ported C++ game Vangers to the web
> (https://www.gamepix.com/play/vangers). Vangers community did big
> work to integrate vange-rs (rust 3d render, based on wgpu) and Vangers
> game. It works as follow:
> 1. Vange-rs provide c ffi interface
> 2. Vange-rs compiled with rust to static library
> 3. Vangers linked with Vanger-rs to executable
>
> Now I want to port  vangers + (vange-rs render) to the web. wgpu
> didn't support wasm32-unknown-emscripten, I added experimental 
> support for
> emscripten and it works. BUT, wgpu is developing to fast, so my 
> changes
> become outdated very fast :)
>
> When I implement support for emscripten, I only disabling
> wasm32-unknown rules and uses 

Re: Rust journey

[Александр Гурьянов]

Did it! Also I added support for emscripten in wgpu/wgpu-native, and soon
it will be possible to use it with SDL/gflw. Want to add tutorial about it.

This article is about linking Vangers (1998) and vange-rs (wgpu renderer)
https://caiiiycuk.medium.com/vangers-3d-example-of-using-emscripten-in-rust-720ee8099d72

чт, 27 янв. 2022 г. в 18:16, 'Ingvar Stepanyan' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> Ah sorry, I see you tried and said it doesn't work even with `extern "C"`
> in the issue description. That's odd, it definitely should.
>
> On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan 
> wrote:
>
>> But it's not a bug. As I said, you just need to add "C" to your `extern`,
>> because right now you're exposing it from Rust via C FFI, but declaring it
>> as a C++ symbol on the other side.
>>
>> On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
>> wrote:
>>
>>> Filled this bug:
>>> https://github.com/emscripten-core/emscripten/issues/16123
>>>
>>> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com>:
>>>
 I think it should be `extern *"C"* int32_t rv_api_1;` on the C++ side,
 otherwise normal mangling rules apply and it's looking up (or, this case,
 declaring) a namespaced variable.

 On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:

> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a
> rust variable?  Does that address of `rv_api_1` on the C side look 
> correct?
>
> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
> initializer function or is it simply static memory (like it would be in
> C/C++)?
>
> Assuming it is generating a ctor then there are a couple of things
> that could be going on.   Are you sure your static ctors have been run?
> i.e. where is your code running?  Is it inside of main?
>  Disassembling your final binary should show all static ctors being called
> from the `__wasm_call_ctors` function.
>
> cheers,
> sam
>
>
> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов 
> wrote:
>
>> Okay, I think I almost did the same in Rust what Alon described.
>> vanger-rs now compiles as static library (.a) with emscripten triple. I 
>> use
>> this static library to link with original C++ game. So I have *.o files
>> from vangers, and librusty_vangers.a (which provides rendering on wgpu). 
>> I
>> link them with emcc, and it produce wasm  without any error!
>>
>> Also I do the same with native build - it works fine.
>>
>> However, when I tries to run it fails with assertion.
>>
>> On RUST side I have the following code:
>> #[no_mangle]
>> pub static rv_api_1: i32 = 1;
>>
>> On C++ side I have the following code:
>> extern int32_t rv_api_1;
>> // ...
>> if(rv_api_1 != 1){
>> printf("Invalid libvangers_ffi version expected 1, actual
>> %d\n", rv_api_1);
>> // abort();
>> }
>>
>> When I run it, I have following output:
>> Invalid libvangers_ffi version expected 1, actual 0
>>
>> For me it looks like static initializer from RUST didn't run. Because
>> if I comment the abort(); seems integration works fine. Native build 
>> works
>> correctly...
>> Do you have any idea why so?
>>
>> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>>
>>>
>>>
>>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <
>>> caii...@gmail.com> wrote:
>>>
 Let's look closer to my case. I ported C++ game Vangers to the web (
 https://www.gamepix.com/play/vangers). Vangers community did big
 work to integrate vange-rs (rust 3d render, based on wgpu) and Vangers
 game. It works as follow:
 1. Vange-rs provide c ffi interface
 2. Vange-rs compiled with rust to static library
 3. Vangers linked with Vanger-rs to executable

 Now I want to port  vangers + (vange-rs render) to the web. wgpu
 didn't support wasm32-unknown-emscripten, I added experimental support 
 for
 emscripten and it works. BUT, wgpu is developing to fast, so my changes
 become outdated very fast :)

 When I implement support for emscripten, I only disabling
 wasm32-unknown rules and uses native code paths everywhere. So, it's 
 little
 bit strange, to work with emscripten you need to disable workarounds 
 for
 wasm32. emscripten emulates native platform, so code that correctly 
 uses
 posix system should work also in emscripten.

 Maybe there is any way to just use native static library and link
 it with emscripten? Like this:
 1. Compile vange-rs static library (with native triple)
 2. Compile vangers project with emscripten
 3. Link 

Re: Rust journey

['Ingvar Stepanyan' via emscripten-discuss]

Ah sorry, I see you tried and said it doesn't work even with `extern "C"`
in the issue description. That's odd, it definitely should.

On Thu, 27 Jan 2022 at 11:11, Ingvar Stepanyan  wrote:

> But it's not a bug. As I said, you just need to add "C" to your `extern`,
> because right now you're exposing it from Rust via C FFI, but declaring it
> as a C++ symbol on the other side.
>
> On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
> wrote:
>
>> Filled this bug:
>> https://github.com/emscripten-core/emscripten/issues/16123
>>
>> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com>:
>>
>>> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++ side,
>>> otherwise normal mangling rules apply and it's looking up (or, this case,
>>> declaring) a namespaced variable.
>>>
>>> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>>>
 Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a
 rust variable?  Does that address of `rv_api_1` on the C side look correct?

 Does `pub static rv_api_1: i32 = 1;` in rust generate a static
 initializer function or is it simply static memory (like it would be in
 C/C++)?

 Assuming it is generating a ctor then there are a couple of things that
 could be going on.   Are you sure your static ctors have been run?  i.e.
 where is your code running?  Is it inside of main?   Disassembling your
 final binary should show all static ctors being called from the
 `__wasm_call_ctors` function.

 cheers,
 sam


 On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов 
 wrote:

> Okay, I think I almost did the same in Rust what Alon described.
> vanger-rs now compiles as static library (.a) with emscripten triple. I 
> use
> this static library to link with original C++ game. So I have *.o files
> from vangers, and librusty_vangers.a (which provides rendering on wgpu). I
> link them with emcc, and it produce wasm  without any error!
>
> Also I do the same with native build - it works fine.
>
> However, when I tries to run it fails with assertion.
>
> On RUST side I have the following code:
> #[no_mangle]
> pub static rv_api_1: i32 = 1;
>
> On C++ side I have the following code:
> extern int32_t rv_api_1;
> // ...
> if(rv_api_1 != 1){
> printf("Invalid libvangers_ffi version expected 1, actual
> %d\n", rv_api_1);
> // abort();
> }
>
> When I run it, I have following output:
> Invalid libvangers_ffi version expected 1, actual 0
>
> For me it looks like static initializer from RUST didn't run. Because
> if I comment the abort(); seems integration works fine. Native build works
> correctly...
> Do you have any idea why so?
>
> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>
>>
>>
>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <
>> caii...@gmail.com> wrote:
>>
>>> Let's look closer to my case. I ported C++ game Vangers to the web (
>>> https://www.gamepix.com/play/vangers). Vangers community did big
>>> work to integrate vange-rs (rust 3d render, based on wgpu) and Vangers
>>> game. It works as follow:
>>> 1. Vange-rs provide c ffi interface
>>> 2. Vange-rs compiled with rust to static library
>>> 3. Vangers linked with Vanger-rs to executable
>>>
>>> Now I want to port  vangers + (vange-rs render) to the web. wgpu
>>> didn't support wasm32-unknown-emscripten, I added experimental support 
>>> for
>>> emscripten and it works. BUT, wgpu is developing to fast, so my changes
>>> become outdated very fast :)
>>>
>>> When I implement support for emscripten, I only disabling
>>> wasm32-unknown rules and uses native code paths everywhere. So, it's 
>>> little
>>> bit strange, to work with emscripten you need to disable workarounds for
>>> wasm32. emscripten emulates native platform, so code that correctly uses
>>> posix system should work also in emscripten.
>>>
>>> Maybe there is any way to just use native static library and link it
>>> with emscripten? Like this:
>>> 1. Compile vange-rs static library (with native triple)
>>> 2. Compile vangers project with emscripten
>>> 3. Link 1+2 with emscripten
>>>
>>>
>> (1) would compile to x86, though, I think? We have to have wasm to
>> link with emscripten.
>>
>>
>>> for (1.) I can't use emscripten triple because of #[cfg] rules for
>>> wasm32 target, they select wrong code path (non-native).
>>>
>>>
>> Hmm, I don't know enough rust to know what fixing that would mean...
>>
>> Overall for an emscripten port I think we would want to use a native
>> build as much as possible? That is, ideally you would *not* use
>> vange-rs/WebGPU, but one of the 

Re: Rust journey

['Ingvar Stepanyan' via emscripten-discuss]

But it's not a bug. As I said, you just need to add "C" to your `extern`,
because right now you're exposing it from Rust via C FFI, but declaring it
as a C++ symbol on the other side.

On Thu, 27 Jan 2022 at 02:32, Александр Гурьянов 
wrote:

> Filled this bug:
> https://github.com/emscripten-core/emscripten/issues/16123
>
> чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++ side,
>> otherwise normal mangling rules apply and it's looking up (or, this case,
>> declaring) a namespaced variable.
>>
>> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>>
>>> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a
>>> rust variable?  Does that address of `rv_api_1` on the C side look correct?
>>>
>>> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
>>> initializer function or is it simply static memory (like it would be in
>>> C/C++)?
>>>
>>> Assuming it is generating a ctor then there are a couple of things that
>>> could be going on.   Are you sure your static ctors have been run?  i.e.
>>> where is your code running?  Is it inside of main?   Disassembling your
>>> final binary should show all static ctors being called from the
>>> `__wasm_call_ctors` function.
>>>
>>> cheers,
>>> sam
>>>
>>>
>>> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов 
>>> wrote:
>>>
 Okay, I think I almost did the same in Rust what Alon described.
 vanger-rs now compiles as static library (.a) with emscripten triple. I use
 this static library to link with original C++ game. So I have *.o files
 from vangers, and librusty_vangers.a (which provides rendering on wgpu). I
 link them with emcc, and it produce wasm  without any error!

 Also I do the same with native build - it works fine.

 However, when I tries to run it fails with assertion.

 On RUST side I have the following code:
 #[no_mangle]
 pub static rv_api_1: i32 = 1;

 On C++ side I have the following code:
 extern int32_t rv_api_1;
 // ...
 if(rv_api_1 != 1){
 printf("Invalid libvangers_ffi version expected 1, actual
 %d\n", rv_api_1);
 // abort();
 }

 When I run it, I have following output:
 Invalid libvangers_ffi version expected 1, actual 0

 For me it looks like static initializer from RUST didn't run. Because
 if I comment the abort(); seems integration works fine. Native build works
 correctly...
 Do you have any idea why so?

 ср, 19 янв. 2022 г. в 00:36, Alon Zakai :

>
>
> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов 
> wrote:
>
>> Let's look closer to my case. I ported C++ game Vangers to the web (
>> https://www.gamepix.com/play/vangers). Vangers community did big
>> work to integrate vange-rs (rust 3d render, based on wgpu) and Vangers
>> game. It works as follow:
>> 1. Vange-rs provide c ffi interface
>> 2. Vange-rs compiled with rust to static library
>> 3. Vangers linked with Vanger-rs to executable
>>
>> Now I want to port  vangers + (vange-rs render) to the web. wgpu
>> didn't support wasm32-unknown-emscripten, I added experimental support 
>> for
>> emscripten and it works. BUT, wgpu is developing to fast, so my changes
>> become outdated very fast :)
>>
>> When I implement support for emscripten, I only disabling
>> wasm32-unknown rules and uses native code paths everywhere. So, it's 
>> little
>> bit strange, to work with emscripten you need to disable workarounds for
>> wasm32. emscripten emulates native platform, so code that correctly uses
>> posix system should work also in emscripten.
>>
>> Maybe there is any way to just use native static library and link it
>> with emscripten? Like this:
>> 1. Compile vange-rs static library (with native triple)
>> 2. Compile vangers project with emscripten
>> 3. Link 1+2 with emscripten
>>
>>
> (1) would compile to x86, though, I think? We have to have wasm to
> link with emscripten.
>
>
>> for (1.) I can't use emscripten triple because of #[cfg] rules for
>> wasm32 target, they select wrong code path (non-native).
>>
>>
> Hmm, I don't know enough rust to know what fixing that would mean...
>
> Overall for an emscripten port I think we would want to use a native
> build as much as possible? That is, ideally you would *not* use
> vange-rs/WebGPU, but one of the native rendering paths (OpenGL of some
> flavor? Or perhaps they have Dawn/WebGPU support?). And you would need to
> tell rust to use the emscripten triple while doing so.
>
> That should work, in theory. If it doesn't and Rust has some issues
> with how it invokes emcc to link, then the workaround could be what I
> 

Re: Rust journey

[Александр Гурьянов]

Filled this bug: https://github.com/emscripten-core/emscripten/issues/16123

чт, 27 янв. 2022 г. в 02:42, 'Ingvar Stepanyan' via emscripten-discuss <
emscripten-discuss@googlegroups.com>:

> I think it should be `extern *"C"* int32_t rv_api_1;` on the C++ side,
> otherwise normal mangling rules apply and it's looking up (or, this case,
> declaring) a namespaced variable.
>
> On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:
>
>> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a
>> rust variable?  Does that address of `rv_api_1` on the C side look correct?
>>
>> Does `pub static rv_api_1: i32 = 1;` in rust generate a static
>> initializer function or is it simply static memory (like it would be in
>> C/C++)?
>>
>> Assuming it is generating a ctor then there are a couple of things that
>> could be going on.   Are you sure your static ctors have been run?  i.e.
>> where is your code running?  Is it inside of main?   Disassembling your
>> final binary should show all static ctors being called from the
>> `__wasm_call_ctors` function.
>>
>> cheers,
>> sam
>>
>>
>> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов 
>> wrote:
>>
>>> Okay, I think I almost did the same in Rust what Alon described.
>>> vanger-rs now compiles as static library (.a) with emscripten triple. I use
>>> this static library to link with original C++ game. So I have *.o files
>>> from vangers, and librusty_vangers.a (which provides rendering on wgpu). I
>>> link them with emcc, and it produce wasm  without any error!
>>>
>>> Also I do the same with native build - it works fine.
>>>
>>> However, when I tries to run it fails with assertion.
>>>
>>> On RUST side I have the following code:
>>> #[no_mangle]
>>> pub static rv_api_1: i32 = 1;
>>>
>>> On C++ side I have the following code:
>>> extern int32_t rv_api_1;
>>> // ...
>>> if(rv_api_1 != 1){
>>> printf("Invalid libvangers_ffi version expected 1, actual %d\n",
>>> rv_api_1);
>>> // abort();
>>> }
>>>
>>> When I run it, I have following output:
>>> Invalid libvangers_ffi version expected 1, actual 0
>>>
>>> For me it looks like static initializer from RUST didn't run. Because if
>>> I comment the abort(); seems integration works fine. Native build works
>>> correctly...
>>> Do you have any idea why so?
>>>
>>> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>>>


 On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов 
 wrote:

> Let's look closer to my case. I ported C++ game Vangers to the web (
> https://www.gamepix.com/play/vangers). Vangers community did big work
> to integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It
> works as follow:
> 1. Vange-rs provide c ffi interface
> 2. Vange-rs compiled with rust to static library
> 3. Vangers linked with Vanger-rs to executable
>
> Now I want to port  vangers + (vange-rs render) to the web. wgpu
> didn't support wasm32-unknown-emscripten, I added experimental support for
> emscripten and it works. BUT, wgpu is developing to fast, so my changes
> become outdated very fast :)
>
> When I implement support for emscripten, I only disabling
> wasm32-unknown rules and uses native code paths everywhere. So, it's 
> little
> bit strange, to work with emscripten you need to disable workarounds for
> wasm32. emscripten emulates native platform, so code that correctly uses
> posix system should work also in emscripten.
>
> Maybe there is any way to just use native static library and link it
> with emscripten? Like this:
> 1. Compile vange-rs static library (with native triple)
> 2. Compile vangers project with emscripten
> 3. Link 1+2 with emscripten
>
>
 (1) would compile to x86, though, I think? We have to have wasm to link
 with emscripten.


> for (1.) I can't use emscripten triple because of #[cfg] rules for
> wasm32 target, they select wrong code path (non-native).
>
>
 Hmm, I don't know enough rust to know what fixing that would mean...

 Overall for an emscripten port I think we would want to use a native
 build as much as possible? That is, ideally you would *not* use
 vange-rs/WebGPU, but one of the native rendering paths (OpenGL of some
 flavor? Or perhaps they have Dawn/WebGPU support?). And you would need to
 tell rust to use the emscripten triple while doing so.

 That should work, in theory. If it doesn't and Rust has some issues
 with how it invokes emcc to link, then the workaround could be what I
 mentioned for Zig and C before: get Rust to link to a static library, and
 then run emcc manually on that.

 (Alternatively, in theory someone could look into supporting
 wasm-bindgen + emscripten.)

 - Alon


> пт, 14 янв. 2022 г. в 07:54, Alon Zakai :
>
>> Thanks, good to know at least 2 people would read a post about this

Re: Rust journey

['Ingvar Stepanyan' via emscripten-discuss]

I think it should be `extern *"C"* int32_t rv_api_1;` on the C++ side, 
otherwise normal mangling rules apply and it's looking up (or, this case, 
declaring) a namespaced variable.

On Wednesday, 26 January 2022 at 19:31:18 UTC s...@google.com wrote:

> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a 
> rust variable?  Does that address of `rv_api_1` on the C side look correct?
>
> Does `pub static rv_api_1: i32 = 1;` in rust generate a static initializer 
> function or is it simply static memory (like it would be in C/C++)?
>
> Assuming it is generating a ctor then there are a couple of things that 
> could be going on.   Are you sure your static ctors have been run?  i.e. 
> where is your code running?  Is it inside of main?   Disassembling your 
> final binary should show all static ctors being called from the 
> `__wasm_call_ctors` function.
>
> cheers,
> sam
>
>
> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов  
> wrote:
>
>> Okay, I think I almost did the same in Rust what Alon described. 
>> vanger-rs now compiles as static library (.a) with emscripten triple. I use 
>> this static library to link with original C++ game. So I have *.o files 
>> from vangers, and librusty_vangers.a (which provides rendering on wgpu). I 
>> link them with emcc, and it produce wasm  without any error!
>>
>> Also I do the same with native build - it works fine.
>>
>> However, when I tries to run it fails with assertion. 
>>
>> On RUST side I have the following code:
>> #[no_mangle]
>> pub static rv_api_1: i32 = 1;
>>
>> On C++ side I have the following code:
>> extern int32_t rv_api_1;
>> // ...
>> if(rv_api_1 != 1){
>> printf("Invalid libvangers_ffi version expected 1, actual %d\n", 
>> rv_api_1);
>> // abort();
>> }
>>
>> When I run it, I have following output:
>> Invalid libvangers_ffi version expected 1, actual 0
>>
>> For me it looks like static initializer from RUST didn't run. Because if 
>> I comment the abort(); seems integration works fine. Native build works 
>> correctly...
>> Do you have any idea why so?
>>
>> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>>
>>>
>>>
>>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов  
>>> wrote:
>>>
 Let's look closer to my case. I ported C++ game Vangers to the web (
 https://www.gamepix.com/play/vangers). Vangers community did big work 
 to integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It 
 works as follow: 
 1. Vange-rs provide c ffi interface
 2. Vange-rs compiled with rust to static library
 3. Vangers linked with Vanger-rs to executable

 Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't 
 support wasm32-unknown-emscripten, I added experimental support for 
 emscripten and it works. BUT, wgpu is developing to fast, so my changes 
 become outdated very fast :) 

 When I implement support for emscripten, I only disabling 
 wasm32-unknown rules and uses native code paths everywhere. So, it's 
 little 
 bit strange, to work with emscripten you need to disable workarounds for 
 wasm32. emscripten emulates native platform, so code that correctly uses 
 posix system should work also in emscripten.

 Maybe there is any way to just use native static library and link it 
 with emscripten? Like this:
 1. Compile vange-rs static library (with native triple)
 2. Compile vangers project with emscripten
 3. Link 1+2 with emscripten 


>>> (1) would compile to x86, though, I think? We have to have wasm to link 
>>> with emscripten.
>>>  
>>>
 for (1.) I can't use emscripten triple because of #[cfg] rules for 
 wasm32 target, they select wrong code path (non-native).


>>> Hmm, I don't know enough rust to know what fixing that would mean...
>>>
>>> Overall for an emscripten port I think we would want to use a native 
>>> build as much as possible? That is, ideally you would *not* use 
>>> vange-rs/WebGPU, but one of the native rendering paths (OpenGL of some 
>>> flavor? Or perhaps they have Dawn/WebGPU support?). And you would need to 
>>> tell rust to use the emscripten triple while doing so.
>>>
>>> That should work, in theory. If it doesn't and Rust has some issues with 
>>> how it invokes emcc to link, then the workaround could be what I mentioned 
>>> for Zig and C before: get Rust to link to a static library, and then run 
>>> emcc manually on that.
>>>
>>> (Alternatively, in theory someone could look into supporting 
>>> wasm-bindgen + emscripten.)
>>>
>>> - Alon
>>>  
>>>
 пт, 14 янв. 2022 г. в 07:54, Alon Zakai :

> Thanks, good to know at least 2 people would read a post about this :) 
> I'll try to find time for it.
>
> About Rust, I haven't had time to look into it yet. My general hope is 
> that the same model as for C and Zig could work:
>
> 1. Tell Rust to use the emscripten wasm triple.
> 2. Tell Rust to compile to 

Re: Rust journey

['Sam Clegg' via emscripten-discuss]

Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a rust
variable?  Does that address of `rv_api_1` on the C side look correct?

Does `pub static rv_api_1: i32 = 1;` in rust generate a static initializer
function or is it simply static memory (like it would be in C/C++)?

Assuming it is generating a ctor then there are a couple of things that
could be going on.   Are you sure your static ctors have been run?  i.e.
where is your code running?  Is it inside of main?   Disassembling your
final binary should show all static ctors being called from the
`__wasm_call_ctors` function.

cheers,
sam


On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов 
wrote:

> Okay, I think I almost did the same in Rust what Alon described. vanger-rs
> now compiles as static library (.a) with emscripten triple. I use this
> static library to link with original C++ game. So I have *.o files from
> vangers, and librusty_vangers.a (which provides rendering on wgpu). I link
> them with emcc, and it produce wasm  without any error!
>
> Also I do the same with native build - it works fine.
>
> However, when I tries to run it fails with assertion.
>
> On RUST side I have the following code:
> #[no_mangle]
> pub static rv_api_1: i32 = 1;
>
> On C++ side I have the following code:
> extern int32_t rv_api_1;
> // ...
> if(rv_api_1 != 1){
> printf("Invalid libvangers_ffi version expected 1, actual %d\n",
> rv_api_1);
> // abort();
> }
>
> When I run it, I have following output:
> Invalid libvangers_ffi version expected 1, actual 0
>
> For me it looks like static initializer from RUST didn't run. Because if I
> comment the abort(); seems integration works fine. Native build works
> correctly...
> Do you have any idea why so?
>
> ср, 19 янв. 2022 г. в 00:36, Alon Zakai :
>
>>
>>
>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов 
>> wrote:
>>
>>> Let's look closer to my case. I ported C++ game Vangers to the web (
>>> https://www.gamepix.com/play/vangers). Vangers community did big work
>>> to integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It
>>> works as follow:
>>> 1. Vange-rs provide c ffi interface
>>> 2. Vange-rs compiled with rust to static library
>>> 3. Vangers linked with Vanger-rs to executable
>>>
>>> Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't
>>> support wasm32-unknown-emscripten, I added experimental support for
>>> emscripten and it works. BUT, wgpu is developing to fast, so my changes
>>> become outdated very fast :)
>>>
>>> When I implement support for emscripten, I only disabling wasm32-unknown
>>> rules and uses native code paths everywhere. So, it's little bit strange,
>>> to work with emscripten you need to disable workarounds for wasm32.
>>> emscripten emulates native platform, so code that correctly uses posix
>>> system should work also in emscripten.
>>>
>>> Maybe there is any way to just use native static library and link it
>>> with emscripten? Like this:
>>> 1. Compile vange-rs static library (with native triple)
>>> 2. Compile vangers project with emscripten
>>> 3. Link 1+2 with emscripten
>>>
>>>
>> (1) would compile to x86, though, I think? We have to have wasm to link
>> with emscripten.
>>
>>
>>> for (1.) I can't use emscripten triple because of #[cfg] rules for
>>> wasm32 target, they select wrong code path (non-native).
>>>
>>>
>> Hmm, I don't know enough rust to know what fixing that would mean...
>>
>> Overall for an emscripten port I think we would want to use a native
>> build as much as possible? That is, ideally you would *not* use
>> vange-rs/WebGPU, but one of the native rendering paths (OpenGL of some
>> flavor? Or perhaps they have Dawn/WebGPU support?). And you would need to
>> tell rust to use the emscripten triple while doing so.
>>
>> That should work, in theory. If it doesn't and Rust has some issues with
>> how it invokes emcc to link, then the workaround could be what I mentioned
>> for Zig and C before: get Rust to link to a static library, and then run
>> emcc manually on that.
>>
>> (Alternatively, in theory someone could look into supporting wasm-bindgen
>> + emscripten.)
>>
>> - Alon
>>
>>
>>> пт, 14 янв. 2022 г. в 07:54, Alon Zakai :
>>>
 Thanks, good to know at least 2 people would read a post about this :)
 I'll try to find time for it.

 About Rust, I haven't had time to look into it yet. My general hope is
 that the same model as for C and Zig could work:

 1. Tell Rust to use the emscripten wasm triple.
 2. Tell Rust to compile to object files (or a static library,
 basically), and *not* to link them.
 3. The user runs emcc on those object files, linking them.

 The nice thing in this model is that C/Zig/Rust does not need to be
 aware of emcc at all here (aside from telling LLVM to use the emscripten
 triple). And it's easy to do this, at least in C and Zig (although there
 are some subtle ABI questions).

 This is actually 

Re: Rust journey

[Александр Гурьянов]

Okay, I think I almost did the same in Rust what Alon described. vanger-rs
now compiles as static library (.a) with emscripten triple. I use this
static library to link with original C++ game. So I have *.o files from
vangers, and librusty_vangers.a (which provides rendering on wgpu). I link
them with emcc, and it produce wasm  without any error!

Also I do the same with native build - it works fine.

However, when I tries to run it fails with assertion.

On RUST side I have the following code:
#[no_mangle]
pub static rv_api_1: i32 = 1;

On C++ side I have the following code:
extern int32_t rv_api_1;
// ...
if(rv_api_1 != 1){
printf("Invalid libvangers_ffi version expected 1, actual %d\n",
rv_api_1);
// abort();
}

When I run it, I have following output:
Invalid libvangers_ffi version expected 1, actual 0

For me it looks like static initializer from RUST didn't run. Because if I
comment the abort(); seems integration works fine. Native build works
correctly...
Do you have any idea why so?

ср, 19 янв. 2022 г. в 00:36, Alon Zakai :

>
>
> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов 
> wrote:
>
>> Let's look closer to my case. I ported C++ game Vangers to the web (
>> https://www.gamepix.com/play/vangers). Vangers community did big work to
>> integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It
>> works as follow:
>> 1. Vange-rs provide c ffi interface
>> 2. Vange-rs compiled with rust to static library
>> 3. Vangers linked with Vanger-rs to executable
>>
>> Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't
>> support wasm32-unknown-emscripten, I added experimental support for
>> emscripten and it works. BUT, wgpu is developing to fast, so my changes
>> become outdated very fast :)
>>
>> When I implement support for emscripten, I only disabling wasm32-unknown
>> rules and uses native code paths everywhere. So, it's little bit strange,
>> to work with emscripten you need to disable workarounds for wasm32.
>> emscripten emulates native platform, so code that correctly uses posix
>> system should work also in emscripten.
>>
>> Maybe there is any way to just use native static library and link it with
>> emscripten? Like this:
>> 1. Compile vange-rs static library (with native triple)
>> 2. Compile vangers project with emscripten
>> 3. Link 1+2 with emscripten
>>
>>
> (1) would compile to x86, though, I think? We have to have wasm to link
> with emscripten.
>
>
>> for (1.) I can't use emscripten triple because of #[cfg] rules for wasm32
>> target, they select wrong code path (non-native).
>>
>>
> Hmm, I don't know enough rust to know what fixing that would mean...
>
> Overall for an emscripten port I think we would want to use a native build
> as much as possible? That is, ideally you would *not* use vange-rs/WebGPU,
> but one of the native rendering paths (OpenGL of some flavor? Or perhaps
> they have Dawn/WebGPU support?). And you would need to tell rust to use the
> emscripten triple while doing so.
>
> That should work, in theory. If it doesn't and Rust has some issues with
> how it invokes emcc to link, then the workaround could be what I mentioned
> for Zig and C before: get Rust to link to a static library, and then run
> emcc manually on that.
>
> (Alternatively, in theory someone could look into supporting wasm-bindgen
> + emscripten.)
>
> - Alon
>
>
>> пт, 14 янв. 2022 г. в 07:54, Alon Zakai :
>>
>>> Thanks, good to know at least 2 people would read a post about this :)
>>> I'll try to find time for it.
>>>
>>> About Rust, I haven't had time to look into it yet. My general hope is
>>> that the same model as for C and Zig could work:
>>>
>>> 1. Tell Rust to use the emscripten wasm triple.
>>> 2. Tell Rust to compile to object files (or a static library,
>>> basically), and *not* to link them.
>>> 3. The user runs emcc on those object files, linking them.
>>>
>>> The nice thing in this model is that C/Zig/Rust does not need to be
>>> aware of emcc at all here (aside from telling LLVM to use the emscripten
>>> triple). And it's easy to do this, at least in C and Zig (although there
>>> are some subtle ABI questions).
>>>
>>> This is actually the main thing I wanted to do before writing the post -
>>> ideally I'd have a Rust demo alongside C and Zig - so if someone figures
>>> that out, let me know!
>>>
>>> - Alon
>>>
>>>
>>> On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов 
>>> wrote:
>>>
 +1 for blog post. Not clear how I can use it with rust, e.g. can I
 compile static lib with target --wasm32-unknown-unknown and then link using
 emscripten? The main problem with RUST is that it even can't compile with
 --wasm32-unknown-emscipten (because of lib dependencies that not support
 emscripten)

 чт, 13 янв. 2022 г. в 16:46, Floh :

> That's a very useful gist, Alon! I think that blog post would be much
> appreciated by a lot of people who like to tinker with other languages :)
>
> On Wednesday, 

Re: Rust journey

[Alon Zakai]

On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов 
wrote:

> Let's look closer to my case. I ported C++ game Vangers to the web (
> https://www.gamepix.com/play/vangers). Vangers community did big work to
> integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It
> works as follow:
> 1. Vange-rs provide c ffi interface
> 2. Vange-rs compiled with rust to static library
> 3. Vangers linked with Vanger-rs to executable
>
> Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't
> support wasm32-unknown-emscripten, I added experimental support for
> emscripten and it works. BUT, wgpu is developing to fast, so my changes
> become outdated very fast :)
>
> When I implement support for emscripten, I only disabling wasm32-unknown
> rules and uses native code paths everywhere. So, it's little bit strange,
> to work with emscripten you need to disable workarounds for wasm32.
> emscripten emulates native platform, so code that correctly uses posix
> system should work also in emscripten.
>
> Maybe there is any way to just use native static library and link it with
> emscripten? Like this:
> 1. Compile vange-rs static library (with native triple)
> 2. Compile vangers project with emscripten
> 3. Link 1+2 with emscripten
>
>
(1) would compile to x86, though, I think? We have to have wasm to link
with emscripten.


> for (1.) I can't use emscripten triple because of #[cfg] rules for wasm32
> target, they select wrong code path (non-native).
>
>
Hmm, I don't know enough rust to know what fixing that would mean...

Overall for an emscripten port I think we would want to use a native build
as much as possible? That is, ideally you would *not* use vange-rs/WebGPU,
but one of the native rendering paths (OpenGL of some flavor? Or perhaps
they have Dawn/WebGPU support?). And you would need to tell rust to use the
emscripten triple while doing so.

That should work, in theory. If it doesn't and Rust has some issues with
how it invokes emcc to link, then the workaround could be what I mentioned
for Zig and C before: get Rust to link to a static library, and then run
emcc manually on that.

(Alternatively, in theory someone could look into supporting wasm-bindgen +
emscripten.)

- Alon


> пт, 14 янв. 2022 г. в 07:54, Alon Zakai :
>
>> Thanks, good to know at least 2 people would read a post about this :)
>> I'll try to find time for it.
>>
>> About Rust, I haven't had time to look into it yet. My general hope is
>> that the same model as for C and Zig could work:
>>
>> 1. Tell Rust to use the emscripten wasm triple.
>> 2. Tell Rust to compile to object files (or a static library, basically),
>> and *not* to link them.
>> 3. The user runs emcc on those object files, linking them.
>>
>> The nice thing in this model is that C/Zig/Rust does not need to be aware
>> of emcc at all here (aside from telling LLVM to use the emscripten triple).
>> And it's easy to do this, at least in C and Zig (although there are some
>> subtle ABI questions).
>>
>> This is actually the main thing I wanted to do before writing the post -
>> ideally I'd have a Rust demo alongside C and Zig - so if someone figures
>> that out, let me know!
>>
>> - Alon
>>
>>
>> On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов 
>> wrote:
>>
>>> +1 for blog post. Not clear how I can use it with rust, e.g. can I
>>> compile static lib with target --wasm32-unknown-unknown and then link using
>>> emscripten? The main problem with RUST is that it even can't compile with
>>> --wasm32-unknown-emscipten (because of lib dependencies that not support
>>> emscripten)
>>>
>>> чт, 13 янв. 2022 г. в 16:46, Floh :
>>>
 That's a very useful gist, Alon! I think that blog post would be much
 appreciated by a lot of people who like to tinker with other languages :)

 On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com
 wrote:

> On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:
>
>> Ah, language and toolchain interoperability, one of my favourite
>> topics ;)
>>
>> Zig has nearly the same problems as Rust: it allows to compile to
>> WASM, it has both a WASI and Emscripten target, with the WASI target
>> working out of the box, but I gave up on the Emscripten target because I
>> just couldn't get it to work.
>>
>
> I wrote up a demo of Zig + Emscripten here:
>
> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>
> That uses GLES3 and Asyncify from Emscripten, so it's a small program
> but it uses interesting features.
>
> The gist also shows using C in the same way, where Emscripten is just
> the linker, not the frontend.
>
> I've been meaning to do the same with Rust and write a blogpost about
> all 3 but haven't found the time...
>
> - Alon
>
>
>
>>
>> IMHO it would be great if the Javascript shims and interop could be
>> somehow split out of the Emscripten SDK into a separate, smaller

Re: Rust journey

[Александр Гурьянов]

Let's look closer to my case. I ported C++ game Vangers to the web (
https://www.gamepix.com/play/vangers). Vangers community did big work to
integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It
works as follow:
1. Vange-rs provide c ffi interface
2. Vange-rs compiled with rust to static library
3. Vangers linked with Vanger-rs to executable

Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't
support wasm32-unknown-emscripten, I added experimental support for
emscripten and it works. BUT, wgpu is developing to fast, so my changes
become outdated very fast :)

When I implement support for emscripten, I only disabling wasm32-unknown
rules and uses native code paths everywhere. So, it's little bit strange,
to work with emscripten you need to disable workarounds for wasm32.
emscripten emulates native platform, so code that correctly uses posix
system should work also in emscripten.

Maybe there is any way to just use native static library and link it with
emscripten? Like this:
1. Compile vange-rs static library (with native triple)
2. Compile vangers project with emscripten
3. Link 1+2 with emscripten

for (1.) I can't use emscripten triple because of #[cfg] rules for wasm32
target, they select wrong code path (non-native).

пт, 14 янв. 2022 г. в 07:54, Alon Zakai :

> Thanks, good to know at least 2 people would read a post about this :)
> I'll try to find time for it.
>
> About Rust, I haven't had time to look into it yet. My general hope is
> that the same model as for C and Zig could work:
>
> 1. Tell Rust to use the emscripten wasm triple.
> 2. Tell Rust to compile to object files (or a static library, basically),
> and *not* to link them.
> 3. The user runs emcc on those object files, linking them.
>
> The nice thing in this model is that C/Zig/Rust does not need to be aware
> of emcc at all here (aside from telling LLVM to use the emscripten triple).
> And it's easy to do this, at least in C and Zig (although there are some
> subtle ABI questions).
>
> This is actually the main thing I wanted to do before writing the post -
> ideally I'd have a Rust demo alongside C and Zig - so if someone figures
> that out, let me know!
>
> - Alon
>
>
> On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов 
> wrote:
>
>> +1 for blog post. Not clear how I can use it with rust, e.g. can I
>> compile static lib with target --wasm32-unknown-unknown and then link using
>> emscripten? The main problem with RUST is that it even can't compile with
>> --wasm32-unknown-emscipten (because of lib dependencies that not support
>> emscripten)
>>
>> чт, 13 янв. 2022 г. в 16:46, Floh :
>>
>>> That's a very useful gist, Alon! I think that blog post would be much
>>> appreciated by a lot of people who like to tinker with other languages :)
>>>
>>> On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote:
>>>
 On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:

> Ah, language and toolchain interoperability, one of my favourite
> topics ;)
>
> Zig has nearly the same problems as Rust: it allows to compile to
> WASM, it has both a WASI and Emscripten target, with the WASI target
> working out of the box, but I gave up on the Emscripten target because I
> just couldn't get it to work.
>

 I wrote up a demo of Zig + Emscripten here:

 https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3

 That uses GLES3 and Asyncify from Emscripten, so it's a small program
 but it uses interesting features.

 The gist also shows using C in the same way, where Emscripten is just
 the linker, not the frontend.

 I've been meaning to do the same with Rust and write a blogpost about
 all 3 but haven't found the time...

 - Alon



>
> IMHO it would be great if the Javascript shims and interop could be
> somehow split out of the Emscripten SDK into a separate, smaller
> "webapi-wasm-tools" SDK which could be better integrated with other
> language toolchains. The goal should be that other programming languages
> can benefit from the work that went into the Emscripten SDK to access web
> APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality,
> instead of having to duplicate this work, or requiring a separate
> installation of the whole Emscripten SDK.
>
> There's a very promising project https://github.com/schellingb/wajic
> by Bernhard Schelling which has the same goals and which was used to port
> Mattias Gustavsson's DOS-like library to the web:
> https://mattiasgustavsson.com/wasm/
>
> Anyway... just my 2 cents :)
> -Floh.
> On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:
>
>> Hi! Just want to share my experiment with using Rust and WebAssembly.
>> I tried to port Vange-rs project (rust + wgpu) to browser. I used
>> emscripten and unknown platforms. Both finally works, 

Re: Rust journey

[Alon Zakai]

Thanks, good to know at least 2 people would read a post about this :) I'll
try to find time for it.

About Rust, I haven't had time to look into it yet. My general hope is that
the same model as for C and Zig could work:

1. Tell Rust to use the emscripten wasm triple.
2. Tell Rust to compile to object files (or a static library, basically),
and *not* to link them.
3. The user runs emcc on those object files, linking them.

The nice thing in this model is that C/Zig/Rust does not need to be aware
of emcc at all here (aside from telling LLVM to use the emscripten triple).
And it's easy to do this, at least in C and Zig (although there are some
subtle ABI questions).

This is actually the main thing I wanted to do before writing the post -
ideally I'd have a Rust demo alongside C and Zig - so if someone figures
that out, let me know!

- Alon


On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов 
wrote:

> +1 for blog post. Not clear how I can use it with rust, e.g. can I compile
> static lib with target --wasm32-unknown-unknown and then link using
> emscripten? The main problem with RUST is that it even can't compile with
> --wasm32-unknown-emscipten (because of lib dependencies that not support
> emscripten)
>
> чт, 13 янв. 2022 г. в 16:46, Floh :
>
>> That's a very useful gist, Alon! I think that blog post would be much
>> appreciated by a lot of people who like to tinker with other languages :)
>>
>> On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote:
>>
>>> On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:
>>>
 Ah, language and toolchain interoperability, one of my favourite topics
 ;)

 Zig has nearly the same problems as Rust: it allows to compile to WASM,
 it has both a WASI and Emscripten target, with the WASI target working out
 of the box, but I gave up on the Emscripten target because I just couldn't
 get it to work.

>>>
>>> I wrote up a demo of Zig + Emscripten here:
>>>
>>> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>>>
>>> That uses GLES3 and Asyncify from Emscripten, so it's a small program
>>> but it uses interesting features.
>>>
>>> The gist also shows using C in the same way, where Emscripten is just
>>> the linker, not the frontend.
>>>
>>> I've been meaning to do the same with Rust and write a blogpost about
>>> all 3 but haven't found the time...
>>>
>>> - Alon
>>>
>>>
>>>

 IMHO it would be great if the Javascript shims and interop could be
 somehow split out of the Emscripten SDK into a separate, smaller
 "webapi-wasm-tools" SDK which could be better integrated with other
 language toolchains. The goal should be that other programming languages
 can benefit from the work that went into the Emscripten SDK to access web
 APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality,
 instead of having to duplicate this work, or requiring a separate
 installation of the whole Emscripten SDK.

 There's a very promising project https://github.com/schellingb/wajic
 by Bernhard Schelling which has the same goals and which was used to port
 Mattias Gustavsson's DOS-like library to the web:
 https://mattiasgustavsson.com/wasm/

 Anyway... just my 2 cents :)
 -Floh.
 On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:

> Hi! Just want to share my experiment with using Rust and WebAssembly.
> I tried to port Vange-rs project (rust + wgpu) to browser. I used
> emscripten and unknown platforms. Both finally works, but have lot of
> obstacles. I am very sad about support level of emscripten in Rust, hope 
> it
> will change at some day.
>
> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>
 --

>>> You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.

>>> To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/9e88b4b5-f110-4d90-a630-1c282a1febffn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the 

Re: Rust journey

[Александр Гурьянов]

+1 for blog post. Not clear how I can use it with rust, e.g. can I compile
static lib with target --wasm32-unknown-unknown and then link using
emscripten? The main problem with RUST is that it even can't compile with
--wasm32-unknown-emscipten (because of lib dependencies that not support
emscripten)

чт, 13 янв. 2022 г. в 16:46, Floh :

> That's a very useful gist, Alon! I think that blog post would be much
> appreciated by a lot of people who like to tinker with other languages :)
>
> On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote:
>
>> On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:
>>
>>> Ah, language and toolchain interoperability, one of my favourite topics
>>> ;)
>>>
>>> Zig has nearly the same problems as Rust: it allows to compile to WASM,
>>> it has both a WASI and Emscripten target, with the WASI target working out
>>> of the box, but I gave up on the Emscripten target because I just couldn't
>>> get it to work.
>>>
>>
>> I wrote up a demo of Zig + Emscripten here:
>>
>> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>>
>> That uses GLES3 and Asyncify from Emscripten, so it's a small program but
>> it uses interesting features.
>>
>> The gist also shows using C in the same way, where Emscripten is just the
>> linker, not the frontend.
>>
>> I've been meaning to do the same with Rust and write a blogpost about all
>> 3 but haven't found the time...
>>
>> - Alon
>>
>>
>>
>>>
>>> IMHO it would be great if the Javascript shims and interop could be
>>> somehow split out of the Emscripten SDK into a separate, smaller
>>> "webapi-wasm-tools" SDK which could be better integrated with other
>>> language toolchains. The goal should be that other programming languages
>>> can benefit from the work that went into the Emscripten SDK to access web
>>> APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality,
>>> instead of having to duplicate this work, or requiring a separate
>>> installation of the whole Emscripten SDK.
>>>
>>> There's a very promising project https://github.com/schellingb/wajic by
>>> Bernhard Schelling which has the same goals and which was used to port
>>> Mattias Gustavsson's DOS-like library to the web:
>>> https://mattiasgustavsson.com/wasm/
>>>
>>> Anyway... just my 2 cents :)
>>> -Floh.
>>> On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:
>>>
 Hi! Just want to share my experiment with using Rust and WebAssembly. I
 tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten
 and unknown platforms. Both finally works, but have lot of obstacles. I am
 very sad about support level of emscripten in Rust, hope it will change at
 some day.

 https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04

>>> --
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/9e88b4b5-f110-4d90-a630-1c282a1febffn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFgNcSPR-KFe35yg%2BU9NXFpG7U_Y5G0APbkZRf5UM2%2B8w%40mail.gmail.com.

Re: Rust journey

[Floh]

That's a very useful gist, Alon! I think that blog post would be much 
appreciated by a lot of people who like to tinker with other languages :)

On Wednesday, 12 January 2022 at 19:32:04 UTC+1 alon...@gmail.com wrote:

> On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:
>
>> Ah, language and toolchain interoperability, one of my favourite topics ;)
>>
>> Zig has nearly the same problems as Rust: it allows to compile to WASM, 
>> it has both a WASI and Emscripten target, with the WASI target working out 
>> of the box, but I gave up on the Emscripten target because I just couldn't 
>> get it to work.
>>
>
> I wrote up a demo of Zig + Emscripten here:
>
> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>
> That uses GLES3 and Asyncify from Emscripten, so it's a small program but 
> it uses interesting features.
>
> The gist also shows using C in the same way, where Emscripten is just the 
> linker, not the frontend.
>
> I've been meaning to do the same with Rust and write a blogpost about all 
> 3 but haven't found the time...
>
> - Alon
>
>  
>
>>
>> IMHO it would be great if the Javascript shims and interop could be 
>> somehow split out of the Emscripten SDK into a separate, smaller 
>> "webapi-wasm-tools" SDK which could be better integrated with other 
>> language toolchains. The goal should be that other programming languages 
>> can benefit from the work that went into the Emscripten SDK to access web 
>> APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality, 
>> instead of having to duplicate this work, or requiring a separate 
>> installation of the whole Emscripten SDK.
>>
>> There's a very promising project https://github.com/schellingb/wajic by 
>> Bernhard Schelling which has the same goals and which was used to port 
>> Mattias Gustavsson's DOS-like library to the web: 
>> https://mattiasgustavsson.com/wasm/
>>
>> Anyway... just my 2 cents :)
>> -Floh.
>> On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:
>>
>>> Hi! Just want to share my experiment with using Rust and WebAssembly. I 
>>> tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten 
>>> and unknown platforms. Both finally works, but have lot of obstacles. I am 
>>> very sad about support level of emscripten in Rust, hope it will change at 
>>> some day.
>>>
>>> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to emscripten-disc...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/9e88b4b5-f110-4d90-a630-1c282a1febffn%40googlegroups.com.

Re: Rust journey

[Alon Zakai]

On Sat, Dec 25, 2021 at 6:02 AM Floh  wrote:

> Ah, language and toolchain interoperability, one of my favourite topics ;)
>
> Zig has nearly the same problems as Rust: it allows to compile to WASM, it
> has both a WASI and Emscripten target, with the WASI target working out of
> the box, but I gave up on the Emscripten target because I just couldn't get
> it to work.
>

I wrote up a demo of Zig + Emscripten here:

https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3

That uses GLES3 and Asyncify from Emscripten, so it's a small program but
it uses interesting features.

The gist also shows using C in the same way, where Emscripten is just the
linker, not the frontend.

I've been meaning to do the same with Rust and write a blogpost about all 3
but haven't found the time...

- Alon



>
> IMHO it would be great if the Javascript shims and interop could be
> somehow split out of the Emscripten SDK into a separate, smaller
> "webapi-wasm-tools" SDK which could be better integrated with other
> language toolchains. The goal should be that other programming languages
> can benefit from the work that went into the Emscripten SDK to access web
> APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality,
> instead of having to duplicate this work, or requiring a separate
> installation of the whole Emscripten SDK.
>
> There's a very promising project https://github.com/schellingb/wajic by
> Bernhard Schelling which has the same goals and which was used to port
> Mattias Gustavsson's DOS-like library to the web:
> https://mattiasgustavsson.com/wasm/
>
> Anyway... just my 2 cents :)
> -Floh.
> On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:
>
>> Hi! Just want to share my experiment with using Rust and WebAssembly. I
>> tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten
>> and unknown platforms. Both finally works, but have lot of obstacles. I am
>> very sad about support level of emscripten in Rust, hope it will change at
>> some day.
>>
>> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRQVO9S_umhNE-0gu-E7LOz2O2HMxhNHnS9uiLFcC3GDg%40mail.gmail.com.

Re: Rust journey

[Alon Zakai]

Very interesting writeup, thanks!

It is sad that things don't work better here. The Emscripten side is
focused on C/C++ obviously and on native API support while the Rust side is
focused on either pure computation or on calling Web APIs. For something
like Vange-rs you really want native APIs + Rust, so neither side is really
enough.

I keep hoping that someone will have an important enough use case for them
to spend time on getting Emscripten+Rust working well, but so far that
hasn't come up. As more native apps get written in Rust though perhaps
eventually it will.

On Fri, Dec 24, 2021 at 6:16 AM Александр Гурьянов 
wrote:

> Hi! Just want to share my experiment with using Rust and WebAssembly. I
> tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten
> and unknown platforms. Both finally works, but have lot of obstacles. I am
> very sad about support level of emscripten in Rust, hope it will change at
> some day.
>
> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVF2wUiuKH1%3DivMhfjuAFdtMwvHxc0YaS4V%2BGoGfBWuy6w%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSs7mNA%2B18XfW%3DndrgoVO0EeG2nESvB6C648xW7dRtf7w%40mail.gmail.com.

Re: Rust journey

[Floh]

Ah, language and toolchain interoperability, one of my favourite topics ;)

Zig has nearly the same problems as Rust: it allows to compile to WASM, it 
has both a WASI and Emscripten target, with the WASI target working out of 
the box, but I gave up on the Emscripten target because I just couldn't get 
it to work.

IMHO it would be great if the Javascript shims and interop could be somehow 
split out of the Emscripten SDK into a separate, smaller 
"webapi-wasm-tools" SDK which could be better integrated with other 
language toolchains. The goal should be that other programming languages 
can benefit from the work that went into the Emscripten SDK to access web 
APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" functionality, 
instead of having to duplicate this work, or requiring a separate 
installation of the whole Emscripten SDK.

There's a very promising project https://github.com/schellingb/wajic by 
Bernhard Schelling which has the same goals and which was used to port 
Mattias Gustavsson's DOS-like library to the 
web: https://mattiasgustavsson.com/wasm/

Anyway... just my 2 cents :)
-Floh.
On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:

> Hi! Just want to share my experiment with using Rust and WebAssembly. I 
> tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten 
> and unknown platforms. Both finally works, but have lot of obstacles. I am 
> very sad about support level of emscripten in Rust, hope it will change at 
> some day.
>
> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com.

Rust journey

[Александр Гурьянов]

Hi! Just want to share my experiment with using Rust and WebAssembly. I
tried to port Vange-rs project (rust + wgpu) to browser. I used emscripten
and unknown platforms. Both finally works, but have lot of obstacles. I am
very sad about support level of emscripten in Rust, hope it will change at
some day.

https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVF2wUiuKH1%3DivMhfjuAFdtMwvHxc0YaS4V%2BGoGfBWuy6w%40mail.gmail.com.