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

Reply via email to