|Re: [eigen] External contributions|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] External contributions
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Wed, 4 Feb 2009 08:46:18 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Y83QGG3UHi4uV9HvufGxBChcmLKUcOgT57H9FGlZknk=; b=NBSF1Hx7twdGvbqwG1jUJcUSPNoMm70Jh8L7zf2YXd9u5ubmL3tRliDLQ+OR8e2HJ3 dHg4lQCTZ7T/hyAm6JBG/TB6cfeE9YHZxO3K4H53FBJdT6xVleCp+EXm34pon1P8Xz6p o503JWDZO4eHkYXMsoc9FmqP/G8bsma+mBZ+0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=n0NneN7uyPB9dXe0LFuOzsWiySByZYyfupI/NjOwAGDN28P+XhlHhQDq+7tv1cy3Uo eNkXjBus55SgwI4JqWXqz+/l/xaIUY17mZxTaVfHzlxBr9GyvF/D1AezMSXEqyW5+e9p J194h+/js29Ulw+G6R+UfbtXI9xr86sUoU2vg=
I mostly agree with you,
about the doc, I'm not sure that's doable to easily change the visual
hint of selected set for files, and I don't feel comfortable with
mixing unsupported classes with the other one in the class list, etc.
So I would propose to have two doxyfiles and nest the doc like this:
and of course the main page would link to the contrib doc, and I think
using ctags we can have cross references from the contrib doc to the
main one. What do you think ?
another related (and complementary) option is to put all the
unsupported stuff in an Eigen::unsupported namespace. I don't
remember all the doxygen features but if that's doable to have the
contrib classes prefixed with the unsupported:: namespace prefix, then
that will be fine for me ! (I mean no need to have a separated doc)
I'll see what's doable with my little unsupported contribution.
About the criteria, I would put the barrier as low as possible, but it:
- must rely on Eigen !
- must be math !
- should have some general purpose in the sense that it could
potentially be included in a Eigen module (or become a new one)
- can be very preliminary though
Another way to add contributions is via the demo/example. For instance
if something is very too specific but shows an interesting way of
using Eigen, then it can be a good demo.
On Wed, Feb 4, 2009 at 5:03 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Thanks for your idea. I too have been thinking about that.
> I think that my favorite option is to have a eigen2/unsupported
> directory inside which things are organized in the same way as in
> eigen2/ itself. So it would look like this:
> Then we would install the headers also with the unsupported/ prefix,
> but still in the same eigen2/ directory, so it would look like this:
> The user would either #include as follows,
> or (non default behavior) he could add
> /usr/include/eigen2/unsupported/ also to his include path so he could
> seamlessly do
>> - documentation: the easiest would be to use the infrastructure from Eigne
> Sure. It's just a matter of:
> 1) adding the unsupported/ paths to doc/Doxyfile.in, and backport to
> Mainpage.dox (for api.kde.org)
> 2) copy the CMakeLists.txt files under doc/ to unsupported/doc/. They
> are the code responsible for building the snippets and recording their
>> have for example a different style/background in the doxygen-generated pages
>> to indicate it is not supported.
> That, or any other visual hint, good idea.
>> - contribution policy: what should be accepted as a contribution? For
>> example, I have some template files based 100% on Eigen for mechanics
>> (Recursive Newton-Euler solver for kinematic chains) and control (algebraic
>> riccati equation solver). I am also thinking of a convex optimization
>> interior-points methods at a later point.
> We have yet to write some clear criteria but I can already say that
> what you mention here sounds very good.