Merge from http://code.google.com/p/lua-ex-api
parent
8a083102cc
commit
0b41064bab
@ -0,0 +1,47 @@
|
||||
There are several reasons for using the existing ''io'' and ''os'' namespaces.
|
||||
|
||||
The ''io.pipe'' function depends on the Lua core in order to return
|
||||
newly-constructed file userdata. The ''io.lock'' and ''io.unlock'' functions
|
||||
are both available as metamethods of file userdata (e.g. ''f:lock("r")''),
|
||||
which seems a natural extension.
|
||||
|
||||
overloading file metatable, may as well overload io table too
|
||||
|
||||
Adding a function to change environment variables requires that the
|
||||
implementation of the ''os.getenv'' function be changed, at least on the
|
||||
Windows implementation. If it is not, then unexpected behavior occurs:
|
||||
|
||||
{{{require "ex"
|
||||
assert( os.getenv"NEWVAR" == nil )
|
||||
ex.setenv("NEWVAR", "value")
|
||||
print( os.getenv"NEWVAR" ) -- prints "nil"
|
||||
print( ex.getenv"NEWVAR" ) -- prints "value"
|
||||
}}}
|
||||
|
||||
Another is that require "ex" changes the semantics of some standard functions,
|
||||
notably os.remove.
|
||||
|
||||
The ''os.remove'' has similar requirements since on Windows, ''os.remove'' will
|
||||
only remove non-directories unless ''require "ex"'' replaces its
|
||||
implementation.
|
||||
|
||||
Even if none of the above implementation details mattered, it is the purpose of
|
||||
this API to extend the Lua standard namespaces with additional functions.
|
||||
|
||||
It seems there are only two major concerns about using the existing namespaces.
|
||||
First, there is concern that a future version of Lua might want to use one of
|
||||
these names. This should not be a concern for one simple reason: this proposal
|
||||
intends to be that future version. While it may not be the case that this
|
||||
library would be distributed as part of the Lua core, it is the goal of this
|
||||
proposal that this extension be recognized to be as much of a standard as
|
||||
''package.loadlib'' which cannot be implemented in standard C.
|
||||
|
||||
The other major concern is that extending the existing namespaces would be
|
||||
confusing to Lua users. The best solution to this issue is to make this API
|
||||
(and its major implementations) a part of the standard Lua distribution.
|
||||
Similarly to both ''io.popen'' and ''package.loadlib'', the functions proposed
|
||||
here would be documented in the reference manual and clearly noted that they
|
||||
are not supported on all platforms. Likewise, these functions would throw an
|
||||
error when called on platforms which cannot provide an implementation.
|
||||
|
||||
goal: have standard methods when available
|
||||
@ -0,0 +1,6 @@
|
||||
luaL_Buffer usage in posix/spawn.c and w32api/spawn.c is broken (reported by Rici Lake)
|
||||
w32api/spawn.c spawn_param_args should properly quote arguments according to CommandLineToArgv(quote) (reported by Rici Lake)
|
||||
os.sleep(math.huge) returns immediately on Windows (reported by David Manura)
|
||||
os.dir() with no parameter should use the . working directory (reported by David Manura)
|
||||
Bug in Windows? require "ex"; assert(io.open("234", "w")):lock("w") (reported by David Manura)
|
||||
run in a tight loop, os.dir() leaks handles faster than garbage collection will collect them (reported by m.i.)
|
||||
@ -0,0 +1,16 @@
|
||||
/*
|
||||
* "ex" API implementation
|
||||
* http://lua-users.org/wiki/ExtensionProposal
|
||||
* Copyright 2009 Mark Edgar < medgar123 at gmail com >
|
||||
*/
|
||||
|
||||
#ifdef __APPLE__
|
||||
|
||||
#include <crt_externs.h>
|
||||
#define environ (*_NSGetEnviron())
|
||||
|
||||
#else
|
||||
|
||||
extern char **environ;
|
||||
|
||||
#endif
|
||||
Loading…
Reference in New Issue