February 27, 2012
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  $()
> > jquery
> > function for better elements handling (instead of
> > 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.
> 
> 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
> 


Very interesting! :)


February 28, 2012
"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.


February 28, 2012
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.

February 28, 2012
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.
February 28, 2012
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.
February 28, 2012
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.
February 29, 2012
Fuck. Yes.

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

Please do more!
February 29, 2012
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.
February 29, 2012
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.

February 29, 2012
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;