i use pipe() syscall from my program. when i compile it I got the following msg:

Error: pipe cannot be interpreted at compile time, because it has no available source code

how can i fix it?

dmd 2.063.2, Mac OS X

On Saturday, September 21, 2013 20:30:00 Ruslan Mullakhmetov wrote:
> i use pipe() syscall from my program. when i compile it I got the
> following msg:
> 
> Error: pipe cannot be interpreted at compile time, because it has no available source code
> 
> how can i fix it?
> 
> dmd 2.063.2, Mac OS X

It sounds like you're trying to use pipe at compile time, and as the error says, you can't use it at compile time, because no source code for it is available. The same goes for all C functions. They can only be used at runtime.

- Jonathan M Davis

Didn't catch. How can I use it at runtime? I can not link to actually C function?

On Saturday, 21 September 2013 at 19:40:48 UTC, Jonathan M Davis wrote:
> On Saturday, September 21, 2013 20:30:00 Ruslan Mullakhmetov wrote:
>> i use pipe() syscall from my program. when i compile it I got the
>> following msg:
>> 
>> Error: pipe cannot be interpreted at compile time, because it has
>> no available source code
>> 
>> how can i fix it?
>> 
>> dmd 2.063.2, Mac OS X
>
> It sounds like you're trying to use pipe at compile time, and as the error
> says, you can't use it at compile time, because no source code for it is
> available. The same goes for all C functions. They can only be used at
> runtime.
>
> - Jonathan M Davis

I found where the problem is.

I used a system call (external C function) in class ctor. then I declared global variable of this class and INITIALZIED that variable inplace. If i move initalization in module static this() everything compiles.

the code is:

incorrect version:
http://dpaste.com/hold/1391530/

correct:
http://dpaste.com/hold/1391523/


But now i need to sort out what the difference between
// global scope

int a = 10;

and

int a;

static this()
{
 a = 10;
}


I appreciate if somebody give a link or chapter number where to read.

22-Sep-2013 15:52, Ruslan Mullakhmetov пишет:
>
> I found where the problem is.
>
> I used a system call (external C function) in class ctor. then I
> declared global variable of this class and INITIALZIED that variable
> inplace. If i move initalization in module static this() everything
> compiles.
>
> the code is:
>
> incorrect version:
> http://dpaste.com/hold/1391530/
>
> correct:
> http://dpaste.com/hold/1391523/
>
>
> But now i need to sort out what the difference between
> // global scope
>
> int a = 10;
>

This just puts calculated value 10 into TLS data section as initializer for a.

> and
>
> int a;
>
> static this()
> {
>   a = 10;
> }
>

This defines a global with 0 initializer.

Then static this is a function that is executed for each D thread on creation, following the module dependency chain (i.e. if there is static this in imported module it should be run first).

I would be curious to see why you believe them to be the same.

> I appreciate if somebody give a link or chapter number where to read.


-- 
Dmitry Olshansky

On Sunday, September 22, 2013 13:52:54 Ruslan Mullakhmetov wrote:
> But now i need to sort out what the difference between
> // global scope
> 
> int a = 10;

That directly initializes the variable at compile time, meaning that whatever is used to initialize the variable must be callable at compile time. And the value must be able to be set at compile time and then be carried over to runtime. That will work with int, but it does not work with most stuff that's on the heap (like classes or AAs) - arrays would be the major exception to that, since they can be set at compile time (and I believe that it was recently changed so that immutable classes could be set at compile time, but not const or mutable ones - implementing that is rather complicated, and it may or may not ever happen). Over time, what you can do at compile time with CTFE (Compile Time Function Evaluation) has improved, but there are still restrictions, and some things will never be possible (e.g. I/O or calling C functions).

> and
> 
> int a;
> 
> static this()
> {
>   a = 10;
> }

That does not set the variable at compile time. Rather, the static constructor sets it at runtime. So, this has none of the restrictions that directly initializing a module or static variable does. However, it does have the downside that two modules that have static constructors can't import each other (either directly or indirectly), because then the runtime wouldn't know which order to run them in. If you do that, you'll get an exception at runtime complaining about a circular import (which sucks, but unfortunately, the circular import can't always be detected at compile time - thanks in part to .di files - so runtime detection is the best that can be done). So, while static constructors can be really nice, you do have to avoid having modules that use them import each other, which means either being careful about how your modules import each other or avoiding static constructors. Which is easier depends on your code.

> I would be curious to see why you believe them to be the same.

Cause i'm a C++ programmer and there is no such thing as module and module initializer, in fact object file initialization consist of initialization of all its static variables somewhen before the first call of a function in that object file (if any).

On Sunday, 22 September 2013 at 19:50:14 UTC, Dmitry Olshansky wrote:
> 22-Sep-2013 15:52, Ruslan Mullakhmetov пишет:
>>
>> I found where the problem is.
>>
>> I used a system call (external C function) in class ctor. then I
>> declared global variable of this class and INITIALZIED that variable
>> inplace. If i move initalization in module static this() everything
>> compiles.
>>
>> the code is:
>>
>> incorrect version:
>> http://dpaste.com/hold/1391530/
>>
>> correct:
>> http://dpaste.com/hold/1391523/
>>
>>
>> But now i need to sort out what the difference between
>> // global scope
>>
>> int a = 10;
>>
>
> This just puts calculated value 10 into TLS data section as initializer for a.
>
>> and
>>
>> int a;
>>
>> static this()
>> {
>>  a = 10;
>> }
>>
>
> This defines a global with 0 initializer.
>
> Then static this is a function that is executed for each D thread on creation, following the module dependency chain (i.e. if there is static this in imported module it should be run first).
>
> I would be curious to see why you believe them to be the same.
>
>> I appreciate if somebody give a link or chapter number where to read.

Thanks. I suspected it but i wanted a formal reference. the logic, though little bit cleared by you is quite obvious. But don't waste time, if you can not tell  from a scratch that this is clause x.y.z of the Standard, sorry, Book.

On Sunday, 22 September 2013 at 19:56:36 UTC, Jonathan M Davis wrote:
> On Sunday, September 22, 2013 13:52:54 Ruslan Mullakhmetov wrote:
>> But now i need to sort out what the difference between
>> // global scope
>> 
>> int a = 10;
>
> That directly initializes the variable at compile time, meaning that whatever
> is used to initialize the variable must be callable at compile time. And the
> value must be able to be set at compile time and then be carried over to
> runtime. That will work with int, but it does not work with most stuff that's
> on the heap (like classes or AAs) - arrays would be the major exception to
> that, since they can be set at compile time (and I believe that it was
> recently changed so that immutable classes could be set at compile time, but
> not const or mutable ones - implementing that is rather complicated, and it
> may or may not ever happen). Over time, what you can do at compile time with
> CTFE (Compile Time Function Evaluation) has improved, but there are still
> restrictions, and some things will never be possible (e.g. I/O or calling C
> functions).
>
>> and
>> 
>> int a;
>> 
>> static this()
>> {
>>   a = 10;
>> }
>
> That does not set the variable at compile time. Rather, the static constructor
> sets it at runtime. So, this has none of the restrictions that directly
> initializing a module or static variable does. However, it does have the
> downside that two modules that have static constructors can't import each
> other (either directly or indirectly), because then the runtime wouldn't know
> which order to run them in. If you do that, you'll get an exception at runtime
> complaining about a circular import (which sucks, but unfortunately, the
> circular import can't always be detected at compile time - thanks in part to
> .di files - so runtime detection is the best that can be done). So, while
> static constructors can be really nice, you do have to avoid having modules
> that use them import each other, which means either being careful about how
> your modules import each other or avoiding static constructors. Which is
> easier depends on your code.