On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
> Go ahead.
> Many features should already be working correctly.

This https://github.com/UplinkCoder/dmd/commits/newCTFE I presume?

On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
> Go ahead.
> Many features should already be working correctly.
>
> The missing important ones are slices and concat.

Ok, great.

I was thinking about benchmarking parser generators such as Pegged.

Is there another way of concatenating strings than with the builtin ~ operator?

On Tuesday, 6 December 2016 at 22:44:34 UTC, Nordlöw wrote:
> On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
>> Go ahead.
>> Many features should already be working correctly.
>>
>> The missing important ones are slices and concat.
>
> Ok, great.
>
> I was thinking about benchmarking parser generators such as Pegged.
>
> Is there another way of concatenating strings than with the builtin ~ operator?

Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the length of string a.

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
> On Tuesday, 6 December 2016 at 22:44:34 UTC, Nordlöw wrote:
>> On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
>>> Go ahead.
>>> Many features should already be working correctly.
>>>
>>> The missing important ones are slices and concat.
>>
>> Ok, great.
>>
>> I was thinking about benchmarking parser generators such as Pegged.
>>
>> Is there another way of concatenating strings than with the builtin ~ operator?
>
> Yes there is.
> Create a char[] give it the length of string a + string b;
> copy string a into the char[]
> then copy string b into the resulting array.
> offsetting it by the length of string a.

But keep in mind function calls are unsupported right now.
Meaning you have to put everything in one function.
However function calls should be working some time soon.
I am still in the middle of restructuring how blocks or handled, because right now I will miscompile for-loops with continues in them.

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
> Yes there is.
> Create a char[] give it the length of string a + string b;
> copy string a into the char[]
> then copy string b into the resulting array.
> offsetting it by the length of string a.

Sounds like you have your concat implementation right there ;)

On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
> Yes there is...

Thanks.

On Tuesday, 6 December 2016 at 23:55:06 UTC, Nordlöw wrote:
> On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
>> Yes there is.
>> Create a char[] give it the length of string a + string b;
>> copy string a into the char[]
>> then copy string b into the resulting array.
>> offsetting it by the length of string a.
>
> Sounds like you have your concat implementation right there ;)

not really, concat needs to be smart about allocation and memory reuse.
when used on char arrays the memory access will be different.
and use more instructions.

On Saturday, 3 December 2016 at 18:00:10 UTC, Stefan Koch wrote:
> classes (unlikely to be added in the near future)
> floating point math (unlikely to be added in the near future)

What's the problem with classes and floating point math?

Andrea

On Wednesday, 7 December 2016 at 08:33:22 UTC, Andrea Fontana wrote:
> On Saturday, 3 December 2016 at 18:00:10 UTC, Stefan Koch wrote:
>> classes (unlikely to be added in the near future)
>> floating point math (unlikely to be added in the near future)
>
> What's the problem with classes and floating point math?
>
> Andrea

Honestly the main problem is that I am not familiar with FloatingPoint-Math.
Therefore I would may not even notice when I introduce a subtle bug.

Classes build on top of a functioning memory-management and require a mechanism for indirect calls or function pointers.
Both are currently not implemented.

I will worry about classes when the rest of the engine runs cleanly.

I have an update about ctfe performance.
I wondered for quite a while why newCTFE had a 5 millisecond overhead, when compared the old interpreter.
Since on my charts it had comparable or better stats.
I finally figured it out.

Because the interpreter is supposed to be ctfe-able itself it uses a gc-allocated stack.
And that in turn call envokes the gc.
The mark phase of the garbage-collector matches up exactly with the extra time taken.

I have no idea, why this happens though since the GC is supposed to be disabled.