From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ff949d1e0d505dfc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-03-13 06:56:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Using Grace.Lists.Unbounded in WindowsXP/GNAT3.15p Date: 13 Mar 2003 09:51:12 -0500 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3e705a78$1@news.wineasy.se> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1047567904 8489 128.183.235.92 (13 Mar 2003 15:05:04 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 13 Mar 2003 15:05:04 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:35290 Date: 2003-03-13T15:05:04+00:00 List-Id: "Frank" writes: > Hi! > > Using WindowsXP/GNAT3.15p/Grace.Lists "1.1". > > See source code and execution-dump at the end. > > 1) > In this example I add a number of nodes to a list, and traverse them > successfully to > print their contence. > > 2) > I traverse the list until the second node. > Then I try to remove the second Node. > The library now throws me a CONSTRAINT_ERROR. > > > Where am I mistaking? I'll look at this in detail later. But I suspect the problem is a design flaw in the current example implementation of Grace.Lists.Unbounded. Try declaring "Allowed_Nodes" at library level, rather than in a procedure; I think the "access check failed" is not a null access but a "nesting level" access failure. When I implemented a draft version of Grace.Lists.Unbounded, I had to add an extra layer of indirection to avoid this problem. The current example implementation does not do that. > The big picture(but not fully coded in this example): > What I want to achieve is to be able to traverse a list, and based on > information in the > node, decide to remove it from the current position in the list and reinsert > it at the end. > This is done to postpone the calculation of the Node until all other Nodes > have been calculated. It is reasonable to expect Grace.Lists to handle this. Until a better implementation of Grace is available (care to contribute one? :), you might try SAL or Charles or Booch or ... -- -- Stephe