www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Native Client in Chrome Beta

reply bearophile <bearophileHUGS lycos.com> writes:
Found though Reddit. It seems Chrome is starting to warm up to the Native
Client (NaCl) idea, the Chrome Beta now has a working NaCl:

http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html

http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti

It's one (the only?) chance to use D in the browser.

Bye,
bearophile
Aug 13 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 13 Aug 2011 15:10:07 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 It's one (the only?) chance to use D in the browser.
* An LLVM back-end exists which emits JavaScript. I believe I've seen Doom on HTML5. * D.NET may be dead, but it would allow running D on Silverlight. * Lastly, Adobe has an LLVM backend for generating ActionScript 3 bytecode (Adobe Alchemy). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Aug 13 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 13/08/11 4:04 PM, Vladimir Panteleev wrote:
 On Sat, 13 Aug 2011 15:10:07 +0300, bearophile
 <bearophileHUGS lycos.com> wrote:

 It's one (the only?) chance to use D in the browser.
* An LLVM back-end exists which emits JavaScript. I believe I've seen Doom on HTML5. * D.NET may be dead, but it would allow running D on Silverlight. * Lastly, Adobe has an LLVM backend for generating ActionScript 3 bytecode (Adobe Alchemy).
None of those are actually D code running natively though.
Aug 13 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:j26bai$2uot$1 digitalmars.com...
 On 13/08/11 4:04 PM, Vladimir Panteleev wrote:
 On Sat, 13 Aug 2011 15:10:07 +0300, bearophile
 <bearophileHUGS lycos.com> wrote:

 It's one (the only?) chance to use D in the browser.
* An LLVM back-end exists which emits JavaScript. I believe I've seen Doom on HTML5. * D.NET may be dead, but it would allow running D on Silverlight. * Lastly, Adobe has an LLVM backend for generating ActionScript 3 bytecode (Adobe Alchemy).
None of those are actually D code running natively though.
Yea. But it's all better than nothing, though. I mean, if you have to run something on JS/AS3/Silverlight, it's better than not being able to use D at all. Speaking of, anyone know of any good tutorials for making an LLVM backend? Preferably geared at someone with no compiler-backend experience? I've looked at LLVM's docs, but I couldn't make heads or tails of a single word of it.
Aug 13 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/13/2011 08:51 PM, Nick Sabalausky wrote:
 "Peter Alexander"<peter.alexander.au gmail.com>  wrote in message
 news:j26bai$2uot$1 digitalmars.com...
 On 13/08/11 4:04 PM, Vladimir Panteleev wrote:
 On Sat, 13 Aug 2011 15:10:07 +0300, bearophile
 <bearophileHUGS lycos.com>  wrote:

 It's one (the only?) chance to use D in the browser.
* An LLVM back-end exists which emits JavaScript. I believe I've seen Doom on HTML5. * D.NET may be dead, but it would allow running D on Silverlight. * Lastly, Adobe has an LLVM backend for generating ActionScript 3 bytecode (Adobe Alchemy).
None of those are actually D code running natively though.
Yea. But it's all better than nothing, though. I mean, if you have to run something on JS/AS3/Silverlight, it's better than not being able to use D at all. Speaking of, anyone know of any good tutorials for making an LLVM backend? Preferably geared at someone with no compiler-backend experience? I've looked at LLVM's docs, but I couldn't make heads or tails of a single word of it.
Actually, the docs contain a nice introductory tutorial on how to use llvm to make a backend: http://llvm.org/docs/tutorial/
Aug 13 2011
prev sibling parent David Nadlinger <see klickverbot.at> writes:
On 8/13/11 8:51 PM, Nick Sabalausky wrote:
 Speaking of, anyone know of any good tutorials for making an LLVM backend?
 Preferably geared at someone with no compiler-backend experience? I've
 looked at LLVM's docs, but I couldn't make heads or tails of a single word
 of it.
Do you mean writing a compiler backend using LLVM, or writing a new code generator backend for LLVM? For the latter, I have found http://llvm.org/docs/WritingAnLLVMBackend.html to be quite helpful, but you will probably have an easier time if you first get acquainted with the other parts of LLVM. David
Aug 13 2011
prev sibling next sibling parent sclytrack <sclytrack superidiot.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Found though Reddit. It seems Chrome is starting to warm up to the Native
Client
(NaCl) idea, the Chrome Beta now has a working NaCl:
 http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html
http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti
 It's one (the only?) chance to use D in the browser.
 Bye,
 bearophile
Read this as a feature request. dmd --restrictedandsafe(std.file1, std.file2) main.d file1.d file2.d file3.d file1.d file2.d file3.d are normal files maind.d is restricted and safe. 1) main.d can only import from std.file1, and std.file2 2) All routines in main.d must be safe. 3) main.d can not make declarations like extern(c) void routine();
Aug 13 2011
prev sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sat, Aug 13, 2011 at 5:10 AM, bearophile <bearophileHUGS lycos.com>wrote:

 Found though Reddit. It seems Chrome is starting to warm up to the Native
 Client (NaCl) idea, the Chrome Beta now has a working NaCl:

 http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html


 http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti

 It's one (the only?) chance to use D in the browser.

 Bye,
 bearophile
Just thought I'd point out that the previous discussions on NaCl seem to have missed this part of the overview: "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is included in the Native Client SDK. This library is written in C, and the SDK also provides a set of C++ bindings for it. Native Client modules use the Pepper API to communicate with the browser's JavaScript, the DOM, and other resources managed by the browser. The Pepper Library also provides a platform-independent multimedia API that Native Client modules can use for audio, video, and 2D graphics." So yes, this is somewhat geared toward multimedia, but it looks like it can also replace javascript in web apps.
Aug 13 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley <wiley.andrew.j gmail.com>:

 On Sat, Aug 13, 2011 at 5:10 AM, bearophile  
 <bearophileHUGS lycos.com>wrote:

 Found though Reddit. It seems Chrome is starting to warm up to the  
 Native
 Client (NaCl) idea, the Chrome Beta now has a working NaCl:

 http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html


 http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti

 It's one (the only?) chance to use D in the browser.

 Bye,
 bearophile
Just thought I'd point out that the previous discussions on NaCl seem to have missed this part of the overview: "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is included in the Native Client SDK. This library is written in C, and the SDK also provides a set of C++ bindings for it. Native Client modules use the Pepper API to communicate with the browser's JavaScript, the DOM, and other resources managed by the browser. The Pepper Library also provides a platform-independent multimedia API that Native Client modules can use for audio, video, and 2D graphics." So yes, this is somewhat geared toward multimedia, but it looks like it can also replace javascript in web apps.
Is this basically the same as the Java applet interface to the browser without the "compile once, run everywhere", but with better API?
Aug 14 2011
parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley <wiley.andrew.j gmail.com>:

  On Sat, Aug 13, 2011 at 5:10 AM, bearophile <bearophileHUGS lycos.com>**
 wrote:

  Found though Reddit. It seems Chrome is starting to warm up to the Native
 Client (NaCl) idea, the Chrome Beta now has a working NaCl:

 http://chrome.blogspot.com/**2011/08/building-better-web-**
 apps-with-new.html<http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html>


 http://channel9.msdn.com/**Shows/C9-GoingNative/**
 GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti<http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti>

 It's one (the only?) chance to use D in the browser.

 Bye,
 bearophile
Just thought I'd point out that the previous discussions on NaCl seem to have missed this part of the overview: "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is included in the Native Client SDK. This library is written in C, and the SDK also provides a set of C++ bindings for it. Native Client modules use the Pepper API to communicate with the browser's JavaScript, the DOM, and other resources managed by the browser. The Pepper Library also provides a platform-independent multimedia API that Native Client modules can use for audio, video, and 2D graphics." So yes, this is somewhat geared toward multimedia, but it looks like it can also replace javascript in web apps.
Is this basically the same as the Java applet interface to the browser without the "compile once, run everywhere", but with better API?
I haven't ever dealt with the applet interface, but that quote came from http://code.google.com/chrome/nativeclient/docs/technical_overview.html if you want to take a closer look. The Pepper API docs are there as well.
Aug 14 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley <wiley.andrew.j gmail.com>:

 On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley  
 <wiley.andrew.j gmail.com>:

  On Sat, Aug 13, 2011 at 5:10 AM, bearophile  
 <bearophileHUGS lycos.com>**
 wrote:

  Found though Reddit. It seems Chrome is starting to warm up to the  
 Native
 Client (NaCl) idea, the Chrome Beta now has a working NaCl:

 http://chrome.blogspot.com/**2011/08/building-better-web-**
 apps-with-new.html<http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html>


 http://channel9.msdn.com/**Shows/C9-GoingNative/**
 GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti<http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti>

 It's one (the only?) chance to use D in the browser.

 Bye,
 bearophile
Just thought I'd point out that the previous discussions on NaCl seem to have missed this part of the overview: "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is included in the Native Client SDK. This library is written in C, and the SDK also provides a set of C++ bindings for it. Native Client modules use the Pepper API to communicate with the browser's JavaScript, the DOM, and other resources managed by the browser. The Pepper Library also provides a platform-independent multimedia API that Native Client modules can use for audio, video, and 2D graphics." So yes, this is somewhat geared toward multimedia, but it looks like it can also replace javascript in web apps.
Is this basically the same as the Java applet interface to the browser without the "compile once, run everywhere", but with better API?
I haven't ever dealt with the applet interface, but that quote came from http://code.google.com/chrome/nativeclient/docs/technical_overview.html if you want to take a closer look. The Pepper API docs are there as well.
It doesn't convince me. The driving force seems to be moving desktop applications into the browser. That's understandable since a lot of people at Google use their web services where possible. I personally don't like that centralization on the browser. It adds up on complexity and bugs, trying to be an operating system that manages running applications. How do they make sure the code is safer than what we know from ActiveX? Even the WebGL standard was in the critics, because it was obviously accessing the gfx card and a malicious texture upload in a buggy driver could become a security risk. Maybe it finds a way through good advertising or real-time games which run faster with native code instead of JavaScript, but there will always be some bad memories from http://www.adoko.com/activex.html At least they take the issue serious :) http://www.zdnet.com/blog/security/google-wants-to-buy-native-client-security-flaws/2702
Aug 14 2011
parent reply Brad Roberts <braddr puremagic.com> writes:
On Sunday, August 14, 2011 3:29:28 PM, Marco Leise wrote:
 Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley <wiley.andrew.j gmail.com>:
 
 On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley <wiley.andrew.j gmail.com>:

  On Sat, Aug 13, 2011 at 5:10 AM, bearophile <bearophileHUGS lycos.com>**
 wrote:

  Found though Reddit. It seems Chrome is starting to warm up to the Native
 Client (NaCl) idea, the Chrome Beta now has a working NaCl:

 http://chrome.blogspot.com/**2011/08/building-better-web-**
 apps-with-new.html<http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html>


 http://channel9.msdn.com/**Shows/C9-GoingNative/**
 GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti<http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti>
 It's one (the only?) chance to use D in the browser.

 Bye,
 bearophile
Just thought I'd point out that the previous discussions on NaCl seem to have missed this part of the overview: "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is included in the Native Client SDK. This library is written in C, and the SDK also provides a set of C++ bindings for it. Native Client modules use the Pepper API to communicate with the browser's JavaScript, the DOM, and other resources managed by the browser. The Pepper Library also provides a platform-independent multimedia API that Native Client modules can use for audio, video, and 2D graphics." So yes, this is somewhat geared toward multimedia, but it looks like it can also replace javascript in web apps.
Is this basically the same as the Java applet interface to the browser without the "compile once
, run everywhere", but with better API?

 I haven't ever dealt with the applet interface, but that quote came from
 http://code.google.com/chrome/nativeclient/docs/technical_overview.html if
 you want to take a closer look. The Pepper API docs are there as well.
It doesn't convince me. The driving force seems to be moving desktop applications into the browser. That's understandable since a lot of people at Google use their web services where possible. I personally don't like that centralization on the browser. It adds up on complexity and bugs, trying to be an operating system that manages running applications. How do they make sure the code is safer than what we know from ActiveX? Even the WebGL standard was in the critics, because it was obviously accessing the gfx card and a malicious texture upload in a buggy driver could become a security risk. Maybe it finds a way through good advertising or real-time games which run faster with native code
instead of
 JavaScript, but there will always be some bad memories from
http://www.adoko.com/activex.html
 At least they take the issue serious :)
 http://www.zdnet.com/blog/security/google-wants-to-buy-native-client-security-flaws/2702
Quite frankly, it's too late to pretend that the web and the browser is all there is for a large segment of the computer and 'net using population. They never leave the browser. That's only going to grow. Pretending otherwise, is, well, fairly pointless. The people on this are in a very small minority and do NOT represent the typical user. Haven't for a long time. Sorry Nick. Later, Brad
Aug 14 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Brad Roberts" <braddr puremagic.com> wrote in message 
news:mailman.2324.1313368907.14074.digitalmars-d puremagic.com...
 Quite frankly, it's too late to pretend that the web and the browser is
Judging by the rest of your post I assume you meant "isn't" not "is"...
 all there is for a large segment of the computer and 'net using
 population.  They never leave the browser.  That's only going to grow.
 Pretending otherwise, is, well, fairly pointless.  The people on this
 are in a very small minority and do NOT represent the typical user.
 Haven't for a long time.
That's a completely absurd cart-before-the-horse question-begging argument. The *reason* a growing number of people never leave the browser is obviously *because* so many idiot trend-whore developers and managers keep pretending the web is all there is. Users are morons (almost by definition), and that means they defer judgement to others and thus follow the *trends*. On the desktop, web is the trend, therefore 1. Moron users assume that means it's better, and 2. That's where all the functionality gets put, and thus, where the users go. Start making *real* applications again and the sheeple will follow. Need evidence of that? iOS and Android. Are shitphone users flocking to webapps or to the app-store apps? The latter, obviously. (At least that's *one* thing they've managed to get sort-of right...) And you can't argue it's a usability matter, because the web sure as shit doesn't win on that: Web app usability is crap, and Average Retard Joe is no worse at real apps than with the web. My mom's one of the dumbest completer-illiterate fucks I've ever met (no exaggeration) and yet even her ability with Word - a *REAL* application - is absolutely *NO* worse than her ability with a web browser. In fact, she's even a little *better* with the real apps like Word: You should see the crap I have to put up with when she *attempts* to use any of those god-awful webmail servces. Same goes for my dad. Your argument here is completely rediculous.
Aug 14 2011
parent reply maarten van damme <maartenvd1994 gmail.com> writes:
wow, would be great to have bindings to the pepper api from d.
one of the reasons I still use java is for its ability to compile to very
fast javascript (using gwt).
If d is able to do this I can finally leave java behind.
Beeing able to compile to a web app could also add a bit to d's popularity
:)
Aug 18 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 19.08.2011, 04:45 Uhr, schrieb maarten van damme  =

<maartenvd1994 gmail.com>:

 wow, would be great to have bindings to the pepper api from d.
 one of the reasons I still use java is for its ability to compile to v=
ery
 fast javascript (using gwt).
 If d is able to do this I can finally leave java behind.
 Beeing able to compile to a web app could also add a bit to d's  =
 popularity
 :)
Just to clarify: NativeClient is not about compiling <any language> to = JavaScript or replacing JavaScript. Your website would provide = architecture-dependent, but OS-independent executables that link to a C = or = C++ API in the browser. But essentially you'll probably get what you wan= t = from it. The opinions on NativeClient are mixed. They range from security concern= s = over people thinking it is a bad idea to turn the browser into an OS to = = game developers or researchers writing games or simulations who'd love t= o = see this happen. To cite a few web blogs: "Mozilla vice president of products Jay Sullivan says that unlike Google= , = the open source outfit has no intention of bundling Firefox with Adobe = Flash =E2=80=94=E2=80=93 or with a plug-in that runs native code inside = the browser. = Mozilla, Sullivan says, believes that the future of online applications = = lies with web standards, including HTML5." "Opera chief standards officer Charles McCathieNevile argued that Google= 's = Native Client plug-in =E2=80=94 a means of running native code inside th= e = company's Chrome browser =E2=80=94 isn't viable as a long-term browser t= echnology. = It's worth experimenting with, he said, but it runs counter to what he = sees as the web's mission. JavaScript performance is improving at an = impressive clip, he added, and any speed improvements you may get from = native code aren't worth the complications it brings." "By not adopting a technology capable of competing with native apps on = iOS, Android, Windows, and Mac, web vendors are preventing important = classes of applications such as high-end games and simulations from movi= ng = to the open web." "The natural comparison is to Microsoft's ActiveX technology -- and to = critics, it's not a flattering one. ActiveX controls allow developers to= = extend the capabilities of Internet Explorer by creating components that= = can access native Windows functions. But because ActiveX's security mode= l = is largely based on trust, users can easily be tricked into installing = components that compromise system security."
Aug 18 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.v0f018nh9y6py2 dslb-088-070-152-209.pools.arcor-ip.net...
"By not adopting a technology capable of competing with native apps on
iOS, Android, Windows, and Mac, web vendors are preventing important classes of applications such as high-end games and simulations from moving to the open web." That actually brings up an interestng point I hadn't really thought of before: I've always liked the idea of using native code instead of JS, because it just makes so much more sense on a technical level. But, if something better than JS, like NaCl, is adopted on the web, something that can compete with real apps in efficiency, then that will only further encourage people to hop onto Google's bullshit web-as-an-OS agenda. Even if NaCl is universally adopted and completely eliminates the efficiency issues, the web will still be horrid as a so-called "applicatins platform" for other reasons, like UI (a big one), reliability, centralization, user-ownership, privacy... And those issues aren't realistically fixable within the confines of a web browser. So I think it's best if such a thing as NaCl *doesn't* get adopted, since it would only further encourage the biggest plague of the 21st century.
Aug 19 2011
prev sibling parent Kagamin <spam here.lot> writes:
Marco Leise Wrote:

 "By not adopting a technology capable of competing with native apps on  
 iOS, Android, Windows, and Mac, web vendors are preventing important  
 classes of applications such as high-end games and simulations from moving  
 to the open web."
Games can do networking already.
Aug 20 2011