Forgive me if I am looking in the wrong place for some of this stuff. I only started looking at this today.
--- Michael Scott <[EMAIL PROTECTED]> wrote: > > I'm fine with that, I understand why - this is not a rant - but I do > think that Parrot has a steep learning curve and that good > documentation is essential if we want to lower it. The potential > benefits seem obvious. I had a read through intro.pod (found a very minor error, patch submitted ) and decided that I might be able to write some tests but I am having a hell of a time trying to find out what tests have been written and which havn't. I have written a few _simple_ tests and deliberately broken a few others and I would like to write a few but I have no idea what needs doing. I have also been unable to find out if there is any sort of methodolgy to the testing. I have had a look through ./parrot/t/* and found a lot of test files but very little actual details on what each test was testing. I could infer from the code what most of the tests are trying to achieve but some docs would be nice. If there are more docs can someone point me at them (I have read most of ./parrot/docs/*.pod) and any other pod I have been able to find. After all that I suppose I should volunteer some time. I have some time on my hands at the moment and would like to get involved in some fashion. Unfortunately I am not a C guru but I am quite happy to write tests[0] in assembler or do documentation. In what areas do people think documentation or tests are most needed, I would be happy to start with the docs first until I am more comfortable with the code, ideas, advice? H [0] As soon as I am comfortable with the assembler, most of the easier tests seem to have been written. __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
