Re: More thoughts on Lua 5.2

["Fabio Mascarenhas" <mascarenhas@...>]

On Mon, Feb 25, 2008 at 2:05 AM, Duck <duck@roaming.ath.cx> wrote:
>
> Now, AFAIK you can open up and manually move around in 64-bit-sized files
> using 32-bit libraries (and offsets) if you use O_LARGEFILE when calling
> open(), except that we aren't using OS-level I/O, were using ANSI-C-level
> FILE *s, so we're calling fopen instead().
>
> So, you could recompile everything with _FILE_OFFSET_BITS=64, but...
>
> ...is this supported? Was Lua built with it in mind? Can I expect it to
> work or do I need to reinvent my own tests and regression tests every time
> I update my Lua build? What other limits on my ability to access regular
> files in my filing system might exist in Lua's standard library code? What
> things won't work in the real world?

Reimplementing the IO library to use POSIX functions is not hard, and
requires no messing with Lua internals. It s even easier if you write
the bulk of it in Lua itself; I have a reimplementation of the IO
library using POSIX non-blocking IO that is less than 500 lines of Lua
code (using Alien to call the POSIX functions). It would be trivial to
make it support large files after I add "long long" support to Alien.
lfs.lock and lfs.unlock won't work with this IO lib, but they are also
trivial to reimplement...

> (Path length is another problem for the pure ANSI-CD-based io library,
> seeing as it doesn't even admit of paths. Even lfs is somewhat hamstrung
> in this regard, with built-in hard wired string length limits such as
> 256. Sure, you can re#define some of them, but to what? And why? And who
> has tested that before?)

The path length limitation to lfs.currentdir() was removed in the last version.

> I trust LuaSocket and use it happily. But I'd be even happier if it were
> currently at LuaSocket 5.1.3, delivered as part of Lua 5.1.3. Same for
> lfs, which is a separate project, with a different outlook to Lua itself
> on what portability means. (lfs works on Windows, but it isn't really
> portable between Linux and Windows. Indeed, lfs is UNIX/Linux specific,
> but can be compiled "in part" so that a useful subset of it happens to
> work on Windows.)

Have you checked LuaRocks? It works really well (apart from some
quirky defaults) and the number of available packages keeps growing,
and it is doubles as a great build tool to make binary packages for
Windows. The Lua team can keep the Lua core as is for the embedders
and the "Lua as platform" folks can happilly install LuaRocks and
bloat out Lua installations with non-portable packages. :-)

> Several respondents have explained to me how I can solve my >2GB
> "problem", mostly by hacking the Lua sources. But original suggestion was
> of a few additional libs which would help to create a (more useable and
> attractive) Lua distro in which that commonly-needed or expected hacks of
> that sort would simply not be necessary.

No patching to the Lua core is necessary; pathing the Lua libraries is
only necessary if you want to reuse their code, but nothing stops you
from replacing them wholesale, as long as you keep the API for scripts
the same (messing with other libraries internals is frowned upon, lfs
being an exception that has already caused problems in Windows). So
libraries can fix a lot of the shortcomings, and I think having a good
way to deliver them obviates the need to have them bundled with the
core.

--
Fabio Mascarenhas