[Developers] What we need in ADMB
sibert at hawaii.edu
Fri Jun 18 11:58:25 PDT 2010
This is a good idea and one we have discussed previously, but before we
get too excited, lets think about it a bit more.
Under which license will such contributions be distributed? It should
probably be up to the author of the source code. But we should impose
some restrictions. It should be freely distributed and open-source
(duh). The ADMB project is distributed with the BSD license because it
is short, simple and non-viral.
Who maintains such code? It is almost guaranteed that new compilers will
eventually break contributed code. Who will fix it?
The word "library" is a bit ambiguous. The Martell example is hardly a
libary, it is C++ source code included (with #include} in a tpl. What
about a more complicated libary that might consist of many C++ source
files plus header files. Would this all be similarly included? Or would
it be better to compile the source code into a true library (a file
wrapping a bunch of object files)? Including a lot of source code in a
tpl, increases the compilation time and could increase the difficulty of
maintaining the code.
What other documentation might be required in the source code files?
I'll try to make Martell's example it look like something that could be
freely distributed and post it where it can be viewed.
On 06/17/2010 04:55 PM, Arni Magnusson wrote:
> Good point Mark, this opens a new and exciting chapter for the ADMB
> Project. I have created a new Plone directory,
> containing Steve Martell's instructions and example.
> The R package model is indeed very successful, and was based on the
> experience of older software projects, such as LaTeX. The R approach
> goes something like this:
> (1) For a package to be accepted, every function must be documented in
> a standard format, described in the "Writing R Extensions" manual. The
> R Team provides the service of compiling a user manual (HTML and PDF)
> from the standard documentation format. Furthermore, package authors
> should write an example application or two, demonstrating how the
> function works.
> (2) A package gets kicked out of the collection if the example
> applications crash in the newest version of R, after a few weeks grace
> (3) Specific functions are occasionally promoted from a user package
> into one of the base packages. This is rare and only dicussed in
> "closed meetings".
> (4) Most packages focus on a well-defined theme of tasks, but there's
> also a few PeterMisc and PaulMisc packages around.
> We could adopt a similar approach. The standard documentation format
> would probably use Doxygen, and it should be easy to compile a user
> manual from that. Our Buildbot could test the example applications.
> John Sibert knows Doxygen best, so maybe he can suggest a standard
> documentation format, with an example of what the corresponding user
> manual might look like. To keep things simple, we could work from
> Steve Martell's contribution
> On Thu, 17 Jun 2010, Mark Maunder wrote:
>> From the recently sent around R article under why R succeeded:
>> "The package system, introduced early in the life of R, permits
>> individuals to participate in the development of R without the direct
>> intervention of the R Core group. In a sense, the package system -
>> like version control - is a technological solution to a social
>> problem: how to invite, motivate, and coordinate the activity of
>> hundreds of volunteers without overwhelming the resources of the Core
>> We need to have a place for user supplied libraries. We need to start
>> it off by a number of us including our own libraries. Finally, we
>> need a way to review the libraries, "certify them", then add them to
>> the core code.
> Developers mailing list
> Developers at admb-project.org
Emeritus Researcher, SOEST
University of Hawaii at Manoa
Visit the ADMB project http://admb-project.org/
More information about the Developers