March 02, 2012
"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
>>>> [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.)
>
> 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.)


March 02, 2012
"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).


March 02, 2012
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.
March 02, 2012
"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 :(


March 02, 2012
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)
March 03, 2012
"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");


March 03, 2012
On Saturday, 3 March 2012 at 00:56:48 UTC, Daniel Murphy wrote:
> Something like this should work:

Awesome, it does! Thanks.

March 03, 2012
"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?)


March 03, 2012
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
March 03, 2012
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