On Friday, 4 November 2016 at 10:59:25 UTC, Marc Schütz wrote:
> In this case better make sure to remove the resulting dead code from the old interpreter, otherwise it will become and unmaintainable mess in the long run.

interpreter is used all over the code, and it is a set of visitors doing various things. that is, it is not possible to remove "dead code" from it, only replace it as a whole. which is a great achievement, but completely unpractical. it is way, way easier to build the basic VM that runs alongside the old interpreter, and call old one if new VM found something it can't process yet. this way new VM can be used to speed up some parts, but nothing will be broken, and VM can be refined gradually. also, it is great for testing: one can call new and old interpreters and compare results. as new VM is completely independent of old interpreter, the code won't be any messier than it is now. ;-)

from a technical POV CTFE interpreter is just a codegen: it receiving lowered AST, visit nodes and does some actions. one can have many codegens in frontend code, they won't hurt each other. ;-)

On Saturday, 5 November 2016 at 03:01:48 UTC, ketmar wrote:
> On Friday, 4 November 2016 at 10:59:25 UTC, Marc Schütz wrote:
>> In this case better make sure to remove the resulting dead code from the old interpreter, otherwise it will become and unmaintainable mess in the long run.
>
> interpreter is used all over the code, and it is a set of visitors doing various things. that is, it is not possible to remove "dead code" from it, only replace it as a whole.

Yes what ketmar said.

It is looking good, current testsuite-failures are caused by the new engines missing checks for ub, and the inability to signal those errors.

Figuring out a good mechanism for error-signaling is the next challenge.

On Saturday, November 05, 2016 01:21:48 Stefan Koch via Digitalmars-d wrote:
> I thought about it some more, and decided that I will replace the
> old interpreter completely in the long run.
> However in order to get something release before 2017, I have to
> rely on it being there.

That seems reasonable, but it definitely seems messy to leave the old stuff there in the long run, especially if only part of it is really used and tested.

- Jonathan M Davis

On 06/11/2016 1:57 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Saturday, November 05, 2016 01:21:48 Stefan Koch via Digitalmars-d wrote:
>> I thought about it some more, and decided that I will replace the
>> old interpreter completely in the long run.
>> However in order to get something release before 2017, I have to
>> rely on it being there.
>
> That seems reasonable, but it definitely seems messy to leave the old stuff
> there in the long run, especially if only part of it is really used and
> tested.
>
> - Jonathan M Davis

Based upon some help I gave Stefan early on with the current implementation, it will be left alone as is. It doesn't need to change in any way beyond the entry point.

So not at all messy and it certainly is already well tested.
Especially since it is mostly localized to a single file.

On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch wrote:
> I thought about it some more, and decided that I will replace the old interpreter completely in the long run.
> However in order to get something release before 2017, I have to rely on it being there.

That's better of course. Parallel use of new and old just shouldn't stay there indefinitely. Look at the problems with the AA implementation as a similar example.

>
> I recently lost 3 days of work because of my git-skills.

Unless you haven't committed your work yet, almost everything in Git can be undone. Make a copy of your entire project directory (including .git) and then have a look at `git reflog` around the time the disaster happened. It will show you commit IDs that you can check out.

On Saturday, 5 November 2016 at 15:48:19 UTC, Marc Schütz wrote:
>> I recently lost 3 days of work because of my git-skills.
>
> Unless you haven't committed your work yet, almost everything in Git can be undone. Make a copy of your entire project directory (including .git) and then have a look at `git reflog` around the time the disaster happened. It will show you commit IDs that you can check out.

Solid advice right there ^

On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch wrote:
> I thought about it some more, and decided that I will replace the old interpreter completely in the long run.
> However in order to get something release before 2017, I have to rely on it being there.
>

Good thinking.

On 11/4/16 9:21 PM, Stefan Koch wrote:
> I thought about it some more, and decided that I will replace the old
> interpreter completely in the long run.
> However in order to get something release before 2017, I have to rely on
> it being there.

That's good thinking - leave short term to the short term and long term to the long term. As the Romanian proverb goes: "Don't sell the skin of the bear before you shoot it." -- Andrei

On Saturday, 5 November 2016 at 15:48:19 UTC, Marc Schütz wrote:
> Unless you haven't committed your work yet, almost everything in Git can be undone. Make a copy of your entire project directory (including .git) and then have a look at `git reflog` around the time the disaster happened. It will show you commit IDs that you can check out.

especially if one will turn off automatic git gc.

On Saturday, 5 November 2016 at 20:57:06 UTC, Andrei Alexandrescu wrote:
> On 11/4/16 9:21 PM, Stefan Koch wrote:
>> I thought about it some more, and decided that I will replace the old
>> interpreter completely in the long run.
>> However in order to get something release before 2017, I have to rely on
>> it being there.
>
> That's good thinking - leave short term to the short term and long term to the long term. As the Romanian proverb goes: "Don't sell the skin of the bear before you shoot it." -- Andrei

I would interpret this proverb as referring to sequential consistency.

A just a small update today:

I just introduced questionable code that enables the interpreter-backed to pass the phobos unitests but will cause the llvm backend to fail.

Also, the list of manual bail-outs just grew by a few members.

Currently work on Function-Call support is halted in favor of investigating why the bail-outs are necessary.

I begun some work on returning Error-Information for the BC-backends.
This is rather difficult due to the high degree of separation between the ctfe-engine and the rest of dmd.

A nice weekend to all of you.


P.S.
Phobos and druntime unittests do compile now.
After the ability for returning errors is added all unitests will be passed. (Most likely if there are not more bugs inside the engine)