Re: Wishlists and Modules (was [ANN] libmc)

[Andre de Leiradella <aleirade@...>]

I really miss the times when Lua was just an embeddable script language. 
I could just compile all Lua libraries I wanted, make a host application 
or change lua.c to open the additional libraries, link everything and be 
happy.

Now I must leave with modules, dynamic link libraries, requires, paths, 
packages, etc. Or I have to change the modules to compile as good 
old-fashioned Lua libraries which is a great deal of work depending on 
which ones I'm using. Or I have to write things from scratch instead of 
reusing code from the community.

It's sad to see Lua move away from its niche. Or I'm completely missing 
an obvious way to require modules that are compiled into the application 
without hacks... In which case everyone is free to punch, ignore or 
enlighten me.

Cheers,

Andre

------------------------------

Message: 6
Date: Wed, 2 Sep 2009 10:22:32 +0200
From: steve donovan <steve.j.donovan@gmail.com>
Subject: Wishlists and Modules (was [ANN] libmc)
To: Lua list <lua@bazar2.conectiva.com.br>
Message-ID:
	<560972290909020122r13aa2ef1xff1b9344e52364a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> Anyway, remember - it *is* a wishlist. :-)

While we are exchanging wishlists, here's one of mine ;)

Although code may be free (in both senses of the English word) it can
still be expensive in terms of time needed to understand it.  In an
ideal world there would be as little friction as possible in the
process, i.e. that when using a new module, the accidental complexity
should be as little as possible. (May well be essential complexity,
sometimes things _are_ rocket science.)

A The ideal module:
  0 well named (using namespaces)
  1 well focused
  2 well contained
  3 explicit dependencies
  4 documented in some standard way
  5 adequate test coverage
  6 useful examples

A0 may seem obvious but namespaces are increasingly a must.  CPAN is
looking after 16486 modules (!) and the only way that they can coexist
is by disciplined use of namespaces (e.g [0]).  A project needs a cool
name, but a module needs a useful name.

A2 means that a module behaves itself and doesn't mess with the global
table, except to introduce its own table.  A module can of course be
'injected' into the global table, but only on explicit request.

B And the ideal package manager:
  1 handles dependencies
       (must do this automatically, like LuaRocks [1])
  2 integrated documentation
       (must be available from a central index after installation, e.g
like perldoc)
  3 specifies external dependencies in a useful way
       (in an ideal world, it use the native package manager to find these)
  4 searchable for capabilities and module names
       (e.g. that the module 'lfs' corresponds to the package
'LuaFileSystem' - new LR will do this)
  5 flexible tag-based classification
      (so we aren't tied to a inflexible fixed hierarchy, like the
Trove system [2])

It seems hard to do B2 without A4, without resorting to hacks &
heuristics (is there a README? is there an index.html, perhaps in an
'en' folder? ...) So naturally there have been Lua people interested
in the Perl POD format.

B4 & B5 are related; the idea is to get as much searchable metadata
into the system. And hierarchies can be constructed dynamically from
tags.

B3 is a tough one, which is hard enough to solve for one system (e.g.
Debian) let alone the whole universe of platforms, mostly without
standard library repositories.

This feels like a lot of work, which it is, but the idea is to
minimize the amount of work the producer of the module has to do.
Personally I think LuaRocks is getting there, especially with a nice
front-end; (the next version will be using a more 'normal' way to
manage modules) but delivering module documentation is not a major
concern and writing cross-platform rockspecs remains a bit of an art.
I've even toyed with the idea of writing a wizard for writing
rockspecs ;)

Documentation remains a big weakness.  Probably it's that
psychological illusion that code is self-evident, because one's head
is full of the 'meta-implementation', all that stuff and cogitation
needed to write a program, and which evaporates quickly and leaves us
saying WTF? when reading our own code in six months.

steve d.

[0] http://search.cpan.org/modlist/Option_Parameter_Config_Processing
[1] http://www.luarocks.org
[2] http://luaforge.net/softwaremap/trove_list.php


------------------------------

Message: 7
Date: Wed, 2 Sep 2009 04:30:05 -0500 (CDT)
From: yxtor <robert.aronica@arcontia.se>
Subject: Re: Lua/SWIG: output parameters of custom types as
	references?
To: lua@bazar2.conectiva.com.br
Message-ID: <1251883805483-3565721.post@n2.nabble.com>
Content-Type: text/plain; charset=us-ascii


Hello. I am a new user here at Nabble.

I wonder if anybody has an answer to Sebs question? Its really hard finding
documentation
about this.

/Robert



Sebastian Wolff wrote:
> Dear Lua community,
>
> I hope someone already encountered the following problem and may assist 
> finding a solution.
>
> I have an own object class type MyClass and want to wrap a C++ library 
> using SWIG 1.3.39 to be used by Lua. Using this library I often have to 
> wrap methods of the form
>
> void foo1(const MyClass & a, MyClass & b)
> {
>     b.assign_and_action(a);
> }
> void foo2(const MyClass & a, MyClass & b)
> {
>     b.modify(a);
> }
> void foo2b(const int &a, int &b)
> {
>     b += a;
> }
>
> 'foo1' simply returns 'b' reading 'a'. foo2 and foo2b modify 'b' using 
> 'a'. Therefore, in Lua I want to call them by
>
> b = foo1(a)
> b = foo2(a,c)
> b = foo2b(a,c)
>
> To let SWIG know about the parameter types one has to specify which is 
> INPUT, OUTPUT or both:
>
> void foo1(const MyClass & INPUT, MyClass & OUPUT);
> void foo2(const MyClass & INPUT, MyClass & INOUT);
> void foo2b(const int & INPUT, int & INOUT);
>
> For 'foo2b' this is working fine. Somehow it does not work for 'foo1' 
> and 'foo2'. In the latter, all parameters are considered being input 
> variables.
>
> Any ideas what went wrong?
>
> Best regards
> Seb

--
View this message in context: 
http://n2.nabble.com/Lua-SWIG-output-parameters-of-custom-types-as-references-tp2740991p3565721.html
Sent from the Lua list mailing list archive at Nabble.com.


End of Lua Digest, Vol 170, Issue 3
***********************************