Thread overview | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 10, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
June 10, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
June 11, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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
|
June 11, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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. |
June 12, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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 |
June 12, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 |
June 12, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
June 12, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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.
|
June 12, 2014 Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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
|
Copyright © 1999-2021 by the D Language Foundation