1. OpenEuphoria and WebASM

https://www.infoworld.com/article/3291780/web-development/what-is-webassembly-the-next-generation-web-platform-explained.html

Maybe we could do this!

new topic     » topic index » view message » categorize

2. Re: OpenEuphoria and WebASM

I've been keeping my eye on asm.js and WebAssembly since they came out and it certainly seems interesting.

Problem is, we'd be a lot better off rewriting the backend to support more dynamic targets instead of trying to cram a square peg in a round hole.

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: OpenEuphoria and WebASM

I have to conclude it is all just complete and utter drivel!

I was around when Michael Jackson changed "bad" to mean "good", but I must have missed the part when "fast" and "slow" traded places.
I assume "near-native performance" now means "how long it would take a long-lost tribe from the Amazon jungle to solve Fermats last theorem".

Maybe if someone could complete 7guis in WebASM and further they would load in less (by which I mean the version of that word as printed in my 1970s Oxford English Dictionary!) than 20 minutes, I might take a look, ideally just at the output binaries, rather than source+that_whole_damn_toolchain. Or just anything between the ridiculously over complicated examples of Video Effects/Zen Garden/Tank Battle and the other extreme, a blank page with a console.log(3).

For now, though, I still think Compilation to Javascript has more promise.

Pete

new topic     » goto parent     » topic index » view message » categorize

4. Re: OpenEuphoria and WebASM

ghaberek said...

I've been keeping my eye on asm.js and WebAssembly since they came out and it certainly seems interesting.

Problem is, we'd be a lot better off rewriting the backend to support more dynamic targets instead of trying to cram a square peg in a round hole.

I think one of the advantages we already have is we translate to C. Going from C to WebASM is already accomplished... I think. Someone has a compiler for that already.

new topic     » goto parent     » topic index » view message » categorize

5. Re: OpenEuphoria and WebASM

It's real, Pete Lomax!

https://blog.logrocket.com/webassembly-how-and-why-559b7f96cd71

😁😁😁

new topic     » goto parent     » topic index » view message » categorize

6. Re: OpenEuphoria and WebASM

euphoric said...

I gave it another spin... After creating and building the hello world in C example on https://webassembly.studio/ I downloaded it and tried to run it locally, at which point I got

Fetch API cannot load file:///C:/Users/Pete/Downloads/wasm-project/out/main.wasm. URL scheme must be "http" or "https" for CORS request. 

So I uploaded it to my web page and ran it, to get a green screen with a 0 on it, and I had to open Developer Tools and click on Console to see the "Hello World".

I conclude that decent examples are still very hard to find, and that

 Edit->Run 

would become

 Edit->Compile to wasm->Login to cPanel->Zip->Upload->Unzip->Open web Page->Open Developer Tools->Open Console->Scratch Head->Rinse, Cycle, Repeat 

as compared to [or maybe not, see last point below]

 Edit->Compile to Javascript->Run Locally->Scratch Head->Rinse, Cycle, Repeat 

and I'm still not really getting what wasm offers that js does not...

To end on one positive idea stemming from all this though:

Just as main.js in that wasm example contains

 let x = '../out/main.wasm'; 
 fetch(x) 

a js-only solution might look more like

  <script src="./compiled.js"></script> 
  <script src="./main.js"></script> 

and in that way we might only have to create fairly straightforward data (il/bytecode of our own design) rather than actual js code.
(Of course we still have to write main.js which contains lots of js code, what I am saying is we might not have to write a program which writes lots of complex js code.)
(Plus, we could possibly have a main.e (and a compiled.e pretty similar to the compiled.js) which emulates main.js in a local/debug-able fashion...)

Pete

PS: This looks quite interesting, and all done in a single source file of just 6087 lines of fairly readable vanilla js: http://tau-prolog.org/
PPS: An even simpler starting point (<250 lines of js): https://www.codeproject.com/Articles/345888/How-to-write-a-simple-interpreter-in-JavaScript

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu