[M3devel] release engineering 5.8: trac issue 1005 (open array initializers)

[Jay K]

There is another vague philosophical point I should maybe explore/teach here.

The vaguer I make it, the more irrefutable it is. :)

 

 

"Logging has a place".

And debuggers do too.

I have seen countless examples where

  logging exists, in some "reasonable" volume 

  bugs are often largly or completely diagnosed from a log alone 

  getting a debugger to the right point would be quite difficult 

 

 

Logging is always "in situ" and often enabled proactively -- all the time.

  That is, no need to figure out exactly which command line to run,

   where to insert the debugger command, no need to try to keep temp files, etc.

 

Very good example: Our Hudson/Tinderbox jobs.

 

 

Callstacks upon assertion failures are a form of logging.

  Would be even better if they showed the local variables of every frame.

  Maybe expanding pointers one level.

 

I often make the prints subject to whether or not an upcoming assertion is going to fail.

 

 

There are counterpoints, of course. Logging wastes time and space.

It makes the source code bigger, the object code bigger. When it is

enabled it slows down runtime and usually "wastes" space to store the logs.

  Except when they end up used. The vast majority of logged date goes

  unread.

 

 

You can't log everything. Good debuggers show things at a much lower level

than most logging. (Except gdb on Debian 4.0 can't do anything, and

CodeView-based debuggers against Modula-3 show very little...)

 

 

I'll have to try m3gdb again, on Debian 5.0. And generate CodeView information.

The CodeView stuff I consider pretty high priority.

I've done a fair amount of research and am better prepared to implement

it than previously. A C generating backend has about

the same value and more.

 

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers)
Date: Sat, 17 Apr 2010 01:48:44 +0000



I haven't found a viable debugger for Modula-3.
Could be better now that I'm on Debian 5.0 though.
gdb is now good, eveything is void*.
VisualStudio/cdb/windbb are no good due to lack of CodeView information.
I'll try m3gdb again, since upgrading to Debian 5.0.
I'm keen on generating good CodeView information because of this.
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Fri, 16 Apr 2010 10:46:41 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers)

PS  I don't use printouts when debugging.  I use a debugger.  There is never a need to put verbose debugging printouts into the source tree.  They just litter the code. 




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On 16 Apr 2010, at 05:58, Jay K wrote:

I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails.
 
 - Jay
 
> Date: Fri, 16 Apr 2010 11:38:14 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers)
> 
> I'm currently reviewing the open issues again, and came across
> 
> https://projects.elego.de/cm3/ticket/1005
> 
> Not sure if I've asked before, but do we need to solve this for this
> release? The GC error seems strange:
> 
> --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200
> +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 
> 08:17:17.000000000 +0200
> @@ -0,0 +1,13 @@
> +o is 0x348
> +init_pc is 0x0
> +bias is 0x5c8
> +Target.Address.align is 0x40
> +Target.Byte is 0x8
> +
> +
> +***
> +*** runtime error:
> +*** <*ASSERT*> failed.
> +*** file "../src/misc/CG.m3", line 1077
> +***
> +
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100417/c7648fad/attachment-0002.html>