[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: os.setenv()???
- From: "Dolan, Ryanne Thomas (UMR-Student)" <rtdmr6@...>
- Date: Fri, 6 Jan 2006 21:39:14 -0600
Use python or perl or some other bloated language; what you propose goes against Lua's design goals entirely. A standard library as you describe would only run on nix/win32/mac, but Lua is designed to be portable to any system with an ANSI C compiler. My robotic's team uses Lua extensively for our robotics applications for this very reason.
Lua's cause is not to be a full-featured programming language, but a light-weight embedded language, and in this context there is no reason for such extensions. There are other languages which are designed to better fill the niche you describe. If you must use Lua, write your own extension or use one of the modules you listed, but this functionality does not belong in the standard library.
-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br on behalf of David Burgess
Sent: Fri 1/6/2006 8:54 PM
To: Lua list
Subject: Re: os.setenv()???
Well I agree with Chris.
Lua is all ANSI C, fair enough. But there exists posix/win32 libraries
and I (amongst others) have our variations upon these and there is
LuaCheia.
A library that is compatible across nix/win32/mac and covers things like
putenv, stat, getcwd, directory functions (mk, rm and something like
Luiz's directory iterator) would advance Luas cause. I would suggest
an inclusion strategy that dictates that each function is implementable
on all 3 OSs would be a fair initial approach.
Mega libraries that attempt to include all of posix or lots of win32 will
probably fail because noone will ever finish it or get enough cross
platform compatibility.
Anyone else interested in contributing to a standardized Lua extensions
library?
David B.
On 1/7/06, Chris Marrin <chris@marrin.com> wrote:
> But this begs the question about which library I should use. They have
> overlapping functionality. And the Posix library have overlapping
> functionality with lfs. Ahhhhhhhhh!
> It seems like there should be some grand unification of all this ...
<<winmail.dat>>
