On 06 Aug 2016 16:30, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> Time for an update.
> (ASCII)-Strings work reasonably well.
>
> I am now working on supporting general Sliceing and Appending. The effort on function calls is also still ongoing.
>
> I added a switch to my version of dmd which allows to toggle the ctfe
engine.
> So now I can compare apples to apples when posting perf data.
>
> A nice weekend to all of you.

Hi Stefan,

Are you saying we can play around with ascii string slicing/appending already?

The gist with the current state of ctfe support seems to have last been changed 21 days ago? Am I reading that right? If so where could I find your current tests, if I wanted to run the tests on my machine.

Cheers,
Rory

On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote:

> Hi Stefan,
>
> Are you saying we can play around with ascii string slicing/appending already?
>
No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations.

> The gist with the current state of ctfe support seems to have last been changed 21 days ago? Am I reading that right? If so where could I find your current tests, if I wanted to run the tests on my machine.

That could be right.
Many features are half-implemented at the moment and will fail in random and exciting ways.
Therefore it is too soon to publish code testing those.

If you want particular features the best way is contacting me.

On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote:
> On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote:
>
>> Hi Stefan,
>>
>> Are you saying we can play around with ascii string slicing/appending already?
>>
> No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations.

Tomorrow this is going to work.

On Saturday, 6 August 2016 at 14:26:00 UTC, Stefan Koch wrote:
> I added a switch to my version of dmd which allows to toggle the ctfe engine.
> So now I can compare apples to apples when posting perf data.

That's indeed very useful, also for testing purposes.

On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote:
> On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote:
>> No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations.
>
> Tomorrow this is going to work.

Hi Stefan,

How much effort will it be to integrate your work into LDC? I'd like to test it on some Weka code.

Definitely let us know once you can CTFE something like std.traits.ParameterStorageClassTuple.

cheers,
  Johan

On Monday, 8 August 2016 at 09:51:03 UTC, Johan Engelen wrote:
> On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote:
>> On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote:
>>> No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations.
>>
>> Tomorrow this is going to work.
>
> Hi Stefan,
>
> How much effort will it be to integrate your work into LDC? I'd like to test it on some Weka code.
>
> Definitely let us know once you can CTFE something like std.traits.ParameterStorageClassTuple.
>
> cheers,
>   Johan

Hi Johan,

It won't be too much effort. Since it was designed with that in mind.

1. You said CTFE engine can be ctfeable itself? But it uses unions in BCValue - it's not going to work in CTFE, is it? Just wondering myself what's the way to have polymorphism at compile time.
2. The byte code generator interface has no mean to declare functions? In case of LLVM jit one would want to declare functions so that jit can use registers to pass parameters for a bit more extra speed, though it's probably not worth it.

On Tuesday, 9 August 2016 at 12:30:18 UTC, Kagamin wrote:
> 1. You said CTFE engine can be ctfeable itself? But it uses unions in BCValue - it's not going to work in CTFE, is it? Just wondering myself what's the way to have polymorphism at compile time.
> 2. The byte code generator interface has no mean to declare functions? In case of LLVM jit one would want to declare functions so that jit can use registers to pass parameters for a bit more extra speed, though it's probably not worth it.

1. unions work fine when you use them as discriminated unions.
2. The BCGen does not have to declare functions. Since every-time it is created it will implicitly define a function.
It will all make more sense once the function-call system works.

I have just committed the changes necessary for (ascii) string indexing and (ascii) string-foreach.

Currently working on UTF8 => UTF32 auto-re-encoding and StringConcat and Slice-Support.

Completion of Slice support will also fix the interplay between structs and arrays.

Cheers,
Stefan

Hi,

I took a break from work on string operations and focused instead of improving the robustness of the engine.
I.E. for it not to halt the compiler on unsupported expressions.

right now,
I can compile druntime without failures.
Phobos should be working by the end of next week.

Have a nice Sunday,

Stefan

PS. String foreach regressed.
And Struct-handling regressed.
Due to a change of memory-layout.

I will fix this as soon as the engine does no longer abort.