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 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. http://kripken.github.com/mloc_emscripten_talk/#/19 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
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 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 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
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
parent 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
prev sibling 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 "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
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 "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 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling 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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling 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 next 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. http://www.dartlang.org/performance/# 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 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 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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
prev sibling 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