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.

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

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

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
> [snip]
>
> 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

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

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.

"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
>> [snip]
>>
>> 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.)

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.

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
> 

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

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.