gnupic: [gnupic] gpsim, documentation
Subject:
Re: [gnupic] gpsim, documentation
From:
Scott Dattalo ####@####.####
Date:
22 May 2006 18:59:49 +0100
Message-Id: <4471FC0F.4050303@dattalo.com>
Nestor A. Marchesini wrote:
> Looking from out, I see that there are certain things a bit as to the
> carelessness in my opinion it would be very beneficial has a graph of
> flows of the gpsim of way that all the participants have a very
> nearby idea of since as,like the blocks of the gpsim work ... not if
> UML or a conventional graph of flows or both, also would be good to be
> able to comment well the code, I believe that it is the key in order
> that many people could take part in the development of this great simulator
> and at the same time to find mas easily the bugs difficult to rake.
> Only it is my opinion and by no means it is to remove value to the
> great made work till now, but my desires would be people see great
> taking part in the development of gpsim, up to me itself ... though
> my knowledges of C belong to a novice.
Nestor,
I'm not exactly sure what you're saying here. (I think something got
lost in the translation!). But if I have to guess, I think you're
suggesting that if gpsim had documentation describing the software
design that it would be easier for others to contribute to the project.
This is undoubtedly true. Unfortunately, I have not made any developer
documentation and it is not high on my list of priorities. I have
experimented time to time with doxygen. In fact, at one point I even
attempted to write some of the class comments in a form that doxygen can
intelligently parse. You can try experimenting with this if you like.
It's especially enlightening to see the massive class hierarchy!
However, to be useful someone needs to go through and document each
member function of every class.
Another useful piece of documentation would be something to give a high
level overview of the code flow. I did write something like this a very
long time ago and placed it in the back of gpsim's user guide. This
could stand to be revisited and improved upon, but maybe it's enough to
get you going for now.
Oh, patches don't only have to be for code... Feel free to submit a
documentation patch too!
Scott
