On Sunday, 6 November 2016 at 15:31:24 UTC, Stefan Koch wrote:
>
> 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)

I just have just implemented the ability to error out.
And I am still not passing interpret3.d.
That is one hard unit-test.

Currently I pass around 25% of interpret3.d.

On Sunday, 6 November 2016 at 22:07:05 UTC, Stefan Koch wrote:
> On Sunday, 6 November 2016 at 15:31:24 UTC, Stefan Koch wrote:
>>
>> 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)
>
> I just have just implemented the ability to error out.
> And I am still not passing interpret3.d.
> That is one hard unit-test.
>
> Currently I pass around 25% of interpret3.d.

I consider the engine ready to be merged into the feature branch.
There are still a few obscure failures.
But nothing preventing an alpha release.

On Monday, 7 November 2016 at 10:02:37 UTC, Stefan Koch wrote:
> On Sunday, 6 November 2016 at 22:07:05 UTC, Stefan Koch wrote:
>> On Sunday, 6 November 2016 at 15:31:24 UTC, Stefan Koch wrote:
>>>
>>> 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)
>>
>> I just have just implemented the ability to error out.
>> And I am still not passing interpret3.d.
>> That is one hard unit-test.
>>
>> Currently I pass around 25% of interpret3.d.
>
> I consider the engine ready to be merged into the feature branch.
> There are still a few obscure failures.
> But nothing preventing an alpha release.

Update I tracked down a bug that prevented a function from std.allocator to execute correctly.

Slowly but steadily new ctfe becomes more robust.

On Monday, 7 November 2016 at 14:13:04 UTC, Stefan Koch wrote:
> On Monday, 7 November 2016 at 10:02:37 UTC, Stefan Koch wrote:
>> On Sunday, 6 November 2016 at 22:07:05 UTC, Stefan Koch wrote:
>>> On Sunday, 6 November 2016 at 15:31:24 UTC, Stefan Koch wrote:
>>>>
>>>> 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)
>>>
>>> I just have just implemented the ability to error out.
>>> And I am still not passing interpret3.d.
>>> That is one hard unit-test.
>>>
>>> Currently I pass around 25% of interpret3.d.
>>
>> I consider the engine ready to be merged into the feature branch.
>> There are still a few obscure failures.
>> But nothing preventing an alpha release.
>
> Update I tracked down a bug that prevented a function from std.allocator to execute correctly.
>
> Slowly but steadily new ctfe becomes more robust.

Another bug was identified.
There are severe issues with the interpreter back-end and it's 32bit only legacy.
Fixing these issues will degrade performance of the interpreter by roughly 7-15%.

Maybe there is still a way around it, but so far my more performance-oriented approaches  are failing to fix the problems.

Errors now know their location, and most of the time assertions thrown be the new engine are close enough to the old interpreters one.
However my errors have less information in them due to design limitations.
It is possible to lift those but only with significant effort.

Slightly OT.
I feel like I hit every bump in the road to a faster interpreter, and I know there are a a lot more ahead.

Today I spent 3 hours to find a bug which caused a division by zero.
It turned out that 64bit large function arguments where silently skipped.
Causing the interpreter to read zero initialized memory instead of the actual arguments. However I suspected the division code to be at fault and wasted a lot of time of second-guessing correct code.

Having these implementation challenges intermixed with design and performance considerations can be taxing sometimes.

Without my bytecode-unitests which are ctfeable it would be almost impossible to for me to work at the pace I am working.
Simply because I get direct feedback if something goes wrong because the compile will abort after less then a second.

These kinds of things are the true strength of ctfe.
CTFE is the one of the greatest development assets one can have.
Because it transforms the compile-debug-edit cycle into a compile-edit cycle.

On 11/05/2016 11:48 AM, Marc Schütz wrote:
> On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch 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.

Yea, but unless you're a git-fu master, sometimes figuring out how to fix whatever got messed up can lose you 3 days of work ;)

I really want to make a saner CLI front-end for git, but that would require learning more about git than I really ever want to know :(

On 11/05/2016 04:57 PM, Andrei Alexandrescu wrote:
>
> 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 really wish Google would take that to heart. They seem to make a habit of ripping things out *before* having replacements in place.

I think they just simply love deleting code.

On Tue, Nov 08, 2016 at 11:40:31AM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 11/05/2016 11:48 AM, Marc Schütz wrote:
> > On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch 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.
> 
> Yea, but unless you're a git-fu master, sometimes figuring out how to fix whatever got messed up can lose you 3 days of work ;)
> 
> I really want to make a saner CLI front-end for git, but that would require learning more about git than I really ever want to know :(

The thing about git is that at its core, it's really very simple. Dumb, even.  It's basically a program for managing a directed acyclic graph (DAG).  That's all there is to it. The rest is just frills.

Trying to rationalize git in terms of traditional version control systems is what usually causes lots of confusion, incomprehension, and frustration.  To truly grok git, you have to just forget about traditional version control concepts, and think purely in terms of DAGs. Once you do, everything falls into place and it all makes sense in its own peculiar way (including all the flaws :-P).


T

-- 
It only takes one twig to burn down a forest.

On 11/08/2016 11:57 AM, H. S. Teoh via Digitalmars-d wrote:
>
> The thing about git is that at its core, it's really very simple. Dumb,
> even.  It's basically a program for managing a directed acyclic graph
> (DAG).  That's all there is to it. The rest is just frills.
>
> Trying to rationalize git in terms of traditional version control
> systems is what usually causes lots of confusion, incomprehension, and
> frustration.  To truly grok git, you have to just forget about
> traditional version control concepts, and think purely in terms of DAGs.
> Once you do, everything falls into place and it all makes sense in its
> own peculiar way (including all the flaws :-P).
>

I don't suppose you have a handy link to an "Understanding Git as a DAG manager instead of VCS" document?

On Tuesday, 8 November 2016 at 17:12:34 UTC, Nick Sabalausky wrote:
> On 11/08/2016 11:57 AM, H. S. Teoh via Digitalmars-d wrote:
>>[...]
>
> I don't suppose you have a handy link to an "Understanding Git as a DAG manager instead of VCS" document?

Hi Nick,

Maybe this one is useful for you:

http://eagain.net/articles/git-for-computer-scientists/

Antonio

On Tuesday, 8 November 2016 at 16:57:27 UTC, H. S. Teoh wrote:
> On Tue, Nov 08, 2016 at 11:40:31AM -0500, Nick Sabalausky via Digitalmars-d wrote:
>> On 11/05/2016 11:48 AM, Marc Schütz wrote:
>> > On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch 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.
>> 
>> Yea, but unless you're a git-fu master, sometimes figuring out how to fix whatever got messed up can lose you 3 days of work ;)
>> 
>> I really want to make a saner CLI front-end for git, but that would require learning more about git than I really ever want to know :(

If you study carefully the data model of git you will then come to the conclusion that its CLI is not that bad.
>
> The thing about git is that at its core, it's really very simple. Dumb, even.  It's basically a program for managing a directed acyclic graph (DAG).  That's all there is to it. The rest is just frills.
>
> Trying to rationalize git in terms of traditional version control systems is what usually causes lots of confusion, incomprehension, and frustration.  To truly grok git, you have to just forget about traditional version control concepts, and think purely in terms of DAGs. Once you do, everything falls into place and it all makes sense in its own peculiar way (including all the flaws :-P).
>
I describe git not as a vcs but as exacly what Linus Torvalds described it when he first presented it the Kernel mailing list: a directory content state recorder optimized for text files. The DAG is already an abstraction above i.e. a mean to that end.