Re: D to Javascript converter (a hacked up dmd)
I love how this started as interesting and turned into awesome. Web programming... might actually become non-horrible?
Re: D to Javascript converter (a hacked up dmd)
Bystroushaak bystrou...@kitakitsune.org wrote in message news:mailman.239.1330541205.24984.digitalmars-d-annou...@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.
Re: D forums now live!
On Friday, 24 February 2012 at 17:43:16 UTC, Vladimir Panteleev wrote: On Thursday, 23 February 2012 at 02:52:24 UTC, XP1 wrote: Would the user be able to change one's password in the future? There's technically no reason why this can't be implemented, but I'm having a hard time coming up with reasons why people would want that, This is much nicer than the old web archive interface. But I couldn't log in with the password I registered with (as a matter of course I use 30-character random passwords), so I had to create a second account with a shorter password. Is there a maximum length password and it's being silently truncated or something? Or disallowed characters which are silently accepted/modified? The registration screen should document what limits on passwords exist.
Re: D to Javascript converter (a hacked up dmd)
Am 29.02.2012, 18:32 Uhr, schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: 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 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. :)
Re: D to Javascript converter (a hacked up dmd)
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/
Re: D to Javascript converter (a hacked up dmd)
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.
Re: D to Javascript converter (a hacked up dmd)
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
Re: D to Javascript converter (a hacked up dmd)
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 [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. 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.
libgc-d: Binding to the Boehm-Demers-Weiser C/C++ GC
Hi, libgc-d is a binding to the libgc garbage collection library (also known as the Boehm-Demers-Weiser GC). This library is primarily useful in the D world for programming language implementations and virtual machines, as D has a built-in GC (though, nothing stops you from using libgc-d for your normal allocations). https://github.com/lycus/libgc-d It's still very much alpha quality. I've only done some small, silly tests, but everything *seems* to work. See README.md for limitations, build instructions, etc. Note also that this binding is just that - a binding. It doesn't provide any high-level wrappers around libgc. Feedback welcome. :) -- - Alex
Re: D to Javascript converter (a hacked up dmd)
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 [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. 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
Re: D to Javascript converter (a hacked up dmd)
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
Re: D to Javascript converter (a hacked up dmd)
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
Re: D to Javascript converter (a hacked up dmd)
On Thu, Mar 1, 2012 at 11:13 AM, Adam D. Ruppe destructiona...@gmail.comwrote: 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
Re: D to Javascript converter (a hacked up dmd)
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 [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. 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
Re: D to Javascript converter (a hacked up dmd)
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
Re: D to Javascript converter (a hacked up dmd)
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. C run pretty much everywhere and metacompiler D2C would be nice.. On 1.3.2012 09:05, Daniel Murphy wrote: Bystroushaak bystrou...@kitakitsune.org wrote in message news:mailman.239.1330541205.24984.digitalmars-d-annou...@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.
Re: D to Javascript converter (a hacked up dmd)
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.
Re: Mono-D 0.3.0
Awesome job, Alex! With the performance improvements of Mono 2.8.6.5 and Parser/Performance improvements of Mono-D 3.0 working with D is on par with working with C# in Visual Studios. Even better since I get the same experience on all three platforms. It would be nice to see Mono-D (and other IDEs) linked to from the dlang.org somewhere. So new D users won't have to dig through the forums or sift through dead dsource.org projects to find it. Seeing as how, for some of us, proper IDE support is a big issue, and Mono-D + MonoDevelop is virtually on-par with Visual Studios (productivity wise). I think it would help D's popularity to some degree if we could direct people to some officially supported IDEs. With Mono-D on top of course! ;)
Re: TDPL monthly sales at 12-month high
WORK YOU SLAVES!! BWAHAHAHA!! No seriously. Thank you! To all the contributes. Really appreciate it :)
Re: D to Javascript converter (a hacked up dmd)
Bystroushaak bystrou...@kitakitsune.org wrote in message news:mailman.281.1330632834.24984.digitalmars-d-annou...@puremagic.com... 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. C run pretty much everywhere and metacompiler D2C would be nice.. I think once you get past the horror that is building gcc for your target platform, the big issue remaining is that druntime needs to be ported. You'll hit the same issue with a D-C translator, so it might be better just to work on the actual runtime. Doing a proper gdc-based compiler should get you some other nice things, like platform specific attributes/versions, inline asm, and a better debugging experience.
Re: D to Javascript converter (a hacked up dmd)
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.
Re: D to Javascript converter (a hacked up dmd)
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.
Re: Please try rdmd on large projects
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:jhugqd$26v0$1...@digitalmars.com... Hello, I just submitted (https://github.com/D-Programming-Language/tools/commit/c77b870fdc5674d7434b03d1767ba831eaac25b1) a change to rdmd that runs one thread per stat when comparing file dates, using David's excellent std.parallelism. In my experiment the change introduces no additional lag on small projects and works 10-15% faster on moderate projects (couple dozen deps). Could someone try rdmd against some larger projects and assess its behavior and speed? Finally got a change to try this. The projects probably aren't as big as what you had in mind, but I tried: rdmd 0124c6b61a VS rdmd 75f292fffd Compiling: - Compiling all of Goldie's targets with DMD 2.058 - Attempting to compile DDMD with DMD 2.053 (the build failed pretty quickly, but not until after RDMD would DMD for the second time) On: - 32-bit single-core Linux, using a HDD - 32-bit single-core Windows, using a HDD - 64-bit dual-core Linux, using a USB Flash drive On all combinations I got no difference between the two versions of RDMD (which is good in the case of the single-core machines, of course). The once slight exception was that compiling Goldie's targets on the 64-bit dual-core machine was about 1-2% faster with the newer RDMD (75f292fffd) compared with the older (0124c6b61a). Could just be noise, though. There was one weird anomaly: When compiling the Goldie targets on the 64-bit dual-core, I compiled all of Goldie 8 times with each of the two RDMDs. On *ONE* of the compilations with the newer RDMD, one of the targets failed to build with a DMD ICE: dmd: ../ztc/aa.c:423: void AArray::rehash_x(aaA*, aaA**, size_t): Assertion `0' failed. I hadn't touched anything during or in-between compilations.
Re: D to Javascript converter (a hacked up dmd)
Ary Manzana a...@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.
Re: D to Javascript converter (a hacked up dmd)
Adam D. Ruppe destructiona...@gmail.com wrote in message news:uvagboafiyjrhvywp...@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.
Re: D to Javascript converter (a hacked up dmd)
On 2012-02-29 18:46, Nick Sabalausky wrote: Alex Rønne Petersenxtzgzo...@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. -- /Jacob Carlborg
