On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I have been looking into the DMD now to see what I can do about CTFE.
> [ .... ]
> I will post more details as soon as I dive deeper into the code.

I decided to keep a gist updated to represent the current state the new engine can handle.

https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e

This is the currentState after approx. 50 hours of work

On Saturday, 9 July 2016 at 20:09:14 UTC, Stefan Koch wrote:
>
> I decided to keep a gist updated to represent the current state the new engine can handle.
>
> https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e
>
> This is the currentState after approx. 50 hours of work

First StringIndexing works now.
The next step is getting structs right,

On Thursday, 14 July 2016 at 00:45:53 UTC, Stefan Koch wrote:
> On Saturday, 9 July 2016 at 20:09:14 UTC, Stefan Koch wrote:
>>
>> I decided to keep a gist updated to represent the current state the new engine can handle.
>>
>> https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e
>>
>> This is the currentState after approx. 50 hours of work
>
> First StringIndexing works now.
> The next step is getting structs right,

Support for _basic_ support for structs has just landed in my branch.
only structs with int or uint members are supported for now.
And no arrays.
But this is coming soon :)

On Friday, 15 July 2016 at 20:36:46 UTC, Stefan Koch wrote:
> I decided to keep a gist updated to represent the current state the new engine can handle.
> https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e

Internal changes to the bytecode engine make the manipulation of values on the ctfe stack possible.

this allows the following code to properly compile now.

struct V3 {int x; int y; int z;}
int fn() {

        auto b = V3(1,2,3);
        b.y += 19;
        return b.y;
}

static assert(fn() == 21);

Nice! how are you keeping track of changes? Are you tagging / branching each time you get something new working?

On Sun, Jul 17, 2016 at 12:12 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 15 July 2016 at 20:36:46 UTC, Stefan Koch wrote:
>
>> I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e
>>
>
> Internal changes to the bytecode engine make the manipulation of values on the ctfe stack possible.
>
> this allows the following code to properly compile now.
>
> struct V3 {int x; int y; int z;}
> int fn() {
>
>         auto b = V3(1,2,3);
>         b.y += 19;
>         return b.y;
> }
>
> static assert(fn() == 21);
>

On Sunday, 17 July 2016 at 12:12:17 UTC, Rory McGuire wrote:
> Nice! how are you keeping track of changes? Are you tagging / branching each time you get something new working?

I just push a new commit.
And add code to the gist.

Why would I branch ?
It all goes towards the same goal.

On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 17 July 2016 at 12:12:17 UTC, Rory McGuire wrote:
>
>> Nice! how are you keeping track of changes? Are you tagging / branching each time you get something new working?
>>
>
> I just push a new commit.
> And add code to the gist.
>
> Why would I branch ?
> It all goes towards the same goal.
>

A commit does pretty much the same thing. Tags/Branches just make UIs show
a "menu" for selecting a change, not important really. I had just wondered
if you were marking these milestones.
Someone could always branch off of any of your commits, it they wanted to
try an alternative approach (or learn from you).

Thanks for all the work you are doing. I love CTFE. I have a lot of big vibe (diet) templates, and my own Jade ctfe implementation, really looking forward to faster compile times.

R

On Sunday, 17 July 2016 at 13:04:33 UTC, Rory McGuire wrote:
> On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
>
>>[...]
>
> A commit does pretty much the same thing. Tags/Branches just make UIs show
> a "menu" for selecting a change, not important really. I had just wondered
> if you were marking these milestones.
> Someone could always branch off of any of your commits, it they wanted to
> try an alternative approach (or learn from you).
>
> Thanks for all the work you are doing. I love CTFE. I have a lot of big vibe (diet) templates, and my own Jade ctfe implementation, really looking forward to faster compile times.
>
> R

If you let me have a look at your jade-impl. I can probably work on speeding up it up. Vibed is still going to take a while. I need to figure all this UTF stuff out to make string handling robust.

On Sun, Jul 17, 2016 at 3:28 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 17 July 2016 at 13:04:33 UTC, Rory McGuire wrote:
>
>> On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
>>
>> [...]
>>>
>>
>> A commit does pretty much the same thing. Tags/Branches just make UIs show
>> a "menu" for selecting a change, not important really. I had just wondered
>> if you were marking these milestones.
>> Someone could always branch off of any of your commits, it they wanted to
>> try an alternative approach (or learn from you).
>>
>> Thanks for all the work you are doing. I love CTFE. I have a lot of big vibe (diet) templates, and my own Jade ctfe implementation, really looking forward to faster compile times.
>>
>> R
>>
>
> If you let me have a look at your jade-impl. I can probably work on speeding up it up. Vibed is still going to take a while. I need to figure all this UTF stuff out to make string handling robust.
>

Thanks that would be great, however I think its a while off before it can work on your ctfe implementation. It uses Pegged, so getting the Pegged JSON parser or pegged.peg working would be a first step.

If you were just meaning to show me any improvements I could make, the
source code is at:
https://github.com/rjmcguire/jaded


Cheers,
R

On Sunday, 17 July 2016 at 15:57:28 UTC, Rory McGuire wrote:
>
> Thanks that would be great, however I think its a while off before it can work on your ctfe implementation. It uses Pegged, so getting the Pegged JSON parser or pegged.peg working would be a first step.

pegged uses templates.
There is an intersection on which it can profit from CTFE improvments. But for the most part, it's a different sub-system in the compiler.

That said, templates are next on my TODO list.