* 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).

* 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.

* 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.

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

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();

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.
--001636eee3184dfbfa04aa6fc5f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sat, Aug 13, 2011 at 5:10 AM, bearophile <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophileHUG=
S lycos.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Found though Reddit. It seems Chrome is starting to warm up to the Native C=
lient (NaCl) idea, the Chrome Beta now has a working NaCl:<br>
<br>
<a href=3D"http://chrome.blogspot.com/2011/08/building-better-web-apps-with=
-new.html" target=3D"_blank">http://chrome.blogspot.com/2011/08/building-be=
tter-web-apps-with-new.html</a><br>
<br>
<a href=3D"http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help=
-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti" target=3D"_blank">http:=
//channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-pla=
ne-Some-modern-C-Meet-Ale-Contenti</a><br>
<br>
It&#39;s one (the only?) chance to use D in the browser.<br>
<br>
Bye,<br>
<font color=3D"#888888">bearophile<br></font></blockquote><div><br></div><d=
iv>Just thought I&#39;d point out that the previous discussions on NaCl see=
m to have missed this part of the overview:</div><div>&quot;<span class=3D"=
Apple-style-span" style=3D"font-family: Helvetica, Arial, sans-serif; line-=
height: 16px; background-color: rgb(255, 255, 255); ">The Pepper Plug-in AP=
I (PPAPI), called=A0<b>Pepper</b>=A0for convenience, is included in the Nat=
ive Client SDK. This library is written in C, and the SDK also provides a s=
et of C++ bindings for it. Native Client modules use the Pepper API to comm=
unicate with the browser&#39;s JavaScript, the DOM, and other resources man=
aged by the browser. The Pepper Library also provides a platform-independen=
t multimedia API that Native Client modules can use for audio, video, and 2=
D graphics.&quot;</span></div>
<div><br></div><div>So yes, this is somewhat geared toward multimedia, but =
it looks like it can also replace javascript in web apps.=A0</div></div><br=

"By not adopting a technology capable of competing with native apps on

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.

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?

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.
--0016368e3582f0f93604aa7c9946
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Marco.Leise gmx.de">Marco.Leise gmx.d=
e</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley &lt;<a href=3D"mailto:wiley.=
andrew.j gmail.com" target=3D"_blank">wiley.andrew.j gmail.com</a>&gt;:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">
On Sat, Aug 13, 2011 at 5:10 AM, bearophile &lt;<a href=3D"mailto:bearophil=
eHUGS lycos.com" target=3D"_blank">bearophileHUGS lycos.com</a>&gt;<u></u>w=
rote:<br>
<br>
</div><div><div></div><div class=3D"h5"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Found though Reddit. It seems Chrome is starting to warm up to the Native<b=
r>
Client (NaCl) idea, the Chrome Beta now has a working NaCl:<br>
<br>
<a href=3D"http://chrome.blogspot.com/2011/08/building-better-web-apps-with=
-new.html" target=3D"_blank">http://chrome.blogspot.com/<u></u>2011/08/buil=
ding-better-web-<u></u>apps-with-new.html</a><br>
<br>
<br>
<a href=3D"http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help=
-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti" target=3D"_blank">http:=
//channel9.msdn.com/<u></u>Shows/C9-GoingNative/<u></u>GoingNative-0-Help-u=
s-fly-<u></u>this-plane-Some-modern-C-Meet-<u></u>Ale-Contenti</a><br>
<br>
It&#39;s one (the only?) chance to use D in the browser.<br>
<br>
Bye,<br>
bearophile<br>
<br>
</blockquote>
<br></div></div><div class=3D"im">
Just thought I&#39;d point out that the previous discussions on NaCl seem t=
o<br>
have missed this part of the overview:<br>
&quot;The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is<b=
r>
included in the Native Client SDK. This library is written in C, and the SD=
K<br>
also provides a set of C++ bindings for it. Native Client modules use the<b=
r>
Pepper API to communicate with the browser&#39;s JavaScript, the DOM, and o=
ther<br>
resources managed by the browser. The Pepper Library also provides a<br>
platform-independent multimedia API that Native Client modules can use for<=
br>
audio, video, and 2D graphics.&quot;<br>
<br>
So yes, this is somewhat geared toward multimedia, but it looks like it can=
<br>
also replace javascript in web apps.<br>
</div></blockquote>
<br>
Is this basically the same as the Java applet interface to the browser with=
out the &quot;compile once, run everywhere&quot;, but with better API?<br><=
/blockquote><div><br></div><div>I haven&#39;t ever dealt with the applet in=
terface, but that quote came from=A0<a href=3D"http://code.google.com/chrom=
e/nativeclient/docs/technical_overview.html">http://code.google.com/chrome/=
nativeclient/docs/technical_overview.html</a>=A0if you want to take a close=
r look.=A0The Pepper API docs are there as well.</div>
</div><br>
--0016368e3582f0f93604aa7c9946--

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?

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

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

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

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

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.

--00151748e768735db704aad2ba6d
Content-Type: text/plain; charset=ISO-8859-1
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
:)
--00151748e768735db704aad2ba6d
Content-Type: text/html; charset=ISO-8859-1
wow, would be great to have bindings to the pepper api from d.<br>one of the
reasons I still use java is for its ability to compile to very fast javascript
(using gwt).<br>If d is able to do this I can finally leave java behind.<br>
Beeing able to compile to a web app could also add a bit to d&#39;s popularity
:)<br>
--00151748e768735db704aad2ba6d--

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=

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."

"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."