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

Hi Guys, I just implemented sliceAssigment.

meaning the following code will now compile:

uint[] assignSlice(uint from, uint to, uint[] stuff)
{
    uint[] slice;
    slice.length = to + 4;
    foreach (uint i; 0 .. to + 4)
    {
        slice[i] = i + 1;
    }

    slice[from .. to] = stuff;
    return slice;
}

static assert(assignSlice(1, 4, [9, 8, 7]) == [1, 9, 8, 7, 5, 6, 7, 8]);
April 28, 2017
On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Hi Guys, I just implemented sliceAssigment.
>
> meaning the following code will now compile:
>
> uint[] assignSlice(uint from, uint to, uint[] stuff)
> {
>     uint[] slice;
>     slice.length = to + 4;
>     foreach (uint i; 0 .. to + 4)
>     {
>         slice[i] = i + 1;
>     }
>
>     slice[from .. to] = stuff;
>     return slice;
> }
>
> static assert(assignSlice(1, 4, [9, 8, 7]) == [1, 9, 8, 7, 5, 6, 7, 8]);

as always ... I spoke too soon :(
while running test I forgot to specify -bc-ctfe ...

Although I use the same code for slicing ... it seems it misbehaves in the usecase.

April 29, 2017
On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> After a little of exploration of the JIT, I have now determined that a simple risc architecture is still the best.
> (codegen for scaled loads is hard :p)
>
> I am now back to fixing non-compiling code,
> such as :
>
> struct S
> {
>     uint[] slice;
> }
>
> uint fn()
> {
>   S s;
>   s.slice.length = 12;
>   return cast(uint)s.slice.length;
> }
>
> static assert(fn() == 12);
>
> This simple test does not compile because;
> ahm well ...
> Somewhere along the road we loose the type of s.slice and we cannot tell where to get .length from.

I fixed this just now!
ABI's are hard :)
April 29, 2017
On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Hi Guys, I just implemented sliceAssigment.
>
> meaning the following code will now compile:
>
> uint[] assignSlice(uint from, uint to, uint[] stuff)
> {
>     uint[] slice;
>     slice.length = to + 4;
>     foreach (uint i; 0 .. to + 4)
>     {
>         slice[i] = i + 1;
>     }
>
>     slice[from .. to] = stuff;
>     return slice;
> }
>
> static assert(assignSlice(1, 4, [9, 8, 7]) == [1, 9, 8, 7, 5, 6, 7, 8]);

FIXED!
April 30, 2017
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.
April 30, 2017
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!


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan
May 01, 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!
>
>
> T

Yes the plan is to make it accessible for the advanced user.
probably with a really bad ui, though (since I am awful at UI code).
May 01, 2017
On Mon, May 01, 2017 at 06:23:08PM +0000, Stefan Koch via Digitalmars-d wrote:
> 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!
> > 
> > 
> > T
> 
> Yes the plan is to make it accessible for the advanced user.  probably with a really bad ui, though (since I am awful at UI code).

I'm not sure about providing a debugger UI inside the compiler itself... it's certainly possible, and could lead to interesting new ways of using a compiler, but I was thinking more along the lines of providing the necessary hooks so that you could attach an external debugger to the CTFE engine.

But if the debugger UI is simple enough, perhaps having it built into the compiler may not be a bad thing. It would also avoid potential trouble caused by some platforms not having debuggers capable of plugging into the compiler in that way.  But still, I can see people demanding IDE integration for this eventually... :-O


T

-- 
Obviously, some things aren't very obvious.
May 02, 2017
On Monday, 1 May 2017 at 19:06:24 UTC, H. S. Teoh wrote:
> On Mon, May 01, 2017 at 06:23:08PM +0000, Stefan Koch via Digitalmars-d wrote:
>> [...]
>
> I'm not sure about providing a debugger UI inside the compiler itself... it's certainly possible, and could lead to interesting new ways of using a compiler, but I was thinking more along the lines of providing the necessary hooks so that you could attach an external debugger to the CTFE engine.
>
> But if the debugger UI is simple enough, perhaps having it built into the compiler may not be a bad thing. It would also avoid potential trouble caused by some platforms not having debuggers capable of plugging into the compiler in that way.  But still, I can see people demanding IDE integration for this eventually... :-O
>
>
> T

I intended for the debugging functionality to be exposed via a udp socket listening on localhost.
Such that a debug-ui does not have to deal with ipc difficulties.
I am strictly against building a debugger into dmd.
May 02, 2017
On Tue, May 02, 2017 at 09:55:56AM +0000, Stefan Koch via Digitalmars-d wrote: [...]
> I intended for the debugging functionality to be exposed via a udp
> socket listening on localhost.
> Such that a debug-ui does not have to deal with ipc difficulties.
> I am strictly against building a debugger into dmd.

Nice, that's a good approach.


T

-- 
Bomb technician: If I'm running, try to keep up.