[m-rev.] for post-commit review: move two deep prof cmds to use reports

[Paul Bone]

On Mon, Aug 04, 2008 at 06:46:46PM +1000, Zoltan Somogyi wrote:
> For post-commit review by Paul.
> 
> Zoltan.
> 
> Use reports to handle the proc_static and proc_dynamic queries.
> 
> deep_profiler/report.m:
> 	Add the two new report types.
> 
> 	Change the report type to give each query its own answer, without
> 	needing to use the report_message for reporting errors. Also, group
> 	each kind of report into a single data structure that can be
> 	manipulated independently of the other kinds of answers (like I did
> 	some time ago for items in the compiler.)
> 
> deep_profiler/create_report.m:
> 	Add the code for the two new report types.
> 
> 	Conform to the other changes in report.m.
> 
> 	Inline some unnecessary intermediate predicates.
> 
> deep_profiler/display.m:
> deep_profiler/html_format.m:
> 	Rename one table_class that is now used not just by the menu command.
> 
> deep_profiler/display_report.m:
> 	Add the code to handle the two new report types.
> 
> 	Refactor some existing code to allow it to called by the new code.
> 
> 	Conform to the other changes in report.m.
> 
> 	Fix several predicate names that would have become misleading as soon
> 	as we added new kinds of reports. The fix is to give them the prefix
> 	"top_procs_", since they all generate parts of top_procs pages.
> 
> deep_profiler/query.m:
> 	Use the new method to handle the two query types.
> 
> Index: display.m
> ===================================================================
> RCS file: /home/mercury/mercury1/repository/mercury/deep_profiler/display.m,v
> retrieving revision 1.2
> diff -u -b -r1.2 display.m
> --- display.m	4 Aug 2008 03:17:45 -0000	1.2
> +++ display.m	4 Aug 2008 05:14:03 -0000
> @@ -110,7 +110,7 @@
>      ;       table_empty_cell.
>  
>  :- type table_class
> -    --->    table_class_menu
> +    --->    table_class_plain
>      ;       table_class_top_procs.
>  
>  :- type table_col_class

My intention with these is that one of them can be created for each
type of table.  Then style sheets (when using HTML) can be used to alter
how they are displayed.  This places the flexability in the style
sheets, and the presentation is defined in one place.  So I'd prefer
creating a class for each type of table.  I don't think this will cause
a problem, so I'm not concerned about it. 

The rest of the diff is fine.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20080811/998670eb/attachment.sig>