Walter Bright wrote:
> Bill Baxter wrote:
>> I'd like to write this:
>>
>> char[] NReps(char[] x, int n)
>> {
>>     char[] ret = "";
>>     for(int i=0; i<n; i++) { ret ~= x; }
>>     return ret;
>> }
>>
>> But that doesn't work.
> 
> It does when I try it:
> ---------------------
> import std.stdio;
> 
> char[] NReps(char[] x, int n)
> {
>     char[] ret = "";
>     for(int i=0; i<n; i++) { ret ~= x; }
>     return ret;
> }
> 
> void main()
> {
>    static x = NReps("3", 6);
>    writefln(x);
> }
> -----------------------
> prints:
> 
> 333333


Doh!  You're right.  I must have had some other bad code commented in accidentally at the time.

--bb

I'm having a few problems getting some simple examples to work, for instance:

-----
char[] foo() { return( "bar" ); }
void main() { const char[] bar = foo(); }

Assertion failure: 'parameters && parameters->dim == dim' on line 96 in file 'interpret.c'

abnormal program termination
-----

and

-----
template eval( A... ) { alias A eval; }
int square( int n ) { return( n * n ); }
void main() { int bar = eval!( square( 5 ) ); }

Error: cannot implicitly convert expression (tuple25) of type (int) to int
-----

What am I doing wrong?

Thanks,
Brian Byrne






Walter Bright wrote:
> ... is now in DMD 1.006. For example:
> 
>> -------------------------------------------
>> import std.stdio;
>>
>> real sqrt(real x)
>> {
>>    real root = x / 2;
>>    for (int ntries = 0; ntries < 5; ntries++)
>>    {
>>        if (root * root - x == 0)
>>            break;
>>        root = (root + x / root) / 2;
>>    }
>>    return root;
>> }
>>
>> void main()
>> {
>>    static x = sqrt(10);   // woo-hoo! set to 3.16228 at compile time!
>>    writefln("%s, %s", x, sqrt(10));  // this sqrt(10) runs at run time
>> }
>> ------------------------------------------
> 
> This should obsolete using templates to compute values at compile time.

Brian Byrne wrote:
> 
> I'm having a few problems getting some simple examples to work, for instance:
> 
> -----
> char[] foo() { return( "bar" ); }
> void main() { const char[] bar = foo(); }
> 
> Assertion failure: 'parameters && parameters->dim == dim' on line 96 in file 'interpret.c'
> 
> abnormal program termination
> -----

This bug has already been reported: http://d.puremagic.com/issues/show_bug.cgi?id=968

Walter Bright wrote:
> Michiel wrote:
>> Walter Bright wrote:
>>
>>> Many functions could be executed at compile time, but should not be.
>>
>> When should they not be?
> 
> 1) Another poster mentioned a function that decompressed a built-in string - the whole point of having it compressed was to reduce the exe file size. Decompressing it at compile time defeats the purpose.
> 
> 2) A function that simply takes too long at compile time. Compile time execution is going to be >100 times slower than run time.

One thought on this.  What about leveraging multiple threads to calculate different algorithms at once.  They should all be self contained, so this shouldn't be much of a problem.  With the quad-cores the compiled program would run maybe at 30 times slower.  Also its a good step towards future-proofing the compiler.

-Joel

janderson wrote:

>> 2) A function that simply takes too long at compile time. Compile time execution is going to be >100 times slower than run time.
> 
> One thought on this.  What about leveraging multiple threads to calculate different algorithms at once.  They should all be self contained, so this shouldn't be much of a problem.  With the quad-cores the compiled program would run maybe at 30 times slower.  Also its a good step towards future-proofing the compiler.

And I'm not 100% sure why you can't compile those functions and run another process to do the algorithms. Not with an interpreter, but with compiled D code.

If course, I wouldn't know how to actually do that, but in theory it's possible.

-- 
Michiel

Walter Bright wrote:
> janderson wrote:
>> Walter Bright wrote:
>>> Right now, the compiler will fail if the compile time execution results in infinite recursion or an infinite loop. I'll have to figure out some way to eventually deal with this.
>>
>> Maybe you could allow the user to specify stack size and maximum iteration per loop/recursion function to the compiler as flags (with some defaults).   This way the user can up the size if they really need it.  This would make it a platform thing.  That way a D compiler could still be made for less powerful systems.
> 
> Whether you tell it to fail at a smaller limit, or it fails by itself at a smaller limit, doesn't make any difference as to whether it runs on a less powerful system or not <g>.
> 
> The C standard has these "minimum translation limits" for all kinds of things - number of lines, chars in a string, expression nesting level, etc. It's all kind of bogus, hearkening back to primitive compilers that actually used fixed array sizes internally (Brand X, who-shall-not-be-named, was notorious for exceeding internal table limits, much to the delight of Zortech's sales staff). The right way to build a compiler is it either runs out of stack or memory, and that's the only limit.
> 
> If your system is too primitive to run the compiler, you use a cross compiler running on a more powerful machine.
> 
> I have thought of just putting a timer in the interpreter - if it runs for more than a minute, assume things have gone terribly awry and quit with a message.

This is exactly pertaining to compiler specific issues, but paralleling the above, why have "The total size of a static array cannot exceed 16Mb. A dynamic array should be used instead for such large arrays." in the Array spec.  Isn't that kind of similar?  16Mb of static array data is a lot no doubt, but why put an arbitrary limit on it.  Unless it's a DMD specific thing.

Joe

Well I just tried compiling a rather large codebase on 1.006, it takes forever and errors out with a 2+ gig executable sitting there. So I must have something going crazy under the hood. :) I will try to track it down.

J Duncan wrote:
> Well I just tried compiling a rather large codebase on 1.006, it takes forever and errors out with a 2+ gig executable sitting there. So I must have something going crazy under the hood. :) I will try to track it down.

I had a huge memory usage like that when I tried to compile a file with an infinite loop in a function executed at compile time...

Sorry if this was already answered, but I can't find it..
Is compile-time execution of library functions allowed?

-- 
serg.

Serg Kovrov wrote:
> Sorry if this was already answered, but I can't find it..
> Is compile-time execution of library functions allowed?

That depends on what you mean by "library functions". Obviously you mean a function in a library, but that's not really what matters here. The important question is whether the source is available to the compiler. It doesn't care where the compiled version ends up, because it doesn't use it. It just needs to see the source.

So basically, for a library with declaration-only (no or incomplete implementation) "headers" the answer is no, for libraries that ship with full source (that's used to satisfy imports, so no .di modules) the answer is yes. Just like with normal source files.