June 20, 2017
On Tuesday, 20 June 2017 at 19:37:47 UTC, David Nadlinger wrote:
>
> But how much of the std.math code are you actually executing with newCTFE? What I meant is that if the std.math{,special} implementations of the various mathematical functions work, there shouldn't be any egregious issues. I'm not sure how much of it is usually run during CTFE, though.
>
>  — David

I just checked.
I execute exactly 0% of it.
It mostly bails out on || and &&.

June 21, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I just figured out howto fix the defaultArg situation.
We just have to check at or slightly before we emit the Call instruction,
if we have enough arguments for the function.
If we don't we pull the missing ones from the default arguments.
This does have the problem that we can generate the same default once per call.
However we would have the same problem if a user typed the default argument manually.

Therefore I argue we should emit the code rather then demanding something clever from the backends.

Clever is usually the opposite of smart :) (In those kinds of things)
June 26, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I finally came around and implemented 64bit as a hacky extension to the interpreter.

ulong[5] testArrayAssignL()
{
    typeof(return) arr = 12;
    arr[3] = 4;
    arr[0] = 1;
    return arr;
}

static immutable arrL = testArrayAssignL();
pragma(msg, arrL); // outputs: [1LU, 12LU, 12LU, 4LU, 12LU]

This should naturally extend to arrays of floats or doubles as well.

June 28, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hi There,

I just wrote the first parts of the ctfe debugger.
Ctfe-Breakpoints are working :)

It looks like we will be able to have greatly enhanced debugging experience soon.
(okay soonish ... since there are still a few tricky details to work out.)
June 28, 2017
On Wed, Jun 28, 2017 at 04:19:02PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> Hi There,
> 
> I just wrote the first parts of the ctfe debugger. Ctfe-Breakpoints are working :)
> 
> It looks like we will be able to have greatly enhanced debugging
> experience soon.
> (okay soonish ... since there are still a few tricky details to work out.)

Awesome!


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.
June 29, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I just "discovered" a bug in my debugging system.
Which caused me to debug the wrong function for about 5 hours.
Since I really could not see why the codegen would produce such vastly different code.
(Almost as if it were generating code for a different function :/ )

The takeaway: Better Debuggers only safe you time if they are actually showing you correct information.

If your debugger is buggy then your are in a world of hurts.
I had my share of pain for today.

The good thing is however, that the floating point stuff is going smooth so far.
The x87 can be persuaded to almost obey the ieee standard if you issue a write after every operation.

The better option would be to just use sse2 all the way. But whatever.


June 29, 2017
On 6/29/17 4:24 AM, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
> 
> I just "discovered" a bug in my debugging system.
> Which caused me to debug the wrong function for about 5 hours.
> Since I really could not see why the codegen would produce such vastly different code.
> (Almost as if it were generating code for a different function :/ )
> 
> The takeaway: Better Debuggers only safe you time if they are actually showing you correct information.
> 
> If your debugger is buggy then your are in a world of hurts.
> I had my share of pain for today.

The same is true for compilers that are buggy. Debugging code is horrible when the compiled code isn't doing what the source says. I've seen my share of that as well...

> The good thing is however, that the floating point stuff is going smooth so far.
> The x87 can be persuaded to almost obey the ieee standard if you issue a write after every operation.
> 
> The better option would be to just use sse2 all the way. But whatever.

I'm looking very much forward to newCTFE. Keep up the good work!

-Steve
July 02, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I ran in trouble with floating point.
This will probably take a week.
The debugger will take probably a month (without gui).

July 03, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hi Guys,

I am very pleased indeed about the following code now running in ctfe.

int maxFloat()
{
  float prev = 0;
  float fOne = 1;
  foreach(int i; 1 .. int.max)
  {
    if (i == prev)
      return i-1;
    else
      prev += fOne;
  }
  return int.max;
}

static assert(maxFloat() == 16777216);

July 03, 2017
On Monday, 3 July 2017 at 06:15:44 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

This code works now as well ;)

int maxFloat()
{
  float prev = 1;
  foreach(int i; 0 .. int.max)
  {
    if (i == prev++)
      return i;
  }
  return int.max;
}

static assert(maxFloat() == 16777216);