Strange error

Strange error

[Laurent]

Hi

I have a strange error with my double linked list, more precisely my reverse_print procedure:

...

Content of L2 (Target) after copying L1 (Source)
Huh. . .Top. . .taa. . .Hat. . .Boy. . .Cat. . .Tut. . .Gna. . .

Content of L2 (Target) after copying L1 (Source), reverse print
Gna. . .Tut. . .Cat. . .Boy. . .Hat. . .taa. . .Top. . .Huh. . .

Content of L2 (Target) after deleting it
List is empty

Content of L3
List is empty

inserting 5000 in L3
Content of L3, normal display
5000. . .
Content of L3, reverse display
5000. . .

inserting 123 in L3
Content of L3, normal display
123. . .5000. . .
Content of L3, reverse display
5000. . .123. . .

inserting 4567 in L3
Content of L3, normal display
123. . .4567. . .5000. . .
Content of L3, reverse display
5000. . .123. . . 

[2015-01-22 22:25:49] process terminated successfully, elapsed time: 00.21s

The version to test the reverse print on L2 which is a list of 3 char silly words works as expected.

The version to test it with integers doesn't. Stops after 2 elements even if there are more in the list.

The files are on git.

https://github.com/Chutulu/Chapter-15.git

No idea what is going wrong. The worst is that before it worked. I had put both versions inside one procedure with an additional parameter to decide if normal print or reverse. wasn't happy with the choice thing and decided to make 2 /= procedures.

Thanks

Laurent

Re: Strange error

[Egil H H]

On Thursday, January 22, 2015 at 10:46:10 PM UTC+1, Laurent wrote:
> 
> The version to test it with integers doesn't.
> Stops after 2 elements even if there are more in the list.

Display and Reverse_Display seems to work as expected. 
Your error is in case (4) of Insert_In_Order. 

You modify Temp.all.Next 
and Previous.all.Next

But not Current.all.Previous
and Temp.all.Previous.

So reverse iterating the list (which depends on Previous 
being set) will skip all elements inserted between Head and Tail.


-- 
~egilhh

Re: Strange error

[Laurent]

Quite obvious could have found that myself by thinking/searching a bit more.

How do you professionals prevent such stupid errors? I am just a noob and playing a bit around so it has no impact on anything.

Thanks

Re: Strange error

[Laurent]

@Egil H H
Thanks for correcting the error on git. Wouldn't have been necessary. Just pointing in the right direction already helped a lot. Had simply forgotten to adapt the child package when I added the double linking.

As programming is just a hobby of mine I probably should get used to write a ToDo list or some version/history in the source files. Not sure if that prevents such stupid errors or add this unimplemented pragma thing.

Thanks

Re: Strange error

[Randy Brukardt]

"Laurent" <daemon2@internet.lu> wrote in message 
news:3fa7d4c4-f9fe-4d00-9034-a348802087a9@googlegroups.com...
...
> How do you professionals prevent such stupid errors? I am just a noob and 
> playing
> a bit around so it has no impact on anything.

You don't (or at least, I don't). I seem to write loops that don't loop 
(forgot the P := P.Next) all the time.

Probably the only real difference is that we're used to questioning 
everything: if faced with a Reverse_Print routine not working, we'd be 
quicker to consider that the input might not be correct. (Indeed, I'd 
probably start with that assumption, because the display routine is so 
simple.) But there is no certainty that we'll look in the right place.

That's, of course, one of the reasons we're interested in Ada, because it's 
possible to move more mistakes to compile-time checks. Bugs detected by a 
compile-time check never need to be debugged from results that might be hard 
to reproduce. (And as well, Ada lets us more easily put in runtime checks, 
which prevent problems from lingering.)

                                        Randy.

Re: Strange error

[Bob Duff]

Laurent <daemon2@internet.lu> writes:

> Quite obvious could have found that myself by thinking/searching a bit more.
>
> How do you professionals prevent such stupid errors? I am just a noob and
> playing a bit around so it has no impact on anything.

One way is to use Ada.Containers.Doubly_Linked_Lists.  But that won't
work for you, because you're not trying to use doubly-linked lists,
you're trying to learn how to implement them.  Which is something
programmers should know how to do.

So draw a doubly-linked list on paper, with circles and arrows.
Go through each procedure and "execute" it by hand, erasing the
arrows and drawing new ones.  Take care to execute what you wrote,
not what you meant to write.  Bugs like the one mentioned will
usually become obvious.

- Bob

Re: Strange error

[Bob Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Laurent" <daemon2@internet.lu> wrote in message 
> news:3fa7d4c4-f9fe-4d00-9034-a348802087a9@googlegroups.com...
> ...
>> How do you professionals prevent such stupid errors? I am just a noob and 
>> playing
>> a bit around so it has no impact on anything.
>
> You don't (or at least, I don't). I seem to write loops that don't loop
> (forgot the P := P.Next) all the time.

"don't loop"?  That loops too much.  ;-)

I tend to write the boilerplate first:

    while P /= null loop
        
        P := P.Next;
    end loop;

Then go back and fill in the body of the loop.  So I don't usually
make that particural mistake.  Anyway, I think GNAT will give a warning
about that.

But in Ada 2012, we have iterators, which largely solves the problem.
Put all your eggs in one basket, and if the iterator works, then all
the myriad "for" loops around the code will work.

- Bob

Re: Strange error

[Brad Moore]

On 15-01-23 06:34 PM, Bob Duff wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Laurent" <daemon2@internet.lu> wrote in message
>> news:3fa7d4c4-f9fe-4d00-9034-a348802087a9@googlegroups.com...
>> ...
>>> How do you professionals prevent such stupid errors? I am just a noob and
>>> playing
>>> a bit around so it has no impact on anything.
>>
>> You don't (or at least, I don't). I seem to write loops that don't loop
>> (forgot the P := P.Next) all the time.
>
> "don't loop"?  That loops too much.  ;-)
>
> I tend to write the boilerplate first:
>
>      while P /= null loop
>
>          P := P.Next;
>      end loop;
>
> Then go back and fill in the body of the loop.  So I don't usually
> make that particural mistake.  Anyway, I think GNAT will give a warning
> about that.
>
> But in Ada 2012, we have iterators, which largely solves the problem.
> Put all your eggs in one basket, and if the iterator works, then all
> the myriad "for" loops around the code will work.

Or in Ada 2005, you can use the Iterate primitive of the containers. 
Then you don't need to write that boilerplate either, as it is already 
done for you. Given the choice though, Ada 2012 iterators provides the 
preferred approach.

Brad

Re: Strange error

[Laurent]

On Saturday, January 24, 2015 at 1:47:06 AM UTC+1, Bob Duff wrote:

> So draw a doubly-linked list on paper, with circles and arrows.
> Go through each procedure and "execute" it by hand, erasing the
> arrows and drawing new ones.  Take care to execute what you wrote,
> not what you meant to write.  Bugs like the one mentioned will
> usually become obvious.
> 
> - Bob

Yes that one I know. If I am not able to get it right on a sheet of paper it is of no use to begin coding.
That was one of the first comments in the initiation course to programming I followed. And the guy was/is right.

Laurent

Re: Strange error

[Laurent]

> > But in Ada 2012, we have iterators, which largely solves the problem.
> > Put all your eggs in one basket, and if the iterator works, then all
> > the myriad "for" loops around the code will work.
> 
> Or in Ada 2005, you can use the Iterate primitive of the containers. 
> Then you don't need to write that boilerplate either, as it is already 
> done for you. Given the choice though, Ada 2012 iterators provides the 
> preferred approach.
> 
> Brad

Iterators are next on my todo list which still only exist in my mind. Quite often the cause of my stupid errors.

Laurent

Re: Strange error

[Stephen Leake]

Laurent <daemon2@internet.lu> writes:

> Quite obvious could have found that myself by thinking/searching a bit more.
>
> How do you professionals prevent such stupid errors? I am just a noob
> and playing a bit around so it has no impact on anything.

Write tests _first_.

In this case, write a complete set of tests on what insert and delete
should do to an empty list, a 1 element list, a 2 element list, and a 3
element list (3 stands in for 3 .. huge).

Then implement the list, and make the tests pass.


AdaCore AUnit is a nice testing framework.

-- 
-- Stephe

Re: Strange error

[Randy Brukardt]

"Bob Duff" <bobduff@theworld.com> wrote in message 
news:87iofx9d2r.fsf@adacore.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Laurent" <daemon2@internet.lu> wrote in message
>> news:3fa7d4c4-f9fe-4d00-9034-a348802087a9@googlegroups.com...
>> ...
>>> How do you professionals prevent such stupid errors? I am just a noob 
>>> and
>>> playing
>>> a bit around so it has no impact on anything.
>>
>> You don't (or at least, I don't). I seem to write loops that don't loop
>> (forgot the P := P.Next) all the time.
>
> "don't loop"?  That loops too much.  ;-)

Meant "don't stop looping", obviously.

> I tend to write the boilerplate first:
>
>    while P /= null loop
>
>        P := P.Next;
>    end loop;
>
> Then go back and fill in the body of the loop.  So I don't usually
> make that particural mistake.

I don't make "particural" mistakes, either. ;-)

I sometimes do that, but sometimes I'm so focused on the important stuff 
(the body of the loop) that I forget the structure.

>  Anyway, I think GNAT will give a warning
> about that.

It certainly goves warnings on loops that aren't a problem. :-) I've never 
seen one on a loop that is a problem, but then again, most of my code was 
written using another compiler first, so most of the gross errors have 
already been removed.

> But in Ada 2012, we have iterators, which largely solves the problem.
> Put all your eggs in one basket, and if the iterator works, then all
> the myriad "for" loops around the code will work.

Yeah, but that would mean finding time to implement them in my favorite 
compiler. :-)

                         Randy.