www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D => asm.js for the web?

reply "bearophile" <bearophileHUGS lycos.com> writes:
Maybe you remember the NaCl or PNaCl plug-in from Google, that 
allows to safely run code at near native speed on the browser 
(only 10-30% speed loss, in a probably safe sandbox). This 
plug-in seems interesting, but so far I think it's not getting a 
lot of traction, and it seems Mozilla is not interested in it.

Now on Reddit they have linked "asm.js". It's an easy to compile 
subset of JavaScript, that contains type annotations (inside 
comments, so it's still valid standard JavaScript). Mozilla has 
created a modified version of its JIT that recognizes asm.js code 
and compiles it ahead of time to give, they say, about half the 
speed of native code (if it's not recognized, it's seen as normal 
JS). Even if this speed will increase a little with time, I think 
it will keep being a little slower than NaCl code, but maybe for 
lot of people the speed of asm.js will be enough (and the safety 
of NaCl is not so certain).

A modified version of Emscripten (a LLVM bytecode to JavaScript 
compiler) outputs asm.js. So if you have C/C++ code, with 
Emscripten and some parts of LLVM you compile it to asm.js, and 
then Firefox Nightly recognizes it (there is an annotation).

So given the LDC2 project, maybe with LDC+Emscripten+asm.js there 
is a chance to see D on the web. I think someone will be happy to 
use D instead of C/C++ on the web for performance-sensitive code, 
like games. This is a small window of opportunity for D.

Bye,
bearophile
Mar 22 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

 I think someone will be happy to use D instead of C/C++ on the 
 web for performance-sensitive code, like games.


If it compiles to any kind of javascript it is a mistake to think 
they'll be a performance boost over just writing javascript, with 
or without annotations. Odds are there will be leaky abstractions 
in the compile process that can hurt speed.
Mar 22 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 23, 2013 at 03:34:54AM +0100, Adam D. Ruppe wrote:

 On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

I think someone will be happy to use D instead of C/C++ on the web
for performance-sensitive code, like games.


 
 If it compiles to any kind of javascript it is a mistake to think
 they'll be a performance boost over just writing javascript, with or
 without annotations. Odds are there will be leaky abstractions in
 the compile process that can hurt speed.


Any kind of translation from language X to language Y will incur at
least the performance overhead of language Y, plus some incidental
overhead incurred by non-trivial or imperfect mapping of X's features to
Y'es features. This incidental overhead is rarely every zero.

So there is no way translating from language X to language Y will be
faster than writing in language Y in the first place, no matter how good
your optimizer is. Otherwise, you might as well just write in language Y
to begin with, and run the optimizer on *that*.


T

-- 
Nothing in the world is more distasteful to a man than to take the path that
leads to himself. -- Herman Hesse
Mar 22 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 23 March 2013 at 02:39:55 UTC, H. S. Teoh wrote:

 On Sat, Mar 23, 2013 at 03:34:54AM +0100, Adam D. Ruppe wrote:

 On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

I think someone will be happy to use D instead of C/C++ on 
the web
for performance-sensitive code, like games.


 
 If it compiles to any kind of javascript it is a mistake to 
 think
 they'll be a performance boost over just writing javascript, 
 with or
 without annotations. Odds are there will be leaky abstractions 
 in
 the compile process that can hurt speed.


 Any kind of translation from language X to language Y will 
 incur at
 least the performance overhead of language Y, plus some 
 incidental
 overhead incurred by non-trivial or imperfect mapping of X's 
 features to
 Y'es features. This incidental overhead is rarely every zero.

 So there is no way translating from language X to language Y 
 will be
 faster than writing in language Y in the first place, no matter 
 how good
 your optimizer is. Otherwise, you might as well just write in 
 language Y
 to begin with, and run the optimizer on *that*.


I don't think you understood the point. asm.js is not the same as 
js. Pure js isn't involved anywhere along the translation path 
bearophile proposed except as a side-effect.
Mar 23 2013
prev sibling parent reply "Dan" <dbdavidson yahoo.com> writes:
On Saturday, 23 March 2013 at 02:39:55 UTC, H. S. Teoh wrote:

 So there is no way translating from language X to language Y 
 will be
 faster than writing in language Y in the first place, no matter 
 how good
 your optimizer is. Otherwise, you might as well just write in 
 language Y
 to begin with, and run the optimizer on *that*.


Too strong of a statement, especially since focus is only 
strength of optimizer and not also caliber of developers. There 
is huge benefit and it is one of the big selling points of Dart. 
You write in a familiar OOP language with great toolset and out 
comes working javascript. I don't know javascript - I've started 
to learn a few times but was repelled by it. But most traditional 
OO programmers can grok Dart in a few days, plus it has great 
tools. If D could do the same it would be great.

Thanks,
Dan
Mar 23 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dan:


 There is huge benefit and it is one of the big selling points 
 of Dart. You write in a familiar OOP language with great 
 toolset and out comes working javascript. I don't know 
 javascript - I've started to learn a few times but was repelled 
 by it. But most traditional OO programmers can grok Dart in a 
 few days, plus it has great tools. If D could do the same it 
 would be great.


I prefer TypeScript. It doesn't require a new JavaScript VM, and 
it looks designed very well. I am waiting for a 
TypeScript=>asm.js compiler :-)

Bye,
bearophile
Mar 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 14:22:04 +0100
"bearophile" <bearophileHUGS lycos.com> wrote:


 Dan:
 

 There is huge benefit and it is one of the big selling points 
 of Dart. You write in a familiar OOP language with great 
 toolset and out comes working javascript. I don't know 
 javascript - I've started to learn a few times but was repelled 
 by it. But most traditional OO programmers can grok Dart in a 
 few days, plus it has great tools. If D could do the same it 
 would be great.


 
 I prefer TypeScript. It doesn't require a new JavaScript VM, and 
 it looks designed very well. I am waiting for a 
 TypeScript=>asm.js compiler :-)
 


While some of this stuff is fairly interesting, if you're doing so much
DHTML that JS's downsides become a problem, then you're doing way
too much DHTML. Time to either:

1. Pre-bake stuff (There are sooo many pages out there that do DOM
manipulations or even AJAX requests during page load or "onload". This
is, of course, completely moronic because if it's done during/upon page
load, it *could* have all been just done ahead of time and baked into
the original page. The only thing "during/upon page load" JS ever has
any legitimate reason to do, is undo certain "JS-disabled" elements on
the page - and even that's only for cases where <noscript> is
unsuitable.)

2. Put some of the processing back on the server, where it belongs.

3. Rip the stupid thing out of the web browser, because it's clearly
not a goddamn document.
Mar 23 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 23.03.2013 16:12, schrieb Nick Sabalausky:

 On Sat, 23 Mar 2013 14:22:04 +0100
 ...

 3. Rip the stupid thing out of the web browser, because it's clearly
 not a goddamn document.


+1 Like :)
Mar 23 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 If it compiles to any kind of javascript it is a mistake to 
 think they'll be a performance boost over just writing 
 javascript, with or without annotations.


The Box3D compiled by Emscripten from C++ code is faster than 
other translations of Box3D to JavaScript written by more 
traditional means. Probably because the code produced by 
Emscripten is very un-idiomatic JS, hard to write manually.

And here we are talking about a version of Emscripten that 
targets asm.js, that a new JIT of Firefox Nightly digests better.

Bye,
bearophile
Mar 22 2013
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.03.2013 03:34, schrieb Adam D. Ruppe:

 On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

 I think someone will be happy to use D instead of C/C++ on the web for
 performance-sensitive code, like games.


 If it compiles to any kind of javascript it is a mistake to think
 they'll be a performance boost over just writing javascript, with or
 without annotations. Odds are there will be leaky abstractions in the
 compile process that can hurt speed.


It is actually quite fast.



Having said this, compiling code to JavaScript just feels wrong.

Unless the idea is to port legacy code, I don't see any advantage.

Code translation eventually means you might end up trying to understand 
why something does not work in the target language, while doing a 
compiler mental model of the translations taking place.

--
Paulo
Mar 23 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 Having said this, compiling code to JavaScript just feels wrong.


I agree. On the other hand going against the trends all the time 
is not wise.

Bye,
bearophile
Mar 23 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-23 10:02, Paulo Pinto wrote:


 Having said this, compiling code to JavaScript just feels wrong.


If you want to run the code in a browser that's basically your only 
option. Good luck getting all the browser to implement support for some 
new kind of language. In addition to that getting all users to update to 
this version of the browser. It will never happen.

-- 
/Jacob Carlborg
Mar 23 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 16:55:14 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-03-23 10:02, Paulo Pinto wrote:
 

 Having said this, compiling code to JavaScript just feels wrong.


 
 If you want to run the code in a browser that's basically your only 
 option. Good luck getting all the browser to implement support for
 some new kind of language. In addition to that getting all users to
 update to this version of the browser. It will never happen.
 


"Never happen"? Nonsense. This is what you do:

Browser devs are obsessed with two things: The speed of their browser,
and blindly imitating each other. So you do this:

1. Make a better language, make it compilable to JS, and also make
an "executes without compiling to JS" browser extension or fork+pull
request for just one browser (or more if you really want, but only
one is needed).

2. Make sure the no-JS-involved version works much better than the
fallback-on-JS version. Luckily, that's easy because being lazy about
it and generating inefficient JS code is totally fair game
here (I actually do mean that, I'm dead serious here).

Remember, most of these Web people are the sorts who firmly believe in
the popular new bandwagon "My time as a developer is far more important
than my user's time; if my code is slow then those mouth-breathing
dinosaurs should just upgrade their computers or fuck off". You could
probably even implement it by compiling "new language" into JS *using*
client-side JS.

Again, I'm dead serious about all that - really hardly anyone will
raise an eyebrow. As long as the language itself (and libs/tooling) is
good enough and convenient enough then most devs will just assume the
speed hit is a natural unavoidable consequence and happily accept it.
(I mean, fuck, they accepted JS and VMs and PHP, etc, didn't they? And
I know people who genuinely believed that iTunes's inability to scroll
smoothly/quickly through your list of songs was just because list of a
few thousand was somehow too much for a 1GHz+, 4GB+ computer to
handle. A laughable notion, of course, to anyone with half a brain, but
people actually believe this shit.) To adapt an old security quote:
"Dancing pigs will win every time."

3. Once the "fallback-to-JS" version catches on (because this new
language *is* worthwhile, isn't it?), then point out to everyone: "Hey,
I've got this extention/pull request/whatever for XXXX browser that
seamlessly makes your 'SuperNewLangauge' webapp far, far faster!"
People will think it's absolutely brilliant and near-magical, and that
you must be a genius. The first browser will adopt it in their mainline
because it's already *right there* for them to fold in since you
already made it for them, and because it gives their browser a huge
instant advantage on all the popular new 'SuperNewLangauge'-based web
apps.

4. As soon as that first browser contains a feature, all the rest will
trip over each other to add it too, because really, when was the last
time a browser developer could actually stand for their browser to not
be blindly dead-identical to every other browser out there? And because
of reigniting the whole "browser speed wars" thing.

(5. W3C will step in and rape the spec into something completely
and utterly moronic. Not to mention excessively convoluted.)
Mar 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-23 17:40, Nick Sabalausky wrote:


 "Never happen"? Nonsense. This is what you do:


[snip]

People still uses IE 6.

-- 
/Jacob Carlborg
Mar 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 17:44:07 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-03-23 17:40, Nick Sabalausky wrote:
 

 "Never happen"? Nonsense. This is what you do:


 
 [snip]
 
 People still uses IE 6.
 


Totally different domain. We're talking about replacing JS due to JS's
problems when used heavily. Any site that uses JS that heavily in the
first place wouldn't be working on IE6 anyway. So, if you're making
such a JS-heavy site that a "NewJS" could even matter at all, then
you've *already* made the decision (explicitly or implicitly,
ill-advised or not) to not support IE6.

In other words, a site that needs to work on IE6 isn't going to
be JS-heavy enough to benefit from "NewJS". Therefore,
the whole issue of a "NewJS" isn't relevant to IE6 at all.
Mar 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-23 18:47, Nick Sabalausky wrote:


 Totally different domain. We're talking about replacing JS due to JS's
 problems when used heavily. Any site that uses JS that heavily in the
 first place wouldn't be working on IE6 anyway. So, if you're making
 such a JS-heavy site that a "NewJS" could even matter at all, then
 you've *already* made the decision (explicitly or implicitly,
 ill-advised or not) to not support IE6.

 In other words, a site that needs to work on IE6 isn't going to
 be JS-heavy enough to benefit from "NewJS". Therefore,
 the whole issue of a "NewJS" isn't relevant to IE6 at all.


What I mean is that users don't upgrade to the latest version of their 
browser.

-- 
/Jacob Carlborg
Mar 24 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 24 Mar 2013 11:03:16 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-03-23 18:47, Nick Sabalausky wrote:
 

 Totally different domain. We're talking about replacing JS due to
 JS's problems when used heavily. Any site that uses JS that heavily
 in the first place wouldn't be working on IE6 anyway. So, if you're
 making such a JS-heavy site that a "NewJS" could even matter at
 all, then you've *already* made the decision (explicitly or
 implicitly, ill-advised or not) to not support IE6.

 In other words, a site that needs to work on IE6 isn't going to
 be JS-heavy enough to benefit from "NewJS". Therefore,
 the whole issue of a "NewJS" isn't relevant to IE6 at all.


 
 What I mean is that users don't upgrade to the latest version of
 their browser.
 


That's why there's the "fallback to JS" stuff.
Mar 24 2013
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.03.2013 16:55, schrieb Jacob Carlborg:

 On 2013-03-23 10:02, Paulo Pinto wrote:


 Having said this, compiling code to JavaScript just feels wrong.


 If you want to run the code in a browser that's basically your only
 option. Good luck getting all the browser to implement support for some
 new kind of language. In addition to that getting all users to update to
 this version of the browser. It will never happen.


To run code in the browser the solution is simple, just code in JavaScript.

For everything else, just use the desktop instead of trying to bend a 
pile of broken abstractions designed for document viewing into some kind 
of application.

I used to be a big fan of web development around 10 years ago.

Nowadays, the experience of years of web development with multiple 
languages and frameworks, just makes me advocate desktop applications 
for what is a pile of broken abstractions full of hacks to try to mimic
the desktop across multiple browsers and operating systems.

And don't get me started to discuss about customers that only pay 
projects when the web application is pixel perfect with the given 
Photoshop design.

--
Paulo
Mar 23 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 19:29:55 +0100
Paulo Pinto <pjmlp progtools.org> wrote:

 
 For everything else, just use the desktop instead of trying to bend a 
 pile of broken abstractions designed for document viewing into some
 kind of application.
 


I'd make a PDF viewer which adds all the JS and such the Web ended
up with as a joke to demonstrate the goofiness of it all...but I'm
afraid it might catch on. ;)


 
 And don't get me started to discuss about customers that only pay 
 projects when the web application is pixel perfect with the given 
 Photoshop design.
 


if(request.userAgent == "IE" && request.ip in paityHairedIPAddresses)
{
    response.send(smokeAndMirrors());
}
else
{
    response.send(normalSite());
}
Mar 23 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 19:29:55 +0100
Paulo Pinto <pjmlp progtools.org> wrote:

 
 And don't get me started to discuss about customers that only pay 
 projects when the web application is pixel perfect with the given 
 Photoshop design.
 


if(request.userAgent == "IE" && request.ip in paityHairedIPAddresses)
{
    response.send(smokeAndMirrors());
}
else
{
    response.send(normalSite());
}
Mar 23 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 15:07:58 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:


 On Sat, 23 Mar 2013 19:29:55 +0100
 Paulo Pinto <pjmlp progtools.org> wrote:

 
 And don't get me started to discuss about customers that only pay 
 projects when the web application is pixel perfect with the given 
 Photoshop design.
 


 
 if(request.userAgent == "IE" && request.ip in paityHairedIPAddresses)
 {
     response.send(smokeAndMirrors());
 }
 else
 {
     response.send(normalSite());
 }
 


Ugh, stupid buggy NG client. Ignore this semi-duplicate post...
Mar 23 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.03.2013 20:09, schrieb Nick Sabalausky:

 On Sat, 23 Mar 2013 15:07:58 -0400
 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:


 On Sat, 23 Mar 2013 19:29:55 +0100
 Paulo Pinto <pjmlp progtools.org> wrote:

 And don't get me started to discuss about customers that only pay
 projects when the web application is pixel perfect with the given
 Photoshop design.


 if(request.userAgent == "IE" && request.ip in paityHairedIPAddresses)
 {
      response.send(smokeAndMirrors());
 }
 else
 {
      response.send(normalSite());
 }


 Ugh, stupid buggy NG client. Ignore this semi-duplicate post...


You forgot the thousand and one versions of Webkit available around the web.

I already had to explain to a few customers why Safari on Windows, Mac 
OS X, iOS on iPhone and on iPad all have different behaviours, even 
though it is always "Safari Browser".
Mar 23 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 23 Mar 2013 22:44:39 +0100
Paulo Pinto <pjmlp progtools.org> wrote:


 Am 23.03.2013 20:09, schrieb Nick Sabalausky:

 On Sat, 23 Mar 2013 15:07:58 -0400
 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:


 On Sat, 23 Mar 2013 19:29:55 +0100
 Paulo Pinto <pjmlp progtools.org> wrote:

 And don't get me started to discuss about customers that only pay
 projects when the web application is pixel perfect with the given
 Photoshop design.


 if(request.userAgent == "IE" && request.ip in
 paityHairedIPAddresses) {
      response.send(smokeAndMirrors());
 }
 else
 {
      response.send(normalSite());
 }


 Ugh, stupid buggy NG client. Ignore this semi-duplicate post...


 
 You forgot the thousand and one versions of Webkit available around
 the web.
 


Yea, I guess my key point was the "request.ip in
paityHairedIPAddresses". I was just thinking "graphic designer
who expects pixel-perfect == doesn't know what a web browser is ==
always uses IE". But then, "graphic designer" tends to imply Mac
anyway, as Mac has always tended to be the artist-type's OS, so no IE.


 I already had to explain to a few customers why Safari on Windows,
 Mac OS X, iOS on iPhone and on iPad all have different behaviours,
 even though it is always "Safari Browser".


Heh, I think the first explanation I would have tried would've been
"They're all different *because* it's Safari." :) Not necessarily to
bash on Safari, but whatever makes the dumb questions go away ;)

"They're different because they're different, dammit! Now shaddup and
lemme finish making your stupid little site..."  <-- Heh, if only we
could get away with that...

"They're different because the people who make browsers just like to
piss me off."

Tons 'o fun to be had with that one!
Mar 23 2013
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 23 March 2013 at 02:34:56 UTC, Adam D. Ruppe wrote:

 On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

 I think someone will be happy to use D instead of C/C++ on the 
 web for performance-sensitive code, like games.


 If it compiles to any kind of javascript it is a mistake to 
 think they'll be a performance boost over just writing 
 javascript, with or without annotations. Odds are there will be 
 leaky abstractions in the compile process that can hurt speed.


The DeltaBlue benchmark written in Dart, translated to JS using 
dart2js, and run on V8 actually just started running faster than 
handwritten JS running on V8.



Of course, the handwritten JS could be optimized to match 
whatever dart2js is doing but it's an interesting result.
Mar 23 2013
prev sibling next sibling parent "Faux Amis" <e mail.com> writes:
On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

 So given the LDC2 project, maybe with LDC+Emscripten+asm.js 
 there is a chance to see D on the web. I think someone will be 
 happy to use D instead of C/C++ on the web for 
 performance-sensitive code, like games. This is a small window 
 of opportunity for D.

 Bye,
 bearophile



I think this is very interesting but needs a dedicated site with 
some awesome examples, otherwise it will just be a nice idea.

Maybe vibe.d could play a significant role here.
Mar 24 2013
prev sibling next sibling parent reply "Kirill" <bribeme gmail.com> writes:
back to the original, will d compile to asm.js?




On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

 Maybe you remember the NaCl or PNaCl plug-in from Google, that 
 allows to safely run code at near native speed on the browser 
 (only 10-30% speed loss, in a probably safe sandbox). This 
 plug-in seems interesting, but so far I think it's not getting 
 a lot of traction, and it seems Mozilla is not interested in it.

 Now on Reddit they have linked "asm.js". It's an easy to 
 compile subset of JavaScript, that contains type annotations 
 (inside comments, so it's still valid standard JavaScript). 
 Mozilla has created a modified version of its JIT that 
 recognizes asm.js code and compiles it ahead of time to give, 
 they say, about half the speed of native code (if it's not 
 recognized, it's seen as normal JS). Even if this speed will 
 increase a little with time, I think it will keep being a 
 little slower than NaCl code, but maybe for lot of people the 
 speed of asm.js will be enough (and the safety of NaCl is not 
 so certain).

 A modified version of Emscripten (a LLVM bytecode to JavaScript 
 compiler) outputs asm.js. So if you have C/C++ code, with 
 Emscripten and some parts of LLVM you compile it to asm.js, and 
 then Firefox Nightly recognizes it (there is an annotation).

 So given the LDC2 project, maybe with LDC+Emscripten+asm.js 
 there is a chance to see D on the web. I think someone will be 
 happy to use D instead of C/C++ on the web for 
 performance-sensitive code, like games. This is a small window 
 of opportunity for D.

 Bye,
 bearophile
Mar 28 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/28/2013 04:47 PM, Kirill wrote:

 back to the original, will d compile to asm.js?
 ...


Eventually.
Mar 28 2013
prev sibling parent reply "Masahiro Nakagawa" <repeatedly gmail.com> writes:
ABA-san tried LDC+Emscripten+asm.js.

http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)

LDC has some limitations but this SDL code works :)


Masahiro

On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:

 So given the LDC2 project, maybe with LDC+Emscripten+asm.js 
 there is a chance to see D on the web. I think someone will be 
 happy to use D instead of C/C++ on the web for 
 performance-sensitive code, like games. This is a small window 
 of opportunity for D.

 Bye,
 bearophile
Mar 31 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Masahiro Nakagawa:


 ABA-san tried LDC+Emscripten+asm.js.

 http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)

 LDC has some limitations but this SDL code works :)


 Masahiro


Very good.

Is is visible the resulting javascript able to run on the 
browswer?


This is a part translated with Google Translate:


Problem of the time being, where is moss Emscripten writing 
class as I wrote at the beginning. The moss just write an empty 
class that does not contain anything that I downright difficult. 
I guess the difference is the treatment of class in Clang and 
LDC.<



What's the problem with classes and LDC?

Bye,
bearophile
Mar 31 2013
parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Sunday, 31 March 2013 at 12:56:46 UTC, bearophile wrote:

 Masahiro Nakagawa:


 ABA-san tried LDC+Emscripten+asm.js.

 http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)

 LDC has some limitations but this SDL code works :)


 Masahiro


 Very good.

 Is is visible the resulting javascript able to run on the 
 browswer?


Yes. The window which has "Nightly" menu in top picture is his 
browser.


 This is a part translated with Google Translate:


Problem of the time being, where is moss Emscripten writing 
class as I wrote at the beginning. The moss just write an empty 
class that does not contain anything that I downright 
difficult. I guess the difference is the treatment of class in 
Clang and LDC.<



 What's the problem with classes and LDC?


I'm not sure.

He tried to use D's class but translating LLVM to JavaScript via 
Emscripten failed.
He guesses internal class representation is different between LDC 
and Clang.
Mar 31 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 31 Mar 2013 14:32:14 +0200
"Masahiro Nakagawa" <repeatedly gmail.com> wrote:


 ABA-san tried LDC+Emscripten+asm.js.
 
 http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)
 
 LDC has some limitations but this SDL code works :)
 


Wow, that's awesome. D SDL running as client-side web.

I hope the class issues get fixed because then I may never have any
need to use Haxe again.

A few years ago, back when Flash was still relevant, I did something
that required Flash and PHP, so I used Haxe. It was far better than
using Flash/PHP directly, but it's still nowhere near as nice as D. Now
I'm finally doing D (with Vibe.d) for server-side stuff, so if I ever
need to do a Flash-like thing again (which I'd obviously do as HTML5 at
this point), then I'd love to do it with LDC+Emscripten+asm.js like
ABA-san is. Obviously wouldn't have the speed or low-level benefits of
D, but it would be far more pleasant.
Mar 31 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 Obviously wouldn't have the speed or low-level benefits
 of D, but it would be far more pleasant.


If Mozilla does well its work on asm.js, when you are using 
floating point values it may become faster than D compiled with 
DMD (as LuaJIT is) :-)

Bye,
bearophile
Mar 31 2013
prev sibling parent safari customer service <laxmanpratap6251 gmail.com> writes:
//Include LCD library
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup() {
   // set up the LCD's number of columns and rows:
   lcd.begin(16, 2);
   // Print a message to the LCD.
   lcd.print("Hello World!");
}

void loop() {
   // set the cursor to column 0, line 1
   // (note: line 1 is the second row, since counting begins with 
0):
   lcd.setCursor(0, 1);
   //Print a message to second line of LCD
   lcd.print("Codebender");
}
foe more information 
https://babasupport.org/browser/safari-customer-service/176
Mar 27 2018