Re: [sv-cc] RE: [sv-champions] Email vote - Ending December 13th

The definition from the "Computing Dictionary" is so deadly accurate that
it made me chuckle.

Jim

-----------------------------------------------------------------------
Jim Vellenga (jvellenga@alum.mit.edu)
Innovative production-oriented Software Engineer for large-scale
scientific, technical, and system software with high algorithmic
complexity. Very strong technical skills, team-based development
skills, and communication skills. Quick learner; constantly brings
new challenges to successful completion.
781-646-6778 --- http://www.jimvellenga.com
-----------------------------------------------------------------------

On 1/9/2011 6:26 AM, Bresticker, Shalom wrote:
>
> The 2009 IEEE Standards Style Manual says,
>
> "The word /should /is used … (in the negative form) a certain course
> of action is deprecated but not prohibited (/should /equals /is
> recommended that/)."
>
> Dictionary.com shows the following definition(s) of "deprecated":
>
> *dep**·**re**·**cate*
>
> */–verb (used with object), /*-cat·ed, -cat·ing.
>
> *1. *to express earnest disapproval of.
>
> *2. *to urge reasons against; protest against (a scheme, purpose, etc.).
>
> *3. *to depreciate; belittle.
>
> */—Synonyms /*
> 1. condemn, denounce, disparage. See decry.
> <http://dictionary.reference.com/browse/decry>
>
> */—Usage note /*
> An early and still the most current sense of deprecate is “to express
> disapproval of.”
>
> Computing Dictionary
>
> *deprecated definition *
>
>
> Said of a program or feature that is considered obsolescent and in the
> process of being phased out, usually in favour of a specified
> replacement. Deprecated features can, unfortunately, linger on for
> many years. This term appears with distressing frequency in standards
> documents when the committees writing the documents realise that large
> amounts of extant (and presumably happily working) code depend on the
> feature(s) that have passed out of favour.
>
> Shalom
>
> *From:*Rich, Dave [mailto:Dave_Rich@mentor.com]
> *Sent:* Thursday, January 06, 2011 7:52 PM
> *To:* Karen Pieper; Jim Vellenga; Bresticker, Shalom; Steven Dovich;
> Chuck Berking
> *Cc:* sv-cc@eda.org; Charlie Dawson
> *Subject:* RE: [sv-cc] RE: [sv-champions] Email vote - Ending December
> 13th
>
> I think Karen meant PLI, not DPI.
>
> My definition:
>
> "to deprecate" is a deliberate removal of a concept, terminology or
> feature that had been described in a previous version of the standard
> from the current standard. A reference to a deprecated feature may be
> included in an informative section of the current standard as being
> deprecated.
>
> Note that you cannot “deprecate” something from a previous version of
> a standard, and an implementation can still be in compliance with the
> current standard even though it supports deprecated features. (as long
> as there is no conflict with newer features).
>
> A standard is not a list of recommendations – it is a list of
> requirements that are needed to achieve interoperability between
> producers and consumers .
>
> Dave Rich
> Verification Technologist
> Mentor Graphics Corporation
> *New Office Number: 510-354-7439*
>
> *Twitter-32* <http://www.twitter.com/dave_59>*Technorati-32*
> <http://go.mentor.com/drich>
>
> *From:*owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] *On Behalf Of
> *Karen Pieper
> *Sent:* Thursday, January 06, 2011 8:44 AM
> *To:* Jim Vellenga; Bresticker, Shalom; Steven Dovich; Chuck Berking
> *Cc:* sv-cc@eda.org; Charlie Dawson
> *Subject:* Re: [sv-cc] RE: [sv-champions] Email vote - Ending December
> 13th
>
> I thought that deprecated meant "no longer recommended," and likely to
> be removed in the future. We deprecated the DPI and then eventually
> removed it, correct? If so, I agree that we need consistent use
> through the LRM.
>
> Thanks,
>
> Karen
>
> ------------------------------------------------------------------------
>
> *From:*Jim Vellenga <vellenga@cadence.com>
> *To:* "Bresticker, Shalom" <shalom.bresticker@intel.com>; Steven
> Dovich <dovich@cadence.com>; Chuck Berking <berking@cadence.com>
> *Cc:* "sv-cc@eda.org" <sv-cc@eda.org>; Charlie Dawson <chas@cadence.com>
> *Sent:* Thu, January 6, 2011 8:18:12 AM
> *Subject:* RE: [sv-cc] RE: [sv-champions] Email vote - Ending December
> 13th
>
> Hmm, yes. 2651 points out that we use “deprecated” to mean either
> “not recommended” or
>
> “no longer recommended” or even “no longer part of the standard.” And
> our usage is
>
> not consistent.
>
> It would be nice to clear that up, but that is not really the province
> of any one committee,
>
> is it? Should we ask SV-BC for guidance?
>
> Jim Vellenga
>
> *From:*owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] *On Behalf Of
> *Bresticker, Shalom
> *Sent:* Thursday, 6 Jan 2011 11:03 AM
> *To:* Steven Dovich; Chuck Berking
> *Cc:* sv-cc@eda.org; Charlie Dawson
> *Subject:* RE: [sv-cc] RE: [sv-champions] Email vote - Ending December
> 13th
>
> See also Mantis 2651.
>
> Shalom
>
> *From:*Steven J. Dovich [mailto:dovich@cadence.com]
> *Sent:* Thursday, January 06, 2011 6:01 PM
> *To:* Chuck Berking
> *Cc:* Bresticker, Shalom; sv-cc@eda.org; Charlie Dawson
> *Subject:* Re: [sv-cc] RE: [sv-champions] Email vote - Ending December
> 13th
>
> Shalom is right, deprecations should be identified in Annex C. The
> PLI TF and ACC deprecations head that list, and the assorted VPI items
> should be added there for consistency.
>
>
>
> *Steven J. Dovich*| Sr Member of Consulting Staff, Advanced
> Verification Systems | Cadence
>
> P: 978.262.6413 M: 978.494.0519 www.cadence.com <http://www.cadence.com>
>
>
>
>
> On 1/6/2011 10:55 AM, Chuck Berking wrote:
>
> As I mentioned, I did see and fix this error in my latest proposal replacement:
>
> #define vpiInterfaceDeclvpiVirtualInterfaceVar /* interface decl deprecated */"
>
> Apparently there is a bug in Framemaker that does not map tab characters to at least an intervening space when generating .pdf files (it appears OK in my original Frame text).
>
> Re. #2:
>
> I see no precedent for noting VPI or PLI #defined symbol deprecation in C.2. I.e. there is a handful of these in VPI that are not mentioned here (e.g. vpiArray property). [ SV-CCers- should they be- or is this overkill ? ]
>
> - CB
>
>
> Chuck Berking | Member of Consulting Staff | Cadence
> P: 978.262.6522 M: 603.253.9130www.cadence.com <http://www.cadence.com>
>
>
>
>
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Thursday, January 06, 2011 3:50 AM
> To: Chuck Berking
> Cc:sv-cc@eda.org <mailto:sv-cc@eda.org>; Charlie Dawson
> Subject: RE: [sv-champions] Email vote - Ending December 13th
>
> Two more points on the new proposal:
>
> 1. In the change to M.2:
>
>
> "REPLACE:
> #define vpiInterfaceDecl 728
> WITH:
> #define vpiInterfaceDeclvpiVirtualInterfaceVar /* interface decl deprecated */"
>
> There should be a space between "vpiInterfaceDecl" and "vpiVirtualInterfaceVar".
>
>
> 2. If vpiInterfaceDecl is being deprecated, a new subclause describing it should probably be added to C.2.
>
>
> Thanks,
> Shalom
> ---------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.