On 12/26/2013 08:15 PM, Iain Buclaw wrote:
> I've been tempted to implement D in Guile - which is a cool extension
> language platform.  Implementing D ontop of its VM would make it
> effectively a REPL (with one or two features missing).  But when will
> I ever get time to do this? Probably never.:)

I've experimented with a D REPL based on shared libraries.
The biggest issue is the lack of a D parser library, other than that the approach works fine.

> In my experience with vibe.d, it's a massive pain in the arse that it's
> compiled.
> It seems to me that web dev involves squillions of micro-changes and
> tweaks, and it's bloody annoying to compile and reboot the server every
> time.
> vibe.d apps should be compiled for deployment, but a JIT option while
> developing/tweaking/tuning would speed up development by about 934x.
> I think that's the main hold-up for vibe.d compared to popular competition;
> the iteration time is just not good, but otherwise it's awesome.

I remember some people using http://www.dsource.org/projects/ddl for faster iterations (eg. Thomas Stachowiak in his PhD shader tool).

On 2013-12-27 01:43, Martin Nowak wrote:
> On 12/26/2013 08:15 PM, Iain Buclaw wrote:
>> I've been tempted to implement D in Guile - which is a cool extension
>> language platform.  Implementing D ontop of its VM would make it
>> effectively a REPL (with one or two features missing).  But when will
>> I ever get time to do this? Probably never.:)
>
> I've experimented with a D REPL based on shared libraries.
> The biggest issue is the lack of a D parser library, other than that the
> approach works fine.

You mean like Dscanner:

https://github.com/Hackerpilot/Dscanner/

-- 
/Jacob Carlborg

On 27 December 2013 09:37, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote:

> On Thursday, 26 December 2013 at 22:01:40 UTC, Manu wrote:
>
>> In my experience with vibe.d, it's a massive pain in the arse that it's
>> compiled.
>> It seems to me that web dev involves squillions of micro-changes and
>> tweaks, and it's bloody annoying to compile and reboot the server every
>> time.
>> vibe.d apps should be compiled for deployment, but a JIT option while
>> developing/tweaking/tuning would speed up development by about 934x.
>> I think that's the main hold-up for vibe.d compared to popular
>> competition;
>> the iteration time is just not good, but otherwise it's awesome.
>>
>
> Could it be workable to have a minimal server + plugins design akin to what you did with Remedy for game functionality?
>

Yeah, that's come up before. I've thought about it, but I haven't tried it
out.
It sounds good in theory, but it will be interesting to see if there are
any significant inconveniences introduced by the DLL boundary.

I have so many things pending on my short-list. I need to find time for all this stuff I wanna do! :P

On 27 December 2013 09:55, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 26 December 2013 at 23:37:07 UTC, Joseph Rushton Wakeling wrote:
>
>> Could it be workable to have a minimal server + plugins design akin to what you did with Remedy for game functionality?
>>
>
> You could also just use CGI, which doesn't require any restart for changes, and can also easily enough compile and cache lazily (like or even with rdmd)
>

Compile times are very slow even in my simple web applications when there are lots of templates sadly. Hopefully CTFE gets much faster in the future.

On Wednesday, 1 January 2014 at 09:40:45 UTC, Manu wrote:
> Compile times are very slow even in my simple web applications when there
> are lots of templates sadly. Hopefully CTFE gets much faster in the future.

Why doesn't D support some kind of partial evaluation instead? With llvm you get to JIT for free, seems to be an overall simpler solution than having an interpreter in the compiler (or equally complex, but more powerful)

On Wednesday, 1 January 2014 at 10:27:48 UTC, Ola Fosheim Grøstad wrote:
> Why doesn't D support some kind of partial evaluation instead? With llvm you get to JIT for free, seems to be an overall simpler solution than having an interpreter in the compiler (or equally complex, but more powerful)

Not really. You'd probably still need a powerful constant folder/interpreter to avoid firing up the LLVM JIT for every single trivial CTFE invocation.

David

On Wednesday, 1 January 2014 at 22:44:31 UTC, David Nadlinger wrote:
> Not really. You'd probably still need a powerful constant folder/interpreter to avoid firing up the LLVM JIT for every single trivial CTFE invocation.

Why is that? You could just aggregate them and execute them in a single run.

On Wednesday, 1 January 2014 at 22:44:31 UTC, David Nadlinger wrote:
> On Wednesday, 1 January 2014 at 10:27:48 UTC, Ola Fosheim Grøstad wrote:
>> Why doesn't D support some kind of partial evaluation instead? With llvm you get to JIT for free, seems to be an overall simpler solution than having an interpreter in the compiler (or equally complex, but more powerful)
>
> Not really. You'd probably still need a powerful constant folder/interpreter to avoid firing up the LLVM JIT for every single trivial CTFE invocation.
>
> David

That is still what SDC does :D

On Wednesday, 1 January 2014 at 22:52:34 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 1 January 2014 at 22:44:31 UTC, David Nadlinger wrote:
>> Not really. You'd probably still need a powerful constant folder/interpreter to avoid firing up the LLVM JIT for every single trivial CTFE invocation.
>
> Why is that? You could just aggregate them and execute them in a single run.

It is not possible as semantic analysis of a given piece of code can depend of the CTFE of another.

Also JITing for trivial thing that could be constant folded is much slower.