May 03, 2017
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
> On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
>> So you're going to reinvent TCP in your debugging protocol?
>
>
> No. there is no need for a full blown recovery mechanism.
>
> For the typical usecase a lossless orderd connection can be assumed.
>
> And most things are not order dependent

The debugger isn't a massive, real-time system that needs to service thousands of clients and squeeze as much performance out of the network as possible. The overhead incurred by TCP is essentially not worth considering for something that's going to be run over localhost 90%, and service just the one client.

Reinventing the wheel adds a far bigger overhead: Maintaining your new protocol.
TCP implementations are readily available. They're well maintained, well documented, and are essentially guaranteed to work across platforms.
Implementing a new protocol just adds an extra point of breakage for little to no gain. It also incurs the cost of the associated development time, and - down the line - any time spent fixing or iterating. Not to mention that tests need to be written, documentation needs to be put in place.

A classic case of premature optimization.
May 03, 2017
On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote:
> On Sun, Apr 30, 2017 at 01:26:09PM +0000, Stefan Koch via Digitalmars-d wrote:
>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> > [ ... ]
>> 
>> Big news!
>> The first step to include debug info has been done.
>> 
>> Yes this means you will be able to step through ctfe code while the compiler executes it.
>
> Wow! Will that be accessible to users in the end?  That could be a totally awesome way of debugging CTFE code!

I used to think the same, but with each new line of code I write that is to be executed in CT, I become more convinced that there's no need to expose such debugging interface to the end user. Why? Because the end user expects that CTFE either gives exactly the same results as run-time execution or that it stops with an explicit error message on something that is not designed to be executed in CT.  Any other problem found during CTFE execution must be 100% reproducible in run time or it's an ICE.
Any CTFE debugging should be only for compiler maintainers, and the user shouldn't worry that CTFE could mess up something.

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

Thanks to Daniel Murphy's input; '&&' works now in my experimental version.
I hope to get it to pass the auto-tester soon!

This is a big step :)

Thanks Daniel.


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

Hi Guys,

Outer function arguments are now supperted.

meaning this code will now work:

int[] filterBy(int[] arr , bool function(uint) fn)
{
    int[] result = [];
    uint resultLength;

    result.length = arr.length;
    foreach(i;0 .. arr.length)
    {
        auto e = arr[i];
        bool r = true;
        r = fn(e);
        if(r)
        {
            result[resultLength++] = e;
        }
    }

   int[] filterResult;
   filterResult.length = resultLength;

   foreach(i; 0 .. resultLength)
   {
     filterResult[i] = result[i];
   }

  return filterResult;
}

bool isDiv2(uint e)
{
  bool result;
  result = (e % 2 == 0);
  return result;
}


static assert(filterBy([3,4,5], &isDiv2) == [4]);

before this would behaved very strangely ;)
because isDiv would have been executed instead filterBy.
And since after bytecode compilation there is no type checking anymore the arrayPtr would have been interpreter as an integer.
(which is always 4byte aligend)
that would have caused the isDiv to return 1;
which would have been interpreted as address.
and whatever was there would have been treated as array descriptor.
resulting in mostly the [] return value.

...
anyway.
I am happy this is fixed now.
May 12, 2017
On Friday, 12 May 2017 at 11:21:56 UTC, Stefan Koch wrote:

> ...
> anyway.
> I am happy this is fixed now.

Now I am less happy.
The fallout of this fix causes code in std.ascii to miscompile.
Apperantly we don't make sure our function list is cleared before finalization.
May 16, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

So I have fixed a few cases of outer function evaluation.
Unfortunately this exposed some hard to track down bugs in how expressions are handled.
The JIT and Debugger features are on ice, until those bugs are eliminated.

Sorry about the delay.
May 16, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

So ...
I just encountered more ABI issues; related to slices which are part of structures.
struct R
{
  uint[] s1;
  uint[] s2;
}

like this.

R returnSlices(int[] s1, int[] s2)
{
    return R(s1[], s2[]);
}
static assert(returnSlices([1,2,3], [4,5,6,7]) == R([1,2,3][4.5.6.7])); // works


R returnSlicedSlices(int[] s1, int[] s2)
{
    return R(s1[], s2[1 .. $-1]);
}
static assert(returnSlicedSlices([1,2,3], [4,5,6,7]) == R([1,2,3],[5,6])); // fails
// returns R([1,2,3],null); at the moment

The reason ABI issues.
Where exactly ? No Idea.


May 17, 2017
On Tuesday, 16 May 2017 at 13:44:27 UTC, Stefan Koch wrote:
> [ ... ]
> The reason ABI issues.
> Where exactly ? No Idea.

Not just abi issues ...
There are more fundamental problems where we sometimes forget to allocate space, for locals (of composite types).


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

So I just verified that the following code runs fine with newCTFE.

int[2] aaa2(bool b1, bool b2, bool b3)
{
  int x = 0;
  if (b1 && ++x && b2 && x++ && b3 && x++)
  {
    return [x, 1];
  }
  else
  {
    return [x, 0];
  }
}

static assert(aaa2(1, 0, 1) == [1, 0]);
static assert(aaa2(1, 1, 1) == [3, 1]);
static assert(aaa2(0, 0, 1) == [0, 0]);

May 20, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> ...

|| works also fine now ... on it's own.
As soon as || and && are mixed wired things happen.
I am happy that the combinations I tried do at least expose the issue.
This is one of the things that you can totally overlook if the test-case does not trigger it.

int[2] aaa2(bool b1, bool b2, bool b3, bool b4)
{
  int x = 0;
  if (b1 && ++x && b2 && x++ && b3 && (b4 || x++))
  {
    return [x, 1];
  }
  else
  {
    return [x, 0];
  }
}

static assert(aaa2(1, 0, 1, 0) == [1, 0]);
//static assert(aaa2(1, 1, 1, 0) == [3, 1]); // argh
static assert(aaa2(1, 1, 1, 1) == [2, 1]);
static assert(aaa2(0, 0, 1, 0) == [0, 0]);


int[2] ooo2(bool b1, bool b2, bool b3, bool b4)
{
  int x = 0;
  if (b1 || x++ || b2 || !x++ || b3 || (b4 && x++))
  {
    return [x, 1];
  }
  else
  {
    return [x, 0];
  }
}

static assert(ooo2(1, 0, 1, 0) == [0, 1]);
static assert(ooo2(0, 1, 1, 0) == [1, 1]);
static assert(ooo2(0, 0, 1, 0) == [2, 1]);
static assert(ooo2(0, 0, 0, 0) == [2, 0]);
//static assert(ooo2(0, 0, 0, 1) == [3, 1]); // oh god ...