Re: [Iup-users] Script BASIC IUP web emulation

[Eric W. <ewm...@gm...>]

On 1/24/17, John Spikowski <su...@sc...> wrote:
> Eric,
>
> Your right and what I'm after isn't a solution for the generic C IUP
> user. I wrap IUP as an extension module in a FFI based interface. I
> have had success with IUP running threaded. Scripting reduces
> complexity and reuses resources by design.
>
> John
>

Okay, so I think we’re on the same page now.


So I just want to put this idea out there. You don’t have to go this route.
But with IupEmscripten, you could still theoretically use this with
Script BASIC.

Basically, you just need to get a compiler to compile Script Basic
into JavaScript or Web Assembly.

I don’t expect libFFI to be a problem (long term). A lot of big
languages depend on it, like Python. A quick web search shows that
somebody may have already worked on porting it for Emscripten.

So you could theoretically just write a normal IUP app in Script BASIC
(no extra server/client protocol stuff). Then run the whole thing
through Emscripten to build your app for the web.

I’ll speculate how this would actually work.

Option 1: First generation (today)
I’ll assume Script BASIC itself is a VM language, say like Lua. I’ll
also assume Script BASIC is written in C or C++.

So basically you just compile world through Emscripten:
- So you compile Script BASIC in Emscripten to produce a target output
for JavaScript that can run in the web browser.
- You also compile libFFI and your FFI bindings for IUP through
Emscripten so Script BASIC can call IUP.
- You also compile IUP through Emscripten using the IupEmscripten backend.

Your Script BASIC scripts remain actual Script BASIC. You do not
compile these to JavaScript. You store them as resource files in the
target output bundle that the Emscripten compiler generates.

Then when you load the program in the web browser, Script BASIC starts
up its VM instance, and then loads your Script BASIC scripts, just
like it normally does on any other platform (Windows, Linux). The only
difference is the VM is running inside the web browser's JavaScript VM
instead of on the native platform. To your Script BASIC scripts, they
can’t see any difference. (It's analogous to the idea of running a
Linux VM in a Windows host. The programs you run in Linux don't see
they are in a VM on Windows.)

This is how people are using Lua in the web browser right now for things.



Option 2: Next generation Web Assembly (a few years from now)

Your compiler folks may find a more optimal way to compile Script
BASIC scripts directly to Web Assembly instead of having to run the
full Script BASIC VM instead the web browser. I don’t really know.
Worst case, they can't, but now you the same as Option 1 except
compile to WebAssembly which supposedly will be faster and smaller.


----
As for threads, I don’t know if Script BASIC uses real native OS
threads, but if it does, you should be very careful with them if you
care about cross-platform portability. Mac, iOS, and Android are
pretty much not thread safe and must run their API commands on the
main UI thread. (I thought GTK is the same way.) I know some SDL users
have been bit hard because they first developed in Windows and
designed things to work on background threads. Windows seems to be
more tolerant of this. Then when they port to Mac, everything crashes.
And they are unhappy they have to re-architect their design and
rewrite their code.

-Eric