Dart bindings for D?

[Rikki Cattermole via Digitalmars-d-learn]

On 31/10/2014 6:39 a.m., Laeeth Isharc wrote:
> Hi.
>
> Thanks for all the thoughts, and sorry it has taken me a little while to
> reply.
>
> Adam - I liked your book very much: it really complemented the other
> resources out there, especially in communicating a refreshing spirit of
> enthusiasm and fearless exploration.
>
> ketmar - I took a look at script.d very briefly.  I would love if I
> could use some kind of D-like and D-friendly scripting language on the
> client (Suliman has a point!), but my understanding is that I cannot if
> I want to use standard browsers without a plugin - Chrome, Firefox, etc.
>
> BTW what was the story behind dscript?  It seems to have changed its
> name and no longer have so much connection to D:
> http://forum.dlang.org/thread/422BE824.6030001@nospam.org
>
> "It would be awesome to write front-end tools in D. However, there won't
> be much browser support unless you're backed by Google or Microsoft."
>
> Etienne - yes, indeed.  That is exactly the problem.  In theory your
> suggestion of compiling D to Javascript sounds intriguing, but I wonder
> if in practice it will be worth it on the client (I confess that you
> likely know much more about this than me).  Even if interoperability
> with the ecosystem is possible, I suppose it will be clunkier to write
> in D compiled to JS than in Dart because there are fewer people pouring
> energy into the project to make it easy.  I don't mind reimplementing
> some things on the back end in order to make it fast, beautiful, and
> efficient but I have no interest in re-writing anything in user
> interface domain.  (Others may be different).
>
> As a second-best, but overall pretty appealing choice (superficially,
> since I haven't written anything substantial in it), Dart at least has a
> C-like syntax, seems to avoid most of the JS infelicities, and has some
> of the benefits of type-checking.  It hasn't taken off yet, but my guess
> is it will.
>
> "What kind of client are you doing? If you are writing a web page,
> you don't need any kind of script language API. JavaScript or
> dart or whatever talk with your server application through http
> requests or websockets, whereas script language APIs are meant
> for extending your application in the same process. For example,
> a text editor might have a script language to make custom
> functions for hotkeys." - Adam Ruppe
>
> Proprietary trading analytics and charting - still at an early stage so
> the design is not fully mapped out.  I understand that if I run D on
> server and Dart on client then I don't need to worry about APIs.  But 1)
> if I decide to run Dart on server and write my number-crunching
> analytics in D then I suppose I either need the Dart headers translated
> to D (API) or have the Dart web server talk to a D analytics server via
> a socket.  And 2) I cannot say that I definitely do not want to cache
> things and do some work on client, and so I need to see what's possible
> to avoid getting trapped in purely local optimum.  3) It's a long way
> from being relevant, but ultimately realtime data licensing occurs at
> local user level for Bloomberg etc, so much better to be able to tap in
> to a data source the user already has.
>
> "Dart makes most sense for internal web applications."- Ola
>
> Yes - exactly my situation.
>
> "Dart VM is available as a standalone, which can be set up to act
> as a web server. But you want to integrate it into D?" - Ola
>
> There are already C headers, and it is simple to wrap any C function
> manually so you can call it from Dart.  Perhaps it would be possible to
> do something like PyD (I am still learning templates/CTFE so I don't
> know), but for now I was just thinking of converting the 3000 line odd
> (but mostly whitespace) header from .h to .d.  Most of it's easy, but I
> struggled a bit with syntax for using alias in D to declare function
> pointer return types and parameters  (I think I get it now).
>
> Why bother?  D seems just perfect for the particular kind of quant
> financial work I want to do, but for the time being it is lacking on web
> server and client.  Vibe.d is great, but is not a complete framework
> from what I have seen (which is fine, since it doesn't pretend to be
> one, but makes it harder if you don't want to spend your time on this).
> And we discussed the client above. So I need to have some way for Dart
> to talk to D.

That's Cmsed, it can generate javascript (prototype currently but 
possible for jquery) ajax code for calling routes and CRUD for data models.
The next version is a bit off from having that support but it will have 
much better development.

> "I don't think so, but integrating DartVM into D means you have to
> deal with two different garbage collectors or put a substantial
> amount of work into making D use the Dart collector."
>
> Thanks for the warning.  I will have a low number of users, and whilst
> on occasion working data sets might be large, they won't stick around
> for very long so pre-allocating buffers should work fine (I hope).
>
> Thanks once again to everyone for all the suggestions and observations.
>
>
> Laeeth/
>
> On Wednesday, 29 October 2014 at 22:12:32 UTC, Laeeth Isharc wrote:
>> Hi.
>>
>> I have had a look around for these, but was not able to see them.
>>  It looks perhaps like dart_api.h is the main file to convert - I will
>> have a crack at starting this unless anyone knows of any already in
>> existence.
>>
>> Rationale for using Dart in combination with D is that I am not
>> thrilled about learning or writing in Javascript, yet one has to do
>> processing on the client in some language, and there seem very few
>> viable alternatives for that.  It would be nice to run D from front to
>> back, but at least Dart has C-like syntax and is reasonably well
>> thought out.
>>
>> Am I missing any existing bindings somewhere?
>>
>> Thanks.
>>
>>
>> Laeeth.
>