www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Experiments with emscripten and D

reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
This is SDL and std.algorithm code translated to JavaScript with 
emscripten. I've used the latest git versions of LDC and emscripten (the 
latter needed some modifications).

https://gist.github.com/pszturmaj/6244260
https://gist.github.com/pszturmaj/6244266

I couldn't manage to post it as single gist, and it seems there's a bug 
in the sdl.html gist (it looks empty). Just click Download Gist or '< >' 
icon (view raw) and save it as sdl.html.

Then open sdl.html in the web browser. It should print sorted and mapped 
array contents and run simple graphics demo.

I'm starting to work on this to fix the rest of the druntime so it can 
work under JS VM. Any help with this will be appreciated :-)
Aug 15 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Piotr Szturmaj:

 Then open sdl.html in the web browser. It should print sorted 
 and mapped array contents and run simple graphics demo.

Very nice. D is meant to run efficiently, but the Web is very important. There are many situations where it could be useful to run D code in a browser, so your work is important. Integration with asm.js too is useful. (Expecially when asm.js gets a garbage collection, as Mozilla says). Currently only C and C++ are perhaps the only two languages usable to write asm.js+WebGL games for the browser. This could become one of the few niches open for D. There is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in the browser. I have found some related activity from Rust people: https://github.com/mozilla/rust/issues/2235 https://github.com/Yoric/Mozilla-Student-Projects/issues/33 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html Once your work is more more completed, the dlang site could show (in a sub-page) the compiler that compiles the online examples of the docs that's able to produce html+JS on the fly from the D code written in the browser. Bye, bearophile
Aug 15 2013
next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 15.08.2013 23:45, Adam D. Ruppe pisze:
 On Thursday, 15 August 2013 at 21:36:07 UTC, bearophile wrote:
 Integration with asm.js too is useful.

Doesn't the llvm backend do that automatically now? So ldc should get that too. I thought I read that llvm did in a blog somewhere, but I'm not sure.

Emscripten can output asm.js. Just add -s ASM_JS=1 to emcc arguments.
Aug 15 2013
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
bearophile:
 Piotr Szturmaj:

 Then open sdl.html in the web browser. It should print sorted and
 mapped array contents and run simple graphics demo.

Very nice. D is meant to run efficiently, but the Web is very important. There are many situations where it could be useful to run D code in a browser, so your work is important. Integration with asm.js too is useful. (Expecially when asm.js gets a garbage collection, as Mozilla says). Currently only C and C++ are perhaps the only two languages usable to write asm.js+WebGL games for the browser. This could become one of the few niches open for D. There is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in the browser.

Also D is garbage collected like JS. This means that high level code translation (like Adam D. Ruppe's work) should be more straightforward. On the other hand translating LLVM IR opens the possibility to mix D with C/C++ libraries.
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases... The other big advantage would having one codebase shared between server, browser (including mobile) and desktop apps.
Aug 15 2013
parent reply Gambler <fake feather.org.ru> writes:
On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
 bearophile:
 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...

Never understood the excitement about things like these. Yes, it's somewhat interesting and technically impressive, but in the end, the only language that benefits here *is* JavaScript. And it's already spreading like cancer. Why help it if you don't like it? If even 1/10th of the effort spent on compile-everything-to-JS projects was directed towards properly bringing other languages into the browser land, the web would be a much better place now.
 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.

Yes, in theory. In practice, this is just something Node.JS people came up with for advocacy of their platform. It's false. In-browser JavaScript has so many constraints imposed on it that it will never behave exactly like server-side code. (For example, your gist doesn't work in IE. Not that I use IE normally, but you get my point.) Worse, no one took time to actually design a sensible model of interaction between server and the client for a "shared" codebase. It's all a jumbled mess of ad-hoc implementations and subverted web technologies that were originally meant for an entirely different purpose. I sometimes see JS examples like this: if (imOnTheServer){ //do one thing } eles { //do another thing } //Yay, "shared" code!!! Every time I do, I get the urge to abandon programming and change my occupation.
Aug 17 2013
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 17.08.2013 16:42, Gambler pisze:
 On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
 bearophile:
 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...

Never understood the excitement about things like these. Yes, it's somewhat interesting and technically impressive, but in the end, the only language that benefits here *is* JavaScript. And it's already spreading like cancer. Why help it if you don't like it? If even 1/10th of the effort spent on compile-everything-to-JS projects was directed towards properly bringing other languages into the browser land, the web would be a much better place now.

It's not about helping JavaScript. It's about using another language to do client side scripting. I hate JS, I really don't like to write bigger applications in it. What happens when you forget a semicolon or a comma? Or make some typos? It silently breaks. I don't care if there are tools to help with it. It's still a mess. Did you see WAT (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here are some examples of JS "additions" which WAT demonstrated: [] + [] // yields empty string [] + {} // [object Object] {} + [] // 0 {} + {} // NaN Seriously, WTF! And again, I don't want to write in it, but I _must_ use it. I just want to use another language that translates to JS. There are many of them already. Still, no one is even close to D in its usefulness. The whole problem is that you need to write a web applications _now_, when the only supported languages for the web is JS. You really don't have a choice. Even if other languages could be widely supported from today, you'd still have to support older browsers. This means JS will stay in for another couple of years.
 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.

Yes, in theory. In practice, this is just something Node.JS people came up with for advocacy of their platform. It's false. In-browser JavaScript has so many constraints imposed on it that it will never behave exactly like server-side code. (For example, your gist doesn't work in IE. Not that I use IE normally, but you get my point.)

Obviously, you can't share every possible code. It's about sharing the cross cutting parts. Imagine an application with a server, web frontend and desktop frontend. With shared codebases, you could write one client code. Just use the same abstractions for the web and for the desktop. Then you can create similar interfaces from the same codebase. It's a huge win. Duplicating efforts is tiresome, error prone and obviously takes time.
 Worse, no one took time to actually design a sensible model of
 interaction between server and the client for a "shared" codebase. It's
 all a jumbled mess of ad-hoc implementations and subverted web
 technologies that were originally meant for an entirely different
 purpose. I sometimes see JS examples like this:

 if (imOnTheServer){
      //do one thing
 } eles {
      //do another thing
 } //Yay, "shared" code!!!

 Every time I do, I get the urge to abandon programming and change my
 occupation.

This is not a new idea. Morfik is a webdev tool that automatically splits your code to the server and JS. I remember it was available in 2005. Also, there is Opa language. I don't see anything wrong with cross platform code. For D example, I'd imagine it could look like this: void showMsg(string s) { version (JS) js.alert(s); else YourDesktopWidgetToolkit.showMessageDialog(s); } void main() { showMsg("hello world"); } Compiled with a regular compiler and GTK, will show a dialog. Compiled with emscripten-like compiler will show a message in the browser.
Aug 17 2013
next sibling parent reply Gambler <fake feather.org.ru> writes:
On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:
 W dniu 17.08.2013 16:42, Gambler pisze:
 On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
 bearophile:
 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in
 the
 browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...

Never understood the excitement about things like these. Yes, it's somewhat interesting and technically impressive, but in the end, the only language that benefits here *is* JavaScript. And it's already spreading like cancer. Why help it if you don't like it? If even 1/10th of the effort spent on compile-everything-to-JS projects was directed towards properly bringing other languages into the browser land, the web would be a much better place now.

It's not about helping JavaScript. It's about using another language to do client side scripting. I hate JS, I really don't like to write bigger applications in it. What happens when you forget a semicolon or a comma? Or make some typos? It silently breaks. I don't care if there are tools to help with it. It's still a mess. Did you see WAT (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here are some examples of JS "additions" which WAT demonstrated: [] + [] // yields empty string [] + {} // [object Object] {} + [] // 0 {} + {} // NaN Seriously, WTF!

WAT is one of my favorite language talks of all times. So we're on the same page here. But I don't think compiling D to JavaScript is a viable long-term solution. 1. The more languages compile to JS, the more powerful it becomes and the harder it will be to replace JS with something better. People will spend more money on optimizing its (not D's) performance, developing its (not D's) APIs for stuff like sound and graphics. This is already happening. I recently interviewed a junior developer for a position that had nothing to do with JavaScript. At some point during the interview he said: "JavaScript is the future of everything". Yeah, it's the actual phrasing he used. That's what some people believe in. 2. Compiling things to an intermediate language creates a whole host of new problems you don't have originally. How do you debug? How do you print an accurate stack trace? Etc. 3. Even if the tool-chain is perfect, a lot of real work in the browser is done by calling APIs. If those APIs are designed for JavaScript, their usage will not be idiomatic inside translated code unless you manually create wrappers. It would still be fine if the whole thing hand some kind of gradual upgrade path that led to using pure D, but I don't see such path.
 And again, I don't want to write in it, but I _must_ use it. I just want
 to use another language that translates to JS. There are many of them
 already. Still, no one is even close to D in its usefulness.

My personal strategy to mitigate the horrors of JavaScript is to use progressive enhancement and write small, targeted JS libraries that are invoked declaratively (i.e. you include them, but then it's all about HTML markup and there is no application-specific JS). Contrary to popular opinion, this approach is capable of creating very efficient and very dynamic websites.
 The whole problem is that you need to write a web applications _now_,
 when the only supported languages for the web is JS. You really don't
 have a choice. Even if other languages could be widely supported from
 today, you'd still have to support older browsers. This means JS will
 stay in for another couple of years.

If things don't change trajectory, I'm afraid JS will not just "stay for a couple of years". It will become de-facto standard for server-side web computing and displace all other languages in that domain. In the company I work for, there is already a number of people calling to rewrite all the web app for Node. I don't see a single tangible benefit coming out of it if, though. It would be a maintainability nightmare.
 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.

Yes, in theory. In practice, this is just something Node.JS people came up with for advocacy of their platform. It's false. In-browser JavaScript has so many constraints imposed on it that it will never behave exactly like server-side code. (For example, your gist doesn't work in IE. Not that I use IE normally, but you get my point.)

Obviously, you can't share every possible code. It's about sharing the cross cutting parts. Imagine an application with a server, web frontend and desktop frontend. With shared codebases, you could write one client code. Just use the same abstractions for the web and for the desktop. Then you can create similar interfaces from the same codebase. It's a huge win. Duplicating efforts is tiresome, error prone and obviously takes time.

This is another reason why I try to design everything using progressive enhancement. It results in very little duplication between client-side and server-side code. Each side has a clearly designated purpose and they rarely overlap. I wish there were more JS libraries that encourages this kind of development style, though.
 Worse, no one took time to actually design a sensible model of
 interaction between server and the client for a "shared" codebase. It's
 all a jumbled mess of ad-hoc implementations and subverted web
 technologies that were originally meant for an entirely different
 purpose. I sometimes see JS examples like this:

 if (imOnTheServer){
      //do one thing
 } eles {
      //do another thing
 } //Yay, "shared" code!!!

 Every time I do, I get the urge to abandon programming and change my
 occupation.

This is not a new idea. Morfik is a webdev tool that automatically splits your code to the server and JS. I remember it was available in 2005. Also, there is Opa language. I don't see anything wrong with cross platform code. For D example, I'd imagine it could look like this: void showMsg(string s) { version (JS) js.alert(s); else YourDesktopWidgetToolkit.showMessageDialog(s); } void main() { showMsg("hello world"); } Compiled with a regular compiler and GTK, will show a dialog. Compiled with emscripten-like compiler will show a message in the browser.

What you're talking about is compiling the same code to run in the browser and as a standalone client. But that's not the same as running the same code on the client and server side, because in that case there would be message sender code (on the server) and message receiver code (on the client). They would need to communicate in some manner. That's not a trivial problem to solve.
Aug 17 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 17.08.2013 23:05, Gambler pisze:
 On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:
 W dniu 17.08.2013 16:42, Gambler pisze:
 On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
 bearophile:
 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in
 the
 browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...

Never understood the excitement about things like these. Yes, it's somewhat interesting and technically impressive, but in the end, the only language that benefits here *is* JavaScript. And it's already spreading like cancer. Why help it if you don't like it? If even 1/10th of the effort spent on compile-everything-to-JS projects was directed towards properly bringing other languages into the browser land, the web would be a much better place now.

It's not about helping JavaScript. It's about using another language to do client side scripting. I hate JS, I really don't like to write bigger applications in it. What happens when you forget a semicolon or a comma? Or make some typos? It silently breaks. I don't care if there are tools to help with it. It's still a mess. Did you see WAT (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here are some examples of JS "additions" which WAT demonstrated: [] + [] // yields empty string [] + {} // [object Object] {} + [] // 0 {} + {} // NaN Seriously, WTF!

WAT is one of my favorite language talks of all times. So we're on the same page here. But I don't think compiling D to JavaScript is a viable long-term solution. 1. The more languages compile to JS, the more powerful it becomes and the harder it will be to replace JS with something better. People will spend more money on optimizing its (not D's) performance, developing its (not D's) APIs for stuff like sound and graphics. This is already happening. I recently interviewed a junior developer for a position that had nothing to do with JavaScript. At some point during the interview he said: "JavaScript is the future of everything". Yeah, it's the actual phrasing he used. That's what some people believe in. 2. Compiling things to an intermediate language creates a whole host of new problems you don't have originally. How do you debug? How do you print an accurate stack trace? Etc.

This is known problem and many JS-like languages use "source maps" to solve it.
 3. Even if the tool-chain is perfect, a lot of real work in the browser
 is done by calling APIs. If those APIs are designed for JavaScript,
 their usage will not be idiomatic inside translated code unless you
 manually create wrappers.

Yes, but we don't want to be strictly idiomatic. We just want to call JS code (modify the DOM, enable a button, or interface to JS widget toolkit). Idiomatic JS code more or less boils down to creating objects and calling functions. GWT is another example of such effort. It translates Java code to JS. "GWT is used by many products at Google, including AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, Blogger." - from GWT website.
 It would still be fine if the whole thing hand some kind of gradual
 upgrade path that led to using pure D, but I don't see such path.

There must be a first step :-)
 And again, I don't want to write in it, but I _must_ use it. I just want
 to use another language that translates to JS. There are many of them
 already. Still, no one is even close to D in its usefulness.

My personal strategy to mitigate the horrors of JavaScript is to use progressive enhancement and write small, targeted JS libraries that are invoked declaratively (i.e. you include them, but then it's all about HTML markup and there is no application-specific JS). Contrary to popular opinion, this approach is capable of creating very efficient and very dynamic websites.

This approach is limiting in some scenarios. Think about RIAs and interfacing to existing JS libraries.
 The whole problem is that you need to write a web applications _now_,
 when the only supported languages for the web is JS. You really don't
 have a choice. Even if other languages could be widely supported from
 today, you'd still have to support older browsers. This means JS will
 stay in for another couple of years.

If things don't change trajectory, I'm afraid JS will not just "stay for a couple of years". It will become de-facto standard for server-side web computing and displace all other languages in that domain. In the company I work for, there is already a number of people calling to rewrite all the web app for Node. I don't see a single tangible benefit coming out of it if, though. It would be a maintainability nightmare.

Yes it would be a mess. But, IMHO even if great number of people talk about "JS everywhere" it's not going to happen. Nobody wants to rewrite tens of thousands lines of code if it already works. Why create the same product multiple times? I understand rewriting JS to other lang, but not the other way.
 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.

Yes, in theory. In practice, this is just something Node.JS people came up with for advocacy of their platform. It's false. In-browser JavaScript has so many constraints imposed on it that it will never behave exactly like server-side code. (For example, your gist doesn't work in IE. Not that I use IE normally, but you get my point.)

Obviously, you can't share every possible code. It's about sharing the cross cutting parts. Imagine an application with a server, web frontend and desktop frontend. With shared codebases, you could write one client code. Just use the same abstractions for the web and for the desktop. Then you can create similar interfaces from the same codebase. It's a huge win. Duplicating efforts is tiresome, error prone and obviously takes time.

This is another reason why I try to design everything using progressive enhancement. It results in very little duplication between client-side and server-side code. Each side has a clearly designated purpose and they rarely overlap. I wish there were more JS libraries that encourages this kind of development style, though.

For client/server this is a regular approach if you don't take a desktop frontend into account. Otherwise you'd have two client-side frontends, desktop and the web and they must overlap.
 Worse, no one took time to actually design a sensible model of
 interaction between server and the client for a "shared" codebase. It's
 all a jumbled mess of ad-hoc implementations and subverted web
 technologies that were originally meant for an entirely different
 purpose. I sometimes see JS examples like this:

 if (imOnTheServer){
       //do one thing
 } eles {
       //do another thing
 } //Yay, "shared" code!!!

 Every time I do, I get the urge to abandon programming and change my
 occupation.

This is not a new idea. Morfik is a webdev tool that automatically splits your code to the server and JS. I remember it was available in 2005. Also, there is Opa language. I don't see anything wrong with cross platform code. For D example, I'd imagine it could look like this: void showMsg(string s) { version (JS) js.alert(s); else YourDesktopWidgetToolkit.showMessageDialog(s); } void main() { showMsg("hello world"); } Compiled with a regular compiler and GTK, will show a dialog. Compiled with emscripten-like compiler will show a message in the browser.

What you're talking about is compiling the same code to run in the browser and as a standalone client. But that's not the same as running the same code on the client and server side, because in that case there would be message sender code (on the server) and message receiver code (on the client). They would need to communicate in some manner. That's not a trivial problem to solve.

I don't know, but you probably meant automatic splitting a single function to client and server code. This is not what I want (yet ;-)). Communication would be done regular way such as this: ran in the web browser: version(JS) string getData(string id) { // this would need async to blocking code transform return js.ajaxRequest("/getData", id); } ran on the server: void handleRequest(Request req) { if (req.relativeUrl == "/getData") { auto data = db.getData(req.requestData /* id */); req.respond(data); } } Nothing magical here.
Aug 17 2013
prev sibling parent Gambler <fake feather.org.ru> writes:
On 8/18/2013 12:52 AM, deadalnix wrote:
 On Saturday, 17 August 2013 at 16:43:14 UTC, Piotr Szturmaj wrote:
 What happens when you forget a semicolon or a comma? Or make some
 typos? It silently breaks. I don't care if there are tools to help
 with it. It's still a mess. Did you see WAT
 (https://www.destroyallsoftware.com/talks/wat) ? If not, please do.
 Here are some examples of JS "additions" which WAT demonstrated:

 [] + [] // yields empty string
 [] + {} // [object Object]
 {} + [] // 0
 {} + {} // NaN

 Seriously, WTF!

I could explain, but I'm not sure you are interested. The ambiguity on that one come from {} being either an object literal or a block statement.

This is what slays me about JavaScritpt community. There is always someone who says "I can explain!" and starts posting type conversion trivia. Which is irrelevant, because no one cares *how* exactly this happens. What's important is *why* and there are no graceful explanations for that. JavaScript's type system is a bloody mess. [0, -1, -2].sort() returns [-1, -2, 0]. ["1", "2", "3", "4", "5", "6", "7", "8", "9"].map(parseInt) returns [1, NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN]. 2147483648 | 0 returns -2147483648. But I'm not even sure that's the worst part of the language. I think the absolute worst aspect of JS is that it's missing huge chunks of *basic* functionality, so everyone invents their own "design patterns" by abusing the hell of what's available. Actual example from StackOverflow with 145 upvotes: var CONFIG = (function() { var private = { 'MY_CONST': '1', }; return { get: function(name) { return private[name]; } }; })(); alert(CONFIG.get('MY_CONST')); //I invented constants!!! So in the end every project ends up using their own little set of ugly hacks that's both hard to read and differs from whatever everyone else is doing.
 I feel pretty confident I can do a wat speech for D.

Not with such succinct, hilarious, obviously broken examples, I bet.
 Obviously, you can't share every possible code. It's about sharing the
 cross cutting parts. Imagine an application with a server, web
 frontend and desktop frontend. With shared codebases, you could write
 one client code. Just use the same abstractions for the web and for
 the desktop. Then you can create similar interfaces from the same
 codebase. It's a huge win. Duplicating efforts is tiresome, error
 prone and obviously takes time.

It has already been done, but didn't caught up. Actually I can't even find theses project in google, so I guess ti was a compete fail. It worked, but cause many problem, especially securitywise.

Aug 18 2013
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 17.08.2013 16:42, Gambler pisze:
 (For example, your gist doesn't
 work in IE. Not that I use IE normally, but you get my point.)

This is because the code was compiled with typed arrays support. It's possible to compile without TA support and then it will work in IE.
Aug 17 2013
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 18.08.2013 03:58, Adam D. Ruppe pisze:
 I wonder how hard it would be to write that. Searching the web for kvm
 though always assumes qemu. No, I want to write a super-small qemu, and
 I don't care if it can't boot linux. How hard can it be?

Someone has written an LLVM backend for DCPU-16 and here's the JS emulator of it: https://github.com/mappum/DCPU-16
Aug 17 2013
prev sibling parent Gambler <fake feather.org.ru> writes:
On 8/17/2013 5:16 PM, John Colvin wrote:
 On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:
 On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
 And you'd have to sandbox the code since arbitrary D code running wild
 on the user's computer is a Bad Thing(tm). Which runs into GC-related
 issues when your client is a low-memory handheld device. Though arguably
 this would still be an improvement over JS, since an interpreted
 language necessarily uses more resources.

You are getting pretty close to NaCl idea :)

Yeah, I was thinking that :p NaCl seems designed mostly as native extensions for the html/js/css world. I was thinking bigger: The browser as a (transient, if appropriate) application delivery system.

IMO, fixing the web and creating a simple/secure delivery/sandboxing system for native apps are two different tasks. Both are very much needed, but the solutions are unlikely to overlap. MS Research is working on several projects for app delivery. Joanna Rutkowska has her Cubes project, which sounds very, very interesting. None of those will fix the problems Web is facing, though. (Aside from taking away the need for thick-client-implemented-in-JS applications.)
Aug 18 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 August 2013 at 21:36:07 UTC, bearophile wrote:
 Integration with asm.js too is useful.

Doesn't the llvm backend do that automatically now? So ldc should get that too. I thought I read that llvm did in a blog somewhere, but I'm not sure.
Aug 15 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2f78a25604e04e4085cb4
Content-Type: text/plain; charset=UTF-8

On 16 August 2013 07:55, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:

 bearophile:

  Piotr Szturmaj:
  Then open sdl.html in the web browser. It should print sorted and
 mapped array contents and run simple graphics demo.

Very nice. D is meant to run efficiently, but the Web is very important. There are many situations where it could be useful to run D code in a browser, so your work is important. Integration with asm.js too is useful. (Expecially when asm.js gets a garbage collection, as Mozilla says). Currently only C and C++ are perhaps the only two languages usable to write asm.js+WebGL games for the browser. This could become one of the few niches open for D. There is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in the browser.

Also D is garbage collected like JS. This means that high level code translation (like Adam D. Ruppe's work) should be more straightforward. On the other hand translating LLVM IR opens the possibility to mix D with C/C++ libraries. I have found some related activity from Rust people:
 https://github.com/mozilla/**rust/issues/2235<https://github.com/mozilla/rust/issues/2235>
 https://github.com/Yoric/**Mozilla-Student-Projects/**issues/33<https://github.com/Yoric/Mozilla-Student-Projects/issues/33>
 https://mail.mozilla.org/**pipermail/rust-dev/2012-April/**001607.html<https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html>

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases... The other big advantage would having one codebase shared between server, browser (including mobile) and desktop apps.

^^ this! I've been looking into this too recently. --001a11c2f78a25604e04e4085cb4 Content-Type: text/html; charset=UTF-8 <div dir="ltr">On 16 August 2013 07:55, Piotr Szturmaj <span dir="ltr">&lt;<a href="mailto:bncrbme jadamspam.pl" target="_blank">bncrbme jadamspam.pl</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">bearophile:<div class="im"><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Piotr Szturmaj:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then open sdl.html in the web browser. It should print sorted and<br> mapped array contents and run simple graphics demo.<br> </blockquote> <br> Very nice. D is meant to run efficiently, but the Web is very important.<br> There are many situations where it could be useful to run D code in a<br> browser, so your work is important.<br> <br> Integration with asm.js too is useful. (Expecially when asm.js gets a<br> garbage collection, as Mozilla says). Currently only C and C++ are<br> perhaps the only two languages usable to write asm.js+WebGL games for<br> the browser. This could become one of the few niches open for D. There<br> is also WebCL (<a href="http://www.khronos.org/webcl/" target="_blank">http://www.khronos.org/webcl/</a> ) for heavy computations in<br> the browser.<br> </blockquote> <br></div> Also D is garbage collected like JS. This means that high level code translation (like Adam D. Ruppe&#39;s work) should be more straightforward. On the other hand translating LLVM IR opens the possibility to mix D with C/C++ libraries.<div class="im"> <br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I have found some related activity from Rust people:<br> <a href="https://github.com/mozilla/rust/issues/2235" target="_blank">https://github.com/mozilla/<u></u>rust/issues/2235</a><br> <a href="https://github.com/Yoric/Mozilla-Student-Projects/issues/33" target="_blank">https://github.com/Yoric/<u></u>Mozilla-Student-Projects/<u></u>issues/33</a><br> <a href="https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/rust-dev/2012-April/<u></u>001607.html</a><br> <br> Once your work is more more completed, the dlang site could show (in a<br> sub-page) the compiler that compiles the online examples of the docs<br> that&#39;s able to produce html+JS on the fly from the D code written in the<br> browser.<br> </blockquote> <br></div> Yes, and it could be used to write rich web applications (which is the reason I&#39;m working on it). JavaScript certainly wasn&#39;t created for big codebases...<br> <br> The other big advantage would having one codebase shared between server, browser (including mobile) and desktop apps.<br> </blockquote></div><br></div><div class="gmail_extra">^^ this!</div><div class="gmail_extra">I&#39;ve been looking into this too recently.</div></div> --001a11c2f78a25604e04e4085cb4--
Aug 15 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
 Every time I do, I get the urge to abandon programming and 
 change my
 occupation.

My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess. --rt
Aug 17 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:
 On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
Every time I do, I get the urge to abandon programming and change
my occupation.

My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess.

It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Aug 17 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:
 On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:
 On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
Every time I do, I get the urge to abandon programming and 
change
my occupation.

My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess.

It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T

How do we fix it? We have a great language here, let's revolutionise the web :p
Aug 17 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
 On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:
On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:
On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
Every time I do, I get the urge to abandon programming and change
my occupation.

My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess.

It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T

How do we fix it? We have a great language here, let's revolutionise the web :p

Yeah! vibe.d FTW! :) And the client-side version thereof. :) T -- Bomb technician: If I'm running, try to keep up.
Aug 17 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:
 On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
 On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:
On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:
On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
Every time I do, I get the urge to abandon programming and 
change
my occupation.

My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess.

It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T

How do we fix it? We have a great language here, let's revolutionise the web :p

Yeah! vibe.d FTW! :) And the client-side version thereof. :) T

Yeah the server-side is relatively easy to pull off, seeing as you're completely in control there. The client side is an eensy little bit harder haha. It would probably require heavily modifying/creating a new web-browser and then convincing people to use it. I wonder how powerful browser extensions can be these days...
Aug 17 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:
 On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:
On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:



It's just like Nick Sabalausky always likes to rant about. In 1975,
we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
applications ran rather slowly.  Then processor speed increased
exponentially, RAM increased exponentially, and today we have
64-bit computers with 4GHz CPUs (and multicore!) and who knows how
many GBs of RAM, and our (web) applications run at about the same
speed as in 1975.  Clearly, *something* is very, very wrong with
this picture.




How do we fix it? We have a great language here, let's revolutionise
the web :p

Yeah! vibe.d FTW! :) And the client-side version thereof. :)


 Yeah the server-side is relatively easy to pull off, seeing as
 you're completely in control there.
 
 The client side is an eensy little bit harder haha. It would
 probably require heavily modifying/creating a new web-browser and
 then convincing people to use it.
 
 I wonder how powerful browser extensions can be these days...

Hmm. That's an idea, write an extension that can run code through rdmd. (You have to deliver the source rather than the object code, since you don't know what OS your client is running on.) Requiring an extension puts it in the same boat as Flash, though. :-( And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). Which runs into GC-related issues when your client is a low-memory handheld device. Though arguably this would still be an improvement over JS, since an interpreted language necessarily uses more resources. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Aug 17 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. Though 
 arguably
 this would still be an improvement over JS, since an interpreted
 language necessarily uses more resources.

You are getting pretty close to NaCl idea :)
Aug 17 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
 On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:
 On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:
On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh 
wrote:



It's just like Nick Sabalausky always likes to rant about. 
In 1975,
we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, 
and our
applications ran rather slowly.  Then processor speed 
increased
exponentially, RAM increased exponentially, and today we 
have
64-bit computers with 4GHz CPUs (and multicore!) and who 
knows how
many GBs of RAM, and our (web) applications run at about 
the same
speed as in 1975.  Clearly, *something* is very, very wrong 
with
this picture.




How do we fix it? We have a great language here, let's 
revolutionise
the web :p

Yeah! vibe.d FTW! :) And the client-side version thereof. :)


 Yeah the server-side is relatively easy to pull off, seeing as
 you're completely in control there.
 
 The client side is an eensy little bit harder haha. It would
 probably require heavily modifying/creating a new web-browser 
 and
 then convincing people to use it.
 
 I wonder how powerful browser extensions can be these days...

Hmm. That's an idea, write an extension that can run code through rdmd. (You have to deliver the source rather than the object code, since you don't know what OS your client is running on.)

not necessarily. The extension would know and could tell the server which version to send (with an optional fallback to code for systems that you don't have a binary ready for). It could also query shared library / dll versions. Also, you could just send llvm IR...
 Requiring an extension puts it in the same boat as Flash, 
 though. :-(

An extension today, built-in to the browser tomorrow?
 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. Though 
 arguably
 this would still be an improvement over JS, since an interpreted
 language necessarily uses more resources.


 T

most, if not all operating systems have good sandboxing, don't they? iOS sandboxes the hell out of everything and I presume android does something similar. on linux you can use selinux utility sandbox or similar.
Aug 17 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:
 On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. 
 Though arguably
 this would still be an improvement over JS, since an 
 interpreted
 language necessarily uses more resources.

You are getting pretty close to NaCl idea :)

Yeah, I was thinking that :p NaCl seems designed mostly as native extensions for the html/js/css world. I was thinking bigger: The browser as a (transient, if appropriate) application delivery system. I really dislike html and css for anything other than simple documents, it quickly feels like one big patchily supported corner-case. Anything other than simple uses ends up requiring significant abuses, even if you're lucky enough to be working in a hypothetical totally standards compliant environment. Even something as simple as a drop-down menu with persistence means either: massively abuse css OR use JS. What I'm imagining is a truly dynamic web-delivered UI with native speed and processing capability, not just a faster web-app.
Aug 17 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 21:16:59 UTC, John Colvin wrote:
 On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:
 On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. 
 Though arguably
 this would still be an improvement over JS, since an 
 interpreted
 language necessarily uses more resources.

You are getting pretty close to NaCl idea :)

Yeah, I was thinking that :p NaCl seems designed mostly as native extensions for the html/js/css world. I was thinking bigger: The browser as a (transient, if appropriate) application delivery system. I really dislike html and css for anything other than simple documents, it quickly feels like one big patchily supported corner-case. Anything other than simple uses ends up requiring significant abuses, even if you're lucky enough to be working in a hypothetical totally standards compliant environment. Even something as simple as a drop-down menu with persistence means either: massively abuse css OR use JS. What I'm imagining is a truly dynamic web-delivered UI with native speed and processing capability, not just a faster web-app.

This would still be working - to some extent, in the browser: the end user experience can be as seamless or as seperated as the developer wants. Your D app could look just like a webpage and behave just like a webpage, or it could be a totally separate window that appears to have no relation to the web as we know it. For an increasing number of users these days, the browser *is* the computer. They barely touch anything else. Nobody wants to install another program to do every little task, but they'll happily click a link to a specialised web-app. Native apps took off on mobile, but at the same time they were dying on the desktop. Now the view seems to be to want to kill them on mobile too and make everything a web-app. Perhaps we can get the best of both worlds. What I want is a true way out from the current obsession with trying to shoe-horn every possible use-case in to html/css/js with the associated necessary over-reliance on js, which is by all accounts a horrible language.
Aug 17 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
 And you'd have to sandbox the code since arbitrary D code 
 running wild on the user's computer is a Bad Thing(tm).

You have to do that with javascript anyway, just in case your impl has a security flaw. Run it in a separate process with a restricted security token and you'll be in decent shape. ...though, you know, just thinking wildly here, I wonder how well it'd work if you used a virtual machine. They are pretty quick nowadays thanks to fancy hardware and such. What if your browser extension fired up a tiny little virtual machine, ran the one process and just mapped its video framebuffer to the browser window? Then the one program can just be a standard program using a special library (I've make small executables with an unmodified dmd that can run on bare metal), no need to modify the compiler like with google's salt thing. I wonder how hard it would be to write that. Searching the web for kvm though always assumes qemu. No, I want to write a super-small qemu, and I don't care if it can't boot linux. How hard can it be? but i'd better not get too much into it, I already have other plans for the next few weeks. Gotta finish my minigui.d!
Aug 17 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 17 August 2013 at 16:43:14 UTC, Piotr Szturmaj wrote:
 What happens when you forget a semicolon or a comma? Or make 
 some typos? It silently breaks. I don't care if there are tools 
 to help with it. It's still a mess. Did you see WAT 
 (https://www.destroyallsoftware.com/talks/wat) ? If not, please 
 do. Here are some examples of JS "additions" which WAT 
 demonstrated:

 [] + [] // yields empty string
 [] + {} // [object Object]
 {} + [] // 0
 {} + {} // NaN

 Seriously, WTF!

I could explain, but I'm not sure you are interested. The ambiguity on that one come from {} being either an object literal or a block statement. I feel pretty confident I can do a wat speech for D.
 Obviously, you can't share every possible code. It's about 
 sharing the cross cutting parts. Imagine an application with a 
 server, web frontend and desktop frontend. With shared 
 codebases, you could write one client code. Just use the same 
 abstractions for the web and for the desktop. Then you can 
 create similar interfaces from the same codebase. It's a huge 
 win. Duplicating efforts is tiresome, error prone and obviously 
 takes time.

It has already been done, but didn't caught up. Actually I can't even find theses project in google, so I guess ti was a compete fail. It worked, but cause many problem, especially securitywise.
Aug 17 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:
 I feel pretty confident I can do a wat speech for D.

I can't think of many wats. There are questionable design decisions, annoying things that look like they should compile but don't (local variable alias to non-global template errors anyone?) and performance pitfalls, but nothing so gloriously broken as what javascript achieves. Coming from a C(++) perspective has prevented a lot of complete gibbering insanity from occurring. In particular, having a basic respect for data-layout at the machine level and an ethos of not doing very costly implicit type type-conversions has staved off a whole horde of crazy.
Aug 18 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 18 August 2013 at 11:21:52 UTC, John Colvin wrote:
 On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:
 I feel pretty confident I can do a wat speech for D.

I can't think of many wats. There are questionable design decisions, annoying things that look like they should compile but don't (local variable alias to non-global template errors anyone?) and performance pitfalls, but nothing so gloriously broken as what javascript achieves.

I know many of them. That is probably because I'm working on SDC, so I have to dig into dark corner of the language, nevertheless, it is really possible to do. In fact I planned to do it, but Denis Korskin warned me about the bad image it would create of D, and I have to admit he was right, so I abandoned the idea.
 Coming from a C(++) perspective has prevented a lot of complete 
 gibbering insanity from occurring. In particular, having a 
 basic respect for data-layout at the machine level and an ethos 
 of not doing very costly implicit type type-conversions has 
 staved off a whole horde of crazy.

I'm not here for nothing :D
Aug 18 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 18 August 2013 at 12:48:49 UTC, deadalnix wrote:
 On Sunday, 18 August 2013 at 11:21:52 UTC, John Colvin wrote:
 On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:
 I feel pretty confident I can do a wat speech for D.

I can't think of many wats. There are questionable design decisions, annoying things that look like they should compile but don't (local variable alias to non-global template errors anyone?) and performance pitfalls, but nothing so gloriously broken as what javascript achieves.

I know many of them. That is probably because I'm working on SDC, so I have to dig into dark corner of the language, nevertheless, it is really possible to do. In fact I planned to do it, but Denis Korskin warned me about the bad image it would create of D, and I have to admit he was right, so I abandoned the idea.

I presume they are at least documented somewhere? A page on the wiki? I'd be interested to see them myself. Who knows, maybe some of them are fixable?
 Coming from a C(++) perspective has prevented a lot of 
 complete gibbering insanity from occurring. In particular, 
 having a basic respect for data-layout at the machine level 
 and an ethos of not doing very costly implicit type 
 type-conversions has staved off a whole horde of crazy.

I'm not here for nothing :D

good point :)
Aug 18 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Aug 18, 2013 at 06:52:14AM +0200, deadalnix wrote:
[...]
 I feel pretty confident I can do a wat speech for D.

Please do, I'm curious to hear it. :) I can't think of any major WATs in D that come from the language itself. Compiler bugs, OTOH, often elicits a "wat?!" from me, one recent example being this gem from a friend: import std.algorithm, std.stdio; void main() { int[] arr = [3,4,2,1]; bool less(int a, int b) { return a < b; } bool greater(int a, int b) { return a > b; } { auto dg = &less; sort!(dg)(arr); } //this dg *should* be different from older destroyed dg //rename to dg2 and everything works as expected auto dg = &greater; sort!(dg)(arr); writeln(arr); //outputs [1,2,3,4] instead of [4,3,2,1] //change dg variable name in either place and it works //also, if you don't do the 1st sort, it works correctly even with same variable name } http://d.puremagic.com/issues/show_bug.cgi?id=10619 T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
Aug 18 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.186.1376878962.1719.digitalmars-d puremagic.com...
 On Sun, Aug 18, 2013 at 06:52:14AM +0200, deadalnix wrote:
 [...]
 I feel pretty confident I can do a wat speech for D.

Please do, I'm curious to hear it. :)

import std.algorithm : filter, map; void main() { foreach(c; map!"a"("hello")) // Identity map function static assert(c.sizeof == 4); // Passes foreach(c; filter!"true"("hello")) // Pass-all filter static assert(c.sizeof == 4); // Passes foreach(c; "hello") static assert(c.sizeof == 4); // Fails } WAT.
Aug 18 2013
prev sibling next sibling parent reply "nazriel" <spam dzfl.pl> writes:
On Thursday, 15 August 2013 at 20:21:46 UTC, Piotr Szturmaj wrote:
 This is SDL and std.algorithm code translated to JavaScript 
 with emscripten. I've used the latest git versions of LDC and 
 emscripten (the latter needed some modifications).

 https://gist.github.com/pszturmaj/6244260
 https://gist.github.com/pszturmaj/6244266

 I couldn't manage to post it as single gist, and it seems 
 there's a bug in the sdl.html gist (it looks empty). Just click 
 Download Gist or '< >' icon (view raw) and save it as sdl.html.

 Then open sdl.html in the web browser. It should print sorted 
 and mapped array contents and run simple graphics demo.

 I'm starting to work on this to fix the rest of the druntime so 
 it can work under JS VM. Any help with this will be appreciated 
 :-)

This is very interesting subject. I bet lots of people will want to help. Give a shout when you setup repository etc ;)
Aug 20 2013
next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 21.08.2013 01:43, Ramon pisze:
 I agree with those who are against it.

 For a variety of reasons, one of them being that, yes, anything that
 produces javasc*t does a) recognize js and b) embold and support it.

 Web pages are/should be about *content* not about eye candy and gadgets.
 Furthermore, increasingly many (like myself) have js filters, often in
 "brutal" mode (cutting out *all* js and enabling it expressly if
 needed/wished).

It's not about simple web pages with fancy gadgets. It's about RIAs.
 The real solution isn't to add one more way to the existing 3 gazillion
 ways for js but to create a real alternative.

This is unreal. Consider a business case: your employer wants some dynamic behavior on a web page (and it must work on IE6).
 Seen from D's perspective a D interpreter would be a start. Although,
 frankly, most web hackers won't like it; it's too unfriendly and hard,
 they want some kind of web basic (which js happens to be).

They will still use JS. I don't want to replace JS, because I want to support existing browsers.
 And why and what for? HTML5 is rich enough. If I want to put serious
 computing work on the client I'd rather put it in a web server (written
 in D). And if I just want to put fancy blabla into a browser I can chose
 from 2,5 gazillion toys.

What about Facebook? But I rather have RIAs in mind. For example: http://www.smartclient.com/#showcaseApp . Among the others are ExtJS, GWT, qooxdoo, etc. In this case code doesn't need to be very fast. It just need to be reliable and _maintainable_. All I currently want is using those RIA libraries from D code. This should give me huge productivity boost when writing _complex_ web applications. Another case is WebGL and online games. I'd rather go to hell than write and maintain 100k lines of code in JS. Even if you do not see a reason for it, there _is_ a demand for it. And money behind it.
Aug 20 2013
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 21.08.2013 01:49, Ramon pisze:
 Ha! Expanding on myself:

 Have simple web server written in D on the client and then a "D-script"
 interpreter in that server. Possibly some minimalist "friendly"
 interpreter thingy like Lua too (or optionally).

 Only problem I see: Does D compile to/for Arm w/ Android and iphone "OS"?

Don't worry. My solution just needs HTML + JS so it will work _everywhere_.
 Might be important as increasingly many users browse from their gadgets
 (rather than from their PCs)

Aug 20 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
I agree with those who are against it.

For a variety of reasons, one of them being that, yes, anything 
that produces javasc*t does a) recognize js and b) embold and 
support it.

Web pages are/should be about *content* not about eye candy and 
gadgets. Furthermore, increasingly many (like myself) have js 
filters, often in "brutal" mode (cutting out *all* js and 
enabling it expressly if needed/wished).

The real solution isn't to add one more way to the existing 3 
gazillion ways for js but to create a real alternative.
Seen from D's perspective a D interpreter would be a start. 
Although, frankly, most web hackers won't like it; it's too 
unfriendly and hard, they want some kind of web basic (which js 
happens to be).

And why and what for? HTML5 is rich enough. If I want to put 
serious computing work on the client I'd rather put it in a web 
server (written in D). And if I just want to put fancy blabla 
into a browser I can chose from 2,5 gazillion toys.
Aug 20 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
Ha! Expanding on myself:

Have simple web server written in D on the client and then a 
"D-script" interpreter in that server. Possibly some minimalist 
"friendly" interpreter thingy like Lua too (or optionally).

Only problem I see: Does D compile to/for Arm w/ Android and 
iphone "OS"?

Might be important as increasingly many users browse from their 
gadgets (rather than from their PCs)
Aug 20 2013
prev sibling parent "Ramon" <spam thanks.no> writes:
On Wednesday, 21 August 2013 at 00:41:58 UTC, Piotr Szturmaj 
wrote:
 W dniu 21.08.2013 01:49, Ramon pisze:
 Ha! Expanding on myself:

 Have simple web server written in D on the client and then a 
 "D-script"
 interpreter in that server. Possibly some minimalist "friendly"
 interpreter thingy like Lua too (or optionally).

 Only problem I see: Does D compile to/for Arm w/ Android and 
 iphone "OS"?

Don't worry. My solution just needs HTML + JS so it will work _everywhere_.
 Might be important as increasingly many users browse from 
 their gadgets
 (rather than from their PCs)


I still disagree. But I understand your point of view and wish you the best of luck. May the keyboard be with you ;)
Aug 20 2013