Tree - Recursive print function

Hi There,

I'm working on a tree data structure at the moment and I'm having
trouble with the recursive print function. It seems that the function
simply restarts every time it finishes... Even though it is not a
infinite loop. Hope that you guy's can help me figure out what the
problem is.

You will find my code in the attachment.

Thanks,
Giac0m0.

Attachments:
http://www.ruby-forum.com/attachment/6635/run.rb

···

--
Posted via http://www.ruby-forum.com/.

Why are you adding 'page' as a child of itself?

tree = page
tree.addchild(page2)
tree.addchild(page3)
tree.addchild(page4)
tree.addchild(page5)
tree.addchild(page)

Sam

···

On 29/09/11 14:10, Giacomo C. wrote:

Hi There,

I'm working on a tree data structure at the moment and I'm having
trouble with the recursive print function. It seems that the function
simply restarts every time it finishes... Even though it is not a
infinite loop. Hope that you guy's can help me figure out what the
problem is.

You will find my code in the attachment.

Thanks,
Giac0m0.

Attachments:
http://www.ruby-forum.com/attachment/6635/run.rb

I'm working on a tree data structure at the moment and I'm having
trouble with the recursive print function. It seems that the function
simply restarts every time it finishes... Even though it is not a
infinite loop. Hope that you guy's can help me figure out what the
problem is.

Instead of answering the answer directly I'm going to take a "teach a man to fish" approach. The Ruby community has many proponents of what is known as TDD or Test Driven Development. In essence the approach is to write a test that will fail (missing class, missing file, incorrect functionality), then make that test pass. Then you write another test which will fail and make that pass as well. Each test should focus on a specific piece of functionality.

Why is this important? Consider your situation now. You've written a giant test which attempts to look at the entire class as a whole instead of the individual components. Now you're stuck trying to figure out which of these components has an issue. If the TDD approach had been taken first, you could have easily narrowed down the problematic piece of code and potentially figured out what went wrong on your own.

I recommend taking a look at how TDD works. Here is a basic screencast to get you started:

http://kanemar.com/2006/03/04/screencast-of-test-driven-development-with-ruby-part-1-a-simple-example/

Write some tests for each piece of functionality in your class and see what's not working out.

Regards,
Chris White
Twitter: http://www.twitter.com/cwgem

Are you teaching a man to fish if you tell him "you should stop asking for
fish and start catching fish"?

how about showing him what that looks like?

···

On Wed, Sep 28, 2011 at 8:30 PM, Chris White <cwprogram@live.com> wrote:

> I'm working on a tree data structure at the moment and I'm having
> trouble with the recursive print function. It seems that the function
> simply restarts every time it finishes... Even though it is not a
> infinite loop. Hope that you guy's can help me figure out what the
> problem is.

Instead of answering the answer directly I'm going to take a "teach a man
to fish" approach. The Ruby community has many proponents of what is known
as TDD or Test Driven Development. In essence the approach is to write a
test that will fail (missing class, missing file, incorrect functionality),
then make that test pass. Then you write another test which will fail and
make that pass as well. Each test should focus on a specific piece of
functionality.

Why is this important? Consider your situation now. You've written a giant
test which attempts to look at the entire class as a whole instead of the
individual components. Now you're stuck trying to figure out which of these
components has an issue. If the TDD approach had been taken first, you could
have easily narrowed down the problematic piece of code and potentially
figured out what went wrong on your own.

I recommend taking a look at how TDD works. Here is a basic screencast to
get you started:

http://kanemar.com/2006/03/04/screencast-of-test-driven-development-with-ruby-part-1-a-simple-example/

Write some tests for each piece of functionality in your class and see
what's not working out.

Regards,
Chris White
Twitter: http://www.twitter.com/cwgem

Sam Duncan wrote in post #1024169:

Why are you adding 'page' as a child of itself?

tree = page
tree.addchild(page2)
tree.addchild(page3)
tree.addchild(page4)
tree.addchild(page5)
tree.addchild(page)

Sam

Hmm... this is a bit painful/embarrassing... Thanks for the comment that
should have been very obvious to me haha. Thanks!

And Chris, thanks for your comment and I'll have a look into it.

Giac0m0.

···

--
Posted via http://www.ruby-forum.com/\.

TDD is great, but Pair Programming might also have caught this. Note
how it wasn't a test but a human noting "hmm, that's odd". (IMHO the
combo of the two is a recipe for awesome-sauce.)

-Dave

···

On Wed, Sep 28, 2011 at 21:30, Chris White <cwprogram@live.com> wrote:

The Ruby community has many proponents of
what is known as TDD or Test Driven Development.

--
LOOKING FOR WORK, preferably Ruby on Rails, in NoVa/DC; see main web site.
Main Web Site: davearonson.com
Programming Blog: codosaur.us
Excellence Blog: dare2xl.com

> I recommend taking a look at how TDD works. Here is a basic screencast to
> get you started:
>
>
> http://kanemar.com/2006/03/04/screencast-of-test-driven-development-with-ruby-part-1-a-simple-example/

Are you teaching a man to fish if you tell him "you should stop asking for
fish and start catching fish"?

how about showing him what that looks like?

Perhaps "teach a man to fish" was a bad analogy. Oh well, thus is the mystery of meaning in words. The link to the screencast was meant to provide a starting point to the process of TDD. Yes, I could have pasted an example of TDD using the given code, but I feel that knowledge is easier to retain knowledge when a majority of the work is done by the person doing the learning. If this person produces some test code and is in need of help in getting further along, I will be more than happy to provide assistance. However I digress, as I fear I am starting to derail the original topic at hand.

Regards,
Chris White
http://www.twitter.com/cwgem

No worries bro. Sometimes /all/ you need is a fresh set of eyes =]

Sam

···

On 29/09/11 14:50, Giacomo C. wrote:

Sam Duncan wrote in post #1024169:

Why are you adding 'page' as a child of itself?

tree = page
tree.addchild(page2)
tree.addchild(page3)
tree.addchild(page4)
tree.addchild(page5)
tree.addchild(page)

Sam

Hmm... this is a bit painful/embarrassing... Thanks for the comment that
should have been very obvious to me haha. Thanks!

And Chris, thanks for your comment and I'll have a look into it.

Giac0m0.

I'll be honest, I have a certain amount of disdain for the TDD community,
because I spent about 2 years trying over and over again to effectively
employ the practice with almost no results (actually, frequently
experiencing negative results). Seeing a post to Ruby 1.8.2 (which came out
in 2004 -- reference: http://ruby-versions.net/vault.html\) on Notepad, with
tab indentation on a class named Foobar, I find raises my ire.

I'm pretty sure I have it figured out now -- or at least I have figured out
what works for me. I'll try to record something more useful than the usual
lip service I seem to see everywhere. Maybe this weekend. If so, I'll post
it here for comments & criticisms.

···

On Wed, Sep 28, 2011 at 8:56 PM, Chris White <cwprogram@live.com> wrote:

> > I recommend taking a look at how TDD works. Here is a basic screencast
to
> > get you started:
> >
> >
> >
http://kanemar.com/2006/03/04/screencast-of-test-driven-development-with-ruby-part-1-a-simple-example/

> Are you teaching a man to fish if you tell him "you should stop asking
for
> fish and start catching fish"?
>
> how about showing him what that looks like?

Perhaps "teach a man to fish" was a bad analogy. Oh well, thus is the
mystery of meaning in words. The link to the screencast was meant to provide
a starting point to the process of TDD. Yes, I could have pasted an example
of TDD using the given code, but I feel that knowledge is easier to retain
knowledge when a majority of the work is done by the person doing the
learning. If this person produces some test code and is in need of help in
getting further along, I will be more than happy to provide assistance.
However I digress, as I fear I am starting to derail the original topic at
hand.

Regards,
Chris White
http://www.twitter.com/cwgem

Fortunately, there has been research[0] into the effectiveness of the
"test first" philosophy.

The executive summary: It increases the time to develop software (by
15-35 percent), while lowering the amount of bugs significantly (by 60
to 90 percent).

[0] http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

···

On Thu, Sep 29, 2011 at 4:06 AM, Josh Cheek <josh.cheek@gmail.com> wrote:

I'll be honest, I have a certain amount of disdain for the TDD community,
because I spent about 2 years trying over and over again to effectively
employ the practice with almost no results (actually, frequently
experiencing negative results).

--
Phillip Gawlowski

gplus.to/phgaw | twitter.com/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
-- Leibniz