“new” don’t need “.h” at end. “new.h” is obsolete GCC 2 header, it should be not used.
3 Likes
With the correct headers, the executable came out identical to the one with the wrong headers, but at least I’ll be future-proof. Now for the bytecode attempt.
I tried using the Python utility to create stubs for all shared objects but it wasn’t robust enough. I’ll have to rework the algorithm in my own stubify.py script.
1 Like
Toolchain
I’m now starting to look into a WebAssembly based toolchain for Haiku.
Binaryen
Binaryen is cross-architecture but deviates from WebAssermbly on several points: The structure of Binaryen’s bytecode is tree-based rather than a stack machine. Due to stack machines being more easily considered position-independent than a tree definition, implementing macros of all system-specific features in a device driver can be encapsulated into a bytecode driver template whose binary code can be rebuilt by an install trigger in the package manager every time the macro definitions change. This could also be used to make applications calling these drivers to incorporate driver code in performance intensive loops by macro-inlining and registering a trigger to also rebuild any time the macro package needs updating. Binaryen translates to raw WebAssembly in the end anyway.
Haiku-specific Headers
This will probably be the type of toolchain I end up using. Packager friendly by being a stable ABI unlike other operating systems that shall remain unnamed except that the first inital of the kernel is the first letter of Linux. (Yes Linux. The famous unstable ABI that broke the closed-source nVidia drivers on my main development machine during a routine kernel update. GRRRRRR! 
)
If we can pioneer enough into a macro-intensive device driver architecture, maybe we can push our changes upstream to the main WebAssembly standard at some point. I’m fairly sure the graphics card makers will appreciate the flexibility.
8 Likes
Short Update
I spent most of Friday trying to get a Haiku-compatible cross-toolchain built on my Linux box. It still doesn’t complete but it gets really close when using the build instructions on the Wiki. It’s probably because the R1beta3 build instructions require the nightly build and I was using the stable build.
2 Likes
Ok, does somebody have a working build script to add a Haiku target to my Linux Rust compiler? It’s a necessary prerequisite for making Wasmer work on Haiku.
Never mind. It’s listed on the HaikuDepot as rust_bin.
Ok. Thanks to @PulkoMandy for the documentation and @Coldfirex for the help getting my Haiku 64 bit VM to have secure GitHub access, today I’m looking into porting the Region crate to Haiku. It’s a virtual memory wrapper used by Wasmer. Hopefully this will be my first successful crate in Rust.
11 Likes
I’ve gotten the foreign function interface code to compile in Rust. Sadly, trying to debug code containing raw pointers and “unsafe” directives are as difficult to debug as if they were written in C++. Right now I’m trying to decode a segmentation fault’s origins. It’s traced to the “drop” code (destructor) of the AreaInfo structure in my code. Either the “new” function (constructor) code or drop code could be generating it. 1 unit test works, 26 to go.
6 Likes
All unit tests in the Region crate run now. 15 pass, 13 fail.
9 Likes
Update
I seem to have hit a slight snag. When I ran the unit tests before, 13 failed with an error message… It was the same error message for all of them and it was triggered only one place in my code. Once I found the extra condition I’d put on the code returning without error, I removed the extra code. Now it doesn’t return from one of my previously passing tests because the error is not triggered properly.
I’m close. I can almost smell victory. Now I need to find out precisely when the error should happen.
4 Likes
what will be the next steps once your project is completed, i am poorly informed about the use of web assembly, can you give me some examples of potential advantages applying web assembly with haiku in the near future?
WebAssembly runs software on any system, regardless of the processor. Wasmer even runs it without a Web Browser. The idea is to level the playing field between operating systems by offering a basic level of compatibility between them all.
1 Like
You have presented WASM as a solution for the web browser issue. Could you describe how can it help to view/experience non-wasm based websites with it? I mean i know currently you are trying to get the system working in cli, but could you explain how a non-wasm based website can profit from this if at all? It seems you belive this can be a game changer and also it seems you belive in this, but as a naive person for me it is not a drop-in replacement for web engines, and it solves only problems tangentially to modern web. And in the same time it -at least for me- start to get to seems like a “developer” like approach to solve some problems, which is basically exists only because unexplained reasons.
Dont get me wrong, i am pro development, even if i think web should have been stopped at html4, but wasm still looks like a “yet another, even deeper penetrating layer”. Is this all actually have any good for us, users? I know, this is a pretty complicated question, but you seems to have experience and knowledge about this topic, so i hope you can give an answer.
Thank you.
I think this was originally being sold as a way to write an app and run it on any version of Haiku, regardless of processor architecture. But the scope seems to be widening as it is becoming a kitchen sink solution for any issue.
I have a .Net Runtime interpreted that I ported to the PSP. I think I could probably get that running on Haiku in about a week with simple GUI apps. But I don’t think it is a replacement for native code. The replacing native code part is still unproven for me.
WebSites, like any other software, target an environment. In this case it is a browser. The legacy software for HTML, CSS and JavaScript will only run on Wasmer once a browser (or at least the missing parts) have been ported to Wasmer. Since Servo is written in Rust like Wasmer is, it might be a target for Wasmer.
As for how Wasmer will be a solution to the browser complexity issue, native apps will be as easy to write under Wasmer as web sites and eliminate the need for a browser by making those native apps portable. It will be simpler by offering a thinner compatibility layer than the browser does.
That is not really how WASM is used though. WASM bypasses the standard browser runtime and runs a big binary blob in its own runtime. It will not help to make a browser happen any more than porting a browser to the native API will.
1 Like
Correct, but if people are writing web apps in an environment like Dart Native, it uses WebAssembly and WebGL only. The only parts of the browser it actually needs.
I don’t think anyone will be doing that though. Dart is a tiny language outside of it’s niche. Why would we abandon C and C++? I don’t see all the BeAPI being ported to WASMER and so I don’t see it as a viable alternative. We might as well use LINUX if we are going to need yet another API to target. Haiku already has too many third party API’s, especially when the native API is actually quite good if you take time to learn and understand it.
1 Like
Emscripten is supported by Wasmer too. C++ is supported by it as are C, Zig, Go, Rust and several other languages.