On Tuesday, 1 November 2016 at 21:12:06 UTC, Nordlöw wrote:
> On Tuesday, 1 November 2016 at 19:28:03 UTC, Stefan Koch wrote:
>> Now a phobos unittest miscompiles :(
>>
>> Again passing the unittests does not mean too much.
>> I just means I bail out before I generate invalid code :)
>
> Keep up!

I am now passing phobos unittests!
However please take it with a grain of salt ;)
The following line resbonsible for baling out of functions I know are failing.

	if (fd.ident == Identifier.idPool("isRooted") || fd.ident == Identifier.idPool("__lambda2") || fd.ident == Identifier.idPool("divideRoundUp") || fd.ident == Identifier.idPool("isSameLength") || fd.ident == Identifier.idPool("wrapperParameters") || fd.ident == Identifier.idPool("wrap") || fd.ident == Identifier.idPool("args"))
		{
			IGaveUp = true;
			return ;
		}

I am working on reducing test-cases to figure out why this is failing.
The code is burried in templates makeing it hard to see what is going on.

Still passing the tests is passing the tests :)

On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch wrote:
> I am now passing phobos unittests!

I can't wait to see this in action!

Keep on going and I'll keep praying... 😊

On Wednesday, 2 November 2016 at 23:48:46 UTC, Nordlöw wrote:
> On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch wrote:
>> I am now passing phobos unittests!
>
> I can't wait to see this in action!
>
> Keep on going and I'll keep praying... 😊

No need for prayer.

I am trying my best to be doing solid engineering work.

Neither god nor the devil will paly any role.

I am currently working on making the DMD-AST-facing side of the code more solid.

With a bit of luck I can role out a preview release soon.

But I will only do so when there are no known bugs left.

On Thursday, 3 November 2016 at 00:02:46 UTC, Stefan Koch wrote:
> No need for prayer.
>
> I am trying my best to be doing solid engineering work.
>
> Neither god nor the devil will paly any role.

Got it.

On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
> I intend to keep the current implemntation around as a fallback.
> For things that are used rarely.
> like floating point and others :)

Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing...

On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote:
> On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
>> I intend to keep the current implemntation around as a fallback.
>> For things that are used rarely.
>> like floating point and others :)
>
> Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing...

Passing the whole test-suite is as good as it gets.

On Thu, 03 Nov 2016 15:44:20 +0000, Marc Schütz wrote:

> On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
>> I intend to keep the current implemntation around as a fallback.
>> For things that are used rarely.
>> like floating point and others :)
> 
> Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing...

I think the intent is that the current implementation will always be used for specific features, not that the compiler will attempt to run CTFE with the bytecode version and resort to the previous implementation if something goes wrong.

On Thursday, 3 November 2016 at 16:35:08 UTC, Stefan Koch wrote:
> On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote:
>> On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
>>> I intend to keep the current implemntation around as a fallback.
>>> For things that are used rarely.
>>> like floating point and others :)
>>
>> Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing...
>
> Passing the whole test-suite is as good as it gets.

But for operations that your new engine supports, the test-suite will not normally test the old engine, right? Except in certain edge cases where that the new engine happens not to support, so it falls back to the old one. But these edge cases are probably not well-defined and hard to test exhaustively...

On Friday, 4 November 2016 at 01:19:36 UTC, Chris Wright wrote:
> On Thu, 03 Nov 2016 15:44:20 +0000, Marc Schütz wrote:
>
>> On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
>>> I intend to keep the current implemntation around as a fallback.
>>> For things that are used rarely.
>>> like floating point and others :)
>> 
>> Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing...
>
> I think the intent is that the current implementation will always be used for specific features, not that the compiler will attempt to run CTFE with the bytecode version and resort to the previous implementation if something goes wrong.

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.

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.

If you ask me the old interpreter is already an unmaintainble mess.
It will not be possible to remove code since the old interpreter and the new one do not share any common state or code-paths.
Therefore all evaluation-capabilty the old interpreter has must be retained otherwise it would not be useful anymore.

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.

I recently lost 3 days of work because of my git-skills.
Now I am working on simplyfing the cases the interpreter can get into.
Before I would do some optimisation to avoid temporaries and the like.
Since I now have the llvm-backend to verify the code is correct it's no longer crucial in order to be able to debug.
This simplification will (hopefully) finally enable me to proper handling of boolean-expressions.
I suspect that most of the invalid code I generated came from a bug in the "temporaries-avoidance optimisation"

Also I will put some effort into documenting the new engine better.
However code-gen bugs take priority over documentation.