Re: [ANN] GSL Shell 2.0 beta1 release

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

2011/11/28 Adam Strzelecki <ono@java.pl>:
> Hi Francesco,
>
> Is there any place in docs where I can find additions to Lua language specification made by GSL Shell? I guess the one is "short function specification" via |arg1, arg2, …| expr, is there anything else?

Hi Adam,

actually GSL Shell *is* Lua, I didn't modify the language with the
exception of the short function syntax that is documented in the main
page. I've made that because I think that it is very convenient for a
software oriented toward mathematical applications.

> Also I wished to ask whether GSL Shell really needs to have its own LuaJIT sources? Why not just link to external LuaJIT GIT repo and particular revision?

Well, I agree with you that it would be better to use LuaJIT2 just as
a library as I'm actually doing with AGG and the GSL library. The
reason why I've included the LuaJIT2 source code is because of the
customizations that I need. With the current release of gsl shell the
only customizations are:
- short function syntax
- customization of the package search path to include also templates
(files .lua.in)

In the past I was using a lot of more customizations to Lua but I've
changed the design to remove all of them and comply with Lua
standards. Now I'm just keeping the short function syntax because I
consider that it is really worth of it.

> From my understanding GSL Shell is set of Lua modules calling GSL/BLAS/Lapack via FFI, ones providing plot functionality and of course shell which is modified Lua shell. That's why it would be IMHO much better if GSL Shell act as extension for existing (installed) LuaJIT, than rolling it's own version. Also all fixes and performance tweaks made by Mike Pall wouldn't need any merges at GSL Shell.

Well, I agree with you in principle but the plot module is special
because it does spawn a separate thread that is in charge of updating
the window. This threads can read the content of some Lua objects so
it cannot be completely detached from the main Lua thread. More
specifically I need to lock of the global interpreter when the window
is closed. Because of its multi threaded nature and the lock on the
global interpreter I think that the plot module cannot be implemented
as an ordinary Lua module AFAIK.

Otherwise there is a small inaccuracy in what you are saying, gsl
shell does not use lapack but only the GSL/BLAS library. I'm thinking
about adding LAPACK functions but for the moment I don't have the time
to develop in this direction.

> Also it would be nice to GSL Shell classes in regular Lua scripts without need to use GSL Shell's shell.

Well, GSL Shell is basically LuaJIT2 with a few additional goodies
like readline support, a more friendly interactive prompt and the
graphical and mathematical modules. If people don't want to use GSL
Shell it is ok to port some modules to be used with LuaJIT2 but I
didn't have any request in this sense. For example the modules for
numerical and ODE integration can actually be written in term of pure
LuaJIT2 modules.

I can consider to port some of the modules in LuaJIT2 is there is some
interest, just let me know.

Cheers
Francesco