"James Dunne" <james.jdunne@gmail.com> wrote in message news:dn255d$203n$1@digitaldaemon.com...
> OMG! OMG!  Code coverage rocks!  Such a simple concept and I never thought to do it!  >:o

I first saw it done in the mid 80's and have been smitten ever since. I *finally* got around to implementing it.

>  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

The windbg.exe from the Digital Mars CD will get it.

> 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.

To parse it, look at std/cover.d. It has a parser for it <g>.

"Knud Sørensen" <12tkvvb02@sneakemail.com> wrote in message news:pan.2005.12.05.21.31.54.211262@sneakemail.com...
> Wow Thanks Walter
>
> I got so happy about it that i added it on digg.com
>
> http://digg.com/programming/DMD_0.141_release

Ok, everyone, go and 'digg' it so it will appear on the front page!

"Dave" <Dave_member@pathlink.com> wrote in message news:dn30a9$2sct$1@digitaldaemon.com...
> 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+.
> >
>
> Wow, this is very cool!
>
> I think mention of this should be added to
>
> http://digitalmars.com/d/comparison.html

Weeelll, I wanted to, but it isn't really a language feature, it's a dmd implementation feature. I expect that the gdc version will instead work with gcov.

>
> and
>
> http://digitalmars.com/d/overview.html
>
>

"clayasaurus" <clayasaurus@gmail.com> wrote in message news:dn30oc$2sl5$2@digitaldaemon.com...
> Is this a compiler specific feature, or is it part of the language?

Compiler specific.

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+.

Wow!
(And it doesn't seem to have increased the size of dmd.exe by much. Is that the smallest ever exe size for a code coverage tool? :-) )

> 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!

I bet that applies to nans, infinities, and 80-bit reals, as well. I think it's the inverse of "give a dog a bad name, and hang it": they are so accessable, that you look for opportunities to use them.

BTW, any chance of getting those implicit conversions real->creal and ireal->creal removed? I have most of the complex functions almost ready to go, once the implicit conversions are gone they can be folded in, and we'll be close to supporting all of the C99 math functions.

"Don Clugston" <dac@nospam.com.au> wrote in message news:dn3nua$gsv$1@digitaldaemon.com...
> 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+.
>
> Wow!
> (And it doesn't seem to have increased the size of dmd.exe by much. Is
> that the smallest ever exe size for a code coverage tool? :-) )

It's about 25 lines of code <g>. The problem with 3rd party tools, is that to instrument the source, they have to build in a full compiler front end. Then you have to come up with some horrible hack to feed the real compiler the altered source code. The actual code coverage implementation work is 0.001% of the effort.

I don't know how gcov is implemented, but it seems excessively complicated. For one thing, for each source file analyzed, it creates 3 extra files in addition to the report file. What's up with that?

> BTW, any chance of getting those implicit conversions real->creal and ireal->creal removed? I have most of the complex functions almost ready to go, once the implicit conversions are gone they can be folded in, and we'll be close to supporting all of the C99 math functions.

I guess I should work on that <g>.

"Walter Bright" <newshound@digitalmars.com> wrote

> I guess I should work on that <g>.

I don't suppose you could whack this one too, while you're at it? :-)

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5641

Walter Bright wrote:
> "James Dunne" <james.jdunne@gmail.com> wrote in message
> news:dn255d$203n$1@digitaldaemon.com...
> 
>>OMG! OMG!  Code coverage rocks!  Such a simple concept and I never
>>thought to do it!  >:o
> 
> 
> I first saw it done in the mid 80's and have been smitten ever since. I
> *finally* got around to implementing it.
> 
> 
>> 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
> 
> 
> The windbg.exe from the Digital Mars CD will get it.
> 
> 
>>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.
> 
> 
> To parse it, look at std/cover.d. It has a parser for it <g>.
> 
> 

As I keep telling others... I really should produce brain-waves before sound-waves.  (Proverbial sound waves in this case, I guess)

Also it's not that hard to parse... just find the first | on the line... it could also be as simple as fixed record sizes and an atoi call.

On Tue, 06 Dec 2005 23:01:51 -0600, James Dunne wrote:

> it could also be as simple as fixed record sizes and an atoi call.

Not really, as I ran a test that did over a billion hits and that shifted the "|" to the right.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
7/12/2005 4:10:02 PM

On Wed, 07 Dec 2005 00:01:51 -0500, James Dunne <james.jdunne@gmail.com> wrote:

>>> 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.
>>   To parse it, look at std/cover.d. It has a parser for it <g>.
>>
>
> As I keep telling others... I really should produce brain-waves before sound-waves.  (Proverbial sound waves in this case, I guess)
>
> Also it's not that hard to parse... just find the first | on the line... it could also be as simple as fixed record sizes and an atoi call.

If the number is large it'll push the | over more columns.
One thing strange about the .lst file is 0 is the only number padded with 0s. Kind of makes it harder to skim the file looking for bigger numbers, I'll get thrown off seeing a number with many digits yet is 0.