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.

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

On Thu, 30 Oct 2014 17:39:13 +0000
Laeeth Isharc via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> 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
we have rdmd now, which can be used in shebangs and allows to run D programs as shell scrips. it is able to track dependencies and caching compiled script, so 2nd and other invocations will be very fast.

Ah - makes sense.  It is satisfyingly fast...

On Thursday, 30 October 2014 at 21:33:59 UTC, ketmar via Digitalmars-d-learn wrote:
> On Thu, 30 Oct 2014 17:39:13 +0000
> Laeeth Isharc via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com> wrote:
>
>> 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
> we have rdmd now, which can be used in shebangs and allows to run D
> programs as shell scrips. it is able to track dependencies and caching
> compiled script, so 2nd and other invocations will be very fast.

On Thu, 30 Oct 2014 22:18:22 +0000
Laeeth Isharc via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> Ah - makes sense.  It is satisfyingly fast...
the only bad thing is that it trashes /tmp/.rdmd-$UID dir. i wrote another simple script that is clearing that dir (but doesn't touch 'locked' dirs, as they are obviously in use) and put it in cron.

this may or may not be the issue for you.

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

On Thursday, 30 October 2014 at 17:39:14 UTC, Laeeth Isharc wrote:
> 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).

Dart+DartVM+D/C/C++ sounds like a good option for you. I have not tried integration with DartVM, but it looks like Dart team is aiming for App Engine support and they need to compete with node.js. So, it looks like DartVM support is a priority for Google.

On Thursday, 30 October 2014 at 02:27:58 UTC, ketmar via Digitalmars-d-learn wrote:
> it was very funny to show some people D code with your jsvar
> and listenting how they don't want to learn just another
> scripting language. and then compile the code with DMD to
> confuse them even more.

hehe, that was the main idea!

On Thursday, 30 October 2014 at 17:39:14 UTC, Laeeth Isharc wrote:
> 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.

One thing you should consider is that asm.js has this very cool ability to run eval() dynamically on the client and generate machinecode on the fly. You will probably get 30-50% of the D speed, but you will be getting OpenCL on the client in the future which will beat anything on the CPU…

Just sayin'. There's some cool JIT capabilities in browsers that can be used for optimized queries on data in combination with local storage (all modern web browsers support this). And it is only getting better…

(But dart is still a safe bet… you can call out to Javascript)