hi EC (and Don), Again I'm teaching at the time of the phone-in today so can't make it, sorry. I'll try here to reply to some of the queries re. closing children of 1702, and 958: [Don] > > 516 ___ Yes __x_ No > > http://www.eda.org/svdb/bug_view_page.php?bug_id=000516 > First line of description in 1702: "This issue comes to group > together the queue syntax issues 412, 517-521, 801:" > 516 is on arrays and is not directly related to queues as > discussed in 1702. Indeed. When I was first working on 1702 it also tried to address some of these array issues. I then exported the problem to Mike Burns since his 1447 proposal was more directly relevant. So, to this and a few other similar comments from others, I would say: agreed that these are no longer addressed by 1702, but they *are* addressed by 1447. Since that's very much "in hand", I would have thought that it would make sense to close the older items anyway, as being subsumed in 1447. [Don] > > 522 ___ Yes _x__ No > > http://www.eda.org/svdb/bug_view_page.php?bug_id=000522 > Jonathan - is 522 also covered in 1702? It is not listed as > one of the > items in the description. It is possible that it is > indirectly covered > by all the other items listed, but I just want to check with > you first. > If it is, I will change my vote to yes. I would say "yes"; I thought I had included it in the list but obviously it slipped my net - sorry. [Don] > > 974 ___ Yes _x__ No > > http://www.eda.org/svdb/bug_view_page.php?bug_id=000974 > > > First line of description in 1702: "This issue comes to group > together the queue syntax issues 412, 517-521, 801:" > 974 is on arrays and is not directly related to queues as > discussed in 1702. I *think* it is; 1702 makes the unpacked-concat syntax equally applicable to any unpacked array (except associative). Also, 1447 generalises the ability to copy any non-associative unpacked array to any other. Mike B.: The comments in the example code of 7.11.1 "Queue operators" should be changed to not explain the operations in terms of append, prepend, insert and delete since these operations have different semantics w.r.t. outdating of references. Agreed; that was an oversight. Can we live with it as an erratum, since there are other definitive statements now that cover the situation? Neil: I reviewed the 958-2.pdf of Dec 14th Note that on page 2 of the proposal there is the following sentence fragment shown in black text, which is not part of the current LRM. I would like to see this removed from the proposal. "If any of these functions is called with arguments (v, n) where v denotes some array variable and n is a dimension number greater than 1," My apologies, that's a copy/paste error (similar text appears in blue further down the page). However, please note that the vote is on proposal 958-1a.pdf; the changes in version 2 were to answer Mike Burns's concerns about non-unique dimensions. I'll make the correction to version 2 later today. THanks -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Dec 17 06:17:15 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 17 2007 - 06:17:55 PST