On Thursday, 2 April 2015 at 12:40:14 UTC, Laeeth Isharc wrote:
Hi.

I am sure most of you saw this:

http://arstechnica.com/gadgets/2015/04/googles-arc-opens-up-to-developers-runs-android-apps-on-most-desktop-oses/

Thanks, I had not seen this, only the earlier hack where some dev got the alpha version of ARC working on desktop OS's on his own, which I thought about mentioning here but didn't. I figured it wasn't that important.

Relates to the Google native client technology which caught attention a while back (not all of it favourable - 'I thought we put a stake through the Active-X vampire, and yet it returns') but seems to have gone quiet, although in meantime as I understand it chrome store apps can be written in C, C++, etc. It's just that nobody uses the chrome store.

To be fair, they've actually done a lot to secure NaCl, unlike ActiveX. ;) But yes, nobody uses the Chrome Store: they seem to be trying to change that with ARC.

From a D perspective, native client seemed lots of work for little tangible benefit, since it depends on a heavily modified compiler toolchain. (It uses a restricted instruction set, a little more restricted than originally as holes were found).

https://developer.chrome.com/native-client
https://developer.chrome.com/apps/getstarted_arc

The idea of being able to have your application run as native code for speed and not have to work in two languages is appealing though.
--snip--
As I understand it, DMD works more or less with Android/x86 (so presumably this tool might be able to convert DMD applications to native client so they run in the browser). When we have android support for ARM, I guess it is feasible to write D apps that run in a browser on ARM phones/tablets.

If we have Android support for ARM, what is the advantage of running in the browser on mobile devices? This is never going to work on iOS, because Apple doesn't allow full Chrome with NaCl on iOS, only the Chrome UI wrapped around Apple's local WebKit. WP? :D

As for converting native Android D apps to run on ARC, they don't mention NDK, ie native, apps on their ARC webpage, but the Chromium bug tracker shows that they're working on some kind of NDK translation layer (funny that they hit the same 64-bit long double issues on x86 that I did):

https://code.google.com/p/chromium/issues/list?can=1&q=ndk+label%3ACr-Platform-ARC

As you said, NaCl requires a modified compiler that restricts the compiled binary to a more secure subset, so they appear to be translating NDK-compiled or our D code to what the NaCl sandbox accepts for it to work. There's talk of Posix translation and some sort of NDK translation source in a handful of those issues, but I don't see that source folder in the public git repo, so maybe it's unreleased:

https://chromium.googlesource.com/arc/arc/+/master/src/

This may allow us to target NaCl easier by using D's existing Android support, assuming they ever get NDK Android apps fully translated to ARC. But I'm skeptical that all these native workarounds in the browser will ever really amount to anything- they haven't so far- not because I don't believe in native, but because you're often still stuck in the browser, ie the horrible HTML/DOM/js stack.

I suppose they want to take the Android runtime everywhere, including the ART support that they're working on now apparently, so given the great success of the Android platform so far, who knows what will come of it.

Reply via email to