Re: RungeKutta, WalshTransform and Evol

[Hisham <hisham.hm@...>]

On Sun, Aug 29, 2010 at 5:17 AM,  <pj@pjb.com.au> wrote:
> Greetings folks; my first post here...  Three of my old
> Perl CPAN modules now have call-compatible Lua translations:
>  http://cpansearch.perl.org/src/PJB/Math-RungeKutta-1.07/lua/
>  http://cpansearch.perl.org/src/PJB/Math-WalshTransform-1.17/lua/
>  http://cpansearch.perl.org/src/PJB/Math-Evol-1.12/lua/
> (Of course the version numbers will change, so it's safest
>  to click down from http://cpansearch.perl.org/src/PJB/ )
>
> I"m now trying to learn about Rocks, and make Rocks out
> of them to integrate them better into the Lua world.

Hi,

I wrote and published some rockspecs for these modules:
http://luarocks.org/repositories/rocks/

For rocks this simple, rockspec like the ones I provided are enough.
For more complicated cases, there should be documentation in
http://www.luarocks.org covering the process of creating rocks (but
help improving them is always welcome -- the site is a wiki).

The presentation of all rocks in a single page is of course not very
scalable, but for our current pace of growth, it will still serve the
purpose for a while and then we can move to a nicer page when the need
arises.

Decisions about module naming aren't really within the scope of
LuaRocks (and even the Lua authors don't seem to care much about it
either, with the mechanisms for letting the caller rename the module
and the deprecation of the module() function for Lua 5.2 which will
take the module name out of the .lua file altogether) but we try to
provide some advice and avoid naming clashes in rocks. (Eventually we
could even adopt some policies for acceptance in the main rocks
repository, but right now we're still in the stage of trying to have
the tool itself being accepted by the community, so who are us to tell
module authors what to do...)

Personally, I don't mind having one-lua-file rocks. Sounds better to
me than having packages combining many unrelated things. OTOH, having
rocks that provide many generally related things (LuaSocket's various
protocols, LOOP's various OOP models) is better than artificially
splitting a package in many sub-packages just because a user might not
need every piece of it.

Perhaps over time different module authors could organize themselves
around namespaces (say, various rocks providing math modules being
written to provide "Math.*" modules (as "math" is taken by the Lua
core)) -- these "special interest groups" centered about people
working on related stuff need less central coordination. IMO it might
work better than to have a general list for discussing names of all
modules, where everyone will have their 2 cents about how a module
they'll never use should be named.

-- Hisham