Jump to page: 1 24  
Page
Thread overview
Writing/Creating files at compile-time
Aug 09, 2015
JDemler
Aug 09, 2015
cym13
Aug 09, 2015
Rikki Cattermole
Aug 09, 2015
jmh530
Aug 09, 2015
Rikki Cattermole
Aug 09, 2015
jmh530
Aug 09, 2015
JDemler
Aug 09, 2015
Etienne
Aug 10, 2015
Rikki Cattermole
Aug 09, 2015
JDemler
Aug 10, 2015
ketmar
Aug 10, 2015
Tofu Ninja
Aug 10, 2015
Rikki Cattermole
Aug 10, 2015
ketmar
Aug 10, 2015
Rikki Cattermole
Aug 10, 2015
Dmitry Olshansky
Aug 10, 2015
Rikki Cattermole
Aug 10, 2015
ketmar
Aug 10, 2015
ChangLong
Aug 10, 2015
Iain Buclaw
Aug 10, 2015
Tofu Ninja
Aug 10, 2015
ketmar
Aug 10, 2015
Iain Buclaw
Aug 10, 2015
lobo
Aug 10, 2015
Iain Buclaw
Aug 10, 2015
ketmar
August 09, 2015
We can read files at compile-time:

  enum file = import(fileName);

But we cannot write to a file or create files at compile time.

Generating code at compile-time and mixing it in is fun but has a few flaws.
It isn't debuggable, the generated code cannot be directly inspected (we have to use pragma(msg, )) and it is not possible to manually tweak it.

If we could generate source files (.d) at compile time and then import them using mixins or something else, these problems can be dealt with.


August 09, 2015
On 8/9/15 5:07 AM, JDemler wrote:
> We can read files at compile-time:
>
>    enum file = import(fileName);
>
> But we cannot write to a file or create files at compile time.
>
> Generating code at compile-time and mixing it in is fun but has a few
> flaws.
> It isn't debuggable, the generated code cannot be directly inspected (we
> have to use pragma(msg, )) and it is not possible to manually tweak it.
>
> If we could generate source files (.d) at compile time and then import
> them using mixins or something else, these problems can be dealt with.

I think this is an interesting pursuit that closes the circle on a number of issues, such as debuggability and compilation speed of mixin code. -- Andrei

August 09, 2015
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
> On 8/9/15 5:07 AM, JDemler wrote:
>> We can read files at compile-time:
>>
>>    enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>> Generating code at compile-time and mixing it in is fun but has a few
>> flaws.
>> It isn't debuggable, the generated code cannot be directly inspected (we
>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>
>> If we could generate source files (.d) at compile time and then import
>> them using mixins or something else, these problems can be dealt with.
>
> I think this is an interesting pursuit that closes the circle on a number of issues, such as debuggability and compilation speed of mixin code. -- Andrei

The moment this is added to D, we will have two complete languages in one: an interpreted one at compile-time and another at runtime.

While I find this interesting, I wonder wether this is  a good idea or not.
August 09, 2015
On 10/08/2015 1:57 a.m., cym13 wrote:
> On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
>> On 8/9/15 5:07 AM, JDemler wrote:
>>> We can read files at compile-time:
>>>
>>>    enum file = import(fileName);
>>>
>>> But we cannot write to a file or create files at compile time.
>>>
>>> Generating code at compile-time and mixing it in is fun but has a few
>>> flaws.
>>> It isn't debuggable, the generated code cannot be directly inspected (we
>>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>>
>>> If we could generate source files (.d) at compile time and then import
>>> them using mixins or something else, these problems can be dealt with.
>>
>> I think this is an interesting pursuit that closes the circle on a
>> number of issues, such as debuggability and compilation speed of mixin
>> code. -- Andrei
>
> The moment this is added to D, we will have two complete languages in
> one: an interpreted one at compile-time and another at runtime.
>
> While I find this interesting, I wonder wether this is  a good idea or not.

I'm actually at the point where I believe the addition of string import was a bad one. No. I prefer preprocessing into a D file first.
It irks me, you have to be pretty careful with them, but at least a preprocessed file you know _exactly_ where all files need to be for CT.
August 09, 2015
On 8/9/15 9:57 AM, cym13 wrote:
> The moment this is added to D, we will have two complete languages in
> one: an interpreted one at compile-time and another at runtime.

Where is the definition of the other one? -- Andrei
August 09, 2015
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
>
> I'm actually at the point where I believe the addition of string import was a bad one. No. I prefer preprocessing into a D file first.
> It irks me, you have to be pretty careful with them, but at least a preprocessed file you know _exactly_ where all files need to be for CT.

Could you provide an example of your point about being careful with D's imports? I'm not sure I've had this problem.

I'm happy to admit I like D's imports, especially compared with C++. Is your ideal alternative something like C's processor or something else?


August 09, 2015
On 10/08/2015 2:38 a.m., jmh530 wrote:
> On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
>>
>> I'm actually at the point where I believe the addition of string
>> import was a bad one. No. I prefer preprocessing into a D file first.
>> It irks me, you have to be pretty careful with them, but at least a
>> preprocessed file you know _exactly_ where all files need to be for CT.
>
> Could you provide an example of your point about being careful with D's
> imports? I'm not sure I've had this problem.

1. The biggest issue is actually a bug. With subdirectories not working on Windows. Yes, bug but a BIG problem.
2. They promote using them all over the place, when in reality with CTFE you shouldn't. You should be very careful when you initiate these sort of things. E.g. Do it in one are of the program so you don't have to grep to find where they are declared.

But alas, most of it is just intuition. I don't think it'll play well if you do anything crazy. But hey I'm the only one that does that sort of thing so no worries there ;)

On that note, when I began working on Developing with compile time in mind[0], string imports didn't exist. So I should really add a bit about that.

> I'm happy to admit I like D's imports, especially compared with C++. Is
> your ideal alternative something like C's processor or something else?

Bin2D[1] is my preferred processor. Note, I'm the author.

Pros:
- Typically these resources are long lived, so files that contain the contents are just as viable
- Can work for any asset files
- Can take in directories and even sub directories
- Can export once program started
- Usable at runtime and compile time

Cons:
- Larger input files ~2-3 larger
- Required to run as a preprocessor over input files


[0] https://leanpub.com/ctfe
[1] https://github.com/rikkimax/Bin2D

August 09, 2015
On Sunday, 9 August 2015 at 14:50:21 UTC, Rikki Cattermole wrote:
>
> Bin2D[1] is my preferred processor. Note, I'm the author.
>

I'll take a look. Thanks.
August 09, 2015
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
> On 8/9/15 5:07 AM, JDemler wrote:
>> We can read files at compile-time:
>>
>>    enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>> Generating code at compile-time and mixing it in is fun but has a few
>> flaws.
>> It isn't debuggable, the generated code cannot be directly inspected (we
>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>
>> If we could generate source files (.d) at compile time and then import
>> them using mixins or something else, these problems can be dealt with.
>
> I think this is an interesting pursuit that closes the circle on a number of issues, such as debuggability and compilation speed of mixin code. -- Andrei

The next step is a DIP on which further discussion is based?
I would be willing to provide one.
August 09, 2015
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
> On 10/08/2015 1:57 a.m., cym13 wrote:
>> On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
>>> On 8/9/15 5:07 AM, JDemler wrote:
>>>> We can read files at compile-time:
>>>>
>>>>    enum file = import(fileName);
>>>>
>>>> But we cannot write to a file or create files at compile time.
>>>>
>>>> Generating code at compile-time and mixing it in is fun but has a few
>>>> flaws.
>>>> It isn't debuggable, the generated code cannot be directly inspected (we
>>>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>>>
>>>> If we could generate source files (.d) at compile time and then import
>>>> them using mixins or something else, these problems can be dealt with.
>>>
>>> I think this is an interesting pursuit that closes the circle on a
>>> number of issues, such as debuggability and compilation speed of mixin
>>> code. -- Andrei
>>
>> The moment this is added to D, we will have two complete languages in
>> one: an interpreted one at compile-time and another at runtime.
>>
>> While I find this interesting, I wonder wether this is  a good idea or not.
>
> I'm actually at the point where I believe the addition of string import was a bad one. No. I prefer preprocessing into a D file first.
> It irks me, you have to be pretty careful with them, but at least a preprocessed file you know _exactly_ where all files need to be for CT.

Consider vibe.d's diet templates: They are compiled into d code using information of the types provided by the user.
Without string imports at compile-time that would either result in a two-step compile process or would rely on run-time type information. Both is nothing I would like to use.

Imagine the .dt files could be compiled into .dt.d files and then imported at compile-time. The development process would be much easier (debugging and examining the source files becomes trivial) and the usage would be more transparent (I see what my .dt file gets compiled into) and would have faster compile times (as Andrei mentioned).
« First   ‹ Prev
1 2 3 4