Re: Porting Instructions

["Daniel Collins" <daniel.collins@...>]

> > I also simplified things by removing all the Lua standard 
> libs that my 
> > project doesn't require (IO, OS and String libs). Note that 
> even when 
> > these libs are left out, there are a lot of file and string uses in 
> > the lua code that require changing.
> 
> As far as we know, there are no file operations inside the 
> Lua core.  (It uses sprintf, which is defined in stdio.h, but 
> this is not a real file operation.) In the other libraries, 
> we try to keep file manipulation to a minimum (print in 
> baselib, debug in debug, and loadfile/panic in auxlib.c; 
> string.format makes heavy use of sprintf, but does not use 
> files). String operations we do use without restrictions, as 
> it is easy to implement them in C whenever necessary.

You are correct. I over generalised and did not mean to imply some
problem on the part of the lua code. Most of the functions I converted
to macros were for string functions. And you are also correct that
string operations are easy to implement in C when necessary. I
implemented several of them to make up for shortcomings of the embedded
platform I am using. This was another step in the porting process.

The final step in the porting process I didn't mention was changing the
lua number type to int, and then implementing a fixed point user data
type for those times when I needed it. The only quirk is that the fixed
point type has to be initialised with strings, since fractional numbers
are no longer legal with the integer lua_number. But constructs like:
	pi = fixed.new("3.141")
are not so bad.

- DC