On 1/23/17, John Spikowski <supp...@scriptbasic.org> wrote:
> My interest is to use my IUP desktop Script BASIC code untouched on the
> Script BASIC HTTPD application server. I can generate browser code
> (text) from Script BASIc efficiently without the bloat of translated C
> to JavaScript code. The same Script BASIC extension modules (cURL,
> MySQL, SQLite, ODBC, ...) I use on the desktop can be used with the
> Script BASIC server. I'm able to share (R/W lockable) variables among
> threads. It really doesn't get much easier.
>
> I'm keeping this as BASIC as possible.
>
Okay.
What you have in mind sounds more like a X remote desktop protocol or
VNC. Either way, I think this sounds pretty far outside the scope of
IUP. IUP is just about native GUIs. And your solution wouldn’t be of
much benefit to IUP users; only Script BASIC users. This sounds like a
project for the Script BASIC community, not the IUP community.
And all the supporting machinery you need to drive this would
introduce necessary runtime dependency bloat which I suspect would be
bigger than the final Emscripten output. And in many respects, I think
your approach is much more complex than what’s going on here
(conceptually). Not to mention it introduces other complicated side
issues, like connectivity issues or scalability, e.g. what if you have
millions of users? Your server solution has to scale, whereas IUP is
generally oriented to just client-side.
Here’s another way to think about what I’m doing:
To implement a new platform, we need two things.
(1) A compiler that takes our code and generates the native machine code.
(2) A way to call native platform GUI APIs
(1) Normally, we use a compiler like gcc or clang that produces native
assembly code for the architectures we are interested in:
- amd64
- i386
- armv7
- aarch64
(2) We also need to be able to call native platform GUI APIs from C,
since that is the language IUP is written in.
- For GTK, this is trivial since the API is already in C.
- For Android, we go through Java JNI to cross between C and Java
- For Mac/iOS, to go between C and Objective-C, the compiler
automatically handles this.
So now apply this to the web browser:
(1) Instead of amd64 assembly or armv7, our native machine code format
is JavaScript (or WebAssembly...see description below)
The Emscripten compiler allows us to compile C code into JavaScript
(instead of amd64, et al.).
(2) We need to be able to call into JavaScript from C so we can call
native APIs like:
var button = document.createElement("button");
Emscripten also solves this for us, providing a calling solution that
looks half-way between the manual Android JNI way and the compiler
automatically doing it for us.
So we now have:
(1) A compiler
(2) A way to write a backend for IUP that calls native web browser
APIs which are in JavaScript
So now we can produce an IUP program that can be compiled for the web
browser, just like we compiled it for Windows, Linux, Mac, iOS, and
Android.
And this satisfies the original criteria:
(2) “IUP's purpose is to allow a program source code to be compiled in
different systems without any modification.”
(3) “it uses native interface elements.”
And conceptually, in the spirit of (2), the program we get works in
the same manner as our native platform binaries. We don’t have to
worry about interoperating a server and client together as in your
model, which is a totally alien concept to IUP programs of today.
Also, thinking about the “bloat” of translated C code to JavaScript,
while has some truth, misses the more important concept that basically
JavaScript is just being treated as the assembly language for the web
browser. Most people don’t argue about the “bloat” that i386 and amd64
code have compared to armv7 and aarch64. (The size difference can be
around 30%.) Most of us just think of it as what the underlying
machine has to take and don’t argue about it.
*WebAssembly: Now that Emscriptem/ASM.js have proven a success, all
the web browser makers seem to be on board to create WebAssembly.
ASM.js was a clever hack that allowed compiling C to JavaScript with
annotations for extra performance, but being 100% compatible with
regular JavaScript. This imposed certain limitations.
WebAssembly is basically an agreement that they are willing to create
something new that doesn’t have the 100% backwards compatibility
constraints of asm.js. The intent is to make it easer for other
languages to write compilers to WebAssembly that can generate much
smaller and more efficient code.
So hopefully, once WebAssembly truly arrives, the output we get will
be significantly smaller than what we are getting with the JavaScript
output today.
So, in the end, I think your solution is actually more complicated.
Conceptually, it works exactly the same way as all the other backends.
All we do here is take our existing IUP program and recompile it for
the web as the target (instead of Windows or Linux). You already have
to do that anyway if you want to compile for Windows, Linux, etc. You
call emcc instead of gcc. It really doesn’t get simpler than that.
For you, since you are using Script BASIC, your one trick would be to
figure out how to get Script BASIC compiled to JavaScript/WebAssembly.
If Script BASIC is written in C/C++, then maybe it is just a trivial
thing of compiling Script BASIC through Emscripten and you're done.
I’m not sure. But I expect in the next 3-5 years as WebAssembly
deploys and becomes viable, we’ll be seeing more and more languages
support WebAssembly. You might start pushing on your Script BASIC
community to start thinking about this so it is ready when the time
comes.
-Eric
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
