Re: GSL Shell software announcement

[Francesco Abbate <francesco.bbt@...>]

Hi David,

thank you very much for you feedback and your help with LuaDist. I've integrated your suggestions, now the file 'makeconfig' allow you to

- disable the support for complex numbers => GSL shell can be loaded as a library

  with a standard Lua binary, you will only miss complex numbers and related functions

- if you enable 'enable-shared' only the shared library will be builded and gsl and math

  functions will be in a separate namespaces. Please note that in this case you cannot

  load 'igsl.lua' and 'integ.lua' as it is but this is probably a minor problem

I've also improved/simplified the makefile. I've also completed the support for the integration

routines: http://www.nongnu.org/gsl-shell/integ.html

now integrating a function with an algebraic-logarithmic singularity or calculating a Fourier integral is like eating a piece of cake :-)

More seriously, now GSL shell features a more that complete interface to the numerical integration routines of GSL and the documentation is also more beautiful.

I will appreciate any feedback.

Best regards,

Francesco

2009/10/7 David Manura <dm.lua@math2.org>

On Sun, Oct 4, 2009 at 10:12 AM, Francesco Abbate wrote:
> I've done like you suggested, now the Lua file 'lmathlib.c' is unchanged.
> I've changed only my top-level file, gsl-shell.c in order to charge the math
> library as you suggested, thank you very much.
> So, now GSL shell just use a vanilla copy of Lua 5.1.4 with LNUM patch, I
> don't know if this help in order to put it LuaDist. For me there are two
> possible utilisation of GSL shell:
> - as a stand-alone program => in this case a top-level program charges all
> the needed
>   library. In this case we can collapse the math and gsl functions in the
> common namespace
> - as a normal lua library => in this case a separate namespace is used for
> gsl and math
>    functions. I've already integrated this possibility in the software with
> the FLAG
>    USE_SEPARATE_NAMESPACE in defs.h
> For me it would be nice if GSL Shell can be made available as a library to
> Lua users even in my main goal in the stand-alone program.
> Francesco

Thanks.  Here's some more comments:

- gslshell builds from LuaDist now [1], as least under Linux and
MinGW: "luadist ~/gsl install gslshell".  This in turn builds the
dependencies gsl and lualnum.  (Side-note: It's better to install into
some alternate location, e.g. "~/gsl" as above, since gslshell
installs lualnum, which would otherwise overwrite the standard version
of lua that LuaDist is running under.)

- gslshell doesn't currently build under MSVC, Cygwin, and maybe
others due gslshell's dependency on complex.h.  If you allow that
dependency to be selectively disabled, we can make it work on these
platforms too.  A lot of applications under standard Lua that might
want to use gslshell as a library don't require complex numbers.

- The gsl-shell application currently statically links to the
gsl-shell module code instead of dynamically linking to the gsl-shell
module.  This is made necessary because the gsl-shell module defines
USE_SEPARATE_NAMESPACE, while the gsl-shell application expects this
to be undefined.  I think the better way to do this is to always
enable USE_SEPARATE_NAMESPACE.  Then in gsl-shell call some function
that moves or copies the members of the "gsl" and "math" tables into
the global table as a convenience.  In gsl-shell, I see no reason not
to have both math.sqrt and sqrt defined and both cnew and gsl.cnew
defined.  This would allow a user to run standard Lua code inside
gsl-shell.

- The gsl Lua module is named lua-gsl.so.  This implies that the Lua
gsl module is loaded by require "lua-gsl", which in turn creates the
table "gsl".  It would be more consistent to name this gsl.so so that
the user can do require "gsl".  (This gsl.so is not to be confused
with libgsl.so, which is GSL itself.)

- I think reStructuredText/Sphinx is solid stuff and would recommend
other Lua module authors consider using it, despite perhaps (like me)
an initial hesitation with the superficial ".. :: _" syntax.

[1] http://lua-users.org/wiki/LuaDist