[IPOL discuss] question about libraries

[Juan Cardelino]

Fine, that tool server will be nice to have, I think that now that we
know each other personally we need a common place to meet remotely.
And this email should be the starting message on the tools forum :D

In addition, as I've been successfuly converted to the IPOL religion,
I'm thinking about preaching myself when I'm back on my lab, because
we have like 5-6 new students starting now and I think it is the right
time to start showing them things like this. In addition, I will try
to get some of my lab mates to start submitting something to IPOL. For
that, I will need some things that maybe you already have.
The most important would, some slides demonstrating the workflow for
the submission and the creation of a new demo will be nice. Something
like the slides you have shown in the meeting.
I'm more than willing to contribute on the creation of some of these
materials if required. Maybe we can think about a "IPOL preaching kit"
so every one of us can bring that back to our labs.
This could also be useful for the diffusion of IPOL in some local
image processing conferences back in south america that I reguarly
attend to.

Well, I promise this will be my last e-mail.....at least for today.
Thanks.


On Thu, Sep 23, 2010 at 11:45 AM, Nicolas Limare
<nicolas.limare at cmla.ens-cachan.fr> wrote:
> [just repeating what I said, because a written trace is always good]
>
>> Regarding image magick, It could be easily replaced, but I'm more
>> worried about GSL. I'm sure many authors will need statistical
>> functions, and GSL provides them (among other many things); and it is
>> well documented, well supported and has stable implementations. I've
>> been using this library without any compiling problems for years.
>> Could you guys discuss among you if it makes sense to include it?
>
> GSL documentation[1] says
> «GSL is a mature library with a stable API. The main emphasis is on
> ensuring the stability of the existing functions, tidying up and
> fixing any bugs that are reported. Potential contributors are
> encouraged to gain familiarity with the library by investigating and
> fixing known problems in the BUGS database.
>
> To maintain stability, any new functionality is encouraged as
> packages, built on top of GSL and maintained independently by their
> authors, as in other free software projects. The design of GSL permits
> extensions to be used alongside the existing library easily by simple
> linking.»
>
> So, I feel it's a very reliable building block. Moreover, the design
> guidelines[2] show they enforce clean design and high-quality code,
> strict compilation, portability, ...
>
> But for all that, I'd like not to be the only one to decide. I'm
> setting up a tools server, with mailing lists, and I'd like all these
> decisions to come through a consensus. I hope we'll have these lists
> next week.
>
> Last detail: GSL promotes code re-use[3] when possible, often via
> grabbing a source file and including it into another code. This may be
> a simpler solution for users, if the algorithms allow.
>
> And GSL is packaged for Windows[4], everything is fine.
>
>
> [1]http://www.gnu.org/software/gsl/
> [2]http://www.gnu.org/software/gsl/design/gsl-design_toc.html
> [3]http://www.gnu.org/software/gsl/design/gsl-design.html#SEC10
> [4]http://gnuwin32.sourceforge.net/packages/gsl.htm
>
> --
> Nicolas LIMARE
> http://nicolas.limare.net/                         pgp:0xFA423F4F
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkybIa8ACgkQvviFAPpCP0/SBACghlKyIp/vA5AsLqQ+JbmTOvNp
> CdcAn18NpZP5iMNM2AZ72PSFJ3gx1rBn
> =CVbo
> -----END PGP SIGNATURE-----
>
>