Walter Bright wrote:
> Some things of note:
> 
> 1) This includes a new code coverage analyzer for dmd (I think gcov should
> work for gdc users). I've been wanting to add this for 20 years, I finally
> realized it was a piece of cake. Took me 3 hours to write, 3 hours to tweak.
> I shoulda done it a long time ago. I can't believe some third party tools to
> do this cost $800+.
> 
> 2) The submissions for bug reports on complex numbers has risen a lot
> lately, and I never get them for the C compiler. This means that nobody uses
> complex numbers in C, but they do in D. Interesting!
> 
> 3) This incorporates a new 'header' generator capability, written by Dave
> Fladebo. I goofed it up merging it in, so it is disabled at the moment (just
> the source for it is included). I hope to get it working by the next update.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 

On WinXP SP2, DMD 0.141 says

  Error: unrecognized switch '-Hdheaders'

and

  Error: unrecognized switch '-Hfheaders'

NOTE: these are listed as options on the help screen output from DMD.exe invoked without any arguments.  Also, the -cov switch is missing from that screen.

I have no idea what code coverage is, but the header file generation code is pretty freakin' cool (if I can get it to work?)!  Way to go Walter.

James Dunne wrote:
> Walter Bright wrote:
> 
>> Some things of note:
>>
>> 1) This includes a new code coverage analyzer for dmd (I think gcov should
>> work for gdc users). I've been wanting to add this for 20 years, I finally
>> realized it was a piece of cake. Took me 3 hours to write, 3 hours to tweak.
>> I shoulda done it a long time ago. I can't believe some third party tools to
>> do this cost $800+.
>>
>> 2) The submissions for bug reports on complex numbers has risen a lot
>> lately, and I never get them for the C compiler. This means that nobody uses
>> complex numbers in C, but they do in D. Interesting!
>>
>> 3) This incorporates a new 'header' generator capability, written by Dave
>> Fladebo. I goofed it up merging it in, so it is disabled at the moment (just
>> the source for it is included). I hope to get it working by the next update.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>>
>>
> 
> On WinXP SP2, DMD 0.141 says
> 
>   Error: unrecognized switch '-Hdheaders'
> 
> and
> 
>   Error: unrecognized switch '-Hfheaders'
> 
> NOTE: these are listed as options on the help screen output from DMD.exe invoked without any arguments.  Also, the -cov switch is missing from that screen.
> 
> I have no idea what code coverage is, but the header file generation code is pretty freakin' cool (if I can get it to work?)!  Way to go Walter.

After looking at code in dmd/src/mars.c ...

Did you forget to #define _DH ? lol.  or perhaps it was wrong exe copied?

James Dunne wrote:
> I have no idea what code coverage is, but the header file generation code is pretty freakin' cool (if I can get it to work?)!  Way to go Walter.

*goes to read code_coverage.html*

=-O.

OMG! OMG!  Code coverage rocks!  Such a simple concept and I never thought to do it!  >:o  Man, I think you've made us all feel a bit dumber today Walter! :)  (well at least I do, I can't speak for everyone)  Friggin' brilliant!  This will help so much in debugging, especially from a DLL context.

Now if only WinDbg would get symbols from a D EXE/DLL, my life would be complete. =P

How about an alternative, easier-to-parse output format for the .lst files?  Say, something like CSV (line number comma execution count), or if overkill is really necessary, XML.  I still like the original .lst; it's nice for humans to look at, but perhaps not as nice for programs.

I'm not sure if you realized you quoted the point where Walter explains why they are not working. see 3).
My appologies if I'm the one being thick-headed ;)

Chris

> James Dunne wrote:
> 
>> Walter Bright wrote:
>> 
>>> Some things of note:
>>> 
>>> 1) This includes a new code coverage analyzer for dmd (I think gcov
>>> should
>>> work for gdc users). I've been wanting to add this for 20 years, I
>>> finally
>>> realized it was a piece of cake. Took me 3 hours to write, 3 hours
>>> to
>>> tweak.
>>> I shoulda done it a long time ago. I can't believe some third party
>>> tools to
>>> do this cost $800+.
>>> 2) The submissions for bug reports on complex numbers has risen a
>>> lot
>>> lately, and I never get them for the C compiler. This means that
>>> nobody uses
>>> complex numbers in C, but they do in D. Interesting!
>>> 3) This incorporates a new 'header' generator capability, written by
>>> Dave
>>> Fladebo. I goofed it up merging it in, so it is disabled at the
>>> moment
>>> (just
>>> the source for it is included). I hope to get it working by the next
>>> update.
>>> http://www.digitalmars.com/d/changelog.html
>>> 
>> On WinXP SP2, DMD 0.141 says
>> 
>> Error: unrecognized switch '-Hdheaders'
>> 
>> and
>> 
>> Error: unrecognized switch '-Hfheaders'
>> 
>> NOTE: these are listed as options on the help screen output from
>> DMD.exe invoked without any arguments.  Also, the -cov switch is
>> missing from that screen.
>> 
>> I have no idea what code coverage is, but the header file generation
>> code is pretty freakin' cool (if I can get it to work?)!  Way to go
>> Walter.
>> 
> After looking at code in dmd/src/mars.c ...
> 
> Did you forget to #define _DH ? lol.  or perhaps it was wrong exe
> copied?
> 

Don Clugston wrote:
> John Reimer wrote:
>> Okay, I've tried the .mangleof property:
>>> int funcA()
>>> {
>>> }
>>> void main()
>>> {
>>>     writefln( funcA.mangleof );
>>> }
>>
> 
>> OUTPUT:
>>
>> C4test1A
>> C4test1A
>> l
>> i
>>
>> So I see that functions still aren't really supported, since the mangled output just returns the return type. It would be fairly useful if we could get the actual mangled name of the whole function somehow.
> 
> It works for function pointers. So you can say:
> writefln((&funcA).mangleof)
> and get:
> PFZi.
> 
> AWESOME!!
> I think in your example, funcA was evaluated as a property, hence it's an int. Looks like DMD is correct.

Yeah... I figured that out, and it's a great feature.  But I guess I'm just expecting it to do more than what it can do.  Being able to access the function name is still critical to me.  Why can't I get that in any sort of way?

I was really hoping I could outdo the C preprocessor with D templates in this regard.  I'm trying to convert a C macro to D:

> #define REGISTER_AS_REMOTE_PROCEDURE_CALL(Object, functionName) (Object)->Register((#functionName),(functionName))

If I can't get the symbol name converted to a string at compile time... all is lost and D is still limited.

Oh well... I must be getting spoiled with these new features.  It makes me want more! :-P

-JJR

In article <dn0i6d$2pgk$1@digitaldaemon.com>, Walter Bright says...
>
>Some things of note:
>
>1) This includes a new code coverage analyzer for dmd (I think gcov should work for gdc users). I've been wanting to add this for 20 years, I finally realized it was a piece of cake. Took me 3 hours to write, 3 hours to tweak. I shoulda done it a long time ago. I can't believe some third party tools to do this cost $800+.
>
>2) The submissions for bug reports on complex numbers has risen a lot lately, and I never get them for the C compiler. This means that nobody uses complex numbers in C, but they do in D. Interesting!
>
>3) This incorporates a new 'header' generator capability, written by Dave Fladebo. I goofed it up merging it in, so it is disabled at the moment (just the source for it is included). I hope to get it working by the next update.
>
>http://www.digitalmars.com/d/changelog.html
>
>
>

What a miracle! During the weekend I was thinking about writinq one program, considering to use Java or D. Because I like D it was big temptation to use it, but also I know Java quite well and know few useful tools, e.g. Cobertura http://cobertura.sourceforge.net/ which is Java code coverage tool. Because better tools available for serious testing on Java platform I almost started in Java. And today we have code coverage in D!

Working! Included directly in the compiler. Very usable and useful!

Excellent job, Walter!

Thank you very much!

Wow Thanks Walter

I got so happy about it that i added it on digg.com

http://digg.com/programming/DMD_0.141_release

John Reimer says...
>
>Don Clugston wrote:
>> John Reimer wrote:
>>> Okay, I've tried the .mangleof property:
>>>> int funcA()
>>>> {
>>>> }
>>>> void main()
>>>> {
>>>>     writefln( funcA.mangleof );
>>>> }
>>>
>> 
>>> OUTPUT:
>>>
>>> C4test1A
>>> C4test1A
>>> l
>>> i
>>>
>>> So I see that functions still aren't really supported, since the mangled output just returns the return type. It would be fairly useful if we could get the actual mangled name of the whole function somehow.
>> 
>> It works for function pointers. So you can say:
>> writefln((&funcA).mangleof)
>> and get:
>> PFZi.
>> 
>> AWESOME!!
>> I think in your example, funcA was evaluated as a property, hence it's
>> an int. Looks like DMD is correct.
>
>Yeah... I figured that out, and it's a great feature.  But I guess I'm just expecting it to do more than what it can do.  Being able to access the function name is still critical to me.  Why can't I get that in any sort of way?
>
>I was really hoping I could outdo the C preprocessor with D templates in this regard.  I'm trying to convert a C macro to D:
>
>> #define REGISTER_AS_REMOTE_PROCEDURE_CALL(Object, functionName) (Object)->Register((#functionName),(functionName))
>
>If I can't get the symbol name converted to a string at compile time... all is lost and D is still limited.
>
>Oh well... I must be getting spoiled with these new features.  It makes me want more! :-P
>
>-JJR

Hey, don't feel bad.  You're just following society's motto: "Gimme, gimme, gimme, gimme!" :-)

Thanks Walter.  This is another great release.  Woowoowoowoooo!

josé

jicman wrote:

> 
> Hey, don't feel bad.  You're just following society's motto: "Gimme, gimme,
> gimme, gimme!" :-)
> 
> Thanks Walter.  This is another great release.  Woowoowoowoooo!
> 
> josé
> 
> 
> 

LOL! Yeah... that's about right!  I'm certainly thankful for all Walter's done, nonetheless.

-JJR

I think this is related to a bug that still exists from .140.

(http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5671)

The essence of the problem is that DMD can't tell the argument list of a function from just the name.

example:

int fn(int);
int fn(char);
void fn(void);

// what type is fn?

auto fnp = &fn;

// what type is fnp and what does it point to



In article <dn0smb$763$1@digitaldaemon.com>, John Reimer says...
>
>Okay, I've tried the .mangleof property:
>
> > module test;
> >
> > import std.stdio;
> >
>> int funcA()
>> {
>> }
>> 
>> class A
>> {
>> }
> >
>> void main()
>> {
>> 
>> 	A a = new A;
>>
>> 	alias long B;
>> 
>> 	writefln( A.mangleof );
>>	writefln( a.mangleof );
>> 	writefln( B.mangleof );
>> 	writefln( funcA.mangleof );
>> }
>
>
>OUTPUT:
>
>C4test1A
>C4test1A
>l
>i
>
>So I see that functions still aren't really supported, since the mangled output just returns the return type. It would be fairly useful if we could get the actual mangled name of the whole function somehow.
>
>-JJR