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