Then we are closed!
John A
-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/08/2010 03:31PM
Cc: "alan.fitch@doulos.com" <alan.fitch@doulos.com>, "owner-systemc-p1666-technical@eda.org"	<owner-systemc-p1666-technical@eda.org>, P1666 Technical WG	<systemc-p1666-technical@eda.org>
Subject: RE: Verbosity Control
    
John, 
  
Yes, your interpretation of report() setting verbosity to  200 for SC_INFO messages and checking against max is exactly what I proposed.  Sorry for the confusion in the wording. 
  
-Bishnupriya 
    
      From: john.aynsley@doulos.com    [mailto:john.aynsley@doulos.com] 
Sent: Wednesday, December 08, 2010    8:19 PM
To: Bishnupriya Bhattacharya
Cc:    alan.fitch@doulos.com; john.aynsley@doulos.com;    owner-systemc-p1666-technical@eda.org; P1666 Technical WG
Subject:    RE: Verbosity Control
   
Bisnupriya,
Re SC_IGNORE_VERBOSITY, I agree. Let's remove    it.
Re. sc_gen_report, I agree. Let's not add it.
Re default    verbosity, I agree with the principle, and I think I understand what you are    suggesting, i.e.
#define SC_REPORT_INFO( msg_type , msg )    \
    sc_report_handler::report( SC_INFO , msg_type , msg ,    __FILE__ , __LINE__ )
where report internally sets verbosity = 200 for    SC_INFO reports before checking against max verbosity? If that is what you    mean, then yes, I fully agree! (I got confused when you said that the    sc_report_handler::report() signature    should assign the default verbosity value.)
John A
-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote:    -----   
   To:      "alan.fitch@doulos.com" <alan.fitch@doulos.com>
From: Bishnupriya      Bhattacharya <bpriya@cadence.com>
Date: 12/08/2010 10:11AM
Cc:      "john.aynsley@doulos.com" <john.aynsley@doulos.com>,      "owner-systemc-p1666-technical@eda.org"      <owner-systemc-p1666-technical@eda.org>,      "systemc-p1666-technical@eda.org"      <systemc-p1666-technical@eda.org>
Subject: RE: Verbosity      Control
          
Alan, thanks for the rationale.     
      
John, given Alan's comments below, I would vote not to      include this additional enum because the benefits are not clear. That leaves      us with the remaining 2 opens      
      
- should existing signature of      sc_report_handler::report() assign default verbosity value of 200 to      SC_INFO messages and compare with max verbosity? I strongly feel it      should     
- should sc_core::sc_gen_report() with verbosity      argument be added? I would vote no.     
      
Did I miss anything?     
      
Thanks,     
-Bishnupriya 
            
              From: alan.fitch@doulos.com        [mailto:alan.fitch@doulos.com] 
Sent: Wednesday, December 08,        2010 3:18 PM
To: Bishnupriya Bhattacharya
Cc:        john.aynsley@doulos.com; owner-systemc-p1666-technical@eda.org;        systemc-p1666-technical@eda.org
Subject: RE: Verbosity        Control
       
owner-systemc-p1666-technical@eda.org wrote on        08/12/2010 05:04:06:
<snip> 
> About SC_IGNORE_VERBOSITY = 9999, I'm not sure I understand.        What 
> can users do with this? Define SC_MY_VERBOSITY = 700? How        will he 
> define it? By changing the header file?          
> 
Hi Bishnupriya, 
  the idea is        that if you want to loop through all values of an enumerated type, you        know what the last enumerated value is, i.e. SC_IGNORE_VERBOSITY. Then if        in future you add new values to the enumerated type (e.g. in IEEE        1666-2016! ) your looping code still works. It's just something I've seen        in other tools that use enumerations, so that extra levels can be inserted        and you still know the last enumeration. 
However now I think about it, it doesn't help in this case because        the enumeration values are not separated by 1, but by 100. So you couldn't        easily write a loop to go through all possible enumeration values - and        anyway, when would you want to? 
So        I'm not too worried, it was just an idea. 
regards 
Alan        
  
>        -Bishnupriya 
> From:        john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]        
> Sent: Wednesday, December 08, 2010 8:45 AM
> To:        Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
> Subject:        RE: Verbosity Control
>        Bishupriya,
> 
> See below:
> 
> Also, what do you        think of adding sc_gen_report as proposed by 
> Philipp? I see no        reason to do so right now.
> 
> John A
> 
>        -----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----        
> To: "john.aynsley@doulos.com"        <john.aynsley@doulos.com>
> From: Bishnupriya Bhattacharya        <bpriya@cadence.com>
> Date: 12/07/2010 05:41PM
> Cc:        Bishnupriya Bhattacharya <bpriya@cadence.com>
> Subject: RE:        Verbosity Control
>        John, 
>          
>   
> 1)        The enum SC_IGNORE_VERBOSITY = 9999 was proposed by Alan for the 
>        case where we have only one report() signature with an optional 
>        verbosity argument at the end. We are not going with that        signature.
> Philip had also not liked this enum. So I don't think        we need this enum. 
> 
> [JA] SEE SEPARATE EMAIL TO        ALAN 
>          
> 2) I agree on your point to not change the        existing macros to supply
> verbosity argument - that can be        misleading. However, I don't like 
> that some SC_INFO messages are        subject to verbosity check and some 
> are not. This is not        consistent. Its better - as per the original 
> proposal - that the        existing report() signature assigns a default 
> verbosity value of        200 to the INFO messages and check these against 
> max verbosity.        Then all INFO messages have a verbosity property - 
> either        explicitly user assigned or an implicit default value, and 
> all        INFO messages are subject to verbosity check. This is nice and 
>        clean and fully backward compatible. ÿ
> 
> [JA]        ÿI'm not sure I understand. Are you saying change the 
>        definitions of the current SC_REPORT_INFO macro to call the 
>        overloaded sc_report_handler::report method with a verbosity, but 
>        leave SC_REPORT_WARNING/ERROR/FATAL unchanged? I would be fine with        that. 
> ÿ        
> 3) ÿAbout the new macro, I like adding        SC_REPORT_INFO_VERB(msg_type,
> msg, verbosity).        
> ÿ 
>        Users will either do 
>        ÿ 
> ÿ        ÿsc_report_handler::report(SC_INFO, "myid", "mymsg", 500, 
>        __FILE__, __LINE__); 
> ÿ        ÿsc_report_handler::report(SC_WARNING, "myid", "msg", __FILE__,        __LINE__); 
> ÿ        
> or 
>        ÿ 
> ÿ        SC_REPORT_INFO_VERB("myid", "mymsg", 500); 
> ÿ SC_REPORT_WARNING("myid", "msg");
> 
> [JA]        Yes, this is how I understood it. 
>        ÿ 
> We should have this        discussion on the reflector also. 
>        ÿ 
> Thanks,        
> -Bishnupriya 
> 
> -- 
> This message has been scanned for viruses        and 
> dangerous content by MailScanner, and is 
> believed to        be clean. 
--        
Alan Fitch
Senior Consultant
Doulos - Developing Design        Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk        * Project Services
Doulos Ltd. Church Hatch, 22 Market Place,        Ringwood, Hampshire, BH24 1AW, UK
Tel: ÿ+ 44 (0)1425 471223 ÿ        ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ        Email: alan.fitch@doulos.com 
Fax: ÿ+44 (0)1425 471573 ÿ        ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ        ÿhttp://www.doulos.com
--------------------------------------------------------------------------------
Doulos        Ltd is registered in England and Wales with company no. 3723454
Its        registered office is 4 Brackley Close, Bournemouth International        Airport,
Christchurch, BH23 6SE, UK. 
This message (and        associated files) may contain information that is confidential,        
proprietary, privileged, or subject to copyright. It is intended        solely for the use
of the individual to whom it is addressed and others        authorised to receive it. If
you have received this email in error,        please notify the sender and delete all
copies. This message may        contain personal views which are not the views of
Doulos, unless        specifically stated.
   
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Dec 8 07:48:45 2010
This archive was generated by hypermail 2.1.8 : Wed Dec 08 2010 - 07:48:46 PST