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.

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).

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.

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?

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/

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/

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!

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.

> Daniel Murphy's microd fork of dmd, meant to output C

Link please.

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/