CTFE execute will be very useful on web develop, for example It is very hard to create a CTFE version template engine with rich feature. But we can use execute call to transe template file to d code string, then mixed it to application.

The vibed project is very cool and I want to add my Jade template to this, but I can't find other way to do it.

Maybe we also need a compiler option to enable this CTFE io operate because security.

On Saturday, 26 May 2012 at 15:56:38 UTC, Chang Long wrote:
> CTFE execute will be very useful on web develop, for example It is very hard to create a CTFE version template engine with rich feature. But we can use execute call to transe template file to d code string, then mixed it to application.
>
> The vibed project is very cool and I want to add my Jade template to this, but I can't find other way to do it.
>
> Maybe we also need a compiler option to enable this CTFE io operate because security.

Let me make myself more clear, what I suggestion is something like this:

mixin(  std.process.execute("/usr/bin/template_engine template_file_path.htm") );

On 28/05/12 03:40, Chang Long wrote:
> On Saturday, 26 May 2012 at 15:56:38 UTC, Chang Long wrote:
>> CTFE execute will be very useful on web develop, for example It is
>> very hard to create a CTFE version template engine with rich feature.
>> But we can use execute call to transe template file to d code string,
>> then mixed it to application.
>>
>> The vibed project is very cool and I want to add my Jade template to
>> this, but I can't find other way to do it.

You can do a lot with import(filename);

>>
>> Maybe we also need a compiler option to enable this CTFE io operate
>> because security.
>
> Let me make myself more clear, what I suggestion is something like this:
>
> mixin( std.process.execute("/usr/bin/template_engine
> template_file_path.htm") );

Yeah, but it requires re-implementing all those tools. If you already have them implemented in D, then it's not a problem, but if you don't or they are closed-source, then import(filename) won't do much good.

On Tue, May 29, 2012 at 1:46 PM, Don Clugston <dac@nospam.com> wrote:

> On 28/05/12 03:40, Chang Long wrote:
>
>> On Saturday, 26 May 2012 at 15:56:38 UTC, Chang Long wrote:
>>
>>> CTFE execute will be very useful on web develop, for example It is very hard to create a CTFE version template engine with rich feature. But we can use execute call to transe template file to d code string, then mixed it to application.
>>>
>>> The vibed project is very cool and I want to add my Jade template to this, but I can't find other way to do it.
>>>
>>
> You can do a lot with import(filename);
>
>
>
>>> Maybe we also need a compiler option to enable this CTFE io operate because security.
>>>
>>
>> Let me make myself more clear, what I suggestion is something like this:
>>
>> mixin( std.process.execute("/usr/bin/**template_engine
>> template_file_path.htm") );
>>
>
>
>


-- 
Bye,
Gor Gyolchanyan.

On Tuesday, 29 May 2012 at 10:08:51 UTC, Gor Gyolchanyan wrote:
> Yeah, but it requires re-implementing all those tools. If you already have
> them implemented in D, then it's not a problem, but if you don't or they
> are closed-source, then import(filename) won't do much good.
>

You just need a two step build process.

On Tue, May 29, 2012 at 2:53 PM, Tobias Pankrath <tobias@pankrath.net>wrote:

> On Tuesday, 29 May 2012 at 10:08:51 UTC, Gor Gyolchanyan wrote:
>
>> Yeah, but it requires re-implementing all those tools. If you already have them implemented in D, then it's not a problem, but if you don't or they are closed-source, then import(filename) won't do much good.
>>
>>
> You just need a two step build process.
>
>
>
Two-step build process is complicated and tedious. The point here is to avoid senseless complications.

-- 
Bye,
Gor Gyolchanyan.

On Tuesday, 29 May 2012 at 11:51:34 UTC, Gor Gyolchanyan wrote:
> On Tue, May 29, 2012 at 2:53 PM, Tobias Pankrath <tobias@pankrath.net>wrote:
>
>> On Tuesday, 29 May 2012 at 10:08:51 UTC, Gor Gyolchanyan wrote:
>>
>>> Yeah, but it requires re-implementing all those tools. If you already have
>>> them implemented in D, then it's not a problem, but if you don't or they
>>> are closed-source, then import(filename) won't do much good.
>>>
>>>
>> You just need a two step build process.
>>
>>
>>
> Two-step build process is complicated and tedious. The point here is to
> avoid senseless complications.

If you rely on third party tools for code gen, it will be complicated either way.

Going this path means that you have to turn the compiler into a full build system. That finds the right tools in the path, gives good error messages if they are absent, that caches results etc.

On Tue, May 29, 2012 at 4:02 PM, Tobias Pankrath <tobias@pankrath.net>wrote:


> Going this path means that you have to turn the compiler into a full build system. That finds the right tools in the path, gives good error messages if they are absent, that caches results etc.
>
>
... which is precisely what we need to reduce all problems related to the build process to zero. This would solve a heap of problems.

-- 
Bye,
Gor Gyolchanyan.

On Tuesday, 29 May 2012 at 16:32:17 UTC, Gor Gyolchanyan wrote:
> On Tue, May 29, 2012 at 4:02 PM, Tobias Pankrath <tobias@pankrath.net>wrote:
>
>
>> Going this path means that you have to turn the compiler into a full build
>> system. That finds the right tools in the path, gives good error messages
>> if they are absent, that caches results etc.
>>
>>
> ... which is precisely what we need to reduce all problems related to the
> build process to zero. This would solve a heap of problems.

If we do that, we should carefully design the system. If we introduce the possiblity to execute arbitrary commands at compile time, we've just introduced
the next generation preprocessor.

On Tue, May 29, 2012 at 9:47 PM, Tobias Pankrath <tobias@pankrath.net>wrote:

> On Tuesday, 29 May 2012 at 16:32:17 UTC, Gor Gyolchanyan wrote:
>
>> On Tue, May 29, 2012 at 4:02 PM, Tobias Pankrath <tobias@pankrath.net
>> >wrote:
>>
>>
>>
>>  Going this path means that you have to turn the compiler into a full
>>> build
>>> system. That finds the right tools in the path, gives good error messages
>>> if they are absent, that caches results etc.
>>>
>>>
>>>  ... which is precisely what we need to reduce all problems related to
>> the
>> build process to zero. This would solve a heap of problems.
>>
>
> If we do that, we should carefully design the system. If we introduce the
> possiblity to execute arbitrary commands at compile time, we've just
> introduced
> the next generation preprocessor.
>

In any case being able to call external build systems is an important part of any build system.

-- 
Bye,
Gor Gyolchanyan.