"Rob T" <rob ucora.com> writes:

Thanks to input from the D community, I've managed to implement a 
reasonable way to log the name of a calling function. This is 
used for basic execution monitoring and for automated logging of 
exception errors.

Here's what I did.

template __FUNCTION()
{
    const char[] __FUNCTION = "__traits(identifier, 
__traits(parent, {}))";
}

Example use in code:

throw new Exception( "Error: Function ", mixin(__FUNCTION!()) );

writefln( "File: %s, Func: %s, Line: %d", __FILE__, 
mixin(__FUNCTION!()), __LINE__ );


The ONLY thing left that I would like to have, is ability to 
display the function signature along with the name. The signature 
will be very useful to show which version of an overloaded or 
templated function was called.

If anyone can suggest imporvements, like how to get rid of need 
to explicitly call mixin, and better yet a solution to get the 
function signature, please post away. Thanks!

I have to mention that we need a real solution that can only be 
provided through improved reflection support, eg 
__scope.function, __scope.line, __scope.file, etc, or whatever 
the D community thinks will fit in best.

--rt

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
 Thanks to input from the D community, I've managed to implement 
 a reasonable way to log the name of a calling function.

Huh, that's pretty brilliant!


 The ONLY thing left that I would like to have, is ability to 
 display the function signature along with the name.

template __FUNCTION_SIGNATURE() { const char[] 
__FUNCTION_SIGNATURE = "typeof(__traits(parent, {})).stringof"; }

int main(string[] args) {
         assert(0, mixin(__FUNCTION_SIGNATURE!()));
}

core.exception.AssertError test4.d(7): int(string[] args)

"Rob T" <rob ucora.com> writes:

On Friday, 2 November 2012 at 17:55:33 UTC, Adam D. Ruppe wrote:
 The ONLY thing left that I would like to have, is ability to 
 display the function signature along with the name.

 template __FUNCTION_SIGNATURE() { const char[] 
 __FUNCTION_SIGNATURE = "typeof(__traits(parent, {})).stringof"; 
 }

 int main(string[] args) {
         assert(0, mixin(__FUNCTION_SIGNATURE!()));
 }

 core.exception.AssertError test4.d(7): int(string[] args)

That was fast, thanks!

template __PRETTY_FUNCTION()
{
	const char[] __PRETTY_FUNCTION = "__traits(identifier, 
__traits(parent, {})) ~ " ~ __FUNCTION_SIGNATURE!();
}


--rt

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 02-11-2012 18:31, Rob T wrote:
 Thanks to input from the D community, I've managed to implement a
 reasonable way to log the name of a calling function. This is used for
 basic execution monitoring and for automated logging of exception errors.

 Here's what I did.

 template __FUNCTION()
 {
     const char[] __FUNCTION = "__traits(identifier, __traits(parent, {}))";
 }

 Example use in code:

 throw new Exception( "Error: Function ", mixin(__FUNCTION!()) );

 writefln( "File: %s, Func: %s, Line: %d", __FILE__,
 mixin(__FUNCTION!()), __LINE__ );


 The ONLY thing left that I would like to have, is ability to display the
 function signature along with the name. The signature will be very
 useful to show which version of an overloaded or templated function was
 called.

 If anyone can suggest imporvements, like how to get rid of need to
 explicitly call mixin, and better yet a solution to get the function
 signature, please post away. Thanks!

 I have to mention that we need a real solution that can only be provided
 through improved reflection support, eg __scope.function, __scope.line,
 __scope.file, etc, or whatever the D community thinks will fit in best.

 --rt

You should totally submit this for inclusion into std.traits in Phobos.

(Though, to follow naming conventions, it should be functionName and 
functionSignature or so.)

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Regan Heath" <regan netmail.co.nz> writes:

On Fri, 02 Nov 2012 18:06:19 -0000, Alex R=F8nne Petersen <alex lycus.or=
g>  =

wrote:

 On 02-11-2012 18:31, Rob T wrote:
 Thanks to input from the D community, I've managed to implement a
 reasonable way to log the name of a calling function. This is used fo=


r
 basic execution monitoring and for automated logging of exception  =


 errors.

 Here's what I did.

 template __FUNCTION()
 {
     const char[] __FUNCTION =3D "__traits(identifier, __traits(parent=


,  =

 {}))";
 }

 Example use in code:

 throw new Exception( "Error: Function ", mixin(__FUNCTION!()) );

 writefln( "File: %s, Func: %s, Line: %d", __FILE__,
 mixin(__FUNCTION!()), __LINE__ );


 The ONLY thing left that I would like to have, is ability to display =


the
 function signature along with the name. The signature will be very
 useful to show which version of an overloaded or templated function w=


as
 called.

 If anyone can suggest imporvements, like how to get rid of need to
 explicitly call mixin, and better yet a solution to get the function
 signature, please post away. Thanks!

 I have to mention that we need a real solution that can only be provi=


ded
 through improved reflection support, eg __scope.function, __scope.lin=


e,
 __scope.file, etc, or whatever the D community thinks will fit in bes=


t.
 --rt

 You should totally submit this for inclusion into std.traits in Phobos=

.
 (Though, to follow naming conventions, it should be functionName and  =

 functionSignature or so.)

+1 :)

R

-- =

Using Opera's revolutionary email client: http://www.opera.com/mail/

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Nov 02, 2012 at 07:06:19PM +0100, Alex Rønne Petersen wrote:
 On 02-11-2012 18:31, Rob T wrote:

[...]
template __FUNCTION()
{
    const char[] __FUNCTION = "__traits(identifier, __traits(parent, {}))";
}

Example use in code:

throw new Exception( "Error: Function ", mixin(__FUNCTION!()) );

writefln( "File: %s, Func: %s, Line: %d", __FILE__,
mixin(__FUNCTION!()), __LINE__ );


[[...]
 You should totally submit this for inclusion into std.traits in Phobos.
 
 (Though, to follow naming conventions, it should be functionName and
 functionSignature or so.)

[...]

+1.


T

-- 
Тише едешь, дальше будешь.

"mist" <none none.none> writes:

fullyQualifiedTypename ) useful for adding function signature 
once it gets finalised and merged.

On Friday, 2 November 2012 at 17:31:55 UTC, Rob T wrote:
 Thanks to input from the D community, I've managed to implement 
 a reasonable way to log the name of a calling function. This is 
 used for basic execution monitoring and for automated logging 
 of exception errors.

 Here's what I did.

 template __FUNCTION()
 {
    const char[] __FUNCTION = "__traits(identifier, 
 __traits(parent, {}))";
 }

 Example use in code:

 throw new Exception( "Error: Function ", mixin(__FUNCTION!()) );

 writefln( "File: %s, Func: %s, Line: %d", __FILE__, 
 mixin(__FUNCTION!()), __LINE__ );


 The ONLY thing left that I would like to have, is ability to 
 display the function signature along with the name. The 
 signature will be very useful to show which version of an 
 overloaded or templated function was called.

 If anyone can suggest imporvements, like how to get rid of need 
 to explicitly call mixin, and better yet a solution to get the 
 function signature, please post away. Thanks!

 I have to mention that we need a real solution that can only be 
 provided through improved reflection support, eg 
 __scope.function, __scope.line, __scope.file, etc, or whatever 
 the D community thinks will fit in best.

 --rt

Jacob Carlborg <doob me.com> writes:

On 2012-11-02 18:31, Rob T wrote:
 Thanks to input from the D community, I've managed to implement a
 reasonable way to log the name of a calling function. This is used for
 basic execution monitoring and for automated logging of exception errors.

 Here's what I did.

 template __FUNCTION()
 {
     const char[] __FUNCTION = "__traits(identifier, __traits(parent, {}))";
 }

 Example use in code:

 throw new Exception( "Error: Function ", mixin(__FUNCTION!()) );

 writefln( "File: %s, Func: %s, Line: %d", __FILE__,
 mixin(__FUNCTION!()), __LINE__ );

That's pretty darn cool, well done :D .

-- 
/Jacob Carlborg

Philippe Sigaud <philippe.sigaud gmail.com> writes:

By changing this to a standard function:

const(char[]) __FUNCTION()  property
{
   return "__traits(identifier, __traits(parent, {}))";
}


... the calling syntax is slightly easier on the eye:

void main()
{
    writefln( "File: %s, Func: %s, Line: %d", __FILE__,
mixin(__FUNCTION), __LINE__ );

    //throw new Exception( "Error: Function " ~ mixin(__FUNCTION) );
}

That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())


Is there any downside to this?

Timon Gehr <timon.gehr gmx.ch> writes:

On 11/02/2012 10:34 PM, Philippe Sigaud wrote:
 By changing this to a standard function:

 const(char[]) __FUNCTION()  property
 {
     return "__traits(identifier, __traits(parent, {}))";
 }


 ... the calling syntax is slightly easier on the eye:

 void main()
 {
      writefln( "File: %s, Func: %s, Line: %d", __FILE__,
 mixin(__FUNCTION), __LINE__ );

      //throw new Exception( "Error: Function " ~ mixin(__FUNCTION) );
 }

 That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())


 Is there any downside to this?

I'd make it

enum currentFunction = q{ __traits(identifier, __traits(parent, {})) };

"Rob T" <rob ucora.com> writes:

On Friday, 2 November 2012 at 21:34:23 UTC, Philippe Sigaud wrote:
 By changing this to a standard function:

 const(char[]) __FUNCTION()  property
 {
    return "__traits(identifier, __traits(parent, {}))";
 }


 ... the calling syntax is slightly easier on the eye:

 void main()
 {
     writefln( "File: %s, Func: %s, Line: %d", __FILE__,
 mixin(__FUNCTION), __LINE__ );

     //throw new Exception( "Error: Function " ~ 
 mixin(__FUNCTION) );
 }

 That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())


 Is there any downside to this?

That looks better. Not sure what the down side would be if any.

Unrelated to either form, I discovered it fails to compile when 
inside a function with "auto" as the return type.

auto test()
{
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
}

Error: forward reference to test

but this works

int test()
{
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
}

So we're kinda sunk for inclusion in phobos unless this error can 
be resolved.

I'll try the enum idea to see if that works.

--rt

"Rob T" <rob ucora.com> writes:

On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
 Unrelated to either form, I discovered it fails to compile when 
 inside a function with "auto" as the return type.

 auto test()
 {
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
 }

 Error: forward reference to test

 but this works

 int test()
 {
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
 }

 So we're kinda sunk for inclusion in phobos unless this error 
 can be resolved.

 I'll try the enum idea to see if that works.

 --rt

No luck with enum version, it still fails to compile when used 
inside a function with auto as the return type, same "forward 
reference" error.

--rt

Jacob Carlborg <doob me.com> writes:

On 2012-11-02 23:33, Rob T wrote:

 That looks better. Not sure what the down side would be if any.

 Unrelated to either form, I discovered it fails to compile when inside a
 function with "auto" as the return type.

 auto test()
 {
     throw new Exception(  mixin(__FUNCTION) );
     return 0;
 }

 Error: forward reference to test

 but this works

 int test()
 {
     throw new Exception(  mixin(__FUNCTION) );
     return 0;
 }

 So we're kinda sunk for inclusion in phobos unless this error can be
 resolved.

I think it would be worth to but in Phobos anyway.

-- 
/Jacob Carlborg

"Rob T" <rob ucora.com> writes:

On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg 
wrote:
 I think it would be worth to but in Phobos anyway.

I suppose it works as a temp solution until a real one is finally 
implemented, or maybe the mixin behaviour is considered a bug and 
can be fixed?

"Damian" <damianday hotmail.co.uk> writes:

On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote:
 On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg 
 wrote:
 I think it would be worth to but in Phobos anyway.

 I suppose it works as a temp solution until a real one is 
 finally implemented, or maybe the mixin behaviour is considered 
 a bug and can be fixed?

I think __FUNCTION__ should be built into the compiler, with it's 
brothers __FILE__ and __LINE__ . This kinda thing is so useful 
while debugging and logging :)

"Rob T" <rob ucora.com> writes:

On Sunday, 4 November 2012 at 13:57:07 UTC, Damian wrote:
 On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote:
 On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg 
 wrote:
 I think it would be worth to but in Phobos anyway.

 I suppose it works as a temp solution until a real one is 
 finally implemented, or maybe the mixin behaviour is 
 considered a bug and can be fixed?

 I think __FUNCTION__ should be built into the compiler, with 
 it's brothers __FILE__ and __LINE__ . This kinda thing is so 
 useful while debugging and logging :)

I completely agree. Direct compiler support is the only way to 
implement this form of reflection reliably for all cases. Also 
consider that with D we have an opportunity to implement 
reflection features in a more consistent way through a generlized 
form of reflection.

--rt

"Rob T" <rob ucora.com> writes:

On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
 I discovered it fails to compile when inside a function with 
 "auto" as the return type.

 auto test()
 {
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
 }

 Error: forward reference to test

 but this works

 int test()
 {
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
 }

 So we're kinda sunk for inclusion in phobos unless this error 
 can be resolved.

 I'll try the enum idea to see if that works.

 --rt

An update on this problem. I found out that the error when using 
auto as return type has nothing to do with the mixin. The 
compiler error persists when you take mixin out and put in the 
__traits( ... ) code directly.

Does anyone else think that this is a compiler bug? If it is a 
bug then I'll report it in the bug tracker.

--rt

Don Clugston <dac nospam.com> writes:

On 06/11/12 07:09, Rob T wrote:
 On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
 I discovered it fails to compile when inside a function with "auto" as
 the return type.

 auto test()
 {
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
 }

 Error: forward reference to test

 but this works

 int test()
 {
    throw new Exception(  mixin(__FUNCTION) );
    return 0;
 }

 So we're kinda sunk for inclusion in phobos unless this error can be
 resolved.

 I'll try the enum idea to see if that works.

 --rt

 An update on this problem. I found out that the error when using auto as
 return type has nothing to do with the mixin. The compiler error
 persists when you take mixin out and put in the __traits( ... ) code
 directly.

 Does anyone else think that this is a compiler bug? If it is a bug then
 I'll report it in the bug tracker.

 --rt

It fails because you're asking for the full function name, before its 
type has been determined. (There's no real return type 'auto', 'auto' 
just means 'work it out for me').

I don't think this is a bug. Although it might be solvable in this 
particular example, in general it's a circular dependency.

eg, if you do:

auto foo()
{
    static if (__FUNCTION == "int foo()") { return 'a' }
    return 0;
}
if __FUNCTION is "int foo()" then it will return a char, which means its 
signature is "char foo()". This is a contradiction.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On 2012-46-06 08:11, Don Clugston <dac nospam.com> wrote:

 It fails because you're asking for the full function name, before its  
 type has been determined. (There's no real return type 'auto', 'auto'  
 just means 'work it out for me').

 I don't think this is a bug. Although it might be solvable in this  
 particular example, in general it's a circular dependency.

 eg, if you do:

 auto foo()
 {
     static if (__FUNCTION == "int foo()") { return 'a' }
     return 0;
 }
 if __FUNCTION is "int foo()" then it will return a char, which means its  
 signature is "char foo()". This is a contradiction.

DMD already does some cycle detection for types, right? I don't remember
the details, but i seem to recall this was made to work a few releases  
back:

class Foo {
     static if ( is( typeof( Foo.bar ) ) ) {
         void baz() {}
     }
     static if ( true ) {
         int bar() {}
     }
}

The algorithm would probably have to exclude mixins, but I think it could
be made to work for most cases.

-- 
Simen

"r_m_r" <r_m_r mailinator.com> writes:

I don't know how I missed this thread. I was having the same 
'forward reference' error and after a brief chat on #D IRC, 
thought it might be a compiler bug and reported it as such: 
http://d.puremagic.com/issues/show_bug.cgi?id=8963 . Should I 
close this issue?

Any thoughts on possible workarounds?

BTW I've been 'mixing'-in this template in all my functions (for 
debugging):

//---- Code ---
import std.traits : PIT=ParameterIdentifierTuple;

template dbg(string msg)
{
     const char[] dbg = "writeln( src(\"DBG\",
                                     __traits(identifier, 
__traits(parent, {})) ~
                                     
_params_join([PIT!(__traits(parent,{}))]),
                                     " ~ msg ~ "
                                     )
                                );" ;
}
//----- Code ---

Its working great except for the "auto"-return functions.

rmr

On Tuesday, 6 November 2012 at 07:46:47 UTC, Don Clugston wrote:
 On 06/11/12 07:09, Rob T wrote:
 On Friday, 2 November 2012 at 22:33:37 UTC, Rob T wrote:
 I discovered it fails to compile when inside a function with 
 "auto" as
 the return type.

 auto test()
 {
   throw new Exception(  mixin(__FUNCTION) );
   return 0;
 }

 Error: forward reference to test

 but this works

 int test()
 {
   throw new Exception(  mixin(__FUNCTION) );
   return 0;
 }

 So we're kinda sunk for inclusion in phobos unless this error 
 can be
 resolved.

 I'll try the enum idea to see if that works.

 --rt

 An update on this problem. I found out that the error when 
 using auto as
 return type has nothing to do with the mixin. The compiler 
 error
 persists when you take mixin out and put in the __traits( ... 
 ) code
 directly.

 Does anyone else think that this is a compiler bug? If it is a 
 bug then
 I'll report it in the bug tracker.

 --rt

 It fails because you're asking for the full function name, 
 before its type has been determined. (There's no real return 
 type 'auto', 'auto' just means 'work it out for me').

 I don't think this is a bug. Although it might be solvable in 
 this particular example, in general it's a circular dependency.

 eg, if you do:

 auto foo()
 {
    static if (__FUNCTION == "int foo()") { return 'a' }
    return 0;
 }
 if __FUNCTION is "int foo()" then it will return a char, which 
 means its signature is "char foo()". This is a contradiction.

"Rob T" <rob ucora.com> writes:

On Tuesday, 6 November 2012 at 07:46:47 UTC, Don Clugston wrote:
 It fails because you're asking for the full function name, 
 before its type has been determined. (There's no real return 
 type 'auto', 'auto' just means 'work it out for me').

In our case, the function name that is returned is nothing but 
the function's symbol name by itself, which of course is known 
ahead of time no matter if auto is stated or not. This is why it 
seems more like a bug to me.


--rt

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Friday, November 02, 2012 22:34:15 Philippe Sigaud wrote:
 By changing this to a standard function:
 
 const(char[]) __FUNCTION()  property
 {
 return "__traits(identifier, __traits(parent, {}))";
 }
 
 
 ... the calling syntax is slightly easier on the eye:
 
 void main()
 {
 writefln( "File: %s, Func: %s, Line: %d", __FILE__,
 mixin(__FUNCTION), __LINE__ );
 
 //throw new Exception( "Error: Function " ~ mixin(__FUNCTION) );
 }
 
 That is, mixin(__FUNCTION) instead of mixin(__FUNCTION!())
 
 
 Is there any downside to this?

Identifiers starting with __ are reserved for the compiler/language. It should 
be __FUNCTION__ if it's built-in, but if it's in the library, I see no reason 
to name it in a way that conflicts with Phobos' naming conventions like this.

- Jonathan M Davis

Philippe Sigaud <philippe.sigaud gmail.com> writes:

On Fri, Nov 2, 2012 at 10:59 PM, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Is there any downside to this?

 Identifiers starting with __ are reserved for the compiler/language. It should
 be __FUNCTION__ if it's built-in, but if it's in the library, I see no reason
 to name it in a way that conflicts with Phobos' naming conventions like this.

Er, yes, but __FUNCTION comes the OP. My question was more about using
a function instead of a template.
And Timon makes a good point, using a token string q{ } should make
this more mixin-able.