www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D to Javascript converter (a hacked up dmd)

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

Daniel Murphy's microd fork of dmd, meant to output C,
made me realize it'd be fairly easy to use that same method
for other languages too.

So, I spent some time these last two weekends making it work
to put out Javascript.


See below for a copy/paste of the readme on how to get started.

A live demo:
http://arsdnet.net/dtojs/test.html

D source code:
http://arsdnet.net/dtojs/microd.d



As you can see, a lot of things work: functions, main,
most the operators, loops, if, basic data types,
even structs, classes (including inheritance), and exceptions.


Take a look at the generated javascript
http://arsdnet.net/dtojs/microd.js

It looks messy, since it uses mangled names almost everywhere.
(if you replace the mangled names with shorter things, it cuts
the size down by like 60%. Or, you can gzip it for a 10x 
reduction.
  See tools/mangledown.d in the zip, but this is raw so you can see
what it makes.)



For classes, it creates a vtable and some run time type 
information
on the Javascript object. This allows dynamic casts and virtual
functions to work like you expect in D.

You can see _Dmain in the middle of the file, and at the bottom,
you can see it is called if present, so you can have one or not 
have
one at your preference.

As you scroll down, you'll see the methods. Since I forked a C
generator, they are made and usually called as free functions,
but extern(js) (see below) are made as object properties.


Not so obvious is the runtime that's mixed in there.

Here's the D source code:
http://arsdnet.net/dtojs/object.d


It's pretty simple code. extern(js) works to let you - and other
JS things - easily interact with the outside world, since it
turns off mangling while letting you define things like loose
variadics.

There is no handwritten Javascript except for the if(_Dmain) at
the end. The rest of the runtime and library is written in D.



Speaking of library, I started something there too.

http://arsdnet.net/dtojs/browser/

the browser package generates no Javascript code. It simply
binds to existing functionality so D can use it in a more
structured manner. (object.d generates ~14kb of code when
raw. If you run mangledown on it, it goes down to about 6.)

browser.document provides some access to the browser DOM.

http://arsdnet.net/dtojs/std/

The std package is a kind of Phobos library, meant to make
source-compatible code with regular D stuff. It generates some
javascript.


I don't want to use the real Phobos though because it is fairly
large, and won't take advantage of the browser's existing library
functions. It *might* work in here though; I haven't tried.



The browser package makes no attempt at cross browser 
compatibility,
but you can test for functions like you would in real JS:

if(&document.querySelector) { we have it }



If I start to use this thing seriously, I might provide a library
wrapper that does this kind of thing.






Anyway, it works pretty well in the trivial tests I've done
so far, but I haven't used it for anything more serious.



Kinda cool though, and hasn't been that hard. The dmd compiler
isn't so bad to hack up once you get to know it.

Combined with the stuff others and I have already done for
D on the server, we might just be coming up on web apps that
use the same D everywhere!

========
Here's how to use it:

First, copy in the backend folder from the dmd.zip you
get from Digital Mars.

(You need it to compile, but I don't have a license to
distribute it myself.)


Then, run make to build the hacked dmd.



When its done, change into the "test" directory and
start to play. The makefile there shows how to build
some javascript.

../dmd -md yourfile.d

and optionally you can use my library in there from
test/browser and test/std.(add std/*.d to the dmd
command line to make sure its code is generated in.)

You can ignore most the messages it spams out; it
will do its best to generate the file anyway.

test/browser is the kind of core runtime to this,
in addition to object.d.

object.d - the stuff D expects and the basic JS language
constructs

browser/*.d - bindings to objects and functions the browser 
provides
such as the DOM.

Most global functions in the browser are found in 
browser/window.d.


std/*.d - just super minimal wrappers to browser functions laid 
out
more like Phobos.
Feb 26 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-27 04:51, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

 Daniel Murphy's microd fork of dmd, meant to output C,
 made me realize it'd be fairly easy to use that same method
 for other languages too.

 So, I spent some time these last two weekends making it work
 to put out Javascript.

Interesting, and cool. -- /Jacob Carlborg
Feb 27 2012
prev sibling next sibling parent Andrea Fontana <advmail katamail.com> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Cool!

Can you call custom (external, from 3rd party libs) JS functions from
there?
You should port jquery syntax sugar :)


Il giorno lun, 27/02/2012 alle 09.48 +0100, Jacob Carlborg ha scritto:

 On 2012-02-27 04:51, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

 Daniel Murphy's microd fork of dmd, meant to output C,
 made me realize it'd be fairly easy to use that same method
 for other languages too.

 So, I spent some time these last two weekends making it work
 to put out Javascript.

Interesting, and cool. =20

Feb 27 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:yfmgvgprfpiquakiyjlk forum.dlang.org...
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

 Daniel Murphy's microd fork of dmd, meant to output C,
 made me realize it'd be fairly easy to use that same method
 for other languages too.

 So, I spent some time these last two weekends making it work
 to put out Javascript.

This is great - it might make javascript actually usable as a platform. =D How come you didn't do this as a proper fork/branch of dmd? It seems like doing it this way would make it harder to maintain, and it certainly makes it harder to see what's been changed. It's also not too hard to strip out the backend if you want to redistribute the binary. (stub out e2ir,s2ir,glue,toobj,iasm and remove the backend specific stuff from main)
Feb 27 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:cjalubgkkdpdacsigxic forum.dlang.org...
 On Monday, 27 February 2012 at 11:32:52 UTC, Daniel Murphy wrote:
 How come you didn't do this as a proper fork/branch of dmd?

At first, I downloaded a zip of your fork just to take a look at it - I had no intention of actually modifying it. But, then I started to play around and never cleaned stuff up. /home/me/d/toys/yebblies-dmd-7723455/src That's the name of the directory where it lives on my computer :) I pushed it up to github last night right before making the ng post as a last-minute decision, figuring github would make it easier for people to look at. Redoing it as a proper fork won't be that hard; most the changes are in the one microd.c file anyway. Maybe I will next weekend.

Cool, please do.
 It's also not too hard to strip out the backend if you want to 
 redistribute
 the binary.  (stub out e2ir,s2ir,glue,toobj,iasm and remove the backend 
 specific stuff from main)

Cool. I took a quick look at doing that but just horribly broke my build. Isn't parts of ctfe implemented in glue.c though? I don't see it obviously in there, but I thought I saw something about that once.

It really shouldn't be. The big things I'm aware of that are in the wrong place in the compiler are that overrides are verified when building the vtables in the glue layer, finding 'this' inside functions is done in the glue, and a couple of things are done too early (array ops, associative array re-writes). You can pretty much just delete, e2ir, s2ir, and a couple of others, then kill everything that calls them up until main. (warning - requires reading linker speak) The main reason I left the glue layer intact in my branch is because I was constantly referring to them for the more complex parts of microD. I had a branch somewhere where I did this, but I don't think it survived.
Feb 27 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:uhqgqgsyzzxrctbeftyf forum.dlang.org...
 On Tuesday, 28 February 2012 at 03:06:12 UTC, Daniel Murphy wrote:
 Cool, please do.

I suck at using git, but I think it works now: https://github.com/adamdruppe/dmd/tree/dtojs The backend refused to die in the last 45 minutes, so I just left it there. I'm pretty sure it is up to date to real dmd now too... i hope. Anyway there it is.

Lol, I think you revered a bunch of stuff when you rebased it. But so long as future changes are done with git it should be possible to fix the history later. I'll try and fix this for you sometime this week. Hopefully this makes some sense.
Mar 03 2012
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:gsverzxcnkptoxxsucah forum.dlang.org...
 On Sunday, 4 March 2012 at 06:50:48 UTC, Daniel Murphy wrote:
 Lol, I think you revered a bunch of stuff when you rebased it.

git and I don't quite understand each other yet. $ git eat flaming death git: 'eat' is not a git command. See 'git --help'. aaaarrrggggh

https://www.semitwist.com/articles/article/view/stupid-git Normally, I just use TortoiseGit. Sooo much nicer. But it's not on Linux.
Mar 04 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 27/02/12 16:16, Adam D. Ruppe wrote:
 On Monday, 27 February 2012 at 11:32:52 UTC, Daniel Murphy wrote:
 How come you didn't do this as a proper fork/branch of dmd?

At first, I downloaded a zip of your fork just to take a look at it - I had no intention of actually modifying it. But, then I started to play around and never cleaned stuff up. /home/me/d/toys/yebblies-dmd-7723455/src That's the name of the directory where it lives on my computer :) I pushed it up to github last night right before making the ng post as a last-minute decision, figuring github would make it easier for people to look at. Redoing it as a proper fork won't be that hard; most the changes are in the one microd.c file anyway. Maybe I will next weekend.
 It's also not too hard to strip out the backend if you want to
 redistribute
 the binary. (stub out e2ir,s2ir,glue,toobj,iasm and remove the backend
 specific stuff from main)

Cool. I took a quick look at doing that but just horribly broke my build. Isn't parts of ctfe implemented in glue.c though? I don't see it obviously in there, but I thought I saw something about that once.

CTFE is entirely implemented in interpret.c. Treatment of the runtime part of (__ctfe) is in the glue layer, that's probably what you saw.
Feb 28 2012
prev sibling next sibling parent "node" <sp m.com> writes:
Does this mean I can do node.js in D? :)

On Monday, 27 February 2012 at 03:51:22 UTC, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

 Daniel Murphy's microd fork of dmd, meant to output C,
 made me realize it'd be fairly easy to use that same method
 for other languages too.

 So, I spent some time these last two weekends making it work
 to put out Javascript.


 See below for a copy/paste of the readme on how to get started.

 A live demo:
 http://arsdnet.net/dtojs/test.html

 D source code:
 http://arsdnet.net/dtojs/microd.d



 As you can see, a lot of things work: functions, main,
 most the operators, loops, if, basic data types,
 even structs, classes (including inheritance), and exceptions.


 Take a look at the generated javascript
 http://arsdnet.net/dtojs/microd.js

 It looks messy, since it uses mangled names almost everywhere.
 (if you replace the mangled names with shorter things, it cuts
 the size down by like 60%. Or, you can gzip it for a 10x 
 reduction.
  See tools/mangledown.d in the zip, but this is raw so you can 
 see
 what it makes.)



 For classes, it creates a vtable and some run time type 
 information
 on the Javascript object. This allows dynamic casts and virtual
 functions to work like you expect in D.

 You can see _Dmain in the middle of the file, and at the bottom,
 you can see it is called if present, so you can have one or not 
 have
 one at your preference.

 As you scroll down, you'll see the methods. Since I forked a C
 generator, they are made and usually called as free functions,
 but extern(js) (see below) are made as object properties.


 Not so obvious is the runtime that's mixed in there.

 Here's the D source code:
 http://arsdnet.net/dtojs/object.d


 It's pretty simple code. extern(js) works to let you - and other
 JS things - easily interact with the outside world, since it
 turns off mangling while letting you define things like loose
 variadics.

 There is no handwritten Javascript except for the if(_Dmain) at
 the end. The rest of the runtime and library is written in D.



 Speaking of library, I started something there too.

 http://arsdnet.net/dtojs/browser/

 the browser package generates no Javascript code. It simply
 binds to existing functionality so D can use it in a more
 structured manner. (object.d generates ~14kb of code when
 raw. If you run mangledown on it, it goes down to about 6.)

 browser.document provides some access to the browser DOM.

 http://arsdnet.net/dtojs/std/

 The std package is a kind of Phobos library, meant to make
 source-compatible code with regular D stuff. It generates some
 javascript.


 I don't want to use the real Phobos though because it is fairly
 large, and won't take advantage of the browser's existing 
 library
 functions. It *might* work in here though; I haven't tried.



 The browser package makes no attempt at cross browser 
 compatibility,
 but you can test for functions like you would in real JS:

 if(&document.querySelector) { we have it }



 If I start to use this thing seriously, I might provide a 
 library
 wrapper that does this kind of thing.






 Anyway, it works pretty well in the trivial tests I've done
 so far, but I haven't used it for anything more serious.



 Kinda cool though, and hasn't been that hard. The dmd compiler
 isn't so bad to hack up once you get to know it.

 Combined with the stuff others and I have already done for
 D on the server, we might just be coming up on web apps that
 use the same D everywhere!

 ========
 Here's how to use it:

 First, copy in the backend folder from the dmd.zip you
 get from Digital Mars.

 (You need it to compile, but I don't have a license to
 distribute it myself.)


 Then, run make to build the hacked dmd.



 When its done, change into the "test" directory and
 start to play. The makefile there shows how to build
 some javascript.

 ../dmd -md yourfile.d

 and optionally you can use my library in there from
 test/browser and test/std.(add std/*.d to the dmd
 command line to make sure its code is generated in.)

 You can ignore most the messages it spams out; it
 will do its best to generate the file anyway.

 test/browser is the kind of core runtime to this,
 in addition to object.d.

 object.d - the stuff D expects and the basic JS language
 constructs

 browser/*.d - bindings to objects and functions the browser 
 provides
 such as the DOM.

 Most global functions in the browser are found in 
 browser/window.d.


 std/*.d - just super minimal wrappers to browser functions laid 
 out
 more like Phobos.

Feb 27 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 27 February 2012 at 09:46:51 UTC, Andrea Fontana wrote:
 Can you call custom (external, from 3rd party libs)
 JS functions from there?

Yes, just make: extern(js) void function_name_here(...); and you can call it. For jQuery, you'd probably want to define an extern(js) class JQuery {} with all its method names. Since so many of them take strings, I think this would actually be somewhat easy.
Feb 27 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 27 February 2012 at 11:32:52 UTC, Daniel Murphy wrote:
 How come you didn't do this as a proper fork/branch of dmd?

At first, I downloaded a zip of your fork just to take a look at it - I had no intention of actually modifying it. But, then I started to play around and never cleaned stuff up. /home/me/d/toys/yebblies-dmd-7723455/src That's the name of the directory where it lives on my computer :) I pushed it up to github last night right before making the ng post as a last-minute decision, figuring github would make it easier for people to look at. Redoing it as a proper fork won't be that hard; most the changes are in the one microd.c file anyway. Maybe I will next weekend.
 It's also not too hard to strip out the backend if you want to 
 redistribute
 the binary.  (stub out e2ir,s2ir,glue,toobj,iasm and remove the 
 backend specific stuff from main)

Cool. I took a quick look at doing that but just horribly broke my build. Isn't parts of ctfe implemented in glue.c though? I don't see it obviously in there, but I thought I saw something about that once.
Feb 27 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 27 February 2012 at 12:10:17 UTC, node wrote:
 Does this mean I can do node.js in D? :)

Probably. When I did my testing, I ran the code in dmdscript and later, firefox. The javascript it outputs is pretty basic so I imagine it will work in any engine. To access the library, you can define them as extern(js) functions or classes, and then some global objects. In my code, check out src/test/browser for examples - that package is just bindings to the browser's functions. Those are translated to javascript almost exactly as you write it in D, giving access to the outside world pretty naturally. Remember though two important facts: 1) there's no optimization here. The D compiler just spits out the code tree in the new language. So, don't expect speed bonuses. 2) Not all of D works. But, a decent chunk of it does and I think it's ready for some serious playing already.
Feb 27 2012
prev sibling next sibling parent Andrea Fontana <advmail katamail.com> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Il giorno lun, 27/02/2012 alle 16.09 +0100, Adam D. Ruppe ha scritto:

 On Monday, 27 February 2012 at 09:46:51 UTC, Andrea Fontana wrote:
 Can you call custom (external, from 3rd party libs)
 JS functions from there?

Yes, just make: =20 extern(js) void function_name_here(...);

Good!
=20
 and you can call it. For jQuery, you'd probably want
 to define an extern(js) class JQuery {} with all its method
 names. Since so many of them take strings, I think this would
 actually be somewhat easy.

About jquery: i mean what about a d function similar to $() jquery function for better elements handling (instead of getElementById() )
Feb 27 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 27 February 2012 at 15:39:50 UTC, Andrea Fontana wrote:
 About jquery: i mean what about a d function similar to  $() 
 jquery
 function for better elements handling (instead of 
 getElementById() )

Have you seen my dom library? :P It's all server side but it is just awesome. Lots of convenience functions, getting elements is easy, and operating on them as a group is too, either through a wrapper struct or just using foreach yourself. I definitely want to port some of it to the javascript output. https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff the file is dom.d. It also depends on characterencodings.d. The most jquery-like interface is Document's opIndex: document[`#something .my-thing > p`].addClass("matched") .appendText("matched me!"); Though, I really think that querySelectorAll + foreach wipes out jquery's element selection advantage. querySelectorAll is in all browsers IE8 and up. Adding foreach to javascript can be done with text macro (see html.d in my github) or D->JS of course has foreach too! The zip of d->js actually breaks on foreach here, but it was an easy fix. I'll push up the changes this next weekend. Anyway, here's how it looks: foreach(element; document.querySelectorAll("#blah > p")) // do something to element
Feb 27 2012
prev sibling next sibling parent Andrea Fontana <advmail katamail.com> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Il giorno lun, 27/02/2012 alle 16.55 +0100, Adam D. Ruppe ha scritto:

 On Monday, 27 February 2012 at 15:39:50 UTC, Andrea Fontana wrote:
 About jquery: i mean what about a d function similar to  $()=20
 jquery
 function for better elements handling (instead of=20
 getElementById() )

Have you seen my dom library? :P

Of course not!
 It's all server side but it is just awesome. Lots of
 convenience functions, getting elements is easy, and
 operating on them as a group is too, either through
 a wrapper struct or just using foreach yourself.
=20
 I definitely want to port some of it to the javascript
 output.
=20
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language=

 the file is dom.d. It also depends on characterencodings.d.
=20
 The most jquery-like interface is Document's opIndex:
=20
 document[`#something .my-thing > p`].addClass("matched")
    .appendText("matched me!");
=20
=20
 Though, I really think that querySelectorAll + foreach
 wipes out jquery's element selection advantage.
=20
 querySelectorAll is in all browsers IE8 and up. Adding
 foreach to javascript can be done with text macro
 (see html.d in my github) or D->JS of course has foreach
 too!
=20
=20
 The zip of d->js actually breaks on foreach here, but
 it was an easy fix. I'll push up the changes this next
 weekend.
=20
=20
 Anyway, here's how it looks:
=20
 foreach(element; document.querySelectorAll("#blah > p"))
      // do something to element
=20

Very interesting! :)
Feb 27 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 28 February 2012 at 09:30:41 UTC, Don Clugston wrote:
 CTFE is entirely implemented in interpret.c. Treatment of the 
 runtime part of (__ctfe) is in the glue layer, that's probably 
 what you saw.

Outstanding! As a side note, I've been looking at dmdscript when I want a detailed reference on Javascript, and it is (as to be expected) written in a very similar style to dmd itself. It's very nice. I like the dmd code now that I'm getting to know it.
Feb 28 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

 Daniel Murphy's microd fork of dmd, meant to output C,
 made me realize it'd be fairly easy to use that same method
 for other languages too.

 So, I spent some time these last two weekends making it work
 to put out Javascript.

Cool! Can it compile a function to native code and JS simultaneously? I want to execute the same code on both client and server side.
Feb 28 2012
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Adam D. Ruppe wrote:
 On Tuesday, 28 February 2012 at 19:27:57 UTC, Piotr Szturmaj wrote:
 Can it compile a function to native code and JS simultaneously? I want
 to execute the same code on both client and server side.

You'd have to run dmd twice because it exits before getting to the backend when doing js. But you can run the same code: dmd -md file.d # outputs file.js dmd file.d # outputs file.exe

I see.
 You might need versions or something for library support,
 but that's just because I haven't ported much over yet.

I realize that work on project has just begun :)
 I just now tried:

 import std.algorithm;
 auto range = sort!"a < b"(["b", "a"]);
 window.alert(range.front);

 .. and it produced 44 KB of Javascript
 code that *almost* worked.

44 KB - that's not bad!
 Looks like I have to fix the dollar expression,
 but otherwise, almost usable.

Some time ago, I was interested in translation to JS, but I rather thought about binary translation, like in http://bellard.org/jslinux/. There's similar "emscripten" project which translates LLVM bytecode to JS: https://github.com/kripken/emscripten. And there's also commercial Morfik: http://en.wikipedia.org/wiki/Morfik. Perhaps you might find these links useful, if you don't know them already.
Feb 28 2012
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Adam D. Ruppe wrote:
 The reason it didn't work before wasn't just dollar, but also
 ref params. This was a bit of a pain.. without pointers, how
 can I implement this?

 After thinking on it for almost an hour, I decided on passing
 lambdas instead:

 void a(ref b) { b = 10; }

 int c = 5;
 a(c);
 assert(c == 10);


 The JS looks like this:

 function a(b) { b(10); }
 var c = 5;
 a(function(set) { if(typeof set != "undefined") c = set; return c; });
 c == 5 || _d_assert();

What about passing values within object? function a(b) { b.value = 10; } var c = 5; var wrapper = { value: c }; a(wrapper); c = wrapper.value;
Feb 28 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Adam D. Ruppe wrote:
 On Wednesday, 29 February 2012 at 03:24:17 UTC, Piotr Szturmaj wrote:
 What about passing values within object?

Yeah, that's one of the first things I thought of, but what about a more complex thing: d = a(c) + 4; where will the c=wrapper.value go? It can't go at the end of the function call now. Also, if the function call is in the middle of something, we'd have to assign the wrapper somewhere too. Suppose: d = (c = 2, a(c)); I think anything that isn't inline for the argument will be too easy to break.

Here's another try with objects: function Wrapper(value) { this.value = value; } Wrapper.prototype.valueOf = function() { return this.value; } Wrapper.prototype.toString = function() { return this.value.toString(); } function a(b) { b.value = 10 + b; } var c = new Wrapper(5); a(c); alert(c); // shows 15 but this implies that all value variables must be initialized with new Wrapper(x).
Feb 28 2012
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 29/02/2012 03:11, Adam D. Ruppe wrote:
 On Wednesday, 29 February 2012 at 02:42:38 UTC, Piotr Szturmaj wrote:
 44 KB - that's not bad!

It actually gets better: 9kb if you trim the mangled names down to size (I've written a mangle name trimmer and an unused function cutter; hello world is about 200 bytes.).

You could probably still beat that if you ran it through Google's closure compiler (on advanced!): http://closure-compiler.appspot.com/home -- Robert http://octarineparrot.com/
Feb 29 2012
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 29/02/2012 09:18, Robert Clipsham wrote:
 On 29/02/2012 03:11, Adam D. Ruppe wrote:
 On Wednesday, 29 February 2012 at 02:42:38 UTC, Piotr Szturmaj wrote:
 44 KB - that's not bad!

It actually gets better: 9kb if you trim the mangled names down to size (I've written a mangle name trimmer and an unused function cutter; hello world is about 200 bytes.).

You could probably still beat that if you ran it through Google's closure compiler (on advanced!): http://closure-compiler.appspot.com/home

I actually just tried this with: http://arsdnet.net/dtojs/microd.js Original Size: 20.14KB (2.61KB gzipped) Compiled Size: 3.05KB (1015 bytes gzipped) Pretty impressive! It did spit out 86 warnings though... Mostly: * JSC_WRONG_ARGUMENT_COUNT * JSC_USED_GLOBAL_THIS * JSC_REDECLARED_VARIABLE * JSC_NOT_A_CONSTRUCTOR (iirc to get around that you have to drop in a /** constructor */ comment before anything you want to use as a constructor for that) Good work at getting std.algorithm (mostly) working! :D -- Robert http://octarineparrot.com/
Feb 29 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Adam D. Ruppe wrote:
 But, wrapping might be fun. I could probably do & 0xff
 if and only if D otherwise forces it to be a ubyte. But,
 what about the bit pattern of negative numbers?

Take a look at WebGL's Typed Arrays. They allow explicit size integers and binary operators. The disadvantage is they're supported only on newest browsers.
Feb 29 2012
prev sibling parent sclytrack <sclytrack hotmail.com> writes:
On 02/28/2012 08:56 PM, Adam D. Ruppe wrote:
 On Tuesday, 28 February 2012 at 19:27:57 UTC, Piotr Szturmaj wrote:
 Can it compile a function to native code and JS simultaneously? I want
 to execute the same code on both client and server side.

You'd have to run dmd twice because it exits before getting to the backend when doing js. But you can run the same code: dmd -md file.d # outputs file.js dmd file.d # outputs file.exe You might need versions or something for library support, but that's just because I haven't ported much over yet. I just now tried: import std.algorithm; auto range = sort!"a < b"(["b", "a"]); window.alert(range.front); .. and it produced 44 KB of Javascript code that *almost* worked. Looks like I have to fix the dollar expression, but otherwise, almost usable.

Do you already have a name for the compiler?
Feb 28 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 28 February 2012 at 19:27:57 UTC, Piotr Szturmaj 
wrote:
 Can it compile a function to native code and JS simultaneously? 
 I want to execute the same code on both client and server side.

You'd have to run dmd twice because it exits before getting to the backend when doing js. But you can run the same code: dmd -md file.d # outputs file.js dmd file.d # outputs file.exe You might need versions or something for library support, but that's just because I haven't ported much over yet. I just now tried: import std.algorithm; auto range = sort!"a < b"(["b", "a"]); window.alert(range.front); .. and it produced 44 KB of Javascript code that *almost* worked. Looks like I have to fix the dollar expression, but otherwise, almost usable.
Feb 28 2012
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Fuck. Yes.

Combined with HTML5 <canvas> and such, this might be an awesome way to 
write web-based games.

Please do more!
Feb 28 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 02:42:38 UTC, Piotr Szturmaj 
wrote:
 44 KB - that's not bad!

It actually gets better: 9kb if you trim the mangled names down to size (I've written a mangle name trimmer and an unused function cutter; hello world is about 200 bytes.). The reason it didn't work before wasn't just dollar, but also ref params. This was a bit of a pain.. without pointers, how can I implement this? After thinking on it for almost an hour, I decided on passing lambdas instead: void a(ref b) { b = 10; } int c = 5; a(c); assert(c == 10); The JS looks like this: function a(b) { b(10); } var c = 5; a(function(set) { if(typeof set != "undefined") c = set; return c; }); c == 5 || _d_assert(); My implementation right now is a filthy hack... but std.algorithm is basically working. assumeSorted's constructor is missing for some reason, but the algorithm itself actually worked. (I spent time making class constructors work, but I think I neglected struct constructors, so probably easy fix.) But, I think the best thing to do though isn't to port phobos implementations, but instead port the interface as much as possible. sort can be a wrapper of Array.prototype.sort() from Javascript, thus letting us leave out the implementation. Odds are the native method will be faster anyway.
 Some time ago, I was interested in translation to JS, but I 
 rather thought about binary translation, like in 
 http://bellard.org/jslinux/. There's similar "emscripten" 
 project which translates LLVM bytecode to JS:

I've heard of these two, but they seem a lot bigger than I like. I want the generated JS to be as small as possible while still covering a good chunk of D features.
Feb 28 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 03:24:17 UTC, Piotr Szturmaj 
wrote:
 What about passing values within object?

Yeah, that's one of the first things I thought of, but what about a more complex thing: d = a(c) + 4; where will the c=wrapper.value go? It can't go at the end of the function call now. Also, if the function call is in the middle of something, we'd have to assign the wrapper somewhere too. Suppose: d = (c = 2, a(c)); I think anything that isn't inline for the argument will be too easy to break.
Feb 28 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 04:02:54 UTC, Piotr Szturmaj 
wrote:
 but this implies that all value variables must be initialized 
 with new Wrapper(x).

Yeah. I don't like that because it means you pay for something that you aren't necessarily going to use. Now, it could follow the variable and say, if it is going into a ref function, wrap it up like this, but that'd be a lot harder to work into the compiler. It's not a bad idea, though. If it can be arranged to only be used when needed, it would probably be better than the lambda.
Feb 28 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 09:27:53 UTC, Robert Clipsham 
wrote:
 Pretty impressive! It did spit out 86 warnings though...

A lot of it is probably the same kind of thing my "linker" does. (I call it that, but it doesn't actually *link* anything.) I get down to 6 KB running it through that. Though, they still cut it in half and there's some code rewriting in there too. Not bad. Fun fact btw: dmd -inline works on this thing too. Though, inline makes a bunch of stuff in the form of (var a = 10, etc) which is illegal in JS (and D, actually). To hack that so it worked, I simply left the var out, so it uses an implicit global variable. The D mangled names are unique so I think it will work in practice, but still, blah. Regardless, inlining functions is pretty cool. Might make things bigger however, so idk if it is actually worth it.
  * JSC_WRONG_ARGUMENT_COUNT
  * JSC_REDECLARED_VARIABLE

I threw it a bone to silence some of these, but much of it isn't actually wrong so meh. But these:
  * JSC_USED_GLOBAL_THIS
  * JSC_NOT_A_CONSTRUCTOR

don't help at all. Even if I add the /** constructor*/, it just spits even more unhelpful warnings. http://arsdnet.net/dtojs/test2.js is where I put it. (the size there is tiny because I left a lot of dead code in there; I just put a return; before my other test code.) JSC_TYPE_MISMATCH: actual parameter 1 of __d_6Object.call does not match formal parameter found : __d_6microd6MyBase required: (__d_6Object|null|undefined) at line 2 character 17 in test2.js__d_6Object.call(this, null); ^ JSC_INEXISTENT_PROPERTY: Property __d_vtbl never defined on __d_6microd6MyBase at line 3 character 0 in test2.jsthis.__d_vtbl.length = 3; I call the Object initalizer (this isn't a constructor in D. The real D compiler would just blit the Object.init to get the memory started. The D constructor is passed as an argument to be called at the end.) to set up that vtable. So, I know its all right, but it is going to warn anyway.
 Good work at getting std.algorithm (mostly) working! :D

Thanks!
Feb 29 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I found the std.algorithm problem. I skipped outputting
templated structs because it crashes my compiler.

For some reason.

microd.d(130): Error: variable t forward declaration
Segmentation fault.

Poo.

Function templates work fine, though.
Feb 29 2012
prev sibling next sibling parent reply Bystroushaak <bystrousak kitakitsune.org> writes:
 Daniel Murphy's microd fork of dmd, meant to output C

Link please.
Feb 29 2012
parent Robert Clipsham <robert octarineparrot.com> writes:
On 29/02/2012 16:56, Bystroushaak wrote:
 Daniel Murphy's microd fork of dmd, meant to output C

Link please.

https://github.com/yebblies/dmd/tree/microd -- Robert http://octarineparrot.com/
Feb 29 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 15:46:40 UTC, Adam D. Ruppe 
wrote:
 microd.d(130): Error: variable t forward declaration
 Segmentation fault.

And that's fixed... and handling if(__ctfe)... and boom! It worked. Generated 70 KB of javascript though, a lot of it is obvious garbage - global variable declarations and pieces of D code. Looks like leftover stuff from CTFE and mixins. Probably shouldn't be outputted at all, but it can be garbage collected pretty well; my simple string search one brought it down to 40 KB. Then, if I run my tools/mangledown, which replaces the D mangled names with $number$, the size goes down to 6 KB. 6 KB isn't half bad! And got the right result from a complex chunk of D code. (it just runs std.algorithm.sort on an array, but that does a LOT of fancy stuff - string lambdas, treating an array as a range, ctfe, and more.) import std.algorithm; void main() { auto range = sort!"a < b"(["hello", "adam"]); println(range.front); // "adam" } The Google thing can probably strip it more by shortening the names more than my program does. (My name shortener doesn't understand scoping - it is just a regex string replacer - so I'm conservative in what it does.) still hehehe, not bad at all. BTW, I've written basic bindings to almost everything in the core browser experience. import jslang.name = the Javascript builtins, RegExp, Array, etc. These generate no code, it is just like calling C from D. import browser.name = Browser objects like JSON, document, window, history, location, canvas, etc. Again, generates no code, but gives access and static checks. Now, I also wrote up a hack so you can do third party extensions, with minimal generated code (especially if you use dmd -inline, but even without it, it does well). import browser.document; final class MyElement { extern(js) JSElement __js_this; // JSElement is the native binding // __js_ words have special meaning - they give direct access to // javascript keywords. use with care, it might not do what you think. // here, since object.this is nonsense in JS, the compiler uses that // to output object instead - giving direct access. alias __js_this this; // alias this translates as A.member = thing. // but since member here is this, which is noop, it is just plain A. void addClass(string a) { className ~= " " ~ a; } } auto a = cast(MyElement) document.getElementById("something"); a.style.color = "green"; a.addClass("cool"); Generates (basically): // it knows it is cast from final class to final class, which // is a no-op in Javascript var a = document.getElementById("something"); a.style.color = "green"; // directly output addClass("cool", a); // the extension class is a free function function addClass(a, d_this) { d_this.className = d_this.className.concat(" ".concat(a)); } alias this is cool. You can also do a real class, but don't reinterpret cast to it - the vtbl will be missing. Instead, just new it and let the compiler do its work. This is getting pretty cool. Next challenge is the in operator. In Javascript, in returns a boolean. D expects a pointer. How can I do it efficiently? The lambda trick will work for the pointer, but I don't want to make that if we don't need it. Perhaps if the in expression is immediately cast to bool, I'll skip it. Another semanitc issue is: ubyte a = 255; a++; // we expect 0, but js will give 256. I solved division: int a = 1/2; // becomes var a = Math.floor(1/2); And since D does a really good job at keeping int and float math distinct, this is generally easy to work with. float a = 1; int b = a/2; // D requires an explicit cast here, so there's out // Math.floor opportunity! float b = a/2; // becomes just a/2. But, wrapping might be fun. I could probably do & 0xff if and only if D otherwise forces it to be a ubyte. But, what about the bit pattern of negative numbers? I could probably just ignore it, but I'd like to match as much as is reasonable.
Feb 29 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei
Feb 29 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind. -- - Alex
Feb 29 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jilnie$1fsr$1 digitalmars.com...
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

Yea, creating JS without having to actually *write* JS is a huge use-case in and of itself. (I still can't believe the web has standardized on such an absolute shit langauge. Hell, two of them if you count PHP on the server.)
Feb 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-29 18:46, Nick Sabalausky wrote:
 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jilnie$1fsr$1 digitalmars.com...
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

Yea, creating JS without having to actually *write* JS is a huge use-case in and of itself. (I still can't believe the web has standardized on such an absolute shit langauge. Hell, two of them if you count PHP on the server.)

Five if you count HTML, CSS and SQL as well. -- /Jacob Carlborg
Mar 01 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jiptfu$qrg$1 digitalmars.com...
 On 2012-02-29 18:46, Nick Sabalausky wrote:
 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jilnie$1fsr$1 digitalmars.com...
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

Yea, creating JS without having to actually *write* JS is a huge use-case in and of itself. (I still can't believe the web has standardized on such an absolute shit langauge. Hell, two of them if you count PHP on the server.)

Five if you count HTML, CSS and SQL as well.

Very true, but a far as shittiness goes, JS and PHP are in a whole other league (IMO). Actually, HTML/CSS for what they are - *document* description formats - really aren't all that bad. The only real *major* problem with HTML/CSS is not the formats themselves, but the fact that people keep abusing them as application presentation layers, which they clearly aren't and were never intended to be. (And basing an entire application around the deliberately-stateless HTTP? Seriously? WTF?) Latex isn't bad (from what little I've seen), but if people started pretending it was a presentation layer for programs, then yea, it would completely blow for that. But that's exactly what people did with HTML/CSS. So HTML and CSS get a bad reputation when really the true blame lies with the people pushing for their misuse. (Not that HTML/CSS couldn't be improved even as pure document formats.)
Mar 02 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-02 19:13, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jiptfu$qrg$1 digitalmars.com...
 On 2012-02-29 18:46, Nick Sabalausky wrote:
 "Alex Rønne Petersen"<xtzgzorex gmail.com>   wrote in message
 news:jilnie$1fsr$1 digitalmars.com...
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

Yea, creating JS without having to actually *write* JS is a huge use-case in and of itself. (I still can't believe the web has standardized on such an absolute shit langauge. Hell, two of them if you count PHP on the server.)

Five if you count HTML, CSS and SQL as well.

Very true, but a far as shittiness goes, JS and PHP are in a whole other league (IMO).

Yeah, I agree. I'm just saying, thank god I don't have to use PHP in my job. I'm using CoffeeScript instead of JavaScript whenever I can which makes it a bit more bearable. Yes I know many people here don't like CS, specially the syntax, but it fixes several of the most annoying things about JS.
 Actually, HTML/CSS for what they are - *document* description formats -
 really aren't all that bad. The only real *major* problem with HTML/CSS is
 not the formats themselves, but the fact that people keep abusing them as
 application presentation layers, which they clearly aren't and were never
 intended to be. (And basing an entire application around the
 deliberately-stateless HTTP? Seriously? WTF?)

 Latex isn't bad (from what little I've seen), but if people started
 pretending it was a presentation layer for programs, then yea, it would
 completely blow for that. But that's exactly what people did with HTML/CSS.
 So HTML and CSS get a bad reputation when really the true blame lies with
 the people pushing for their misuse. (Not that HTML/CSS couldn't be improved
 even as pure document formats.)

Yes, I think both HTML and CSS could be improved a lot. One of the most annoying things is there's no good way to handle scoping. SASS (regardless of which syntax you choose to use) makes this problem less annoying and fixes several other issues with CSS. The fact that you most likely uses a server side language to output HTML fixes many of the problems with HTML. -- /Jacob Carlborg
Mar 03 2012
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 2/29/12 2:34 PM, Alex Rønne Petersen wrote:
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

I think it's cool you can convert D to JS, but I don't see why anyone would want to do it. 1. JS is a superior language: variables are dynamic and are not bound to just one single type during their lifetime. JS objects can store any property. 2. JS funcions are much easier to write (no need to declare types) and also to pass around (no need to write "&"). If you'd like to annotate variables, you could use Closure: https://developers.google.com/closure/compiler/docs/js-for-compiler 3. With JS you don't have to compile and run your code (well, I guess you could make something smart in D for that). 4. If you write JS you can debug it in the browser. No need to track back to the original source code. 5. If you don't like JS syntax or verbosity, you can use CoffeeScript, which is just a syntax rewriter, not a language/paradigm shift: http://coffeescript.org/ 6. Javascript objects have some built-in properties that are different from D. So implementing those in D would make their performance worse (but you can always hard-code those functions into the compiler and translate them directly to their JS equivalent). The good thing about writing in D is that you could probably get some IDE for autocompletion and such. You might also like to type things instead of using dynamic types.
Mar 01 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/01/2012 07:04 PM, Ary Manzana wrote:
 I think it's cool you can convert D to JS, but I don't see why anyone
 would want to do it.

 1. JS is a superior language:
 [snip.]

Nope.
Mar 01 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-03-2012 19:04, Ary Manzana wrote:
 On 2/29/12 2:34 PM, Alex Rønne Petersen wrote:
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

I think it's cool you can convert D to JS, but I don't see why anyone would want to do it. 1. JS is a superior language: variables are dynamic and are not bound to just one single type during their lifetime. JS objects can store any property.

You're arguing with a crowd gathered around a statically typed language. I think we can predict what this argument will lead to. :)
 2. JS funcions are much easier to write (no need to declare types) and
 also to pass around (no need to write "&"). If you'd like to annotate
 variables, you could use Closure:
 https://developers.google.com/closure/compiler/docs/js-for-compiler

See the above.
 3. With JS you don't have to compile and run your code (well, I guess
 you could make something smart in D for that).

? The D -> JS converter just translates it. It's no different from running e.g. the CoffeeScript compiler.
 4. If you write JS you can debug it in the browser. No need to track
 back to the original source code.

Valid argument. Maybe we can make the D -> JS converter help in some way here?
 5. If you don't like JS syntax or verbosity, you can use CoffeeScript,
 which is just a syntax rewriter, not a language/paradigm shift:
 http://coffeescript.org/

Don't even get me started on the horrible "features" in CoffeeScript. The guy who wrote the language literally had no clue what he was doing (he admitted to reading some "make your own language" book), and it isn't much better than JavaScript in terms of odd behavior and weird design decisions.
 6. Javascript objects have some built-in properties that are different
 from D. So implementing those in D would make their performance worse
 (but you can always hard-code those functions into the compiler and
 translate them directly to their JS equivalent).

Can you be a little more specific here?
 The good thing about writing in D is that you could probably get some
 IDE for autocompletion and such. You might also like to type things
 instead of using dynamic types.

To be fair, excellent JS IDEs exist already; Visual Studio has great JS auto-completion, and ReSharper enhances it a lot too. -- - Alex
Mar 01 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-01 19:56, Alex Rønne Petersen wrote:
 On 01-03-2012 19:04, Ary Manzana wrote:
 3. With JS you don't have to compile and run your code (well, I guess
 you could make something smart in D for that).

? The D -> JS converter just translates it. It's no different from running e.g. the CoffeeScript compiler.

It's quite a difference. The semantics of CoffeeScript and JavaScript is more alike than D and JavaScript. CoffeeScript was created to be compile to JavaScript, not something you could say about D.
 4. If you write JS you can debug it in the browser. No need to track
 back to the original source code.

Valid argument. Maybe we can make the D -> JS converter help in some way here?

Similar problem with CoffeeScript, not as bad as with D since it outputs readable JavaScript.
 5. If you don't like JS syntax or verbosity, you can use CoffeeScript,
 which is just a syntax rewriter, not a language/paradigm shift:
 http://coffeescript.org/

Don't even get me started on the horrible "features" in CoffeeScript. The guy who wrote the language literally had no clue what he was doing (he admitted to reading some "make your own language" book), and it isn't much better than JavaScript in terms of odd behavior and weird design decisions.

It's way way WAY more better than JavaScript. * Class based object model * Function binding, language support for binding the this reference If CoffeeScript had only these two features it would be so much more useful than JavaScript, but it has a lot more: * Extremely short function/lambda syntax * Built-in loop comprehension * == behaves as you would expect * Existential operator * Default arguments * Variadic arguments * Object syntax * foreach loop that actually makes sense * Almost everything is an expression * No need to declare variables * Implicit returns * No need for semicolons (yeah, I know JS have this as well but most don't seem to use this feature) * Ranges * Arrays slicing
 6. Javascript objects have some built-in properties that are different
 from D. So implementing those in D would make their performance worse
 (but you can always hard-code those functions into the compiler and
 translate them directly to their JS equivalent).

Can you be a little more specific here?
 The good thing about writing in D is that you could probably get some
 IDE for autocompletion and such. You might also like to type things
 instead of using dynamic types.

To be fair, excellent JS IDEs exist already; Visual Studio has great JS auto-completion, and ReSharper enhances it a lot too.

-- /Jacob Carlborg
Mar 01 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-01 19:04, Ary Manzana wrote:
 On 2/29/12 2:34 PM, Alex Rønne Petersen wrote:
 On 29-02-2012 18:32, Andrei Alexandrescu wrote:
 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

Avoiding writing JS directly in web apps comes to mind.

I think it's cool you can convert D to JS, but I don't see why anyone would want to do it. 1. JS is a superior language: variables are dynamic and are not bound to just one single type during their lifetime. JS objects can store any property.

I really miss static typing sometimes in my day to day work (Ruby, JS, ...).
 2. JS funcions are much easier to write (no need to declare types) and
 also to pass around (no need to write "&"). If you'd like to annotate
 variables, you could use Closure:
 https://developers.google.com/closure/compiler/docs/js-for-compiler

D's new lambda syntax is way more superior than the one in JS. Most of the times I would like to be able to specify types in function declarations.
 3. With JS you don't have to compile and run your code (well, I guess
 you could make something smart in D for that).

True.
 4. If you write JS you can debug it in the browser. No need to track
 back to the original source code.

True. But if you're compiler is good enough that won't be a problem, i.e. CoffeeScript.
 5. If you don't like JS syntax or verbosity, you can use CoffeeScript,
 which is just a syntax rewriter, not a language/paradigm shift:
 http://coffeescript.org/

Already doing that. But if you're doing that you would most likley pre-compile it and have the same problems as 3. and 4.
 6. Javascript objects have some built-in properties that are different
 from D. So implementing those in D would make their performance worse
 (but you can always hard-code those functions into the compiler and
 translate them directly to their JS equivalent).

 The good thing about writing in D is that you could probably get some
 IDE for autocompletion and such. You might also like to type things
 instead of using dynamic types.

-- /Jacob Carlborg
Mar 01 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jiodnj$ric$1 digitalmars.com...
 I think it's cool you can convert D to JS, but I don't see why anyone 
 would want to do it.

 1. JS is a superior language: variables are dynamic and are not bound to 
 just one single type during their lifetime. JS objects can store any 
 property.
 2. JS funcions are much easier to write (no need to declare types) and 
 also to pass around (no need to write "&").

Are you insane or just masochistic? ;)
 3. With JS you don't have to compile and run your code (well, I guess you 
 could make something smart in D for that).

Meh. I've done a lot of web work where "no compile" is common, and I've never seen it as really being that big of a deal (unless you're using something like C++ that takes ages to compile). It's an overrated selling point of such langauges, IMO, much like "Our langauge doesn't require semicolons!" Meh, so what? Trivialities.
 4. If you write JS you can debug it in the browser. No need to track back 
 to the original source code.

Not a bad point. Although Adam's suggestion does help mitigate it.
 5. If you don't like JS syntax or verbosity, you can use CoffeeScript, 
 which is just a syntax rewriter, not a language/paradigm shift: 
 http://coffeescript.org/

Bleh. I hate JS with a passion and I'd still much rather use straight JS than CoffeeScript. CoffeeScript has a few nice bits of sugar, but the basic syntax is just plain horrid. At least plain JS doesn't have that indent-syntax abomination that's so popular these days.
 6. Javascript objects have some built-in properties that are different 
 from D. So implementing those in D would make their performance worse (but 
 you can always hard-code those functions into the compiler and translate 
 them directly to their JS equivalent).

If you're doing any non-trivial JS, you can *expect* it to be slow, period. This is like saying "I drive a $100k sports car with 600 horsepower and yet I care about my gas mileage". Just kinda goofy.
Mar 01 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.02.2012 21:58, Adam D. Ruppe wrote:
[...]
 4) This is an insane idea, but one that came to mind.
 I'm testing this by piping the generated JS into
 dmdscript.

 dmd runs insanely fast when compiling this code. Phobos
 is kinda slow to compile, but you don't have to use it
 here. Write D1 style code and dmd is blink of an eye.

 dmdscript is reasonably fast too.

As someone that spent quite some time porting and fixing dmdscript I humbly suggest using Google's standalone version of v8. I mean I've done benchmarking, and it was like 20-200x times slower depending on the things you do. For one hashtables are the bottleneck, I though of reworking them but lost interest along the way. The other problem is FP speed since JS uses double for eveerything. dmd used FP stack for double back then, probably now it uses SSE(?).
 Suppose you're writing an app and you want a scripting
 extension. Embed dmdscript, boom you can use javascript.

 (I really want to revive a dmdscript D2 port to make this
 even easier, but it isn't hard right now either.)

You can try where I stopped it's still on D source, though I should probably upload that on github. If you are serious about dmd I would recommend it, as I've spent weeks to figure out proper try/catch/finally implementation and fix closures that were broken. Last thing I vaguely recall is building it with 2.055 or 2.056, and moving deprecated parts of phobos into it.
 What if you want to script in D? If you're GPL... embed
 dmd front end too.


 Make D output JS, which is interpreted by D, calling
 D apis....


 Pretty insane, but you could script your app in D without
 doing shared libraries or anything like that!

Indeed, but who knows ;)
 Compared to cases 1-3 though, this is silly. Just a thought
 that came to mind.



 The web app use case is strong though. I think I'll actually
 use this thing.

-- Dmitry Olshansky
Feb 29 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.02.2012 23:40, Adam D. Ruppe wrote:
 On Wednesday, 29 February 2012 at 19:10:27 UTC, Dmitry Olshansky wrote:
 If you are serious about dmd I would recommend it, as I've spent weeks
 to figure out proper try/catch/finally implementation and fix closures
 that were broken.

Indeed, I still have a copy of your zip from before. I tried to do it too, but I never got a lot of things working quite right; it'd sometimes crash, I replaced the AAs with a linear lookup since I didn't get that working right either.

I ended up using hacked RandAA by David Simcha, it works quite well. It's a somewhat slow on reads comapred to d's native one, but sure it's more stable ;)
 Your version worked well, as I recall.


 But on dmdscript vs v8, v8 is faster, but I'm not too
 concerned about speed.

 A couple big advantages dmdscript has are:

 a) I expect it will be easier to integrate in D apps

 b) I already know its source code, so if I want to hack new
 things on to the language, it won't be a big todo.

 c) license is a little more permissive.



 The big one though is familiarity with the source.

Agreed, it's very clean and lean for full interpreter (not to mention built-ins). -- Dmitry Olshansky
Feb 29 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/29/12 11:58 AM, Adam D. Ruppe wrote:
 Sorry if I sent twice, it is so easy to hit the
 wrong button on things.

 On Wednesday, 29 February 2012 at 17:32:42 UTC, Andrei Alexandrescu wrote:
 So the idea is to make an entire subset of D convertible to Javascript?

Yeah, and I'm pretty much there - I just built a little sort program with std.algorithm to it, which is pretty cool.

Saw that - pretty amazing. The motivation sounds great. I think one area of focus going forward might be defining precisely the subset of D supported (e.g. I suppose pointer semantics would be difficult). I presume most of Safe D would be supported, but there's no formal definition of that either :o). Si this area is ripe for development. Andrei
Mar 01 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:uvagboafiyjrhvywpiyd forum.dlang.org...
 but I'd rather than an error than it generating
 horribly inefficient javascript for simple operations.

You make it sound as if there's another kind of JS.
Mar 01 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:arowwzayimwhzmqahxic forum.dlang.org...
 On Friday, 2 March 2012 at 05:58:03 UTC, Nick Sabalausky wrote:
 You make it sound as if there's another kind of JS.

Horribly inefficient relative to the environment :P I just don't want 100 kb of crap to download just to write a hello world.

Heh, yea. That's why, even though I use Haxe, I don't use it for generating JS (unless I wanted to do a Flash-style HTML5/canvas thing).
 A lot of people prefer to use gzipped sizes, but I don't
 because the browser still has to parse the whole thing,
 and that takes time after the download, even if you don't
 actually run any of it.

 (On some browsers, it parses it again on every page load!)


 This generated D code gzips very, very well, but I still
 want to keep it small in general for general speed.

 The fastest code is no code at all. Less to parse, less
 to run.

Suggestion: Allow all D features even if it requires...inefficient-er...boilerplate, BUT then have a system similar to safe/ trusted/ system (or maybe just a "pragma(SimpleJS)") so a developer can selectively turn on "Disallow any D features that would result in extra-inefficient JS output" at the module-level (and/or whatever other granularity safe works on).
Mar 02 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:sazpaicrjwzchqcfwlql forum.dlang.org...
 On Friday, 2 March 2012 at 18:28:15 UTC, Nick Sabalausky wrote:
 Suggestion: Allow all D features even if it
 requires...inefficient-er...boilerplate, BUT then have a system [...]

Eh. A problem there is those pragmas or whatever would be unrecognized by the real dmd. A command line switch, maybe, though.

I thought unrecognized pragmas were supposed to just be ignored? (Or maybe I have it backwards?)
Mar 02 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-03 06:56, Nick Sabalausky wrote:
 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:sazpaicrjwzchqcfwlql forum.dlang.org...
 On Friday, 2 March 2012 at 18:28:15 UTC, Nick Sabalausky wrote:
 Suggestion: Allow all D features even if it
 requires...inefficient-er...boilerplate, BUT then have a system [...]

Eh. A problem there is those pragmas or whatever would be unrecognized by the real dmd. A command line switch, maybe, though.

I thought unrecognized pragmas were supposed to just be ignored? (Or maybe I have it backwards?)

No, they're not: "Compilers must diagnose an error for unrecognized Pragmas, even if they are vendor specific ones. This implies that vendor specific pragmas should be wrapped in version statements". http://dlang.org/pragma.html -- /Jacob Carlborg
Mar 03 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jit2r7$rlu$2 digitalmars.com...
 I thought unrecognized pragmas were supposed to just be ignored? (Or 
 maybe I
 have it backwards?)

No, they're not: "Compilers must diagnose an error for unrecognized Pragmas, even if they are vendor specific ones. This implies that vendor specific pragmas should be wrapped in version statements". http://dlang.org/pragma.html -- /Jacob Carlborg

There's a switch to ignore them.
Mar 03 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-02 15:38, Adam D. Ruppe wrote:
 On Friday, 2 March 2012 at 05:58:03 UTC, Nick Sabalausky wrote:
 You make it sound as if there's another kind of JS.

Horribly inefficient relative to the environment :P I just don't want 100 kb of crap to download just to write a hello world. A lot of people prefer to use gzipped sizes, but I don't because the browser still has to parse the whole thing, and that takes time after the download, even if you don't actually run any of it. (On some browsers, it parses it again on every page load!) This generated D code gzips very, very well, but I still want to keep it small in general for general speed. The fastest code is no code at all. Less to parse, less to run.

No, we don't want to do it like Dart: https://gist.github.com/1277224 17260 lines of code for Hello World. -- /Jacob Carlborg
Mar 03 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-04 23:29, Brad Anderson wrote:
 On Saturday, 3 March 2012 at 12:10:47 UTC, Jacob Carlborg wrote:
 On 2012-03-02 15:38, Adam D. Ruppe wrote:
 On Friday, 2 March 2012 at 05:58:03 UTC, Nick Sabalausky wrote:
 You make it sound as if there's another kind of JS.

Horribly inefficient relative to the environment :P I just don't want 100 kb of crap to download just to write a hello world. A lot of people prefer to use gzipped sizes, but I don't because the browser still has to parse the whole thing, and that takes time after the download, even if you don't actually run any of it. (On some browsers, it parses it again on every page load!) This generated D code gzips very, very well, but I still want to keep it small in general for general speed. The fastest code is no code at all. Less to parse, less to run.

No, we don't want to do it like Dart: https://gist.github.com/1277224 17260 lines of code for Hello World.

To be fair to Dart, that was from the initial preview release of it. They managed to get it quite a bit smaller a couple months ago. https://gist.github.com/1385015 Regards, Brad Anderson

Seems they found a way to not include the complete runtime every time. -- /Jacob Carlborg
Mar 04 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mxstsriydkbxxrjlfxqn forum.dlang.org...
 Then again, when giant things like jQuery is considered
 a "necessity" when I get by just fine with my 10 KB
 (source, not minified, not gzipped) custom library,
 if even that, it shows there's a big disconnect between
 me and most other web people nowadays.

Yea, a disconnect of about 50 IQ points (in your favor). Things like that are why I hate "typical" web developers and webdev "conventional wisdom" (hah!) with a burning passion. We're talking "thermonuclear power of a thousand suns" here.
Mar 06 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:wplwmjdlvvqcokxykskm forum.dlang.org...
 Here's one of the nicer things to do:

 http://arsdnet.net/dtojs/game.d
 http://arsdnet.net/dtojs/game.html

 we can do little browser games in D.

 If you look at game.js:
 http://arsdnet.net/dtojs/game.js

 you can see it is similar in size to the original
 D file (this is after running tools/gcfunctions and
 tools/mangledown on it; before them, it was 21 KB).

 I just quickly whipped this together, so it isn't
 much of a game - you just move your thing around.
 Use keys a,d, and w to control it.


 Not much to it, and writing this in Javascript would
 have been easy enough, but even for this trivial thing,
 a few D nicieties came through:

 1) I typo'd one of the method names. D caught it instantly.

 2) The degrees thing is supposed to be a user defined literal..
    but it didn't actually work like that (it outputted functions
    that returned the literals!) I consider this a bug in the converter.

 3) The click event handler is a little more succicent than the
    same in Javascript would be.

 4) The switch. Two nice features of D here that JS lacks:

    a) "case 'A':" comes out as "case 65:". The key code is a
       number, which is not equal to 'A' in Javascript!

       A lot of sites have tables for this, but it is just ascii,
       so 'A' works well. In D.

    b) the comma on case is a bit shorter than the same in JS.
       D is better at this short, dynamic stuff than JS itself
       if you ask me - just look at the beauty of my server side
       dom.d compared to JS.




 But, it also shows that D->JS isn't a magic bullet.


 1) This won't work on IE8, since it doesn't have the canvas thing
    nor addEventListener. (The latter could be emulated in a library,
    though, with exactly the same syntax too.)

 2) It runs smoothly on IE9, but sucks my butt on Firefox 9 on the
    same computer (my little laptop).

    It is still javascript when it runs, so speed boosts are limited
    by that; if the browser is slow, using D won't help much.

 3) Obviously, it won't magically turn on people's javascript either.
    But, same language client+server means it is that much less
    work to make nice fallbacks (e.g. proper validation).

 BTW speaking of validation, I'm pondering if scope(failure)
 could make elegant code for that...



 But, hey, I'm calling it a win. The suckage of browsers
 is a reality regardless of the language.

Yea, that's pretty cool. The *one* nice thing about modern JS is that is can kill off Flash. Of course, it's still not a partucularly good approach, but at least it's an improvement over Flash. Your demo there reminds me of an awesome demoscene website around ten years ago...umm "matt"-something-or-other. Shit, I can't remember, but it was like a demoscene entry, but with the browser as the platform. Included one or two DHTML games, and this was years before anyone had even heard of "canvas" or "HTML5". Unfortunately, I don't think it's around anymore :(
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 17:32:42 UTC, Andrei 
Alexandrescu wrote:
So the idea is to make an entire subset of
 D convertible to Javascript?

 What use cases do you have in mind?


 Andrei

Feb 29 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Sorry if I sent twice, it is so easy to hit the
wrong button on things.

On Wednesday, 29 February 2012 at 17:32:42 UTC, Andrei 
Alexandrescu wrote:
 So the idea is to make an entire subset of D convertible to 
 Javascript?

Yeah, and I'm pretty much there - I just built a little sort program with std.algorithm to it, which is pretty cool.
 What use cases do you have in mind?

A number of things: 1) The obvious one is writing the client side portions of a web app in D, as well as the server side portions. This gives all kinds of benefits: well, just think how much better D is than all other languages for both little and big things. I really like having static checking of names and types. D syntax is amazing. (Javascript really isn't bad here; add a foreach macro and it isn't bad at all. But D is still better.) Sane libraries. You could use something like an include macro in Javascript, or those insane client side add script tag include functions, but here, you can just use D's superior import system. You get namespacing, stripping what you don't use; all the advantages D brings to the table for any app. Well, I'm sure I don't have to sell the D language to you! 2) Using the same language for client and server means you can reuse code. Library functions, field validation, building parts of the site. No duplication of effort for the two locations. (Now this is already kinda small, since calling D functions from Javascript isn't hard thanks to ajax - my web.d makes it stupid easy by automatically wrapping functions. But, that does require a trip to the server, so it isn't always suitable.) 3) You don't need to write javascript at all! Imagine you want to write an iPad app. Apple wants you do fork over all kinds of dough and play ball by their rules. I expect we'll see a D compiler that can output code for that platform soon, but there's another option that avoids all this right now: a web app (which you can make full screen on the home page btw). But, writing web apps means javascript. Gross. No more! Just write the whole thing as D, then convert it to Javascript and offer that to the ipad users. I've started doing things like porting std.file to use browser local storage, so you can pretend to use files and have it save there too. 4) This is an insane idea, but one that came to mind. I'm testing this by piping the generated JS into dmdscript. dmd runs insanely fast when compiling this code. Phobos is kinda slow to compile, but you don't have to use it here. Write D1 style code and dmd is blink of an eye. dmdscript is reasonably fast too. Suppose you're writing an app and you want a scripting extension. Embed dmdscript, boom you can use javascript. (I really want to revive a dmdscript D2 port to make this even easier, but it isn't hard right now either.) What if you want to script in D? If you're GPL... embed dmd front end too. Make D output JS, which is interpreted by D, calling D apis.... Pretty insane, but you could script your app in D without doing shared libraries or anything like that! Compared to cases 1-3 though, this is silly. Just a thought that came to mind. The web app use case is strong though. I think I'll actually use this thing.
Feb 29 2012
prev sibling next sibling parent reply Bystroushaak <bystrousak kitakitsune.org> writes:
Thx.

On 29.2.2012 18:03, Robert Clipsham wrote:
 On 29/02/2012 16:56, Bystroushaak wrote:
 Daniel Murphy's microd fork of dmd, meant to output C

Link please.

https://github.com/yebblies/dmd/tree/microd

Feb 29 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Bystroushaak" <bystrousak kitakitsune.org> wrote in message 
news:mailman.239.1330541205.24984.digitalmars-d-announce puremagic.com...
 Thx.

 On 29.2.2012 18:03, Robert Clipsham wrote:
 On 29/02/2012 16:56, Bystroushaak wrote:
 Daniel Murphy's microd fork of dmd, meant to output C

Link please.

https://github.com/yebblies/dmd/tree/microd


Don't get your hopes up, it was more of an experiment than a serious fork, I have no intention of doing anything more with it (unless I get really bored again). It does work, but the effort is probably better spent on improving gdc's support of embedded platforms.
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 February 2012 at 19:10:27 UTC, Dmitry Olshansky 
wrote:
 If you are serious about dmd I would recommend it, as I've 
 spent weeks to figure out proper try/catch/finally 
 implementation and fix closures that were broken.

Indeed, I still have a copy of your zip from before. I tried to do it too, but I never got a lot of things working quite right; it'd sometimes crash, I replaced the AAs with a linear lookup since I didn't get that working right either. Your version worked well, as I recall. But on dmdscript vs v8, v8 is faster, but I'm not too concerned about speed. A couple big advantages dmdscript has are: a) I expect it will be easier to integrate in D apps b) I already know its source code, so if I want to hack new things on to the language, it won't be a big todo. c) license is a little more permissive. The big one though is familiarity with the source.
Feb 29 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I probably should have been working today.... but instead
spent a good amount of time on this again.

New zip:

https://github.com/downloads/adamdruppe/dtojs/dtojs-0.3.zip

(I haven't cleaned up the github fork yet)

To give you an idea of what is working, check out
my tests.d file:

http://arsdnet.net/dtojs/tests.d

This compiles (raw) into this:
http://arsdnet.net/dtojs/tests.js

BTW, when compiling, be sure to put test/object.d
on your command line too, or the runtime functions
won't be present in your .js file!

23 KB (down to 11 KB if you run the included mangledown tool
on it. gcfunctions can often make a big difference, but not here,
since it removes what you don't use. A test that doesn't use
something is an incomplete test!)


I think I broke std.algorithm again :(, but fixed a lot of
other stuff. (it is the lambda generator in std.algorithm that
is breaking. The JS has the function, but it is nested too deep
and inaccessible to the actual algorithm.)



But, a lot of stuff works now, and the generated code isn't
half bad. I've started using more static type info to slightly
optimize it too, but only some basics.


One of the messiest things was try/catch. JS doesn't do
types like D, so I implemented it with a series of
if(dynamic_cast()), and ultimately rethrow if none matched.

A bit ugly, but it seems to pass the tests!

(The messiest compiler implementation so far is [0..$]. That
pesky dollar sign. In microd.c, you can see a couple global
variables there to hack things up. Poo. But, again, it works.)


Library wise, check out src/test/jslang and src/test/browser.
I tried for completeness there, but not full accuracy yet.

This gives free (no generated wrappers) access to regexps,
the array object, string functions, etc. as part of the
core language, and browser has things for the DOM, window,
history, location, canvas, style, json, ajax, etc. - all
just bindings to the native functions.



I'm to the point where I think I'm ready to write a program
with this thing!
Feb 29 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-01 06:20, Adam D. Ruppe wrote:
 I probably should have been working today.... but instead
 spent a good amount of time on this again.

BTW, how do you fit D's class based object model in JavaScript's prototype based object model? -- /Jacob Carlborg
Feb 29 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-01 16:07, Adam D. Ruppe wrote:
 On Thursday, 1 March 2012 at 07:14:02 UTC, Jacob Carlborg wrote:
 BTW, how do you fit D's class based object model in JavaScript's
 prototype based object model?

Short answer is each D object in JS has a virtual function array and implements array as properties attached to the object. The JS constructor for the object populates these arrays. Virtual calls thus look like: obj._virtual_table[call_num](); instead of obj.function(); It is similar in principle to how you'd implement it in C. Long answer:

Ok, I see. Thanks for the detailed explanation. -- /Jacob Carlborg
Mar 01 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
I love how this started as interesting and turned into awesome.

Web programming... might actually become non-horrible? 
Mar 01 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-02 03:28, Adam D. Ruppe wrote:
 On Thursday, 1 March 2012 at 08:01:07 UTC, Daniel Murphy wrote:
 Web programming... might actually become non-horrible?

As far as I can tell, we have variable lifetime! (JS's garbage collector is still a question, and some of the variables are global - dmd loves the (var a, b) syntax, which is invalid so I made var a in global scope. It is not set to null when done.)

What do you mean with "dmd loves the (var a, b) syntax, which is invalid so"? -- /Jacob Carlborg
Mar 02 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jipus9$v81$1 digitalmars.com...
 On 2012-03-02 03:28, Adam D. Ruppe wrote:
 On Thursday, 1 March 2012 at 08:01:07 UTC, Daniel Murphy wrote:
 Web programming... might actually become non-horrible?

As far as I can tell, we have variable lifetime! (JS's garbage collector is still a question, and some of the variables are global - dmd loves the (var a, b) syntax, which is invalid so I made var a in global scope. It is not set to null when done.)

What do you mean with "dmd loves the (var a, b) syntax, which is invalid so"?

CommaExp's containing Declarations
Mar 02 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-02 10:57, Daniel Murphy wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jipus9$v81$1 digitalmars.com...
 On 2012-03-02 03:28, Adam D. Ruppe wrote:
 On Thursday, 1 March 2012 at 08:01:07 UTC, Daniel Murphy wrote:
 Web programming... might actually become non-horrible?

As far as I can tell, we have variable lifetime! (JS's garbage collector is still a question, and some of the variables are global - dmd loves the (var a, b) syntax, which is invalid so I made var a in global scope. It is not set to null when done.)

What do you mean with "dmd loves the (var a, b) syntax, which is invalid so"?

CommaExp's containing Declarations

Is he saying "var a, b, c;" is invalid JavaScript code? -- /Jacob Carlborg
Mar 02 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jiq8kb$1ht0$1 digitalmars.com...
 CommaExp's containing Declarations

Is he saying "var a, b, c;" is invalid JavaScript code? -- /Jacob Carlborg

It's invalid if it's a comma expression. eg. auto x = (auto a = 3, a); Which dmd creates _everywhere_.
Mar 02 2012
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 02/03/2012 02:28, Adam D. Ruppe wrote:

 3) The JS language doesn't have block scoping like D.

Have you considered faking scopes in JS using anonymous functions? ---- var foo; (function(a, b){ var foo; // not the same as the foo outside the func! // do stuff }(x, y)); // invoke immediately with needed arguments from outer scope ---- by passing all the parameters to the anon func you get a speed increase in the lookup on most JS platforms. I don't think they are very pretty, but it is sometimes a useful technique. A...
Mar 02 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:omhitgvibquioulpcxxq forum.dlang.org...
 If I add a way to instead put those var declarations in
 function scope, it is cleaner - no globals - and the same
 thing Javascript itself would do anyway!


 I'll have to redo the string buffering to make that though,
 so it will take some code to do it. Dumping it in the global
 was simple to implement with what was already there.

Btw, in VarDeclaration::toMicroD you're using microd_decl23 as the sink, which results in all var declarations getting doubled. The problem with globals not getting default initialized is here too, it's only using explicit initializers. Something like this should work: // set sink to be one of the normal buffers, not a tee sink(" = "); if (init) init->toMicroD(sink); else type->defaultInit(0)->toMicroD(sink); sink(";\n");
Mar 02 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-02 15:57, Adam D. Ruppe wrote:
 On Friday, 2 March 2012 at 09:33:44 UTC, Alix Pexton wrote:
 Have you considered faking scopes in JS using anonymous functions?

Yeah, though right now I'm trusting the D compiler to keep it straight, and it is doing a pretty good job while being really simple to code. What happens is all the local variables are mangled with respect to their full scope too (which leads to ridiculously long, but unique names).

Wouldn't you save a lot of characters by properly scoping the variables instead of using unique names? The compile JavaScript code would also be more readable. -- /Jacob Carlborg
Mar 03 2012
next sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 03/03/2012 12:12, Jacob Carlborg wrote:
 On 2012-03-02 15:57, Adam D. Ruppe wrote:
 On Friday, 2 March 2012 at 09:33:44 UTC, Alix Pexton wrote:
 Have you considered faking scopes in JS using anonymous functions?

Yeah, though right now I'm trusting the D compiler to keep it straight, and it is doing a pretty good job while being really simple to code. What happens is all the local variables are mangled with respect to their full scope too (which leads to ridiculously long, but unique names).

Wouldn't you save a lot of characters by properly scoping the variables instead of using unique names? The compile JavaScript code would also be more readable.

and potentially faster! A...
Mar 03 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-03 17:29, Adam D. Ruppe wrote:
 On Saturday, 3 March 2012 at 12:12:53 UTC, Jacob Carlborg wrote:
 Wouldn't you save a lot of characters by properly scoping the
 variables instead of using unique names?

There's no such thing as proper scoping in Javascript. The next best thing is the nested functions, but that's really just trading one poison for another.

Ok, I see.
 D mangled names do a lot more than scoping, too, anyway.
 Mangled names overload properly:

 void a(int, int);
 void a(int, string);

 a(1, "one"); // which one gets called?


 With dmd's name mangling, it Just Works.

Well, functions are different.
 Now, there might be something to gain by using prettier
 local variable names, but it is a lot of extra work and
 IMO the benefit is still very small.


 Note that local variables are still local variables
 95% of the time (and the other 5% is a bug that I'm
 hoping to fix today), so its already scoped almost
 as well as it can be on the function level.



 The biggest benefit is readability and size. Size is handled
 by running it through a string replacer (tools/mangledown.d).

 Readability is a nice gain, but not an essential one I think;
 it is readable right now if you want to.

-- /Jacob Carlborg
Mar 03 2012
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 01/03/2012 05:20, Adam D. Ruppe wrote:
 I probably should have been working today.... but instead
 spent a good amount of time on this again.

 New zip:

 https://github.com/downloads/adamdruppe/dtojs/dtojs-0.3.zip

 (I haven't cleaned up the github fork yet)

 To give you an idea of what is working, check out
 my tests.d file:

 http://arsdnet.net/dtojs/tests.d

 This compiles (raw) into this:
 http://arsdnet.net/dtojs/tests.js

 BTW, when compiling, be sure to put test/object.d
 on your command line too, or the runtime functions
 won't be present in your .js file!

 23 KB (down to 11 KB if you run the included mangledown tool
 on it. gcfunctions can often make a big difference, but not here,
 since it removes what you don't use. A test that doesn't use
 something is an incomplete test!)


 I think I broke std.algorithm again :(, but fixed a lot of
 other stuff. (it is the lambda generator in std.algorithm that
 is breaking. The JS has the function, but it is nested too deep
 and inaccessible to the actual algorithm.)



 But, a lot of stuff works now, and the generated code isn't
 half bad. I've started using more static type info to slightly
 optimize it too, but only some basics.


 One of the messiest things was try/catch. JS doesn't do
 types like D, so I implemented it with a series of
 if(dynamic_cast()), and ultimately rethrow if none matched.

 A bit ugly, but it seems to pass the tests!

This is really cool! It would be quite interesting to run the dmd testsuite through it and see how much passes. Same goes for phobos unittests (obviously both of these would fail for system stuff like inline asm...) I'd also be interested in some benchmarks (eg std.algorithm.sort vs Array.sort), but that seems a bit pointless really. Might be interesting to throw in some optimisations when translating though (though you're doing some of these already!) Interesting idea: version(JavaScript) asm { /* Well... it's not really asm, but it's as close as you could get with a javascript backend :p */ document.write("Oh look, inline javascript D-:"); } Perhaps it would be better to have a dedicated function for that though. -- Robert http://octarineparrot.com/
Mar 01 2012
prev sibling next sibling parent Mikael Lindsten <mikael lindsten.net> writes:
--f46d044517a33f2bf404ba29a7b4
Content-Type: text/plain; charset=ISO-8859-1

2012/2/29 Adam D. Ruppe <destructionator gmail.com>

 4) This is an insane idea, but one that came to mind.
 I'm testing this by piping the generated JS into
 dmdscript.

 dmd runs insanely fast when compiling this code. Phobos
 is kinda slow to compile, but you don't have to use it
 here. Write D1 style code and dmd is blink of an eye.

 dmdscript is reasonably fast too.



 Suppose you're writing an app and you want a scripting
 extension. Embed dmdscript, boom you can use javascript.

 (I really want to revive a dmdscript D2 port to make this
 even easier, but it isn't hard right now either.)


 What if you want to script in D? If you're GPL... embed
 dmd front end too.


 Make D output JS, which is interpreted by D, calling
 D apis....


 Pretty insane, but you could script your app in D without
 doing shared libraries or anything like that!

exciting! Also, being a fan of embedding JS into Java applications using their ScriptingEngine API, I absolutely don't think number 4 is an insane idea. I think it's a great idea! I wish I had more time (and D knowledge!) to contribute.. for now I'm just cheering! / Mikael --f46d044517a33f2bf404ba29a7b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>2012/2/29 Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destru= ctionator gmail.com">destructionator gmail.com</a>&gt;</span></div><div cla= ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> 4) This is an insane idea, but one that came to mind.<br> I&#39;m testing this by piping the generated JS into<br> dmdscript.<br> <br> dmd runs insanely fast when compiling this code. Phobos<br> is kinda slow to compile, but you don&#39;t have to use it<br> here. Write D1 style code and dmd is blink of an eye.<br> <br> dmdscript is reasonably fast too.<br> <br> <br> <br> Suppose you&#39;re writing an app and you want a scripting<br> extension. Embed dmdscript, boom you can use javascript.<br> <br> (I really want to revive a dmdscript D2 port to make this<br> even easier, but it isn&#39;t hard right now either.)<br> <br> <br> What if you want to script in D? If you&#39;re GPL... embed<br> dmd front end too.<br> <br> <br> Make D output JS, which is interpreted by D, calling<br> D apis....<br> <br> <br> Pretty insane, but you could script your app in D without<br> doing shared libraries or anything like that!<br><br> </blockquote></div><br><div><div>Being mainly a web developer, I think this= =A0project of yours is really exciting!</div><div><br></div><div>Also, bein= g a fan of embedding JS into Java applications using their ScriptingEngine = API, I absolutely don&#39;t think number 4 is an insane idea. I think it&#3= 9;s a great idea!</div> <br class=3D"Apple-interchange-newline"></div><div>I wish I had more time (= and D knowledge!) to contribute.. for now I&#39;m just cheering!</div><div>= <br></div><div><br></div><div>/ Mikael</div><div><br></div> --f46d044517a33f2bf404ba29a7b4--
Feb 29 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 07:14:02 UTC, Jacob Carlborg wrote:
 BTW, how do you fit D's class based object model in 
 JavaScript's prototype based object model?

Short answer is each D object in JS has a virtual function array and implements array as properties attached to the object. The JS constructor for the object populates these arrays. Virtual calls thus look like: obj._virtual_table[call_num](); instead of obj.function(); It is similar in principle to how you'd implement it in C. Long answer: A D class is written out like this: function _d_class_NAME(requested_constructor) { _d_class_object.call(this, null); // repeat for all base classes through to Object _d_class_baseclass.call(this, null); this.virtual_function_table[index] = member_function; // repeat for all virtual functions /* BTW, I'm probably going to change this implementation but it will have the same result */ this.implements = ["Object", "Interface_Name", "Base_Class", "This_Class"]; // (these names are actually mangled in the real thing) if(requested_constructor) requested_constructor(this, arguments); } function member_function(arguments..., d_this) { // implementation of the member function } Usage: in D: MyClass a = new MyClass(); a.final_function(); a.virtual_function(); in Javascript: var a = new _d_class_MyClass(default_constructor); // most functions are free functions, like they would be implemented // in C. You pass this as a final parameter: MyClass_final_function(a); // but virtual functions have to use the table: a.virtual_function_table[0](); The index into the virtual table is known by dmd ahead of time, so plain integers are outputted. If you override, what happens is the base class initializer is called first, which creates its virtual functions. Then, your class initializer simply overwrites that entry in the table. (Plain Javascript properties probably could have done this too, with the base class being the prototype, but dmd already has the infrastructure to do it C style, and getting the Js names right in the presence of things like overloading would have been harder to keep straight than a simple integer index.) Whether you access it through a base class, interface, or whatever, the vtable is attached to the object, so it works. The other thing you expect in classes is dynamic casting. That's where the this.implements comes in. If you write cast(Class) object; in D, it outputs var n = __d_dynamic_cast(object, "Class"); The dynamic cast function is implemented in test/object.d as a simple loop: // given an object, should we allow the runtime cast to succeed? // if no, return null. Object __d_dynamic_cast(Object from, string to) { if(from.__d_implements) { foreach(s; from.__d_implements) if(s == to) return from; return null; // it is a D object, but not of this class } // if in doubt, let it pass since we don't want to tie hands // where the programmer knows what he is doing. I might // change this since it isn't actually that good of an idea. // (there's always reinterpret_cast if you know you want it) return from; } But yeah, if the class name is in the implements list, go ahead and return the object; the cast succeeds. If not, do null. This is used in exception handling. In D, if you write: try { throw new Exception("not an error"); } catch(Error e) { assert(0); } you expect the exception to keep flying, since Exception is not an Error. Javascript, though, doesn't have the same concept of types. I implemented this like so: try { throw new _d_Exception(exception_string_constructor, "not an error"); } catch(e) { var was_exception_caught = false; var e_as_error = _d_dynamic_cast(e, "Error"); if(e_as_error) { was_exception_caught = true; 0 || _d_assert(...); } // repeat for other catch blocks, if present if(!was_exception_caught); throw e; // keep it going up the call stack } The dynamic cast lets the program know if we have the right catch block, so it works like you expect it would in D. (Javascript can do something similar with if(e instance of y), but... I'm not 100% sure; I don't do this kind of JS often, but I'm pretty sure instanceof only looks at the constructor - there's no inheritance chain to look at. If we catch(Throwable), we want Error, Exception, and all their subclasses in D.) That initializer that sets up the vtbl also does things like default value initialization, so int a; is == 0 like you expect in D. This got a little fun for the magical "null" word. int[] a = null; a ~= 3; if we translated that as var a = null; a = a.concat(3); // fails, a is null it is no good. JS null isn't the right type. But, D's null knows what type it is! So, NullExp looks like this: if(type->ty == Taarray) // ass array sink("{}"); // use an object literal as this null else if(string) sink("\"\"") else if(array) sink("[]"); else sink("null"); Now, the JS variables are the right type when initialized to D's null. The trick will now be getting is null right... but meh that confuses people in D itself due to implementation details, so I think I'll just make (array is null) mean (array === []) or something along those lines and call it good enough.
Mar 01 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 29.02.2012, 18:32 Uhr, schrieb Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org>:

 On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
 https://github.com/downloads/adamdruppe/dtojs/dtojs.zip

That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei

The visualizer I wrote for aichallenge.org had 3 versions: - HTML 5 / JavaScript - Java applet - Java application The source code was in JavaScript and executed in the Rhino JS engine for the Java versions. The applet was actually there to support Internet Explorer versions which suffered from a massive NIH syndrome when it came to HTML 5. So with those becoming a minority the remaining targets are the standalone application and the browser visualizer. With D-to-JS I would have had the option to write the application in D using GtkD or similar GUI library with access to drawing functions that are similar to the HTML 5 Canvas, and then export the whole thing to JS. The obvious benefits are to me: - Native efficiency (JS in Rhino in JVM used masses of memory and was slow as molasses) - Type checking and compiler errors The downside is that I would have missed the perfect JavaScript debugging support in the major browsers when working with D code. :)
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 16:29:10 UTC, Robert Clipsham wrote:
 Perhaps it would be better to have a dedicated function for 
 that though.

eval() :) I considered doing asm {} for javascript, but that'd be a pretty invasive change to the compiler, so I decided against it; I want to keep most the changes as simple as possible. One possibility would be a special function, let's call it static_eval, that takes a string but instead of being a function call, simple pastes the string itself into the js file. But, I haven't really wanted it yet! All the functions I want have been implementable in relatively plain D (with the addition of the __js_keywords in some places), except foreach on associative arrays. I had to hardcode that function, since there's no way to represent for(i in obj) on the low level. For phobos btw, I haven't decided how to run with that yet. My first thought was to implement my own version - test/std shows this - that emulates the interface using native JS functions where possible. That will be hard to keep up to date, and causes conflicts if you want to borrow a little from the real Phobos. So eh, I don't know yet.
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 18:56:07 UTC, Alex Rønne Petersen 
wrote:
 Valid argument. Maybe we can make the D -> JS converter help in 
 some way here?

I don't know yet. assert() in your D code, while a far cry from a real debugger, does have the decency to give file and line number in your browser error log, like so: Error: uncaught exception: tests.d:9 [object.AssertError] Assertion failure in firefox, but it works in IE and I assume the others too. Debugging in javascript is sure to be painful due to two big facts though: 1) the line/file won't match up, and 2) the function and variable names are mangled, which gets RIDICULOUSLY long in places, and very difficult to read. For debugging, I might just put comments in the source code. /* file.d:30 */ var some_long_horrible_mangled_name = 20; so at least you'd have a hope of reading it, by matching it back up to your original source. This would be fairly easy to implement and is better than nothing. But, I don't know yet. For what I've done so far, a combination of asserts and manually picking the generated code apart has been what I use.
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 17:35:02 UTC, Andrei Alexandrescu 
wrote:
 The motivation sounds great. I think one area of focus going 
 forward might be defining precisely the subset of D supported 
 (e.g. I suppose pointer semantics would be difficult).

Right. I'm not sure exactly what is and is not safe myself, but I think *most* of it is realistic. goto and pointers are the questionable ones right now. They are solvable, but are they solvable in a way that I'm willing to do? I don't want a while() { switch() { } } thing; the code should look like javascript, not assembly. Some integer semantics might be hard too. ubyte is ok, but byte is different because 127+1 isn't as simple as x & 0xff I'll have to think about that. Again, it surely *can* be done, but I'd rather than an error than it generating horribly inefficient javascript for simple operations. But, everything else I've considered either already works or is solvable with a little more time. It helps a lot that dmd lowers a lot of the fancier things into simple C-like constructs for me. I just got scope guards working a few minutes ago, so destructors can't be far behind.... then some bugs on struct, and int math, goto, and pointer are the only big rough spots left. At least that I've thought of so far!
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 18:04:35 UTC, Ary Manzana wrote:
 6. Javascript objects have some built-in properties that are 
 different from D. So implementing those in D would make their 
 performance worse (but you can always hard-code those functions 
 into the compiler and translate them directly to their JS 
 equivalent).

It's not so bad. In my zip, src/test/jslang provides bindings to these things, which generate no code to use. In src/test/std, I implement some Phobos interfaces this way. (Run with dmd -inline and they generate no extra code.) module std.string; import jslang.string; string replace(string a, string b, string c) { auto s = cast(JSString) a; // cast just to appease D return s.replace(b, c); // uses the built in method } ...come to think of it, I think that's wrong. replace() in JS only does the first occurrence iirc. D expects them all. But, we could do: import jslang.string; import jslang.regexp; string replace(string a, string b, string c) { auto s = cast(JSString) a; // cast just to appease D return s.replace(new RegExp(b, "g"), c); // uses the built in method } or something like that. But, none of this is hard coded in the compiler. You can call javascript functions just like anything else, given a prototype. Object eval(...); // don't bother typing the arguments if you don't want to
Mar 01 2012
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
--20cf307d07425436de04ba33c21f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 1, 2012 at 11:13 AM, Adam D. Ruppe <destructionator gmail.com>wrote:
 Some integer semantics might be hard too. ubyte is ok, but byte
 is different because 127+1 isn't as simple as x & 0xff

 I'll have to think about that. Again, it surely *can*
 be done, but I'd rather than an error than it generating
 horribly inefficient javascript for simple operations.

Might TypedArrays help you implement some number type semantics? http://www.khronos.org/registry/typedarray/specs/latest/ --bb --20cf307d07425436de04ba33c21f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Mar 1, 2012 at 11:13 AM, Adam D. Ruppe <= span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destructi= onator gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Some integer semantics might be hard too. ubyte is ok, but byte<br> is different because 127+1 isn&#39;t as simple as x &amp; 0xff<br> <br> I&#39;ll have to think about that. Again, it surely *can*<br> be done, but I&#39;d rather than an error than it generating<br> horribly inefficient javascript for simple operations.<br></blockquote><div=
<br></div><div>Might TypedArrays help you implement some number type seman=

/">http://www.khronos.org/registry/typedarray/specs/latest/</a></div> <div><br></div><div>--bb</div><div>=A0</div></div> --20cf307d07425436de04ba33c21f--
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 19:49:46 UTC, Bill Baxter wrote:
 Might TypedArrays help you implement some number type semantics?

Yeah, I think so. I do have compatibility concerns though; it'd be a pity of something taking a ubyte means it doesn't work in IE8 anymore. I'll have to play with it though.
Mar 01 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 1 March 2012 at 08:01:07 UTC, Daniel Murphy wrote:
 Web programming... might actually become non-horrible?

hehe. I already found it ok though; I've been using D on the server for... will be two years in a couple weeks. Javascript isn't bad if you use it sparingly, and in the last year, my web.d server side thing has just enough javascript to let me write less of it. I just call server side functions in most the JS. I went a little nuts on partial application to make it nice looking; you pass arguments to the callback when you make it. But, it is nice to have this other stuff too. If I have to do a browser game, definitely doing D now, from top to bottom. Work wants ipad apps too... I'll probably do them as downloadable browser things, now in D! Anyway, a few more hours on d to js today. I spent the time working on struct semantics. It is amazing how complicated structs are! Compared to this, classes are just plain easy. My tests file (which I need to run in real D to confirm my thought here, but I think all my asserts are sane) now passes including tests of struct. http://arsdnet.net/dtojs/tests.d I implement structs as Javascript Object()'s, but this doesn't quite match what D expects. 1) JS Object are references, whereas D struct are value. 2) JS variables have indeterminate lifetimes 3) The JS language doesn't have block scoping like D. (1) was a big mess, and I'm sure I don't have it right yet (I know it is a lot less efficient than it could be). My solution was to make all assignments do shallow copies, including function call. void t(MyStruct a) {} t(a); becomes t(__d_struct_copy(a)) Worked for the basics. But, D structs are incredibly complex monsters. opAssign, postblit, copy constructors, blit initializers, expression initializers, TOKconstruct - something I'm not even sure what it actually is. Well, I think I got it. Lots of filthy dirty code, but it passed the test file. I haven't tested struct constructors yet, but they are relatively easy, just like class constructor, so I'm confident it will work. (2) and (3) go together: variable lifetime. D structs die when they go out of scope, both on function returns and exceptions. dmd implemented this as a Scope followed by a Finally. I ended up making it put try {} around the scope, and then write out the finally {}. dmd really did all the work already! And... finally works in Javascript. Amazing, we have struct destructors working like you expect. Moreover, dmd implements scope(exit) the exact same way. Boom, we have scope guards too. To my surprise, scope(failure) and scope(success) Just Worked: dmd set up a flag variable and automatically added it to the appropriate places. As far as I can tell, we have variable lifetime! (JS's garbage collector is still a question, and some of the variables are global - dmd loves the (var a, b) syntax, which is invalid so I made var a in global scope. It is not set to null when done.) Pretty cool. The majority of the language works correctly, though there's a few hacks in there to make it happen. I probably won't upload another zip until the weekend though.
Mar 01 2012
prev sibling next sibling parent "Jean-Bernard Pellerin" <jeanbern ualberta.ca> writes:
This will go nicely with the web framework I'm building in D. I'm 
borrowing heavily from silverlight. Here's a teaser (sorry, 
neglected to comment the code...)

Here's a sample code file (CGI script for apache, I'm new to 
these web technologies):
http://pastebin.com/SpfmfpmS

and here's what the resulting site looks like, sorry for the 
image quality

before pressing the button:
http://i.imgur.com/JGvMC.png
after:
http://i.imgur.com/9ZiQp.png
Notice how I clicked a different tab (woot)

It's my first time using HTML, CSS, or JS, so it's a bit rough. 
But I learn it as I go along, to perform the code generation.

A whole lot of really neat CTFE and mixins went into having the 
Control classes and Factory working as smoothly as they do. I'll 
publish it on my blog once it's built (I want to showcase 
darklight with a blog written in darklight) :D

But I just noticed you have a whole suite of D web code, I'll 
have to look into it.

Thanks for all the hard work you've put into D, it's quite a feat.
Mar 01 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 01 Mar 2012 21:13:41 +0100
schrieb Bystroushaak <bystrousak kitakitsune.org>:

 I've played with gdc, but it's pretty complicated. I have few ADM 5120
 routers with debwrt and it would be nice to be able compile D2 code
 there, but so far, it was just fail.
 

ADM 5120 is MIPS, right? Are you trying to build a cross compiler or a compiler running on the MIPS itself? Making a cross-compiler is never easy. Assuming you already have a C cross-compiler, you have to patch the build process to include D at some point. You could also try https://bitbucket.org/goshawk/gdc/wiki/crosstool-ng but then you need a compatible 'sysroot' (a folder including the basic libraries & headers as on your target system, must include libc & some kernel headers, afaik) for your router. Another issue: druntime/phobos might not compile (as long as debwrt uses glibc it could work though), so configure with --disable-phobos to disable both druntime and phobos. You'll only get the compiler this way. And MIPS is probably also affected by GDC issue 120, so you have to configure like this: DFLAGS="-fno-section-anchors" ./configure [configure arguments here]
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 March 2012 at 05:58:03 UTC, Nick Sabalausky wrote:
 You make it sound as if there's another kind of JS.

Horribly inefficient relative to the environment :P I just don't want 100 kb of crap to download just to write a hello world. A lot of people prefer to use gzipped sizes, but I don't because the browser still has to parse the whole thing, and that takes time after the download, even if you don't actually run any of it. (On some browsers, it parses it again on every page load!) This generated D code gzips very, very well, but I still want to keep it small in general for general speed. The fastest code is no code at all. Less to parse, less to run.
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 March 2012 at 09:33:44 UTC, Alix Pexton wrote:
 Have you considered faking scopes in JS using anonymous 
 functions?

Yeah, though right now I'm trusting the D compiler to keep it straight, and it is doing a pretty good job while being really simple to code. What happens is all the local variables are mangled with respect to their full scope too (which leads to ridiculously long, but unique names). The D scope simply outputs its own code: D: { // create a scope int a = 10; } int a = 20; // the old a is out of scope, so we can do this Javascript: var _D_inner_a = 10; // not a real var name, just demo var _D_outer_a = 20; // new var The inner variable is still in scope, so I doubt Javascript garbage collects it, but thanks to the rules of D, it is never used again. But, if you use a struct with a destructor (or scope(exit)), it generates this: D: { MyStruct a; } MyStruct a; Javascript: try { var _D_inner_A = new MyStruct(); } finally { MyStruct_destructor(_D_inner_A); } try { var _D_outer_A = new MyStruct(); } finally { MyStruct_destructor(_D_outer_A); } And, in this case, Javascript's bizarre scoping actually simplifies things. In Javascript, when you write "var x = y;" in the middle of a function, the way it really works is it adds a "var x;" to the top of the function, and leaves "x = y;" in hte middle. You write: function test() { if(something_here()) { var a = 10; } a++; } Javascript acts as if you wrote: function test() { var a; if(something_here()) { a = 10; } a++; } With our try/finally (that dmd generates, mostly; I didn't have to do much to make this work), the var declartion in the try being hoisted up top means we can be sure it works correctly in the finally, too. But, with regard to the D scoping, dmd mangles the names to make sure you don't reference anything that's out of scope accidentally by giving them unique names. This hoisting behavior is the proper solution to the CommaExp declarations mentioned previously, where dmd likes to write: foo( (var a = 10, a) ) and the sort. Currently, I put the var a; in global scope, leaving just (a=10,a) in the expression. This is legal Javascript, and should be ok due to unique names, but it pollutes the globals. If I add a way to instead put those var declarations in function scope, it is cleaner - no globals - and the same thing Javascript itself would do anyway! I'll have to redo the string buffering to make that though, so it will take some code to do it. Dumping it in the global was simple to implement with what was already there.
 I don't think they are very pretty, but it is sometimes a 
 useful technique.

heh, same with mangled names :)
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Here's one of the nicer things to do:

http://arsdnet.net/dtojs/game.d
http://arsdnet.net/dtojs/game.html

we can do little browser games in D.

If you look at game.js:
http://arsdnet.net/dtojs/game.js

you can see it is similar in size to the original
D file (this is after running tools/gcfunctions and
tools/mangledown on it; before them, it was 21 KB).

I just quickly whipped this together, so it isn't
much of a game - you just move your thing around.
Use keys a,d, and w to control it.


Not much to it, and writing this in Javascript would
have been easy enough, but even for this trivial thing,
a few D nicieties came through:

1) I typo'd one of the method names. D caught it instantly.

2) The degrees thing is supposed to be a user defined literal..
    but it didn't actually work like that (it outputted functions
    that returned the literals!) I consider this a bug in the 
converter.

3) The click event handler is a little more succicent than the
    same in Javascript would be.

4) The switch. Two nice features of D here that JS lacks:

    a) "case 'A':" comes out as "case 65:". The key code is a
       number, which is not equal to 'A' in Javascript!

       A lot of sites have tables for this, but it is just ascii,
       so 'A' works well. In D.

    b) the comma on case is a bit shorter than the same in JS.
       D is better at this short, dynamic stuff than JS itself
       if you ask me - just look at the beauty of my server side
       dom.d compared to JS.




But, it also shows that D->JS isn't a magic bullet.


1) This won't work on IE8, since it doesn't have the canvas thing
    nor addEventListener. (The latter could be emulated in a 
library,
    though, with exactly the same syntax too.)

2) It runs smoothly on IE9, but sucks my butt on Firefox 9 on the
    same computer (my little laptop).

    It is still javascript when it runs, so speed boosts are 
limited
    by that; if the browser is slow, using D won't help much.

3) Obviously, it won't magically turn on people's javascript 
either.
    But, same language client+server means it is that much less
    work to make nice fallbacks (e.g. proper validation).

BTW speaking of validation, I'm pondering if scope(failure)
could make elegant code for that...



But, hey, I'm calling it a win. The suckage of browsers
is a reality regardless of the language.
Mar 02 2012
prev sibling next sibling parent Bystroushaak <bystrousak kitakitsune.org> writes:
 ADM 5120 is MIPS, right? Are you trying to build a cross compiler or a
 compiler running on the MIPS itself? 

Compiler running on the MIPS.
 And MIPS is probably also affected by GDC issue 120, so you have to
 configure like this:
 DFLAGS="-fno-section-anchors" ./configure [configure arguments here]

Thanks.
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 March 2012 at 18:28:15 UTC, Nick Sabalausky wrote:
 Suggestion: Allow all D features even if it
 requires...inefficient-er...boilerplate, BUT then have a system 
 [...]

Eh. A problem there is those pragmas or whatever would be unrecognized by the real dmd. A command line switch, maybe, though. But on pragmas, I have extern(js) and pragma(no_js_output), but I want to keep them hidden inside the library modules. Even if you version() something out, if dmd's lexer doesn't understand it, it won't compile under the normal thing. This breaks the benefit of same code on both sides. But, version(generating_js) import something; always works. That's about as fine-grained as I think it should be. But, on this stuff, if it is there, I think it is ok to use it. The key though is to not pay for what you don't use. The gcfunctions helper app (in src/test/tools) acts like a static linker here, cutting out unreferenced functions and variables. The library now can define a whole mess of functions, and if you don't use them, they get stripped out of the final file. The key is then: a) not referencing stuff in a hidden fashion; make sure typical D code is still small and b) minimizing interdependencies, so pulling in one function doesn't pull in a whole package. This is something that's generally desirable in regular D, too (for the same reason, even) so it is I think a good path.
Mar 02 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 29.02.2012, 04:11 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>:

 sort can be a wrapper of Array.prototype.sort() from Javascript,
 thus letting us leave out the implementation. Odds are the native
 method will be faster anyway.

That's right, although at least Google tries to implement the predefined functions in JS as well (that's what an engineer said in a video podcast)
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 3 March 2012 at 00:56:48 UTC, Daniel Murphy wrote:
 Something like this should work:

Awesome, it does! Thanks.
Mar 02 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 3 March 2012 at 12:12:53 UTC, Jacob Carlborg wrote:
 Wouldn't you save a lot of characters by properly scoping the 
 variables instead of using unique names?

There's no such thing as proper scoping in Javascript. The next best thing is the nested functions, but that's really just trading one poison for another. D mangled names do a lot more than scoping, too, anyway. Mangled names overload properly: void a(int, int); void a(int, string); a(1, "one"); // which one gets called? With dmd's name mangling, it Just Works. Now, there might be something to gain by using prettier local variable names, but it is a lot of extra work and IMO the benefit is still very small. Note that local variables are still local variables 95% of the time (and the other 5% is a bug that I'm hoping to fix today), so its already scoped almost as well as it can be on the function level. The biggest benefit is readability and size. Size is handled by running it through a string replacer (tools/mangledown.d). Readability is a nice gain, but not an essential one I think; it is readable right now if you want to.
Mar 03 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 3 March 2012 at 12:10:47 UTC, Jacob Carlborg wrote:
 No, we don't want to do it like Dart:
 17260 lines of code for Hello World.

Wow. I thought I was a bit on the bloated side with ~100 lines of boilerplate (before running the unused function stripper). $ ../dmd -md object.d DMD v2.058 DEBUG $ wc object.js 108 472 11843 object.js Then again, when giant things like jQuery is considered a "necessity" when I get by just fine with my 10 KB (source, not minified, not gzipped) custom library, if even that, it shows there's a big disconnect between me and most other web people nowadays.
Mar 03 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 3 March 2012 at 16:29:25 UTC, Adam D. Ruppe wrote:
 There's no such thing as proper scoping in Javascript.

Let me expand a bit. consider this D: if(1) { int a = 3; } In JS, right now, that'd output: if(1) { var mangled_a = 3; } which, to the interpreter, is: var mangled_a; if(1) { mangled_a = 3; } thanks to declaration hoisting. If you want it to be scoped literally like D, it'd look more like this: if(1) { function() { var a = 3; }(); } I really doubt that'd help performance. Another option is to reuse declarations: if(1) { int a = 0; } string a = ""; could become: var a; if(1) { a = 0; } a = ""; // we know the old a is out of scope, so we'll reuse it but I don't see a big benefit there either. Now, the JS compiler will definitely see a as a dynamically typed var, and may not be able to do the same optimizations it could if it had a consistent type. When you consider the bug-pronedness of me doing this instead of relying on dmd's well debugged mangling process to do it all for me, I really think it is a net loss, despite the slightly more readable names. Oh another thing: global variables in D are module scoped. The mangledness again handles that for me. Just another bug opportunity. Perhaps a smarter helper tool could make pretty names, but I don't want to put it in the compiler.
Mar 03 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 4 March 2012 05:40, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Saturday, 3 March 2012 at 12:10:47 UTC, Jacob Carlborg wrote:
 No, we don't want to do it like Dart:
 17260 lines of code for Hello World.

Wow. I thought I was a bit on the bloated side with ~100 lines of boilerplate (before running the unused function stripper). $ ../dmd -md object.d DMD v2.058 DEBUG $ wc object.js =C2=A0108 =C2=A0 472 11843 object.js Then again, when giant things like jQuery is considered a "necessity" when I get by just fine with my 10 KB (source, not minified, not gzipped) custom library, if even that, it shows there's a big disconnect between me and most other web people nowadays.

Hmm, does your DOM library compile with this? Also, is it smaller than jQuery? And how easy would it be to make it work with the browser dom? This is mostly because I pretty much use jQuery for AJAX and Dom manipulation, everything is just extras. -- James Miller
Mar 03 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/3/12, Adam D. Ruppe <destructionator gmail.com> wrote:
 Oh another thing: global variables in D are module scoped.

Could export help?
Mar 03 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 4 March 2012 at 00:05:19 UTC, James Miller wrote:
 Hmm, does your DOM library compile with this?

No. I want do a port of some of the functions to it, though. (Even if I fix it to not use goto, so it compiles to JS, I don't actually need a parser in the browser - it should use native methods when possible. So, my strategy will be to port convenience functions instead of the whole thing.) For Javascript dom stuff, I'm generally happy enough with the browser's api alone, but my little js file ports some of my convenience functions: addChild insertAfter prependChild hasClass toggleClass removeClass addClass getParent appendText replaceText removeFromTree All as free functions in Javascript. Together with what the browser already has, that covers everything I want, well, except for dataset which is beautiful on the server, but meh on the client since you have to use getAttribute for compatibility. But, that's not a big deal. I didn't port most of my form functions in dom.d because I just don't do that kind of stuff client side anyway. (Other stuff in my js lib are some functional programming helpers and an event compatibility set.) But, for the D->JS DOM additions, these functions are pretty much what I want. My strategy I'm considering is to make a separate document module, that replaces the browser.document. Using alias this magic, I'll make extension classes that are compatible with the real thing, without any runtime wrapping. It'll be like a homemade UFCS: final class BetterElement { JSElement __js_this; alias __js_this this; BetterElement addClass(string c) { className ~= " " ~ c; } } /* do the same for document */ auto be = document.querySelector("#foo > p"); be.addClass("test"); When this is compiled, it comes out as: function addClass(c, d_this) { d_this.className += " " + c; } var be = document.querySelector("#foo > p"); addClass("test", be); Which is about as minimal as you can get in JS (it's about the same as I wrote by hand), while keeping the beautiful syntax in D. Anyway, bottom line is my goal is indeed to have a compatible version of my dom library for D->JS too, but it will have almost a completely separate implementation to be more efficient in the browser environment.
Mar 03 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 28 February 2012 at 03:06:12 UTC, Daniel Murphy wrote:
 Cool, please do.

I suck at using git, but I think it works now: https://github.com/adamdruppe/dmd/tree/dtojs The backend refused to die in the last 45 minutes, so I just left it there. I'm pretty sure it is up to date to real dmd now too... i hope. Anyway there it is.
Mar 03 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 4 March 2012 at 06:50:48 UTC, Daniel Murphy wrote:
 Lol, I think you revered a bunch of stuff when you rebased it.

git and I don't quite understand each other yet. $ git eat flaming death git: 'eat' is not a git command. See 'git --help'. aaaarrrggggh
Mar 04 2012
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 3 March 2012 at 12:10:47 UTC, Jacob Carlborg wrote:
 On 2012-03-02 15:38, Adam D. Ruppe wrote:
 On Friday, 2 March 2012 at 05:58:03 UTC, Nick Sabalausky wrote:
 You make it sound as if there's another kind of JS.

Horribly inefficient relative to the environment :P I just don't want 100 kb of crap to download just to write a hello world. A lot of people prefer to use gzipped sizes, but I don't because the browser still has to parse the whole thing, and that takes time after the download, even if you don't actually run any of it. (On some browsers, it parses it again on every page load!) This generated D code gzips very, very well, but I still want to keep it small in general for general speed. The fastest code is no code at all. Less to parse, less to run.

No, we don't want to do it like Dart: https://gist.github.com/1277224 17260 lines of code for Hello World.

To be fair to Dart, that was from the initial preview release of it. They managed to get it quite a bit smaller a couple months ago. https://gist.github.com/1385015 Regards, Brad Anderson
Mar 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 4 March 2012 at 00:09:11 UTC, Andrej Mitrovic wrote:
 Could export help?

Not for the global (that's handled adequately by dmd's name mangling anyway), but I did just add export checking as comments. export void foo() {} becomes function /*export*/ mangled_foo() {} the idea is then tools like gcfunctions will know not to strip that function out, since it may be referenced in another module. It also occurs to me that .di generation may be useful here for things like server communication. So that might be cool.
Mar 04 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 7 March 2012 16:19, Nick Sabalausky <a a.a> wrote:
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:mxstsriydkbxxrjlfxqn forum.dlang.org...
 Then again, when giant things like jQuery is considered
 a "necessity" when I get by just fine with my 10 KB
 (source, not minified, not gzipped) custom library,
 if even that, it shows there's a big disconnect between
 me and most other web people nowadays.

Yea, a disconnect of about 50 IQ points (in your favor). Things like that are why I hate "typical" web developers and webdev "conventional wisdom" (hah!) with a burning passion. We're talking "thermonuclear power of a thousand suns" here.

I don't know what webdev "conventional wisdom" is, but it would be nice to use site that don't eat my CPU because of a billion different javascript, erm, scripts all trying to do things. There's something to be said for rolling your own libraries. However, I would like jQuery's CSS selector engine as a standalone library, sooo much easier than complex DOM lookups, especially when you want something fairly specific. -- James Miller
Mar 06 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 7 March 2012 at 03:46:45 UTC, James Miller wrote:
 However, I would like jQuery's CSS selector engine as a 
 standalone library, sooo much easier than complex DOM lookups

CSS selector is built into all the browsers since IE8/FF3.5. The functions are element.querySelector and element.querySelectorAll. http://msdn.microsoft.com/en-us/library/cc304119%28v=VS.85%29.aspx https://developer.mozilla.org/En/DOM/Document.querySelector If you need to support older browsers, I think jquery's engine is called Sizzle stand alone, but I just let it throw the method not found exception, and carry on without the javascript. It's not worth the size.
Mar 06 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 7 March 2012 16:51, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Wednesday, 7 March 2012 at 03:46:45 UTC, James Miller wrote:
 However, I would like jQuery's CSS selector engine as a standalone
 library, sooo much easier than complex DOM lookups

CSS selector is built into all the browsers since IE8/FF3.5. The functions are element.querySelector and element.querySelectorAll. http://msdn.microsoft.com/en-us/library/cc304119%28v=VS.85%29.aspx https://developer.mozilla.org/En/DOM/Document.querySelector If you need to support older browsers, I think jquery's engine is called Sizzle stand alone, but I just let it throw the method not found exception, and carry on without the javascript. It's not worth the size.

Oh right, I didn't know that, IE8 and FF3.5 are old enough that you can use it without too much worry, older browsers can just have some graceful fallback. -- James Miller
Mar 06 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 01.03.2012, 17:29 Uhr, schrieb Robert Clipsham <robert octarineparrot.com>:

 Interesting idea:

 version(JavaScript) asm
 {
      /* Well... it's not really asm, but it's
         as close as you could get with a javascript backend :p */
      document.write("Oh look, inline javascript D-:");
 }

 Perhaps it would be better to have a dedicated function for that though.

How about: pragma(js) { document.write("Oh look, inline javascript D-:"); }
Mar 08 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
This is still alive:

https://github.com/adamdruppe/dmd/tree/dtojs

Merging in DMD changes as they happen has been fairly
easy, so we have things like UFCS in there.

I'm pretty happy with the core setup, though it still
isn't finished. Enough of the D language works like
you expect that you can do a lot of things with it
naturally.

Thus, I've moved on to libraries. I previously
talked about the jslang and browser packages. These
provide zero-overhead, direct access to javascript
built-ins.

You can also use a good chunk of the real Phobos in
here if you want.


But now, I'm adding minimal overhead nicer libraries,
including a port of my dom.d, adopted to try to
cover some browser incompatibilities. (The browser
package, being zero overhead, makes no attempt at
this. It just provides the tools to DIY.)


The trick is though, doing it with as lean code as
possible. Here's my domtest.d:

import arsd.dom;
import browser.window;

void main() {
	Element e = document.getElementById("cool");
	e.addClass("sweet");
	e.style = "font-weight: bold;";
	e.style.fontSize = "30px";
	e.innerText = e.style;
	window.alert(e.parentNode.tagName);
	e.removeFromTree();
}


It generates about 2 kb of javascript, libraries
included, after you strip unused functions and
reduce the variable name length. (NOT gzipped!)

Let's talk about one line at a time:

	Element e = document.getElementById("cool");

In browser.document, there are JSElement and JSDocument
classes defined. Here, though, I'm using a custom
type: Element.

The implementation for this uses zero overhead forwarding
to native methods, unless I override them, in which case
it is implemented as a free function.

Many functions are now mixin templates in browser.document
so I don't have to repeat them, even if changing types.

Using alias this, these are compatible with the native
types as well.


	e.addClass("sweet");

Is a new function in class Element. It manipulates the
native className property and in the resulting .js file
is a free function.

	e.style = "font-weight: bold;";

The style object is defined in browser.document and has
a  long list of properties. It maps directly to native
code, but with one addition:

    alias cssText this;


style.cssText in Javascript is the attribute as a string.
In my dom.d, Element.style can be treated as a string or
a struct, and I wanted that here too.

alias this accomplishes that goal with zero overhead.
e.style = ""; translates simply to e.style.cssText = "";

	e.style.fontSize = "30px";

The property is a native one, nothing special here.

	e.innerText = e.style;

innerText, while a property on some browsers, isn't present
on all of them.

Thus, class Element defines it itself. This generates a free
function (with a mangled D name, so no conflict) that is
called using D property syntax.

The generated code looks like this:
     _D_mangled_innerText(e.style.cssText, e);



This is the general pattern I'll do for browser compatibility.
Use the real name in D, but let it implement as free functions
with mangled names.

	window.alert(e.parentNode.tagName);


The browser.window module defines some things that are global
in JS, including alert(). e.parentNode returns an Element,
thanks to a mixin that can specialize on types with zero overhead.


tagName, while a native property, is actually a function here.
The reason is dom.d uses lowercase tag names, but Javascript
uses uppercase.

Thus, this is implemented:

 property string tagName() { return 
__js_this.tagName.toLowerCase(); }


and the above line calls a D function. Some overhead, but very
little.

	e.removeFromTree();


Finally, this is just a regular function. I'm thinking about
changing it to UFCS though so it can check for null on e too.

(It does:

  if(parentNode) parentNode.removeChild(this);

the idea being to just ensure it isn't in the tree without
needing an external null check.

If this is null, it is also not in the tree, so its contract
is satisified anyway, so it might as well succeed. Currently,
though, it will not work since the Element invariant will
segfault it.)




But, there's a rundown of what I'm doing with libraries.
Beautiful D code, compatible implementations, minimal
overhead.


I'll be posting the library soon, and then this will
be sharable.
Mar 17 2012