On Fri, Jul 12, 2013 at 5:10 PM, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Jul 12, 2013 at 05:00:29PM -0700, Timothee Cour wrote:<br>
> On Fri, Jul 12, 2013 at 4:51 PM, H. S. Teoh <<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>> wrote:<br>
><br>
> > On Sat, Jul 13, 2013 at 12:51:03AM +0200, Tofu Ninja wrote:<br>
> > > On Friday, 12 July 2013 at 22:36:22 UTC, Peter Alexander wrote:<br>
> > > >On Friday, 12 July 2013 at 20:42:50 UTC, Tofu Ninja wrote:<br>
> > > >>So I had an idea recently, wouldn't it be cool to have the<br>
> > > >>ability to call an executable at compile time and capture its<br>
> > > >>output.<br>
> > > ><br>
> > > >How long until D compilers are able to read mail? :-)<br>
> ><br>
> > Zawinski's law of software envelopment:<br>
> ><br>
> >         Every program attempts to expand until it can read mail. Those<br>
> >         programs which cannot so expand are replaced by ones which can.<br>
><br>
><br>
> forget about reading mail, we currently don't even have hello world! (we<br>
> have pragma(msg) but no ctfewriteln, which pragma(msg) can't do)<br>
<br>
</div>Why should the compiler turn into a hello world program?<br></blockquote><div><br></div><div><br></div><div>For logging / debugging purposes, we often need to be able to print at compile time some variables, but ctfeWriteln doesn't even work. And again, pragma(msg) can't replace it.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
<div class="im">> > Makefiles, for example, can't correctly recompile your program if you<br>
> > change compiler flags. And complex interdependencies, like you said,<br>
> > require painful manual maintenance, otherwise they tend to screw up and<br>
> > produce inconsistent results.<br>
> ><br>
> > For an example of a modern build system, see <a href="http://gittup.org/tup/" target="_blank">http://gittup.org/tup/</a>.<br>
> ><br>
> ><br>
> Using a build system would likely be non-portable (see current mess<br>
> even in dmd source code, which requires <a href="http://posix.ma" target="_blank">posix.ma</a> / win32.mak /<br>
> win64.mak which is not DRY and hard to maintain), and suffer from the<br>
> points I mentioned in my previous post.<br>
<br>
</div>Again, makefiles are a poor example of build systems. There *are* build<br>
systems that allow you to write portable build scripts, such as SCons.<br>
They're not perfect, but makefiles are a far cry from what they can do.<br>
<div class="im"><br>
<br>
> We don't need yet another build system if we have "exec" available at<br>
> CT.<br>
<br>
</div>That doesn't replace a proper build system.</blockquote><div> </div><div>I wrote a D based makefile-like tool in D (which uses direct acyclic graph to find compilation order). It's much cleaner in D for obvious reasons.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What if your external program itself is a D program that needs to be compiled first?</blockquote><div><br></div>
<div>call exec("dmd mydeps.d"); (or exec("make -all") or the D based makefile)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What if you need to run an external program like povray in order to generate<br>

images (say, animation frames) that are string-imported into your<br>
program?</blockquote><div><br></div><div>I don't see how that's different:</div><div>void main(){</div><div>enum s=exec("program generating images");</div><div>import(s);</div><div>//use the string import</div>
<div>//or even simply: use s directly, depending on conditions</div><div>}</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Should DMD have the capability of running arbitrary programs<br>

that produce arbitrary output and be able to sort out which programs<br>
must run first and which output should be imported into the D program?<br></blockquote><div><br></div><div>The order would be simply program order, as in the example above: "enum s=exec(...)" is run during CTFE before import(s), as it comes first.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So we're no longer talking about the D compiler, but about the D<br>
operating system. The real "DOS". :-P Which, mind you, would be a good<br>
thing IMO, but I think it's a bit of a stretch from where we are<br>
currently.<br></blockquote><div><br></div><div>No, all it requires in terms of dmd modification is CTFE exec. </div><div>The user can use it to do complex stuff if he so wishes. </div><div><br></div><div>CTFE already runs very complex program (involving std.algorithm and whatnot), so there's already a justification for running complex programs during CTFE. Allowing that one simple function will enable many more things. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Let's put it another way: if I or someone else made a pull request for<br>
> CTFE "exec", would it have a chance of being accepted?<br>
<br>
</div>I'm not one to decide, you have to convince Walter.<br>
<br>
And I'm not saying this idea is good or bad, I'm just saying that you<br>
can already do such things without compiler support. </blockquote><div><br></div><div>we can't even print variables during CTFE. Using a build system to do that is way overkill.</div><div><br></div><div> </div></div>