Watch, discuss, upvote!

https://news.ycombinator.com/newest

https://twitter.com/D_Programming/status/476386465166135296

https://www.facebook.com/dlang.org/posts/863635576983458

http://www.reddit.com/r/programming/comments/27sjxf/dconf_2014_day_1_talk_4_inside_the_regular/


Andrei

On Tuesday, 10 June 2014 at 15:37:11 UTC, Andrei Alexandrescu wrote:
> Watch, discuss, upvote!
>
> https://news.ycombinator.com/newest
>
> https://twitter.com/D_Programming/status/476386465166135296
>
> https://www.facebook.com/dlang.org/posts/863635576983458
>
> http://www.reddit.com/r/programming/comments/27sjxf/dconf_2014_day_1_talk_4_inside_the_regular/
>
>
> Andrei

http://youtu.be/hkaOciiP11c

At about 40.42 in the "Thoughts on static regex" there is written "even compile-time printf would be awesome". There is a patch about __ctWrite in GitHug, it should be fixed and merged.

Bye,
bearophile

On Tuesday, 10 June 2014 at 19:36:57 UTC, bearophile wrote:
> At about 40.42 in the "Thoughts on static regex" there is written "even compile-time printf would be awesome". There is a patch about __ctWrite in GitHug, it should be fixed and merged.
>
> Bye,
> bearophile

I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe said what I was thinking of saying: unit test and debug the CTFE function at runtime and then use it at compile-time when it's ready for production.

Yes, Dmitry brought up compiler bugs. But if you write a compile-time UT and it fails, you'll know it wasn't because of your own code because the run-time ones still pass.

Maybe there's still a place for something more than pragma msg, but I'd definitely advocate for the above at least in the beginning. If anything, easier ways to write compile-time UTs would be, to me, preferable to a compile-time printf.

Atila

On Wednesday, 11 June 2014 at 18:03:06 UTC, Atila Neves wrote:
> I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe said what I was thinking of saying: unit test and debug the CTFE function at runtime and then use it at compile-time when it's ready for production.

Aye. It wasn't long ago that this wasn't really possible because of how incomplete and buggy CTFE was, you kinda had to do it with special code, but now so much of the language works, there's a good chance if it works at runtime it will work at compile time too.

I was really surprised with CTFE a few months ago when I tried to use my dom.d with it... and it actually worked. That's amazing to me.

But anyway, in general, the ctfe mixin stuff could be replaced with an external code generator, so yeah that's the way I write them now - as a code generator standalone thing then go back and enum it to actually use. (BTW I also like to generate fairly pretty code, e.g. indentend properly, just because it makes it easier to read.)

> Yes, Dmitry brought up compiler bugs. But if you write a compile-time UT and it fails, you'll know it wasn't because of your own code because the run-time ones still pass.

Yeah, good point too.

11-Jun-2014 22:03, Atila Neves пишет:
> On Tuesday, 10 June 2014 at 19:36:57 UTC, bearophile wrote:
>> At about 40.42 in the "Thoughts on static regex" there is written
>> "even compile-time printf would be awesome". There is a patch about
>> __ctWrite in GitHug, it should be fixed and merged.
>>
>> Bye,
>> bearophile
>
> I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe said
> what I was thinking of saying: unit test and debug the CTFE function at
> runtime and then use it at compile-time when it's ready for production.
>

Yes, that's a starting point - a function working at R-T.

> Yes, Dmitry brought up compiler bugs. But if you write a compile-time UT
> and it fails, you'll know it wasn't because of your own code because the
> run-time ones still pass.

It doesn't help that it's not your fault :)
And with a bit of __ctfe's to workaround compiler bugs you won't be so sure of your code anymore.

>
> Maybe there's still a place for something more than pragma msg, but I'd
> definitely advocate for the above at least in the beginning. If
> anything, easier ways to write compile-time UTs would be, to me,
> preferable to a compile-time printf.
>

There is nice assertCTFEable written by Kenji in Phobos. I think it's our private magic for now but I see no reason not to expose it somewhere.

> Atila


-- 
Dmitry Olshansky

12-Jun-2014 03:29, Adam D. Ruppe пишет:
> On Wednesday, 11 June 2014 at 18:03:06 UTC, Atila Neves wrote:
>> I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe
>> said what I was thinking of saying: unit test and debug the CTFE
>> function at runtime and then use it at compile-time when it's ready
>> for production.
>
> Aye. It wasn't long ago that this wasn't really possible because of how
> incomplete and buggy CTFE was, you kinda had to do it with special code,
> but now so much of the language works, there's a good chance if it works
> at runtime it will work at compile time too.
>
> I was really surprised with CTFE a few months ago when I tried to use my
> dom.d with it... and it actually worked. That's amazing to me.
>
> But anyway, in general, the ctfe mixin stuff could be replaced with an
> external code generator, so yeah that's the way I write them now - as a
> code generator standalone thing then go back and enum it to actually
> use. (BTW I also like to generate fairly pretty code, e.g. indentend
> properly, just because it makes it easier to read.)
>

This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in _practical_ context (DSL that is quite stable, not just tiny helpers)?

By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) vs having to wait for a couple of minutes each build hoping the compiler won't hit your system's memory limits.

And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke.

And speaking of seamless integration: just generate a symbol name out of pattern at CTFE to link to later, at least this much can be done relatively fast. And voila even the clunky run-time generation is not half-bad at integration.

Unless things improve dramatically CTFE code generation + mixin is just our funny painful toy.

-- 
Dmitry Olshansky

Dmitry Olshansky:

> Unless things improve dramatically CTFE code generation +

An alternative and much faster JITter for LLVM, something like this could make CTFE on LDC2 very quick:
http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/fast-jit-code-generation.pdf

Bye,
bearophile

On Thursday, 12 June 2014 at 09:17:45 UTC, Dmitry Olshansky wrote:
> 12-Jun-2014 03:29, Adam D. Ruppe пишет:
>> On Wednesday, 11 June 2014 at 18:03:06 UTC, Atila Neves wrote:
>>> I wish I'd taken the mic at the end, and 2 days later Adam D. Ruppe
>>> said what I was thinking of saying: unit test and debug the CTFE
>>> function at runtime and then use it at compile-time when it's ready
>>> for production.
>>
>> Aye. It wasn't long ago that this wasn't really possible because of how
>> incomplete and buggy CTFE was, you kinda had to do it with special code,
>> but now so much of the language works, there's a good chance if it works
>> at runtime it will work at compile time too.
>>
>> I was really surprised with CTFE a few months ago when I tried to use my
>> dom.d with it... and it actually worked. That's amazing to me.
>>
>> But anyway, in general, the ctfe mixin stuff could be replaced with an
>> external code generator, so yeah that's the way I write them now - as a
>> code generator standalone thing then go back and enum it to actually
>> use. (BTW I also like to generate fairly pretty code, e.g. indentend
>> properly, just because it makes it easier to read.)
>>
>
> And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke.


Maybe a change to the compiler to write any mixin'd string out to a temporary file (along with some identifier information and the line of code that generated it) and at the next compilation time try reading it back from that file iff the line of code that generated it hasnt changed?

Then, there'd be no heavy work for the compiler to do, apart from read that file in to a string.

Am 12.06.2014 11:17, schrieb Dmitry Olshansky:
> This one thing I'm loosing sleep over - what precisely is so good in
> CTFE code generation in_practical_  context (DSL that is quite stable,
> not just tiny helpers)?
>
> By the end of day it's just about having to write a trivial line in your
> favorite build system (NOT make) vs having to wait for a couple of
> minutes each build hoping the compiler won't hit your system's memory
> limits.
>
> And these couple of minutes are more like 30 minutes at a times. Worse
> yet unlike proper build system it doesn't keep track of actual changes
> (same regex patterns get recompiled over and over), at this point
> seamless integration into the language starts felling like a joke.
>
> And speaking of seamless integration: just generate a symbol name out of
> pattern at CTFE to link to later, at least this much can be done
> relatively fast. And voila even the clunky run-time generation is not
> half-bad at integration.
>
> Unless things improve dramatically CTFE code generation + mixin is just
> our funny painful toy.

you should write a big top post about your CTFE experience/problems - it is important enough