RE: Lua libraries

[Nick Trout <Nick.Trout@...>]

CRIBBSJ:
> And even if I had the time to learn everything, I'm selfish!  
>  :)   I like
> the way Lua fits into my head, therefore, I would like to use 
> it for more of
> my scripting needs.  It doesn't mean that its better than 
> Perl, Python, or
> Tcl which are probably a better fit for someone else's noggin.

Thats an interesting point of view :-) And, one I can subscribe to. I can't
be bothered with Perl for that reason, why cram my head full of (more)
chaos. We're all trying to make sense of technology and use it for sensible
simple solutions.


Jim Mathies:
>> Ok, so somehow I think the discussion got off the main topic, which 
was a "standard" way of loading interface libraries...

I'm not sure it did wander off topic. I agree with Reuben that makefiles
should not be used to add this library inclusion system. Its fairly standard
that most source project have more than one platform makefile included for
the vanilla build, so I'll have to agree to disagree with Reuben there.

>> Was there any resolution to this?  I think it would be neat if there
was a way to facilitate this, but I don't think there is a simple, 
all encompassing solution. 

The (*nix) makefile system is not portable enough to be the solution so I
think a simple Lua build system could possibly be the solution. Lua is ideal
as a config language. You could build it out of the box and play with it
with the std dist and then get Reubens enhanced dist for this other
framework which could be hosted by lua-users.org and constantly updated for
new platforms and compilers. Potentially a set of libraries which provide a
config script for the enhanced dist would allow them to be easily linked and
used statically or dynamically with Lua. Well, thats where I'm at! I'll need
some kind of framework for Doris to do this eventually but not quite there
yet. File data lib needs adding for timestamp comparison, I notice this has
been noted on the Harvard std lib discussion list.

Will be very interested to see what come out of that meeting. Quite happy to
leave you fellas to it. Hopefully all this argument will give you plenty to
discuss :-)

>> The loadlib code is going to work, sometimes.
A recompile of Lua is (sometimes) going to be required for certain
interface libs. Especially when 4.1 comes out and people start injecting 
their own data structures into the Lua state.

We could go with Thatchers suggestion in the meantime and Robertos solution.
I havent progressed to 4.1 yet but I can see that as a problem.

>> I don't really think Lua proper should standardize on a set of 
extension libraries though.

There is a set of standard libraries, they are being revised, at least thats
what I think is happening. They may be organised (into namespaces) and more
features added sparingly.

>> ack.. have i helped or made things worse. :) die thread die!

So if we all shut up and ignore the problem it will go away :-) Thats what
this list is good at, people tackle problems head on and then the authors
sift out the relevent information and everything moves forward. I for one
like working in a productive environment and this list feels like one. Its
not just noise (well maybe I go on a bit).

If there was a flexible build framework in place it would compliment the
huge flexibility of Lua. Lua is definitely maturing into a stand alone
scripting language and if standard libraries are being discussed this also
makes sense. But for me its important because if I release portable code, I
want people to be able to build it with ease on any platform, as I have
taken the care to make my solution portable. Maintaining build systems is
boring, I'm sure we'd all rather code, and then you dont have to supply X
different binaries.

Regards,
Nick