Re: Proposal: Virtualization of Filesystem Operations for Lua 5.2.

[Sean Conner <sean@...>]

It was thus said that the Great Timm S. Mueller once stated:
> 
> I have once written a vfs in the shape of a filesystem and device
> driver architecture for some kind of embedded operating system. It
> supported mounting, multiple roots, loops, asynchronous I/O, locking,
> automounting etc. Lua was adapted to this and part of the distribution.
> The result was fully transparent, in that require, dofile, module
> loading, and even stdin and stdout went through the vfs layer, and
> modules could be loaded from mountable loop devices such as zip files.
> Stdio was shielded completely, not just a little here and there. [1]

  At one point, I had written my own replacement for C's stdio.h mechanism
since I found it limiting [2].  The first implementation was buggy and hard
to use.  The second implmentation was less buggy and a bit easier to use. 
The third implementation was better still, but then I found out about the
various extentions that the GNU C library provides, thought hard about where
my code was going to run (the particular program had run exclusively on
Linux) and being realistic about things, decided to scrap all that code and
go with the GNU extentions (since it provided everything I felt missing from
C's stdio.h).  

  Sure, it's less portible now, but it's also less code I have to maintain. 
Six of one, half-dozen the other.

  -spc (Likes that Lua is small ... )

[1]	Not my footnote.

[2]	The biggest limitation---you can't treat an arbitrary region of
	memory as a FILE *.